Yes, both are configured to to listen to the wan gateway group, but different ports.

I've tried doing this a NAT: [image: 1750866954364-044467cb-9aba-43cd-9478-da27475ebcfe-image.png] Resolving in no port open and no trafik towards my host, as a simple nginx page. This is what I would Normally do NAT a port to a service. I'm testing with https://ismyportopen.com/ - or directly onb the IP:PORT With my VPN-CLient created as a Interface - without any rules for that Interface: [image: 1750867425016-4f35e0a9-d1fa-42c2-93a0-5cb8d1a679aa-image.png] Since my VPN-client are created as an Interface - I would like to think there should be the rules under this interface for incomming rules. Where I should believe (as the torguard as a Interface) should look like this instead: [image: 1750867966347-498a8fdc-11a4-41ff-990f-983764915838-image.png]. But I'm not getting through in any of the 2 ways to my nginx. No issue with internal IP and port - which showing nginx testpage

@itinfo PICNIC I'm glad, that it was as simple to resolve.

@rajukarthik As I'm sure you've found, you can bind the OpenVPN to both WAN interfaces, so that's the first part. After that, I can think of a couple of ways to sort out incoming clients. Quick and dirty - publish 2 A records for vpn.mycompany.com with the respective WAN IPs in each. The downside is that there's no real way to have the clients 'prefer' one WAN over the other (so not great if you have a fast leased line primary and DSL backup, for instance) and that if you have a failure it'll take a while for clients to sort themselves out and use the other IP. Use DDNS - sign up a DDNS address to use for VPN. You should be able to configure configure PFsense to update it with the 'main' WAN when that is in use and then drop back to the backup if you loose your connection. I'm sure there are guides about on this.

Has anyone found a solution to this?

@johnpoz Hey so I actually got this working via OpenVPN for my LAN network on the first try...every device in 192.168.1.0/24 now has the VPN provider's public IP. However, the remote access device connected through my OpenVPN Server (tunnel network 192.168.6.0/24) still has my local IP, even when I add equivalent NAT and firewall rules. What do I need to adjust to also send the remote access device through the VPN client? Do I just assign it an IP on the LAN network range instead?

@SteveITS said in pfSense 2.4.5->2.6.0 OpenVPN: "no route to host": @bartgrefte Library errors can mean the wrong version of things was installed. Specifically how did you choose update branches etc? Did you try to update or install a package after? (See my sig) If starting back far enough Netgate usually recommends just installing new and restoring the config file. I chose the branch on System->Update -> System Update ( pfSenseIP/pkg_mgr_install.php?id=firmware ), this after the update to 2.7.0 didn't start, then thought it might be better to go to 2.6.0 first which I selected on that page. Couldn't do anything after the update because due to the down connection with PIA-VPN, there was no internet access in pfSense. I'd have to find the tutorial about the "kill switch" firewall rules to see how that works, been so long I set this up I've forgotten how... The library issue aside, did anything significant change between 2.4.5 and 2.6.0 that could influence OpenVPN connections? Other than the "no route to host" (and library issue with the proxy server) I've got nothing to go on, setting up the connection with PIA seems to go without any authentication or certificate errors, just the "no route to host"-error. edit: @SteveITS Just checked pfSenseIP/diag_routes.php and compared the working and not working install. There are no routes related to ovpnc1 on the not working install. Seems there's no route being created upon connecting to PIA.

SOLVED: This is possibly a bug. In the client specific overrides, the IPV4 Remote Newtork setting doesn't have the desired effect. When I removed that setting and added iroute 10.20.120.0 255.255.255.0 to advanced settings, it began working bidirectionally, between all nodes.

@abonent1978 If the only VPN config present contains : remote 171.x.x.x 1199 Then where does "92.113.146.1:1194" come from ? What / who is the client VPN ?

Several things will affect performance. VPN will always be slower due to the encryption-decryption processes. What else is the VM host doing ? Have you tried other encrytpion algorythms ? What CPU is the client using ? Perhaps run PfSense on it's own hardware ?

@IT-META I guess, your "TLS Key Usage Mode" is wrong. You can either configure it for authentication only or auth + control channel encryption. Check your server settings and configure the client accordingly.

I found an error in the RADIUS server setup that has fixed this issue.

@patient0 Thanks much, I'll check it out!

For reference, the site-to-site environment we had set up between the two locations was based on this official Netgate configuration: [OpenVPN + OSPF Site-to-Site Setup] This is the exact topology and integration model that was implemented, that worked flawlessly until the upgrade to 24.11, which further supports the conclusion that the issue lies with the OpenVPN tunnel performance rather than OSPF itself.

@pietsnot56 said in Endpoint address family (IPv6) is incompatible with transport protocol (udp4): Any idea what's wrong? Many cell networks are now IPv6 only. On Android devices, 464XLAT is used to connect to IPv4 only sites over an IPv6 only network. iPhones use something similar, but I don't know the details. Perhaps there's some issue there. My phone gets the IPv4 address 192.0.0.4, which is reserved for 464XLAT, as well as a global IPv6 address. I have pfSense configured to allow openVPN to use either IPv4 or IPv6 to connect. Do you have IPv6 available from Telenet? BTW, Telenet used to be an X.25 packet switched network back in the dark ages. The company I used to work for provided Telenet in Canada and I maintained part of that system.