on android mobile data cannot reach router via ssh with zerotier enabled,
i am able to connect with router via ssh only via wifi
Test the ZeroTier address directly rather than the Flint’s LAN address. With Wi‑Fi disabled and mobile data active, temporarily turn off all traffic through ZeroTier but leave the ZeroTier network connected, then try:
ssh root@10.147.19.235
Also open http://10.147.19.235 in the Android browser. If the Admin Panel opens but SSH fails, report the exact SSH error; that isolates the issue to SSH access. If neither works, the basic Android-to-Flint ZeroTier connection is currently failing, so the exit-node test cannot proceed. Do not test 192.168.8.1 at this stage.
This ZeroTier exit-node configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
On Android zerotier connected, Could connect to router via SSH 10.147.19.235
Run the command to ping 1.1.1.1 on Android at the same time
Results
root@GL-AX1800:~# timeout 20 tcpdump -ni any 'host 1.
1.1.1'
tcpdump: data link type LINUX_SLL2tcpdump: verbose output suppressed, use -v[v]... for
full protocol decodelistening on any, link-type LINUX_SLL2 (Linux cooked
v2), snapshot length 262144 bytes13:15:10.213207 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34417, length 813:15:10.380498 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34417, length 813:15:11.253222 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34421, length 813:15:11.517512 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34421, length 813:15:12.293212 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34425, length 813:15:12.456646 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34425, length 813:15:13.333217 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34429, length 813:15:13.502030 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34429, length 813:15:14.383216 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34433, length 813:15:14.718668 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34433, length 813:15:15.413223 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34437, length 813:15:15.664179 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34437, length 813:15:16.453249 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34441, length 813:15:16.619982 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34441, length 813:15:17.493224 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34445, length 813:15:17.664574 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34445, length 813:15:18.533218 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34449, length 813:15:18.730965 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 34449, length 813:15:19.573215 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 34453, length 813:15:19.808851 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34453, length 8
13:15:20.613211 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34457, length 8
13:15:21.170367 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34457, length 8
13:15:21.653218 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34461, length 8
13:15:22.072119 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34461, length 8
13:15:22.693220 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34465, length 8
13:15:23.144883 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34465, length 8
13:15:23.733213 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34469, length 8
13:15:24.300523 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34469, length 8
13:15:24.773211 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34473, length 8
13:15:25.656923 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34473, length 8
13:15:25.813205 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34477, length 8
13:15:26.447679 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34477, length 8
13:15:26.853222 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34481, length 8
13:15:27.651929 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34481, length 8
13:15:27.893213 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34485, length 8
13:15:28.781567 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34485, length 8
13:15:28.933215 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34489, length 8
13:15:29.973208 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 34493, length 8
13:15:30.065956 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 34489, length 8
39 packets captured
41 packets received by filter
0 packets dropped by kernel
root@GL-AX1800:~#
The unchanged ICMP ID (45935) and absence of packets on ztw4lmxo2r indicate that this ping is being run inside the SSH session on the Flint, not locally on Android.
Enable all traffic through ZeroTier, disconnect the SSH session, and use an Android ping app or a local Android terminal—not an SSH shell—to ping 1.1.1.1. At the same time, run this from a separately connected PC:
timeout 20 tcpdump -ni ztw4lmxo2r icmp
The successful mobile-data SSH connection to 10.147.19.235 confirms the basic ZeroTier path. This test will determine whether Android sends its default-route traffic through that path.
This ZeroTier exit-node configuration is not officially supported by GL.iNet. Guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain it.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Run ping 1.1.1.1 on Android in termux.
Results
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=258 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=425 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=213 ms
Etc..
--- 1.1.1.1 ping statistics ---
86 packets transmitted, 87 received, -1% packet loss, time 85161ms
rtt min/avg/max/mdev = 131.921/264.818/456.993/91.481 ms, pipe 29102
End
The successful Termux ping confirms that Android’s IPv4 traffic is now passing through ZeroTier and exiting through the Flint. No additional firewall rules are needed.
While all traffic through ZeroTier remains enabled, test DNS and HTTPS in Termux:
ping -c 3 example.com
curl -4 https://ifconfig.me
If both work, normal Internet routing is operational. Note the returned public IP, then enable Proton on the Flint and repeat the curl command. It should change to Proton’s exit IP. If Internet access stops after enabling Proton, disable Proton again; that indicates the documented routing conflict between ZeroTier and the VPN client rather than a ZeroTier exit-node failure.
This ZeroTier exit-node configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Results from Termux
ping -c 3 example.com
curl -4 https://ifconfig.me
ping: unknown host example.com
curl: (6) Could not resolve host: ifconfig.me
IPv4 routing is working; the remaining failure is DNS. First confirm that a public resolver is reachable from Termux:
nslookup example.com 1.1.1.1
If that returns addresses, configure the ZeroTier network to supply 1.1.1.1 as its DNS server, enable the Android network’s Allow DNS option if shown, then disconnect and reconnect ZeroTier. Alternatively, set Android Settings → Network & Internet → Private DNS → Private DNS provider hostname to one.one.one.one. Retest:
ping -c 3 example.com
curl -4 https://ifconfig.me
Keep Proton disabled until DNS works. This ZeroTier exit-node configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I set up dns to 1.1.1.1 in zerotier android APP
Now successfully have internet connection with routers intenet IP.
All work.
Now will try to turn on proton VPN on router to See Does it work or. Need further configuration.
nslookup example.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: example.com
Address: 104.20.23.154
Name: example.com
Address: 172.66.147.243
Name: example.com
Address: 2606:4700:10::6814:179a
Name: example.com
Address: 2606:4700:10::ac42:93f3
~ $ ping -c 3 example.com
PING example.com (104.20.23.154) 56(84) bytes of data.
64 bytes from 104.20.23.154: icmp_seq=1 ttl=53 time=155 ms
64 bytes from 104.20.23.154: icmp_seq=2 ttl=53 time=235 ms
64 bytes from 104.20.23.154: icmp_seq=3 ttl=53 time=232 ms
--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 155.489/208.033/235.983/37.181 ms
~ $ curl -4 https://ifconfig.me
92.40.174.173~ $
The Internet is working now, i set up dns as 1.1.1.1 in Android zerotowr APP.
Now on router i enabled proton vpn client. The vpn is turned on properly but on android the internet connection don't go through VPN, it Goes directly to Internet doungle provider…
On firmware 4.8.3, open VPN → VPN Dashboard and select Global Mode rather than Policy Mode. Confirm the Proton tunnel’s IP Masquerading option is enabled, reconnect Proton, and then repeat from Android:
curl -4 https://ifconfig.me
Global Mode is intended to send all client traffic through the active VPN. However, ZeroTier traffic may still bypass that policy because ZeroTier and VPN Client operation together can cause routing conflicts and this cascading arrangement is not officially supported. If the IP remains 92.40.174.173, run the following on the Flint while repeating the Android curl command and post the packet lines:
timeout 20 tcpdump -ni any 'host 1.1.1.1 or port 443'
This will confirm whether ZeroTier traffic continues to leave through eth5 or is entering the Proton interface before any custom policy-routing changes are considered.
This ZeroTier-to-Proton cascading configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
The results ;
Etc….
15:35:24.871750 wgclient1 Out IP 10.2.0.2.33423 > 79.135.104.91.443: UDP, length 1312
15:35:24.871675 wlan1 P IP 192.168.8.186.33423 > 79.135.104.91.443: UDP, length 1312
15:35:24.871675 br-lan In IP 192.168.8.186.33423 > 79.135.104.91.443: UDP, length 1312
15:35:24.871787 wgclient1 Out IP 10.2.0.2.33423 > 79.135.104.91.443: UDP, length 1312
15:35:24.877781 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 1245, length 8
15:35:24.878493 wlan1 P IP 192.168.8.186.33423 > 79.135.104.91.443: UDP, length 304
15:35:24.878493 br-lan In IP 192.168.8.186.33423 > 79.135.104.91.443: UDP, length 304
15:35:24.878532 wgclient1 Out IP 10.2.0.2.33423 > 79.135.104.91.443: UDP, length 304
11786 packets captured
11793 packets received by filter
0 packets dropped by kernel
root@GL-AX1800:~#
This capture only confirms that the LAN device 192.168.8.186 is routed through Proton (wgclient1, translated to 10.2.0.2). It does not show the Android ZeroTier traffic.
Disconnect or idle the LAN device, then run this interface-specific capture while executing curl -4 https://ifconfig.me locally in Termux:
timeout 20 tcpdump -ni ztw4lmxo2r 'tcp port 443'
If packets appear, post those lines together with the IP returned by curl. This will verify that the tested HTTPS connection actually entered the Flint from Android. If the returned address is still the dongle provider’s IP, the ZeroTier source is bypassing GL.iNet’s VPN policy even though ordinary LAN clients correctly use Proton; custom policy routing would then be required.
This ZeroTier-to-Proton cascading configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
The results
|_______|| ||***||||**|| ||
|*_| W I R E L E S S F R E E D O M
ApNos-1d14362f-devel
OpenWrt 23.05-SNAPSHOT,
root@GL-AX1800:~# curl -4 https://ifconfig.me92.40.174.171root@GL-AX1800:~# timeout 20 tcpdump -ni
ztw4lmxo2r '
tcp port 443'tcpdump: verbose output suppressed, use -v[v]... for
full protocol decodelistening on ztw4lmxo2r, link-type EN10MB (Ethernet),
snapshot length 262144 bytes15:41:28.120578 IP 10.147.19.248.38982 > 172.217.115.4.443: Flags [FP.], seq 3671855843:3671855867, ack 3429385424, win 141, options [nop,nop,TS val 1547966408
ecr 2526672577], length 2415:41:30.829000 IP 10.147.19.248.55218 > 47.90.241.107.443: Flags [R.], seq 3233064037, ack 3987904332, win 133, options [nop,nop,TS val 3435959781 ecr 1713809
807], length 015:41:31.061585 IP 10.147.19.248.38982 > 172.217.115.4.443: Flags [FP.], seq 0:24, ack 1, win 141, options [nop,nop,TS val 1547969480 ecr 2526672577], length 2
415:41:36.612548 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [S], seq 813880596, win 65535, options [mss 2760,sackOK,TS val 3435965605 ecr 0,nop,wscale 9]
, length 015:41:36.630423 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [S.], seq 605867519, ack 813880597, win14600, options [mss 1320,nop,wscale 12,sackOK,TS val
1061423166 ecr 3435965605], length 015:41:36.725514 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [.], ack 1, win 128, options [nop,nop,TS
val 3435965788 ecr 1061423166], length 015:41:36.740511 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [.], seq 1:1309, ack 1, win 128, options [nop,nop,TS val 3435965788 ecr 1061423166], length 1
30815:41:36.745446 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [P.], seq 1309:2341, ack 1, win 128, options [nop,nop,TS val 3435965788 ecr 1061423166], leng
th 103215:41:36.751720 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [.], ack 1, win 1024, options [nop,nop,T
S val 1061423288 ecr 3435965788], length 015:41:36.781481 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [.], ack 2341, win 1023, options [nop,no
p,TS val 1061423318 ecr 3435965788], length 015:41:36.859404 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [P.], seq 1:261, ack 2341, win 1024, options [nop,nop,TS val 1061423397 ecr 3435965788], leng
th 26015:41:36.991723 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [.], ack 261, win 131, options [nop,nop,
TS val 3435966028 ecr 1061423397], length 015:41:36.991842 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [P.], seq 2341:2421, ack 261, win 131, options [nop,nop,TS val 3435966029 ecr 1061423397], le
ngth 8015:41:36.991930 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [.], seq 2421:3729, ack 261, win 131, options [nop,nop,TS val 3435966030 ecr 1061423397], len
gth 130815:41:36.991996 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [P.], seq 3729:4860, ack 261, win 131, options [nop,nop,TS val 3435966030 ecr 1061423397], le
ngth 113115:41:36.998228 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [P.], seq 4860:5548, ack 261, win 131, options [nop,nop,TS val 3435966030 ecr 1061423397], le
ngth 68815:41:37.018346 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [.], ack 3729, win 1023, options [nop,no
p,TS val 1061423555 ecr 3435966029], length 015:41:37.023343 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [.], ack 5548, win 1023, options [nop,no
p,TS val 1061423560 ecr 3435966030], length 015:41:37.089564 IP 47.90.241.107.443 > 10.147.19.248.43466: Flags [P.], seq 261:564, ack 5548, win 1024, options [nop,nop,TS val 1061423627 ecr 3435966030], le
ngth 30315:41:37.325730 IP 10.147.19.248.38982 > 172.217.115.4.443: Flags [FP.], seq 0:24, ack 1, win 141, options [nop,nop,TS val 1547975628 ecr 2526672577], length 2
415:41:37.325874 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [.], ack 564, win 133, options [nop,nop,
TS val 3435966294 ecr 1061423627], length 015:41:46.666976 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [S], seq 2021494701, win 65535, options[mss 2760,sackOK,TS val 502044208 ecr 0,nop,wscale 9]
, length 015:41:46.689464 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [S.], seq 319928735, ack 2021494702, win 14600, options [mss 1320,nop,wscale 12,sackOK,TS val
2066114361 ecr 502044208], length 015:41:46.821718 IP 10.147.19.248.43466 > 47.90.241.107.443: Flags [R.], seq 5548, ack 564, win 133, options [nop,nop,TS val 3435975860 ecr 1061423627], length
015:41:46.824893 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 1, win 128, options [nop,nop,TS
val 502044375 ecr 2066114361], length 015:41:46.840821 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 1, win 1024, options [nop,nop,T
S val 2066114513 ecr 502044375], length 015:41:46.860547 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], seq 1:1309, ack 1, win 128, options [nop,nop,TS val 502044376 ecr 2066114361], length 13
0815:41:46.860684 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 1309:2285, ack 1, win 128, options [nop,nop,TS val 502044376 ecr 2066114361], lengt
h 97615:41:46.936648 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 2285, win 1023, options [nop,no
p,TS val 2066114571 ecr 502044376], length 015:41:46.948841 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [P.], seq 1:1309, ack 2285, win 1024, options [nop,nop,TS val 2066114582 ecr 502044376], leng
th 130815:41:46.948965 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [P.], seq 1309:1466, ack 2285, win 1024, options [nop,nop,TS val 2066114582 ecr 502044376], l
ength 15715:41:47.064535 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 1, win 131, options [nop,nop,TS val 502044621 ecr 2066114571,nop,nop,sack 1 {1309:14
66}], length 015:41:47.075934 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 1466, win 142, options [nop,nop
,TS val 502044636 ecr 2066114582], length 015:41:47.076036 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 2285:2359, ack 1466, win 142,options [nop,nop,TS val 502044637 ecr 2066114582], le
ngth 7415:41:47.079582 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 2359:2451, ack 1466, win 142,options [nop,nop,TS val 502044638 ecr 2066114582], le
ngth 9215:41:47.114898 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], seq 2451:3759, ack 1466, win 142, options [nop,nop,TS val 502044638 ecr 2066114582], len
gth 130815:41:47.115622 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 3759:4868, ack 1466, win 142,options [nop,nop,TS val 502044638 ecr 2066114582], le
ngth 110915:41:47.116066 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 2451, win 1024, options [nop,no
p,TS val 2066114776 ecr 502044637], length 015:41:47.116106 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [P.], seq 1466:2428, ack 2451, win 1024, options [nop,nop,TS val 2066114776 ecr 502044637], l
ength 96215:41:47.126532 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [P.], seq 2428:2459, ack 2451, win 1024, options [nop,nop,TS val 2066114779 ecr 502044637], l
ength 3115:41:47.140733 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 4868:4978, ack 1466, win 142,options [nop,nop,TS val 502044639 ecr 2066114582], length 110
15:41:47.174461 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 3759, win 1024, options [nop,nop,TS val 2066114825 ecr 502044638], length 0
15:41:47.178207 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 4978, win 1024, options [nop,nop,TS val 2066114835 ecr 502044638], length 0
15:41:47.246021 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 2459, win 147, options [nop,nop,TS val 502044807 ecr 2066114776], length 0
15:41:47.336155 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 4978:5009, ack 2459, win 147,options [nop,nop,TS val 502044808 ecr 2066114776], length 31
15:41:47.392880 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], seq 2459:3767, ack 4978, win 1024,options [nop,nop,TS val 2066114949 ecr 502044807], length 1308
15:41:47.392934 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [P.], seq 3767:4006, ack 4978, win 1024, options [nop,nop,TS val 2066114949 ecr 502044807], length 239
15:41:47.482110 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 5009, win 1024, options [nop,nop,TS val 2066115040 ecr 502044808], length 0
15:41:47.493574 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 2459, win 152, options [nop,nop,TS val 502045061 ecr 2066114835,nop,nop,sack 1 {3767:4006}], length 0
15:41:47.493691 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [.], ack 4006, win 163, options [nop,nop,TS val 502045062 ecr 2066114949], length 0
15:41:47.497490 IP 10.147.19.248.43264 > 172.217.76.17.443: Flags [P.], seq 5009:5048, ack 4006, win 163,options [nop,nop,TS val 502045064 ecr 2066114949], length 39
15:41:47.540644 IP 172.217.76.17.443 > 10.147.19.248.43264: Flags [.], ack 5048, win 1024, options [nop,nop,TS val 2066115206 ecr 502045064], length 0
52 packets captured
52 packets received by filter
0 packets dropped by kernel
root@GL-AX1800:~#
The curl command was run at the root@GL-AX1800 prompt, so 92.40.174.171 is the public IP used by traffic originating from the Flint itself. It does not determine how the Android client is routed. The capture does confirm that Android (10.147.19.248) is sending HTTPS traffic through ZeroTier and receiving replies.
Run the following locally in Termux on Android, not inside the SSH session:
curl -4 https://ifconfig.me ; echo
If it returns Proton’s exit IP, the required Android traffic is already using Proton. If it still returns the dongle provider’s IP, ZeroTier traffic is bypassing the firmware’s VPN client policy even in Global Mode; the next step would be source-based custom policy routing, which is outside the supported GL.iNet ZeroTier/VPN configuration.
This ZeroTier-to-Proton cascading configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Results
root@GL-AX1800:~# curl -4 https://ifconfig.me ; echo
92.40.174.171
It's not the proton IP, it's the internet dongle one. If it's so difficult to set up internet access via VPN client only why zerotier is for?
I Don't want use my internet provider direct internet access ans my ISP See my Internet traffic…
That command was again run in the Flint’s SSH shell—the root@GL-AX1800 prompt proves it. Router-originated traffic may use WAN directly and does not reveal Android’s exit path. Exit SSH, open the local Termux prompt (normally $, not root@GL-AX1800), and run:
curl -4 https://ifconfig.me ; echo
ZeroTier primarily provides encrypted remote access between members; it does not automatically make the Flint an Internet exit node or cascade traffic into Proton. If the Android-local result is still the dongle IP, firmware 4.8.3 is not applying its VPN-client policy to the ZeroTier source. That combination requires unsupported custom policy routing. If avoiding any direct WAN fallback is essential, stop using this configuration until it is verified; the standard VPN kill switch may not cover this custom ZeroTier path.
This ZeroTier-to-Proton cascading configuration is not officially supported by GL.iNet. Any guidance is provided on a best-effort basis, and GL.iNet Technical Support may not be able to troubleshoot or maintain this configuration.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Hi,
Thank you for your continued testing and feedback.
To further investigate the routing through Proton VPN, could you please help us check the following?
- Could you share screenshots of your current VPN Dashboard and VPN tunnl settings?
- With Proton VPN connected on the Flint, please connect your Android phone to ZeroTier using mobile data, then open https://ipv4.icanhazip.com directly in your phone's browser and share the IP address shown.
Alternatively, you can runcurl -4 https://ifconfig.mein Termux directly on your Android phone, rather than through an SSH session to the router.
I didn't resolve the issue, tried solutions from a few sources, from a year tried to resolve the issue, i am giving up. No internet on Tailscale and that's it.
Hi,
We understand that you have tried many different solutions and spent a lot of time investigating this issue.
If you are willing to continue, could you please provide the following information based on your current configuration?
- Your current VPN Client settings on the Flint.
- The public IP address shown on your Android phone when connected through ZeroTier .
Of course, we also understand if you would prefer not to continue testing at this point.
Thank you again for your patience, time.