[Swan-dev] [libreswan/libreswan] About Ipsec IPAddresspool (#377)

[Paul Wouters]

On Fri, 30 Oct 2020, kamalsust wrote:

> Describe the issue
> I have installed this script successfully. After running couple of hour I can't connect ot VPN Server from iOS client.
> It's seems to be an issue of ip_addresspool. I have found following comments from libreswan addrespool implementation

> created by lease_an_address if an existing or lingering lease for the
> same thatid isn't found.
> released (to linger or freed) by rel_lease_addr.
> current code never frees a lease that could be shared.
> ??? This constitutes a leak.
> */
> which means when addresspool would be full then it wouldn't clear it's unused pool.

That is only when two conns share an addresspool and one conn has it in
use, the other one cannot free it. I don't think this is your issue.

> How do i solve the problem or how do i increase the addresspool also.
> To Reproduce
> I am serving multipool user using same username and password. After running sometimes the addresspool goes to be full.

It is likely related to you using the PSK. It means for each connection
from the same user we cannot (in time) determine this is a re-connect,
so a new IP is assigned. Then it will take an hour for unused, idle
connections to go away and release the lease.

What version of libreswan are you using?

> rightaddresspool=192.168.43.10-192.168.43.250

How many real users are connecting? 150 would be a lot for a few users
reconnecting?

> If I increse the rightaddresspool like 192.168.43.250 to 192.168.83.250 then client can connect to server but no internet access.

That is a _very_ large addresspool. Still wonder why that makes your
router fail?

> Some times I get following as Ipsec Service log:
> 
> pluto[1040425]: "xauth-psk"[15838] 213.205.241.87 #16522: them: 213.205.241.87[%any,+MC+XC+S=C]===192.168.43.145/32
> pluto[1040425]: "xauth-psk"[15838] 213.205.241.87 #16522: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode {ESP/NAT=>>
> pluto[1040425]: "xauth-psk"[15838] 213.205.241.87 #16522: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x03f948ad <0x00b16fc5 xfrm=AES>
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: STATE_XAUTH_R0: retransmission; will wait 16 seconds for response
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: XAUTH: Sending Username/Password request (XAUTH_R0->XAUTH_R0)
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: STATE_XAUTH_R0: retransmission; will wait 32 seconds for response
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: XAUTH: Sending Username/Password request (XAUTH_R0->XAUTH_R0)
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: STATE_XAUTH_R0: 60 second timeout exceeded after 7 retransmits. No response (or no accept>
> pluto[1040425]: "xauth-psk"[15836] 89.189.188.111 #16520: deleting state (STATE_XAUTH_R0) aged 66.530s and sending notification
> pluto[1040425]: #16520: deleting connection "xauth-psk"[15836] 89.189.188.111 instance with peer 89.189.188.111 {isakmp=#0/ipsec=#0}
> lines 1-23/23 (END)

It seems that the client went away after some failing. The IKEv1 XAUTH
protocol is a little flaky because both ends retransmit on packet drops.
It would be better to move your clients to IKEv2. So this would take up
a lease, but it should only take it up for 60 seconds and then free.
Can you see in the logs if that is happening?

> and sometimes I get like as follows:
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16523: STATE_MODE_CFG_R1: ModeCfg Set sent, expecting Ack {auth=PRESHARED_KEY cipher=AES_CBC_256 >
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16523: the peer proposed: 0.0.0.0/0:0/0 -> 192.168.43.145/32:0/0
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: responding to Quick Mode proposal {msgid:81106fcb}
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: us: 0.0.0.0/0===167.71.116.96[MS+XS+S=C]
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: them: 202.134.14.134[10.236.154.244,+MC+XC+S=C]===192.168.43.145/32
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode {ESP/NAT=>>
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: STATE_QUICK_R1: retransmission; will wait 0.5 seconds for response
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: STATE_QUICK_R1: retransmission; will wait 1 seconds for response
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: STATE_QUICK_R1: retransmission; will wait 2 seconds for response
> pluto[1040425]: "xauth-psk"[15764] 202.134.14.134 #16524: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x0c97eb1f <0xbb9c66f8 xfrm=AES>

So this is fine, but it does show there is some packet loss happening
causing retransmits. But in this case it established fine.

Paul