Flint GL-AX1800 ZeroTier for all Internet traffic

Router
1

Hello, My configuration is-

Router Ax1800 at home with active Internet connection ( SIMPoYo uFi usb dongle)

Active VPN client connection - Proton

Active ZeroTier on router with default settings(turned on via interface)

The goal:

Want to connect my Android device with the router via zerotier to receive a internet access via router vpn connection.

The USB dongle internet comes without dedicated IP.

I have installed on android device zerotier APP, added my zerotier virtual network but have no internet access. I did read need to configure manually the router in Luci- exit node?

Can someone help me step by step do it?

Thanks

2

A public IP is not required because ZeroTier can operate through CGNAT. Do not add a LuCI route yet; first confirm the basic ZeroTier path:

  1. Authorize both the Flint and Android phone in ZeroTier Central.
  2. Temporarily disconnect Proton VPN on the Flint. GL.iNet warns that ZeroTier and a VPN client can create routing conflicts when used together.
  3. Using mobile data on Android, verify that you can open the Flint’s ZeroTier Managed IP in a browser.
  4. If that works, add this Managed Route in ZeroTier Central: 0.0.0.0/0 via <Flint-ZeroTier-IP>, then enable Allow Default or Route via ZeroTier for that network on Android.

The Flint must additionally be configured to forward and masquerade traffic from its ZeroTier interface. Internet exit-node mode is not provided by the GL.iNet ZeroTier interface and requires firmware-specific firewall configuration; please post the Flint’s exact firmware version and whether step 3 succeeds so the correct firewall4/LuCI procedure can be identified. After ordinary Internet access works through the Flint, Proton can be re-enabled and tested separately. See the GL.iNet ZeroTier documentation and ZeroTier exit-node guide.

This 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.

3

1: all devices are authorized in zerotier central

  1. Proton VPN is now disconnected
  2. By using Android mobile data with active connection with zerotier APP and kill switch on in settings i can connect with assigned router IP(in zerotier central) to See login website for the router
  3. Last… i use new interface in zerotier central portal, don't See Anything to Configure….
4

Your successful router-login test confirms that the basic ZeroTier path works. In the new ZeroTier Central, custom Managed Routes are available only with an Essential plan or higher. On a supported plan, open the network and go to Settings → Managed Routes, then add:

0.0.0.0/0 via <Flint ZeroTier Managed IP>

If that section is absent, check the organization’s plan; the Personal plan cannot add this route. Upgrading the plan is therefore required before this network can advertise the Flint as Android’s default gateway.

Please also provide the Flint’s exact firmware version. That determines the appropriate firewall configuration for forwarding and masquerading ZeroTier traffic; do not add arbitrary LuCI routes meanwhile. Keep Proton disabled until ordinary Internet access through the Flint works. This 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.

5

I did meet criteria from 1 to 3.

I have an Old account without zerotier where I can Manage Routes

I added

Destination : 0.0.0.0/0 via 10.147.19.XXX(Assigned My zerotier network IP)

Default also is set up 10.147.19.0/XX via LAN

The GL inet flint 1800 router firmware is OpenWRT 23.05 branch git 25.222.75657-7ce34fe

Kernel 5.4.164

6

The 10.147.19.0/XX (LAN) route is the normal direct route for the ZeroTier subnet; leave it in place. With Proton still disabled, enable Route via ZeroTier on Android and test both https://1.1.1.1 and a normal domain. If the IP works but the domain does not, the remaining issue is DNS; if neither works while the Flint’s ZeroTier IP remains reachable, forwarding/masquerading on the Flint is missing.

The value provided is the LuCI build and kernel version, not the GL.iNet firmware version. Please check GL.iNet Admin Panel → SYSTEM → Upgrade and provide the displayed Current Version (for example, 4.x.x). That determines the correct persistent firewall procedure; the exit-node setup is not available as a standard GL.iNet/LuCI option.

