cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
45763
Views
0
Helpful
15
Replies

Error "Death by retransmission P1" with an IPsec tunnel between two routers

Vincent Fortrat
Level 1
Level 1

Hello,

I have a problem with an IPSec tunnel between a 877W router and a 1812 router. Configuration on both routers seems to be OK as soon as the tunnel is going up but goes down after a while. I get those logs :

040687: *Apr 16 10:50:44.415 PCTime: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer X.X.X.X)

040688: *Apr 16 10:50:57.867 PCTime: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.X)

The 1812 router is ending 2 IPSec tunnel and the second one is working fine. The 877W is behind another router which is performing NAT. Is there something special in this configuration?

Any tips or ideas?

Thanks for your help,

Vincent

15 Replies 15

andrew.prince
Level 10
Level 10

The device that is performing NAT needs to forward the following:-

UDP 500

UDP 4500

Protocol 50

HTH>

The device that is performing is already redirecting every port to the 877W router.

The output of the logs indicate no reply from the remote end.

Debug the remote end when you try and initiate a VPN connection.

HTH>

Tunnel has been up during the night but just went down. I join the logs from "debug crypto isakmp".

It appears that the routeur is trying to establish an ISAKMP SA on UDP/500 port even if we're NATed and doesn't try to rebuild it on UDP/4500 port. Both isakmp and non500-isakmp are allowed in the ACL applied on both side's interfaces.

UDP4500 is NAT-T, this is negotiated for the IPSEC VPN operation after ISAKMP Phase 1 and IPSEC Phase 2 have been sucessfully negotiated.

Your logs indicate ISAKMP is not completing.

UDP500 is ISAKMP.

I suggest you double check all configuration.

I checked my configuration and there is a matching isakmp policy. Here is the result of "show crypto isakmp policy" on both routers :

prtratalys01#sh crypto isakmp policy

Global IKE policy

Protection suite of priority 2

encryption algorithm: Three key triple DES

hash algorithm: Secure Hash Standard

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 28800 seconds, no volume limit

Protection suite of priority 10

encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 86400 seconds, no volume limit

Default protection suite

encryption algorithm: DES - Data Encryption Standard (56 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Rivest-Shamir-Adleman Signature

Diffie-Hellman group: #1 (768 bit)

lifetime: 86400 seconds, no volume limit

--------------------------------------------------

877-StPathus#sh crypto isakmp policy

Global IKE policy

Protection suite of priority 10

encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 86400 seconds, no volume limit

Default protection suite

encryption algorithm: DES - Data Encryption Standard (56 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Rivest-Shamir-Adleman Signature

Diffie-Hellman group: #1 (768 bit)

lifetime: 86400 seconds, no volume limit

Looks OK - policy 10 on 877 device mactches priority 10 on other decvice.

Now I suggest you double check any devices "in front" of the VPN devices to makes sure all access is un-restricted for VPN's.

The 1812 router is in front of Internet and 877 router is passing through a business livebox (from french ISP Orange). I will check if there is any access limitation on this device.

The NAT enabled device between router and internet doesn't filter any kind of traffic. Actually there was another tunnel going through it before configuring this one.

Have you debugged the remote end to confirm the requests are reaching the remote end?

Yes, they are. The first logs I sent to this post was from the remote end :

040687: *Apr 16 10:50:44.415 PCTime: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer X.X.X.X)

040688: *Apr 16 10:50:57.867 PCTime: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.X)

post your configs for review.

Hello Andrew,

Here are the configuration files of both routers and some additional logs.

Thanks for your help,

I just figured it out what the problem was. I added on both routers the global configuration command "crypto ipsec nat-transparency spi-matching". The VPN tunnel is now up since friday without any problem.

Thanks Andrew,

Vincent