[strongSwan] had to manually up a connection

[Felipe Polanco]

I always use auto=route or start_action=trap and just keep a ping
running in the background for critical UDP traffic.

I know it's a poor's man solution but guarantees the connection is always
up.

On Mon, Mar 9, 2020 at 10:59 AM Victor Sudakov <vas at sibptus.ru> wrote:

> Victor Sudakov wrote:
> > Tobias Brunner wrote:
> > >
> > > > 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.
> > > >
> > > > Why does this happen?
> > >
> > > It's a known property of the Linux kernel.  Packets, in particular the
> > > triggering one, are not cached and lost until the IPsec SAs are
> established.
> > >
> > > > and is there a way to avoid it?
> > >
> > > Not that I'm aware.
> >
> > Maybe using "auto=start" would be better in this scenario? When the
> > host wants to send an SNMP trap, the IPSec connection will have already
> > been established. No need for triggering.
>
> I'm almost ready to take my words back.
>
> I've experimented in my lab and it turned out that if you configure your
> Strongswan connections for anything other than "auto=route", you risk
> for some packets to be sent unencrypted until the SA is established.
>
> If you value the data in your SNMP datagrams (e.g. the community
> string), you may expose it.
>
> Proof:  http://admin.sibptus.ru/~vas/1.txt
>
> traffic is sent unencrypted until 21:28:40.577854 when
> Strongswan at 192.168.246.10 is finally up.
>
> At 21:28:58.538009 the host 192.168.246.10 is shut down and traffic from
> 192.168.246.1 is again being sent unencrypted.
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49 at fidonet http://vas.tomsk.ru/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200309/dc461510/attachment.html>