This 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.

7

The current version of the software is 4.8.3

I cannot connect with https://1.1.1.1, no internet

8

That result confirms the Android default route is active and the ZeroTier link works, but the Flint is not yet forwarding/NATing the traffic. Before adding rules, check whether firmware 4.8.3 already created a ZeroTier firewall zone, so we do not create duplicate or conflicting zones.

SSH to the Flint and run:

ip -br addr | grep '^zt'
sysctl net.ipv4.ip_forward
uci show firewall | grep -Ei "=zone|=forwarding|\.name=|\.network=|\.device=|\.src=|\.dest=|\.masq=|zerotier|zt"

Please post that limited output, with any public IP address redacted. It will show the ZeroTier device/zone name, whether IPv4 forwarding is enabled, and whether a ZeroTier-to-WAN forwarding already exists. Keep Proton disabled for this test. This exit-node configuration is not officially supported by GL.iNet; guidance is best-effort, and GL.iNet Technical Support may not be able to 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.

9

I did run the command in SSH, please See the results

st=|.masq=|zerotier|zt"firewall.wan_drop_leaked_adgdns.name='wan_drop_leaked
_adgdns'
firewall.wan_drop_leaked_adgdns.src='wan'firewall.wan_drop_leaked_dns.name='wan_drop_leaked_dn
s'
firewall.wan_drop_leaked_dns.src='wan'firewall.guest_drop_leaked_dns.name='guest_drop_leake
d_dns'
firewall.guest_drop_leaked_dns.src='guest'firewall.guest_drop_leak_adgdns.name='guest_drop_leak
_adgdns'
firewall.guest_drop_leak_adgdns.src='guest'
firewall.@zone[0]=zone
firewall.@zone[0].name='lan'
firewall.@zone[0].network='lan'
firewall.@zone[1]=zone
firewall.@zone[1].name='wan'firewall.@zone[1].network='wan' 'wan6' 'wwan' 'tether
ing'
firewall.@zone[1].masq='1'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].src='lan'
firewall.@forwarding[0].dest='wan'
firewall.@rule[4].name='Allow-DHCP-Renew'
firewall.@rule[4].src='wan'
firewall.@rule[5].name='Allow-IGMP'
firewall.@rule[5].src='wan'
firewall.@rule[6].name='Allow-DHCPv6'
firewall.@rule[6].src='wan'
firewall.@rule[7].name='Allow-MLD'
firewall.@rule[7].src='wan'
firewall.@rule[8].name='Allow-ICMPv6-Input'
firewall.@rule[8].src='wan'
firewall.@rule[9].name='Allow-ICMPv6-Forward'
firewall.@rule[9].src='wan'
firewall.@rule[9].dest='*'
firewall.@rule[10].name='Allow-IPSec-ESP'
firewall.@rule[10].src='wan'
firewall.@rule[10].dest='lan'
firewall.@rule[11].name='Allow-ISAKMP'
firewall.@rule[11].src='wan'
firewall.@rule[11].dest='lan'
firewall.@zone[2]=zone
firewall.@zone[2].name='guest'
firewall.@zone[2].network='guest'
firewall.@forwarding[1]=forwarding
firewall.@forwarding[1].src='guest'
firewall.@forwarding[1].dest='wan'
firewall.@rule[12].name='Allow-DHCP'
firewall.@rule[12].src='guest'
firewall.@rule[13].name='Allow-DNS'
firewall.@rule[13].src='guest'firewall.lan_drop_leaked_dns.name='lan_drop_leaked_dn
s'
firewall.lan_drop_leaked_dns.src='lan'firewall.lan_drop_leak_adgdns.name='lan_drop_leak_adg
dns'
firewall.lan_drop_leak_adgdns.src='lan'firewall.wgserver_drop_leaked_dns.name='wgserver_drop
leaked_dns'
firewall.wgserver_drop_leaked_dns.src='wgserver'firewall.ovpnserver_drop_leaked_dns.name='ovpnserver
drop_leaked_dns'
firewall.ovpnserver_drop_leaked_dns.src='ovpnserver'firewall.wgserver_drop_leaked_adgdns.name='wgserver_d
rop_leaked_adgdns'
firewall.wgserver_drop_leaked_adgdns.src='wgserver'firewall.ovpnserver_drop_leaked_adgdns.name='ovpnserv
er_drop_leaked_adgdns'firewall.ovpnserver_drop_leaked_adgdns.src='ovpnserve
r'
firewall.sambasharewan.src='wan'
firewall.sambasharelan.src='lan'
firewall.glnas_ser.src='wan'
firewall.webdav_wan.src='wan'
firewall.wgclient1=zone
firewall.wgclient1.name='wgclient1'
firewall.wgclient1.network='wgclient1'
firewall.wgclient1.masq='1'
firewall.lan2wgclient1=forwarding
firewall.lan2wgclient1.src='lan'
firewall.lan2wgclient1.dest='wgclient1'
firewall.guest2wgclient1=forwarding
firewall.guest2wgclient1.src='guest'
firewall.guest2wgclient1.dest='wgclient1'
firewall.wan2wgclient1=forwarding
firewall.wan2wgclient1.src='wan'
firewall.wan2wgclient1.dest='wgclient1'
firewall.ovpnserver2wgclient1=forwarding
firewall.ovpnserver2wgclient1.src='ovpnserver'
firewall.ovpnserver2wgclient1.dest='wgclient1'
firewall.wgserver2wgclient1=forwarding
firewall.wgserver2wgclient1.src='wgserver'
firewall.wgserver2wgclient1.dest='wgclient1'
firewall.wgclient12lan=forwarding
firewall.wgclient12lan.src='wgclient1'
firewall.wgclient12lan.dest='lan'
firewall.zerotier=zone
firewall.zerotier.name='zerotier'
firewall.zerotier.input='ACCEPT'
firewall.zerotier.forward='REJECT'
firewall.zerotier.masq='1'
firewall.zerotier.mtu_fix='1'
firewall.zerotier.output='ACCEPT'
firewall.zerotier.enabled='1'
firewall.zerotier.network='zerotier'
firewall.zerotier_lan=forwarding
firewall.zerotier_lan.dest='lan'
firewall.zerotier_lan.src='zerotier'
firewall.lan_zerotier=forwarding
firewall.lan_zerotier.dest='zerotier'
firewall.lan_zerotier.src='lan'
firewall.zerotier_wan=forwarding
firewall.zerotier_wan.dest='wan'
firewall.zerotier_wan.src='zerotier'
firewall.wgserver=zone
firewall.wgserver.name='wgserver'
firewall.wgserver.network='wgserver'
firewall.wgserver.masq='1'
firewall.wgserver_allow.name='wgserver_allow'
firewall.wgserver_allow.src='wan'
firewall.wgserver2lan.name='wgserver2lan'
firewall.wgserver2lan.src='wgserver'
firewall.wgserver2lan.dest='lan'
firewall.wgserver2wan=forwarding
firewall.wgserver2wan.name='wgserver2wan'
firewall.wgserver2wan.src='wgserver'
firewall.wgserver2wan.dest='wan'
firewall.lan2wgserver=forwarding
firewall.lan2wgserver.name='lan2wgserver'
firewall.lan2wgserver.src='lan'
firewall.lan2wgserver.dest='wgserver'
firewall.wgserver2wgserver.name='wgserver2wgserver'
firewall.wgserver2wgserver.src='wgserver'
firewall.wgserver2wgserver.dest='wgserver'
firewall.wgserver_allow_dns.name='wgserver_allow_dns'
firewall.wgserver_allow_dns.src='wgserver'
root@GL-AX1800:~#

