Is this routing setup correct?

Hi. My zt network has two geographically separated OpenWrt routers. The LANs are 192.168.1.0 (…196.1) and 192.168.2.0 (…196.111). Both have bridging enabled on the controller:

blarg

The 192.168.196.150 address is a cloud instance that does route override.

Is this the correct routing setup? Are the routes actually necessary, considering NAT already done by openwrt when udb port 9993 is correctly forwarded?

The docs say “additional setup needed on device” - presumably OpenWrt doesnt need any additional setup beyond the firewall zones/device settings, as it already has ip forwarding enabled…

Without knowing the specifics of your network, that looks fine.

It doesn’t look like you’re doing any bridging (stretching Layer2 between sites), you appear to only be doing routing (route between subnets at different site).

The routes will be necessary to talk between sites. UDP/9993 is part of the underlay. It is what is used to bring up the ZeroTier network, so it’ll be separate from all of your overlay routes (192.168.1.0/24, 192.168.2.0/24, 192.168.196.0/24).

The main additional setup on OpenWRT will be the firewall stuff you mentioned. The only additional thing you may need to do is allow the use of the default if/when needed. You would just do that when SSH’ed into one of your routers: Here’s the command (insert your networkID):

sudo zerotier-cli set <networkId> allowDefault=1

1 Like

Thank you! But wait! Im unable to set a route of 192.168.1.0/23 - it always reverts to 192.168.0.0/23. If i set a netmask of 24, it stays .1.0/24:

222

Whats with that?

About topology, its simple:

Home 1 LAN — Internet — Home 2 LAN

All zt network devices have a client installed - should i disable bridging on the routers?

I guess i dont understand how bridging makes devices without a client work through zerotier…

Based on your setup, you can remove bridging on the routers (as well in ZT Central).

The 2 sites will talk like you would talk to something on the internet (evaluating the Layer3 destination IP hop by hop). Here’s a quick packet walk:

Let’s say you have a host (Host1) at site 1 with an IP of 192.168.0.100 that wants to talk to 192.168.2.100 (Host2) at site 2.

  • Host1 generates a packet with Source:192.168.0.100 / Destination:192.168.2.100
    • It looks how to get to 192.168.2.100; noticing it doesn’t have a direct route, so it follows its default gateway to OpenWRT1.
  • OpenWRT looks at the packet and looks at its routing table and sees it has a direct route to 192.168.2.0/23 (which would include 192.168.2.100), via 192.168.196.111, so it forwards that packet to OpenWRT2 that owns the 192.168.196.111.
  • OpenWRT2 looks at its routing table and sees that 192.168.2.0/23 is directly attached, so it sends an ARP message to its local LAN to see what MAC address owns 192.168.2.100, and once received will send the final packet down to 192.168.2.100.
  • The return from 192.168.2.100 to 192.168.0.100 will simply reverse the source/destination and send back over the reverse path.
1 Like

192.168.1.0/23 isn’t a valid subnet, since it falls in the middle of 192.168.0.0/23. It’s just correcting the route.

192.168.0.0/23 covers 192.168.0.0 to 192.168.1.255

If you wanted to cover 192.168.1.0-192.168.1.255, that would be 192.168.1.0/24

Another thing to add, if you SSH into your OpenWRT routers, you can run either of these commands to see the routing tables on those boxes (you can also see them in Luci, but I prefer to see them from Linux):

route -n
ip route show
1 Like

Is this the optimal way for them to talk in my situation? My goal is hosting some of my own moons as well…

Ive looked at the output from both routers and one (currently the “remote”) shows a route using the zt net.

The “local” router doesnt show a route to the remote however…

Yes, you’ve basically created a site-to-site VPN. If you wanted to have your own root servers, you’ll likely want to place them on the underlay, so how you do your site-to-site network won’t necessarily impact that.

Your routing tables should generally look like this (plus your other routes):

#############################################
root@Site1:# route -n
Kernel IP routing table
Destination     Gateway         Genmask      
192.168.0.0     0.0.0.0         255.255.254.0
192.168.2.0     192.168.196.111 255.255.254.0

#############################################
root@Site2:# route -n
Kernel IP routing table
Destination     Gateway         Genmask        
192.168.0.0     192.168.196.1   255.255.254.0   
192.168.2.0     0.0.0.0         255.255.254.0

If one of the remote routes is missing from one of the site routers, that usually means (from what I’ve seen), that ZeroTier sees something local that would be overlapping at the site (or the gateway under the ‘via’ section is incorrect).

It could also be that the node doesn’t currently allow managed routes. We can do something similar to what we did for the default:

sudo zerotier-cli set <networkId> allowManaged=1

You can see your current ‘set’ settings using this cli command:

zerotier-cli listnetworks -j
1 Like

That seems to have fixed it! Routes are appearing on both sides. Also zerotier-cli peers shows that all connections are direct whereas before there were two or three relay leafs.

I just had to reinstall this local router… Dont know what happened, possibly i made a mistake in building zt from source. The way it was set up before i always saw all direct connections.

Thank you very much for your guidance, ive learned some from this.

No problem, glad you were able to get everything squared away.

1 Like

I guess i spoke too soon. With that setup i wasnt able to see any of my windows shares on the remote LAN.

Ive added another two routes:

wefw

This seems to fix the problem of not seeing the shares. Not sure why…

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