Just a note .... Have you guyzz actually tried to revert the negotiated algo's ? As it is , a working negotiated setup , might select and use 128-bits instead of 256-bits. Below the window it says the order is respected. And that makes me always put 256 before 128 I don't have Nord , and haven't upgraded to 2.50 yet /Bingo

@gertjan I checked the logs and did more research. It turned out to be a compression issue and I had to add push route... to the advanced settings. The config file was not changing the compression when it was no longer adaptive (Bug?) in the open vpn server config. So it kept on creating a file with adaptive compression. I commented out the compression line and it works now.

Yes did follow the vpn provider guide, thanks for the video link. Still does not work, bit stuck now and frustrated been over two weeks of struggling, might give up on this provider.

Updated and simplified explanation: @viragomann Thanks for your reply. Any RFC 1918 could be used for TN*. Let´s say it is 192.168.100.0/24. And it is distict from any other used net. O.k. You recommended a smaller net, but the functioning VPNs are /24 too. There should be no problem with the tunnel itsself, as with additional routing information on a clients sides computer, packets are passed through, and to answer another question: From a computer on site of the PFsense to the remote site and back. Analyzing the routing table shows 192.168.100.1 (OpenVPN server side) as a gateway for the remote network. In the routing table 2 entries with gateway "link#12" for 192.168.100.1 and 192.168.100.2 (OpenVPN client side) can be found too. I guess "link#12" means that 192.168.100.1 and 192.168.100.2 are some kind of bridged. This is analog to what I can see on a remote PFsense acting as a client. Ping to the remote site is possible, if a route on the pinging maschine is added to the remote net with 192.168.100.2 as a gateway. (In the routing table of the PFsense 192.168.100.1 is used as the gateway) Some site on the internet suggests to take out the remote net from VPN client configuration and add a route with 192.168.100.2 via SSH, config.rc etc. I don´t like such solutions, because you can´t find them in config-firewall....xml I think the "system-routing" menue won´t help in this situation. What has gone wrong. Why points the routing table to the transfer ip on the other side (192.168.100.1) and not to his own ip of the transfer net (192.168.100.2)? Why does this work between pfsense only and not generally with OpenVPN? Is there/will there be a fix for this problem? Another try to desribe: A packet for a remote site computer is sent to the PFsense. The PFsense has a routing table rule to send it to 192.168.100.1. This IP is assigned to the remote site and the packet is not routed. I didn´t make this entry -it is automatically created- But it would need to be 192.168.100.2 which is an ip of PFsenses side of the tunnel. I´m I allowed to post a link outside netgate.com? Would make the problem much clearer.

@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.