[strongSwan] strongswan seems to go mad after some time

Christoph Anton Mitterer calestyo at scientia.net
Mon Oct 4 13:03:52 CEST 2010

Hi Martin.

>> I do not understand why port 4500 is used. I shouldn't have a NATed
>> setup.
> A MOBIKE enabled peer always switches to port 4500 for IKE_AUTH, this is
> the intended behavior.
Ah I see :)

Just out of curiosity:
In both cases (I mean 500 and 4500) I cannot make firewall rules to just
udp with sport and dport 500
udp with sport and dport 4500
but each only with dport 500/4500, right?

Because with NAT the sport can be different anyways (due to the NAT) and
with non-NAT the port 500 seems to be configurable in strongswan.
Is the port 4500 also configurable?

> Looks like a bug if reauth=yes is used in conjunction with
> dpdaction=restart and uniqueids=yes. If an IKE_SA is deleted for some
> reason, the responding peer tries to reestablish the same with the
> restart action. However, the peer deleting the SA actually does a
> reauthentication by close-and-reestablish, resulting in redundant
> IKE_SAs. This probably triggers the unique checking of an IKE_SA, and
> again, deletes one of them.
Just for my understanding:
rekey = yes is important, or otherwise my connections will be closed after
the end of the key lifetime.
reauth = yes means just that if a rekey happens, than the authentication
(e.g. via certificates) is also re-done.

And I guess I (in my scenario) need the dpdaction=restart (in conjunction
with the keyingtries = %forever) to guarantee that a connection is no
simply closed once the peer becomes) temporarily unavailable or has some
problems in setting it up again. So reauth=no is the only "solution" for me
for now?!

> The main issue here is the problematic reauthentication procedure
> defined by the IKEv2 protocol. I'd highly recommend to disable it with
> reauth=no, as it is usually useless from a security perspective if the
> user does not have to reenter his credentials manually.
Mhh ok,.. yeah,.. perhaps with one exception, that one peer looses his
credentials (the cert) completely, or it expires?!

> There is currently a discussion about a proper reauthentication
> extensions for IKEv2 on the IPsec mailing list. We probably should drive
> that thing forward and fix all the problems resulting from
> reauthentication.
Ok :)
btw: is there some bug-tracker for strongswan, where one could hook up
such issues in order to allow end users (like me) to some how trace these
things better?


More information about the Users mailing list