But are you not worried that you will be leaking dns from pfsense when it checks for updates and package list, etc. <rolleyes>;)</rolleyes>

An auth error is considered a hard failure by the OpenVPN daemon and it shuts down. Try adding this to the custom options in the client's advanced config: auth-retry nointeract; Service watchdog should also work.

Ok, I've narrowed this down.  It seems the redirect-gateway command is what's preventing IOS from switching from cellular to WiFi when "Cellular Only" is enabled in the OpenVPN settings.  Any thoughts?

any help please

Very true - but the export gui is not designed for that fancy stuff ;)  You would would have to edit the config by hand for that..

@sirbusby: After upgrading to version 2.3.4-p1, static IP clients in openvpn do not work. Earlier I registered in the Custom options ifconfig-pool-persist /var/opvpn/ipstatic.list. The file specified the correspondence of ip adresses. Now after restarting openvpn in the file /var/opvpn/ipstatic.list, ip addresses are overwritten Yes, some trouble were detected in Open VPN connexion.

Its also just screams – person doesn't know what they are doing at all ;) Then that seems to have served my purpose well. I changed my LAN interface to 10.233.233.1/24 and everything is working now! Thanks for the feedback. I'm still trying to wrap my head around how it was a problem but for now I'll have to accept that I'm not as smart as my mom tells me I am.

No, I said to check Don't Pull Routes not Don't Add/Remove Routes. Check Don't pull routes Uncheck Don't Add/Remove Routes

You could always just pass DNS (TCP/UDP on port 53) to This firewall and then block all other TCP/UDP port 53 destinations. If that's really what's important to you.

Thanks - solved my problem as well. I would have thought this was a pretty common configuration.  An easier to find guide for newbies would be helpful.

pfSense will add a static route for the monitoring IP via the given interface. If there is a x.x.x.x address is used there then the router will always send traffic for that IP to PIA, adding latency for non-VPN users and breaking Geo lookup (in DNS case). I'm using there one of Level 3 DNS resolvers (4.2.2.1 - 4.2.2.6)  which I don't need to contact for any other purpose.

How is the client supposed to know which DNS server to use? Before it knows the answer to the query it has no idea if the destination is out on the internet or over the VPN. You are probably best off sending the queries to the DNS server over the VPN and letting it return the appropriate answer.

@SpaceBass: out of curiosity, it looks like your screenshot is of the client end. Does the client eventually time out and reconnect? Yeah, it's a client setup to a 3rd party VPN provider.  And nope, the client doesn't time out and reconnect on its own.  The service is completely stopped in pfSense until I manually log in and restart it. I've had success testing the Service_Watchdog package in a VM.  Just enabled it in production.  This may be a decent workaround. I'm still curious what the root cause of the service failing in the first place.

Also upgrade the OpenVPN clients.

I have the same issue with a IKEv2 VPN. The VPN clients don't route through squid / squidguard. Does anybody have a solution / configuration to get this working together?