still see traffic going out via 53

[robertkwild]

hi all,

enabled DNS over TLS via here

https://www.zenarmor.com/docs/network-security-tutorials/how-to-configure-dot-on-opnsense

getting stuck when i create my own fw rules and nat to stop 53 out

as i have a few fw rules, should i create the block for 53 at the bottom so its first or at the top

thanks,
rob

[RamSense]

Firewall rules are processed from top to bottom, so top

[robertkwild]

thanks RamSense

doing this command on my opnsense

tcpdump -i vtnet0 port 853

should i replace vtnet0 with my lan or wan interface?

thats very wierd i made a floating rule to block 53 and it worked as i couldnt access any websites anymore but when i did a tcpdump on my lan interface on 53 i could see loads of activity so somethings wierd, so it looks like my DoT isnt working

thanks,
rob

[robertkwild]

reading this

In order to provide a secure and verified environment, it is advisable to use a firewall rule to prohibit any outgoing DNS traffic on port 53 when using DNS over TLS. If clients choose to directly query other nameservers on their own, a NAT redirect rule can be used to send these requests to 127.0.0.1:53, which is the local Unbound service. This will ensure that these requests are sent over TLS.

ive done the block rule

   IPv4+6 TCP/UDP    *    *    ! RFC1918     53 (DNS)    *    *       block LAN DNS to internet

but how do i set up the NAT

what do i put in

destination -  any
destination port range - 53
redirect target ip - 127.0.0.1/32 or "this firewall"
redirect target port - 53

thanks,
rob

[robertkwild]

bumping this please as i need help

also I heard encrypting your DNS via DoH or DoT still leaks the SNI to your ISP, is there anyway round this to fully encrypt my DNS via opnsense?

thanks,
rob

[OPNenthu]

also I heard encrypting your DNS via DoH or DoT still leaks the SNI to your ISP

It doesn't leak the content of your query; that's encrypted.  SNI reveals the hostname of the server you connect to.  Your ISP will see that you use, for example, Quad9 or Cloudflare.

They see this anyway.  Your requests have a destination IP.

With DoT I think it's more important to make sure you use the "Verify CN" option so that it's not easy for someone to spoof the server certificate.

[robertkwild]

thanks, can i get some help with how to setup this

NAT redirect rule can be used to send these requests to 127.0.0.1:53, which is the local Unbound service. This will ensure that these requests are sent over TLS.

Thanks,
Rob

[OPNenthu]

Lots of threads about this already, but here goes...

You need one rule to block outbound DNS on port 53 from each of your internal networks.  So for example on your LAN interface, you would put a rule like:

Code Select Expand

Interface: LAN
Quick: <checked>
Action: Reject (or Block)
Version: IPv4+IPv6
Protocol: TCP/UDP
Source: any
Source port: any
Dest: !ThisFirewall (inverted destination)
Dest port: 53

Next, you need a Destination NAT rule (again, one per interface) to redirect requests on port 53 to Unbound.  There are opinions about whether or not to redirect all requests, but IMO it doesn't make sense to redirect ones that are anyway destined for the firewall (Unbound).  So I redirect only the requests to "!ThisFirewall."  If you choose to you can redirect on Dest=any.  You do you.

For IPv4 it's simple, you use 127.0.0.1 as the redirect target:

Code Select Expand

Interface: LAN
Version: IPv4
Protocol: TCP/UDP
Source: any
Dest: !ThisFirewall (inverted destination)
Dest port: 53
Redirect target: 127.0.0.1
Redirect port: 53

Now before you save the NAT rule, there will be an option at the bottom for the type of firewall rule.  What you choose there will determine whether or not you need to create a third rule.  Easiest is to choose "Pass" and then you're done.

For IPv6 it's the same process regarding the NAT rule except you can't use ::1 as the redirect target.  It's not routable, so that needs a work-around.  https://forum.opnsense.org/index.php?topic=51269.msg262743#msg262743

Easiest is to add a VIP to your existing loopback device, something like fdff::1.  Any short, valid ULA will do.  Then you can use that ULA as the redirect target.

Better is to create a dedicated loopback device for redirects and assign it a static ULA in interface settings, then use that.

Hope that helps.