Problem with vpn client on machines below 700 MHz

[karl-koch]

Hi there,

We use Wingate (current Version 5.2.2) to give our staff the ability to work from Home.
Everythink work fine with Machines with more than 800 MHz machines with W2k.

Some of out Stuff have only 700Mzh oder 500Mhz machines and all this machines do have Problems with VPN!

They can connect the Server.
No Problem!
The first application work fine...
But if there schould be more traffic to the server... no IP transfair is possible.
You have to restart the machine...

If you use IMAP you can only browse in folders with only a few mail...
If you have a folder with 10 entrys or more, the IP connection is lost...


Do enybody have heard of this problem before?

[Pascal]

Do enybody have heard of this problem before?

Most of our testing work here was done on sub-700mhz machines (400 -> 600 mhz range). What are they using to connect to the internet ?

[karl-koch]

The machines with this problem are 400Mhz W2k machines With DSL-Connection (512KBit Downlink 128 kBit Uplink)

We have this problem on at least 15 different machines.
The VPN Connection is established. Fine...
The computers can browse in network-drives and transfair files.. (With MS Explorer) ... fine...

But IMAP and some others protocolls don't work!

If we connect directly (without VPN) the Server we have no problem!
But we want to use the vpn to add more security to our system!

I tried different IMAP Clients (Mozilla and Outlook)... there are the same symtoms...
Smal Files and folders are no problem... but if you have a big folder
there is only a few kByte of transfair than the connection interrupts.
If you restart the Wingate-VPN-Machine you can transfair a few KBits again...

Is there a SSL-Timeout in the VPN client which cut of delayed packets?
Can I monitor the traffic trough the VPN Client if there are lost Sync or ACK IPs?

Thank you for your Response

Karl

[adrien]

Hi

Normally connection speed only has the effect of slowing things down or speeding things up - not locking up the system entirely. We have tested over slow dialup even without the problems you are describing.

Are you using a PPPoE connection?

Also, is there anything else in common about these slower machines? I.e. a common piece of software that you used to install when these machines were new but you didn't on newer faster machines etc.

Adrien

[karl-koch]

Hi,

Yes, they all use PPPoE to connect with the internet...

They all have a W2k OS... and Netscape ..
I tried with different versions of netscape... More RAM on the board...
Other ISP.... POTS Dail-in with analog modem...
With fast CPU VPN work... under all conditions... slow cpu.. makes trouble

I put the Harddisk with the software on it in an fast PC...
With the fast CPU everythink work fine...

I tried different system at my office today...
If i use more than 700 Mhz all problems disapaer....
Maybe it is a Problem of Windows IP kernel?
But we use latest Service Pack...

