Posts made by adam.ierymenko

That is entirely possible. Ideas in progress.

In the short term I'm not sure what to do, but priority seems like part of the answer.

Basically it's virtual redundant multipath ethernet. If you've ever used network bonding, you can set two interfaces to connect to two different switches such that if one switch fails the second link takes over and traffic is not interrupted. This would be the same thing but with a virtual network as failover path.

This discussion is helpful toward a product idea we've had for a long time: a very simple device that can be plugged into a physical network and will "extend" it. Basically you plug in this device and it creates a virtual ZeroTier network that you join on endpoint devices. The missing piece for us has been "what then?" How should IPs be assigned on this virtual network and what should endpoint devices do with those IPs? I think this is giving me some ideas, and they're very very interesting. Short answer: "no IPs should be assigned" and "the virtual network should shadow the physical and only be used if the physical is not available."

@Dashrender Can you go up a level and out of the realm of technical details and explain what you're actually attempting to accomplish? Is this a road warrior use case or something else like inter-site collaboration?

@Dashrender Yes, I can see issues as well. Unfortunately I can't see a clean solution that doesn't involve either changing the layout of things or some form of client-side hackery. But I want to think about this a bit longer.

On further thought, I wonder if it would work if ZT were given the same IP scheme as the main network, but were set to a lower priority on all machines. Then it would be used as an alternate path and only if the main network were not available.

This might be something we'd want to officially support: "shadow network" use case?

@Dashrender

"Upon further consideration I also realized that I don't want to remove the ZT IP from DNS, because then my ZT client would no longer be able to use DNS to find DC2."

Oh my. The horror. Let me check my understanding. What you want (ideally) is:

(1) Clients on the regular network get regular network addresses when they resolve things, especially the DCs.

(2) Clients on the ZeroTier network get ZeroTier network addresses when they resolve things, especially the DCs.

... but DNS and AD were not designed for multi-path or multi-network use.

I think I might understand Pertino's hack now. They hacked multipath into DNS by rewriting DNS queries or responses based on which networks you belong to. (???)

If this were a greenfield deployment I'd suggest using ZeroTier as the company LAN and binding AD only to that. This is what we'd call the "fully virtualized network." We have some distributed teams doing that and it works fine, though they had to do a bit of hackery to coax AD into preferring the ZT interface.

Here's an idea, though we have not tried this:

Don't run ZeroTier on the domain controllers. Instead, set up a Linux VM and bridge the DC's network to the ZeroTier network. Then set up the ZT network to assign IPs within the main network's range but in a region that will not be handed out on the main network by its DHCP servers. Now when clients join ZT they get another main network IP address and from the perspective of any clients on the main network they now have two connections to it. It looks as if they have two network cards with two cables plugged into the same switch (which is legal, and each will get a different IP).

Then set the physical interface to higher priority on the clients. When connected to the LAN, clients will go over that. When off-site, clients will go through ZT.

Now you no longer have two address spaces, so DNS will just have one IP.

@scottalanmiller I wonder then: why all the DNS magic if the issue can be solved by simply setting connection priority? Or did the under the hood DNS magic solve a different issue?

??? Could this perhaps be helpful?

https://support.microsoft.com/en-us/kb/2526067

Root of the problem is that none of these protocols (DNS, AD, DHCP, etc.) were designed for a world in which a client can belong to more than one network.

Hmm... so the question is: how does Windows determine a priority list for adapters and which one is 'default?' Answering that question seems more elegant than highjacking DNS.

Hmm... so perhaps the problem is that the AD client is enumerating its addresses and choosing the wrong one. If so, I think the thing to do would be to look into Windows' logic for choosing the "primary" interface and/or AD's logic for choosing which IP address(es) reported by clients to name as their primary.

You would think Windows would be smart enough to set AD DNS to IPs within the IP block managed by AD, but that probably assumes too much.

@colliver How are these DNS records "learned?" What is the mechanism? Does the client computer enumerate its interface addresses to AD, or does AD learn them by listening to the network?

Also in the scenario described above:

(1) Is the desire to use the ZeroTier network as the main "company LAN" and run AD over that?

(2) Or is the desire to use ZeroTier for other purposes and keep the main company LAN from getting polluted by its addresses?

These are obviously different use cases. I imagine #1 might actually be easier than #2, but that's a greenfield approach.

@dafyre Well here I am! (Author/founder of ZeroTier)

Reading the above, it seems the issue is active directory DNS. While I know tons about networking, I am not unfortunately an AD expert.

Pertino it seems highjacks DNS. This stuff is in the category of things we want to avoid-- ugly, nasty hacks that fix one thing but likely break everything else. This "enterprise" approach is how Windows networking got in such a bad state to begin with -- in digging into Windows one can see how this or that hack was put in place to make this or that work in an "enterprise" environment, and each hack results in a fractal explosion of edge cases that in turn demand more and more ugly hacks, and so on, until the entire thing becomes the ridiculous ball of garbage that it is today.

But in some cases we have simply been forced to do it. In all such cases we've tried to build such hacks as far from the ZeroTier core as possible. Here's one from WindowsEthernetTap:

https://github.com/zerotier/ZeroTierOne/blob/master/osdep/WindowsEthernetTap.cpp#L902

So let me explain my understanding of this Windows AD DNS issue:

Windows AD DNS likes to automatically register DNS entries for all adapters in the system. When ZT adapters are added, these can collide with, override, or pollute the DNS space with undesired entries. Is this the problem?

If not, can someone explain the issue in a bit more detail? What precisely is going on under the hood? Maybe we can figure out and document a fix that's more elegant.