@massimope this is a really old thread, and not about internet access.. But about policy routing where was forcing traffic out a specific gateway, ie the vpn..

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing

If your trying to get multiple vlans to use your vpn client connection.. That would be most likely related to your outbound nat, not including your vlans networks..

Vs jumping on a 3 year old thread.. I would suggest you start your own with your own details of what exactly your wanting to accomplish.. Are you policy routing out specific to your vpn client connection, are you wanting to default route everything out the vpn?

What is your outbound nat settings? etc..

@viragomann Yes the same local database for all users. I guess this can be chalked up to "gremlins" in the system. All the other accounts using the openvpn are still working after the host name resolution change. I even considered the fat finger syndrome - :) - but that was eliminated with repeated copy/pastes. Still scratching my head on the cause? However, it in now not as critical, since I have a work around. I appreciate your help!!

@viragomann
Hmm, not sure I already did that. But let's see. Thanks.

@utnuc said in Client can't see LAN servers after connect:

creating an A-Record with cloudflare to point to 10.0.0.2,

Well that tells me your client isn't using your local dns then, but you said it resolved to 10.0.0.2 - so maybe your browser wasn't using your dns.. But using doh, the makers of the browsers being smarter than us love to point the browser to their dns vs you know the one we tell the OS to use ;)

When you defined the OVPN, you specified an IP range to assign the incoming connection. By default, traffic OUT of those ranges is allowed and the traffic IN to the subnets/VLAN is BLOCKED. Simply go to each of the subnets and ALLOW traffic from the OVPN ranges appropriately.

@omegahacker
As I mentioned, it is due to the reply-to tagging is not happening if a pass rule on an interface group matches the incoming traffic.
OpenVPN is an interface group. It is generated automatically, when firing up an OpenVPN instance, be it a client or a server.

The reply-to is needed to route response packets back to the proper non-default gateway.
The reply-to tagging is done by the firewall rule, which passes the traffic.

However this requires that the interface is unique. Since rules on interface groups or floating rule can be applied to multiple interface, it isn't unique and the reply-to tagging is not done by such rules.

And yes, interface group and floating rules have priority over interface rules. Hence you have to care, that there is no pass rule matching the incoming traffic on a non-default gateway interface for proper routing back the respond packets.

Here is my transfer performance using Wireguard

DOWNLOADING FROM SERVER (Server upload performance)
fa6458705745c2fe12cf2ee4b989de6b[1].png

UPLOADING TO SERVER (Server download performance)
cbd266b143cfdf96762c54a44e8b5656[1].png
I'm very happy with these results.

@nettolc91

What was the IP you were using , 192.168.1.1 ?
Should work if you use the 'perfect' VPN (server) 'LAN' rules :

aab00203-dcb3-4870-bad7-b135e433809b-image.png

My OpenVPN server uses the "192.168.3.1/24" tunnel, my phone got 192.168.3.3, and I could access 192.168.1.1 (the LAN pfSEnse IP) just fine.

edit : oh lol : The GUI web server also listens on 192.168.3.1 (The VPN interface) so I could access the pfSense also using that IPv4.

@Bambos said in site-to-site OpenVPN with client side with dynamic IP and behind NAT:

Maybe you have setup (in the beginning a firewall rule taking into consideration the "source IP" as well ??

Yup, I'm a dummy. That was it. My firewall rule for the OpenVPN port (standard is 1194) was restricted to an Alias Group containing all the public IPs of my clients. I've disabled that group for now - just until I can get a static IP for the client that moved.

Thanks!

@dgall

On the Client Export tab, select Inline Configuration. I use Network Manager on openSUSE and it can directly use the OVPN file.

@LukasH
With Inter-client communication enabled, pfSense cannot filter the traffic, because it doesn't enter the interface.

@viragomann I've switched FastestVPN to use their wireguard option as all of my wireguard connections are working.. only OpenVPN having issues... so at this moment, the only VPNSecure isn't working as wireguard isn't available on that provider. But the original FastestVPN openvpn connection had the same exact problem.. nothing goes out.. but can access LAN

Hi @Aseknet
I apologize for the delay in responding. I made the recommended changes and tested them on the same day, but there was no difference.

However, yesterday I tried reconnecting and it started working. The new exported client from AES-256-GCM and the old are also functioning properly. I can't figure out if the issue was with the key or my ISP. Thank you so much.

@brepo

I feel a little sorry for myself, because I spent more than 10 years with pfsense and everything suited me before :)

Another advantage is the ability to use the cryptographic acceleration hardware built in the firewall Netgate appliances, the use of DOC, control access with radius, or even set up local access policies, direct use of syslogs and a granular level of security by way of a magnitude of logs available directly on the firewall, a separate access control list can be used for OpenVPN. Share a NAS private cloud with your family for photos and large files. Many types of encryption algorithms are also available, and Netgate’s open source community that can help you with issues. Finally scheduling, an ability to set up when users can access the VPN even lock it completely out on holidays.

@PerfectBake420 NVM. I had a failover internet on the same IP scheme as Site 1.

I've crawled through the routing tables (previously posted), and I find nothing incorrect. The tracert result from a client behind the Z router/OpenVPN client to a client behind the Y router/OpenVPN server shows the correct first two hops, and I can see no reason why it should not find the final destination (10.55.73.193):

@wmcneil said in SG1100: routes seem correct, but not working:

tracert from Z windows client (192.168.2.135) to Y client 10.55.73.193:

> > 1 1 ms <1 ms <1 ms cabin_pfSense.localdomain [192.168.2.1] > 2 33 ms 31 ms 39 ms 10.55.203.1 > 3 * * * Request timed out.