Put the Harddisk in 400 machine... the problems come back :o(

Maybe the delay of encryption couse too bad delay or jitter for some application...

How you can explain that if once the connection is interrupted i have to restart the wingate-vpn service to get some new packets to the server?

If you have never heard of this problem before, it may be the best way to buy new machines....or use the Microsoft VPN... but this is not a nice solution ;o(



Thanks

Karl

[adrien]

OK, time to test with some pings of varying sizes then.

If you ping a server over the vpn with a large packet using for example

ping 192.168.1.1 -l 1472

then it will send a 1472 byte payload, plus 28 bytes for the ping overhead means a 1500 byte packet which is normally the biggest packet you can send on a LAN before a packet is fragmented (not counting the 14 byte ethernet header)

I suspect you will get a timout for this.

I would try sending say a 500 byte packet, a 1200 byte packet, and keep going up until you find the threshold where it stops working. If you need to you can also increase the amount of time the system will wait for a reply by using the -w switch and specifying a time in milliseconds, for instance

ping 192.168.1.1 -l 1500 -w 3000

will send a 1500 byte payload and wait 3s for the reply - in the reply the whole packet is sent back, so the bigger the ping the longer it takes. On slow links you may need to increase the wait time.

Adrien

[karl-koch]

Hi...

I did some PING test on the machines...
I did this test on 2 different machines (win 2k, 400 and 450 MHz)
For reference I have an 1000MHz machine in my office without the problem

All connected with DSL (same line.. same isp)
I did this test twice on every machine with nearly the same result...


1. Fresh boot ...
2. Connect to VPN Server via Internet...
3. Up to here everythink fine...

4 Did some PING Test with various values...
Nice results... with 400 and 1000 MhZ

Byte Timo (mSec)
32 Byte 100 ms
500 153 ms
900 208
1000 220
1500 280
2000 330
3000 450
4000 580
OK here comes realy BIG PayLoad ;o)
5000 700
6000 800
7000 930
8000 1100

1. Problem...there is al Limit at 15000 of payload (1800 msec)
This must be a restriction by the VPN...
On my LAN i can go to the kernel-maximum of 65500

But this limit i have at all machines... also on the machine with 1000 MHz
This is not the problem we are looking for!


These values are just fine up to this point...
Now I started an IMAP application (i.e Netscape or Outlook)

First connect, work fine .. but if i want to connect a folder with many headers... the transfair stop on 400 and 450 MHz machines! ;o(
1000 MHz works fine...


I did the PING again...
Here we have differences between the machines now!

Now Ping is limited by
1407 Byte Payload at the 400 and 450 MHz machine....
Even ich you set Timeout to some sec. there is an timeout...

The 1000MHz machine still does PING up to 15000 Byte Payload


If i reconnect the VPN server... nothing change...

If i restart Wingate VPN Engine...
I can ping up to 15000 byte on the slow machine again and IMAP work for short time...

The Round Trip Time is nearly the same on the slow and fast CPU...
But if i use IMAP there is something that limit me Payload...

Stange isn't it?



Maybe there is a problem with packet segmentation?

Do you have congestion-control implemented in the VPN protocol?

But what couse the vpn client to set the maximum palyoad down?

Is there a way to monitor the ip-Header (segmentation Flag, etc)
on the local-loop interface to the vpn?
I tried the MS-Sniffer but there are no packets shown that go to the vpn network ;o(

What do you say?



Karl




P.S.


I remember a strange bug like this. Coused by an old (1995) Borland
Pascal Compiler...
Did you use Pascal to write some VPN components ;o)

[karl-koch]

Hi adrian,
Good morning to Auckland...

I refleced on thie problem then night and found a practicable solution.

Maybe ther is a problem with the flow control.
I tryed to set varius ReciveWindowsSize.


And it works!

You can read some more on Microsoft Knowledge Base Article 263088

I set
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
to 2238 (HEX)

This is a working value...
The connection is a little bit slower than before... BUT IT WORKS!

Maybe this help some other people who are still swear like a trooper because of
interrupting IMAP or other protocolls ;o)



Karl

[karl-koch]

OK, the workaround doesn't work!
It works only by a fluke!

The problem still is here and drives me crazy!
The packet is limites by 1406 byte!

Ping with moren than 1406 will be lost!
This looks like a segmentation problem!

1406 is the Payload of n IP...
The IP have 24 Byte Header...
1406 +24 = 1430
This looks like 1 MTU...

I guess that all packets are lost that have been segmentated...

gosh... an now?

What do you say?



Karl

[adrien]

Hi

There is a process called MTU path discovery. It uses a flag in packets called the DF flag (don't fragment). With this flag set, if a router receives a packet that is too big to forward, it will send an ICMP error packet back and specify the MTU for the next hop. Otherwise if this bit is not set, then the router will fragment the packet and send it.

WinGate supports Path MTU discovery by doing this. Also, by default, Windows supports it - but only for TCP connections. Windows remembers these new MTU values by creating a route in the route table.

So, after you did the IMAP connections, I bet you would see new routes in the route table on the client machines.

After Windows has learned the new MTU, then it won't send packets bigger than that to that site.

However, testing we have done here, shows that the OS will still send up to 64k packets, but just fragment them into smaller chunks.

PPPoE will use up some of the MTU, and so does WinGate VPN tunnel. The VPN tunnel is about 60 bytes of overhead, and the PPPoE I think about 16, so 76+28+1406 = 1510 which would be maximum, since VPN tunnel payload length must be divisible by 16 because of the encryption algorithm.

So I think what you can do, is set manually the MTU on your client network adapters. There is a registry setting for this. If you set it to about 1424 then you can test with ping again.

There is another flag with ping - the -f flag. This sets the don't fragment bit in the ping packet, so if you find the biggest packet you can send with ping before getting a message like "packet must be fragmented but df set", then subtract 28, you have your effective MTU size.

Adrien

[karl-koch]

Hi ...

I tried to set the MTU on some common values for all interfaces...
1500 1468 1300
There are not realy some changes...
The PING on local Network with "don't fragment" flag do couse some changes....

If i Ping the machine externaly and use the "don't Frag" Flag... i will be able to incerease
the PayLoad at the Ping Command up to set up MTU - 80 ....


But Internaly and on the VPN interface i have no changes!
On the Loopback interface and on the VPN i can ping up to
1472 of payload with the "don't FRAG" flag!


The situation with IMAp is still the same!
First connect work fine...
Connection problems...
Ping work still up to a PayLoad of 1406 byte!
If i send bigger packets.... they will be lost!
smaler packets work fine!

I I restart Wingate.. everything fine for a few time :o(


I hate Windows IP stack! Never have seen somethink like this on Linux!

I also tried to disable the MTUPathDiscovery ...
this seems to effect the physical interface only!

Do you see any way to solve this problem?
Maybe it would be easier to install new motherboard and CPU :o(



Maybe this is a problem of "AIMD" or "slow start" ?
Do you know any way to disable slow start?Hi ...

I tried to set the MTU on some common values for all interfaces...
1500 1468 1300
There are not realy some changes...
The PING on local Network with "don't fragment" flag do couse some changes....

If I increase the "payload" at the Ping command with the "dondFrag" Flag couse a "can't defrag" error.

On the VPN there are the limitation of the new MTU too...
This is the MTU size i have added to the registry

But here we have the same problem again...
First connections to the IMAP server fine...

But after a few commands the connection faild...
I do the PING again...

Here we have the same as before..
Payload up to 1406 work fine...
More are lost!



Ping work still up to a PayLoad of 1406 byte!
If i send bigger packets.... they will be lost!
smaler packets work fine!

I hate Windows IP stack! Never have seen somethink like this on Linux!

I also tried to disable the MTUPathDiscovery ...
this seems to effect the physical interface only!

Do you see any way to solve this problem?
Maybe it would be easier to install new motherboard and CPU :o(



Maybe this is a problem of "AIMD" or "slow start" ?
Do you know any way to disable slow start?



Karl

[adrien]

Hi

WinGate VPN ENS will be the device that is sending the ICMP error back when you set the df flag in the ping packets. If you can ping up to 1472 like this, then that means WinGate thinks the MTU for that hop is 1500 bytes.

That is very strange, since WinGate should at least have reduced the MTU by the overhead of the VPN tunnel, which is about 60 bytes.

The only way I can figure it misses this is if you were pinging an IP address that wasn't over the VPN, or if there was an additional route being created on the WinGate server which is deemed local.

That makes me wonder whether you installed an earlier version of our RIP client on the WinGate VPN machine. If you have a RIP client running on the VPN, turn that off and see if that helps.

Adrien

[karl-koch]

Hi

i check my system for a other tunnel to the remote machine.
No, nothing. VPN is the only way to connect the machine.

I also used route -f to delete all routing entries.

there is no route to the destination machine.

Generaly i can't find any entry in the routing-table to the vpn server.
is this ok? "route print" doesn't show any route to vpn network....

I can't imagine what couses this... and why it is gone if i use a faster CPU ;o(


Karl

[karl-koch]

Hello everybody...
It's a pity that i had no response from the Wingate Stuff!

But i still keep on searching for an solution because i had many enquiries
about this problem.

This problem seems to appear on many W2k machines because W2k doesn't have a build-in PPPoE driver.
So many 2nd party driver are used.

As we supposed in the posts, the lost of packets is couses by a to big MTU on the outgoing interface can couse problems.

With slow-start and fast-recovery this problem may appear at big payload
only...

Some ISP don't acceot big MTU to advoide congestion in there routers.
unfortunately there is no easy way to set up a MSS and MTU settings for
PPoE with the windows OS
(at lease t don't know how)
I tried with cfos PPPoE but this coused trouble

The easyest way is to get a PPoE driver for W2k which support
manipulation of MSS and MTU by it self!

I found a good one on
www.raspppoe.com
It is freeware and support setting for MSS and MTU

I run the PPPoE Driver with the following settings...
Limitation of MMS enabled
Overide MTU to 1400

Now also on 300 and 400 Mhz machines VPN works fine!


I hope to help all the people who also have trouble with W2k and MTU ;o)



Karl

[adrien]

Hi Karl

Thanks for posting this information.

Adrien