[strongSwan] Strange behaviour

[Raphael Cohn]

Martin,

Thank you.

My config excerpts:-
config setup
    crlcheckinterval=180
    strictcrlpolicy=no
    plutostart=no
    charonstart=yes

ca ipsec-certificate-authority
    cacert=ipsec-certificate-authority.certificate.pem
    auto=add

include /etc/ipsec.d/ipsec.mesh.conf

(ipsec.mesh.conf)
conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyexchange=ikev2
    # My IP address for default route (ie eth0)
    # We can not use %defaultroute (eg if using DHCP, or multiple routes
because of an aliased interface)
    left=10.0.0.54
    leftcert=certificate.pem
    leftsendcert=always
    rightsendcert=always
    auto=start


conn local-amqp
    right=10.0.0.52
    rightid="C=GB, ST=County Durham, L=Gateshead, O=StormMQ Limited, OU=
amqp.stormmq.com, CN=amqp.stormmq.com"
    rightca="C=GB, ST=County Durham, L=Gateshead, O=StormMQ Limited, OU=
stormmq.com, CN=stormmq.com IPSec Certificate Authority"

... others similar

We use bonded interfaces, bond0, with aliased ip addresses - in this case
bond0 is the internal ip address 10.0.0.54.

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.

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?

Raph

Raphael Cohn
Managing Director
raphael.cohn at StormMQ.com
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN,
United Kingdom
Telephone: +44 845 3712 567

Registered office:
78 Broomfield Road, Chelmsford, Essex, CM1 1SS, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number
07175657
StormMQ.com


On 25 October 2010 08:39, Martin Willi <martin at strongswan.org> wrote:

> Hi Raph,
>
> > creating rekey job for ESP CHILD_SA with SPI cbf0f0af and reqid {3720}
> > creating rekey job for ESP CHILD_SA with SPI c3a35904 and reqid {3721}
> > creating delete job for ESP CHILD_SA with SPI c2eb09ce and reqid {3720}
> > creating delete job for ESP CHILD_SA with SPI cbf0f0af and reqid {3720}
> > creating delete job for ESP CHILD_SA with SPI c3b5dc9e and reqid {3721}
> > creating delete job for ESP CHILD_SA with SPI c3a35904 and reqid {3721}
> > creating rekey job for ESP CHILD_SA with SPI c665f5aa and reqid {3722}
> > creating rekey job for ESP CHILD_SA with SPI c1ccd29a and reqid {3718}
> > ...
>
> The kernel triggers many rekey/delete events for the installed CHILD_SAs
> concurrently. What is your rekey configuration (lifetime/margin/fuzz)?
>
> Regards
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20101025/27d49541/attachment.html>