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....@lists.strongswan.org 
[mailto:users-bounces+zmao=qualcomm....@lists.strongswan.org] On Behalf Of 
Tobias Brunner
Sent: Thursday, September 27, 2012 3:51 AM
To: David Shane Holden
Cc: users@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@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

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

Reply via email to