DNS over tunnel not working on Android client

[marcopaganini]

Hello there!

I'm testing pangolin and I'm seeing an interesting problem related to the Android DNS override + tunneling.

In a nutshell, in the pangolin dashboard, I've created a private resource for my "internal" DNS server:

• Mode: Host
• Destination: 172.30.1.1 (my internal DNS server)
• Post restrictions: TCP and UDP -> Custom: 53, ICMP ping enabled.

Inside the pangolin android client I have:

• Enable aliases (DNS Override): On
• DNS Over Tunnel: On
• Primary upstream DNS server: 172.30.1.1
• Secondary Upstream DNS server: Blank
• Enable log collection: On

I have newt running on a another machine in the 172.30.1.0/24 network. It can access the DNS server without problems, no firewall involved.

With this setup, I'd expect all DNS queries to go over the tunnel and hit my internal DNS server, which does not happen. I've verified this with tcpdump on port 53 on my DNS server.

The interesting thing is that when I use a DNS resolution app on my phone (PingTools, for example), it does go through the tunnel and I can see the exact query on tcpdump in my server. However, all browser queries seem to use the carrier DNS, and thus I cannot resolve any internal IP addresses :(

I even changed the browser settings on the phone and turned off "Secure DNS" (DNS over https), but it still does not work.

I also have a plain Wireguard client installed on this phone. This client is configured to override DNS. When I turn off pangolin and turn on the Wireguard VPN client, everything works as expected. Naturally, the Wireguard client is not using pangolin -- this just serves to show that the VPN override works for another VPN client.

PS: Despite log collection being turned on, the "Logs" option in the pangolin client app shows a greyed out "Download logs" button. Bug?

Any ideas will be appreciated.

[marker]

Trying out Pangolin today and this is definitely broken for Android clients, it's not possible to tunnel DNS to your defined upstreams. I did pretty much the same investigation and troubleshooting you did before I found this issue posted. From similar reports it sounds like the Pangolin client on a computer will work as expected, making it an Android-specific problem... I'm going to be testing with a VM to verify if that's the case.

[crisidev]

I was able to create the private resource and add my own DNS server as the only server for the pangolin app on Android. If I dig @myserver I get the right responses, but the default android DNS still goes out of the tunnel, effectively preventing me to have a working setup for now.

[crisidev]

To add to this, with my DNS setup, I should't see some request going over pangolin as they would be routed to my private load balancer that is available in the tunnel. However, I still see the request to those sites to go over the pangolin traefik in the request logs

[marcopaganini]

So I ran a few more tests with this, and it appears that I cannot fully reach private resources even when using IP, but there's a catch.

The basic setup is the same: Android device with the app running. On pangolin, I configured one of my IPs as a private resource:

• Mode: Host
• Destination: 172.30.1.1
• Port Restrictions:
  • TCP: Custom 22,53
  • UDP: Blocked
  • ICMP: Allowed

Using this configuration, attempting to ping from the android device fails with a timeout. On the newt logs I see:

INFO: 2026/03/09 17:58:23 ICMP Handler: Queued echo reply packet for transmission
INFO: 2026/03/09 17:58:23 Removed target subnet 100.90.128.2/32 with destination 172.30.1.1/32
INFO: 2026/03/09 17:58:23 Added target subnet from 100.90.128.2/32 to 172.30.1.1/32 rewrite to  with port ranges: [{22 22 tcp} {53 53 tcp}]

However, if I change the Port restrictions above to TCP=All, and UDP=All, then everything magically works. Of course, that's undesirable from a security perspective. New logs show:

INFO: 2026/03/09 18:07:40 Removed target subnet 100.90.128.2/32 with destination 172.30.1.1/32
INFO: 2026/03/09 18:07:40 Added target subnet from 100.90.128.2/32 to 172.30.1.1/32 rewrite to  with port ranges: []
INFO: 2026/03/09 18:07:41 ICMP Handler: Echo Request from 100.90.128.2 to 172.30.1.1 (ident=3166, seq=1)
INFO: 2026/03/09 18:07:41 ICMP Handler: Matched subnet rule for 100.90.128.2 -> 172.30.1.1
INFO: 2026/03/09 18:07:41 ICMP Handler: Ping successful to 172.30.1.1 using raw ICMP, injecting reply (ident=3166, seq=1)
INFO: 2026/03/09 18:07:41 ICMP Handler: Queued echo reply packet for transmission
INFO: 2026/03/09 18:07:42 ICMP Handler: Echo Request from 100.90.128.2 to 172.30.1.1 (ident=3167, seq=1)
INFO: 2026/03/09 18:07:42 ICMP Handler: Matched subnet rule for 100.90.128.2 -> 172.30.1.1
INFO: 2026/03/09 18:07:42 ICMP Handler: Ping successful to 172.30.1.1 using raw ICMP, injecting reply (ident=3167, seq

[crisidev]

I made It work by adding 2 resources: 1 for my internal DNS, which returns the internal Load balancer IP for all resources and 1 for the load balancer IP. The DNS only has UDP 53 and ICMP, and the load balancer only has 80 and 443.

[marcopaganini]

In my case it does not even appear to be DNS related anymore. I'm pinging the plain IP of the internal resource and things don't work. The only way to make it work is to set TCP and UDP ports to "All" in the restrictions. Having custom ports breaks ICMP, even if Allow ICMP is set.

[marcopaganini]

I think my case is covered by #2193

[crisidev]

I see. I don't really care about ICMP in my case, so I guess I am not impacted by this, but it would be nice to have this fixed. Nice report!

[GisaLab]

I have exactly the same problem. I've added a private resource, allowed all TCP and UDP ports in the DNS restrictions, and then in the Pangolin Android client, I have:
Enable aliases (DNS replacement): Enabled
DNS via tunnel: enabled

If I test a ping from my phone to the DNS, it responds correctly, but it's as if Android isn't recognizing the Pangolin DNS configuration.