10-16-2009 08:52 AM - edited 02-21-2020 03:44 AM
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.
Solved! Go to Solution.
10-20-2009 11:07 AM
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
10-21-2009 09:29 PM
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.
10-16-2009 08:53 AM
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): 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
10-16-2009 08:54 AM
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.
10-19-2009 11:53 AM
It appears AT&T provided me with incorrect information. I changed my transform-set to MD5 and it came right up.
10-20-2009 11:07 AM
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
10-20-2009 11:45 AM
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
10-20-2009 12:08 PM
I searched Cisco and Google and couldn't readily find a list defining the Notify Message #'s.
Any idea if such a list exists?
10-21-2009 09:29 PM
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.
10-22-2009 10:02 AM
Thank you again. This has been very very helpful.
Denny
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: