[Vpn-help] Client and Remote subnets are the same

[Matthew Grooms]

Jeff wrote:
> 
> This was not an issue when we used the Cisco VPN Client to our Cisco router.
> 
> 1. Are the matching subnets the likely source of the problem?

Jeff,

Yes. This will easily cause problems that can't be solved regardless of 
how sophisticated your VPN client software is. For example, consider the 
following scenario where your main network and the client office network 
are both 10.1.1.0/24 ...

/----MAIN OFFICE-----\            /-----------CLIENT OFFICE-----------\
resources  vpn gateway <--INET--> firewall   vpn client      printers
\10.1.1.1  \10.1.1.254            \10.1.1.1  \10.1.1.2       \10.1.1.3
|10.1.1.2                                    |10.2.2.1(vip)  |10.1.1.4
|10.1.1.4
|10.1.1.5

The client is locally attached to the network using the 10.1.1.1.2/24 
address. Any attempt to communicate with a device in this network will 
be handled directly between the client and that device. For example, if 
it attempts to communicate with 10.1.1.3 then it will send a ARP request 
( layer 2 broadcast ) to resolve the MAC address. It will get a response 
from the printer and store the result in its ARP cache. As long as that 
ARP entry exists, any traffic destined to 10.1.1.3 will be dropped on 
the wire with the Ethernet header destination MAC address set to the 
printers MAC address.

If the client attempts to communicate with 10.1.1.5, the same resolution 
process would occur. But since 10.1.1.5 isn't part of the same physical 
broadcast domain, an ARP response would never be received. What you can 
try is to add a policy that specifically defines the 10.1.1.5 host as a 
remote resource. This should cause the client to add a route that is 
more specific than the locally attached network ( /32 < /24 ) and bound 
to the virtual network adapter. In other words, packets sent to 10.1.1.5 
would be sourced from 10.2.2.1 instead of 10.1.1.2 which causes the IP 
source and destination to be in separate broadcast domains. I haven't 
tried this so I can't guarantee this won't blow up on you in some other 
way. I can only say that it should work 'in theory' :)

But the problem is a lot more difficult to solve if the client attempts 
to communicate with 10.1.1.1, 10.1.1.2 or 10.1.1.4 on the main network. 
To my knowledge, there is no way to get this working with vanilla IPsec. 
Hosts simply can't reside on both sides of the connection without some 
degree of logical separation. You can try working around this using NAT, 
but in my experience this quickly becomes a very messy solution even if 
your vpn gateway is not the default gateway for your main office.

Your best course of action is to renumber your main office network to a 
subnet that isn't used everywhere else. You will thank yourself later.

Hope this helps,

-Matthew