VPN Performance Issues - can't ping greater than 1913 bytes

[DamonC]

Hi there,

We have purchased 2 D-Link DI-804HV Broadband VPN Routers. We have set up an IPSec Tunnel between the 2 routers.

Users are complaining that performance over ther VPN is poor and often copying files will fail.

We found that using the PING utility we could ping with a packet size no larger than 1913 bytes (ping 192.168.0.1 -l 1913).

The MTU on both Routers has been left as the default (1500).

Client machines are Windows XP and Windows 2003 Server.

Can anybody explain why this is happening and would this be causing the poor performance that users are experiencing (also any suggestions on how to fix/improve this)?

Thanks in advance!

Damon

 

[bcastner]

Cable, DSL or what is your broadband?

The MTU on the routers is likely the issue. DSL is generally 1492, and some ISPs as low as 1420.

http://www.broadbandreports.com/forum/remark,1700907~root=equip,16~mode=flat

 

[DamonC]

At our office end we have a 100Mb connection to the internet, at the client end they have a 4Mb connection.

Hopefully that is useful? (it's not Cable or DSL).

Thanks for your reply - I'll check out that other link now.

 

[bcastner]

You know the 4 mbit. connection is the tail that wags the dog.

The other side of it is that the download side matters little; it is the upload side that matters. If your connection is asynchronous the lowest upload speed is determining your effective link speed.

And you also have to factor in the VPN side of things. IPSEC is not without overhead.

 

[bcastner]

As a guess: if you get a roughly and approximately half the stated rate with one end-point of 4 mbs. through your VPN, I would say you are doing all you can. Which is what your numbers you stated above show.

MTU of 1500 is likely an acceptable value on the routers.

 

[DamonC]

But shouldn't I still be able to get a reply from the ping utility when setting the packet size greater than 1913 bytes?

 

[bcastner]

No. See if the following helps:

http://www.experts-exchange.com/Security/Firewalls/Q_21034711.html

http://www.cisco.com/warp/public/794/router_mtu.html

 

[bcastner]

My apologies, I gave you the wrong link above as the first link I wanted:

http://support.microsoft.com/default.aspx?scid=kb;en-us;314067

 

[MarkhP]

I had a similar problem recently and it turned out to be our ISP had changed the MTU size on their modem/router. Yes this was SDSL, but it does sound like your MTU size is the problem. If you are using windows 2000 server (as we are) we had to look at setting the registry keys EnablePMTUDiscovery and EnablePMTUBHDetect on the 2000server. Once we did this we could print using tcpip over the VPN to a remote office printer etc whereas without it we could not. A way to prove this without playing with registry keys is to run the free DRTCP utility on a pc at each end and set the MTU at the pcs to 1418 or something lower?. Then restart pc/networking and see if you can then ping. if you can, the MTU is the problem. To get default MTU back use DRTCP and blank the MTU field and apply.

 

[johnny99]

As others already said, to me it also sounds as a MTU problem.
I have also seens this once when there was a firewall that blocked all ICMP traffic and had the "do not fragment" bit turned on.

What happend in that installation was that one network had a sligtly smaller MTU size then the rest so when a packet was send that was larger the the smal MTU size and the "do not fragment" bit was turned on, the ICMP packets that was returned was never received because they where dropped by the firewall.

/johnny

 

[pgerth]

You're not going to get anything by upping the MTU beyond 1500 and might be better off to lower it. Ethernet has a max frame length of 1514 bytes, deduct the headers from that and you end up with ~ 1460 bytes. Since you're going through a VPN you'll have an additional header or wrapper, deduct another 40 or so bytes or so. If your ISP is doing PPOE deduct again. Now you said you can ping using packet lenghts of ~1900 bytes, that tells you that fragmentation is allowed, else nothing would get through.
You didn't say how far apart the sites were or what type of applications are woprking across the link. You also didn't mention the type of links, ADSL, Frame Relay or ? Hows the return time on the link, use the pathping command on a host, it'll tell you loss and delay for each hop. Look at the router and VPN stats for help.

---p

 

[DamonC]

Thanks for the replies everyone.

We have a bit of a workaround - but it's not ideal, and we are still unable to ping anything over 1913 bytes in size.

It is an Ethernet network, the return time on the link is max 3ms, and there is only one router in between the 2 devices (tracert shows 2 hops, 2nd hop is the WAN address of the destination device).

Here is what we have done:

I have confirmed the MTU that exists between the two DI-804HV routers. The MTU is 1500, which I found by pinging the external interface with the ‘do not fragment’ flag set. I was able to ping with a load of 1472 bytes, which is what I would expect for an Ethernet network. After adding 28 bytes to account for the ICMP overhead, this confirms a MTU of 1500. We have set the WAN interface of both DI-804HV routers with this value.

I have also successfully been able to ping across the VPN, between Windows 2003 Server computers on each respective network, with the ‘do not fragment’ flag set and a load of 1472 bytes. This would suggest that default MTU settings (MTU=1500) on each of the servers should be fine. However, when we try and transfer data between the servers (via the VPN) the transfer fails.

The only way we have been able to achieve any sort of acceptable performance is to set the MTU of all computers, at both ends of the circuit with an MTU of 576. With this setting applied, we can copy data between computers on both sides of the VPN – however, this is not a satisfactory solution for us as is very inefficient and there are a variety of circumstances that we cannot change the MTU of some workstations.

Interestingly, just as before, we are still unable to ping between the two servers with a load greater than 1913 bytes (this is without the ‘do not fragment’ flag set)