Cisco IPsec VPN problems on Satellite broadband

[jimbosmith]

Hi all, I'm a non-techie looking for some help so please excuse my ignorance...

We recently had to switch to satellite broadband following a house move to enable my wife to work from home. After being assured by the satellite provider (Tooway in the UK) that any issues with the VPN her employer has in place (Cisco) would be due to upload speed and nothing else, we've discovered that whenever she connects to the VPN the connection speed drops from 3mb down / 0.2mb up, to 0.2mb down / 0.02 up which makes email and the online databases she needs for work impossible to use.

From what I can work out, it appears that the system the satellite provider has in place to get around the latency is being stripped out by the VPN and the inherent latency is slowing it right down (something to do with TCP 'handshakes' having to go on a long trip each time?!?!). But what do I know so that might be rubbish.

The problem we have is that we really need to get it fixed yesterday (workload is suffering) and Tooway don't seem to have a clue and my wife's IT support (at a global company) stare at her blankly.

So my question - does anyone know of a way of telling the VPN client (5.0.6 ??) to ignore the latency and let the data pass through at the normal speed or have a realistic workaround / other solution (I can't see her IT people changing that much if I'm honest).

If we can't fix it, we've got to move house. Again.....help!

[andrew.prince]

Jim,

I would suggest that your wife should ask her IT dept to use UDP encapsulation for the IPSEC Client.

Tell them they should configure:-

crypto isakmp nat-traversal  20

- This will ensure that UDP 4500 is used.

HTH>

[jimbosmith]

Hi Andrew,

Thanks for the advice but those settings are apparently already in place. The best suggestion the IT team have come up with is switching from the Intel wireless manager to the Windows one. I might not be a techie but that doesn't fill me with confidence. We suggested switching to SSL but they'd need to move thousands of people and that's not going to happen.

Any other suggestions (aside from moving?).

[andrew.prince]

I have had working VPN client on a 56kbps GPRS and 2000ms round trip connection with no issues - slow;  but no issues.

Post a screen shot of the "statistics" of the connected session (right click the padlock in the windows status bar)

[jimbosmith]

Hi, screen shot below.

Not sure about the MTU settings - will check.

Thanks for the advice guys, really appreciated.

Cheers,

J

[andrewswanson]

hello

     have you tried reducing the MTU size? see here for cisco vpn documentation:

http://www.cisco.com/en/US/docs/security/vpn_client/cisco_vpn_client/vpn_client500_501/administration/5vcAch11.html#wp1153482

     alternatively, you can use drtcp:

http://www.dslreports.com/drtcp

try 1300 or lower - reboot pc when done - if it doesn't help with the vpn, reverse the MTU change.

hth

andy

[andrew.prince]

When you install the clent - it automatically changes the mtu of all network adapaters found.

I see from the screen shot - they are using UDP encapsulation, but no compression.

Ask the IT boys to enable compression.

[andrewswanson]

hello
    yes, the vpn client sets all adapters mtu to 1300 as default as per the document:

http://www.cisco.com/en/US/docs/security/vpn_client/cisco_vpn_client/vpn_client500_501/release/notes/51client.html#wp1193117

you can check if 1300 is ok by:

1 connect to your work vpn service

2 ping an ip address (X.X.X.X which should be an ip adddress at your work accessible by vpn) down the vpn tunnel from a command prompt using an mtu size 1299:

    ping X.X.X.X -f -l 1299

3 if you get "Packet needs to be fragmented but DF set." try the command again using a lower mtu:

    ping X.X.X.X -f -l 1290

4 keep going till you get a reply from X.X.X.X and then try setting your adapter mtu accordingly

hth
andy