[Swan] releasing old connection to free the route
paul.wouters at aiven.io
Mon Jan 24 17:52:10 EET 2022
On Mon, 24 Jan 2022, Christoph Litauer wrote:
> I use libreswan 3.29 on an Ubuntu 20.04.3 LTS.
> Until now we had a l2tp-setup using openswan 2.6.49 on an ubuntu 16.04.7. No problems, we had hundreds of users in parallel. Some of these users by accident use the same local ip address.
> For security we have to upgrade to Ubuntu 20 and thus had to change to libreswan. Setup is nearly identical. But now we have a serious problem:
> - User A uses local ip 192.168.55.45 behind NAT. Public IP is 188.8.131.52
> - User B uses local ip 192.168.55.45 behind NAT. Public IP is 184.108.40.206
> A starts the tunnel. As soon es B starts his tunnel, the tunnel for A is terminated and vice versa.
Do they use a unique ID or are these clients that pick their native IP
as ID? If so, they would both share the same ID 192.168.55.45 and
libreswan would assume this is a reconnect. The libreswan behaviour
depends a bit on whether certs or PSKs are used.
You can try setting uniqueids=no in "config setup" because I believe
Windows clients do use their pre-NAT IP as the ID for l2tp.
A more modern solution would be to migrate to IKEv2 and avoid the
whole problem of transport mode and virtual-private= and L2TP
I would be interested in a full debug log of this event of a second
client connecting with both openswan and libreswan if you can, so
I can better understand the differece and if there is a libreswan
mitigation we can do.
More information about the Swan