5 ms·

This is a very real problem when using a VPN into another network with same ip-space. Though I'm not sure the complexity is worth it. Suppose it would be nice

This is a very real problem when using a VPN into another network with same ip-space. Though I'm not sure the complexity is worth it. Suppose it would be nice if tailscale implemented this type of substitution-routing-NAT this for users.

dilyevsky 4y ago
I mean they kinda do by assigning each node a cgnat space IP?
- tarasglek 4y ago
  They have NAT routing support for exposing nodes that don't/can't run tailscale. Meant that ip space
zamadatix 4y ago
Another possible option for the VPN use case, depending on what you're trying to do and how you're doing it, is to just put the VPN into the VRF (or a netns) and only bind connections you intend to run through the VPN to that context. It's not particularly fantastic either but it's a little more straightforward.
bob1029 4y ago
> 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.
- 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.
linsomniac 4y ago
Tailscale does do something along these lines, but it's kind of surprising... If there is a tailscale route announced, it will take precedence over other routes, even if they are more specific. The primary use case for this seems to be if you are at a coffee shop, you can access a tailscale routed network that has the same IP range as the coffee shop. The down side of this is that if you have, say, a wider announced network routed over your tailscale (say 10.0.0.0/16), and then you have machines within that network also connect to the tailscale (say a machine with 10.0.1.1/24), it now will try to reach machines on its local network interfaces via routing over the tailnet. Pretty unexpected. https://github.com/tailscale/tailscale/issues/6231 https://github.com/tailscale/tailscale/issues/6231
WirelessGigabit 4y ago
We had this issue with Docker, which uses 172.19.0.0/16 for the default bridge. You can change it but it was weird figuring that out the first 2 months.
tecleandor 4y ago
Tailscale does a fun thing that's mapping overlapping ipv4 networks into different ipv6 networks: https://tailscale.com/kb/1201/4via6-subnets/ https://tailscale.com/kb/1201/4via6-subnets/

dilyevsky 4y ago

I mean they kinda do by assigning each node a cgnat space IP?

tarasglek 4y ago
They have NAT routing support for exposing nodes that don't/can't run tailscale. Meant that ip space

zamadatix 4y ago

Another possible option for the VPN use case, depending on what you're trying to do and how you're doing it, is to just put the VPN into the VRF (or a netns) and only bind connections you intend to run through the VPN to that context. It's not particularly fantastic either but it's a little more straightforward.

bob1029 4y ago

> 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.
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.

linsomniac 4y ago

Tailscale does do something along these lines, but it's kind of surprising... If there is a tailscale route announced, it will take precedence over other routes, even if they are more specific. The primary use case for this seems to be if you are at a coffee shop, you can access a tailscale routed network that has the same IP range as the coffee shop. The down side of this is that if you have, say, a wider announced network routed over your tailscale (say 10.0.0.0/16), and then you have machines within that network also connect to the tailscale (say a machine with 10.0.1.1/24), it now will try to reach machines on its local network interfaces via routing over the tailnet. Pretty unexpected. https://github.com/tailscale/tailscale/issues/6231 https://github.com/tailscale/tailscale/issues/6231

WirelessGigabit 4y ago

We had this issue with Docker, which uses 172.19.0.0/16 for the default bridge. You can change it but it was weird figuring that out the first 2 months.

tecleandor 4y ago

Tailscale does a fun thing that's mapping overlapping ipv4 networks into different ipv6 networks: https://tailscale.com/kb/1201/4via6-subnets/ https://tailscale.com/kb/1201/4via6-subnets/