cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1748
Views
0
Helpful
6
Replies

IPSec tunnel dropping

chesebrgr
Level 1
Level 1

Hello,

I have set up a IPSec VPN between two 3845 routers:

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

crypto isakmp key XXXXXXXXXXXX address 1.1.1.1

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

crypto map MyCryptoMap local-address GigabitEthernet0/1

crypto map MyCryptoMap 15 ipsec-isakmp

set peer 1.1.1.1

set transform-set CTransformSet

set pfs group2

match address CryptoC

ip access-list extended CryptoC

permit ip 192.168.1.0 0.0.0.255 1.1.1.0 0.0.0.255

And similar on the other side. It all works great, once the tunnel is up and running. However if I don't send any data from the 192.168.1 network to the 1.1.1 network for a while (5-10 minutes?), it seems to drop the tunnel, and the first request I make fails (I guess because the tunnel is establishing). Subsequent requests work fine again, but the first one always fails.

Is there any way to (preferably) make the first request succeed? Or if not, how to make the tunnel not drop after a certain time has passed? I have tried:

crypto ipsec security-association lifetime kilobytes 536870912

crypto ipsec security-association lifetime seconds 86400

crypto isakmp keepalive 10

...with no success! "show crypto ipsec sa" tells me there's plenty of time remaining on the inbound and outbound esp:

sa timing: remaining key lifetime (k/sec): (513953358/5739)

6 Replies 6

Michael Muenz
Level 5
Level 5

Can you please enable debugging on ipsec and isakmp and wait the 5-10 minutes what the routers say?

Michael

Please rate all helpful posts

Michael Please rate all helpful posts

debug crypto ipsec

debug crypto isakmp

I just get this block:

Jul 19 12:50:48.145: ISAKMP (0:134217734): received packet from 1.1.1.1 dport 500 sport 500 Global (R) QM_IDLE     

Jul 19 12:50:48.145: ISAKMP: set new node -46235277 to QM_IDLE     

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1): processing HASH payload. message ID = -46235277

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1): processing NOTIFY DPD/R_U_THERE protocol 1

        spi 0, message ID = -46235277, sa = 64F91240

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):deleting node -46235277 error FALSE reason "Informational (in) state 1"

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):DPD/R_U_THERE received from peer 1.1.1.1, sequence 0x4BD2106F

Jul 19 12:50:48.145: ISAKMP: set new node 32334157 to QM_IDLE     

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1

        spi 1886462640, message ID = 32334157

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1): seq. no 0x4BD2106F

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1): sending packet to 1.1.1.1 my_port 500 peer_port 500 (R) QM_IDLE

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):purging node 32334157

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE

Jul 19 12:50:48.145: ISAKMP:(0:6:SW:1):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

... every few minutes. It doesn't seem to be regular: 12:50:48, 12:53:00, 13:04:04, 13:07:36...even though the keepalive is set to 10 seconds. Not sure why that is.

When it "drops", there's no logging and when it reestablishes there's nothing either. Which seems to suggest it's not actually dropping..... but when I remove the IPSec tunnel, I don't get the problem. So it must be something to do with it.

What about the debugs on the other machine?

Michael

Please rate all helpful posts

Michael Please rate all helpful posts

Hi Mark,

I have couple of questions to ask,

On either of the routers do you have any previous vpn configured either l2l or remote vpn? if yes, please can you copy the crypto map commands and paste lets see?

What is your routing to the destination like?

I recently faced such related to the first question I asked. I had on an ASA a l2l and Remote VPN configured, those were working perfectly fine no issues whatsoever. This happend last friday and saturday!

I configured the third l2l vpn with ASA3. All my configs were fine and all that.....but the tunnel kept dropping after a while and it goes int different mode state, showing MM_Active, MM_WAIT_MSG 2-6. Mine did pass traffic for a while but stopped.

I the problem was that I placed the crypto map for the ASA3 connection at the bottom....Crypto maps work just like you ACL! Your router would treat it just the same way! If you L2L is very important then move it  i mean the crypto map statement above any other you have.

Also you have to look at the routing for your network just so you make sure all the packets get to desination as expected.

I hope this helps out as you expect.

Teddy

Michael,

The debugs on the other side look the same. There's nothing apart from R_U_THERE messages.

Teddy,

On one of the other routers there is a VPN to another company, this one seems to remain up and has R_U_THERE packets every 20 seconds without fail. I don't understand why I am not getting keepalives on this connection every 20 seconds? Config:

crypto map MyCryptoMap 5 ipsec-isakmp

set peer XXX.xXX.XXX.XXX

set transform-set PTransformSet

set pfs group2

match address CryptoP

It's exactly the same as our tunnel but with different IP's and password.

Both sites have public internet connections. With the VPN up, I get 100% packet transfer, but if I don't send any data for 5-10 minutes, the first few packets I send fail. Without the VPN tunnel I get 100% packet transfer - even if I leave it idle the first packets succeed.


Hi Mark!

Hmmm this is strange, what is the lifetime you have on both routers for you phase1 and 2 for both routers?

Here is the below url that might futher help you in getting this perfectly resolved.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml

look it up and see, you just might not know it might be a little misconfig.

Have a good one!

Teddy