[Swan] releasing old connection to free the route
Christoph Litauer
litauer at uni-koblenz.de
Wed Jan 26 17:03:20 EET 2022
Hi,
I uploaded
- libreswan.log - excerpt from syslog regarding the two connections from 87.156.203.224 and 185.66.195.84
- openswan.log - same using the older openswan server, which support to parallel connections
- libreswan-pluto.log - another try with plutodebug=control
- openswan-pluto.log - same using openswan
would be very nice of you could take a look?
> Am 25.01.2022 um 09:00 schrieb Christoph Litauer <litauer at uni-koblenz.de>:
>
> Paul, thanks a lot for your quick response.
>
> I checked the log. Indeed, the peer id is the native ip. We already had uniqueids=no but we are using PSK. According to the manpage this setting ist ignored when authby=secret is used.
> I should have mentioned, that the described behaviour belongs solely to windows clients (we think so, but did not check very hard).
>
> Today, I am not able to create a new test case on the openswan server, will do tomorrow. Here you can find libreswan.log and my ipsec.conf:
> https://cloud.uni-koblenz-landau.de/s/52fmDgFX9dMG4yF
>
> Will upload an openswan.log as soon as we have it.
>
>> Am 24.01.2022 um 16:52 schrieb Paul Wouters <paul.wouters at aiven.io>:
>>
>> 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 87.156.203.224 - User B uses local ip 192.168.55.45 behind NAT. Public IP is 185.66.195.84
>>>
>>> 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
>> protocol overhead.
>>
>> 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.
>>
>> Paul
>
> --
> Freundliche Grüße
> Christoph Litauer
> _________________________________________
> Christoph Litauer
> Uni Koblenz, Rechenzentrum, Raum A 022
> Postfach 201602, 56016 Koblenz
> Fon: +49 261 287-1311, Fax: -100 1311
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
--
Freundliche Grüße
Christoph Litauer
_________________________________________
Christoph Litauer
Uni Koblenz, Rechenzentrum, Raum A 022
Postfach 201602, 56016 Koblenz
Fon: +49 261 287-1311, Fax: -100 1311
More information about the Swan
mailing list