ISAKMP Connection Issue

Greetings,

I am having a problem with my ISAKMP config on 2 routers. These routers have two T1 lines each. I first configured a Multilink between the 2 interfaces on both routers. This connection worked fine and without any issues. I then configured the ISAKMP configs on both routers and they came up and I was able to ping across to the other network with no problem. I was feeling all was right with the world. Then once the network went into production, it was a terrible lag with the larger packets. It was so bad that I had to remove the crypto map config from the interfaces. I was wondering if anybody had any ideas as to what could be the cause of this. Below is the config that is used on both routers. The only thing I can think of is that I had 9 different ACL entries so I don't know if that could have caused a lagging problem. Any assistance is appreciated.

Thanks,

conf t

ip cef

int Multilink 1
ip address 192.168.254.1 255.255.255.252
ppp multilink-group 1
ppp multilink interleave
exit

int s1/0:0
no ip load-sharing per-destination
ip load-sharing per-packet
no ip address
encapsulation ppp
ppp multilink
multilink-group 1

int s1/1:0
no ip load-sharing per-destination
ip load-sharing per-packet
no ip address
encapsulation ppp
ppp multilink
multilink-group 1

access-list 101 remark crypto config acl
access-list 101 permit ip 10.10.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.10.0.0 0.0.255.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 10.10.0.0 0.0.255.255 172.16.100.0 0.0.0.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 172.16.100.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 172.16.100.0 0.0.0.255

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 5
exit

crypto isakmp key xxxxxxxxx address 192.168.254.2

crypto ipsec transform-set xform1 ah-sha-hmac esp-3des esp-sha-hmac

crypto map FTX 10 ipsec-isakmp
set peer 192.168.254.2
set transform-set xform1
match address 101
exit

int Multilink 1
crypto map FTX

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

APA

sounds like an MTU issue to me.....

When you start using IPSec tunnels you'll learn that trying to use the standard Ethernet MTU of 1500 will cause heartache and pain due to the lag....

Try changing the MTU on both routers too something lower (1452 - 1492) and you should see performance return to normal.

Remember when encapsulating packets each protocol adds it's own header and trailer..... Some interfaces cannot handle excessive MTU sizes so you must tell the router to utilize a lower MTU to cater for the additional encapsulations. (fragment)

Hope this helps

PS :- The interface level commands are mtu (size) or ip mtu (size)

jezg76

crypto ipsec transform-set xform1 ah-sha-hmac esp-3des esp-sha-hmac

Is it common to use both AH and ESP on real-world VPNs? To me, in my limited implementation of VPNs and readings, seems like it is a bit excessiveand adding unneeded overhead.

Anyone care to expand?

APA

For full encryption of headers and payload then yes it is practical but does add the additional overhead.

Most including myself tend to build IPSec tunnels with just the esp side of encryption to ensure the payload (data) of packets are secured (After all our data is what we are trying to protect right?)

IT Man

crypto ipsec transform-set xform1 ah-sha-hmac esp-3des esp-sha-hmac

I thought the same thing about that line and was thinking that could be a cause of it. When I was given this task, some of the configs were already on the router, with that being one of them I left it the same. Since it seems that common practice is to only use the esp, I will check with my boss and see if it would be ok to just use that. I will also try lowering the MTU and see if that works. I won't be able to do it until tomorrow so I will let you guys know the outcome. Thanks for your help and suggestions.

Paul Boz

My money is on MTU also. When you add additional headers you're increasing the total size of the packet. If the total size of the header is larger than the defined MTU you'll get significant fragmentation which will cause the slowness you're describing.

IT Man

Greetings,

So for the updated....

I have removed the ah-sha-hmac section of the transform-set as well as lowered the MTU. The one thing that we could not do was RDP into one of the servers through the VPN so I tried that after making those changes. I was still unable to do so. I lowered the MTU to 1475 and 1450 and still no luck.

