3 ms·

> This is a very real problem when using a VPN I've been really careful about selecting virtual network IP spaces throughout due to this concern. The hardest

> This is a very real problem when using a VPN I've been really careful about selecting virtual network IP spaces throughout due to this concern. The hardest part is accounting for the point-to-site VPNs on top of everything else (i.e. employees connecting from home/Starbucks/airport). For internal corporate networks, I typically will provision smaller targeted networks in order to get around this. Lopping-off all of 10.0/16 or 192.168/16 for your internal LAN will put you at a fairly high statistical likelihood of overlapping domestic ISP address spaces. Smaller, odd networks like 192.168.111/24 are much easier to plan around.

m463 4y ago
One network I used allocated from 172.16.0.0 – 172.31.255.255 but then docker wouldn't work if you were in 172.17
- rudasn 4y ago
  Ah what a fun issue to figure out and resolve 10 minutes before endofday,especially if you are the one handling docker and some dude in another country is handling the vpn that wants access to said docker.
  - deleted 4y ago
    [deleted]
- rzzzt 4y ago
  For me, this was WSL2's virtual machine and (IIRC) not the default bridge network, but the next one created by docker-compose.
- jrockway 4y ago
  I ran into this problem a long time ago with EKS. I picked a network for EKS, but it also needed a network for docker running on each node, and this happened to conflict with a network that we had peered to AWS (we were an ISP, this was our internal management network). I learned on that day to put everything in our IP address management system (netbox). Allocate private networks like we allocated public networks to our customers. (It would have been nice if I allocated Docker's defaults before they had been allocated to an internal network, but ... hindsight 20/20. At least with that network in the IPAM system, people could figure out why it broke though.)
  - doubled112 4y ago
    I have had this happen with Docker compose too in a much less complicated setup. When you add a network, it gives you a network. It allocates a pretty big address space each time, and eventually it'll run out of 172.16.0.0/12 space and move on to 192.168.0.0/16 networks. Why can I get to this from the guest network but not the client network? Oh... It sucks, but I manually set networks now. And keep track of them.
    - jrockway 4y ago
      Yeah, for EKS you pick an IP range for docker, but it can't be changed after the cluster is created. So remember to pick right.
zamadatix 4y ago
For virtual network IP space you can go with the 0.0.0.0/8 space (sometimes called "zeronet") as long as you are using kernel 5.4+ everywhere you want that network. Obviously 0.0.0.0/32 is still excluded. Windows (and probably macOS?) still block that as of today so it can be an extra safe (and large) space if your only worry is "I don't want my virtual network space to collide with outside or client sourcing networks".
justsomehnguy 4y ago
There is an extremely low chance what you find a collision with 30/8.

m463 4y ago

One network I used allocated from 172.16.0.0 – 172.31.255.255 but then docker wouldn't work if you were in 172.17

rudasn 4y ago
Ah what a fun issue to figure out and resolve 10 minutes before endofday,especially if you are the one handling docker and some dude in another country is handling the vpn that wants access to said docker.
- deleted 4y ago
  [deleted]
rzzzt 4y ago
For me, this was WSL2's virtual machine and (IIRC) not the default bridge network, but the next one created by docker-compose.
jrockway 4y ago
I ran into this problem a long time ago with EKS. I picked a network for EKS, but it also needed a network for docker running on each node, and this happened to conflict with a network that we had peered to AWS (we were an ISP, this was our internal management network). I learned on that day to put everything in our IP address management system (netbox). Allocate private networks like we allocated public networks to our customers. (It would have been nice if I allocated Docker's defaults before they had been allocated to an internal network, but ... hindsight 20/20. At least with that network in the IPAM system, people could figure out why it broke though.)
- doubled112 4y ago
  I have had this happen with Docker compose too in a much less complicated setup. When you add a network, it gives you a network. It allocates a pretty big address space each time, and eventually it'll run out of 172.16.0.0/12 space and move on to 192.168.0.0/16 networks. Why can I get to this from the guest network but not the client network? Oh... It sucks, but I manually set networks now. And keep track of them.
  - jrockway 4y ago
    Yeah, for EKS you pick an IP range for docker, but it can't be changed after the cluster is created. So remember to pick right.

zamadatix 4y ago

For virtual network IP space you can go with the 0.0.0.0/8 space (sometimes called "zeronet") as long as you are using kernel 5.4+ everywhere you want that network. Obviously 0.0.0.0/32 is still excluded. Windows (and probably macOS?) still block that as of today so it can be an extra safe (and large) space if your only worry is "I don't want my virtual network space to collide with outside or client sourcing networks".

justsomehnguy 4y ago

There is an extremely low chance what you find a collision with 30/8.