<div dir="ltr">I always use auto=route or start_action=trap and just keep a ping running in the background for critical UDP traffic.<div><br></div><div>I know it's a poor's man solution but guarantees the connection is always up.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 10:59 AM Victor Sudakov <<a href="mailto:vas@sibptus.ru">vas@sibptus.ru</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">Victor Sudakov wrote:<br>
> Tobias Brunner wrote:<br>
> > <br>
> > > I see that the first packet in matching<br>
> > > traffic is always lost: in a ping session, packet with seq=1 never makes<br>
> > > it to the other side, only from seq=2 onwards.<br>
> > > <br>
> > > Why does this happen?<br>
> > <br>
> > It's a known property of the Linux kernel.  Packets, in particular the<br>
> > triggering one, are not cached and lost until the IPsec SAs are established.<br>
> > <br>
> > > and is there a way to avoid it?<br>
> > <br>
> > Not that I'm aware.<br>
> <br>
> Maybe using "auto=start" would be better in this scenario? When the<br>
> host wants to send an SNMP trap, the IPSec connection will have already<br>
> been established. No need for triggering.<br>
<br>
I'm almost ready to take my words back. <br>
<br>
I've experimented in my lab and it turned out that if you configure your<br>
Strongswan connections for anything other than "auto=route", you risk<br>
for some packets to be sent unencrypted until the SA is established. <br>
<br>
If you value the data in your SNMP datagrams (e.g. the community<br>
string), you may expose it.<br>
<br>
Proof:  <a href="http://admin.sibptus.ru/~vas/1.txt" rel="noreferrer" target="_blank">http://admin.sibptus.ru/~vas/1.txt</a><br>
<br>
traffic is sent unencrypted until 21:28:40.577854 when<br>
<a href="mailto:Strongswan@192.168.246.10" target="_blank">Strongswan@192.168.246.10</a> is finally up.<br>
<br>
At 21:28:58.538009 the host 192.168.246.10 is shut down and traffic from<br>
192.168.246.1 is again being sent unencrypted.<br>
<br>
-- <br>
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN<br>
2:5005/49@fidonet <a href="http://vas.tomsk.ru/" rel="noreferrer" target="_blank">http://vas.tomsk.ru/</a><br>
</blockquote></div>