XP VPN client fails randomly for 3Com OfficeConnect

[robto01]

Hi,

I have a problem with my office VPN. My config is:

Hardware VPN Server: 3Com OfficeConnect 3CR856-95-US VPN Secure Gateway (with latest firmware)
Client: XP Pro SP2 using built in VPN client connection
Protocol: PPTP
Home connection: cable broadband
...connected over the internet to...
Office connection: ADSL


I can connect fine and in the past I have used the VPN connection successfully for file browsing, telnet, Outlook, remote desktop and pretty much anything that I normally would use when directly connected to the LAN. Others from my company also use it successfully. I am the systems administration dept so can change any settings as required.

A few months ago, one of my colleagues with an identical connection found the connection would fail especially when using Remote Desktop. This started happening despite no changes. Subsequently, this became worse such that even using Outlook would cause the connection to drop. At the same time as this, I was able to connect fine. Recently, the same problem has hit me and another colleague. There are others who are not affected. I cannot understand where the problem lies and have tried to rule out everything that I can: we have moved ADSL providers, used different client machines, changed MTU sizes etc. The only thing that seems consistent is that the problem gets worse for some folk through time.

Fixes that seemed to help (and through time no longer do) are:

- Using a bandwidth throttle to reduce the traffic from the client (Shunra Nimbus)
- Removing QoS Packet Scheduler from the network card.

When the connection fails, the network connection icon in the system tray looks fine but a ping shows there is no connection. The router itself has crashed and rebooted. I guess this is a bug in the 3Com device, but the fact that it used to work for me (with the same firmware on the router) and still works for others confuses me.

I read one suggestion that said that a VPN connection requires static routing by your ISP. This doesn't make sense to me because a static route can't be guaranteed over the internet?

3Com have discontinued the product and we're now considering a Linux solution but if anyone can give me any pointers as to where to go from here then I'd appreciate it.

An ipconfig /all on my client laptop gives the following if it is of any use:


Windows IP Configuration

Host Name . . . . . . . . . . . . : MYLAPTOP
Primary Dns Suffix . . . . . . . : AA.local
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : AA.local

Ethernet adapter Wireless Network Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/Wireless 2200BG Network Connection
Physical Address. . . . . . . . . : 00-0E-44-06-15-00
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.7.15
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.7.1
DHCP Server . . . . . . . . . . . : 192.168.7.1
DNS Servers . . . . . . . . . . . : 192.168.7.1
Lease Obtained. . . . . . . . . . : 20 February 2005 08:37:35
Lease Expires . . . . . . . . . . : 20 February 2005 20:37:35

PPP adapter MyCompany Backup VPN:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-55-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.100.227
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.100.3
192.168.100.4

Thanks in advance if you can help,

Tom

 

[technome]

Do you have the correct MTU at the office and at home gateway router.If there is a router along the way which is dropping packet, it can cause this
Definitely check from home.

http://www.speedguide.net/downloads.php

 

[robto01]

Hi Technome,

Thanks for the advice - I have followed it with some success but as usual with my problem it doesn't seem to be the complete answer. Following the use of TCPOptimizer I seem to have a slightly more stable connection but even so, it still fails about 50% of the time.

