"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 and redirecting or blocking DoH traffic, assuming redirection even makes sense. 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.
