<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-source45.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?
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!
-A POSTROUTING -o eth0 -s 10.6.4.0/22-j SNAT --to-source45.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
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.
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.
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.