"Floating" NAT rules?
-
I have a set of four NAT rules to redirect IPv4 and IPv6 DNS and DoT requests arriving on a pfSense interface to the pfSense itself. I'd like to have corresponding NAT rules on additional interfaces. Is there something akin to a "floating" NAT rule that would apply to multiple interfaces, or do I need to explicitly add the rules to each additional interface? Thanks.
[Looking at these rules, I now wonder whether the NATed DoT requests would ever succeed since the hostname in the server cert wouldn't match the client's requested DNS server hostname ... but the question about floating NAT rules stills stands.]
-
@marcg said in "Floating" NAT rules?:
Is there something akin to a "floating" NAT rule that would apply to multiple interfaces, or do I need to explicitly add the rules to each additional interface?
You would create an Interface Group with all the interfaces you want and create the NAT rules for that group.
-
@Bob-Dig said in "Floating" NAT rules?:
You would create an Interface Group with all the interfaces you want and create the NAT rules for that group.
That worked ... thanks! The only changes required to the NAT rules were to replace the interface name with the interface group name, and the destination "![interface name]" with "!self".
Have only done the DNS rules so far, still trying to decide whether NATing DoT is sensible.
-
@marcg said in "Floating" NAT rules?:
still trying to decide whether NATing DoT is sensible.
I don't think so, but at least you could block it.
-
@marcg said in "Floating" NAT rules?:
still trying to decide whether NATing DoT is sensible
You want to redirect dot to pfsense and have it answer vs what specific dot server some device is wanting to talk to directly?
While in theory its possible - but here is the big problem in doing it. A sane dot client would be validating the cert the dot server hands it.. So unless you can get the client to trust a CA you sign the cert with your unbound running dot would use - the client shouldn't accept any answer from your redirection. Because either CN/SAN isn't correct, ie dot.domain.tld its wanting to talk too. Or even if you created a cert with that san or cn on it - it wouldn't trust your CA that signed that cert..
One of selling points of doh and dot are that the client should validate who its talking to via the cert used.. Any client that doesn't do this is pretty shitty doh/dot client.
-
@johnpoz said in "Floating" NAT rules?:
@marcg said in "Floating" NAT rules?:
still trying to decide whether NATing DoT is sensible
You want to redirect dot to pfsense and have it answer vs what specific dot server some device is wanting to talk to directly?
Thanks. That was the idea, but I decided it wasn't sensible for the reason that you provided.
There are definitely hosts on my network -- generally IoT devices -- with hardwired non-DoT DNS servers. The port 53 redirect fixes that. There may not be any with hardwired DoT servers. I can check to see whether there are. If so, looks like I'll need to accept that for the reasons discussed (or get rid of those devices if it's somehow objectionable).
-
@marcg I think dot would be rare, dot is more for like a ns to another nameserver. Doh would be the thing most devices would use. There might be some out there that do you dot, if that was there was they would be simple to block - just port 853.. Doh is much harder because it uses 443 and just hides in all your other 443 traffic.
You can have unbound answer on doh as well as dot.. But again you run into the same problem with some sane client should actually validate that cert.
I setup unbound to listen and answer via doh - but I just did it for an exercise in can you do it. Its only real use if you ask me is to make a warning go away on say your phone or something.
-
@johnpoz Yep. There's also the challenge of reliably identifying DoH traffic. I'm not running DPI, and relying on a canned list of DoH servers for identification feels fragile.
Mine is a residential network. I run standard port 53 DNS internally and unbound DoT for external resolution, mostly for privacy reasons. If there are clients on the network using DoT or DoH, I guess some privacy objective is still met ... but probably not mine :) Devices like that are (likely) on untrusted VLANs though.
-
@marcg not all that simple identifying stuff inside a ssl/tls connection. Even if running dpi
Really the only way to stop doh realistically currently is list of ips serving it, and block those.
Until such time that esni (long live ech) you might be able to look at the sni sent and block on that? Or use some sort of method to determine its a doh server. But since esni never took off, who says its replacement will, etc.
While sure there are some valid use cases for dot or doh, hiding your traffic from your isp really isn't one of them - since they can see in the sni what domain your going to.. And even with ech/esni they would still know the IP your going to - so the whole selling point of privacy from your isp is a bunch of smoke if you ask me to get you to send your dns to these services..
-
@johnpoz said in "Floating" NAT rules?:
@marcg not all that simple identifying stuff inside a ssl/tls connection. Even if running dpi
<snip>
While sure there are some valid use cases for dot or doh, hiding your traffic from your isp really isn't one of them - since they can see in the sni what domain your going to.. And even with ech/esni they would still know the IP your going to - so the whole selling point of privacy from your isp is a bunch of smoke if you ask me to get you to send your dns to these services..@johnpoz agreed on sniffing inside SSL/TLS. I know there are MITM proxies that enable this, but have no plans to deploy one in my home network.
On the privacy thing, I should have been more specific. Agree that my ISP sees all of my traffic anyways and also agree that the privacy claims for residential VPNs -- NordVPN, et al -- are snake oil in many scenarios. I don't run one (I do run inbound VPNs).
That said, my ISP, ATT, has an opt-out feature called DNS Error Assist (screenshot below) which seems to be a clear statement that they're mining DNS requests and manipulating responses. This was the privacy issue, which was addressed by using third party DNS servers and adding DoT. Not a complete privacy fix to be sure.
-
@marcg I agree manipulation of any dns should be opt in for sure.. If I want you to filter stuff, or help with my typo's etc.. I would point to the IP specifically that you offer those services up on.
If you offer such service, I should be able to point to any other dns I wan't and your not going to mess with the traffic - shouldn't have to opt-out if not pointing to your dns that is for damn sure.
Default opt-in is rarely a good thing for anything.. No matter what services they are providing - the user should have to opt-in in some way if you ask me.
One of the pet peeves I have with doh - many of these browsers like to turn it on by default, which is not the way to go about it.. If its so good inform the users and they will enable it if they want too. If you turn it on by default - tells me its not so good of a thing.. Seems like to me your trying to sneak it in under the radar.
