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! Le 18/01/2018 à 14:38, Hoggins! a écrit : > Thank you Anvar, > > Le 18/01/2018 à 14:09, Anvar Kuchkartaev a écrit : >> I had similar type of error and it was kernel-libipsec plugin was >> conflicting with selinux. I disabled the kernel-libipsec and issue has been >> resolved. > However, I did not compile StrongSwan with --enable-kernel-libipsec and > no TUN device is created on the host, so I believe the plugin is already > inactive on my implementation. I guess the Truth is out there. > > Hoggins! >
signature.asc
Description: OpenPGP digital signature
