VPN Issue

Barrypr

Hi all, I'm working on a remote acces VPN at the moment, its set up and working OK, however when we connect to the VPN and try to RDP to the server it is very very slow.

I have been on the phone with cisco tech all morning(4 hours), it seems when the got the RDP to work fast, the Internet speed for the LAN PC's dropped, and when we got the Internet working fast, the RDP to the server was slow again.

In the end I was told that the overhead and encryption is causing this to be slow, he also tweaked around with the speed settings adjust-mss and also mtu, the customer we are doing this for is complaing how slow the connection is, and I cant see anything else we can do at this stage, they also said that the there may not be much of a difference if we set up the site to site VPN, I have not a great detail of info in regards to VPN as I only have the CCNA done, so a lot of it is over my head.

Any info or advice would be great

ilcram19-2

are you using transport or tunnuel mode?
also you can try to make a GRE tunnel or a GRE/IPSEC tunnel to see if that makes any diference,

Barrypr

I got an email with from cisco with his recommendation:

Hi Barry,

So as mentioned before the header size of the IPSec information in your
setup is as follows:

20 bytes IPsec header (tunnel mode)
4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header)
8 byte IV (IOS ESP-DES/3DES)
6 byte pad (ESP-DES/3DES 64 bit)
1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer)
12 bytes ESP SHA 96 digest

So a total of 56 bytes.

As agreed I will proceed with the closure of the case.

If you believe there is a slowness problem I suggest you get the
transfer numbers as we've discussed and open a case. We will be happy to
investigate.

Thanks for contacting us and Best Regards.

--

Jose
Customer Support Engineer - Security Team

cisco_trooper

Where is the VPN terminating? Is it an ASA firewall, a PIX? How's the CPU etc on that device? Also, how is the bandwidth for the device utilizing remote access? If they have a measley DSL line that it going to be part of the problem.

ilcram19-2

Barrypr wrote: »

I got an email with from cisco with his recommendation:

Hi Barry,

So as mentioned before the header size of the IPSec information in your
setup is as follows:

20 bytes IPsec header (tunnel mode)
4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header)
8 byte IV (IOS ESP-DES/3DES)
6 byte pad (ESP-DES/3DES 64 bit)
1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer)
12 bytes ESP SHA 96 digest

So a total of 56 bytes.

As agreed I will proceed with the closure of the case.

If you believe there is a slowness problem I suggest you get the
transfer numbers as we've discussed and open a case. We will be happy to
investigate.

Thanks for contacting us and Best Regards.

--

Jose
Customer Support Engineer - Security Team

well unless you have a really slow link that affects the encryption/decryption process other wise you should be fine unless is a bug on the IOS, but like i said try another aproach you can also try DMVPN tunnel see if that have better, results, also what kind of traffic are you pulling from the end point (dc,file sharing/ voice/ etc) if you dont have a qos in place alot of the aplicattions could be sucking the bandwith or you probably have some one using limewire or something, i would stop waiting on cisco and do something myself i've seen cases where the people from cisco say it just wont work just to close ur case instead of finding a solution good thing i dont have to deal with them

Barrypr

Well we installed a cisco 1841 series out there, there topology was:

modem--sonicwall--switch

The modem was removed as well as sonicwall so now its just

router--switch

What they have is a company 50 or so miles away that want to connect to the server via RDP through the VPN, they want to use this for some kind of training using the sage software package, so they will be using it every day, the way it is now they cant really do this, its far too slow, even logging onto the server you type the password and wait a while before it even enters the keys you have typed.

But like I said the company I work for don't really work with cisco alot, it was left to me to set this up, there are around 12 PCs that are connected to the switch and a few ip phones, so this does not seem like a lot of overhead, he said that it being slow was normal, I find this hard to believe!

I dont want to go at this too much they rely on the Internet heavily, when it does do down they lose money, and they have had a lot of downtime recently due to:

Me having to config this on my own( with just CCNA Knowledge)
Me not have having any real word hands on cisco experience.

ilcram19-2

Barrypr wrote: »

Well we installed a cisco 1841 series out there, there topology was:

modem--sonicwall--switch

The modem was removed as well as sonicwall so now its just

router--switch

What they have is a company 50 or so miles away that want to connect to the server via RDP through the VPN, they want to use this for some kind of training using the sage software package, so they will be using it every day, the way it is now they cant really do this, its far too slow, even logging onto the server you type the password and wait a while before it even enters the keys you have typed.

But like I said the company I work for don't really work with cisco alot, it was left to me to set this up, there are around 12 PCs that are connected to the switch and a few ip phones, so this does not seem like a lot of overhead, he said that it being slow was normal, I find this hard to believe!

I dont want to go at this too much they rely on the Internet heavily, when it does do down they lose money, and they have had a lot of downtime recently due to:

Me having to config this on my own( with just CCNA Knowledge)
Me not have having any real word hands on cisco experience.

what i would do if the vpn wasnt working corectly i'lldo a nat translation from the public ip address to the rdp port 3389 (i would change this to a non- standad port) on the side where the terminal server is at and see if thats moves faster if it does just leave like that
thats should work properly for them instead of going from the vpn u be going from the internet

cisco_trooper

ilcram19-2 wrote: »

