@mrsliff said in OVPN Server with DD-WRT client - remote network not reachable: 10.1.200.0/24 (OpenVPN network for p2p connection) Since it's a P2P, you should use a /30 mask for the tunnel network. @mrsliff said in OVPN Server with DD-WRT client - remote network not reachable: also set up Firewall rules to accept any to any on OVPN Network Rules on the OpenVPN tab has no impact on the outgoing traffic to the client side, only these ones on the LAN.

Silly me, I was missing the client specific override that tells the server to route the network behind the client. All good now!

@profit As long as this [image: 1613546397429-ed41177d-9e73-42f7-b072-cd834e561321-image.png] isn't running, its normal the OpenVPN client won't be able to connect. So, first things first : Start the OpenVPN Server "New_VPN" and look at the log : [image: 1613546801603-05ba0ecd-f85f-4f39-bc4b-2d25d67a3324-image.png] if it stops executing, it should log the reason. @profit said in Service not running or connecting...: No matter if I create a new server... Somewhat normal, if you use the same 'wrong' settings. What settings ? These settings : https://www.youtube.com/watch?v=jQHqPq7ftz4 are known to work.

@jimp thats the nuance I was missing, thank you. The servers cipher order is CHACHA20-POLY1305 AES-256-GCM AES-256-CBC AES-192-GCM AES-192-CBC AES-128-GCM AES-128-CBC Configuring pfSense with only AES-128-GCM added to the allowed data encryption list, and having AES-256-CBC as the fallback data encryption list results in a client side of data-ciphers AES-128-GCM:AES-256-CBC. Given these two configurations its correct that the servers higher preference for AES-256-CBC is selected over the GCM cipher. My mistake was thinking the client had more control, and the fall back option was a last hope fallback, not evaluated equally and as part of the allowed cipher list. thanks for clearing this up

@zombat Deleted the OpenVPN server and recreate it without using the wizard. Seems to work now.

@viragomann Hi, I will try, thanks

@stevemosher said in OpenVPN Limits?: Hi there, We are trying to load up a couple nord tunnels here. We can successfully get 2 running but when we try a third we keep getting "Unable to contact daemon Service not running?" I tried this also with another VPN service and again pFsense will only allow us to create 2 per vpn service provider. Man how stupid can stupid be. I didnt even enter a password :) We can close this

@m0t0b0y1337 said in PfSense-OpenVPN only conection: I do not have a license to use its vpn. there we will use pfsense. understood? Well then just replace it with pfsense - problems solved.

@viktor_g thank you very much. That explains it.

@johnpoz Update : The Issue is fixed now by re exporting the client profile and dns is also seems to be working.

Users have a hard time understanding leak test to be honest. For example if you point to google you might get all kinds of different IPs, not the 8.8.8.8 you are pointing to. If you point to some vpn DNS, a dns leak would show you the resolver IPs that its pointing too.. And not the specific IP your pointing too.. All a dns leak test does is have your client look up some unique fqdn.. And then what IP actually came and asked for that specific fqdn.

@griffo said in Route Traffic via VPN: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html The second choices is what I want. To route all outbound traffic to my VPN provider.

@johnpoz True. I never said that it has something to do with pfsense. But I found the problem and perhaps it might be interesting for others. I dig a bit further and I did figure out that it has to do with the MTU Size of the packets in connection with certain providers. How did I come up with it? Yesterday I did configure one Notebook here in the office with openVPN and rdp connection. I did use our Guest lan to test it. openVPN => works RDP => works Today the Notebook is at home and I have the described problem. So I did start playing arround with ping MTU size (option -l) and did figure out that I can get a reply with packet size 1471 but not anymore with 1472. I did use the custom option in openVPN server config and did try it with tun-mtu 1300; and it works! I will now try to figure out what the best MTU size is. thanks a lot for your help, always usefull to me!

@viragomann I agree, and we run pfSense with that turned on our on-premises hardware. However, when installing the official AMI in EC2 (and paying for it), I'd expect the defaults to be compatible with AWS' virtualized hardware edge-cases.

@gertjan Thanks for the link to the channel. I will definitely see everything. You have two interfaces. OPENVPN OpenVPN do they both need them to work correctly?

So after deleting the Virtual IP, clearing the "IPv4 Remote Network(s)" fields on both of the OpenVPN configs and adding in Static Routes for the remote subnets, it seems this is now working and the Static Route persists between tunnel reconnects. For some reason it still doesn't seem to work without defining a Static Route for the remote subnets to route over the VPN Interface gateway, but nonetheless, it works! Would have never even considered to look in the Virtual IPs, thanks for your help @viragomann

@tsptsp So there should appear hints in the OpenVPN Log to find out the reason.