VPN Intermittent Packet Loss

[mungdrool]

Hi all,
I am trying to get my WIN98SE laptop to connect to my work's LAN. We are using the Nortel Contivity VPN software V04_15.06. The problem I'm having is when I try to connect through my ADSL connection. I can get the VPN client to connect fine, but I cannot log onto the Novell server, and when I try to ping various servers, sometimes it works and sometimes I get 50 - 100% packet loss. The error I get from Novell is "Tree or Server cannot be found". We've tried using both its name and its ip address, assuming it was a problem with DNS. I can browse the internet and ping other sites prior to connecting the VPN, so I don't think it's a problem with my computer talking to my ISP.
The really wierd thing is I can use a dial up connection with no problem. So it has something to do with my ADSL connection.

Has anyone else seen this? Does anyone have any suggestions of things to try?

Any help would be appreciated.

Thanks,
Jeff Tendam

 

[Sc0tt99]

It sounds like the problem we were having with VPN over DSL. It took me a couple of months to figure it out, being my first time troubleshooting VPN. Using a sniffer I could tell that there were a lot of packets being dropped. Finally I discovered from researching on the Internet that our problem was the MTU (maximum transmission unit).

In a nutshell, here's what I found. The standard MTU for an ethernet network is 1500. However, for some reason the MTU over DSL is 1492 (if I remember correctly). On top of the that, the extra overhead caused by the VPN drops the MTU even further.

Here's how to find your MTU. While connected to the VPN, ping a server on your network using the following command:
ping -f -l X a.b.c.d

To be clear the "-l" is a lowercase "L", not a number one. Of course replace the "a.b.c.d" with the IP address of your server. The "X" will be a number you will use to determine the MTU. Start with 1500. If you get "Request timed out" or "Packet needs to be fragmented but DF set", try 1490. Keep decreasing the number by 10 until you get "Reply from a.b.c.d". Once you get replies, increase the number by 1 until you get a "timed out" or "fragement but DF set" error.

Take the highest number that got replies (in our case it was 1418) and add 28 to that to get the MTU (ours was 1446). Download DR. TCP from

http://www.dslreports.com

and set the "Path MTU Discovery" setting to "No" and set the MTU for your network card to the MTU you came up with. Reboot and try your VPN again.

I hope this helps.

 

[mungdrool]

Thanks a lot Sc0tt99!!! I'll give it a try. I should have thought of that. I worked with a VPN about a year and a half ago, trying to get our web application to connect to their database. It was a state owned database for vehicle registrations, so we didn't have much control over things. We ran into a similar situation with MTS not being able to start a transaction. It turned out to be exactly what you said. In that case, it had something to do with the network topology at the different sites, or the type of networks, or something like that.
My support folks here more or less told me I was out of luck and would need to dial in with this one. If this works, I'll pass it on to them.

Thanks again!! I'll let you know if it works.
Jeff Tendam

 

[mungdrool]

I gave this a try over the weekend. No luck. It appears that my MaxMTU changes every time I reboot. The first time it was around 1380. After I made the change for this and rebooted, it went down to 12xx. I even tried setting it to 572, so it would look like a PPP dialup connection, and it still wouldn't work. There must be something in my ISP's network, or my work's connection to it, that's still causing a problem.
Oh well, at least my dialup connection works. I had hoped to use my DSL to keep my phone line free, but if I can't, I can't.

Thanks for your help anyway.

Jeff Tendam

 

[Sc0tt99]

Jeff,

FYI...after you change the MTU, if you do the ping test again to test the MTU, it will have a lower number. This is because the number you get when you do the ping test isn't the MTU (I believe it's the MSS). As you recall, you add 28 to the highest successful number from the ping test to get the highest MTU that will work. Therefore, when you manually set the MTU to a lower number, the highest number that will work with the ping test also goes down.

Anyway, sorry it didn't help you.