HowTo: Route part of your LAN via TorGuard or PIA.
-
Here's a very quick, step-by-step guide that shows how I use pfSense to tunnel a subset of LAN devices via TorGuard. These settings should be virtually identical for PIA. I've attached a .zip file with screenshots. It should be possible to read this post and follow along with the screenshots.
This example was created using a VM with two interfaces; WAN, LAN. Whenever possible I used the default settings. Please note, this configuration prevents clients being routed via the VPN from using the DNS Resolver.
Warnings
- As pointed out by @chebyshev in this reply, IPv6 must be disabled for many of the assumptions in this example to be correct.
Changes
-
v1 - Original
-
v2 - Removed incorrect static port selection on outbound NAT rule.
-
v3 - Switched to nopull routes for the VPN client and created NO_WAN_EGRESS marking / rejection as suggested in this post.
01-setup-wizard
Pick an appropriate time zone. If your WAN is using a private IP, unselect Block RFC1918 Private Networks.
02-adjust-dhcp-range
Adjust the DHCP IP range so it's a bit smaller. I've used 192.168.1.62/26 which gives 62 IPs for DHCP.
03-configure-dns-resolver
The DNS Resolver is only going to be used for pfSense and devices that don't get tunnelled via the VPN.
04-create-vpnclients-alias
Create and alias that can be used to identify devices that are supposed to be tunnelled via the VPN. I use 192.168.1.128/27 for this which gives 30 IPs for devices that need to be tunnelled via the VPN.
05-import-certificate-authority
TorGuard and PIA will provide a certificate authority certificate with their configs. It's usually named ca.crt or something similar. The certificate needs to be imported using pfSense's certificate manager so that it can be used when creating the OpenVPN client. The descriptive name provided while importing can be anything. I've used torguard-ca. Something like pia-ca would also work.
Once the certificate authority is imported, the Distinguished Name section for the certificate should contain details about the certificate.
06-create-openvpn-client
Most of the information needed to configure the client can be found in the .ovpn files provided by TorGuard or PIA. Here's the .ovpn config for the connection set up in this example:
client dev tun proto udp remote gr.torguardvpnaccess.com 443 resolv-retry infinite remote-cert-tls server nobind tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 ca ca.crt auth-user-pass comp-lzo fast-io ping-restart 0 route-delay 2 route-method exe script-security 3 system mute-replay-warnings verb 3
The directives in the .ovpn config are described in the Client Mode section of the OpenVPN manual. If unsure about a setting, look it up.
-
I start with the client disabled. Enabling it without finishing the rest of the config will likely break internet access. Don't forget to go back and enable it once everything else is configured.
-
Use the protocol from the proto directive. Ex: proto udp.
-
Use the host / port from the remote directive. Ex: remote gr.torguardvpnaccess.com 443.
-
Use the device mode from the dev directive. Ex: dev tun.
-
Use WAN for the Interface. This will always be WAN unless you're starting with a dual / multi-WAN configuration.
-
Select Infinity resolve server. This matches the resolv-retry infinite directive. Even if the .ovpn config doesn't include the directive, I would still enable this.
-
Enter your username and password in the authentication section.
-
Disable TLS Authentication. It's not used unless your .ovpn config contains a tls-auth directive.
-
Select the CA that was imported earlier for the Peer Certificate Authority. The list of options should include the descriptive name that was used when importing the CA. Ex: torguard-ca.
-
Select None for the Client Certificate. Some older examples create a dummy certificate for this, but it's no longer necessary.
-
Select BF-CBC for the Encryption algorithm. This is the default. If a different algorithm is needed your .ovpn config will contain a cipher directive. If your .ovpn config doesn't contain a cipher directive, choose the default: BF-CBC.
-
Select SHA1 for the Auth Digest Algoritm. This is the default. If a different algorithm is needed your .ovpn config will contain an auth directive. If your .ovpn config doesn't contain an auth directive, choose the default: SHA1.
-
Select Enable with Adaptive Compression for Compression. This matches the comp-lzo directive. Adaptive compression is the default type of compression used with comp-lzo. If adaptive compression wasn't supported the .ovpn config would contain a comp-noadapt directive.
-
Check the option for Don't pull routes. This will prevent pfSense from accepting any routes that may be pushed by the server. The main thing this accomplishes is ensuring the default route isn't updated to use the VPN gateway. Note that when using this option care needs to be taken to make sure traffic from vpnclients isn't accidentally allowed to egress via the WAN.
-
Select Don't forward IPv6 traffic for Disable IPv6. The server probably isn't going to push any IPv6 routes, so this likely doesn't matter. I disable it anyway.
I've added the remote-cert-tls directive to the advanced configuration:
remote-cert-tls server
This ensures the certificate used by the server has TLS Web Server Authentication extended key usage which means that client certificates issued using the imported certificate authority aren't considered valid when checking the identity of the server. Omitting this directive will cause a warning to be logged:
WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
I've also added 3 MTU related directives to the advanced configuration:
tun-mtu 1500 tun-mtu-extra 32 mssfix 1450
These are taken directly from the .ovpn config. If these settings are needed, but omitted, warnings similar to the following will show up in the logs:
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574' WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
07-configure-vpn-client-interface
Once the OpenVPN client interface is assigned, it'll be possible to use it as a gateway by modifying the outbound NAT rules. Assign the newly created client interface and enable it. I like to change the name to something more descriptive. I've used TORGUARD as the interface name in this example.
08-configure-outbound-nat
There's a new(ish) hybrid mode for outbound NAT which makes this pretty easy. Add the two rules shown in the screenshots and then set the Mode to Hybrid Outbound NAT. I use the entire LAN subnet as the source address for these entries, but it could also be limited to the network block chosen for vpnclients (192.168.1.128/27). I use the entire LAN subnet so I don't have to worry about updating outbound NAT rules if I want to change the vpnclients alias.
09-create-lan-firewall-rules
Add a rule to block vpnclients from making DNS queries to the LAN IP. This prevents vpnclients from using the DNS Resolver and prevents DNS leaks if you forget to override DNS settings when adding static DHCP mappings for vpnclients.
Add a rule that creates a policy based route for vpnclients. Traffic that matches the rule will be sent via the VPN (ex:TORGUARD) gateway. Traffic that doesn't match will fall through to the default LAN rule.
-
Don't forget to select the VPN gateway (ex: TORGUARD_VPNV4) in the Advanced features section. This is what causes traffic from vpnclients devices to be tunnelled via the VPN.
-
Don't forget to set the Advanced Option to mark matching packets with NO_WAN_EGRESS. This is extremely important because when the VPN interface is down pfSense deletes the gateway from the rule which will cause the traffic to be routed via the routing table (aka out the default route which is the WAN). There also must be a matching floating rule to reject the marked traffic (see below). A good explanation of what happens can be found here.
10-create-floating-firewall-rules
Create a floating rule that watches for and rejects outbound WAN traffic that's marked NO_WAN_EGRESS. This prevents vpnclients from connecting to the internet via the WAN when the VPN interface goes down.
11-add-static-dhcp-mapping
Add static DHCP mappings for any devices that you want using the VPN. Assign them an IP from the 192.168.1.128/27 block and override the DNS settings to use public servers (ex: Google or OpenDNS). All traffic for vpnclients is routed via the VPN which will include queries to public DNS servers.
Don't forget to enable the VPN client if you started with it disabled.
12-verify
Once a device has been assigned an IP from the vpnclients IP range, visit an IP lookup and DNS leak test site to verify everything is working as expected.
tg-pfsense-howto-v3.zip -
Excellent guide! Thank you for making the time and effort to put this together!
-
Great how-to guide. A couple of suggestions for additional information.
Using Squid Proxy with the VPN
A common issue that I've seen a lot of people posting is not understanding how the squid proxy works with a VPN. Policy based routing won't work with firewall rules if clients are using the squid proxy or the transparent proxy is enabled as the traffic will originate from pfSense rather than the internal networks.This can be overcome with some limitations by using custom ACLs in squid as I've described at /index.php?topic=106221.msg592358#msg592358. I believe if you specify the client IPs under the Bypass Proxy for These Source IPs when the transparent proxy is configured then it will also work without a custom ACL, but not if the client is configured to use the proxy.
You can also do other things with custom ACLs, such as sending specific destination domains via the VPN. For example certain websites could be blocked by your ISP on the WAN interface, so you want all traffic for those to go via the VPN. A few examples are described at /index.php?topic=104628.msg583327#msg583327
VPN Client DNS
You've suggested creating a firewall rule to block VPN clients on the subnet from using your local DNS. Is it possible with bind to create an ACL for the local VPN clients and then specify the PIA or TORGUARD VPN servers as forwarders for these clients? All other local clients would still use the default settings in bind. This way you wouldn't need to configure the external DNS server individually for each of you local VPN clients. You'd probably still want a firewall rule to block any outbound DNS requests from those clients to prevent leakage (although the packet matching floating rules would probably prevent this anyway). I don't use bind, but from what I've seen in various guides this could be possible. Not sure how this would be configured through the GUI. I don't know how DNS caching would work if there was a conflicting result between what your WAN DNS servers return and what your VPN server returns. -
In step 3, for outgoing network interfaces, your have selected only WAN. When I try to replicate that step on my system, I receive the following error message: "This system is configured to use the DNS Resolver as its DNS server, so Localhost or All must be selected in Network Interfaces."
How were you able to avoid getting that error?
Edit: I was able to fix this by choosing localhost for "network interfaces" and de-selcting localhost for "outgoing network interfaces"
-
This is an excellent guide! and @kesawi , your comment is also an excellent addition.
edit:
Hi @kesawi
I was able to follow your instruction to get this to work using "Custom Options" under squid. However, it seems that I can only access https:// websites, not http:// sites. Any idea to fix this?
Thanks
-
Thanks for this.. I use TorGuard and had to figure this out before you posted your guide. I have a few differences I'd like to discuss..
1. Your guide mentions how to configure the connection using the main UI but you show the actual advanced settings some of which map to what's in the UI. For consistency, I recommend ensuring options are either in the UI or in advanced settings to avoid forgetting an advanced setting that's set and wondering why a UI setting is not working. My preference is to keep as many settings in the advanced section as possible so that if I create more VPN connections, I can just cut and paste the block.
2. From the original TorGuard ovpn files, there are a few parameters I don't see you mention..
a. persist-tun
b. persist-key
c. float
d. mute-replay-warningsWhat are your thoughts on including these?
3. You have different settings for
a. resolve-retry
b. route-delay4. You include auth-user-pass and although so does the original config, I think this should be taken out as it requires credential input somewhere, either in a file or in the GUI. Since we use GUI, i'm pretty sure this is automatically sent by pfSense.
What are your thoughts on the original values?
5. I further minimized logging by setting
a. mute-replay-warnings
b. verb 1 - because the UI doesn't seem to have that option available in the dropdown.6. I minimized warnings by setting
a. remote-cert-tls server as you suggested
b. route-noexec instead of route-nopull as it generated more warnings that way and I think has the same ultimate effect.
c. adding auth-nocache7. Stabilized connectivity by
a. not specifying a ping-restart and thus defaulting to 120s. This is in case traffic stops flowing but the vpn stays connected.
b. adding auth-retry nointeract because sometimes during a reconnection a BAD AUTH appeared at which point retries stopped. This solved that problem.
c. When you configure more than one connection to TorGuard to different regions, ie 1 connection to US, 1 to Canada, the internal IPs they assign on each server can actually match! at which point pfSense gets confused and traffic stops flowing on one. Virtual IP will show ie 10.9.0.25 for both connections. To solve this I wrote a script that looks for vpn connections and their Virtual IPs and if duplicates are detected, it asks all but the first connection to cycle. This check happens on say a 1 minute interval. https://forum.pfsense.org/index.php?topic=79900.msg439018#msg439018 -
I've never tried to set up a proxy that routes via the VPN, so I don't have an opinion on anything proxy related.
As for DNS, the way I did it is simple and fails closed if you forget to set external DNS servers.
I don't think the packet matching floating rule would catch a mishandled DNS lookup. Wouldn't mishandled DNS requests appear to be new connections originating from localhost? When I say mishandled I mean as a result of misconfiguration, not pfSense misbehaving.
1. I don't see any duplicate advanced settings. I only have 4 settings in the advanced config. I noted all 4 in section 6. Cutting and pasting most of a config into the advanced section would probably work ok.
2. Only the mute-replay-warnings option is in the original config I show. IMO, it's better for someone to see a bit of spam in their logs and be forced to research how to squelch it than it is for them to not realized information that could be important is already squelched.
Glancing at the man page (I haven't tested these, so there's a bit of assumption), I wouldn't use any of them:
- persist-tun sounds like it lets the process restart without re-configuring the interface. If I restart the process, it usually means I want a new tunnel.
- persist-key shouldn't matter since the openvpn client process runs as root (ps -aux | grep openvpn).
- float likely doesn't matter with something like TorGuard. I doubt they're using dynamic IPs. Even if they are, I don't care if my connection breaks and has to reconnect as long as no traffic leaks.
3. I explained resolve-retry in the bullet point list in section 6. The OpenVPN manual only notes route-delay as being useful for tap interfaces. AFAIK most (all?) VPN providers are using tun interfaces.
4. I let the GUI handle user-auth-pass. Where do you see it duplicated?
5. I like verbose logs.
6. I don't think route-noexec and route-nopull are the same. I haven't tested it, but, reading the man page, to me it sounds like route-noexec affects how routes pushed by the server are set and route-nopull affects if routes pushed by the server are set (or ignored). Put another way, if you set route-nopull then route-noexec has no effect. I mention setting route-nopull by using the Don't pull routes in section 6.
7. I don't include ping-restart in the config. Using auth-retry nointeract sounds useful. I only use 1 VPN connection.
-
I used this tutorial and everything worked great, except dnsleaktest.com still shows my ISP instead of Choopa.com (which is PIA's DNS).
Where should I start to diagnose this?
-
The key might be in section (above) - "Add a rule to block vpnclients from making DNS queries to the LAN IP. This prevents vpnclients from using the DNS Resolver and prevents DNS leaks if you forget to override DNS settings when adding static DHCP mappings for vpnclients."
Has this rule been set up?
-
Yes, I set up that rule.
-
Is your client Windows 8 or up?
Then it could be this:
https://forum.pfsense.org/index.php?topic=110910.msg617899#msg617899 -
I just tried that, but got the following in my OpenVPN log:
May 6 20:54:13 openvpn 84233 SIGTERM[hard,] received, process exiting May 6 20:54:13 openvpn 30195 Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn/client2.conf:31: block-outside-dns (2.3.9) May 6 20:54:13 openvpn 30195 Use --help for more information.
This seems weird to me because the documentation for OpenVPN 2.3.9 seems to indicate that the –block-outside-dns option is available.
-
I just tried that, but got the following in my OpenVPN log:
May 6 20:54:13 openvpn 84233 SIGTERM[hard,] received, process exiting May 6 20:54:13 openvpn 30195 Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn/client2.conf:31: block-outside-dns (2.3.9) May 6 20:54:13 openvpn 30195 Use --help for more information.
This seems weird to me because the documentation for OpenVPN 2.3.9 seems to indicate that the –block-outside-dns option is available.
I had to use "push block-outside-dns" which someone recommended. not sure if that is actually working or not. don't see anything in the log.
I am still having the issue where any of the leaktest sites are showing my DNS server as my IP from the ISP (not my ISPs DNS servers)
I have done all the different rules for blocking DNS and forcing certain servers. It just seems like it was working at first and now it always displays the ISP IP even when connected to VPN
I am using DNS Resolver (no forwarding and no DNS servers configured on general setup…using 127.0.0.1)
-
The "push block-outside-dns" seems to allow the client to start at least, but it didn't change anything in terms of the leak tests. You're right - they are showing my IP, not my ISP's DNS server. Strange and pretty much the opposite of what I'm looking for out of a VPN.
-
@chebyshev On the host you are performing DNS leak tests what are the configured name servers? Precisely what firewall rules did you create (screen shot would be best).
-
The host doing the leak tests gets a static IP assigned via DHCP from the pfSense box - it is assigned the Google DNS servers (8.8.8.8 and 8.8.4.4). Those are the ones that show up if I do 'ipconfig /all'. It is running Windows 10.
Screenshots of my firewall rules are attached.
-
Do you have name servers set up in System > General Setup?? What are they?
-
I just tried that, but got the following in my OpenVPN log:
May 6 20:54:13 openvpn 84233 SIGTERM[hard,] received, process exiting May 6 20:54:13 openvpn 30195 Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn/client2.conf:31: block-outside-dns (2.3.9) May 6 20:54:13 openvpn 30195 Use --help for more information.
This seems weird to me because the documentation for OpenVPN 2.3.9 seems to indicate that the –block-outside-dns option is available.
I had to use "push block-outside-dns" which someone recommended. not sure if that is actually working or not. don't see anything in the log.
I am still having the issue where any of the leaktest sites are showing my DNS server as my IP from the ISP (not my ISPs DNS servers)
I have done all the different rules for blocking DNS and forcing certain servers. It just seems like it was working at first and now it always displays the ISP IP even when connected to VPN
I am using DNS Resolver (no forwarding and no DNS servers configured on general setup…using 127.0.0.1)
Here is my config at the moment…I have the DNS related rules disabled until I figure out the situation
-
Don't know why you have all those rules duplicated. Only the first match is going to have any effect.
-
Don't know why you have all those rules duplicated. Only the first match is going to have any effect.
some of those are due to it being 2 separate images that i should have done a better job of editing before posting :)
the others are due to being autocreated and manually created. duplicates remain disabled and were left in place only for testing -
Do you have name servers set up in System > General Setup?? What are they?
I have the Google DNS servers in there: 8.8.8.8 and 8.8.4.4.
-
I think that might be the problem. Manually set your DNS server on that host to just 4.2.2.2 and run your DNS leak test again.
-
Tried that - same result.
-
And what result is that?
-
Sorry - my IP is showing up in the DNS leak test results.
-
Hmm. When I set mine to use google for DNS all dnsleaktest.com sees is google.
You positive you're working from a host that has all traffic forwarded to the VPN?
You sure that host has google and only google set as its DNS servers?
-
I'm pretty sure on all counts. Is there a DNS leak test site I can use that doesn't require a browser? Like how I can just wget ipecho.net/plain. That way I could test it on my headless clients that are supposedly behind the VPN.
The only thing I wonder about is if IPV6 is somehow leaking my IPV4 info, but I don't know enough about IPV6 to know if that is possible.
-
Update!
It was in fact IPV6 somehow leaking IPV4 information. I turned off IPV6 in Interfaces/WAN and now all that shows up is Google's DNS information in the leak tests.
So on to the next question: am I losing anything by not having IPV6 enabled and if so, how can I prevent the leak with it enabled?
-
After debugging, upon creating the floating rule matching the tag NO_WAN_EGRESS, my wan gateway goes offline or appears to be fully offline.
Why would this be so?
Is the alternative shown at the bottom of the single post at https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN a viable alternative?
My setup is as this article defines, allocating only a portion(s) of subnets to vpn clients. Otherwise, my setup is identical to the steps listed here and I intend to match this guide.
-
It's something else. Traffic sourced from the firewall (dpinger gateway monitoring) will not be matched by the rule that marks traffic with the NO_WAN_EGRESS tag.
-
It's something else. Traffic sourced from the firewall (dpinger gateway monitoring) will not be matched by the rule that marks traffic with the NO_WAN_EGRESS tag.
When I disable just that rule I get most of what the guide is set out to do to work. I'm guessing you can't have both this floating rule and the advanced setting to Skip rules when gateway is down (the alternative I mentioned in Advanced -> Misc -> Gateway Monitoring) to be active at the same time.
I'm also surprised that it was by disabling only this floating rule that my router goes back to having a stable WAN gateway connection.
Any ideas on where to look or what to check for?
Also, each of the openvpn client gateways I defined show offline in Gateway status but are active in OpenVPN status and are actually working. Does this help and could this mean that the gateway monitoring service has something interfering?
-
The rules and that checkbox can coexist I just don't know why you'd want to. I hate to do it but instead of saying the rules are the same how about showing us what you actually have.
Any packages (snort/squid) involved?
-
General audience:
After resolving my previous issue I am now unable to get through with the BLOCK dns port 53 rule hierarchically ordered above the pass rules in the firewall rules. I have been checking every detail and now I have a new question.
My router general DNS servers have both google public dns and another dns outside of my ISP's dns. Because of this, I did not specifically add DNS settings (to the same criteria) per static mapping.
I'm not sure why when the OpenVPN clients use WAN so to work with blocking LAN requests from those client's assigned IP/range, yet it still prevents connection so somehow these OpenVPN clients are still using the LAN interface and the block is preventing successful connections.
Derelict:
The new pfsense interface had me put the tagged in tag instead, because I was going by the screen shots and now the web front end is slightly different with labels. So the floating rule is fixed.
-
Here is my config at the moment…I have the DNS related rules disabled until I figure out the situation
I would avoid using the port forward rules that you have for DNS. I tried that once and my current opinion is that it adds unnecessary complexity. You have two port forward rules:
Iface Protocol Src Address Src Ports Dest Address Dest Ports NAT IP NAT Ports LAN TCP/UDP IPVanish_Hosts 53 (DNS) !IPVanish_DNS 53 (DNS) 198.18.0.1 53 (DNS) LAN TCP/UDP * * !LAN address 53 (DNS) 127.0.0.1 53 (DNS)
What happens when one of your IPVanish_Hosts makes a DNS query to 8.8.8.8? I haven't tested it, but I'm pretty sure:
-
The first rule doesn't match.
-
The second rule does match and rewrites the addresses for the traffic. I think the destination IP will be re-written to 127.0.0.1.
-
You have a (disabled) firewall rule that allows any traffic destined for 127.0.0.1 on port 53, so the traffic is allowed to hit the local DNS Resolver. It looks like the rule is linked to (auto-added by) the second port forward rule.
-
The DNS Resolver is using the WAN, so the request exits via the WAN.
-
The traffic was allowed before it made it to the LAN rule that tags it NO_WAN_EGRESS, so the floating rule has no effect.
Port forwarding / NAT makes it much more difficult to reason about the firewall rules because you have to understand when NAT occurs in relation to the firewall rules and also how the source and / or destination addresses get re-written.
-
-
My router general DNS servers have both google public dns and another dns outside of my ISP's dns. Because of this, I did not specifically add DNS settings (to the same criteria) per static mapping.
If you don't assign alternate DNS servers in the static mapping, the default will be the LAN IP. That traffic will get blocked by the rule you mentioned. That's what it's supposed to do.
Having (ex:) Google public DNS set under general won't cause your LAN devices to make queries directly to those servers. Instead, your LAN devices query the DNS Resolver and the DNS Resolver might use the servers listed under general to make upstream queries. I say might because the way it behaves is configurable in the DNS Resolver (DNS forwarding). Regardless, all traffic from the DNS Resolver routes via the WAN.
For DNS queries to be routed correctly, LAN devices must make queries directly to a DNS server that's not local. The simplest thing to do is override DNS to use Google's public DNS when creating static mappings for your vpnclients.
-
I have a question that I think is at least similar to this thread, but if I am incorrect, please direct me to any information.
I have succesfully set up a PIA VPN Gateway and can turn on the openVPN client to protect my entire network through my pfsense box. It is awesome to have everything protected for all of our devices. However, I notice that some https sites don't like being access through a VPN (like bank of america). I am wondering the best way to allow for these exceptions through the firewall.
-
Use firewall rules to block outgoing SSL (port 443) traffic from the VPN gateway, forcing that https (443) traffic to the WAN?
-
Use Squid/proxy to force all non-https traffic to the VPN and all https traffic to the WAN?
-
URL filtering to allow certain urls to use WAN gateway instead of VPN?
-
Other ideas?
Any advice, input would be helpful.
-
-
@violinjjb I wouldn't mix traffic like that and, personally, I wouldn't access my bank account via one of these VPNs. There's no benefit to it. As it is, the connection between you and your bank is already private (it's encrypted). The only thing your ISP is seeing is that you're going to the BoA site. They can guess you're a BoA customer, but that's probably not a big secret anyway.
If you mix VPN and non-VPN traffic on the same machine, there's going to be a lot of correlation that can be done. I keep my VPN activity isolated in a VM (virtual machine).
-
Update!
It was in fact IPV6 somehow leaking IPV4 information. I turned off IPV6 in Interfaces/WAN and now all that shows up is Google's DNS information in the leak tests.
So on to the next question: am I losing anything by not having IPV6 enabled and if so, how can I prevent the leak with it enabled?
I need help, followed the guide with PIA in mind, everything works great (I think) until I disable IPV6 on WAN. What follows is internet access goes down on all my hosts (connectivity to http, etc yet the status all say the internet is fine). Strange things is I can ping 8.8.8.8 from inside pfSense as well as from command line on all my hosts with no issues but nothing works in browsers. Anyone else have this issue? Any help would be greatly appreciated!
-
Bumping this up….
Followed the guide to a T with PIA and it works fine if I set the "Don't auto add/remove routes" to unchecked. Problem is, the rest of the LAN now doesn't get any joy going out with regards to DNS.
Not sure at all what is going on with just that. If I do check that box, my LAN works but my IP address leaks on clients behind the VPN.
-
Policy routing is your friend.