Overlapping IP ranges in Tunnels

Currently, the office IP range is 192.168.1.x. One of the servers (192.168.1.15) is running cloudflared.

Say I’m now at a client’s office. Their IP range is also in the 192.168.1.x range. On my laptop, I’ve got WARP running with ‘Gateway with WARP’ checked. If I try to ssh over to the server with ‘ssh [email protected],’ it hangs. It looks like its trying to connect to a 192.168.1.15 on the client’s network.

If I go to client’s office whose IP range is NOT in the 192.168.1.x range, I can connect to the office 192.168.1.15 server just fine.

What is the best way to make sure traffic for the 192.168.1.x range always uses the tunnel when not in the office?

2 Likes

I’m also hitting this issue with a similar setup and am curious for the solution!

1 Like

If you’re running Cloudflared, then it should have an assigned hostname for SSH, right? Then you can ssh to the hostname instead of the IP address.

Speaking for my case: cloudflared has a tunnel within my network setup for the IP range of that network. The tunnel has a hostname under an existing domain, but I don’t think I can connect to that directly… how would it know which machine to go to? Are you referencing a separate feature of cloudflared?

(Sorry if this is a dumb question… I’m very much new to anything networking-related. cloudflared seemed like a nice way for me to be able to do macOS’s built-in Screen Sharing across networks behind something secure.)

I have an ingress rule on that machine for hostname ssh.example.com that connects to localhost:22.

My computer’s local ssh config file proxies to that ssh hostname.

ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h

I think @sdayman is describing the documented ssh over tunnel method.

Maybe my understanding of Teams is wrong, but if I’m connected over WARP, shouldn’t I be able to access the resources via IP? If not, using the ssh over tunnel with a cname method requires a separate cname for each application running on the server, correct?

1 Like

I think this problem is somewhat better with SSH, however when you’re using a different protocol, overlapping IP ranges are still a pain to work around. If you’re trying to access 192.168.1.3:3389 at Office A for Remote Desktop, you can’t access 192.168.1.3:3389 at Office B until the tunnel at Office A is down.

1 Like

I concur that @sdayman is talking about the Tunnel use case where we expose a private origin to the Internet (and then protect it with Access), so you have an Internet-resolvable hostname.

Instead, this thread is about the Tunnel use case where we provide a private network end to end, by requiring the clients to set up the Teams/WARP client in order to access the private origins.

