[strongSwan] Multiple %aquire-netlink messages in ipsec status

[Sascha Kinz]

Hi Folks,

I'm running a Ubuntu Server 10.04.03 LTS with latest patches. I'm using 
Strongswan from Ubuntu Lucid packages. Ipsec version shows following 
output:Linux strongSwan U4.3.2/K2.6.32-35-server
I have 26 ipsec tunnels. Some connections setup's are equal and some 
setups differ.
When I do a ipsec status I got the following %aquire-netlink messages:

000 "internal LAN Address"/32:55155 -> "Remote LAN Address"/32:161 => 
%hold:17 0    %acquire-netlink
000 "internal LAN Address" -> "Remote LAN Address"/32:2889 => %hold:6 
0    %acquire-netlink
000 "internal LAN Address"/32:1536 -> "Remote LAN Address"/32:12346 => 
%hold:6 0    %acquire-netlink
000 "internal LAN Address"/32:4639 -> "Remote LAN Address"/32:2889 => 
%hold:6 0    %acquire-netlink

When i restart the ipsec daemon everything is ok. After daemon restart 
the ipsec status shows no %aquire-netlink messages and everything looks 
good. The tunnels work fine although these messages appear. After a few 
days the %aquire-netlink messages will appear again.

Here is an example configuration for a tunnel setup with the message. 
Its a ADSL Line with a connection reset after 24h.

config setup
         #charondebug=ike3,enc3,dmn3,chd3,net3
         #plutodebug=control
         strictcrlpolicy=no
         nat_traversal=yes
         keep_alive = 20s
         charonstart=yes
         plutostart=yes
         interfaces=%defaultroute

include /var/lib/strongswan/ipsec.conf.inc

conn xyz
         auth=esp
         esp=3des-md5
         ike=3des-md5-modp1024
         left=%defaultroute
         leftnexthop=xxx.xxx.xxx.xxx
         right=xxx.xxx.xxx.xxx
         rightsubnet=xxx.xxx.xxx.xxx
         authby=secret
         pfs=yes
         leftsubnet=xxx.xxx.xxx.xxx
         auto=start
         dpdaction=restart
         dpddelay=10
         dpdtimeout=60

I found some "netlink" messages in the log: netlink recvfrom() of 
response to our XFRM_MSG_DELPOLICY message for policy 
int.0 at xxx.xxx.xxx.xxx was too long: 100 > 36

When in the Log file a netlink recvfrom()... messages comes up, in 
syslog this message is logged:
Nov 25 06:17:41 vpngate charon: 16[KNL] creating delete job for ESP 
CHILD_SA with SPI 6945dd20 and reqid {16389}
Nov 25 06:17:41 vpngate charon: 17[JOB] CHILD_SA with reqid 16389 not 
found for delete

I don't know if it is at the moment a real problem while communication 
looks good. But maybe it could be a problem in future? Hopefully 
somebody could help. Searching in the Internet and the mailing list 
didn't help me.

Here is the full log file:

Nov 25 05:14:20 vpngate pluto[31774]: "xyz" #541: DPD: No response from 
peer - declaring peer dead
Nov 25 05:14:20 vpngate pluto[31774]: "xyz" #541: DPD: Terminating all 
SAs using this connection
Nov 25 05:14:20 vpngate pluto[31774]: "xyz" #538: deleting state 
(STATE_QUICK_I2)
Nov 25 05:14:20 vpngate pluto[31774]: "xyz" #541: deleting state 
(STATE_MAIN_I4)
Nov 25 05:14:20 vpngate pluto[31774]: DPD: Restarting connection "xyz"
Nov 25 05:14:20 vpngate pluto[31774]: netlink recvfrom() of response to 
our XFRM_MSG_DELPOLICY message for policy int.0 at xxx.xxx.xxx.xxx was too 
long: 100 > 36
Nov 25 05:14:20 vpngate pluto[31774]: netlink recvfrom() of response to 
our XFRM_MSG_DELPOLICY message for policy int.0 at xxx.xxx.xxx.xxx was too 
long: 100 > 36
Nov 25 05:14:20 vpngate pluto[31774]: "xyz" #559: initiating Main Mode
Nov 25 05:15:30 vpngate pluto[31774]: "xyz" #559: max number of 
retransmissions (2) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKE message
Nov 25 05:15:30 vpngate pluto[31774]: "xyz" #559: starting keying 
attempt 2 of at most 3
Nov 25 05:15:30 vpngate pluto[31774]: "xyz" #560: initiating Main Mode 
to replace #559
Nov 25 05:16:40 vpngate pluto[31774]: "xyz" #560: max number of 
retransmissions (2) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKE message
Nov 25 05:16:40 vpngate pluto[31774]: "xyz" #560: starting keying 
attempt 3 of at most 3
Nov 25 05:16:40 vpngate pluto[31774]: "xyz" #564: initiating Main Mode 
to replace #560
Nov 25 05:16:49 vpngate pluto[31774]: packet from xxx.xxx.xxx.xxx:500: 
received Vendor ID payload [Dead Peer Detection]
Nov 25 05:16:49 vpngate pluto[31774]: "xyz" #565: responding to Main Mode
Nov 25 05:16:51 vpngate pluto[31774]: packet from xxx.xxx.xxx.xxx:500: 
received Vendor ID payload [Dead Peer Detection]
Nov 25 05:16:51 vpngate pluto[31774]: "xyz" #566: responding to Main Mode
Nov 25 05:16:59 vpngate pluto[31774]: packet from xxx.xxx.xxx.xxx:500: 
received Vendor ID payload [Dead Peer Detection]
Nov 25 05:16:59 vpngate pluto[31774]: "xyz" #567: responding to Main Mode
Nov 25 05:16:59 vpngate pluto[31774]: "xyz" #567: Peer ID is 
ID_IPV4_ADDR: 'xxx.xxx.xxx.xxx'
Nov 25 05:16:59 vpngate pluto[31774]: "xyz" #567: sent MR3, ISAKMP SA 
established
Nov 25 05:16:59 vpngate pluto[31774]: "xyz" #568: responding to Quick Mode
Nov 25 05:17:00 vpngate pluto[31774]: "xyz" #568: Dead Peer Detection 
(RFC 3706) enabled
Nov 25 05:17:00 vpngate pluto[31774]: "xyz" #568: IPsec SA established 
{ESP=>0x1003da1d <0xcfbb107a}
Nov 25 05:17:10 vpngate pluto[31774]: "xyz" #564: received Vendor ID 
payload [Dead Peer Detection]
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #564: Peer ID is 
ID_IPV4_ADDR: 'xxx.xxx.xxx.xxx'
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #564: ISAKMP SA established
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #569: initiating Quick Mode 
PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#564}
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #569: Dead Peer Detection 
(RFC 3706) enabled
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #569: sent QI2, IPsec SA 
established {ESP=>0x1003da1e <0x39f8270f}
Nov 25 05:17:11 vpngate pluto[31774]: "xyz" #564: received Delete 
SA(0x1003da1d) payload: deleting IPSEC State #568
Nov 25 05:17:59 vpngate pluto[31774]: "xyz" #565: max number of 
retransmissions (2) reached STATE_MAIN_R1

Best regards
Sascha Kinz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111129/7fa90008/attachment.html>