3.10.3 - wireguard remote dns neglected

Software SW bugs discussion
1

kmod-wireguard 4.4.138+0.0.20171017-…e-1
luci-proto-wireguard git-18.145.30016-526a876-1
wireguard-tools 0.0.20171017-1

Trying to get the local wg peer (TO router) to utilize the dns resolver of the remote endpoint. To my understanding that should be achieved through

etc/config/network
    config interface 'wg0'
	option dns '172.24.120.10'

However that does not work and the TO router keeps using its local resolver only.

Unless I am mistaken resolv.conf should be updated/added with nameserver 172.24.120.10 but it does not and only contains nameserver 127.0.0.1.

curiously /tmp/resolv.conf.auto reads

# Interface wan
# Interface wg0
nameserver 172.24.120.10
2

My understanding of Omnia’s policy is that it always directs clients to ask Omnia’s IP. Omnia’s resolver then can be configured e.g. to forward to some other IPs (with caching and by default DNSSEC validation).

3

I would expect that you simply protect the IP layer and let DNS go the usual way (over the encrypted IP). Of course, one can certainly set things up in other ways…

4

where is such understanding derived from?

That is not the issue.

There is a difference in expectation then. My expectation is to be at liberty (being my network and TO to facilitate it) to utilize the remote endpoint’s resolver in the wg tunnel as opposed to be limited to utilizing the local resolver routed over the wg tunnel. DNS settings for the WAN iface are honoured so why not for the WG iface?

apparently one cannot as described in the inital post. Similar to WAN iface DNS settings the DNS settings for the WG iface should be honoured too and not be neglected.

5

That’s my feeling from long-term observation :slight_smile: and it makes sense to me to default to that. I’m really concerned with things inside knot-resolver, not much around. Some people certainly have configured Omnia’s DHCP to hand out other IPs for DNS.

6

If there were an (un)offical TO policy of such kind it would be kind of silly to allow dns settings for the WAN iface but not for the tunnel iface, would it not? Thus it seems rather a bug/oversight that the tunnel dns is neglected, perhaps not being parsed.

Apparently it does not to me, else I would not have opened this thread. IMHO TO is there to facilitate but not to tell me how to run things :smirk:

That as it it may be and being their choice or misunderstanding of settings. But perhaps discussed in another thread then.

7

If you directly want to set the local resolver for your TO you can try out this which lets you override the local dns server https://github.com/CZ-NIC/turris-os/pull/69

Also you can set the dns servers that are assigned to the clients via dhcp eg see Local DNS for LAN network

1 Like
8

That is kind of you to offer some potential workarounds but I am afraid not being a solution since it is either the local dns resolver or the remote dns resolver. However the router’s clients are split routed - some via WAN and some via WG and each is to use the respective dns resolver. Which would be a piece of cake if it was not for this bug…

9

Not sure how wireguard works but if it is a separate interface and it uses the default dhcp (dnsmasq) it should be possible to set separate servers for them by setting them different in the dnsmasq config file

10

Sure, dhcp-option=wg0,6,172.24.120.10 should do the trick except it does not. Reckon that such dnsmasq setting does not work on virtual/tunnel interfaces but only physical ones. Afik it does not with openvpn tun either but the dns option is to be set within the openvpn configuration, as it is with wg.

11
12

For it to work it requires “/etc/config/resolver”

config resolver 'common'
	option forward_upstream '1'