[strongSwan] had to manually up a connection
felipeapolanco at gmail.com
Mon Mar 9 16:06:20 CET 2020
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
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
> > > > 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
> > >
> > > > 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...
More information about the Users