@robato I have gateways setup for my vpn tunnels. Gateway monitoring via dpinger is pinging across the tunnel. If pings fail at a rate set up under routing / gateway advanced, then I get an email from pfsense. It sounds similar to what you would like to achieve. Set up a client gateway and make sure it's pings go across the tunnel. If gateway fails, so should pings and you should get a notification. -Devan

@wmw509 I'm talking about simple firewall rules. That's part of the basic setup of pfSense. Start here: Rule Methodology

@tanguyims said in OpenVpn: When I don't set the ifconfig-push 10.0.8.5 255.255.255.0;, my client gets an IP provided by OpenVPN DHCP And what's the tunnel pool network? Show your VPN firewall rules. BTW: When configuring a CSO, you should better enter 10.0.8.5/24 (subnet topology presumed) into the "IPv4 Tunnel Network" field instead of using "ifconfig-push".

I found the solution as to how to bypass a vpn on the protonvpn [this is a real nologs vpn based in Switzerland] ln this page protonvpn.com/support/pfsense-vpn-setup/ Basically the idea is to go to the specific vlan , or if you have a single LAN and want to exclude an IP range or host from the vpn you create a rule in Firewall-->Rules for the VLAN/LAN and identify the interface (LAN or a specific VLAN) identify the source (host, alias, interface[vlan] etc.) go to Advanced and change the Gateway to WAN. Then go to Firewall-->NAT--Outbound and switch mode to auto save/apply and go back to Manual. It works. I tried setting my vlan to access the WAN directly, but that got me no connection outside my VLAN. I suspect that is because [ its somewhere in this massive trail of notes] that the settings for OpenVPN say something like "pull all connections" or something similar. Which seems to direct everything to the VPN. Anyway, although I am not connected to ProtonVPN in any way, I would recommend them for their veracity, clarity and support. And want to thank them for solving a problem that a whole trail of notes leading to 10 or more pages did not seem to answer.

I know this is an old post but it is directly relevant to my needs. I've had a hub and spoke pfsense/openvpn for years but only using the basic config fields with no advanced 'push' or 'iroute' commands. For the most part routing works but sometimes there are issues and I'm wondering if this is a better way. For reference my current setup is detailed in a recent post: OpenVPN hub and spoke with AD/DNS on spoke I'd like to try the configuration suggested in this thread but I don't have the luxury of changing to contiguous subnets - I have 5 spokes and their subnets are all over the place (mix of 192.168.x.x, 172.x.x.x & 10.x.x.x). Therefore I'd like to understand if I have the config right in this case. Looking at the OP's original subnets, I'm wondering if the following config would have worked. I've added a third spoke for completeness. The only tweaks are in the server's IPv4 Remote Network/s field, the server's advanced 'push' commands, and the CSO 'iroute' commands. OpenVPN Server: LAN: 192.168.248.0/24 Tunnel: 172.16.0.0/24 Client A: 192.168.246.0/24 Client B: 192.168.249.0/24 Client C: 172.27.30.0/24 OpenVPN Server Config: Server Mode: Peer to Peer ( SSL/TLS ) Protocol: UDP Device Mode: tun Interface: WAN Local port: 1194 IPv4 Tunnel Network: 172.16.0.0/24 IPv6 Tunnel Network: blank Redirect Gateway: blank IPv4 Local Network/s: 192.168.248.0/24 IPv6 Local Network/s: blank IPv4 Remote Network/s: 192.168.246.0/24,192.168.249.0/24,172.27.30.1 IPv6 Remote Network/s: blank Compression: No preference Type-of-Service: blank Duplicate Connections: blank Disable IPv6: blank Advanced configuration: push "192.168.246.0 255.255.255.0"; push "192.168.249.0 255.255.255.0"; push "172.27.30.1 255.255.255.0"; Client Specific Override Client A: Common name: (matching with certificate name) Tunnel Network: blank IPv4 Local Network/s: blank IPv6 Local Network/s: blank IPv4 Remote Network/s: blank IPv6 Remote Network/s: blank Redirect Gateway: blank Advanced: iroute 192.168.249.0 255.255.255.0; iroute 172.27.30.1.0 255.255.255.0; Client B: Common name: (matching with certificate name) Tunnel Network: blank IPv4 Local Network/s: blank IPv6 Local Network/s: blank IPv4 Remote Network/s: blank IPv6 Remote Network/s: blank Redirect Gateway: blank Advanced: iroute 192.168.246.0 255.255.255.0; iroute 172.27.30.0 255.255.255.0; Client C: Common name: (matching with certificate name) Tunnel Network: blank IPv4 Local Network/s: blank IPv6 Local Network/s: blank IPv4 Remote Network/s: blank IPv6 Remote Network/s: blank Redirect Gateway: blank Advanced: iroute 192.168.246.0 255.255.255.0; iroute 192.168.249.0 255.255.255.0; Any comments or advice is very much appreciated.

