Firewall rule bug?
-
I have DNS-Resolver (unbound) running DNS over TLS and DNSSEC for localhost and LAN interfaces. Outgoing is VPN and WAN. I do this so that the VPN can access secure DNS during startup. Once startup is complete, I can remove WAN as an outgoing interface and the VPN continues to work. There are no port 853 packets captured on the WAN.
I created a Floating outbound rule to block destination port 853 on WAN (as a test; I will use tagging for conditional removal later). I must disable this rule and restore WAN as an outbound interface for unbound in order to restart the VPN. Once the VPN is running, I can enable the rule.
However, if I look at a packet capture on WAN for port 853 traffic, I find traffic.
If I turn off the VPN and check WAN packet capture for 853 again, there isn't any. Turning the rule back off, restarting the VPN and turning the rule back on results in port 853 WAN traffic.
So, it appears that the rule does not get executed when the VPN is running. Something must exit rule processing before it gets to the Floating rule when the VPN is running.The purpose of this exercise is to keep all DNS traffic invisible to the ISP (except the vpn startup, of course, which is DNS over TLS anyway). The ISP should only see VPN traffic.
Additionally, I still have a DNS leak that seems impossible to eliminate. A separate issue.Any help will be appreciated. Thanks.
-
While I found nothing to address the FW Rule issue above, I did find the solution to the VPN bootup and running problem to stop DNS traffic leaking out the WAN port (at least after bootup). In DNS Resolver (unbound), I set the incoming interfaces to LAN and Localhost. This covers LAN user's and the pfSense system's requests. I set the outgoing interfaces to LAN only. I had to disable all block/reject Floating rules (filtering) to allow pfsense to bootup with VPN autostart, so no Floating rules are required. At first this configuration seemed confusing. When the VPN is not running, LAN traffic naturally transitions to the WAN and then out, so the VPN bootup can occur. When the VPN is running, LAN traffic transitions through the VPN, including DNS over TLS traffic. The only traffic visible on the WAN is VPN traffic (besides ICMP and MAC based traffic). This was confirmed using packet capture on the interfaces. Exactly what I was trying to accomplish.
Now, to try to stop the DNS leak. Dnsleaktest.com is showing the DNS server IP addressed used by Quad9's DNS over TLS with DNSSEC service. -
@wtw said in Firewall rule bug?:
to try to stop the DNS leak. Dnsleaktest.com is showing the DNS server IP addressed used by Quad9's DNS over TLS with DNSSEC service.
Can you give us a little more detail about the problem you're observing? I take it you're running a caching forwarding resolver internally, and using DoT to communicate with Quad9... One of your clients sends a query to your caching forwarder; if it's a cache miss, it gets forwarded to Quad9; if it's a cache miss here as well, that results in a query from one of Quad9's transit or peering interfaces to whoever's authoritative for the domain you're querying... Is that not what you're seeing? Or not what you're intending to do?
-
OK. First, the DNS issue is not what I believe to be the bug in the firewall rules. Second, I believe that I misunderstood the technical definition of a DNS leak. I used dnsleaktest.com, and it returned several consecutive IP addresses, all belonging to WoodyNet. WoodyNet provides DNS service for Quad9 (Quad9 does not have their own DNS database). I use pfSense DNS Resolver (unbound) using DNS over TLS (DoT) with DNSSEC. So the DNS leak test found the DNS provider that was being used (end point service), but there would be no way to track it back to me anymore than the similar resulting DNS leak test done for a VPN service provider usage, where the IP returned is the DNS server/service the VPN provider is using, which does not match the DNS IP you actually make the request to on the VPN service providers servers. This, I believe is basically the same as what you (bwoodcock) are stating.
As long as there is a disassociation in the IP chain, and Quad9 is not keeping records and is conglomerating all DNS requests to the same DNS servers, it is not a DNS leak.
If it is using caching, it does not cache for long. I will check on that.So, is my understanding that this is not a DNS leak correct?
Or does the DNS leak test need to return your exit IP ("who" you are) for there to be a leak?
From what I have read, a true leak is the ability to determine your exit IP (ISP issued IP).
Thanks. -
@wtw said in Firewall rule bug?:
dnsleaktest.com, and it returned several consecutive IP addresses, all belonging to WoodyNet. WoodyNet provides DNS service for Quad9.
WoodyNet is Quad9's primary transit provider, meaning that the IP addresses which Quad9 uses to issue queries to authoritative nameservers are within WoodyNet's allocated IP address blocks. WoodyNet is performing IP routing for Quad9, rather than DNS service for Quad9.
Quad9 does not have their own DNS database
Quad9 is a recursive resolver, while PCH (which is back-to-back with Quad9) is the largest authoritative resolver in the world, and Quad9 has direct interconnections with most of the other large authoritative DNS operators, like Verisign, as well. These are complimentary roles, and the relationship between Quad9 and PCH is as close as any two significant authoritative and recursive networks have ever gotten. None of the other large recursive operators are significant authoritative operators, and none of the other large authoritative operators are significant recursive operators.
So the DNS leak test found the DNS provider that was being used (end point service), but there would be no way to track it back to me anymore than the similar resulting DNS leak test done for a VPN service provider usage.
Sort of. In a perfect world, you'd be right. Unfortunately, people who monetize personal information wind up with a lot of money as a consequence of that badness, and they spend a fair bit of it figuring out clever or heavy-handed ways of getting their hands on more personal information to sell. So, a few things you should watch out for:
Cache-busting. People who are trying to track you will make up completely unique names for things, hand you those unique names, and then watch to see where they see queries for that unique name come back from. Because they're unique, each one will be a cache miss, no matter how long you hold onto it before issuing a query. And they can set the TTL on the answering record to zero, so if you cache the name (like, for instance, by leaving a web page open, and the web page auto-reloads periodically or whenever you return from sleep) they'll still see a new query, from whatever new location you may be at.
EDNS Client Subnet. People who are trying to track you are also now trying to get your identity (your IP address) transitively through your recursive resolver operator. By default, Quad9 does not inform authoritative nameserver operators (and everyone else watching the upstream transaction in the clear) of your IP address, but you should be aware that most recursive resolver operators do, and the most rapacious of the CDN operators unpredictably punish users whose IP address is not included with the query, by giving them slower service, to make it seem as though their recursive resolver is slow, and try to force them to switch to a recursive resolver which discloses their IP address.
I've written in more detail about both of these practices, and how they're used in conjunction to capture users' data.
-
@wtw said in Firewall rule bug?:
From what I have read, a true leak is the ability to determine your exit IP (ISP issued IP).
Not a leak if that is what your doing.. I don't give two shits if the authoritative NS I am asking for their records know my IP.. This comes in real handy when they are serving geoIP based records back.. So I actually get back an IP for something in my region vs half way around the planet ;)
If your concern is "leaking" your IP.. Your leaking it to who your forwarding it too.. So clearly you don't care that they know it ;) So your concern is that the NS for domainX.tld knows that your IP address 1.2.3.4 asked for www.domainX.tld..
-
@johnpoz said in Firewall rule bug?:
I don't give two shits if the authoritative NS I am asking for their records know my IP.
It's a little worse than that... Because ADoT hasn't been implemented yet, the communication between the recursive resolver and the authoritative is in the clear, and many (most?) large authoritatives are aggressively monitored for that reason. So although some of the authoritatives aren't monetizing, it's unlikely that nobody watching them is monetizing, or won't be, at some point in time, adverse to your interests.
-
Yeah it would be in my interests when I move to the woods and live off the grid..
Its a little late to worry about some NS knowing that IP address 1.2.3.4 asked for www.domainX.tld when I use CC to pay for everything. There are camera's everywhere. I carry around a tracking device in my pocket whereever I go.. My car tied to the grid sending its gps location everywhere..
But yeah - I'm real concerned that www.domainX.tld knows that I went to their site and logged in with an account, that is tied to me.. Its a real big concern that they also know what ISP I use /s
I get it - your in the business of securing dns.. But its too little too late.. And a minor concern via all the other tracking that every other site can do via just fingerprinting my machine, etc. etc..
And you can hide your intentions around this promise and that promise - and oh we are looking our for you... But in the big picture, user still ends up sending you everywhere they go - on a silver platter..
Sorry but I trust my connection being in the clear and directly to the authoritative ns for each domain I have interest in.. Vs sending it all to xyz company - because they "say" they are doing me a favor..
Atleast when I hand over my info to a company via a rewards program - I get something ;) Your offering up filtering "bad" shit - so yeah if users want that "reward" they can send you their queries.. And they can do whatever they want - but until its not possible to resolve, I will resolve directly..
-
I didn't realize this was such a hot topic. I appreciate the replies. It appears that I am still very ignorant about DNS. I need to do more research.
johnpoz brought up several other privacy issues, but the issue here is DNS based tracking.
When a DNS request is made, the ISP IP address I use will be sent in the DNS server (for, like johnpoz said, geoIP base results; proximity biased)? Or will it be the VPN IP? Or if I make the request to Quad9 through the VPN, I send my IP to Quad9, else if I use the VPN provided DNS service, they send their IP to the DNS service? This would seem logical.
For geoIP bias, this creates more questions. If I query Quad9 directly, do they send their IP info for geoIP, or the one from the requester?
Either way, I am either trusting Quad9 or the VPN provider with the DNS request info, and I am already trusting the VPN provider just by using their service.
The goal here is to try to make tracking and profiling my internet activities as difficult as practical. I appreciate you insights, but please try to use less "colorful" language. Thanks. -
@bwoodcock said in Firewall rule bug?:
WoodyNet is Quad9's primary transit provider, meaning that the IP addresses which Quad9 uses to issue queries to authoritative nameservers are within WoodyNet's allocated IP address blocks. WoodyNet is performing IP routing for Quad9, rather than DNS service for Quad9.
When I run the DNS leak test, I'm not seeing the same results for WoodyNet. I see a result at the top for Fusion Network as well? I have Unbound configured to forward to Quad9 using DoT.
-
@wtw said in Firewall rule bug?:
If I query Quad9 directly, do they send their IP info for geoIP, or the one from the requester?
That's your choice to make. If you use 9.9.9.9 (and its secondary, and its IPv6 counterparts), Quad9 will send a Quad9 IP address to the authoritative server. When the authoritative server is a CDN that's trying to do DNS tricks rather than anycast for load balancing, that means that you'll be sent to a CDN instance that's near the Quad9 server. If you were using anycast by itself to reach the Quad9 server, that would, in essentially all cases, give you the optimum result. It becomes a little more complicated when you use a VPN... In that case, your query passes through the VPN, and is routed to the Quad9 instance nearest the VPN concentrator (the other end of the VPN tunnel). Generally, that's what you'd want... for instance, if you were trying to stream a TV show that's geo-blocked in your own region, but available in the region of your VPN provider. And, for whatever traffic you're routing through the VPN, you want to be given servers near your VPN endpoint, anyway.
If, on the other hand, you want to send EDNS Client Subnet, you'd send your queries to 9.9.9.11 (and its counterparts) rather than 9.9.9.9. If you weren't using a VPN, we'd then send a /24 generalization of your IP address onward to the authoritative server. If you are using a VPN, we'd send the /24 of the VPN tunnel endpoint. But if you're trying to deal with a really aggressive monetizer, who's punishing you for not disclosing your identity, they're likely to be maintaining lists of Quad9's IP addresses as well as the IP addresses of the VPN operator, and so they'll likely still punish you. On top of the performance hit you take going through the VPN. So there's no magic bullet here, other than just not giving people who think that kind of coercion is reasonable any of your attention to monetize.
Either way, I am either trusting Quad9 or the VPN provider with the DNS request info, and I am already trusting the VPN provider just by using their service.
Again, there's a bit more nuance available to you here, if you want. First of all, your traffic between your endpoint or your caching forwarder and Quad9 should be encrypted as well, using DoT, ideally, which would deny your VPN provider access to it. But your point stands, that they would still then see the destination of your actual subsequent connection, whatever it may be, as it leaves their network, if you're using a single VPN provider. If you use two VPN providers back-to-back, and they're not in collusion, you solve that problem. That's the principle behind TOR. As always, though, intelligence services and criminals know this, and single VPNs generally, and TOR specifically, out for special attention. Using them flags your traffic as being worthy of additional inspection; the more of them you use, the more likely you are to be using a compromised one.
The goal here is to try to make tracking and profiling my internet activities as difficult as practical.
Think of it a little bit like what you do with an old credit card that you want to destroy, or a confidential document that you want to discard... You cut it up into pieces that are as small as practical. You distribute those pieces in as many disparate and unrelated places as possible. And you make sure that in each of those places, there's as much chaff as possible. And you try to select those places to be as uninteresting as possible. The same applies with network traffic. Looking just at the DNS portion of the traffic, running your own recursive resolver for yourself and only yourself is the worst possible thing you can do for your privacy, because it uniquely identifies all of your traffic, it positively distinguishes it from anyone else's traffic, it concentrates it, making it all available for collection in a single place, and it ensures that none of it can be encrypted. On the other hand, if you can run a recursive resolver that serves a significant population of users, and you maintain a large cache, and you enable QNAME minimization, then you're actually doing yourself some good in the sense that you only have to deal with insider threat and compromise, not a monetizer's business-model threat (or, in our case, that there's no skulduggery and that regulators and auditors are doing their jobs); but whether this is good or bad depends completely on the size of the user population behind the cache. The basic proposition of Quad9 is that, for a lot of people, the advantage of their queries being hidden in the chaff of hundreds of millions of other users outweighs their worry that privacy regulators aren't sufficiently auditing us.
-
@pfsvrb said in Firewall rule bug?:
I see a result at the top for Fusion Network as well?
I've just confirmed that they're a legitimate transit provider to Quad9, for the St. Louis, US, location. That means that a test node was near St. Louis, but was not downstream from one of Quad9's peers at the exchange there.
-
Thanks for the info bwoodcock. I guess I'm a bit naive not recognizing that johnpoz was replying to your post and not my issue. While he may be happy with his process, it really has no relationship to my concern in this post.
Second, there is no bug with the firewall rules. That was pilot error (not a surprise) due to my ignorance about the firewall states. Updating the rules is not sufficient, the states need to be reset as well. This is probably standard process when making rule changes. Now I know. The system is working well. It always helps when you know what you're doing. Not that I really qualify here yet, but I am making progress.
I am working on a more concise statement about the DNS process. I will post it when I finnish. If you would be willing to review it for accuracy and reasonable completeness, I would appreciate it. Thanks again.
-
@wtw said in Firewall rule bug?:
I am working on a more concise statement about the DNS process. I will post it when I finnish. If you would be willing to review it for accuracy and reasonable completeness, I would appreciate it.
Always happy to help any way I can.
-
@bwoodcock
Thanks for your help. It seems I believed that this was a bigger issues than it really is. Your assistance is greately appreciated.
This issue is now closed.
