@demihalf

What you are asking for is what Gateway Groups do. Under System >> Routing, configure a gateway group that includes your two VPN connections. Configure your primary VPN as Tier1 & secondary VPN as Tier 2. And configure the gateway trigger for member down. Then configure your routing policy rules to use the gateway group as the outbound gateway.

No need for a walk through, just read up on these pfSense routing configuration items, that's what they do.

@codemonkey76
By any chance are you running pfS 2.4.3?
I ran into this same problem when upgrading from 2.4.2.
No change in Configuration(s). Same firewall rules.
Can connect and ping port addresses of pfSense box, but not beyond.
Worked perfectly with 2.4.2 (and 32 bit versions).

Same openvpn version (2.4.4), same SSL library version(1.0.2m) on both 2.4.2 and 2.4.3

I'd like to understand what has broken.

@jausk said in Extremely slow OpenVPN:

Update: switching to TCP seems to improve performance significantly. Over TCP I'm getting 30/30mbps

UDP does not acknowledge sent packets, TCP does. Generally, due the extra overhead of acknowledging packet exchange via TCP, tends to cause more overhead, thus less achieved bandwidth vs. UDP, which is why UDP is the default for VPN services. And protocols that use UDP are considered to tolerate intermittent packet loss.

So if you're experiencing an increasing in throughput with an acknowledged exchange protocol vs. a lossy protocol, that suggests something in the connection link may be priority throttling /losing/dropping packets, affecting overall throughput based on lossy vs. lossless protocol exchanges. This also does not rule out a packet size negotiation issue that may be the difference between your UDP and TCP connection differences.

If TCP is giving you improved bandwidth over UDP, use that the explore if there is a packet fragmentation or priority issue in the upstream link between you, your VPN provider, and your target throughput test service.

@sparkman123 said in Cloudflare DNS + PIA:

@TechyTech:

Then create two outbound float rules on your WAN interface, the first to allow only DNS-SSL to CloudFlare, and the second to block/reject any non SSL DNS out the WAN.  This will restrict only DNS-SSL out the wan while the WAN is being used for DNS until the VPN links come up and DNS traffic is routed out the VPN.

For the second rule you mentioned, I assume you would create this rule by blocking any traffic whose destination port is 53 and destination IP is not 1.1.1.1?

Basic answer Yes. I actually have a few rules I use depending on what I'm playing with. Since I also have been testing Tenta's DNS-SSL, I create an alias of DNS forward hosts, then one rule to allow only DNS-SSL (port 853) to allowed forwarders (defined by host alias), then another rule to block any other DNS (53/853) in case any other client tries to use their own DNS, so that only my defined forwarders are allowed only DNS-SSL out the WAN and any other DNS activity (SSL 853 & non-ssl 53) is blocked. Mix and match as you need but the jist of it is to allow only DNS-SSL, restricted to the DNS provider of your choice if you desire, then block any other DNS activity egressing via the WAN that didn't pass the first rule, until the VPN link is up and routes to DNS are shifted over.

Ultimately I only have rules on my WAN that allow only DNS-SSL to specified forwarders and OpenVPN to specified VPN hosts, and everything else egressing the WAN is blocked. This allows DNS to get the VPN service host address, and connection of the VPN links, and blocks anything else that may default out the WAN until the VPN links are brought up the the routing is shifted over to the VPN links.

Also, have you tried your configuration with any dns leak testing sites? i.e. dnsleaktest.com or whoer.net? My problem is, regardless of my settings, I get US based Cloudflare is detected as my DNS server.

1.1.1.1 like googles 8.8.8.8 is an ANYcast address. Basically when you access it it's like saying give me the closest UNIcast address associated to this ANYcast address. How your ISP handles AS group routing may affect the use of ANYcast addresses and the resulting UNIcast accessed host.

As example: When I run the DNS leak test, it detects the actual IP's of the Cloudflare DNS servers that got accessed, not the 1.1.1.1 / 1.0.0.1 address that is configured as the forwarder.

For example, when I use my normal LAN connection with my regular default gateway, I get Cloudflare US as my DNS (as expected). When change the default gateway of my LAN to my VPN connection (which is a tunnel to the UK or New Zealand) I'm still getting Cloudflare's US based DNS servers even though I should be getting Cloudflare's servers in those countries.
Based on this behavior, from what I can tell, It's almost like the DNS traffic has its own independent tunnel outside of the VPN/default gateway.

This depends on where the traffic is coming from and what you have configured for outbound interfaces under DNS resolver. If coming from your LAN it will go via policy or default route as LAN rules define, but if initiated from the firewall, coming from the DNS resolver, unbound will try to access all configured DNS directly out each configured outbound interface, even bypassing routing. To wit, it will keep track of which DNS was accessed and how quickly, via each interface and attempt to optimize future activity from there.

When using a VPN client and shifting your default route this can cause some unexpected behavior between expected routing due to direct out the interface access. So, in short, where your LAN client is getting routed to, and where pfSense sourced services are routing to do not always go the same routes.

