I messed with this a bit more. My main question was does the "set
isakmp-profile" actually force the IOS to tie the profile to a crypto
map entry even when in responder mode. The answer is yes.
To test, I created the following (its PSK as opposed to Certs, but
still validated the behavior I desired)--
crypto isakmp profile MYPROFA
keyring default
match identity address 192.168.20.1
crypto isakmp profile MYPROFB
keyring default
match identity address 0.0.0.0
crypto map CMAP 10 ipsec-isakmp
set peer 192.168.20.1
set transform-set aes128
set isakmp-profile MYPROFB
So I peered this router to 192.168.20.1. Outbound connections used
MYPROFB as expected based on the initiator profile. If I initiated
the tunnel from 192.168.20.1, I received a failure (see the debug
below). If I change the "set isakmp-profile" to MYPROFA, or deleted
it altogether or delete the profile itself, it works as a responder
and allows incoming sessions. So the moral of the story is the P1 SA
profile assignment is checked against the set isakmp-profile as P2
SA's are built.
When you see this type of failure, you might see a message as follows--
*Apr 1 12:33:33.467: ISAKMP:(1070):atts are acceptable.
*Apr 1 12:33:33.467: ISAKMP:(1070): IPSec policy invalidated proposal
with error 32
*Apr 1 12:33:33.467: ISAKMP:(1070): phase 2 SA policy not acceptable!
(local 192.168.20.2 remote 192.168.20.1)
*Apr 1 12:33:33.467: ISAKMP: set new node 1382828144 to QM_IDLE
*Apr 1 12:33:33.467: ISAKMP:(1070):Sending NOTIFY PROPOSAL_NOT_CHOSEN
protocol 3
spi 1695892080, message ID = 1382828144
*Apr 1 12:33:33.467: ISAKMP:(1070): sending packet to 192.168.20.1
my_port 500 peer_port 500 (R) QM_IDLE
*Apr 1 12:33:33.467: ISAKMP:(1070):Sending an IKE IPv4 Packet.
*Apr 1 12:33:33.467: ISAKMP:(1070):purging node 1382828144
*Apr 1 12:33:33.471: ISAKMP:(1070):deleting node 1582851472 error
TRUE reason "QM rejected"
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