@viragomann Thanks for the reply and all the answers, I will research and continue to attempt to get it configured correctly. I almost got it, but am taking a break today, maybe tomorrow. There is an app for linux, I do have it installed, I see the open vpn configs, but I need to get the app configured and the firewall configured still, to get it working. I really appreciate the tips and clarification!

@darkcorner said in Internet access lost with OpenVPN: Why doesn't Internet browsing work without this setting? If I ask to direct all traffic via pfSense, I would have already had to use the DNS of pfSense, Imagine the clients resides in 192.168.1.0/24, his network settings are IP = 192.168.1.25 mask = 255.255.255.0 DNS server = 192.168.2.3 So his DNS server resides in another subnet, which he is able to access via his router. Now the VPN clients establishes the VPN connection and as you have checked "Redirect gateway", the client changes the default route and point it to the VPN server instead of his local router. Hence he will no longer be able to reach the DNS server at 192.168.2.3, cause this traffic is directed to the OpenVPN server as well. Why did the navigation stop after some time? If I was missing DNS, I was missing them from the start. Possibly due to his local DNS cache.

Good ideas, I will try these out when back at the office. My concern would be that the VPN server IP's might not be static but I will take that up with the VPN provider.

@nsai said in OpenVPN clients can only ping, but can't access any of the remote servers: pfSense is not the gateway in the LAN. So the LAN devices cannot route back packets properly to the VPN clients. They will send respond packets to their default gateway. Best practice to solve is to set up a transit network between pfSense and your router if that is possible. pfSense must not have an interface in your LAN. On the router you have to add a route for the VPN tunnel network pointing to pfSense. Other options are either to add routes on all LAN devices for the VPN tunnel network or do masquerading on pfSense to translate the source address in packets destined to LAN devices into the LAN IP. The TCP request packet is not reaching LAN interface. Did you check that on pfSense itself? I cannot really believe. If so, there must be something wrong in pfSense oralso pings should not passed. Presumed your firewall rules are allowing all traffic.

Found the issue... had several 1:1 NAT rules and can't have the openvpn wan ip on it as the 1:1 bypasses it. All good now. JP

@viragomann The router has no GW. It is set in bridge mode. WAN port not used. [image: 1641836824389-tplink.png]

@mode said in OpenVPN Client does not connect after update from 2.4.4 to 2.5.2: i see it will not be easy to fix this Easy or not, most pfSense users use the latest version. 2.5.2 CE or equivalent if the use a Netgate device. My pfSense OpenVPN server access for remote management works fine - using an iphone OpenVPN connect app, or the OpenVPN connect on a remote W10 PC (me at home).

@jimcorkery NetBIOS is not supported across a peer-to-peer VPN. As mentions you can provide your internal DNS server to the clients in the OpenVPN access server settings, but the clients may need to use FQDNs to access the remote sites, since they are not joined in the remote domain.

@dennis100 ah if your clients can not do it? Then you have a bit of a problem.. But that is something you would want to implement because it keeps noise away from your vpn.. Only authorized clients to actually even start a conversation with your vpn, etc. But I find it hard to believe the viscosity client could not do that.. Its basic openvpn stuff.. Maybe not do tls-crypt, but they should be able to do at min tls-auth edit: so quick google found this, so there might of been a problem with older client, but looks like from that that the viscosity client should for sure support tls-crypt https://www.sparklabs.com/forum/viewtopic.php?t=2647 Here is tls-auth I found on their site. So clearly they support it, you would just need to set it up https://www.sparklabs.com/support/kb/article/advanced-configuration-commands/#tls-auth Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack. In a nutshell, tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.

Thank you so much for responding, @viragomann. It was solved

@johnpoz Ok, so I got this fixed. My older install only had a single Data Encryption Algorithms listed under the client side. The new had a bunch listed by default for some reason. I made the new match the old and this appears to have corrected the issue, as the VPN's are working again. Note that my REMOTE VPN's continued to work, only my PEER-PEER VPN's stopped working. MP