> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Harald Dunkel > Sent: Monday, June 30, 2008 9:17 AM > To: [EMAIL PROTECTED] > Cc: Misc OpenBSD > Subject: Re: isakmpd -- NCP IPsec client: peer proposed > invalid phase 2 IDs > > Hi Prabhu, > > I do get a connection for > > ike passive esp from 192.168.5.0/31 to 192.168.1.249 > > but not for > > ike passive esp from 192.168.5.1 to 192.168.1.249 > > (192.168.1.249 is the remote Windows laptop running NCP IPsec client.) > > So I doubt that this is a problem of aes vs 3des. AFAICS the problem > is that isakmpd doesn't accept the proposal packet with > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.1.249 > payload: ID len: 16 type: IPV4_ADDR_SUBNET = > 192.168.5.1/255.255.255.255 [ttl 0] (id 1, len 248) > : > > If I setup an IPsec tunnel between 2 OpenBSD hosts, then the > proposal packet says > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.3 > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.1 [ttl > 0] (id 1, len 312) > : > > which seems to be fine for isakmpd.
It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size /32. As I already explained to you in a private mail, ipsecctl will export both 192.168.1.249 and 192.168.1.249/32 into IPV4_ADDR=192.168.1.249 while your windows client is sending IPV4_ADDR_SUBNET for 192.168.1.249/32, and this will not match. I have looked into changing this ipsecctl's behaviour but I can't find a clean way to do it. > > The questions are: > > Does NCP's IPsec client violate some RFC? > Can isakmpd adjusted to accept "IPV4_ADDR_SUBNET" in the proposal > packet, if this is fine with the RFCs? Since it's not an isakmpd's problem but a problem in ipsecctl parsing the config for isakmpd, you can always use the old-style isakmpd.conf config. Or see if your windows client can define a different destination type. > > > Regards > > Harri Mitja
