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;
        }

Reply via email to