[strongSwan] 5.0.1rc1 and FreeBSD

[Mao, Zhiheng]

Hi Tobias,

I am also seeing this UDP_ENCAP error in 5.0.1rc1 on my Red Hat  Enterprise Linux 5.6 machine. I did not see it in the 5.0.0 release, so looks like this error is new in 5.0.1 and is happening not only on the FreeBSD:
Sep 27 11:44:53 sit-iwf charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, Linux 2.6.18-238.el5, x86_64) 
Sep 27 11:44:53 sit-iwf charon: 00[KNL] unable to set UDP_ENCAP: Protocol not available 
Sep 27 11:44:53 sit-iwf charon: 00[NET] enabling UDP decapsulation failed

Thanks!

Zhiheng


-----Original Message-----
From: users-bounces+zmao=qualcomm.com at lists.strongswan.org [mailto:users-bounces+zmao=qualcomm.com at lists.strongswan.org] On Behalf Of Tobias Brunner
Sent: Thursday, September 27, 2012 3:51 AM
To: David Shane Holden
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] 5.0.1rc1 and FreeBSD

Hi David,

> The first was some simple compile errors which I think I fixed in the 
> attached patch.

Thanks, applied to master.

> On startup I get the following messages:
> 
> 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, FreeBSD 
> 9.0-RELEASE-p4, amd64) 00[KNL] unable to set UDP_ENCAP: Invalid 
> argument 00[NET] enabling UDP decapsulation failed

This happens when the NAT-T IPv6 socket is opened and the daemon tries to enable UDP en-/decapsulation for that port.  Linux supports this for IPv6, FreeBSD apparently not.  The patch at [1] improves the error message if this fails.  As long as it works for IPv4 (requires the kernel to be built with the IPSEC_NAT_T option) this should be fine.

> 03[NET] received packet: from 192.168.1.201[500] to 192.168.1.1[500] 
> 03[KNL] 192.168.1.1 is not a local address or the interface is down 
> 03[NET] received packet from 192.168.1.201[500] to 192.168.1.1[500] on 
> ignored interface

This is caused by a new check for inbound packets which together with the new options charon.interfaces_ignore and charon.interfaces_use allow one to ignore specific interfaces.  Unfortunately, the map used for this check in kernel-pfroute was not properly initialized, see [2] for a patch.  Actually, the patch at [3] avoids the check altogether if the above options are not used.

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=45178362
[2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=9845391a
[3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2e2feffb

_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users