10

The firewall configuration already contains the required zerotier → wan forwarding, and the WAN zone has masquerading enabled, so do not add another zone or NAT rule. The first two command results appear to be missing from the pasted output. Please run these separately:

sysctl net.ipv4.ip_forward
ip -br addr | grep '^zt'
ip route get 1.1.1.1

Then restart the firewall once with service firewall restart and retest https://1.1.1.1 from Android. This briefly interrupts routed connections. If it still fails, post the three outputs above; they will show whether forwarding is enabled, whether the ZeroTier interface is correctly attached, and which outbound route the Flint is selecting. Keep Proton disconnected during this test.

This 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.

11

Added Command, and restarted firewall, 1.1.1.1 still doesn't work, no internet access,

Please See SSH results :

root@GL-AX1800:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@GL-AX1800:~# ip -br addr | grep '^zt'
ztw4lmxo2r UNKNOWN 10.147.19.235/24
root@GL-AX1800:~# ip route get 1.1.1.11.1.1.1 via 192.168.1.1 dev eth5 src 192.168.1.100 ui
d 0
cache
root@GL-AX1800:~# service firewall restartSection wgclient1 (wgclient1) is disabled, ignoring s
ectionSection wan_drop_leaked_adgdns (wan_drop_leaked_adgdn
s) is disabled, ignoring sectionSection wan_drop_leaked_dns (wan_drop_leaked_dns) is
disabled, ignoring sectionSection guest_drop_leaked_dns (guest_drop_leaked_dns)
is disabled, ignoring sectionSection guest_drop_leak_adgdns (guest_drop_leak_adgdn
s) is disabled, ignoring sectionSection ovpnserver_drop_leaked_dns (ovpnserver_drop_leaked_dns) option 'src' specifies invalid value 'ovpn
server'Section ovpnserver_drop_leaked_dns (ovpnserver_drop_l
eaked_dns) skipped due to invalid optionsSection ovpnserver_drop_leaked_adgdns (ovpnserver_drop_leaked_adgdns) option 'src' specifies invalid value
'ovpnserver'Section ovpnserver_drop_leaked_adgdns (ovpnserver_dro
p_leaked_adgdns) skipped due to invalid optionsSection sambasharewan specifies unknown option 'dest_
proto'Section sambasharelan specifies unknown option 'dest_
proto'Section glnas_ser specifies unknown option 'dest_prot
o'Section webdav_wan specifies unknown option 'dest_pro
to'Section wgserver2lan (wgserver2lan) is disabled, igno
ring sectionSection lan2wgclient1 option 'dest' specifies invalid
value 'wgclient1'
Section lan2wgclient1 skipped due to invalid optionsSection guest2wgclient1 option 'dest' specifies inval
id value 'wgclient1'Section guest2wgclient1 skipped due to invalid option
sSection wan2wgclient1 option 'dest' specifies invalid
value 'wgclient1'
Section wan2wgclient1 skipped due to invalid optionsSection ovpnserver2wgclient1 option 'src' specifies i
nvalid value 'ovpnserver'Section ovpnserver2wgclient1 skipped due to invalid o
ptionsSection wgserver2wgclient1 option 'dest' specifies in
valid value 'wgclient1'Section wgserver2wgclient1 skipped due to invalid opt
ionsSection wgclient12lan option 'src' specifies invalid
value 'wgclient1'
Section wgclient12lan skipped due to invalid options
Section nat6 option 'reload' is not supported by fw4Section dns_order option 'reload' is not supported by
fw4Section glblock option 'reload' is not supported by fw4
Section dmz_exclude option 'reload' is not supportedby fw4
Section security option 'reload' is not supported byfw4
Automatically including '/usr/share/nftables.d/ruleset-post/dns_accept.nft'
Automatically including '/usr/share/nftables.d/ruleset-post/tcp_dns_leak_drop.nft'
Automatically including '/usr/share/nftables.d/chain-pre/dstnat/00-dhcp-no-flow_offloading.nft'

