SmartDNS: Starts before wireguard tunnels - DNS over VPN refused

[TCB13]

Package Name

smartdns

Maintainer

@pymumu

OpenWrt Version

All

OpenWrt Target/Subtarget

All

Steps to Reproduce

1. Setup a Wireguard tunnel (named vpn)
2. Setup smartdns in port 53 (main server, no dnsmasq proxy) and bind it to the tunnel interface as well
3. Reboot the router
4. On a tunnel peer try to run a DNS query using the smartdns as server

root@Swift:~# cat /etc/config/smartdns

config smartdns
        option enabled '1'
        option server_name 'swift'
        option port '53'  <--- important, not set as dnsmasq upstream proxy
        option auto_set_dnsmasq '1'
        option tcp_server '1'
        option ipv6_server '1'
        option bind_device '1'
        option dualstack_ip_selection '1'
        option serve_expired '1'
        option cache_persist '1'
        option resolve_local_hostnames '1'
        option force_https_soa '1'
        option rr_ttl_min '60'
        option seconddns_port '6553'
        option seconddns_tcp_server '1'
        option bind_device_name 'br-lan,vpn' <--- bound to the br-lan and also the wireguard interface
        option old_port '53'
        option old_enabled '1'
        option old_auto_set_dnsmasq '1'
(...)

Actual Behaviour

SmartDNS replied from the LAN but not to wireguard peers.

• Lan machine test => works fine.
• Now a remote peer on the VPN, sometimes it works, others I get "connection refused".

Looks to me like there's some timing issue around wireguard and smartdns where smartdns starts before the tunnel is working properly and never binds to the tunnel IP.

Thank you.

Confirmation Checklist

• The package is maintained in this repository.
• I understand that issues related to the base OpenWrt repository or LuCI repository will be closed.
• I am reporting an issue for OpenWrt, not an unsupported fork.

[egc112]

Usually DNS servers start very early to resolve e.g. NTP or URL's used in the WG client so that is the desired behaviour.

Not binding to an interface which is not present is another story.

As a test , why not bind devices at all. e.g. you listen on all interfaces by default and see if that helps.

Other workaround just restart SmartDNS

[TCB13]

or URL's used in the WG client so that is the desired behaviour.

What URL since the router acts as the "server" - even though WG doesn't have sides - there's no URL to resolve.

The endpoint address is optional either way:

[egc112]

In case WireGuard is used as a client of course :)

[TCB13]

In case WireGuard is used as a client of course :)

Yeah, but in this case I'm using it as a server and seeing that behavior sometimes. It's hard to tell that binding to all interfaces would work because I would have to be running it on that state for days to confirm. Even with a firewall rule dropping port 53 on WAN not sure if I'm comfortable with that. Thanks.

[egc112]

The firewall will not allow traffic coming in from the wan.
For DNSMasq it is the default behaviour.
About WireGuard , there is actually no distinction between a "server" and a "client", WireGuard is a point-to-point connection and can be both even at the same time :)

Either file a bug report at SmartDNs or make a hotplug script to restart SmartDNS after the WireGuard interface is up

[TCB13]

Either file a bug report at SmartDNs or make a hotplug script to restart SmartDNS after the WireGuard interface is up

That's what I've been doing, a 10s sleep seems to fix the problem. However there's likely a bug somewhere in the openwrt version of smartdns.