HowTo: Route part of your LAN via TorGuard or PIA.
-
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.
