Martin,<br><br>Thank you.<br><br>My config excerpts:-<br>config setup<br>    crlcheckinterval=180<br>    strictcrlpolicy=no<br>    plutostart=no<br>    charonstart=yes<br><br>ca ipsec-certificate-authority<br>    cacert=ipsec-certificate-authority.certificate.pem<br>
    auto=add<br><br>include /etc/ipsec.d/ipsec.mesh.conf<br><br>(ipsec.mesh.conf)<br>conn %default<br>    ikelifetime=60m<br>    keylife=20m<br>    rekeymargin=3m<br>    keyexchange=ikev2<br>    # My IP address for default route (ie eth0)<br>
    # We can not use %defaultroute (eg if using DHCP, or multiple routes because of an aliased interface)<br>    left=10.0.0.54<br>    leftcert=certificate.pem<br>    leftsendcert=always<br>    rightsendcert=always<br>    auto=start<br>
<br><br>conn local-amqp<br>    right=10.0.0.52<br>    rightid="C=GB, ST=County Durham, L=Gateshead, O=StormMQ Limited, OU=<a href="http://amqp.stormmq.com">amqp.stormmq.com</a>, CN=<a href="http://amqp.stormmq.com">amqp.stormmq.com</a>"<br>
    rightca="C=GB, ST=County Durham, L=Gateshead, O=StormMQ Limited, OU=<a href="http://stormmq.com">stormmq.com</a>, CN=<a href="http://stormmq.com">stormmq.com</a> IPSec Certificate Authority"<br><br>... others similar<br>
<br>We use bonded interfaces, bond0, with aliased ip addresses - in this case bond0 is the internal ip address 10.0.0.54.<br><br>We've identified a chain of events, in which many connections to our HTTP server end up in CLOSE_WAIT - this seems to happen because mid-connection an IP address is being blacklisted by iptables (using xt_recent module). At this point, connections in CLOSE_WAIT reach c. 500 or so and ipsec seems to then fall over... Blaclkisting occurs because a connection from a valid IP and http client is identified as 'Invalid' by iptables - as a solitary ACK packet initiating a connection. The source IP address is not one covered by ipsec routes.<br>
<br>It's not clear which causes what - iptables, HTTP server or ipsec. My suspicision is that CLOSE_WAITs occur because the http releasing a resource fails because of blacklisting - but why should ipsec's netlink code then fail subsequently?<br>
<br>Raph<br><br clear="all">Raphael Cohn<br>Managing Director<br>raphael.cohn@StormMQ.com<br>StormMQ Limited<br><br>UK Office: <br>Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom<br>
Telephone: +44 845 3712 567<br><br>Registered office:<br>78 Broomfield Road, Chelmsford, Essex, CM1 1SS, United Kingdom<br>StormMQ Limited is Registered in England and Wales under Company Number 07175657<br>StormMQ.com<br>

<br><br><div class="gmail_quote">On 25 October 2010 08:39, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Raph,<br>
<div class="im"><br>
> creating rekey job for ESP CHILD_SA with SPI cbf0f0af and reqid {3720}<br>
</div><div class="im">> creating rekey job for ESP CHILD_SA with SPI c3a35904 and reqid {3721}<br>
</div><div class="im">> creating delete job for ESP CHILD_SA with SPI c2eb09ce and reqid {3720}<br>
</div><div class="im">> creating delete job for ESP CHILD_SA with SPI cbf0f0af and reqid {3720}<br>
</div><div class="im">> creating delete job for ESP CHILD_SA with SPI c3b5dc9e and reqid {3721}<br>
</div><div class="im">> creating delete job for ESP CHILD_SA with SPI c3a35904 and reqid {3721}<br>
</div><div class="im">> creating rekey job for ESP CHILD_SA with SPI c665f5aa and reqid {3722}<br>
</div><div class="im">> creating rekey job for ESP CHILD_SA with SPI c1ccd29a and reqid {3718}<br>
</div>> ...<br>
<br>
The kernel triggers many rekey/delete events for the installed CHILD_SAs<br>
concurrently. What is your rekey configuration (lifetime/margin/fuzz)?<br>
<br>
Regards<br>
<font color="#888888">Martin<br>
<br>
</font></blockquote></div><br>