The point is if that feature is not disabled and the gateway is detected as down, the rule still exists but without the policy routing applied so all that VPN traffic goes to the routing table and out WAN in-the-clear. This is the default behavior. By default, when a rule has a gateway specified and this gateway is down, the rule is created omitting the gateway. This option overrides that behavior by omitting the entire rule instead. tagging/tagged is the best way to ensure traffic that should go over the VPN does not go out WAN. If it should go over the VPN tag it. Do not let anything out WAN with that tag.

Not a problem from 2.3.4 just a nasty route on the wrong place …

https://forum.pfsense.org/index.php?topic=130407.msg718680#msg718680

Uninstall your package and then reinstall it – don't just do a reinstall/upgrade. If you were coming from a much older version there was a bug a couple revs back that could delete the template files, so the template pkg needs reinstalled, which would only happen if you removed it completely then reinstalled it.

Well, reinstalling the openvpn-client-export package added back the Export tabs, but I found out it also changed our client export files. I downloaded a new config file & found that the two bottom lines in the old version's client config file:       tls-auth pfSense-udp-<port>-<username>-tls.key 1       ns-cert-type server Were replaced with the following line:       remote-cert-tls server I updated my config file (instead of right-clicking and selecting "Connect", select "Edit Config") and now VPN connects like normal. I updated the package to 1.4.5 this morning, and it still connects fine after making the change above.  Now I just have to update the config file on the other laptops.</username></port>

Yep. Just create a * * * rule on the OpenVPN interface (or limit it however you want.) Until you do, no traffic will pass on it.

It's not simple to have the firewall do that, you have to use a somewhat redundant gateway+route as described here: https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

Hi all Still no have access to file server nor server mail. I have on openvpn rules * * * * and also in lan rules I have * * * * but if i go on diagnostic/ping and try to ping my file server from my vpn server, i can't

^ good example, if your not using user certs to validate user as 2FA then there is really nothing that can not be publicly published. And you don't have to worry about the certs because your using a different OTP as your 2FA..

I would imagine that you could follow the guide to setting up a Private Internet Access (PIA) VPN, and just replace anything in the guide that is specific to PIA with the information from hide.me.  Maybe combine a tutorial for PIA with the hide.me tutorial for setting up a client on an DD-WRT Router?  The hide.me DD-WRT guide on their site for an OpenVPN configuration should give you what you need to swap out with PIA when following the PIA guide. DDWRT Guide: https://hide.me/en/vpnsetup/ddwrt/openvpn/ PIA Guide for pfSense: https://forum.pfsense.org/index.php?topic=76015.0

the rule looks good.

@jameswebb: Can you try disabling TLS-Auth - then we can try and pick out the problem further if this works. James Alright. So I disabled TLS-auth for the remote OpenVPN. And rebooted a few times, to test. After each reboot, I can connect from my client w/o problems (deleted the tls auth in the config). BUT it seems OpenVPN server 2 (p2p) got somehow affects as now the pfsense cannot tracert nor ping the branch office pfsense (not even the tunnel IP) but the branch office pfsense can successfully ping the headquarter pfsense. (that worked before, I even tested a anything-open-for-anything rule for LAN just in case) After that I enabled TLS-auth again, with the original key. My client was still able to connect successfully. After that I rebooted once again and it remains working. So the bug seems to be fixed, which is great. The pfsense can still not ping the branch office pfsense (yes the BOpfsense has a rule on OpenVPN to allow anything for the HQpfsense and as written it was working before). I'd like to get that working again, too. But as long as both OpenVPN are working again without flaw also after reboots I'm quite happy again. Thanks for the hint.

I actually have the issue on all UDP ports. My VPN provider says to use UDP 2000 or something like that and if that doesn't work try UDP 53. I get the same speed issues on both. But not on TCP 443.