Seeking Assistance with Zerotier Network Integration

Hello Zerotier Community,

I hope this message finds you well. I’m reaching out to seek assistance with integrating my Zerotier network (172.29.0.0/16) with my local LAN network (192.168.1.xxx/24) to enable seamless access to the Zerotier network from devices on the LAN without the need to install ZerotierOne software on each device.

Here are the steps I’ve taken so far:

  1. Added routes from 172.29.0.0/16 via 192.168.1.1 (the gateway on my LAN).
  2. Attempted to route through my Windows machine (192.168.1.5) by forwarding port 9993.

However, despite these efforts, I haven’t been able to achieve the desired integration. Additionally, I have an Ubuntu installation on VMware Workstation that I could potentially use as well.

I initially wanted to use a Routerboard RB433 to handle Zerotier, but since it’s a MIPS-based device and Zerotier isn’t supported, I’ve turned to my Windows desktop as my alternative solution.

I would greatly appreciate any guidance, insights, or suggestions from the community on how to successfully set up this integration, considering both my Windows machine and the Ubuntu installation on VMware Workstation as potential options.

If you need additional information or configuration details to better assist me, please don’t hesitate to ask.

Thank you in advance for your help.

Best regards,

What kind of device is 192.168.1.1? Does it support ZeroTier? If not, does it support static routing.

There seems to b a couple issues with your current logic, but I might just not have enough information to fully understand your topology.

1. Added routes from 172.29.0.0/16 via 192.168.1.1 (the gateway on my LAN).
I’m assuming this is in the ZeroTier Manage Routes section. Your ZeroTier network has no idea what 192.168.1.1 is, so this route won’t be useful for devices in your ZeroTier network. You want to tell devices on your ZeroTier network how to get to you 192.168.1.0/24. So the route in there should be something along the lines of: “192.168.1.0/24 via <some ZT IP that knows how to get to 192.168.1.0/24>”. If the device that has 192.168.1.1 supports ZeroTier, this will be easy. You just need the 192.168.1.0/24 route as a managed route and you’re good.

2. Attempted to route through my Windows machine (192.168.1.5) by forwarding port 9993.
This is ultimately unnecessary. When you’re talking on port 9993, this is part of the underlay of the network (ZT refers to this as VL1). Everything you’re trying to do is part of the overlay (ZT refers to this as VL2). Any time you try to access a webpage, or ping, or print to a network server via a ZT device, that is overlay traffic.

Getting your ZT network to know how to get to 192.168.1.0/24 is very easy; it’s as simple as the managed route I mentioned previously. Getting your LAN devices to understand how to get to your ZT devices is the harder part. If you can put ZT on your 192.168.1.1 device, then you don’t really need to do anything special. I’ll assume for this next part that you’re not able to do that.

Option 1:
For this your 192.168.1.1 device needs to support static routing. On that device, you’ll need to put a static route to 172.29.0.0/16 with a next hop of 192.168.1.5 (or whatever device you ultimately use to interconnect your LAN and ZT). In your managed routes, you’d have 192.168.1.0/24 via <the ZT IP on that 192.168.1.5 device>. For this, your path would be LAN Host → 192.168.1.1 → 192.168.1.5 → Remote ZT Device.

Option 2:
If that 192.168.1.1 device does not support either ZT or static routing, you can replace it with a device that does, and it’ll make your deployment easier

Option 3:
If you don’t want to purchase a new router, then you can solve this by bridging everything. For this, you’ll need to make your ZT network also within that 192.168.1.0/24 range, and bridging your ZT network, and the interface of the device where you’re hosting ZT. This can be on something like Windows, Ubuntu, or something else entirely (more on that in a little bit). For this, you will have to look at what the DHCP Scope on your 192.168.1.1 device is issuing. Most DHCP severs will assign an upper and lower limit of IPs that it will issue out. This is to leave room for static IPs if needed. You’d need to assign IPs to your ZT nodes from those reserved for static IPs. So your DHCP Server might issue .50-200 or something. So you can assign from .10-40 or something.

Device Selection:
You mentioned Windows and Ubuntu, but there’s free network appliances that are purpose built for routing between subnets. You may want to consider those as well. Some options would be VyOS, OpenWRT, pfSense…just to name a few

Hope all of that made sense.

Thank you for your detailed reply.

Most of it makes sense, I’m not the best when it comes to working with Networking, I appreciate your detailed response, and will try to respond in the best way I can. 192.168.1.1 is my main Router. It’s a TP Link Archer, and unfortunately doesn’t support Zerotier natively, and does have some form of static routing, but all attempts to set it up, it moans about “Gateway must be on the same subnet with the device interface’s IP address. Please input another one.” more on that later.

After going through your list of options, I decided that the best approach currently is option 3, but I can’t change my Zerotier network IP range due to the fact I have vital servers running, and to change the IP address range will mean hours of needing to reconfigure everything, so what I have done is change the 192.168.1.x range. I have told my main router to issue the IP address range of 172.29.1.110-172.29.255.254 - this is right in Zerotier’s range, and I bridged the two connections in my network settings. Both networks have the 255.255.0.0 subnet range.

I can now communicate with both networks from my desktop, which was 192.168.1.5, it’s now 179.29.100.115 Although when the bridge was created, it couldn’t get an IP address, and assigned a 169.254.x.x.x address, I gave the bridge interface 179.29.100.115

But when I tested pinging a Zerotier network on my laptop with Zerotier disconnected, requests are timing out.

It should be routing through the zerotier client running on 179.19.100.115.

With Pinging 172.29.232.160 with 32 bytes of data:
Reply from 172.29.1.113: Destination host unreachable.

What were you putting for the values of the static route? Looking at their config sections online, my guess is one of 2 things happened. 1.) You put something other than 192.168.1.5 as the gateway, or you put that as the gateway, and didn’t select the LAN interface.

I do recommend trying to get this working with L3 routing before deciding on bridging. Bridging will have more considerations and limitations later on, especially if deciding on expanding your network or adding redundancy.

If you still want to do bridging, it looks like ARP likely isn’t propagating (assuming 172.29.1.113 is the laptop you’re pinging from). We can see this because you’re getting Destination Host Unreachable from the host you’re pinging from. If ARP resolved, but the ping couldn’t get through, it would time out instead. This indicates that the bridging isn’t working correctly.

As a sanity check, let’s make sure you’ve done these things.

  1. For the 172.29.100.115 node, make sure you’ve enabled “Allow Ethernet Bridging” in the ZeroTier console (it’s also best to disable auto assigning IPs)
  2. Configure a bridge on the 172.29.100.115 host with both the physical interface, as well as ZT interface within it.

That’d be a basic bridge setup. If that is still not working, can yo ping 172.29.100.115 from your laptop with ZT disabled on the laptop?

Got it working - thank you so much for your assistance!

All that I needed to do was to configure my LAN and Zerotier to have the same IP range, and to be on the same subnet. Bridged the connection between Zerotier, and my LAN connection on my Windows 10 Desktop.

There was a registry setting I had to change * Run regedit.exe

  • Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
  • Change the entry IPEnableRouter REG_DWORD to 1
  • Reboot

and then I knew, communication between the two networks were working effortlessly.

Had a few minor hickups with IP addresses, but no need for port forwarding, routing, etc.

Awesome, glad you got it working!

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