@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.

Thanks, it worked! I knew it could be something very simple. I was silly assuming OpenVPN Server pushes the default DNS.

So, I have no idea why it worked, but I installed the VPN version of the client, and it started downloading! I guess the container might be a bit buggy? It's double tunnelled now, so the client makes a VPN connection to the VPN network by using the original VPN tunnels. This stuff makes my head spin!

The OpenVPN tab encompasses all OpenVPN traffic. So any rules there are applied to all OpenVPN connections. The tabs for assigned OpenVPN interfaces (StrongVpnMiami here) have rules only for that connection. So if you want to allow traffic in on only one VPN interface you should put rules there and only there. The main OpenVPN tab is parsed first so if you have an allow all rule there rules on the individual connections are not ever hit. That becomes important if you have site-to-site tunnels with incoming traffic. When traffic comes in via a particular connection you need it to hit a rule on the specific tab so it get a 'reply-to' tag on the firewall state allowing the reply traffic to go back via the correct connection. With a VPN connection to a public server like StrongVPN you normally don't want connections coming in over the VPN at all so don't need rules there. The firewall rules in your screenshot above on LAN have some issues. Nothing can ever hit the bottom two rules because all traffic from the LAN subnet will be caught by the 4th rule and sent via WAN_DHCP. No traffic that isn't from the LAN subnet should come in via the LAN (unless you have routed subnets). Steve