@user13923 I think you can configure the Teams client Split Tunnel to have 192.168.1.15/32 (or a broader range) to be included in the WARP traffic (so that such traffic is always sent through Cloudflare and therefore eligible for your “virtual private network” that can arrive to your Cloudflare Tunnel origins. See https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/exclude-traffic/split-tunnels
The downside of this is that you will always go via Cloudflare edge, even when you are in the same actual physical private network as the machine where cloudflared is running. This is something that’d require Split Tunnel configurations to be configurable differently depending on which Wifi/Network your Teams client is connected to, which is currently not (yet?) possible.

3 Likes

This is something that’d require Split Tunnel configurations to be configurable differently depending on which Wifi/Network your Teams client is connected to, which is currently not (yet?) possible.

Yeah, that sounds like the best solution. Another option would be if split tunnels could be set by locations. Maybe that makes it too complicated.

This might just be me, but I haven’t been able to make the iOS client to forward requests over the Cloudflare edge at all. As long as there is a 192.168.1.1 on the local network, the client will access the local IP, irregardless of the Split Tunnel rules. I guess this could be easily worked around when you’re planning the different locations, but when you have devices that are working from home, it defeats the entire purpose of the VPN anyway

We’re facing the exact same problem. We have the WARP client installed on the employees’ computers, with split tunnel (in “include” mode) of 10.0.6.0/24 redirecting to our corporate network, but employees having a local network at home with the range of 10.0.0.0/8 cannot access the tunnel. It’s like the home (local) network is taking precedence over the WARP client. Only when we instruct them to reconfigure the subnet in their routers to 10.0.0.0/24, the WARP client relays traffic. But this is obviously not a feasible solution, for example in coffee shops and airports, and it also doesn’t provide a solution to tunnel traffic of 10.0.0.0/24.

Another problem that we were facing is configuring tunnels to multiple different private networks, that use the same subnets. We were only able to configure the first tunnel, then cloudflared refused to assign conflicting ranges (and rightly so). We couldn’t find a documented recommended solution to this situation.

We were able to find vague mentions of this in the cloudflared inline documentation, where it suggested to use “virtual networks”, which to our understanding should “map” one CIDR to another, so for example we could map 172.16.6.0/24 to 10.0.6.0/24 and solve the problem. But we couldn’t find how to actually configure it, since the documentation is non-existing. It is also possible that we got the entire concept of virtual networks wrong.

Any help would be appreciated.

1 Like

About “virtual networks”:
cloudflared tunnel vnet help
It was added in fresh version cloudflared version 2022.1.3 (built 2022-01-28-1606 UTC)

1 Like

Wondering has anyone been able to figure out a workaround for this? We’re having exactly the same issue. Looks like DNS requests that resolve ip thats in the same subnet range are not beeing passed on to warp but instead resolved locally.

user21387 seems to have found the best solution yet. It was recently documented here (original commit just 2 weeks ago), and it seems to be Cloudflare’s solution so far for this overlapping mess. I haven’t yet experimented with it, but if it works the way it says it does, I think it solves about 50% of the issues that we’re having. It seems like it will solve trying to start tunnels that are on overlapping IP ranges, but it won’t solve assigning them to different IP ranges, preventing clients from connecting to the two overlapping tunnels at once (you simply choose between one or the other in the virtual network).

I think a fair amount of work still needs to be done, but it’s a step in the right direction, and I think some of the questions raised up in this thread can be solved by this, just not all.

Other

Also this seems to just not be anywhere on the internet but take a read here for their explanation in the CLI itself:

NAME:
   cloudflared tunnel vnet - Configure and query virtual networks to manage private IP routes with overlapping IPs.

USAGE:
   cloudflared tunnel vnet [global options] command [command options] [arguments...]

DESCRIPTION:
   cloudflared allows to manage IP routes that expose origins in your private network space via their IP directly
   to clients outside (e.g. using WARP client) --- those are configurable via "cloudflared tunnel route ip" commands.
   By default, all those IP routes live in the same virtual network. Managing virtual networks (e.g. by creating a
   new one) becomes relevant when you have different private networks that have overlapping IPs. E.g.: if you have
   a private network A running Tunnel 1, and private network B running Tunnel 2, it is possible that both Tunnels
   expose the same IP space (say 10.0.0.0/8); to handle that, you have to add each IP Route (one that points to
   Tunnel 1 and another that points to Tunnel 2) in different Virtual Networks. That way, if your clients are on
   Virtual Network X, they will see Tunnel 1 (via Route A) and not see Tunnel 2 (since its Route B is associated
   to another Virtual Network Y).

COMMANDS:
   add      Add a new virtual network to which IP routes can be attached
   list     Lists the virtual networks
   delete   Delete a virtual network
   update   Update a virtual network
   help, h  Shows a list of commands or help for one command

I think that OP is having isues with overlapping subnet ranges between Corporate Infrastructure and Warp client when working from home. His home network is 192.168.1.0/24 and his Infrastructure is on the same subnet range - 192.168.1.0/24. so when OP has set up Network Access Policies and exposed a server like 192.168.1.100/32, the WARP client will not pass the request via Tunnel but attmpt to resolve it locally on his home network because its the same subnet range. That’s how I understand it and Im having the same problem.

Recent blog post addresses that I believe https://blog.cloudflare.com/building-many-private-virtual-networks-through-cloudflare-zero-trust/

Every current Cloudflare Zero Trust organization using private network routing will now have a default virtual network encompassing the IP Routes to Cloudflare Tunnels. You can start using the commands above to expand your private network to have overlapping IPs and reassign a default virtual network if desired.

If you do not have overlapping IPs in your private infrastructure, no action will be required.

1 Like

As @rraginskis and I mentioned prior though, this only solves the issue with multiple tunnels running on the same IP subnet, and only solves about half of the problems. Split tunneling on the WARP clients are still fairly unstable and confusing.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.