DHCP and DHCPv6 support (and discussion)

[adamierymenko]

Right now ZeroTier networks can use DHCP, but it requires a lot of manual config and few people use it. ZeroTier's internal IP management is simpler but obviously a lot more limited than a full-blown DHCP server.

Properly supporting DHCP is complex and will probably require that we write (or adapt) a DHCP filter/parser or possibly even a full blown DHCP client.

Some of the issues are:

1. DHCP is absolutely NOT secure if accepted from an un-trusted source. Joining a network should NOT engage DHCP on the interface by default, ever, without the user approving it. Right now ZT explicitly turns DHCP client functionality off to prevent this. DHCP can be used to push all kinds of config to clients which many will blindly accept-- everything from DNS to Windows domain info to routes.
2. We're currently working on #178 ("full tunnel" in VPN parlance) to allow ZeroTier networks to easily be assigned default gateway status without disrupting ZT P2P traffic. This is also dangerous, so we will not permit a network to set a default gateway without explicit user approval. Otherwise randomly joining a network would allow that network to grab and redirect all your traffic. If DHCP is supported we will have to merge these two functions somehow since extra steps are required to support default gateway, such as by sniffing DHCP and engaging our default gateway trap door routes when DHCP pushes a default gateway. Fun fun fun.
3. It might be useful to users to support a "safe mode" DHCP. This would use a built-in DHCP client instead of your OS'es and would only allow the setting of interface IPs. All other DHCP options would be ignored. This would let you join and get an IP on DHCP managed networks without letting them reconfigure your entire networking environment.

This is kind of a big ticket and is dependent on #178. We will do default gateway / full tunnel first, probably in 1.1.6, and then do this at some point in the future.

One final DHCP issue:

DHCP hosts should be flagged as Ethernet bridges even if they don't bridge anything. In addition to being a permission (for security reasons), the Ethernet bridge flag exempts hosts from the multicast limit. On large networks DHCP could start failing if the number of clients exceeds the multicast limit, but if the DHCP server is flagged as a bridge this won't happen. This is a UI issue on the controller and a documentation issue but I wanted to mention it here.

[ehmry]

Could a simple DHCP server be embedded in the ZeroTier virtual interface? I don't think it would be too much work to intercept DHCP requests, but for IPv6 it might mean implementing both DHCPv6 and router advertisement.

[adamierymenko]

@ehmry I just came here to post exactly your idea. 😄

The idea would be to embed a tiny DHCP server in the core. It could either delegate to another DHCP server if configured to do so (at network level) or could serve DHCP requests and reply with ZeroTier-assigned network info. In either case it could sanitize DHCP data according to whatever security settings were/are selected and would not permit "strange" fields unless configured to pass them.

This would also make DHCP work better. Networks could configure certain members as designated DHCP servers, meaning that DHCP would traverse the network as unicast and not multicast. (This can be done with rules too but this idea has other benefits.)

[ehmry]

I decided that it was safer to use some sort of platform specific IP config in my first use-case, but with things like VMs DHCP cuts out a lot of the hassle.

[amosbird]

Is it going to benefit PXE installation of virtual machines?

[dharrigan]

@adamierymenko now that OPNsense has initial zerotier support via a plugin, the DHCP server on OPNsense works great with the configured zerotier networks. I would welcome the ability to delegate the proposed built-in dhcp server on zerotier to the one on the router, or even the possibility to turn it off.

BTW, I've a report of OSPF working over Zerotier as well :)

-=david=-

[Lillecarl]

@adamierymenko Could we not just add a box here that enables DHCP? Also add allow and disallow on Network level too? Maybe we could also in the WebUI add an option on clients to specify which are allowed to respond to DHCP requests, so that people can't join and rogue.

I guess it could be solved with the rules engine, but that's too complicated for people to use, people like checkboxes ;)

The above approach is sane in my opinion, it'd help in a setup like this: My ZT Edge / Raspberry Pi i installed at a customers site (bridged), who has a firewall which i do not have access to (so i can't change DHCP span to free addresses for ZT IP Assigner). Then i'd just want my clients which connect to the bridged ZT network to get an IP from the firewall onsite.

If you're going with "It might be useful to users to support a "safe mode" DHCP" then it'd be nice if there was a config array where i could enter which DHCP options i want to passthrough, where IP is enabled by default.

[dch]

I'm interested to know what the use case here is - what is missing from the current setup where IPs are pushed down to zt, that people want to use DHCP somehow in preference? DNS is one obvious setting, but perhaps there are other ways to achieve that.

[paulp]

@dch See the comments on #360 for more details.

[Lillecarl]

@dch When bridging ZeroTier clients into a network where you're not the admin of the DHCP server it's hard to change the DHCP span, so the ZT IP pool will eventually collide with onsite DHCP server.

