Default route / full tunel trouble

Hey all,

I’ve read through this:

<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 -j SNAT --to- source
“Our net is”. What is “our net” referring to? is that our LAN (non zerotier) or is it our zerotier network?

-A FORWARD -i zt+ -s -d /0 -j ACCEPT
-A FORWARD -i eth0 -s /0 -d -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 Is that intentional?

“Log into ZeroTier Central and add a route to via the IP address of your new virtual edge router”
“On our net is our network and is our virtual edge router’s internal IP address (internal to the ZeroTier network)”
Ok working backwards, the subnet probably includes ip and we know thats a zt ip address. we also know LAN and ZT subsets shouldn’t overlap. So i’m going to assume is in fact a zerotier subnet. But then going back to the postrouting command at the beginning. we have eth0 and 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?

I agree, a diagram would be great.

Extrapolating from that KB article, /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!

The point of that postrouting command:

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

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. = ZT IP on my local PC. = google’s IP = 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= DST= 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= DST= 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= DST= 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.

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

Well it makes sense when you say it like that.

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 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 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 -d -j ACCEPT
it should be
-A FORWARD -i eth0 -s /0 -d -j ACCEPT

It works either way but just saying.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.