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 <[email protected]>: > > 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 <[email protected]>: >> >> 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 > [email protected] > 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
