Solved: L2L VPN not coming up, or is it?

dennylester · ‎10-16-2009

I've been banging my head against a wall trying to figure this one out and I'm stumped. I've been trying to setup a LAN to LAN VPN between our network (Pix515e) and AT&T (IOS Router). AT&T provided the following configuration information.

ATT's peer address is 209.183.xxx.yyy

IKE Phase I settings:

3des

sha1 or md5

pre-shared key

DH group 2

IPSec phase II settings:

3des

Sha

Pre-shared key:****

ATT's ACL or Local/Remote Network List:

permit ip 192.168.80.0 0.0.0.255 192.168.3.0 0.0.0.15

Here is my config, which should match theirs. You can also see my hit counters are climbing for NoNat and Interesting traffic.

**********************************************************************************************************************************

IPSEC Configuration

**********************************************************************************************************************************

access-list ATTIPSecACL permit ip 192.168.3.0 255.255.255.240 192.168.80.0 255.255.255.0

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

crypto map SSVPN 9 ipsec-isakmp

crypto map SSVPN 9 match address ATTIPSecACL

crypto map SSVPN 9 set peer 209.183.xxx.yyy

crypto map SSVPN 9 set transform-set att

isakmp key ******** address 209.183.xxx.yyy netmask 255.255.255.255 no-xauth no-config-mode

isakmp policy 7 authentication pre-share

isakmp policy 7 encryption 3des

isakmp policy 7 hash md5

isakmp policy 7 group 2

isakmp policy 7 lifetime 28800

isakmp policy 9 authentication pre-share

isakmp policy 9 encryption 3des

isakmp policy 9 hash sha

isakmp policy 9 group 2

isakmp policy 9 lifetime 28800

access-list ATTIPSecACL line 1 permit ip 192.168.3.0 255.255.255.240 192.168.80.0 255.255.255.0 (hitcnt=161)

access-list nonat line 16 permit ip 192.168.3.0 255.255.255.240 192.168.80.0 255.255.255.0 (hitcnt=5312)

**********************************************************************************************************************************

Due to size limits, I will post the debug in a second post.

Patrick0711 · ‎10-20-2009

Yup, you would have been able to determine this by the notify message sent back from the peer:

ISAKMP (0): processing NOTIFY payload 14 protocol 3

Notify message 14 is a "NO_PROPOSAL_CHOSEN" message which indicates an unsuccessful Phase 2 SA proposal

View solution in original post

Patrick0711 · ‎10-21-2009

RFC 2408:

http://www.faqs.org/rfcs/rfc2408.html

Section '3.14.1 Notify Message Types'

6.x code will not display the meaning of the notify message types, even at the highest debug levels.

7.x and above code will display the meaning of the notify messages in the higher-level debug outputs.

It's always best to troubleshoot the IKE negotiation by examining your debugs as the responder, however, knowing these message types will help you troubleshoot as the initiator.

View solution in original post

dennylester · ‎10-16-2009

Here is the output from debug crypto isakmp, ipsec, and engine

ISAKMP (0:0): sending NAT-T vendor ID - rev 2 & 3

ISAKMP (0): beginning Main Mode exchange

crypto_isakmp_process_block:src:209.183.xxx.yyy, dest:63.167.xxx.yyy spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing SA payload. message ID = 0

ISAKMP (0): Checking ISAKMP transform 1 against priority 7 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash MD5

ISAKMP: default group 2

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 28800

ISAKMP (0): atts are acceptable. Next payload is 0

ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T

ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR

ISAKMP (0:0): constructed HIS NAT-D

ISAKMP (0:0): constructed MINE NAT-D

ISAKMP (0:0): Detected port floating

return status is IKMP_NO_ERROR

crypto_isakmp_process_block:src:209.183.xxx.yyy, dest:63.167.xxx.yyy spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing KE payload. message ID = 0

ISAKMP (0): processing NONCE payload. message ID = 0

ISAKMP (0): processing vendor id payload

ISAKMP (0): remote peer supports dead peer detection

ISAKMP (0): processing vendor id payload

ISAKMP (0): speaking to another IOS box!

ISAKMP (0): processing vendor id payload

ISAKMP (0): received xauth v6 vendor id

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT match MINE hash

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT match HIS hash

ISAKMP (0): ID payload

next-payload : 8

type : 1

protocol : 17

port : 500

length : 8

ISAKMP (0): Total payload length: 12

return status is IKMP_NO_ERROR

crypto_isakmp_process_block:src:209.183.xxx.yyy, dest:63.167.xxx.yyy spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing ID payload. message ID = 0