what i would do if the vpn wasnt working corectly i'lldo a nat translation from the public ip address to the rdp port 3389 (i would change this to a non- standad port) on the side where the terminal server is at and see if thats moves faster if it does just leave like that
thats should work properly for them instead of going from the vpn u be going from the internet

You assume the powers that be are ok with RDP being exposed....eek. Make sure you aren't accidentally funneling internet bound traffic for all 12 users through this VPN connection.

ilcram19-2

cisco_trooper wrote: »

You assume the powers that be are ok with RDP being exposed....eek. Make sure you aren't accidentally funneling internet bound traffic for all 12 users through this VPN connection.

testing purposes, just to see if that make any diference on the speed to make sure that is not the vpn, plus you would even knoe what to do with it anyways lol

Barrypr

cisco_trooper wrote: »

You assume the powers that be are ok with RDP being exposed....eek. Make sure you aren't accidentally funneling internet bound traffic for all 12 users through this VPN connection.

I would be hoping the cisco tech that spent all the time with me would have pointed out any mistakes....I had 2 cases open with them at one stage each one going through what I had done.

Also I have a nat set up, our offices also connects to one of there servers on the internet via RDP, they just asked me to set this up so as they could get to this server for support which I did.

ip nat inside source list 101 interface Dialer1 overload
ip nat inside source static tcp 192.168.176.11 25 x.x.x.x 25 extendable
ip nat inside source static tcp 192.168.176.11 110 x.x.x.x 110 extendable
ip nat inside source static tcp 192.168.176.11 3338 x.x.x.x 3338 extendab
le
ip nat inside source static tcp 192.168.176.11 3389 x.x.x.x 3389 extendab
le

ilcram19-2

Barrypr wrote: »

I would be hoping the cisco tech that spent all the time with me would have pointed out any mistakes....I had 2 cases open with them at one stage each one going through what I had done.

Also I have a nat set up, our offices also connects to one of there servers on the internet via RDP, they just asked me to set this up so as they could get to this server for support which I did.

ip nat inside source list 101 interface Dialer1 overload
ip nat inside source static tcp 192.168.176.11 25 x.x.x.x 25 extendable
ip nat inside source static tcp 192.168.176.11 110 x.x.x.x 110 extendable
ip nat inside source static tcp 192.168.176.11 3338 x.x.x.x 3338 extendab
le
ip nat inside source static tcp 192.168.176.11 3389 x.x.x.x 3389 extendab
le

that should do it, but is there any diference on the speed?

Barrypr

Another few hours on phone with cisco tech today, the VPN guy brings the VPN up to be working perfect however then in the Internet slows down, I ring back and the WAN guy brings the net back and the VPN goes down....

When I use the tcp ip adjust-mss 1412 under dialer int I am unable to RDP to the server, now waiting on a call back, I have asked for the VPN support to work with WAN support this time!

Ahriakin

Maybe I've missed something but nowhere do you mentione what speed the actual Line is at both sites, and what it's current utilization is? When you mention that the 'WAN guy' gets your internet speed back what exactly is he doing, prioritizing traffic, changing any link parameters etc.? You need to know your Upload and Download speeds are enough before digging into the protocols going across them.
This was suggested by Cisco_trooper earlier, stop banging your head against a wall that may be down the wrong street....okay overuse of metaphors but I think you get the meaning

Barrypr

From what I can see all them seem to be doing is editing the adjust-mss and also the mtu values, I am kind of relying on them as like I said I have zero experience working hands on with cisco, and never set up a VPN before, but still I managed to get it up and running to a degree. The cisco tech was going on about mtu and adjust-mss alot I was unsure about what he was doing, I asked the difference between then or to explain more and he said "good question I don't really no".....Me thinking hold on ye guys have been editing these values for what a few days now and you don't no why!

The customer has a 7.6mb line down upto 672kbps upload we have the same connection.

ilcram19-2

what devices are you working with?

Ahriakin

MTU is a layer 2 adjustment, basically how big of a frame can be sent on the wire. If your host/appliance MTU is higher than the other appliances along the route your packets will be fragmented. A good way to test your MTU setting is to ping the end host with the Dont Fragment bit set and specify different packet sizes for your PING traffic, when it fails you know you've hit fragmentation, start throttling the payload size back. The highest MTU that allows the traffic through is the lowest between you and the endpoint....and it's a good idea to set yours a little lower again to allow for flux in different devices if routing changes along the way.
e.g. from Windows "ping -f -l (size) x.x.x.x"
MSS is the maximum payload size TCP will use per segment. Think of it like you need to size the Box you put your data into so that it will fit neatly into the truck you will use which in turn will fit onto the road between you and the endpoint. If this box is an ASA it can (and by default on current software does) intercept the host MSS and instead request the value you specify (1380 is a common value). MSS is advertized by both peers in the Syn's, it's up to them to honor it or not (some versions of the ASA software will drop anything that exceeds the specifeid value, the latest versions allow them by default).

Anyway the effective bandwidth between you and the other office is 672Kbps, not a lot if they are doing anything else. You need to get an idea of their line usage. As asked above knowing what devices you are using would really help.

Barrypr

Ahriakin thanks for the explanation, we finally got this sorted out and all is working well, I had a mistake in an access list, a wrong wildcard subnet mask and also a typo!

Was a good learning experience and makes me want to understand the hole process better, I enjoy working with cisco however its mostly Microsoft we deal with, got myself the cbt nuggets CCSP videos which I'm hoping will aid me.