ZeroTier: Gateway device?
-
I think right now, that will be the only way. One idea is the possibility of telling ZT that you will manage your own IP addresses, and then setting up a DHCP server on the ZeroTier interface. I tested this and had fair results with it on my home network. The only issue was at the time I tested this, Android clients did not execute a DHCP request over the ZT interface, and they would not work, unfortunately.
Spin up a Linux VM, and enable ip forwarding, and install ISC's dhcp server, and install ZT on that same VM. Set the DHCP-Server to listen on the ZT interface and allow it to give out static routes to the ZT clients.
The only gotcha is that your routers on the network that you are connecting to will need to know how to talk back to your ZT network...So... Let's assume...
CORP Network: 172.16.1.0/24 (172.16.1.1-254).
CORP Router: 172.167.1.1
ZT Gateway CORP : 172.16.1.50ZT Network 192.168.100.0/24 (192.168.100.1-254, IP addresses are given via DHCP using 192.168.100.100-250)
ZT Gateway CORP Network: 172.16.1.50
ZT Gateway ZT : 192.168.100.1
ZT Laptop: 192.168.100.138 (assigned via DHCP)In order to get traffic from CORP network to the 192.168.100.0/24 ZT Network, you would have to add a route on the CORP Router...
(dest network) (gateway)
ip route 192.168.100.0/24 172.16.1.50 (that is an HP-ish syntax).That would provide every device in your corporate network a way to communicate with devices on the ZeroTier network.
In the ZT Gateway's DHCP settings, you would set a default route of 192.168.100.1, effectively turning your ZT Gateway (and DHCP Server) into a router.
You can then add other static routes at the ZT Gateway and allow it to foward traffic to multiple sites instead of just HQ.
Clear as mud?
Edit: Dang -- @Dashrender beat me to it.
-
@dafyre Yep, clear as mud
Y'all will need to "dumb" this down.
Spinning up a VM is out of the question -
@FATeknollogee Do you have an an existing Linux server that can do it?
-
@dafyre Nope.
What if I need to put a phone or some similar device at a remote location ?
-
@FATeknollogee You will need to buy a ZT gateway appliance to install at the edge of the network.
Currently I think @coliver was working on getting an Ubiquiti ERL to have ZT installed on it directly, but he's run into a snag.
-
@Dashrender said:
Currently I think @olivier was working on getting an Ubiquiti ERL to have ZT installed on it directly, but he's run into a snag.
Xen Orchestra was working on that?
-
@FATeknollogee said:
@dafyre Nope.
What if I need to put a phone or some similar device at a remote location ?
You put a gateway in front of it.
-
@scottalanmiller said:
@FATeknollogee said:
@dafyre Nope.
What if I need to put a phone or some similar device at a remote location ?
You put a gateway in front of it.
Yepp. You could even have the ZT Gateway act as a DHCP Server for the LOCAL network as well, if it is necessary... Just one more config block.
-
I should have mentioned earlier though, you only NEED one DHCP server on the ZT Network if you are going to do that.
-
@scottalanmiller said:
@FATeknollogee said:
@dafyre Nope.
What if I need to put a phone or some similar device at a remote location ?
You put a gateway in front of it.
Where is this gateway device everyone keeps talking about?
No spinning up a VM -
@scottalanmiller said:
@Dashrender said:
Currently I think @olivier was working on getting an Ubiquiti ERL to have ZT installed on it directly, but he's run into a snag.
Xen Orchestra was working on that?
whoops.. wrong person.
@scottalanmiller said:
@Dashrender said:
Currently I think @olivier was working on getting an Ubiquiti ERL to have ZT installed on it directly, but he's run into a snag.
Xen Orchestra was working on that?
Whoops - wrong person.. I meant @coliver - I think it was him. It was whoever couldn't compile the MIPS version because he couldn't get make onto the ERL.
-
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@dafyre Nope.
What if I need to put a phone or some similar device at a remote location ?
You put a gateway in front of it.
Where is this gateway device everyone keeps talking about?
No spinning up a VMthere is no such device today that I'm aware of, you have to build it yourself.
-
In theory a Raspberry Pi 2 would work very well for that.
-
@scottalanmiller said:
In theory a Raspberry Pi 2 would work very well for that.
+1
I said the same thing in another thread. I think it's perfect for this purpose (in theory).
-
@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.
-
-
@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.