Any Ideas?

As always thanks for your help and suggestions!!

networker050184

Are you sure it is not an issue with RDP and not the VPN?

mikej412

IT Man wrote:

The one thing that we could not do was RDP into one of the servers through the VPN

But everything else works? You can access other services on that server or ping it from something at the remote end of the VPN tunnel?

Could you RDP to the server before you configured the VPN tunnel?

IT Man

mikej412 wrote:

IT Man wrote:

The one thing that we could not do was RDP into one of the servers through the VPN

But everything else works? You can access other services on that server or ping it from something at the remote end of the VPN tunnel?

Could you RDP to the server before you configured the VPN tunnel?

When I pull the crypto map configs from the interfaces, I am able to RDP with no problem. My guess is there is something wrong with the VPN configs that I am using, just not sure what. With the VPN up, the only thing I tried was a ping and that was successful. Like I stated before, when the site went into production, the lag on regular data, ie: internet access, accessing files on the file server, was extremely slow. I tried logging into the router on that end of the network and was able to ping the server with no problem as well.

Netstudent

Debugs always help too.....Thats what they are there for. debug crypto isakmp/ipsec sa
I think a show crypto isakmp sa will show you how many packets are going in and out that have been encrypted and decrypted.

Is it getting past phase1?

AS others have already stated, you shouldn't use authentication header and encrypted securiy payload for hashing. USe one or the other, but ESP is more secure.

To really nail down a VPN problem, debugs will tell you the most if you know ipsec.

If your tunnel is up, and you can access resources through the tunnel but you can;t RDP through the tunnel then I have to agree with MTU. I've seen MTU problems across MPLS networks with RDP. WHen I put the IP into the RDP console it would start to open the window for the remote desktop and get stuck like it was half open or something.

IT Man

Netstudent wrote:

If your tunnel is up, and you can access resources through the tunnel but you can;t RDP through the tunnel then I have to agree with MTU. I've seen MTU problems across MPLS networks with RDP. WHen I put the IP into the RDP console it would start to open the window for the remote desktop and get stuck like it was half open or something.

That is exactly my problem when I attempt an RDP session, it opens up and the screen remains black until it times out. I tried lowering the MTU to 1450 and still the same thing. I guess I can keep lowering it and see if anything improves. I also put a ticket in with Cisco so if they do find the solution, I will be sure to post it.

Thanks again for all your help and suggestions!!

APA

can you show us your configs please.... crypto and interface configs

IT Man

A.P.A wrote:

can you show us your configs please.... crypto and interface configs

I had my configs up top but here they are again:

int Multilink 1
ip address 192.168.254.1 255.255.255.252
ppp multilink-group 1
ppp multilink interleave
exit

int s1/0:0
no ip load-sharing per-destination
ip load-sharing per-packet
no ip address
encapsulation ppp
ppp multilink
multilink-group 1

int s1/1:0
no ip load-sharing per-destination
ip load-sharing per-packet
no ip address
encapsulation ppp
ppp multilink
multilink-group 1

access-list 101 remark crypto config acl
access-list 101 permit ip 10.10.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 permit ip 10.10.0.0 0.0.255.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 10.10.0.0 0.0.255.255 172.16.100.0 0.0.0.255
access-list 101 permit ip 10.20.0.0 0.0.255.255 172.16.100.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 172.16.100.0 0.0.0.255

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 5
exit

crypto isakmp key xxxxxxxxx address 192.168.254.2

crypto ipsec transform-set xform1 esp-3des esp-sha-hmac

crypto map FTX 10 ipsec-isakmp
set peer 192.168.254.2
set transform-set xform1
match address 101
exit

int Multilink 1
crypto map FTX

the only difference is I removed the ah-sha-hmac from the transform set.

APA

sorry I should have stated I wanted to see the changed config's...... I don't see the mtu re-adjustment???

Netstudent

yoou can test your MTU by using ping with the -l and -f flags.