Warning: iptables-legacy tables present, use iptables-legacy-save to see them

Warning: iptables-legacy tables present, use iptables-legacy-save to see them

root@GL-AX1800:~#

12

The router-side forwarding, ZeroTier interface, and Internet route all look correct. The firewall warnings shown are unrelated legacy/disabled sections and do not explain this failure.

The next step is to determine whether Android’s traffic reaches the Flint and whether it leaves through eth5. Run this on the Flint, then immediately try opening https://1.1.1.1 on Android while ZeroTier is active:

timeout 20 tcpdump -ni any 'host 1.1.1.1'

Please post only the resulting packet lines. If no packets appear on ztw4lmxo2r, Android is not accepting the advertised default route. If they arrive on ztw4lmxo2r but do not leave on eth5, the Flint is blocking forwarding; if they leave on eth5 but no replies return, the NAT or upstream path is the next point to inspect. Keep Proton disabled during this capture.

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.

13

The results

X1800:~# 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 bytes12:33:36.293211 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24825, length 812:33:36.323647 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24825, length 812:33:37.333218 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24829, length 812:33:37.362791 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24829, length 812:33:38.373218 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24833, length 812:33:38.427054 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24833, length 812:33:39.413209 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24837, length 812:33:39.444556 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24837, length 812:33:40.453253 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24841, length 812:33:40.483589 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24841, length 812:33:41.493206 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24845, length 812:33:41.524452 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24845, length 812:33:42.533210 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24849, length 812:33:42.562712 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24849, length 812:33:43.573216 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24853, length 812:33:43.603500 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24853, length 812:33:44.613214 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24857, length 812:33:44.651476 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24857, length 812:33:45.663208 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24861, length 812:33:45.693517 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24861, length 812:33:46.703213 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24865, length 812:33:46.745632 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24865, length 812:33:47.733226 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24869, length 812:33:47.763698 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24869, length 812:33:48.773211 eth5 Out IP 192.168.1.100 > 1.1.1.1:
ICMP echo request, id 45935, seq 24873, length 812:33:48.811412 eth5 In IP 1.1.1.1 > 192.168.1.100:
ICMP echo reply, id 45935, seq 24873, length 812:33:49.813217 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 24877, length 8
12:33:49.842665 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 24877, length 8
12:33:50.853208 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 24881, length 8
12:33:50.884568 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 24881, length 8
12:33:51.893218 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 24885, length 8
12:33:51.924433 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 24885, length 8
12:33:52.933221 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 24889, length 8
12:33:52.951083 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 24889, length 8

