We have a new client with as misconfigured network as they are using 192.1.1.1 / 24 for their internal network. Migrating them to a non-routable network will prove challenging due to time constraints. Despite multiple efforts we are unable to make zerotier talk to end point devices on the remote nodes when using this network using a Dream Machine SE. We also tried using opensense to rule out any squirliness with regard to the Dream Machine. In both cases, if we change the network to a non-routable network, ([192.168.42.0/24]) it works without issue. Our assumption was that ZT or opensense recognizes that it is routable and routes to the actual public network. However, when we installed Zerotier client on a device using the 192.1.1.1 network it works, and likewise the Dream Machine routes using the 192.1 network without ZT.
We have tried using Vlans between the two networks using a router to speak between the [192.1.1.1] network and a 192.168.x.x network. The two networks communicate with each other. We assigned a static route form the [192.1.1.1]) network when calling to a remote endpoint to use the 192.1168.42.0 network which has ZT installed on the same network. We tried a bridge router, but all without success. Any guidance as to what we are doing wrong or what we should do differently would be appreciated.
Well, that’s somewhat of a dilemma you or rather the customer is in because 192.1.1/24 is part of a public network owned by Raytheon BBN Technologies in the US that owns the entire 192.1/16 subnet.
I suspect that you have already informed the customer of this rather serious situation which should be corrected as soon as possible. But in the meantime, you can use an interim solution:
add 192.168.42/24 to the main router to run in parallel with 192.1.1/24 on the same network.
add static ip addresses from 192.168.42/24 to the clients you need to access. These clients will now have two addresses, one for each network. Configure ZeroTier to use only 192.168.42/24.
When there is time, you may continue to add 192.168.42/24 addresses until you are able to uninstall the entire 192.1.1/24 network.
Thank you for your thoughts. Yes we had considered that approach. Ultimately this came down to a routing issue which in retrospect seems obvious. Using a packet sniffer we determined that packets were being sent out to the remote end, but upon return the router on the remote end was doing what it was supposed to do, which was to funnel internet traffic to the appropriate destination. Entering in the static route at the remote router to redirect the 192.1.1.0/24 traffic back to ZT, solved the issue.