And DHCP has all those insecure things that we might wanna use like pushing routes, ntp, dns etc...

[CStaveRun]

Interesting and good to know -- I can verify that DHCP requests will be answered, the tricky bit is triggering the request. Since I really only want to push DNS information, it is likely just as easy to set that rather than implementing a DHCP mechanism.

[Lillecarl]

@CStaveRun It seems like @adamierymenko is trying to find a solution that'll make the most people happy. I'd say there could be different options, one is to plain enable DHCP, and another one to just push DNS settings from ZeroTier central.

I'm a fan of DHCP, it's useful for many things to keep your network nice and tidy, pushing the same NTP server to everyone, including stupid printers etc...

[CStaveRun]

For anyone who might find this page and want a quick-and-dirty works-for-some-uses "solution" to adding DNS--

If you're using Zerotier as the default route, and you happen to be using OPNSense as your gateway device, you can forward any port 53 traffic over to the DNS server you want to use (standard warnings apply, serving suggestion only, not recommended in all cases, ask your network engineer if captive dns is right for you.)

I like this because it requires no userland intervention.

[gregory-fitz]

I agree with @Lillecarl Right now I use zerotier to bridge into a LAN. I have to renew IPs manually every time a host connects and windows does not make this easy. There should be a configuration option to allow dhcp. I agree that it should be off by default and maybe hidden away (i.e. not in gui but set via json).

[rcmcdonald91]

Any updates? Going on 3 years now.

[rcmcdonald91]

Sorry for stepping on toes but marketing ZeroTier as "delivers the capabilities of VPNs, SDN, and SD-WAN with a single system" is terribly misleading without proper support for DHCP and configuring DNS on clients. Things like Active Directory won't work without some pretty extensive manual client-side configuration...which obviously isn't ideal for your average John Doe VPN user

[blalor]

Right now ZeroTier networks can use DHCP, but it requires a lot of manual config and few people use it.

How does one do this?

[marshalleq]

For anyone who might find this page and want a quick-and-dirty works-for-some-uses "solution" to adding DNS--

If you're using Zerotier as the default route, and you happen to be using OPNSense as your gateway device, you can forward any port 53 traffic over to the DNS server you want to use (standard warnings apply, serving suggestion only, not recommended in all cases, ask your network engineer if captive dns is right for you.)

I like this because it requires no userland intervention.

Would be great to have a pointer how to do this...

[dimkasta]

There's no need for a split-brain dns or anything. A simple dnsmasq-like service on the zt client would be enough.

1) Define names for each connected client on the web interface 2) Upon connection to the vpn, the client starts a local dns server like dnsmasq and configures it to respond for the name entries. 3) For everything else, the pre-existing dns server of the machine is registered as upstream. This way everything not found in the zt dns is forwarded to the client-network's dns servers.

[andrewgdotcom]

A simple dnsmasq-like service on the zt client would be enough.

This is only practical for small numbers of homogeneous clients. I have ZT installed on my iPhone, how do I install dnsmasq there?

[Lillecarl]

A simple dnsmasq-like service on the zt client would be enough.

This is only practical for small numbers of homogeneous clients. I have ZT installed on my iPhone, how do I install dnsmasq there?

You misunderstood the point, he meant to replicate the basic behaviour of dnsmasq, as in make the ZT client a recursive forwarder that first forwards the dns request over ZT, if an nx is received, use the dhcp advertised dns server, or the other way around.

[andrewgdotcom]

You misunderstood the point, he meant to replicate the basic behaviour of dnsmasq, as in make the ZT client a recursive forwarder that first forwards the dns request over ZT, if an nx is received, use the dhcp advertised dns server, or the other way around.

I don't see the point in reinventing the wheel. DHCP is a standard protocol, everything else is the OS's business.

[marshalleq]

It's not reinventing the wheel, it's just standard DNS. Anyway, I stopped using ZeroTier - it's pointless without proper DNS capability for most use cases, which you can't assign without a functioning DHCP.

[paulp]

It's not reinventing the wheel, it's just standard DNS. Anyway, I stopped using ZeroTier - it's pointless without proper DNS capability for most use cases, which you can't assign without a functioning DHCP.

I was made aware recently that at some point it became possible to set custom DNS servers directly on the IOS client. The option wasn't there until I removed my zerotier network and added it back in again. Apparently it has been in there for years (!) but as far as I can see has not been mentioned in this ticket.

I realize this is not quite DHCP, but it does enable scenarios which were not possible without it.

[marshalleq]

I tried all of that, but it didn't work. Ultimately it's challenging connecting up multiple DNS servers that don't know about each other.

[rudiservo]

