Wingate VPN - traffic is VERY slow across the VPN link.

[LordPhantom]

Hi Everyone,

I'm hoping someone can help me with my VPN problem. I've never installed one before, but everything seemed to go smoothly when I installed it.

The setup is Wingate with VPN on the "server", with 8-10 workstations in the office, and just the VPN client running on single PC off site. Server has SDSL and the offsite PC has ADSL.

The off site pc connects the the VPN first time, every time. You can browse shared folders on the server without too much hassle.

The problem is one of performance. Trying to transfer data across the VPN is near impossible as the transfer rate is almost zero.

I installed "NetLimiter" so I could see what was going on. When I attempted to copy a large file from the server to the off site machine, the traffic generated was never more than about 1k/sec.

Does anyone have any idea why the performance would be this bad?

[adrien]

Hi

Sounds like this could be an issue with MTU. MTU affects the size of the largest packet that can be sent. If there is a problem, it can mean that big packets don't make it through the VPN, but smaller ones do. This can play havoc with throughput.

To test if you have an MTU issue, you use the ping.exe program, but use the ping extensions to send larger than normal packets.

for example

ping 192.168.0.1 -l 1472 will send an ICMP echo packet with a payload of 1472 bytes (makes a 1500 byte IP packet, since the ICMP packet overhead is 28 bytes).

So by pinging with larger and larger packets, you can narrow down the size at which packets stop being transmitted.

If you have an MTU issue, you can reduce the MTU on your adapters with registry settings.

In general if you can ping over 1500 byte packets, you don't have an MTU issue.

If you don't have an MTU issue, the main issue affecting throughput is normally latency. the delay between packets being sent, and being received at the other end also limits throughput, since for TCP connections, the next packet won't be sent until the sender has received acknowledgement that the last packet was received. There is not much that can be done for that if this is the case, there are some registry settings that can alter TCP receive window sizes which can help, but this is normally mainly a function of your internet connection. Here in NZ anyway ADSL connections aren't the greatest for latency.

Adrien

[LordPhantom]

What would be considered good, bad or adequate latency? I'm planning on visiting the site this afternoon, and will check on that as well as the MTU issues.

Hopefully I can get it working :-)

[LordPhantom]

After telling wingate to allow pings from the internet, I have found the following;

Pinging the internet IP of the server machine;
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 264ms, Average = 95ms

Pinging 192.168.0.1, the internet IP of the server;
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 72ms, Maximum = 109ms, Average = 80ms

Pinging 192.168.0.1 -l 1472
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 442ms, Maximum = 681ms, Average = 466ms

Pinging 192.168.0.1 -l 2972
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 799ms, Maximum = 1198ms, Average = 836ms

Pinging 192.168.0.1 -l 4972
Packets: Sent = 100, Received = 99, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 1300ms, Maximum = 1489ms, Average = 1324ms

So, I can ping larger packets, but the time gets very very slow.

The remote machine is conneting to the net via a router, so I might get rid of that and put an internal ADSL modem in and see how it goes.

Can you tell me anything further based on this information?

[jono659]

Hi there, all our machines have been set to 1350 MTU after weeks of trial and error. All are working fine

JonO

[adrien]

yep those times are quite slow.

A full-size packet is 1500 including all the headers (excl ethernet header).

So a 466ms round-trip time for your 1472 byte ping is actually quite abysmal.

That would mean any one connection, which maximum sends 2 packets before waiting for an acknowledgement would have a maximum real data throughput of about 48kbit/s. Less than your average dialup modem. Actually delays in acknowledgement longer than about 300ms normally totally decimate TCP throughput because of retries.

If you use the tracert program (another command shell program) you can see which hop is taking the delay.

In New Zealand here, DSL latency is about 27 ms, on the backbone you should get around the world and back in less than 200ms, so there is something really holding up your link.

It's not satellite in there is it? Or a very slow modem link?

Adrien

[LordPhantom]

What I fail to understand, is that I can PC-Anywhere from the remote machine to the server and it runs great. I would have expected all communications between the machines to run badly if it was a problem with the speed of the link between them.

I also connected to the VPN from my office. Both the server of the VPN and my office are connected via the same ISP (only 1 hop between the two machines). This was just as slow as the clients home PC to their server was.

Could the performance be a result of the VPN going through PPPOE at both ends, as well as NAT at the off site end?

Could the performance of the server box be an issue?

Are there any other factors in software VPN performance?

[jono659]

What I fail to understand, is that I can PC-Anywhere from the remote machine to the server and it runs great. I would have expected all communications between the machines to run badly if it was a problem with the speed of the link between them.

I also connected to the VPN from my office. Both the server of the VPN and my office are connected via the same ISP (only 1 hop between the two machines). This was just as slow as the clients home PC to their server was.

Could the performance be a result of the VPN going through PPPOE at both ends, as well as NAT at the off site end?

Could the performance of the server box be an issue?

When I was running into problems with the wingate vpn I also could connect with no problems with either PCAnywhere or the windows VPN, it was only when i used wingate which is a multi connection routing solution that the mtu problems were evident. do you have the rip2 client installed on all the machines behind the server?
Are there any other factors in software VPN performance?

[adrien]

What I fail to understand, is that I can PC-Anywhere from the remote machine to the server and it runs great. I would have expected all communications between the machines to run badly if it was a problem with the speed of the link between them.

I also connected to the VPN from my office. Both the server of the VPN and my office are connected via the same ISP (only 1 hop between the two machines). This was just as slow as the clients home PC to their server was.

Could the performance be a result of the VPN going through PPPOE at both ends, as well as NAT at the off site end?

Could the performance of the server box be an issue?

Are there any other factors in software VPN performance?

Hmmm, that is interesting.

So the perfomance of the same 2 machines running PCAnywhere over the same links is wildly different when they are connecting over the VPN vs connecting directly?

If the performance is about the same, the other thing to note, is that things like file browsing is very slow because explorer makes dozens of "transactions" (packet send and receive) for each file displayed in explorer.

Those ping times are odd though. If you were running the VPN on a very slow machine, the decryption and encryption overhead could make problems.

Also, you say that the 2 ends are only 1 hop apart, so presumably connected to the same ISP. Does this mean they both have external IP addresses in the same subnet?

In which case, it may pay to not publish the external IP addresses or routes in the VPN on either end (only the internal ones).

[LordPhantom]

The two machines are not using the same ISP, but both ISP's peer with pipenetworks, so the traffic goes to the ISP POP, To the local Pipe box, then to the 2nd ISP's POP. Perhaps I overstated the simplicity of that earlier :-)

What does this Rip2 thing do, and should I be configuring it? There are Rip2 settings, of which Send Updates and Enable Listener are enabled, but publish learned routes on VPN is not enabled, should it be?

You also mention that file browsing is likely to be slow, but in fact, its about all you can actually do! I can open folders on the server from the client machine, and they appear slowly, but in sufficient time not to be too much of a problem. It seems to be whenever you try and so something that requires a bit of data transfer things go pear shaped (launching an app off the server or copying a file from it).

I looked at the "customize routes" section, and there are 3 listed as being published by the server, localhost, the local lan ip and the ISP ip. Should I do something to the ISP IP there to stop it being published?

The home PC is only on 256K/64K, the server is on 512K/512K. Is upgrading the speed of the remote PC's connection likely to have a significant difference? The problem I have is I don't want to start incurring costs on behalf of the client if its not going to solve the problem.

Anyway, if you can comment on these issues, and I'll see how I go.


Thanks,
Mathew.