<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.
I ended up focusing on the NAT part and discovered there were loads of forwarding rules under the postrouting chain in iptables
sudo iptables -t nat -L -v
As if it was recording every permutation I had ever tried.
I was also wondering why my ping requests to 10.0.0.4 from my local PC had double the ping compared to ping request from my local PC to the ZT IP on the VM.
turns out ufw appends the rules every time it’s reloaded or stopped/started. What I needed to do was add a -F above the first -A in /etc/ufw/before.rules to flush out the existing ones.
I guess it was firing traffic all over the place and getting confused.
so the ipv4 side is working now but only if I either MASQUERADE or SNAT to 10.0.0.4 not the public IP as the article suggests.
I’ll have to come back to ipv6 another time maybe next year. Interesting times - I’ve never really had to chase packets around a network before. TBH I’ve never even had to understand iptables since I’ve always been able to get away with google + copy n paste.
FYI I’m pretty sure this is a typo in the KB article -A FORWARD -i eth0 -s 0.0.0.0/0-d 10.6.4.0/0-j ACCEPT
it should be -A FORWARD -i eth0 -s 0.0.0.0/0-d 10.6.4.0/22-j ACCEPT