14

This capture shows that ICMP requests are being NATed to 192.168.1.100 and that replies return on eth5. However, because no ztw4lmxo2r packets appear, it does not confirm that these requests originated from Android; the traffic shown is ICMP ping traffic, not the browser’s HTTPS connection.

Run the following and, during the capture, ping 1.1.1.1 specifically from Android:

timeout 20 tcpdump -ni ztw4lmxo2r 'host 1.1.1.1'

Post the packet lines and state whether Android reports ping replies. No packets would mean Android is not sending its default route through ZeroTier; requests without replies would identify a return-forwarding problem; packets in both directions would confirm that the complete tunnel works and allow the browser/DNS behavior to be investigated separately.

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.

15

I did a test, tried to reach 1.1.1.1 on android

at the same time run SSH command via PC,

result:

0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@GL-AX1800:~# timeout 20 tcpdump -ni ztw4lmxo2r 'host 1.1.1.1'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ztw4lmxo2r, link-type EN10MB (Ethernet), snapshot length 262144 bytes

16

The zero-packet capture confirms that Android is not sending its default-route traffic into ZeroTier. Verify that the Managed Route points specifically to the Flint’s address shown above—not the phone’s address:

0.0.0.0/0 via 10.147.19.235

Then, in the Android ZeroTier app, open this network and enable Route via ZeroTier (the kill switch alone does not accept a managed default route). Disconnect and reconnect the ZeroTier network so it downloads the updated route, then repeat the capture and test. If it still captures zero packets, please post a screenshot of the Android network options and the Managed Routes entry, with the Network ID and other identifiers redacted.

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.

