Repository: zerotier/ZeroTierOne

Issue #142: IP address conflict resolution
Created: 2015-01-15T01:11:30Z
What happens if you're on network A and you join network B, which has a conflicting IP range? Current thought:
(1) The newer network should be temporarily disabled with an error: IP conflict.
(2) It should offer an option to resolve this error by instituting local NAT to an IP range that does not conflict. This would be bidirectional static NAT, so it would not interfere with connectivity in either direction to/from other hosts on the network.
This is less of an issue with uses like cloud backplanes, etc. But one goal for this project is to be able to join networks and use them almost like chat rooms, and I could see this coming up there more often. Adding to backlog since I was reminded of this by a conversation with a customer.

Duplicate issue #650: Multiple overlapping networks on MacOS: no connection
Created: 2017-12-22T12:59:41Z
Workstation running:
MacOS Sierra 10.2.6
Zerotier One 1.2.4
Problem:
My client has joined two networks, alan_servers (93afae596390704d) with 10.147.18.0/24 managed route, and  alan_work_clients (93afae5963e20f16) with 10.147.19.0/24 and 10.147.18.0/24 managed routes. (you may immediately spot the issue, I didn't)
10.147.18.64 is an online remote host on alan_servers. If the only connected network (check in the zt client) is alan_servers, this is usually ok:
Alanmbpro:~ alan$ ifconfig zt0
ifconfig: interface zt0 does not exist
Alanmbpro:~ alan$ ifconfig zt1
zt1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 5000 mtu 2800
	ether 4e:52:e3:04:49:1a
	inet 10.147.18.213 netmask 0xffffff00 broadcast 10.147.18.255
	inet6 fe80::4c52:e3ff:fe04:491a%zt1 prefixlen 64 scopeid 0xa
	inet6 fcf0:3fde:1422:7367:10b4::1 prefixlen 40
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
	open (pid 40681)
Alanmbpro:~ alan$ route get 10.147.18.64
   route to: 10.147.18.64
destination: 10.147.18.0
       mask: 255.255.255.0
  interface: zt1
      flags: <UP,DONE,CLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      2800        -8
Alanmbpro:~ alan$ ping 10.147.18.64
PING 10.147.18.64 (10.147.18.64): 56 data bytes
64 bytes from 10.147.18.64: icmp_seq=0 ttl=64 time=58.351 ms
^C
--- 10.147.18.64 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 58.351/58.351/58.351/0.000 ms

Now, if I enable the alan_work_clients network:
Alanmbpro:~ alan$ ifconfig zt0
zt0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 5000 mtu 2800
	ether 16:2d:91:04:49:1a
	inet 10.147.19.213 netmask 0xffffff00 broadcast 10.147.19.255
	inet6 fe80::142d:91ff:fe04:491a%zt0 prefixlen 64 scopeid 0xb
	inet6 fcf0:4da1:4f22:7367:10b4::1 prefixlen 40
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
	open (pid 40681)
Alanmbpro:~ alan$ ifconfig zt1
zt1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 5000 mtu 2800
	ether 4e:52:e3:04:49:1a
	inet 10.147.18.213 netmask 0xffffff00 broadcast 10.147.18.255
	inet6 fe80::4c52:e3ff:fe04:491a%zt1 prefixlen 64 scopeid 0xa
	inet6 fcf0:3fde:1422:7367:10b4::1 prefixlen 40
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
	open (pid 40681)
Alanmbpro:~ alan$ route get 10.147.18.64
   route to: 10.147.18.64
destination: 10.147.18.64
  interface: zt0
      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      2800       -21
Alanmbpro:~ alan$ ping 10.147.18.64
PING 10.147.18.64 (10.147.18.64): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
--- 10.147.18.64 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

The problem seems to be that nothing prevented me from joining networks with overlapping ip addresses; and that SOMETIMES the network would work (I think it's a matter of which is started before or later); i think this is quite an easy mistake to do, and any kind of alert would be appreciated!
Thanks for your great piece of software.

Closing comment (2018-01-09T16:51:26Z): Closing since it's a dupe of #142 and because IPv4 address space is too small, making this problem basically unavoidable in practice.