You should NOT give any IP Configuration to the assigned OpenVPN Inerface (check https://www.netgate.com/docs/pfsense/book/openvpn/assigning-openvpn-interfaces.html). Why don't you just hand out one separate pfSense local User for each of your real User? This will add more Security and you are able to give different access rights based on Firewall Rules. -Rico

Thanks for sharing gateway settings

I think I found a solution. From https://www.reddit.com/r/PFSENSE/comments/7or0bt/pia_vpn_leaking_ipv6/ System -> General Setup -> DNS Server Override (unchecked) System -> General Setup -> Disable DNS Forwarder (checked) Services -> DNS Resolver -> DNS Query Forwarding (checked) Reboot I am now posting on this forum while using my pfSense router and all seems good

Yeah, you need an additional phase 2 for the routing between the remote network and the OpenVPN tunnel subnet. So the phase 2 has to be added on both site of the IPSec tunnel, of course. In the OpenVPN server settings add the remote network 10.50.0.0/20 to the "IPv4 Local network/s".

Actually I don't have any problem with 6.7 (running Windows Server and Ubuntu Server VMs), seems also strange that problem is caused by vmware because it should affect also traffic from the Windows client that it's behind pfSense but runs VPN flawless without packet loss. I've followed all requirements and suggestions in order to virtualize pfSense on ESXi so everything it's already enabled (with VMXNET ethernet interfaces) and it's working fine since some years & upgrades (I think I've installed it when there was pfSense 2.1 and ESXi 5.5/6.0)

You have this firewall rule on your WAN interface : [image: 1537551394239-166422c1-9ef1-4195-b266-4e1289058c2f-image-resized.png] My 1194 is your 1200. Just for testing :if you make this firewall rule on WAN : [image: 1537551643036-1dde5799-c17c-4a72-a525-86796299fe66-image-resized.png] can you access the pfSense GUI from "Internet" ? Using https://myvpn.my-fqdn.tld or https://a.n.c.d ? If not : something is blocking between pfSense and the rest of Internet.

Ended up finding that Client Override needed to be enabled on the Server Side PFsense. Once we enabled this, everything started working.

@thenarc Thanks for trying anyway. Yeah, watching the CPU usage was one of the first things I tried and it definitely isn't a problem as far as I can see, not even close. I'll keep trying different configurations, but if you or anyone else thinks of something then do let me know and I'll owe you a beer :-)

Sorry, it was an idiotic error on my part. I was using the wrong .ovpn file. Problem solved!

No, iroutes are not needed in that mode.

@bcruze said in Connecting to AirVPN with OpenVPN and Gateway issue: https://airvpn.org/topic/17444-how-to-set-up-pfsense-23-for-airvpn/ i learned ALOT by reading and following this guide. there are still things to uncheck but you have to read the entire thread. my connection has been 100% stable if i just stop tinkering. good luck Airvpn is a great provider (tunnel settings uncheck BOTH that you have checked) you can also type IFCONFIG at the diag > command prompt and your tunnel interface gateway will be listed towards the bottom.. Alright, ill check this out thanks. @rico said in Connecting to AirVPN with OpenVPN and Gateway issue: With 0.1ms RTT I don't think you are Monitoring the other Tunnel Side (VPN Provider). -Rico I thought this was strange also, considering my local ISP gateway was 8.9ms and 2.2ms

Firewall rules - lan- add each of your devices (assign a static up to then from dhcp lease page). Anyways add them again to the above then change the gateway to your vpn gateway If you don’t have another gateway your vpn isn’t setup properly... my setup like this has been working for years! Pfsense is an amazing firewall

I have found some more. This is apparently a known issue that is caused by changing the Monitor IP on an OpenVPN-Interface. Here is the bug report: https://redmine.pfsense.org/issues/8142 And here the discussion linked in the report: https://forum.pfsense.org/index.php?topic=138608.msg764734#msg764734 The issue is still present in 2.4.3-RELEASE (amd64). The only workaround I have found without resetting the system was to change the subnet of the Ubuntu OpenVPN-server to something different than x.x.x.0/24. x.x.x.0/24 seems to be forever blocked by the non removable route. If anyone has any updates in that regard, I would be highly interested, so please let me know! Kind regards, Holger

In the OpenVPN client settings check "Don't pull routes" to avoid to get pushed the default route by the VPN servers. Assign interfaces to each client instance and enable the interfaces. Edit the firewall rules on your LANs which are allowing the upstream traffic, expand the advanced options, go down to Gateway and select the appropriate gateway. In System > Advanced > Miscellaneous check "Skip rules when gateway is down". Consider that firewall rules with stated gateway allow traffic passing that gateway solely. So you will need separate rule to permit internal access it you need, for instance DNS to the pfSense interface.

@derelict Thanks Derelict. I will have a further look into it. It seems I cannot replicate this issue anymore, but not much has changed. I will return if I manage to figure it out. Thanks

There is usually no reason to use push route commands any more. Put the network in the Local Networks field instead.

@derelict I will try to post the network diagram. We are using two Devices at the Remote sites: An Intel NUC running custom data acquisition software which periodically publishes messages to the MQTT Broker at the central site . It initiates the OpenVPN channel to the central site via the 4G cellular wireless router. There is a power controlling/monitoring device at the site which has a web and SNMP interface. We need to occasionally check or reconfigure that from the central site. We would like to SSH into that device from the central site across the OpenVPN tunnel. All of this palava comes about because of the "carrier grade NAT" at these Remote sites, which means we don't have static IP addresses and DynDNS doesn't work so we need to open the comms channel from that end.