Simplest way around this is to only use on the lo or 127.0.0.1 interface as the outbound interface for DNS resolver under pfSense, this will cause all traffic from the firewall dns to go through routing, as well as limit unbound from attempting to access each defined forwarder more than once (all forwarders per each outbound interface), such that when your VPN client is up and becomes the default route, your DNS traffic will shift to the temporary default route (def1) accordingly. Similarly is to define a gateway for each DNS under System >> General, this will cause a static route to be created for that DNS when the defined gateway is up, otherwise it goes through default routing, but he same direct out interface issues noted above still come into play if you have additional interfaces defined.

It seems like I have finally solved this while debugging some other issues I've had with an OpenVPN client connection.

The final solution for this problem seems to have been that pfSense cannot set up routes correctly to openvpn client connections, and instead falls back to setting the interface as "lo0" when checking netstat -rn. I debugged this while creating a dummy route towards 1.2.3.4/32 under "Static routes" and attempted setting my OpenVPN clients gateway as the route, and then checked "netstat -rn" for the results.

After editing my OpenVPN client setting " IPv4 Remote network(s)" and adding 0.0.0.0/0 to it, I am able to set this connection as gateway for certain addresses and, for example, DNS-servers under General Settings and seeing pfSense finally setting the gateway to "ovpnc2" as the interface instead of "lo0".

i've done this for years..

i assigned my devices static ip addresses that i wanted the traffic going through a different gateway. once that is done and your VPN connection is working go to: firewall > rules > Lan > add that computer and identify it so you know what it is, edit the rule then under gateway change it to your WAN interface.
apply

everything else will go across the VPN like normal. only that device will transfer over the WAN interface

I presume, the routes on the client are not added by pushing from server.
Check the clients routing table.

can you list providers that have moved to this cipher?

i am still using CBC with no issues

also this: https://www.netgate.com/blog/more-on-aes-ni.html

"AES-GCM in particular has problems with side-channel attacks on pure software implementations. ChaCha20, which nicely avoids these issues when in software, isn’t an option. This is because: a) it’s not RFC-compliant, and b) there are currently no acceleration offloads for it, and the situation is that there could be thousands, or tens of thousands of pfSense instances hitting a single (clustered) instance of our cloud management platform."

Are the network settings correct on the switch? Is the internal pfSense IP the gateway on it?

Another reason could be that it blocks access to management interface from addresses outside off its own network segment. If this is the case you can get it working by an SNAT rule on pfSense.

Probably possible but you'd have to write a bunch of php to do it.

They are pushing that anyway.

Maybe you could configure 5 different clients to connect to 5 different AirVPN nodes.

This thread solved my issue - https://forum.pfsense.org/index.php?topic=147108.0

Added remote site's LANs into Access server's config.

Works fine!

Thanks!

That is from an issue with the openvpn wizard. Already fixed in 2.4.3_1 and 2.3.5_2

So the client can't reach 8.8.8.8.  :o

According to your routing table, it should be routed to your default gateway 192.168.7.254.
Try a "tracert 8.8.8.8" to see where it stucks.

Maybe it helps to route the DNS server over the vpn. To do so, add "8.8.8.8/32" to you "IPv4 Local networks" in the vpn server settings (comma separated from other networks).

Also an outbound NAT rule for the vpn tunnel network on WAN is needed in this case. Maybe it was added automatically by pfSense.

If you upgrade to 2.4.3-p1 that wizard issue has been fixed. So if you use the wizard again after upgrading it will be OK for future tunnels. Editing the current rule and fixing it manually will work around the issue on 2.4.3.

I know saying "me too!" isn't the biggest help ever.  However, I also have run in to this issue.

I have my WAN Gateway and running OpenVPN for my other gateway.  At random, my internet kill-switch kicks in because OpenVPN is restarting.

May 15 19:25:09 rc.gateway_alarm 98632 >>> Gateway alarm: VPN_WAN_VPNV4 (Addr:REDACTED Alarm:1 RTT:31347ms RTTsd:5964ms Loss:21%) May 15 19:25:09 check_reload_status updating dyndns VPN_WAN_VPNV4 May 15 19:25:09 check_reload_status Restarting ipsec tunnels May 15 19:25:09 check_reload_status Restarting OpenVPN tunnels/interfaces May 15 19:25:09 check_reload_status Reloading filter May 15 19:25:10 php-fpm 243 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use VPN_WAN_VPNV4.

I thought it was a memory issue, I did turn up a few things to push my rig to see what I could get away with but even with things turned down (log retention, number of entries for pfblocker, things like that) it still keeps cycling itself.

I will say I only started having this issue in the past few weeks.  I am only running the pfBlocker package, but I do have some large lists.  I initially thought a cron job was causing a memory issue to make this go down however, I switched the cron jobs to once a day at 2am but still experienced the issue.

Either of you guys have similar setups that can correlate potential causes so we can start to work towards a solution?  Or smarter minds than my own are definitely in this community so I would love to hear back from someone that can tell me where my dumb mistake lies - I will glady wear egg on my face if it means network gains some stability.

Thanks!

From the client:

dig @dns_server_ip_address something.com

Does that work? If not find out why not.

Sorry. Don't know about all that microsoft crap.