ISAKMP (0): processing HASH payload. message ID = 0

ISAKMP (0): SA has been authenticated

ISAKMP (0): beginning Quick Mode exchange, M-ID of -1073275296:c0071e60IPSEC(key

_engine): got a queue event...

IPSEC(spi_response): getting spi 0x1ceb70cb(485191883) for SA

from 209.183.xxx.yyy to 63.167.xxx.yyy for prot 3

return status is IKMP_NO_ERROR

ISAKMP (0): sending INITIAL_CONTACT notify

ISAKMP (0): sending NOTIFY message 24578 protocol 1

VPN Peer: ISAKMP: Added new peer: ip:209.183.xxx.yyy/500 Total VPN Peers:5

VPN Peer: ISAKMP: Peer ip:209.183.xxx.yyy/500 Ref cnt incremented to:1 Total VPNPeers:5

crypto_isakmp_process_block:src:209.183.xxx.yyy, dest:63.167.xxx.yyy spt:500 dpt:500

ISAKMP (0): processing NOTIFY payload 14 protocol 3

spi 485191883, message ID = 8338705

ISAKMP (0): deleting spi 3413175068 message ID = 3221692000

return status is IKMP_NO_ERR_NO_TRANSIPSEC(key_engine): request timer fired: count = 1,

(identity) local= 63.167.xxx.yyy, remote= 209.183.xxx.yyy,

local_proxy= 192.168.3.0/255.255.255.240/0/0 (type=4),

remote_proxy= 192.168.80.0/255.255.255.0/0/0 (type=4)

ISAKMP (0): beginning Quick Mode exchange, M-ID of -1084598074:bf5a58c6IPSEC(key_engine): got a queue event...

IPSEC(spi_response): getting spi 0x9f947e5(167331813) for SA

from 209.183.xxx.yyy to 63.167.xxx.yyy for prot 3

crypto_isakmp_process_block:src:209.183.xxx.yyy, dest:63.167.xxx.yyy spt:500 dpt:500

ISAKMP (0): processing NOTIFY payload 14 protocol 3

spi 167331813, message ID = 689271268

ISAKMP (0): deleting spi 3846699273 message ID = 3210369222

return status is IKMP_NO_ERR_NO_TRANS

dennylester · ‎10-16-2009

Here is the show crypto isakmp sa and show crypto ipsec sa

In the show crypto ipsec sa, you can see all the traffic increments the sent errors counter.

**********************************************************************************************************************************

pixfirewall# show crypto isakmp sa

Total : 5

Embryonic : 0

dst src state pending created

209.183.xxx.yyy 63.167.xxx.yyy QM_IDLE 0 0

*****************Others have been removed************************

**********************************************************************************************************************************

pixfirewall# show crypto ipsec sa

local ident (addr/mask/prot/port): (192.168.3.0/255.255.255.240/0/0)

remote ident (addr/mask/prot/port): (192.168.80.0/255.255.255.0/0/0)

current_peer: 209.183.xxx.yyy:0

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 111, #recv errors 0

local crypto endpt.: 63.167.xxx.yyy, remote crypto endpt.: 209.183.xxx.yyy

path mtu 1500, ipsec overhead 0, media mtu 1500

current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

**********************************************************************************************************************************

I am completely stumped.

dennylester · ‎10-19-2009

It appears AT&T provided me with incorrect information. I changed my transform-set to MD5 and it came right up.

Patrick0711 · ‎10-20-2009

Yup, you would have been able to determine this by the notify message sent back from the peer:

ISAKMP (0): processing NOTIFY payload 14 protocol 3

Notify message 14 is a "NO_PROPOSAL_CHOSEN" message which indicates an unsuccessful Phase 2 SA proposal

dennylester · ‎10-20-2009

Hi Patrick,

I guess I need to track down a list of the notify messages as I was looking for something a little clearer than a number.

At least I know what to look for the next time.

Thank you for pointing this out as it really helps.

Denny

dennylester · ‎10-20-2009

I searched Cisco and Google and couldn't readily find a list defining the Notify Message #'s.

Any idea if such a list exists?

Patrick0711 · ‎10-21-2009

RFC 2408:

http://www.faqs.org/rfcs/rfc2408.html

Section '3.14.1 Notify Message Types'

6.x code will not display the meaning of the notify message types, even at the highest debug levels.

7.x and above code will display the meaning of the notify messages in the higher-level debug outputs.

It's always best to troubleshoot the IKE negotiation by examining your debugs as the responder, however, knowing these message types will help you troubleshoot as the initiator.

dennylester · ‎10-22-2009

Thank you again. This has been very very helpful.

Denny