vpn performance issues

[dano1979]

Hello,

We have a few site 2 site VPN's setup (PIX515 as the host and 501's as the remote peer) and we recently changed DSL providers at one location. They seem to be having a lot of lag or hanging so to speak. The users are doing a RDP session back to the host site and there are a few PC's using a Terminal Emulation program and that also will hang for about 30 seconds. It's become noticable to the users and causing problems. I have the MTU inside and outside set to 1500 which is what is was set to before with our previous DSL circuit. Should the NIC speed be hardcoded? I'm running out of ideas and looking for some help.

Thanks,
Dan

 

[Supergrrover]

drop the mtu as a test. what do the logs say? have you one a speed and latency test on the line?


Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[dano1979]

Ok, dropped the MTU to 1492 on the outside interface. Still didn't fix the issue. I can ping the site fine from both ends via the vpn tunnel with good response times, right around 42ms. We have another site that has higher response times and they don't have the same issues, perhaps because they're using a cable modem? Speed and Latency appears to be good.

 

[Supergrrover]

Have you done a speed test when they experience the lag?
Are both sides 1492 or lower for the mtu?

Check the logs and see if things are getting dropped.


Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[baddos]

All your inside interfaces and hosts MTU should be left alone to default 1500. Your DSL may very well have a low MTU. I know my home DSL has a mtu at 1200 something. The way you can find out if your ISP doesn't know what the MTU should be is to use the do not fragement option and ping your ISP's router (dsl router's default gateway).

To do this from windows, you would use "ping -f -l 1500 x.x.x.x". Change x.x.x.x to your router's default gateway. If ping cannot ping saying packet needs to be fragmented, then lower the mtu until you get successful pings.

Some dsl routers also have an auto mtu discovery option as well.

 

[dano1979]

Ok I got this figured out. I was doing a trace route from the remote location to the host site and discovered the 11th hop was timing out. I'm almost 100 percent positive that may be the issue. What do you guys think? I'm pretty sure the ip is owned by one communications which is our communications provider. Hopefully I can communicate this to them. Thanks for the help.

Dan

 

[baddos]

Traceroute help, but you can't really use that as a final answer because a lot of people now block icmp traffic. So when you reach their network, it will always look down.