Default route / full tunel trouble

Community Support
1

Hey all,

I’ve read through this:
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7110693/Overriding+Default+Route+Full+Tunnel+Mode

<3 other discussions where the posters have the same problem… I can only post 2 links for the moment>

And I’m having the same problem everyone else is having. I was wondering if a visual diagram could be created to help clear up the confusion e.g.
-A POSTROUTING -o eth0 -s 10.6.4.0/22 -j SNAT --to- source 45.32.69.220
“Our net is 10.6.4.0/22”. What is “our net” referring to? is that our LAN (non zerotier) or is it our zerotier network?

-A FORWARD -i zt+ -s 10.6.4.0/22 -d 0.0.0.0 /0 -j ACCEPT
-A FORWARD -i eth0 -s 0.0.0.0 /0 -d 10.6.4.0/0 -j ACCEPT
do I need to replace zt+ with my zerotier interface name? (ztfp6ileyh)
on the first line we have 10.64.0/22 and on the second line is 10.6.4.0/0. Is that intentional?

“Log into ZeroTier Central and add a route to 0.0.0.0/0 via the IP address of your new virtual edge router”
“On our net 10.6.4.0/22 is our network and 10.6.6.2 is our virtual edge router’s internal IP address (internal to the ZeroTier network)”
Ok working backwards, the subnet 10.6.4.0/22 probably includes ip 10.6.6.2 and we know thats a zt ip address. we also know LAN and ZT subsets shouldn’t overlap. So i’m going to assume 10.6.4.0/22 is in fact a zerotier subnet. But then going back to the postrouting command at the beginning. we have eth0 and 10.6.4.0/22 on the same line. Is that is that intentional?

“You will want to change 2001:19f0:6001:01a6::/64 to the IPv6 /64 address prefix of your gateway.”
Are these in private IP space or public?

2

I agree, a diagram would be great.

Extrapolating from that KB article, 10.6.4.0 /22 is the Zerotier network - because on every ZT network I look at, the one that says (LAN) next to it is the Zerotier network. I don’t know why the default name of “(LAN)” is chosen - IMO if there is one thing that a ZT network is not, then that’s a LAN!

3

The point of that postrouting command:

-A POSTROUTING -o eth0 -s 10.6.4.0/22 -j SNAT --to- source 45.32.69.220
If the packet is leaving eth0 and has a source of 10.6.4.0/22, then NAT it to 45.32.69.220

4

Ok thanks. I’ve been poking and prodding at this for entire days now and I’ve learnt a lot but also have some weeks to go before I crack this one.

It looks like my ping requests are getting back to my VM. but they have the wrong destination address and are getting lost before they make it back to my local PC.

e.g.
172.28.133.118 = ZT IP on my local PC.
142.250.204.3 = google’s IP
10.0.0.4 = VM local IP.

ping request:

Nov 25 02:00:50 vm-gateway kernel: [68426.729543] [UFW AUDIT] IN=ztfp6ileyh OUT=eth0 MAC=4a:96:bb:32:05:ca:4a:46:77:fb:4d:64:08:00 SRC=172.28.133.118 DST=142.250.204.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=5284 DF PROTO=ICMP TYPE=8 CODE=0 ID=135 SEQ=5

ping response:

Nov 25 02:00:51 vm-gateway kernel: [68427.756034] [UFW AUDIT INVALID] IN=eth0 OUT= MAC=00:22:48:11:30:e7:12:34:56:78:9a:bc:08:00 SRC=142.250.204.3 DST=10.0.0.4 LEN=84 TOS=0x00 PREC=0x00 TTL=115 ID=0 PROTO=ICMP TYPE=0 CODE=0 ID=135 SEQ=6 
Nov 25 02:00:51 vm-gateway kernel: [68427.756041] [UFW BLOCK] IN=eth0 OUT= MAC=00:22:48:11:30:e7:12:34:56:78:9a:bc:08:00 SRC=142.250.204.3 DST=10.0.0.4 LEN=84 TOS=0x00 PREC=0x00 TTL=115 ID=0 PROTO=ICMP TYPE=0 CODE=0 ID=135 SEQ=6

I’m not sure what’s up with ipv6. From the VM I can see the ping requests from my local PC to google. But nothing at all back. So I’m probably closer to getting something working with ipv4.

5

Google are replying, so that’s good. I think you’re just missing the NAT element here, when Google’s replies get to 10.0.0.4 it should know from the NAT state table that the packet should be translated to 172.28.133.118 rather than being dropped as invalid.