[strongSwan] "signal of type SIGINT received. Shutting down" ?

[Hoggins!]

Following the little diary of my experiments, here is what i believe I
found :

Because I'm doing traffic shaping at the output of my NIC (HTB with hard
capping), I believe that when there is a lot of outbound traffic in the
StrongSwan tunnel, it also clogs the available bandwidth for the whole
link, and... well, is it the DPD mechanism that can't get through fast
enough anymore, triggering a restart ? That's when bad things happen.

So I guess I should be able to define a specific prio for the packets
responsible for DPD / IKE. For that, I'm using the value ikedscp=101110
in my ipsec.conf, matching with an iptables rule to push the DSCP 0x2e
packets through a priority lane. But am I doing it right ?
Is there a better way ? What could I match to be sure that all the
signalling packets have a higher priority than the data packets ?

Thanks !

    Hoggins!

Le 20/01/2018 à 18:24, Hoggins! a écrit :
> I think I'm getting closer to what I'm looking for.
>
> So this event happens because I have dpdaction=restart. At least that's
> what I found.
> Problem is that with auto=route, if there is any connection drop, the
> tunnel is never reestablished again, hence the dpdaction=restart, which
> was obviously a workaround for me.
>
> So I guess I need to understand why :
>     - when there is excessive latency on the link, the tunnel fails
> (should I work on the replay_window parameter ? The StrongSwan "server"
> audit daemon complains with an "MAC_IPSEC_EVENT op=SA-replayed-pkt")
>     - why, after having failed, the tunnel is not reestablished, why the
> traps are not catching anything
>
>     Hoggins!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180125/80f7f2a5/attachment.sig>