John,

A few things to try:

-          See if you can get the people on the far-end side (the law firm) to do a wireshark capture off the VPN device.  The thing you are really looking for is the traffic to see if it gets there.  90% of the time it isn’t, and there is something either blocking it, or drastically delaying the traffic.  Some older VPN protocols drop packets if there are out-of-order or delayed beyond some pre-defined buffer.  The capture on the line would help determine that.

-          See if you can use a generic VPN client that has 64-bit support.  Some generic clients that I’ve found work very well with most devices include NCP Remote and to a lesser extent, Shewsoft VPN Client.  NCP costs some money but is very well supported.  Shrewsoft is free.

-          I doubt this is the problem, but it is something to check – make sure that the binding order of the VPN client is in line with what you would expect in the network card stack (it should be first, or at least before your active network cards).  Also, check your routing table on your network stack to make sure traffic is being routed with the correct priority. 

-          Finally, make sure your packets aren’t getting fragmented in a weird way.  We ran into an issue where one of our clients on a DSL connection was only sporadically working.  Turns out that their ISP only supported a very small TCP window size, which was causing packets to be thrown out (and not resent) causing large payloads to be dropped on the floor.  IT Services helped me find this one – unless you know what you are looking for in that one, it’s damn near impossible to find.

Good Luck!

-Nick Kwiatkowski

MSU Telecom Systems

Good morning MSUNAG,

I have a professor using an older Watchguard Mobile VPN Client (ver. 10.10) to try to reach back to his law firm’s computers to access files.  We’re seeing some odd behavior that we don’t see with other VPN clients from other vendors, so I thought I’d ask if anyone has seen something like this.

The client is 32bit, installed on Windows7-64bit, which I’ve been assured by their technical support isn’t an issue.  We’ve tried this with the Windows firewall turned off and on, and the results are the same either way.  Antivirus software it told to ignore the VPN application.

When we watch the logs in real time, the VPN client authenticates to the remote VPN firewall, builds the tunnel, gets IP and DNS address information for the tunnel and the VPN interface, and says it’s connected.  Despite what looks like a clean tunnel, we can’t see anything on the other side: we can’t connect to their remote hosts, and we can’t even ping the firewall and DNS server that the client is connected to.  When I watch the traffic go down the tunnel in verbose mode, I can see the first two steps of the SYN, ACK traffic, but the third part of the handshake never happens.  On the far side, their admins can see this connection come up, and see the tunnel is connected and appears to be error free.

At the Law College side of things, the PC running the VPN client is in the highest security zone, so according to our internal network firewall rules, it has permission to open any statefull connection for inbound or outbound traffic. 

So, I’m stumped.  Any of the security gurus who monitor this list, am I missing something grossly obvious? Any suggestions or advice would be appreciated. 

John Resotko

Assistant Director, Systems Administration and Support

Michigan State University College of Law

648 N. Shaw Lane, Room 208 Law Building

East Lansing, MI 48842-1300

email: [log in to unmask]

phone: 517-432-6836

fax: 517-432-6861

web: http://www.law.msu.edu/