Slow VPN To Remote Site

ashrobbo · 11 Feb 2011 at 11:09

Hi GUys,

We are having some slow VPN issues. Office holds 6 staff, who RDP via VPN to our terminal servers here in our main office.

Main office has Pix 506E running a vpn tunnel to a Cisco 877 at the remote site.

They are experiencing drop outs and hangs quite often, making it unbearable slow to work on. Cisco isnt my strong point in all fairness, I set up the 877 using the GUI interface (which I know isnt ideal, but was easy enough to get up and running).

After googleing on fragmentation Ive tried lowering the MTU of the dialer 0 interface to 1400 (did an ping -l -f to figure out the value and then took 50 bytes off).

Use pc's in remote site that open an automatic desktop then the RDP connection opens up, not really intensive stuff.

Any ideas?

Ash

this hasnt really helped anything

Moley · 11 Feb 2011 at 11:13

Do a ping and leave it running for several minutes to see if there are any drop outs, also on the router do a "show int" and check to make sure the interfaces aren't showing any errors.

edscdk · 11 Feb 2011 at 11:23

do you know its a software / vpn issue?

set a ping from router to router going bypassing the VPN?

set up a non vpn session to bypass VPN so you can test transfer speeds / RDP while bypassing the vpn... probably something not to do if you are on a secure site / bank / etc...

did it once work and now is slow?

have to set a monitor going to see whats talking over the line? (assuming its not a vpn / software issue)...

have you checked they are not trying to download virus / windows updates over your vpn?

^^ sorry jsut a list of more things to test really and no answers...

ashrobbo · 11 Feb 2011 at 11:52

Show int reported no errors on the interface, here is a ping test.

From remote site - To Head office.
Reply from 10.0.0.221: bytes=32 time=49ms TTL=127
Reply from 10.0.0.221: bytes=32 time=600ms TTL=127
Reply from 10.0.0.221: bytes=32 time=55ms TTL=127
Reply from 10.0.0.221: bytes=32 time=288ms TTL=127
Reply from 10.0.0.221: bytes=32 time=56ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=49ms TTL=127
Reply from 10.0.0.221: bytes=32 time=50ms TTL=127
Reply from 10.0.0.221: bytes=32 time=54ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=410ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=271ms TTL=127
Reply from 10.0.0.221: bytes=32 time=46ms TTL=127
Reply from 10.0.0.221: bytes=32 time=286ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=46ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=54ms TTL=127
Reply from 10.0.0.221: bytes=32 time=64ms TTL=127
Reply from 10.0.0.221: bytes=32 time=43ms TTL=127
Reply from 10.0.0.221: bytes=32 time=204ms TTL=127
Reply from 10.0.0.221: bytes=32 time=50ms TTL=127
Reply from 10.0.0.221: bytes=32 time=500ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=56ms TTL=127
Reply from 10.0.0.221: bytes=32 time=455ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=47ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=277ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=66ms TTL=127
Reply from 10.0.0.221: bytes=32 time=678ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=518ms TTL=127
Reply from 10.0.0.221: bytes=32 time=44ms TTL=127
Reply from 10.0.0.221: bytes=32 time=303ms TTL=127
Reply from 10.0.0.221: bytes=32 time=53ms TTL=127
Reply from 10.0.0.221: bytes=32 time=88ms TTL=127
Reply from 10.0.0.221: bytes=32 time=45ms TTL=127

Few high MS replies.

From Head office to remote office:

Pinging 10.0.4.1 with 32 bytes of data:
Reply from 10.0.4.1: bytes=32 time=622ms TTL=255
Reply from 10.0.4.1: bytes=32 time=759ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=732ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=47ms TTL=255
Reply from 10.0.4.1: bytes=32 time=713ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=636ms TTL=255
Reply from 10.0.4.1: bytes=32 time=630ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=45ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=754ms TTL=255
Reply from 10.0.4.1: bytes=32 time=52ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=55ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=45ms TTL=255
Reply from 10.0.4.1: bytes=32 time=45ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=864ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=50ms TTL=255
Reply from 10.0.4.1: bytes=32 time=47ms TTL=255
Reply from 10.0.4.1: bytes=32 time=598ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=46ms TTL=255
Reply from 10.0.4.1: bytes=32 time=45ms TTL=255

This is what i've tried,

- Reducing MTU on dialer 0 on remote site Cisco 877 to 1400
- Reducing MTU on PIX here to also 1400

This is a new office, we have 1 other office that uses a vpn connection and this did have similar issues, but these were cured after upgrading to a Cisco 877 (from an 837, This site had 10 users).

This is an IPSEC VPN Tunnel FYI,

Thanks for the assistance guys.

Yamahahahahaha · 11 Feb 2011 at 12:06

If you haven't already, you may need to apply the updated modem firmware to the router.
You can check this by doing 'show dsl int' and looking for the last four lines above the line stats. It should be similar to this;
Init FW: init_AMR_4.0.018.bin
Operation FW: AMR-E-4.0.018.bin
FW Source: external
FW Version: 4.0.18

The file is called adsl_alc_20190.bin which should be available either on the Cisco website or through tech support.

ashrobbo · 11 Feb 2011 at 12:17

Mine shows this on the remote site:

Init FW: init_AMR-3.0.014_no_bist.bin
Operation FW: AMR-3.0.014.bin
FW Source: embedded
FW Version: 3.0.14

so it looks lik eit is out of date, will i need to reload my config?

Yamahahahahaha · 11 Feb 2011 at 12:42

Only changing the IOS will effect the ability to run the config. So you're fine.

It's just a case of copying the new file to flash0 and power cycling the router.

There are different versions like .20 and .21 but .18 works with the majority of ADSL services in the UK.

ashrobbo · 11 Feb 2011 at 14:32

Yamahahahahaha said:
Only changing the IOS will effect the ability to run the config. So you're fine.

It's just a case of copying the new file to flash0 and power cycling the router.

There are different versions like .20 and .21 but .18 works with the majority of ADSL services in the UK.

OK so ive copied the .bin file to the flash, will it automatically load it on reloading the router?

Thanks for the Help,

Ash

Yamahahahahaha · 11 Feb 2011 at 14:50

The file name needs to be adsl_alc_20190.bin for it to load.

And yes, it'll grab it once you restart.

Basically there was a problem with the SNR (Noise margin) on the DSL interface slowly degrading until it dipped into negative figures and dropped out. This sounds similar to what you're experiencing.

ThorpedoUK · 12 Feb 2011 at 02:06

Whats the bandwidth site to site? (lowest)

One side is dropping the connection, have you figured out which side this is? I will take a guess and choose the 877.

The PIX does not directly control the ATM, so what sits infront of it and bridges VPN traffic to it?

BTW: Google Citrix Xendesktop, it gives you 10 free licenses and is far superior to RDP.
BTWBTW: Fire up Zenoss or OpenNMS, configure SNMP traps on your 877 and aim at one of these two, they are quite lightweight and will run on almost anything Linux based.

Not sure what ping is going to show you that you don't already know.

ashrobbo · 14 Feb 2011 at 17:03

Hi Guys,

Thanks for the help, the firmware update seems to have solved the issue!! happy days.

I've lowered the MTU to stop fragmentation too.

Everything seems a lot more responsive and no drop out or hangs so far!

Thanks again,

Ash

ThorpedoUK · 19 Feb 2011 at 00:02

Nice job!!!