Solved: One-way L2L VPN Error - 1720 to ASA5510

mmurray · ‎10-14-2009

I thought I was out of the woods with this one but I'm not. I was able to get the site-to-site tunnel up when I originate traffic from the 172.18.3.x/24 subnet going to the 172.22.3.x subnet but not the other way around.

I get this with debug crytpo isakmp sa on the 1720:

*Mar 1 04:21:03: ISAKMP (0:1): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

spi 0, message ID = -1652585053

*Mar 1 04:21:03: ISAKMP (0:1): deleting node -1652585053 error FALSE reason "informational (in) state 1"

*Mar 1 04:21:03: ISAKMP:received payload type 0

*Mar 1 04:21:03: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 74.92.14.73

*Mar 1 04:21:03: ISAKMP (0:1): received packet from 17.29.14.73 (I) QM_IDLE

*Mar 1 04:21:03: ISAKMP (0:1): processing HASH payload. message ID = -1420595240

*Mar 1 04:21:03: ISAKMP (0:1): processing DELETE payload. message ID = -1420595240

*Mar 1 04:21:03: ISAKMP (0:1): deleting node -1420595240 error FALSE reason "ISAKMP Delete notify (in)"

*Mar 1 04:21:03: ISAKMP (0:1): deleting SA reason "P1 delete notify (in)" state(I) QM_IDLE (peer 74.92.14.73) input queue 0

*Mar 1 04:21:03: ISAKMP (0:1): deleting node -1553921438 error FALSE reason "P1 delete notify (in)"

When I ping from 172.18.3.1 to 172.22.3.1 the tunnel comes up fine. I can access the 172.18.3.x subnet at this point from the 172.22.3.x subnet and all the servers there. I just can't initiate the tunnel traffic from the 1720 side.

Configs and diagram attached.

Herbert Baerten · ‎10-14-2009

I believe you still forgot to move the dynamic map on the ASA to the last position in the crypto map.

With the current config, inbound connections on the ASA always land on the dynamic map, which uses 3DES. The 1720 only offers DES, so the negotiation fails.

If you still have a problem after moving the dynamic map on the ASA, then please get the crypto debugs on both sides at the same time (deb cry isa, deb cry ips on the router; deb cry isa 10, deb cry ips 10 on the ASA) and post the entire output (e.g. if you still get PROPOSAL_NOT_CHOSEN then the part before that is interesting, as well as the corresponding part on the peer).

View solution in original post

slmansfield · ‎10-14-2009

The ISAKMP messages seem to be related to another peer, 74.92.14.73.

I'm wondering if your inbound access list on the ASA is preventing the 1720 from initiating the VPN tunnel.

Herbert Baerten · ‎10-14-2009

Where in the debugs do you see that address? I only see 17.29.14.73 which is the correct peer?

Herbert Baerten · ‎10-14-2009

Sorry, I was clearly not fully awake yet :)

The debugs indeed mention both an incorrect and the correct peer address:

*Mar 1 04:21:03: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 74.92.14.73

*Mar 1 04:21:03: ISAKMP (0:1): received packet from 17.29.14.73 (I) QM_IDLE

I'm *guessing* that the incorrect ip address is a cosmetic bug, i.e. the syslog simply prints the wrong address. Getting the full debug output (from the start of the negotiation) would confirm this.

mmurray · ‎10-15-2009

The mixup in IPs is "cosmetic". Treat the 74.92.14.73 address as if it were 17.29.14.73. I tried changing all the IPs to protect the innocent but obviously I missed one. Oh well.

Herbert Baerten · ‎10-14-2009

I believe you still forgot to move the dynamic map on the ASA to the last position in the crypto map.

With the current config, inbound connections on the ASA always land on the dynamic map, which uses 3DES. The 1720 only offers DES, so the negotiation fails.

If you still have a problem after moving the dynamic map on the ASA, then please get the crypto debugs on both sides at the same time (deb cry isa, deb cry ips on the router; deb cry isa 10, deb cry ips 10 on the ASA) and post the entire output (e.g. if you still get PROPOSAL_NOT_CHOSEN then the part before that is interesting, as well as the corresponding part on the peer).