[Swan-dev] addresspool code and thatid bug

Paul Wouters paul at nohats.ca
Tue Aug 21 03:18:43 UTC 2018


The addresspool code uses a struct id thatid;

This is filled in with or checked against &c->spd.that.id
For authby=secret (which should never share/re-use a lease because
clients cannot be uniquely identified) this means the clients will
put their pre-NAT IP in an ID_IPV4_ADDR type ID payload.

1) For multiple clients on the same internal IP behind a different NAT,
this can be the same despite not being the same client. Which is why
authby=secret must never share a lease.

2) Somehow this struct can also end up with the IP address of
the NAT gateway (eg the IKE source ip from the server's point of view)
which causes problems for two clients behind the same NAT IP. In this
case, both clients end up with the same lease IP, which breaks the first
connected client. The issue can be seen now in xauth-pluto-28-twobehindnat
which shows the bug. I do not understand how c->spd.that.id ends up
with the IKE source IP of the client despite the client sending their
pre-NAT IP in their ID payload.

It's odd because with authby=secret, share_lease() which calls
can_share_lease() checks for POLICY_PSK and returns FALSE if allowed.

So I do not understand why the addresspool is _still_ somehow handing
out the same lease IP to the two clients.

It seems people are running into similar and the same issues as reported
on https://github.com/libreswan/libreswan/issues/166 although the logs
I was mailed actually shows two clients behind the same NAT getting a
different lease IP yet still the first client is losing connectivity.
And the odd thing is I tried to reproduce this and ended up with the
different issue (Issue 2)

Paul


More information about the Swan-dev mailing list