0

We have a number of site to site VPN tunnels which each have a their own consecutive subnet, for example:

Branch 1 - 192.168.1.0/24
Branch 2 - 192.168.2.0/24
Branch 3 - 192.168.3.0/24
Branch 4 - 192.168.4.0/24
Branch 5 - 192.168.5.0/24
Branch 6 - 192.168.6.0/24

We also have a number of users whom need to create PPTP tunnels while they are roaming. Occasionally those roaming users hit the expected problem that their local network matches that of Branch 1.

Note: All VPN tunnels terminate at Branch 1 and are given an IP in the 192.168.1.0/24 range.

The network design is the result of a legacy management system of which the network was a product of. I am now working towards adding additional subnets to Branch 1 to terminate the VPN tunnels. So, for example, Branch 1 would have the following subnets:

192.168.1.0/24
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24

What I am trying to get my head around is where the conflict is causing problems. Essentially, the question is; if the VPN tunnels terminate to a subnet that does not match that of the roaming users' local network - will the conflict remain due to the 192.168.1.0/24 subnet existing on the terminating device, even though it's not the actual subnet the roaming client is connecting on?

Company VPN on same subnet as home network

dannymcc
  • 2,677
  • 10
  • 46
  • 72
  • Possible solution: http://serverfault.com/questions/548888/connecting-to-a-remote-server-through-openvpn-when-local-network-subnet-conflict/557030#557030 – ErikE Nov 23 '13 at 22:43

1 Answers1

0

The problem is that when a users is on a network with a matching subnet (192.168.{0,1,2}.0/24 are the most dangerous ones) the remote address it is trying to hit is a link-local address now, so the routing table is never consulted and the packet is just sent on the wire. Thus, the packet ment to go down the VPN doesn't since the machine thinks that the address it is trying to reach is link-local.

Zypher
  • 36,995
  • 5
  • 52
  • 95
  • So even if they connected to `10.0.1.0/24`, the fact that they would be requesting devices in the `192.168.1.0/24` would still cause a problem? It's looking increasingly like we need an IP change. – dannymcc Jul 08 '13 at 16:24
  • @dannymcc correct. If the node they are trying to connect to is on the same IP range, then they will never get there. – Zypher Jul 08 '13 at 16:52