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

[Jeff]

On Tue, Dec 23, 2008 at 6:56 PM, Matthew Grooms <mgrooms at shrew.net> wrote:
> 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.

Well, I did not immediately think it would be an issue as our Cisco
Router with Cisco VPN Client did not have any trouble navigating such
a network topology.

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

Not really a practial option at this time. We have VPNs with vendors
that would have to be redone.

> Hope this helps,

It does, thank you. Though perhaps not the answer I was hoping for.

For the most part, our VPN users are connecting from home. We will
have to help them change their local networks. If the occasional
coffee shop uses our same subnet, then I guess we are out of luck.

-- 
Jeff