On my GL-AXT1800 (Version: 4.8.2. Firmware Type: release5) I have configured Tailscale to use an exit node on my LAN when working remotely. To allow both intranet and internet traffic I had to check the Masquerading for the tailscale0 zone using LUCI. Using an SSH connection I manually entered tailscale set --accept-dns=true, it was false, however the DNS provided by the tethered device is still used, the only way I could use the DNS on the LAN was to use the Manual setting on the GUI DNS page and enter its IP address explicitly.
The consequence of the above is that if the tailscale does not connect, say because the public wifi uses a portal page DNS requests cannot be resolved, if I add a secondary public DNS server to the manual list there is a possibility of DNS leaks occurring when connected via tailscale.
I think that there is an issue with the implementation of tailscale which means that DNS requests are not exclusively sent to the tailscale interface when tailscale is enabled.
It is possible to configure the firewall rules manually to correctly direct DNS requests to the tailscale DNS server but this has to be manually reverted if tailscale is not in use.
By default, only domain names ending with ts.net are routed to Tailscale’s DNS.
This design ensures that all other DNS queries continue to use the DNS servers configured in DNS / AdGuard Home.
If you prefer to use the DNS servers provided by Tailscale instead, you can manually modify the relevant section in /usr/bin/gl_tailscale.
modify_dns_resolv()
{
dns_suffix=$(timeout 2 tailscale status -json | jsonfilter -e '@.MagicDNSSuffix')
rule_exist=$(grep "ts.net/100.100.100.100" /etc/dnsmasq.conf)
domain_orig=$(uci get dhcp.@dnsmasq[0].domain)
domain_orig_clean=$(echo "$domain_orig" | sed "s/.*ts.net //g")
if [ "$1" = "1" ]; then
if [ "$rule_exist" = "" ]; then
[ "$dns_suffix" = "" ] && dns_suffix="ts.net"
echo "server=/$dns_suffix/100.100.100.100" >> /etc/dnsmasq.conf
uci set dhcp.@dnsmasq[0].domain="$dns_suffix $domain_orig_clean"
uci commit dhcp
/etc/init.d/dnsmasq restart
fi
else
uci set dhcp.@dnsmasq[0].domain="$domain_orig_clean"
uci commit dhcp
if [ -n "$rule_exist" ]; then
sed -i '/ts\.net\/100\.100\.100\.100/d' /etc/dnsmasq.conf
/etc/init.d/dnsmasq restart
fi
fi
}
Thank you for this, to confirm, the modification required will route all DNS queries via the secured tailscale tunnel to the remote exit node. I believe the above code only routes DNS queries for .ts.net to tailscale MagicDNS, I want to ensure that if tailscale –accept-dns=true then DNS requests are sent so the remote LAN, ie LAN (GL-AXT1800) → Routers DNS Resolver (tailscale enforced) → Tunnel → Remote LAN DNS resolver, the “Remote LAN DNS resolver” being specified in the DNS page of the tailscale.com admin console.
At this time, the feature is not supported.
The part we attached is the portion of the script that handles DNS modification, which you may adjust as needed.
We also discussed this with the development team.
Currently, it seems that Tailscale CLI does not provide a stable interface for retrieving DNS configuration details from the Tailscale Admin Console.
For example, DNS settings configured in the Admin Console:
The use of Tailscale via the GL-inet GUI on GL routers has deficiencies. OpenWRT is capable of fully implementing Tailscale but the “backoffice” of the GUI fails to adjust the operation OpenWRT effectively.
I have suggestions for your consideration:
Tailscale should be treated as a VPN and should be in the VPN section of the GUI.
Tailscale operation should exclude the use of OpenVPN or Wireguard connections and possibly others. Although technically possible to introduce policy rules to handle the redirection of traffic when establishing the connections, the loss, reestablishment and order of connecting, are complex and as such might be prone to failure.
2. The use of a remote exit node should cause all traffic to be routed to that node.
A full tunnel is required, all traffic including DNS requests should be sent to to the remote LAN. If an exit node is not declared then the Tailscale is in split tunneling mode. These 2 states require different settings for the firewall rules and the OpenWRT Masquerading flag.
I understand your implementation of Tailscale is in beta but, it was introduced sometime ago and should be more mature than it is.
Tailscale relies on its proprietary Tailscale CLI tool to function.
It only offers limited flexibility which make it unable to operate like OpenVPN or WireGuard within the GL UI.
During runtime, it automatically handles routing, DNS, and internally determines which traffic should be routed and which discarded.
If Tailscale provides greater flexibility in the future, I think we will gald to make it happen.
This is expected behavior, where DNS requests are sent to the remote exit node.
However, it adheres to the local DNS configuration.
That is, if Google DNS have been configured in router's DNS settings, DNS requests from LAN clients to router will be sent through the Tailscale tunnel to Google DNS servers.
LAN Client -- (DNS to Router) -> Router (Google DNS configured) -- (Fowarding DNS to Google DNS via Tailscale tunnel) -> Tailscale Exit node --> Google DNS server