17

once again the results

root@GL-AX1800:~# timeout 20 tcpdump -ni any 'host 1.1.1.1'
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:55:29.813208 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29877, length 8
12:55:29.833054 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29877, length 8
12:55:30.853225 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29881, length 8
12:55:30.888068 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29881, length 8
12:55:31.893212 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29885, length 8
12:55:31.913073 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29885, length 8
12:55:32.933241 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29889, length 8
12:55:32.949093 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29889, length 8
12:55:33.973210 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29893, length 8
12:55:34.001344 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29893, length 8
12:55:35.013216 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29897, length 8
12:55:35.032111 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29897, length 8
12:55:36.053219 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29901, length 8
12:55:36.076381 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29901, length 8
12:55:37.093218 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29905, length 8
12:55:37.112136 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29905, length 8
12:55:38.133211 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29909, length 8
12:55:38.161276 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29909, length 8
12:55:39.173217 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29913, length 8
12:55:39.211154 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29913, length 8
12:55:40.213214 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29917, length 8
12:55:40.231171 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29917, length 8
12:55:41.253333 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29921, length 8
12:55:41.287421 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29921, length 8
12:55:42.293253 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29925, length 8
12:55:42.310941 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29925, length 8
12:55:43.333216 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29929, length 8
12:55:43.353442 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29929, length 8
12:55:44.373222 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29933, length 8
12:55:44.391328 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29933, length 8
12:55:45.413212 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29937, length 8
12:55:45.466713 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29937, length 8
12:55:46.453211 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29941, length 8
12:55:46.473600 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29941, length 8
12:55:47.493212 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29945, length 8
12:55:47.524238 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29945, length 8
12:55:48.533217 eth5 Out IP 192.168.1.100 > 1.1.1.1: ICMP echo request, id 45935, seq 29949, length 8
12:55:48.552497 eth5 In IP 1.1.1.1 > 192.168.1.100: ICMP echo reply, id 45935, seq 29949, length 8

38 packets captured
40 packets received by filter
0 packets dropped by kernel
root@GL-AX1800:~#

18

This capture still shows only traffic on eth5; it does not show any packet entering through ztw4lmxo2r. The ICMP requests are therefore likely coming from the Flint or the PC, not from Android through ZeroTier.

Stop any ping running on the Flint/PC, then run the requested interface-specific capture and ping 1.1.1.1 from an Android ping app:

timeout 20 tcpdump -ni ztw4lmxo2r icmp

If it remains at zero packets, please post screenshots of the Managed Route and the Android ZeroTier network options, showing that 0.0.0.0/0 via 10.147.19.235 and Route via ZeroTier/Allow Default are enabled. Redact the Network ID and device identifiers.

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.

19

Zerotier central config:

Managed Routes 2/128

0.0.0.0/0 via 10.147.19.235
10.147.19.0/24 (LAN)

Android config:

ticked all traffic through zerotier

connection online

20

The Managed Route and Android all traffic through ZeroTier option are correct, so no further Flint firewall changes are needed yet. Refresh the Android client’s route state:

  1. Disconnect the ZeroTier network in the app.
  2. Force-stop the ZeroTier app, reopen it, and reconnect using mobile data.
  3. Ensure no other VPN or firewall/ad-blocking VPN app is active.
  4. Run timeout 20 tcpdump -ni ztw4lmxo2r 'host 1.1.1.1' and ping 1.1.1.1 from Android during the capture.

If it still captures zero packets, please provide the Android version and ZeroTier app version. That would indicate the Android client is not installing the advertised default route despite the option being enabled, rather than a Flint forwarding problem.

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.