@johnpoz Thanks for the reply! I think I understand what you're saying with the nat reflection, but why is this the case if both pfsense, and the ISP modem have different public IPs? Also just to clarify: if you want to connect to pfsense while on pfsense wan network Sorry if this might be trivial, but just to clarify, do you mean if I'm trying to connect to pfsense from the devices connected directly to the ISP modem (devices on ports 2-5, and wifi)? just use its IP whatever rfc1918 address that is Aren't RFC1918 addresses just private addresses (10.x.x.x, 172.x.x.x, ...)? If the WAN interface has a public IP, how would you find the rfc1918 address? (Again sorry if this is trivial)

@rico Sorry I don't understand that why this is not possible or doesn't make any sense. [image: 1658484001319-1c390efb-8d29-4bee-97e6-e2d4a6a15bf9-image.png] Peer to Peer = Side to Side Remote Access = Client to Server (client = Laptop or device from external network) Me: I want to have: Peer to Peer (SSL/TLS + User Auth) <- Does not exist! Is this correct?

@viragomann That was it! Its now working. Thank you for your help and patience

I'd try the TLS Encryption and Authentication option in OpenVPN first. -Rico

@alextsic Hattest du Erfolg? Ich habe genau das selbe Problem, das hinzufügen von Routen unter VPN funktioniert nicht. Vielleicht kann ich mich hier mit meinem Fall äussern: LAN: 10.108.36.128/25 Tunnel VPN: 10.0.8.0/24 Static route: 10.252.12.0 /22 via Gateway 10.108.36.130 /25 Ich versuche eine Webseite im Netzwerk 10.252.12.0 /22 zu erreichen. Der DNS im LAN Netzwerk löst die Webseite auf mit der IP im Static Route Netzwerk. OpenVPN hat diesen DNS als Server als Nameserver hinterlegt und nslookup funktioniert auch einwandfrei. Static Routes haben nicht geholfen und auch nicht Force jeglichen Traffic durch den Tunnel. Der Gateway 10.108.36.130 /25 ist noch mit anderen Netzwerken verbunden, werden jedoch nicht von mir verwaltet, daher keinen Einblick was dort passiert. Mein Verdacht: 10.0.8.0/24 ist eventuelle ein Netzwerk das er schon kennt und der Traffic wird nicht an nicht zu mir zurückschickt bzw. er ist so konfiguriert das er nur Traffic von 10.108.36.128/25 akzeptiert, ist das eine Möglichkeit? Gibt es eine Möglichkeit den Traffic von OpenVPN in ein NAT umzustellen das es von 10.108.36.128/25 kommt?

I finally figured this out. I had to manually re-create an Outbound NAT rule for the NordVPN interface. Once I did that, everything started routing as expected. Very strange that an update caused the previous config to bomb. Either way, It is working now and I hope this helps somebody else out! Below is what I added: [image: 1658087577878-4e19b52f-ab7a-4a84-9906-83bb7a1e52c3-image.png]

@dimskraft said in Back route of second OpenVNP connection not added: I don't think gateway groups help here, since "client" has only one WAN The gateway group should include the OpenVPN gateways, and there should be two of them as well in the client.

@viragomann: I fixed it, but that was not the issue. What was the problem was that I had configured the OPT port, even though it is not in use, to use the same IP subnet as the VPN. With that having been changed, everything is working now. Thanks for your help!

OK, so deep diving, this does not function as expected in pfSense if you try and chain CA certificates. It just doesn't and hard-fails. The only way to do this is to use a single-tier OpenVPN Certificate Authority and then things just work. Unfortunate, but this is a solution we can work with (everything's stored in a X.509 cert management utility so nothing is lost and everything is equally secure). Just annoying I can't use the intermediate chains...

@bartkowski Try removing WireGuard and then going again.

@wspence Yeah, it's not expected to see any route for an IPSec P2P with traditional phase 2. The IPSec Status page shows if the connection is established properly. And if you can reach the other site everything should be fine. To give the OpenVPN users access to the remote sites you have to add two P2 to each site: On location 1: P2-2: local network: 10.10.10.0/24 remote: 192.168.11.0/24 (I guess) P2-3: local network: 192.168.1.0/24 remote: 10.10.50.0/24 loc 2: P2-2: local network: 192.168.11.0/24 remote: 10.10.10.0/24 P2-3: local network: 10.10.50.0/24 remote: 192.168.1.0/24 Also to the OpenVPN access Servers you have to add the remote network to the "IPv4 Local Network/s" on both sites: loc 1 / 2: IPv4 Local Network/s: 192.168.1.0/24,192.168.11.0/24

Found the problem, sort of, and it's not with pfSense (never really thought it was to be honest). In the GUI version of NetworkManager it shows the VPN connection as down every time I connect, but if I connect manually in the terminal with the exact same credentials the connection is up, and I think I know the reason why. I use an external dongle to get ethernet on my utrabook. NetworkManager does not see the card, not in the GUI or in "nmtui". Still it has a driver and is working obviously. So because the Ethernet interface is not present in NetworkManager, then it seems it cannot use that interface to establish the connection, which seem logical. Before I set up pfSense I always used the Wireless interface to connect to NordVPN, and that is present both in the GUI and in nmtui. The strange thing is that it is NetworkManager that manages my network connections, and when NetworkManager stars in boot up and the dongle is connected the interface works and gets a name if you look it up in the terminal with "ip a", yet the interface does not show up in "nmtui" or the GUI version of NetworkManager. Oh well, as long as it works.

I’m no longer receiving the route from the server, log output above. I can mainly add the route manually on the client side and get it to work. Also - Radius logins is broken in this release. Jul 11 19:53:39 openvpn 55807 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options Jul 11 19:53:39 openvpn 55807 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.20.0

ok i got it working i did have that the "SSL/TLS + User Auth" what i noticed i didnt notice before for both site to site and remote access the description is "openvpn remote access" i had for both.. i did not know that under Client Export under "Remote Access Server" it goes by description and when i read it saying "openvpn remote access" thought i was fine.. when i clicked it i had 2 "openvpn remote access" i never knew that was "Description" and not name of the certificate... i know if i used openvpn alot i wouldnt make mistakes like that.... too bad for newbs they didnt offer a little note under Client Export under Remote Access Server.. Server name is from Description Name from Server Tab... or under the Servers.. when you write Description.. like it say "This will be Remote Access Server Name" i never clued in at all till i found i had both desc same and that made the difference... didnt even know

@blasterspike Thank you for updating the bug. Since Jim Pingle took ownership and rejected it, I'm hoping he'll get update notifications, review it, and consider reopening it. If not, I'll look for other ways to reach out. I suppose you could open a bug of your own, too, if you thought that was a good idea. You could just refer to 13327 and report you're having the same experience on the current release. I'm not sure which approach will be the most effective. We know it's a real bug - it's just that the developers don't.