Hello, whilst setting up IPSEC, I discovered, that isakmpd answers with NO_PROPOSAL_CHOSEN if you mix up the phase 2 ID's, here the src/dst IPs of the rule.
I think this is misleading, since as I understand it, NO_PROPOSAL_CHOSEN should be sent, if the clients can't find a matching encryption algorithm in phase 2. Please correct me here, if I'm wrong. 172-Oct 13 21:51:15 PFusch isakmpd[21124]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id ac10015f: 172.16.1.95, responder id ac100100/ffffff00: 172.16.1.0/255.255.255.0 173:Oct 13 21:51:15 PFusch isakmpd[21124]: dropped message from 172.16.1.95 port 500 due to notification type NO_PROPOSAL_CHOSEN I think this should make it more clear to state that it's the message id and not the enc algorithm. Don't be to harsh, it's the first patch I ever made. Index: src/sbin/isakmpd/ike_quick_mode.c =================================================================== RCS file: /cvs/src/sbin/isakmpd/ike_quick_mode.c,v retrieving revision 1.101 diff -u -r1.101 ike_quick_mode.c --- src/sbin/isakmpd/ike_quick_mode.c 15 Aug 2007 21:05:45 -0000 1.101 +++ src/sbin/isakmpd/ike_quick_mode.c 14 Oct 2008 16:27:12 -0000 @@ -1699,7 +1699,7 @@ (exchange->doi->decode_ids("initiator id %s, responder" " id %s", ie->id_ci, ie->id_ci_sz, ie->id_cr, ie->id_cr_sz, 1))); - message_drop(msg, ISAKMP_NOTIFY_NO_PROPOSAL_CHOSEN, 0, 1,0); + message_drop(msg, ISAKMP_NOTIFY_INVALID_MESSAGE_ID, 0, 1,0); goto cleanup; }