I have played with the MTU in the past (I've also tried clean machines that I have not changed the settings on just in case I messed them up) with about the same success rate. What intrigues me about using TCPOptimizer are the other settings that it changes. I wonder if anyone can shed any light on the settings that have been altered when I optimized my connection then changed the MTU to the maximum allowed over my VPN connection (1300 - the value I originally started with). Here's a diff of the registry changes saved in before/after TCPOptimizer backups:

[SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
<! TcpWindowSize=-1
<! GlobalMaxTcpWindowSize=-1
<! EnablePMTUDiscovery=-1
<! EnablePMTUBHDetect=-1
<! SackOpts=-1
<! TcpMaxDupAcks=-1
<! Tcp1323Opts=-1
<! DefaultTTL=-1
!> TcpWindowSize=256960
!> GlobalMaxTcpWindowSize=256960
!> EnablePMTUDiscovery=1
!> EnablePMTUBHDetect=0
!> SackOpts=1
!> TcpMaxDupAcks=2
!> Tcp1323Opts=1
!> DefaultTTL=64
[Software\Microsoft\Windows\CurrentVersion\Internet Settings]
<! MaxConnectionsPerServer=-1
!> MaxConnectionsPerServer=20
<! MaxConnectionsPer1_0Server=-1
!> MaxConnectionsPer1_0Server=40
[SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}]
<! {D6277990-4C6A-11CF-8D87-00AA0060F5BF}=-3
!> {D6277990-4C6A-11CF-8D87-00AA0060F5BF}=-2
[SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{4D1B2652-72F0-4FE4-A830-ECFF30A7A7C8}]
MTU=1300
TcpWindowSize=-1
[SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{53A40543-48EC-48E8-92DE-293FC0201A49}]
<! MTU=1300
!> MTU=1500
TcpWindowSize=-1
[SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{D0DD2683-EABB-40C6-B703-7ED68D4CE0F3}]
MTU=1300
TcpWindowSize=-1

Key variables I am curious about are:

TcpWindowSize
GlobalMaxTcpWindowSize
EnablePMTUDiscovery
EnablePMTUBHDetect
SackOpts
TcpMaxDupAcks
Tcp1323Opts
DefaultTTL
MaxConnectionsPerServer
MaxConnectionsPer1_0Server

Is it a blackhole router issue? I'll do a google search to find out what all these mean but I am interested in their significance in a VPN context so if anyone can help...

One more question: I've changed the MTU on my client machine. Do I need to change the MTU on every server it connects to over the VPN? I assume Remote Desktop is probably complex enough to warrant my server initiating the pushing of data towards my client; are the packets of data too big and failing to be fragmented properly?

Cheers,

Tom

 

[robto01]

Sorry - I failed to address one point in Technome's reply: the office router does not have a place to set the MTU. The chain of separate physical devices I have are:

XP Pro laptop -> Wireless Access Point -> DSL Router -> Cable Modem -> {INTERNET} -> ADSL Modem -> 3Com Secure Gateway VPN Router -> Win2k Server

Max MTU test against my Win2k server over the VPN from my laptop is 1300. What devices should I be configuring the MTU for?

 

[technome]

The only thing that seems consistent is that the problem gets worse for some folk through time."
On the affected machines have you run Spybot and Adaware from "safe mode",you might have a malware problem; running through your normal startup is pretty useless .

Try the pathping command to see if you get packet losses; it will also show the point at which packets are lost.
Pathping through an established tunnel to the VPN endpoint and a machine at the endpoint. You should have few if any packet losses.

This could cause aggravation on a server, this is a last resort. You might reset the TCP stack with winsockfix.exe, this resets the TCP stack to default settings, so expect to add all the settings to the "network connection"(s) again; so document all you connect's settings before using it.

http://www.tacktech.com/display.cfm?ttid=257

As far as the wireless access point, can you connect the laptop to the device directly with a cat5 cable, to bypass the wireless connection.


For MTU on windows 2000 server, it may or may not have this setting for MTU discovery.

http://www.netmax.com/fom/cache/467.html

Windows XP or 2003 should be automatic as far as mtu settings. Not sure if the wireless has an mtu setting, change if you can. The Wk2000 should have the reg settings in the link. after applying the setting, guess a reboot is in order, run pathping through the tunnel.

describes some of the settings

http://www.speedguide.net/read_articles.php?id=157

 

[robto01]

I've checked for viruses and spyware and all machines have Trend OfficeScan installed which protects against viruses and some spyware. I have also run Adaware in safe mode on one machine. No difference so I don't think it's that.

I will try pathping. A normal ping is fine until the router crashes (caused by some other traffic normally) so I guess pathping will be. Strangely an Angry IP scan (a util to ping a range of IP addresses) normally blows the connection.

Not sure that I fancy resetting the TCP stack on one of our servers. The problem happens with several different servers so I had ruled this out. Do you think I'm wrong to do so?

I have tried bypassing the wireless stuff before with no difference.

I will try changing the MTU discovery reg value and I will probably drop the MTU to 1300 on the main server to see how this affects it too.

Thanks again for your help - I'll let you know how I get on.

Cheers,

Tom

 

[technome]

I would avoid the winsockfix on the servers, but the laptops and other affected machines could be easily configured..remember to document all the settings for the NIc and PPP adapter.

Curious how are other machines with xp sp2 behaving with VPN?