DNS queries only work on the same interface IP, not on others

[meyergru]

I observed the following behavior on my OpnSense router:

I use a "listen_addresses = ['[::]:53']" directive (the same is true for '0.0.0.0:53', I assume the service to listen on all interfaces and all addresses.

The router has two interfaces, say "ix0_vlan10" with 192.168.10.2/24 and "ix0_vlan7" with 192.168.7.1/24 as their interface IP.

When I do a DNS query from a client machine on "ix0_vlan10" by calling "nslookup www.ibm.com 192.168.10.2", it will get answered (as expected).

When I do a query from the same client as "nslookup www.ibm.com 192.168.7.1", the request times out.

I can try the same two DNS requests from a client on interface "ix0_vlan7", and this time the request to 192.168.7.1 will get answered, while the one to 192.168.10.2 will not.

Obviously, on the router itself, both requests get answered immediately.

Mind you: there are no interfering firewall rules in place, of that I am sure!

It seems that dnscrypt-proxy answers only on the interface subnet of the target IP. There is a trick to circumvent this: When I use listen_address = [ '192.168.10.2:53','192.168.7.1:53'], the queries work from both interfaces, regardless of the target.

This behavior is most unwelcome - the potential remedy is problematic, because you have to list all interface addresses explicitely, since a "bind all" to 0.0.0.0 or [::] does not work as one could expect.

Maybe this effect is limited to FreeBSD, where every assigned IP for an interface has a route to lo0 - when you use netstat -nr, you will see something like:

default            82.135.x.y       UGS          pppoe0
82.135.x.y       link#20            UH           pppoe0
93.104.x.y     link#7             UHS             lo0
127.0.0.1          link#7             UH              lo0
192.168.7.0/24     link#16            U         ix0_vlan7
192.168.7.1        link#7             UHS             lo0
192.168.10.0/24    link#12            U        ix0_vlan10
192.168.10.2       link#7             UHS             lo0

[lifenjoiner]

Just to be clear.

Assuming devices:

• A[192.168.10.2, 192.168.7.1]
• B[192.168.10.3]
• C[192.168.7.3]

You say, servers on A:

1. listen_address = [ '[::]:53']
   • On B, 192.168.10.2 works, 192.168.7.1 no answers;
   • On C, 192.168.10.2 no answers, 192.168.7.1 works;
   • On A, both work well.
2. listen_address = [ '192.168.10.2:53','192.168.7.1:53']
   • All work well.

AFAIK, normally networks on different interfaces of the same device are isolated. Case 2 is unusual to me.

Test other servers written in Go and other languages, to see if they work well. We may get more clues.

[meyergru]

Correct. And other servers work fine, of course, say Unbound or DNSmasq. Usually, you do not specify any specific address, which is 0.0.0.0 or ::, depending on protocol, or specific interfaces. Both work for those DNS servers.

FWIW, using "[]" works, too, this results in (just like when specifying all IP:port combinations):

# sockstat 
root     dnscrypt-p 66523 7   udp4   192.168.10.2:53       *:*
root     dnscrypt-p 66523 8   tcp4   192.168.10.2:53       *:*
root     dnscrypt-p 66523 9   udp4   192.168.7.1:53        *:*
root     dnscrypt-p 66523 10  tcp4   192.168.7.1:53        *:*
...

whereas "[::]:53" results in:

# sockstat 
root     dnscrypt-p 43049 7   udp46  *:53                  *:*
root     dnscrypt-p 43049 8   tcp46  *:53                  *:*
...

Which does not work as expected. Unbound, when configured on "ALL" Interfaces, port 53 looks like:

# sockstat 
unbound  unbound    39267 5   udp6   *:53                  *:*
unbound  unbound    39267 6   tcp6   *:53                  *:*
unbound  unbound    39267 7   udp4   *:53                  *:*
unbound  unbound    39267 8   tcp4   *:53                  *:*
...

and works on all IPs on all interfaces.

So, probably, the problem is that IPv4 and IPv6 should be specified separately, but specifying both 0.0.0.0:53 and [::]:53 does not work, as the latter means dual-stack. OpnSense does not let me specify that, nor does it let me use "[]".

"[]" works, but is still not enough, because I cannot set the port with that. At least we would need "[]:port" or, better, that "[::]:port" worked as expected, because "[]:port" is not a valid ip:port specification.

[lifenjoiner]

Also try some servers (DNS, web or proxy) written in Go. Let's make sure if it is an issue of the Go standard lib.

[meyergru]

I tried Caddy. I configured it on port 444 and 80 as a reverse proxy and its socket bindings are:

# sockstat
root     caddy      58073 7   tcp46  *:444                 *:*
root     caddy      58073 8   tcp46  *:80                  *:*

I could connect successfully to port 444 using "openssl s_client -connect 192.168.7.1:444" from B.

[meyergru]

I got a tip from a fellow OpnSense expert: This is probably a problem in the code....

When you access 192.168.10.2 from 192.168.7.3 and have a binding only on 0.0.0.0, then dnscrypt-proxy answers with a source ip of the interface address that it originally received the request from, which in this case is 192.168.7.1.

The client then dismisses the response, because it expects it from 192.168.10.2, whom it originally asked.

This is different with explicit IP bindings, because then the correct sender address can be chosen.

BIND and other servers do this explicitely. Caddy will probably do it correctly, just because the requests were done via TCP and other than with UDP, you have a session with explicit source and destination IPs, there.