@divsys Appreciate the heads up. Gonna wait for a fix for all this. Right now I'm getting by as a Wireguard client.

@sensecanuck said in VPN up Gateway up - No Internet: Solved in this thread by disabling Data Encryption Negotiation. https://forum.netgate.com/topic/161040/openvpn-client-showing-100-packetloss-following-2-5-0-upgrade/10 Thank you sir. Just got back to town and this worked. For those who are having this same issue the following two things will fix this issue: Uncheck "Enable Data Encryption Negotiation" or Remove "tls-client" from custom option settings in OpenVPN

@viragomann Yes, I was assuming the ciphers are identical on both sides and they were. But as I figured out "Enable NCP" was activated. After disabling it the connection attempt succeeded. So, everything seems to be ok now. :-) Many thanks for our help!

@jknott ok thank you :-)

@stephenw10 thank you :-)

@hieroglyph thank you :-)

AES-GCM would be the best choice.

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.