@ddbnj Basically it doesn't matter, where you add the rules, however if you have already assigned an interface, I'd prefere the interface tab. It's quite simpler. For instance, if you add a block rule you can use any at source without affecting the other VPN instances. Furthermore if there is an incoming traffic from a public source on an OpenVPN interface (forwarded from the remote site) you have to care, that there is no rule on the OpenVPN tab mathing it. Otherwise responses are not routed back properly.

@viragomann the 192 address is my local LAN making the requests. "So again, my assumption is that the remote site is missing the route back to this LAN IP and so its not possible to direct its packets correctly into the VPN, instead it will send them out to its default gateway." I agree that if the server side was missing the route back, it wouldn't know what to do with the traffic and how to send it back, but the key bit I'm not getting is that shouldn't I see that traffic emerging from the tunnel on the VPN side, the bottom tcpdump on the second screenshot. I fully get why I don't see any traffic coming back into pfSense from the VPN side, because no traffic is sent back, but I don't get why I don't see the ICMP requests that go in on the top of the screenshot come out on the bottom. Where does that traffic go? I'm sure you are right with what you are saying, I just want to know where the packets go missing. I thought that if they went into a tunnel they would come out the other side, even if they then got lost and the next hop sent them the wrong direction and out the wrong gateway.

The router from my ISP is setup in 'modem only' mode, it does not perform any routing or wi-fi functions, its only connection is t othe WAN port of my pfSense unit. I run Unifi switches and access points all of which sit behind the pfSense unit. I am guessing that since I only have the one WAN IP, once the VPN tunnel is opened from the pfSense firewall, the VPN IP is now perceived by all clients to be their external IP, whereas previously when I ran a VPN on an individual device, the VPN IP only applied to that single device. In effect running a PIA VPN tunnel from the pfsense firewall can only act as a 'whole house' VPN, regardless of what firewall rules I may use. I have also noticed a severe drop in bandwidth when using the PIA OpenVPN tunnel on the pfSense firewall. All tests were performed from my iMac desktop: Test Case down/up No VPN 386/20.8 pfSense + London 152/19.8 pfSense + Southampton 205/19.4 VPN app + London 303/19.5 VPN app + Southampton 293/19.6 The PIA app based firewall is using wireguard, although until recently it was using OpenVPN, the results using the app are usually within 50-60Mb/s of the figures with no VPN (they are a bit down today), but never as bad as those shown for OpenVPN on pfSense. Looks like I may be sticking with local VPNs for now. For comparison, I ran a speedtest from my media server using a wireguard based PIA tunnel to the same London server and recorded speeds of 317/19.6 with the VPN tunnel and 322/21.1 without. The media server is connected to the same switch as my iMac, both with 1m cables.

@tunge2 According to the above referenced post , and the redmine inside that post. It seems that the issue was introduced in 2.5 /Bingo

Show as the outbound NAT rules and check, that every client got a different private IP address from your VPN provider. If they share an address, it will not work.

@viragomann Thanks I'll try this tomorrow and post the screenshots.

I just wanted to follow up on this, in case anyone else runs into the same problem. The way I was doing it is for a 1:1 VPN. I solved it by following these instructions: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html A bit more complicated setup, but it's now working.

@jagradang Hi, I am not at my machine at the moment, but I found out what this issue was. In the 'General DNS Resolver Options' , Outgoing Network Interfaces is set to nordVPN (as per the instructions). However if you set this to WAN, it appears to work. To be honest I am not sure what the 'real' exposure is.

Also a more advanced question, is it possible to enable UPNP at Site A such that they're applied at Site B?

