> -----Original Message-----
quoted text
> From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] 
> On Behalf Of Harald Dunkel
> Sent: Monday, June 30, 2008 9:17 AM
> To: pgurumu@gmail.com
> 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.

quoted text
> 
> 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.

quoted text
> 
> 
> Regards
> 
> Harri

Mitja