Correct me if I am wrong in terms of DHCP security I think that this is not a problem and there is either an over reaction or complete lack of knowledge.

lets start with the obvious, if we want Zerotier as a better alternative to any VPN, we need DNS and DHCP.

Other one is we have flow rules that in theory can block or allow UDP port 68 or 67 from a certain device, this is where the security is implemented, so there is really no issue. Only issue they have to solve is the multicast limmit, and the ability to ignore zerotier routes if the device is inside the network.

So to the Zerotier team, this is a spectacular project, I mean I love how easy it is and it's concept, but it is handicapped and limits sysadmins in general to use effectively and widely inside organizations.

[NigelColtellaIT]

I find myself here also after testing out ZeroTier and felt I had found an amazing solution for the companies I support but the fact users can only connect to company servers using IP addresses OR that we have to use a publicly accessible DNS server with a FQDN means we expose our internet IP ranges to anyone who wants to view. For me just the ability to have a couple of DNS servers configured on the client at the same time as the auto-allocation of an IP address would resolve this.

[blaggacao]

Her's what I did (with search domain):

resolvectl status ztnfaasznt 
Link 4 (ztnfaasznt)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.194.54
         DNS Servers: 192.168.194.54
                      192.168.194.121
          DNS Domain: xoe.cloud

systemd-resolved gives priority to the search domain (xoe.cloud) and looks it up on the DNS servers that run in the zt network (if connected)...

Here is the problem:

• I've no idea how to set this up on an android device
• I've no idea how to explain this to a technical analphabet (on an android device)

It would be nice if a DHCP like feautre could communicate just those few parts:

• DNS Servers
• DNS Search Domain

Edit: I also tried delegate a subdmoain with an NS record on clouflare to a private IP, but that didn't work either, for some reason.

[magikmw]

Since there doesn't seem to be any interest from devs to take care of this, I've planned a switch to Wireguard for my usecase, especially with the mainline kernel adopting it.

[memorycradle]

Since there doesn't seem to be any interest from devs to take care of this, I've planned a switch to Wireguard for my usecase, especially with the mainline kernel adopting it.

Along with the rest of us unfortunately, this has so much promise, but such a little thing makes it pointless to use for anything real.

[laduke]

@blaggacao, on android, for now, when you're first adding a network, you can manually specify dns server addresses.

public DNS not working is sometimes a router checkbox "Discard upstream RFC1918 responses" / "Rebind protection"

[RobinBeismann]

I agree, this is a hardly required feature for endpoints, in times of SSL and even internal SSL and for the the sake of usability, DNS is a must have.

[blaggacao]

@adamierymenko

While in an ideal world, peers using a peer to peer VPN would be just that peers: people of equal rights, knowledge, care and ethics.

In a real world, mostly, knowledge and care are completely transferred to a primus inter pares (a.k.a sysadmin) which the peers (more often than not: completely) entrust with knowledgability and care.

If you join a network, in a broader societarian sense, you always join a scope of rulesets, too (a.k.a. with metadata attached).

So the true choice is: does one peer trust the primus inter pares through the act of joining? And why should one trust him more or less than the ISP (which does the same thing, and worse)?

The primus inter pares in turn is made responsible, too. Any failure mode scenario is socially blamed on him, because he was entiteled the one with knowledge and trust (and therefore expectations) by the peers.

Now add the fact, that some peers don't even speak english. This renders all considerations irrelevant, because it renders them no sovereign peers any more: they can only blindly trust.

Based on those consideratios, I think jt's time to implememt the DHCP protocol on the client side with an "more-than-zero-trust" feature flag. Or better a separate command, to make it intellectually different from joining:

# cli ux proposal
zerotier-cli join <>
zerotier-cli trust dhcp dhcp6 <>
zerotier-cli untrust dhcp dhcp6 <>

And for the purity of the argument of preserving the true peer's sovereignty, this feature flag must be translated in all the world's languages. Ok that latter aspect is unbalanced and unfeasible.

[kjkent]

As it's been over two years since the last activity on this issue, this is just an interest check to see if there's any behind-the-scenes activity on enabling DHCP traffic over ZeroTier, as I'm trying to decide whether it's a viable option for my organisation.

I've read the existing comments, and FWIW, I agree that it's important to ensure high levels of network security, but, when joining any other network, isn't it the case that the user accepts a certain amount of auto-configuration, or disables the auto-config client-side?

Many thanks.

[someara]

Hello! It's definitely possible... I managed to PXE boot a Virtualbox VM from a DHCP server hosted on AWS last year. I believe the trick was to Allow Ethernet Bridging on both interfaces involved

[someara]

Also, having wide open flow rules and a packer sniffer helped

[kjkent]

@someara fastest issue response in the west :gun: :sunglasses: many thanks.