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
_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
