<div dir="ltr">Hi,<div><br></div><div>I have a related question with that.</div><div><br></div><div>with auto=route and action=trap I see that the first packet in matching traffic is always lost: in a ping session, packet with seq=1 never makes it to the other side, only from seq=2 onwards.</div><div><br></div><div>Why does this happen? and is there a way to avoid it? I'm thinking about SNMP traps over IPSec that are not retransmitted since they use UDP.</div><div><br></div><div>Thanks,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2020 at 6:47 AM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Victor,<br>
<br>
> That could be the case, thanks for the hint. Strongswan could have made 3<br>
> attempts after detecing a dead peer and given up, is that what you<br>
> imply?<br>
<br>
Yes.<br>
<br>
> What's the timeout between keyingtries?<br>
<br>
No timeout between them, regular retransmission timeouts apply for each<br>
attempt.<br>
<br>
> And why is<br>
> `keyingtries=%forever` not the default?<br>
<br>
Who knows, legacy reasons maybe (on the other hand, the default is 1 now<br>
with swanctl.conf).<br>
<br>
> Is there no need for `keyingtries=%forever` in the `auto=route` mode?<br>
<br>
Further traffic will trigger another acquire (it might even cause<br>
duplicate SAs if a retry occurs while traffic triggers another acquire<br>
from the kernel).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>