ping yoyo.who.com -f -l 1472

ICMP has a 28 byte header so 1500 - 28 = 1472

If that goes through without needing to be fragmented then you know your MTU is 1500.

IT Man

A.P.A wrote:

sorry I should have stated I wanted to see the changed config's...... I don't see the mtu re-adjustment???

I did make those MTU changes but I put it back to 1500 when I pulled the crypto map off the interfaces. I did verify with the MTU size with the "show interface multilink 1" command

Netstudent,

I did try your ping test with the 1472 and it kept timing out. At around 1415 I am able to ping successfully across the network.

IT Man

Per the advice of the Cisco Rep....

I have changed the DH from group 5 to group 2

the hash from aes to md5

the transform set from esp-3des esp-sha-hmac to esp-3des esp-md5-hmac

With these changes I am now able to RDP into the server on the other network.

IT Man

IT Man wrote:

With these changes I am now able to RDP into the server on the other network.

OK, I recant my last statement...now its not working again

larkspur

IT Man wrote:

IT Man wrote:

With these changes I am now able to RDP into the server on the other network.

OK, I recant my last statement...now its not working again

welcome to working with vpn's. what is the config on the other side look like?

post up your debugs too ?

APA

IT Man wrote:

A.P.A wrote:

sorry I should have stated I wanted to see the changed config's...... I don't see the mtu re-adjustment???

I did make those MTU changes but I put it back to 1500 when I pulled the crypto map off the interfaces. I did verify with the MTU size with the "show interface multilink 1" command

Netstudent,

I did try your ping test with the 1472 and it kept timing out. At around 1415 I am able to ping successfully across the network.

Is that with the crypto config and VPN up?? As before you said you only lowered the MTU to 1450.... try MTU 1400 with the VPN up on your interface that are going to be passing the traffic...

See how you go..... I still think it's an MTU issue.....

Slowhand

Oh, yeah. I'm looking forward to late-night sessions of beating my head against the wall when my time for all this comes.

IT Man

Slowhand wrote:

Oh, yeah. I'm looking forward to late-night sessions of beating my head against the wall when my time for all this comes.

LET THE HEAD BEATINGS BEGIN!!!

IT Man

Let me just start out by saying that I do appreciate everybodies input on my issue. Once the jr status is removed from my title and I become a sr. network engineer, I will not forget the help you guys have given as I am sure i'll have more issues coming down the line ie. 802.1x port authentication.

So per Cisco's advice again, he recommended that I add the "ip tcp adjust-mss 1200" command to all the router interfaces that are routing the interesting traffic. I did add this to all those interfaces and it does appear to be working now. It was weird, whenever I enable the crypto map on the 2 multilink interfaces, I always have to do the router at the other site first, then the one at my location. When I apply the config at the furthest router, the session will hang until I apply the config to the router here. After adding the commands to the interfaces, when I enabled the crypto map, the router kept right on going with no hang. Either way, it does seem to have corrected the issue. I will have to keep testing because as before, it started working and within about 15 mins, it stopped again.

APA

Yeah sometimes when you help people you assume they know all the commands your talking about as well...

I automatically remember to adjust the MSS.... Sorry about this IT Man!!! Could have saved you an extra day or two if this was expressed earlier....

MTU = Size of entire packet
MSS = Size of the Payload only......

Your MSS can actually be 1415 going by your tests from earlier.... remember when using the ping command with -l it isn't going by MTU it is going by the size of the Payload of the packet so before when I mentioned changing MTU to 1400 should really try and MSS of 1400 and it should work fine..... 1200 for MSS seems really low....

IT Man

It no problem at all a.p.a. I learned alot of useful tools from this discussion that I can carry on with me. I will try to raise the MSS to 1400 and give that a test. Thanks for clearing that up too...I really had no idea what MSS was but I just did it since the recommendation came from Cisco. I planned on looking it up today.