ZeroTier: Gateway device?
-
@adam.ierymenko said:
@FATeknollogee Two ways:
-
Run ZeroTier on the device(s) themselves. Right now this varies in terms of do-ability, but we're planning more in the future here.
-
Bridge them with an auxiliary device.
Bridging is a subject that needs more documentation, but it's not terribly hard to do.
Let's say you have a ZeroTier network with the IPv4 subnet 10.10.10.0/24 and you have ten devices you want to bridge in.
The simplest thing would be to:
-
Edit the network's IP auto-assignment configuration and reduce the assignment range to reserve, say, everything above 200 for non-ZT devices.
-
Set up ZT on a Linux machine such as a Raspberry Pi or a Linux VM on your network. (If it's a VM, be sure the hypervisor allows bridging. Some like VMWare have a setting for this.) Designate this device as an "active bridge" at the network controller level, which means it's allowed to bridge other things in. (The active bridge setting also alters its behavior in terms of multicast a bit. Bridges use slightly more bandwidth since they see more multicast traffic.)
-
Create a Linux bridge device (instructions differ by Linux distro) br0 and add zt0 and eth0 (or wlan0, etc.) to it.
-
Assign your phones and other devices IPs like 10.10.10.201, 10.10.10.202 manually and attach them to the network that is bridged to ZeroTier via the ZT bridge you configured above.
ZeroTier emulates L2 Ethernet, so what you've done is created a single Ethernet network consisting of a physical wired or WiFi network bridged to a virtual ZeroTier network by a bridge device. The bridge device "glues" them together, passing packets back and forth and such. Linux's bridging driver is very good and handles a lot of edge cases like MTU mismatch, etc., and we've found that it works pretty good in practice.
Now a ZT device with IP 10.10.10.100 should be able to ping 10.10.10.201, etc.
Raspberry Pi's work great for this kind of thing. They're great for cheap DIY low-power network devices like bridges, routers, NAS boxes (connect a USB drive), etc.
Thank you
This is the kind of instructions I had been looking for. runs off to try it -
-
@adam.ierymenko Thanks!
-
I got my setup ALMOST working... It would seem that despite enabling proxy arp and other things, that I cannot get both halves of the ethernet segment to talk...
IP Subnet: 192.168.100.0/24
192.168.100.1-199 (HOME)
13 (ZTGateway, Linux, Bridged)-----------------------CLOUD---------------------------192.166.100.201 (REMOTE MACHINE, Linux)I am able to ping the bridged IP, but I am unable to ping anything behind it. I did enable IP_FORWARD, but that did not help. I also tried enabling net.ipv4.proxy_arp but that also did not help.
@adam-ierymenko Is there any of your user base that could help with this? I'd be happy to post it over on the Github thread if you would rather me post it there.
-
We have our own community site at https://www.zerotier.com/community/
I'd look into bridging options in Linux. I don't remember off the top of my head, but I know it has some options around enabling bridging and bridge behavior. There's several.
Does tcpdump on the remote end show you anything?
-
@adam.ierymenko said:
We have our own community site at https://www.zerotier.com/community/
I'd look into bridging options in Linux. I don't remember off the top of my head, but I know it has some options around enabling bridging and bridge behavior. There's several.
Does tcpdump on the remote end show you anything?
I'll go and pester that community for a bit.
tcpdump on the bridge shows the packets are being received by the bridge, but it's not doing the proxy arp.
-
@dafyre It shouldn't really have to proxy arp in theory. The arps should cross the bridge and "just work." I could see proxy arp making things more reliable though.
-
@dafyre Maybe proxy arp is actually in the way.
-
It is possible. I just checked in the community and noticed something in the build that somebody else did. They had a separate management interface.
My system currently has only 1 ethernet interface and the zt0 interface... Time for more testing, lol.