I fixed it! Sort of... There was a OpenVPN client override. The address wasn't complete, I guess I must've missed it. I don't remember setting it at all though, maybe somebody else did. Upon restoring some areas from the old firewall the outbound NAT was restored without matching the gateway, so that was another problem. The finally the gateways were correct, the routes were correct but pings would only work one way.. I kept resetting things until neither could ping. I have frequent backups for both firewalls going back for almost a year, I always took them at the same time so settings would match but none seem to work. Even after adding allow-everything rules on the tunnel I cannot get it to ping, it just stopped. Installed FRR, didn't help. [image: 1617976884153-wrong-openvpn-gateway11.png] [image: 1617976913554-wrong-openvpn-gateway12.png] Then I tried playing with the ciphers with some interesting effects, like tanking all connectivity despite the tunnel is no set as the default gateway in either side to the one sided thing. However, it was when I switched to shared key that I got connectivity back. It had always been as a TLS tunnel, I don't know what's different now. [image: 1617977011383-wrong-openvpn-gateway14.png] [image: 1617977011309-wrong-openvpn-gateway13.png] But the tunnel is merely a conduit to have a static public IP disposable at any moment; it's considered as a WAN interfaced and policed as so thus I could care less about encryption security or anything else, I'm just soo grateful it works again. :D Now I have to close it up 'cause it's still wide-open-firewall as I speak. I tried IPsec BTW, but it had mismatching numbers, then I tried to "play its game" so to speak so I duplicated one of the P1s so the interface numbers would match. They did, but it still never connected. Since this is heavily dependent on encryption as well as the TLS OpenVPN, I think there might be something wrong with OpenSSL or whatever's behind the scenes there--that's just my highly uneducated guess though. Anyway, maybe this helps somebody else.

@griffo said in Help diagnosing 2.5x OpenVPN Issues: @griffo A new day, a bigger cup of coffee and I worked it out. Two issues a) the NordVPN guides say to add the option tls-client to the custom config. With this option left in, it will connect but not pass traffic. There's obviously a TLS mismatch going on but it works without it. b) with the option "Don't pull routes" NOT selected in the client, the pfsense box does not seem to give the gateway the addresses correctly. Bizarrely when I was doing a packet trace I could see the ICMP packets for the gateway monitor flying around, but in the system -> routing -> gateway screen no gateway or monitor IP was listed. Changed those two settings and it works. Not sure if either are bugs or just a change in behavior of the new OpenVPN client version? @Griffo Thank you sooooooooo much for writing back the solution here ! I was experiencing the exact same problem after upgrading from 2.4 to 2.5 and a tunnel interface to NordVPN. Removing tls-client; in custom config is working fine for me too. Wow ! Merci beaucoup !

@amir75 said in SSL VPN goes down: "Version 2.4.4-RELEASE (amd64) built on Thu Sep 20 09:03:12 EDT 2018 FreeBSD 11.2-RELEASE-p3 The system is on the latest version." Yeah, that's known. The package system is brain dead, or DNS settings have been broken by the admin, the file system got a blow in the face by a power loss, etc - and he system says it's up to date (because it fails to prove otherwise). Or, TV channels, Youtube (thousands !), the Netgate's announcement blog (twitter, redit, etc) , or the thousands of messages posted on this forum might have inform you that 2.5.0 is out and 2.5.1 is coming. @amir75 said in SSL VPN goes down: Should I uprade to it or an other one more stable ? Maybe. My personal advise is : play with it first. And if it pleases you, upgrade. I now, it's 2021, but I say it ones more : always prepare a way to retrograde. If you can go back, you will never do so (extension of Murphy's law). At least, read about it. See if there are current issues with functionalities that you use. For me, 2.5.0 vanilla on a I5 box is just great, better as 2.4.5-p3 which was already more then ok (for me ) - VPN server for remote access works - and recently I discovered that OpenVPN client works ( for me : using Expr*ssVPN where many said : it's broken, so go figure )

I turned on the “Allow multiple concurrent connections from the same user” option only after the original post in this thread. With that checked, two concurrent clients using the same certificates get distinct IP addresses. That option turns on a configuration line in /var/etc/openvpn/server* that says duplicate-cn A post on ServerFault had pointed me in that direction.

@bambos said in OPENVPN to secondary LAN: @hossimo to my understanding, restarting the open vpn service rebuilds the routes of accessible networks again. so it's important to restart the service on any change. That does seem to be the case in this instance. After some additional testing I found that removing or adding the interface deleted the routes and restarting the solved it. I should have just restarted the router in the evening and that would have also brought it back, at worse it would have been a trip to the color, but know I know I can just restart the service to the same effect.

Maybe this is the best way to solve the issue: [image: 1617765546112-screen-shot-2021-04-06-at-11.18.36-pm.png] Are there any opinions out there, as to which approach is best?