[vpn-help] Bug report: same subnet both ends of the tunnel doesn't work.

[Matthew Grooms]

On 7/28/2010 8:46 PM, Matthew Grooms wrote:
> On 7/28/2010 9:29 AM, Ian Fraser wrote:
>> Hi, I have a problem with the Shrew Soft Windows VPN client and would
>> like to submit the following bug report:
>>
>> Problem: Recently changed from Junipers VPN client to Shrew Soft's
>> VPN client for windows. I happily completed all testing without a
>> problem. After the users switched some of them complained of various
>> behaviour such as: Connects RDP client for a short while(10-20 mins)
>> then disconnects and refuses to reconnect. Tunnel comes up, until try
>> they to connect the RDP client, then the tunnel drops. Tunnel comes
>> up, but RDP client fails to connect.
>>
>> After some time, it emerged that the users experiencing these
>> problems were using home connections that used the same subnet range
>> as our internal network (192.168.1.0/24 for example). I am hoping
>> that because other VPN client software can cope with this situation,
>> this is not an insurmountable problem.
>>
>> VPN Client Version : 2.1.5-release (have also tried 2.1.6-rc-1)
>> Windows OS : Windows Vista and XP Gateway Make/Model: Juniper SSG-140
>> Gateway OS version: 5.4
>>
>
> Hi Ian,
>
> I can only think of one way to cope with this situation and that's to
> cut off access to the local network by promoting the identical route
> that points the distant network. The Shrew Soft client is designed to
> increment the route metric on existing routes and use the lowest route
> metric possible to reach distant networks. I'll try to re-create the
> scenario you describe and see if I can re-produce, and with any luck,
> correct the issue.
>

Hi Ian,

I did some investigation and this is what I found. The client does do a 
pretty good job of demoting existing routes and promoting the routes it 
adds for tunneling. But since the client responds to ARP requests based 
on the IPsec policies ( and there was an IPsec policy for the local 
network because it exists remotely as well ), the host would get really 
confused because it was receiving ARP responses on the real adapter as 
well as the virtual adapter. In fact, you could see it bouncing between 
the two interfaces using arp -a at the command line.

In any case, the client now does a lookup to see if a gateway is used to 
reach the VPN gateway. If so, we install a NONE policy to ensure that 
packets destined to the gateway won't match an IPsec policy. The ARP 
code was also modified to ensure that we won't respond to a request 
coming from our virtual adapter to resolve the gateway MAC. This should 
get you closer to what you want. Please let me know how it goes ...

http://www.shrew.net/download/vpn/vpn-client-2.1.6-arpfix-1.exe

But I will say this, having networks overlap is a good way to get into 
trouble fast. For example, lets say your user is trying to remotely RDP 
into a Windows server at 192.168.1.10. His home network is configured 
for DHCP and he gets handed the address 192.168.1.9. Things work great. 
But later, he is woken in the middle of the night because there is an 
emergency. He fires his computer back up and gets handed out ( yup, you 
guessed it ) 192.168.1.10. No amount of route manipulation or trickery 
will allow a host to RDP to 192.168.1.10 when he has the same address 
assigned to a local interface. It just isn't going to happen. Your best 
option is to renumber your work network to something that every Tom, 
Dick and Harry wont have setup by default in the SOHO router. Believe 
me, you will sleep better at night.

-Matthew