Hey, hoping someone can tell me if this is an actual bug or if I'm missing a setting somewhere.
Setup: GL-MT3000, WireGuard client (Mullvad), VPN policy-based routing, "Override DNS Settings for All Clients" on, IPv6 disabled.
I keep getting random dns leaks to my isp instead of mullvad DNS. I found that the DNS goes through: dns_dispatcher -> policy_redirect -> dns_redirect. policy_redirect (which should send vpn marked dns traffic to mullvad's dnsmasq on port 2153) only has a rule for udp:
REDIRECT udp -- mark match 0x1000/0xf000 redir ports 2153
There's no tcp version of that rule? So any dns query that goes out over tcp instead of udp falls through which sends it to the regular dnsmasq instance. I added a matching tcp rule myself and the leak stopped
iptables -t nat -A policy_redirect -p tcp -m mark --mark 0x1000/0xf000 --dport 53 -j REDIRECT --to-ports 2153
Is this a bug in the firmware? or is there a setting I should've been using instead that would've avoided this?
firmware: 4.8.1
Hi
This is because TCP requires a three-way handshake before the actual DNS query is sent. If the nfmark is applied at that stage, subsequent packet matching may differ, which can interfere with establishing the TCP connection.
Therefore, the processing flow for TCP DNS requests is:
[dns-mark]
│ Set ctmark
▼
[dnsmasq main process (--conntrack)]
│ Set nfmark based on ctmark
▼
[dnsmasq output (with nfmark)]
▼
[iptables OUTPUT]
│ REDIRECT (matched by nfmark)
▼
[VPN dnsmasq instance]
Rather than the UDP DNS flow:
[dns-mark]
│ Set nfmark directly
▼
[iptables PREROUTING]
│ REDIRECT (matched by nfmark)
▼
[VPN dnsmasq instance]
Accordingly, the anti-DNS-leak rule is also implemented in the OUTPUT chain:
Coming back to your issue, have you manually updated the dnsmasq version previously?
If so, that would cause our patches to dnsmasq to no longer be applied, which could explain why TCP DNS is not working correctly.
We recommend performing a factory reset and checking whether the issue still occurs.