Project

General

Profile

Bug #764

Report IP pool is full even not so much user online!

Added by richard hu almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
charon
Target version:
Start date:
11.11.2014
Due date:
Estimated time:
Affected version:
5.2.1
Resolution:
Fixed

Description

Found this on production environment.
Some times client can not make connection and server log report:
Nov 11 04:55:30 10[IKE] <XauthRSA|1975879> peer requested virtual IP %any
Nov 11 04:55:30 10[CFG] <XauthRSA|1975879> pool '172.16.0.0/20' is full, unable to assign address
Nov 11 04:55:30 10[IKE] <XauthRSA|1975879> no virtual IP found for %any requested by '83B4C0FE-ABB7-4E89-94C8-F1830B155EE5'
There are more than 4000 ips in the pool and only several hundreds users online.
And we found that there is something threshold:
ipsec leases
Leases in pool '172.16.0.0/20', usage: 33/4094, 2 online
On one server, when reach 33/4094, the new client can not make connection.
when it decrease to lower, the client can make again.
And we also found this can be temp solve by reboot the service, but for all the server that runs for several days all have such issues.


Related issues

Has duplicate Issue #795: pool is full, unable to assign address problemClosed20.12.2014

Associated revisions

Revision 8ab1b29d (diff)
Added by Tobias Brunner over 5 years ago

mem-pool: Fix potential memory leak and lost leases when reassigning leases

If no offline leases are available for the current client and assigning online
leases is disabled, and if all IPs of the pool have already been assigned to
clients we look for offline leases that previously were assigned to other
clients.

In case the current client has online leases the previous code would
replace the existing mapping entry and besides resulting in a memory leak
the online leases would be lost forever (even if the client later releases
the addresses). If this happens repeatedly the number of available addresses
would decrease even though the total number of online and offline leases seen
in `ipsec leases` would indicate that there are free addresses available.

Fixes #764.

History

#1 Updated by richard hu almost 6 years ago

Since reboot will dismiss this issue, so can not set log level to see more logs.

#2 Updated by Tobias Brunner over 5 years ago

  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

I may have found the problem. It's a bit tricky to reproduce but there was a bug if offline leases are assigned after all addresses in a pool have been assigned at least once.

Address assignment with the in-memory pool currently works as follows:

  1. Search for an existing mapping (from identity to online and offline address leases) for the current client identity (83B4C0FE-ABB7-4E89-94C8-F1830B155EE5 in your case)
    • If a mapping is found check if there are offline leases for the client that can be reassigned
    • If there aren't any offline leases, check if available online leases are to be assigned (the charon.mem-pool.reassign_online settting in strongswan.conf controls this, it's disabled by default) and if so check if there are any for the client that can be reassigned
  2. If no IP has been found so far check if there are IPs left in the pool that have not yet been assigned to any clients, if so assign it (creates a mapping if required)
  3. If all IPs have been assigned to clients (they are now all in online/offline mappings for any client's identities) find the first offline lease in any mapping and assign that to the current client

Now with that last step there was a problem. It would unconditionally create a new mapping for the current identity, despite that there may be an existing mapping with online leases (in which case step 1 would return no address, by default). So what happen in such a case is that the existing mapping would get replaced and any online mappings would thus disappear into nirvana (so there was also a memory leak). If this happened repeatedly more and more addresses would get lost and eventually no addresses would be left to assign to clients even if there technically would be addresses free to assign.

The associated commit fixes this bug.

#3 Updated by richard hu over 5 years ago

Just a little question.
I set 172.16.0.0/30 and after one device connected:
Virtual IP pools (size/online/offline):
172.16.0.0/30: 2/1/0
the second one can not connect.
/30 can only allow one user, is this correct behavior?

#4 Updated by Tobias Brunner over 5 years ago

I set 172.16.0.0/30 and after one device connected:
Virtual IP pools (size/online/offline):
172.16.0.0/30: 2/1/0
the second one can not connect.
/30 can only allow one user, is this correct behavior?

No, that was a bug I fixed recently. Two addresses should be assignable (only the network ID and the broadcast address of the subnet will be ignored) see #744 for details.

#5 Updated by richard hu over 5 years ago

Is this bug only result in miss 1-2 IPs in an given ip range? If yes, that should not a critical issue for product system.
for your #744 comments:
/*
The first and last addresses in subnet based pools are now skipped
properly and the pools' sizes are adjusted accordingly. Which is also
the case if pools are configured with an offset, e.g. 192.168.0.100/24,
which reduces the number of available addresses from 254 to 155, and
assignment now starts at .100 not .101, i.e. .100-.254 are assignable
to clients.*/
not sure the comments related with issue I found for 172.16.0.0/30

I use http://ppa.launchpad.net/strongswan/strongswan-daily/ubuntu/pool/main/s/strongswan/ for our system, is this already contain #744?
Is this the master branch of strongswan? I also checked github branches did not find a branch name "men-pool-range" you mentioned in #744.
Could you explain a little more for above code/build relationship?

#6 Updated by Tobias Brunner over 5 years ago

Is this bug only result in miss 1-2 IPs in an given ip range?

The bug was that in a /30 subnet only one address was assignable instead of two.

not sure the comments related with issue I found for 172.16.0.0/30

Could you please post a detailed log of when the two clients connect.

I use http://ppa.launchpad.net/strongswan/strongswan-daily/ubuntu/pool/main/s/strongswan/ for our system, is this already contain #744?

These packages are built from our master branch daily (if there were any changes). And if you updated them recently (i.e. in November) then you already have the patches from #744.

I also checked github branches did not find a branch name "men-pool-range" you mentioned in #744.

I merged that branch on Oct 30th, so the changes are contained in the current master and the above packages. The patch here should also be contained in the latest packages.

#7 Updated by Dave Lewthwaite over 5 years ago

Unfortunately I am seeing this issue with the latest git master (as of today).

To replicate, set a small IP pool (e.g. rightsourceip=172.16.17.1/29) then connect/disconnect a number of times until the pool is exhausted. The client device in this case is an iPhone with iOS 8 (IKEv1). reassign_online is also defined as true in strongswan.conf

As far as I can tell, StrongSWAN will initially give out the previous IP then a few moments later go through the process again, this time using a new IP - this may be an interop bug.

Relevant log sections -

2014-11-24T15:14:21.301792+00:00 test-server charon: 14[IKE] activating new tasks
2014-11-24T15:14:21.301796+00:00 test-server charon: 14[IKE]   activating MODE_CONFIG task
2014-11-24T15:14:21.301799+00:00 test-server charon: 14[CFG] reassigning offline lease to 'OU=Devices, CN=test'
2014-11-24T15:14:21.301803+00:00 test-server charon: 14[IKE] assigning virtual IP 172.16.17.5 to peer 'OU=Devices, CN=test'

2014-11-24T15:14:21.316345+00:00 test-server charon: 15[IKE] peer requested virtual IP %any
2014-11-24T15:14:21.316352+00:00 test-server charon: 15[CFG] assigning new lease to 'OU=Devices, CN=test'
2014-11-24T15:14:21.316358+00:00 test-server charon: 15[IKE] assigning virtual IP 172.16.17.6 to peer 'OU=Devices, CN=test'

Thanks

#8 Updated by Tobias Brunner over 5 years ago

To replicate, set a small IP pool (e.g. rightsourceip=172.16.17.1/29) then connect/disconnect a number of times until the pool is exhausted. The client device in this case is an iPhone with iOS 8 (IKEv1). reassign_online is also defined as true in strongswan.conf

reassign_online only has an effect if the client requests the same IP it already got assigned previously, if it doesn't, e.g. requests %any (0.0.0.0), then a new lease is assigned. If these leases are not released (e.g. because there is no proper DELETE received by the client) they can't be assigned again (the existing IKE_SAs first have to be closed).

2014-11-24T15:14:21.301792+00:00 test-server charon: 14[IKE] activating new tasks
2014-11-24T15:14:21.301796+00:00 test-server charon: 14[IKE]   activating MODE_CONFIG task
2014-11-24T15:14:21.301799+00:00 test-server charon: 14[CFG] reassigning offline lease to 'OU=Devices, CN=test'
2014-11-24T15:14:21.301803+00:00 test-server charon: 14[IKE] assigning virtual IP 172.16.17.5 to peer 'OU=Devices, CN=test'

2014-11-24T15:14:21.316345+00:00 test-server charon: 15[IKE] peer requested virtual IP %any
2014-11-24T15:14:21.316352+00:00 test-server charon: 15[CFG] assigning new lease to 'OU=Devices, CN=test'
2014-11-24T15:14:21.316358+00:00 test-server charon: 15[IKE] assigning virtual IP 172.16.17.6 to peer 'OU=Devices, CN=test'

I don't see anything wrong with this log. In the first part there apparently is an offline lease that is reassigned, in the second a new lease is used.

#9 Updated by Dave Lewthwaite over 5 years ago

Ok, so if that's the case, how can the leases be cleared up?

The session has been completely cleaned up (ie no half open sessions waiting for DPD etc) but these leases remain assigned forever - meaning that after a connect/disconnect cycle on even a very large pool, ultimately it will run out.

Using the sql-attr pool (ipsec pool ... ...) with a 1 hour lease shows the same behaviour - they are never cleaned up.

#10 Updated by Tobias Brunner over 5 years ago

Ok, so if that's the case, how can the leases be cleared up?

When IKE_SAs are closed the IP lease should be released too (i.e. it is then in state offline an can get reassigned to clients). Do you see any lease ... by '...' went offline messages in the log?

The session has been completely cleaned up (ie no half open sessions waiting for DPD etc) but these leases remain assigned forever - meaning that after a connect/disconnect cycle on even a very large pool, ultimately it will run out.

How does the output of ipsec statusall and ipsec leases look like at that point?

#11 Updated by Dave Lewthwaite over 5 years ago

I've done a bit more investigation, on a clean start (reboot, empty pool, no sessions, client restart etc), during the connect process two IPs are allocated to the device - one during 'activating MOD_CONFIG task' and one after 'peer requested virtual IP %any'.

This causes two leases to be allocated (so ipsec leases shows two addresses, both against the same user).
On a clean disconnect, the SA is correctly shutdown and the system logs 'lease <ip> by <user> went offline. ipsec leases now shows an offline lease and an online lease.

When re-connecting, the offline lease is chosen but then ignored and a new one allocated - so each time we end up with an orphaned 'online' lease.

I'm not sure if this is simple config, a client bug or an interop bug, but it wasn't present in v4/Pluto

Here's the full clean connnecting log

2014-11-25T08:46:08.635258+00:00 test-server charon: 10[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (636 bytes)
2014-11-25T08:46:08.635643+00:00 test-server charon: 10[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V ]
2014-11-25T08:46:08.635800+00:00 test-server charon: 10[IKE] received NAT-T (RFC 3947) vendor ID
2014-11-25T08:46:08.635891+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID
2014-11-25T08:46:08.635961+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
2014-11-25T08:46:08.636029+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
2014-11-25T08:46:08.636096+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
2014-11-25T08:46:08.636163+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
2014-11-25T08:46:08.636229+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
2014-11-25T08:46:08.636296+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
2014-11-25T08:46:08.636362+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2014-11-25T08:46:08.636427+00:00 test-server charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2014-11-25T08:46:08.636493+00:00 test-server charon: 10[IKE] received FRAGMENTATION vendor ID
2014-11-25T08:46:08.636663+00:00 test-server charon: 10[IKE] received DPD vendor ID
2014-11-25T08:46:08.636887+00:00 test-server charon: 10[IKE] 192.168.37.216 is initiating a Main Mode IKE_SA
2014-11-25T08:46:08.636973+00:00 test-server charon: 10[IKE] IKE_SA (unnamed)[1] state change: CREATED => CONNECTING
2014-11-25T08:46:08.637101+00:00 test-server charon: 10[IKE] sending XAuth vendor ID
2014-11-25T08:46:08.637175+00:00 test-server charon: 10[IKE] sending DPD vendor ID
2014-11-25T08:46:08.637244+00:00 test-server charon: 10[IKE] sending NAT-T (RFC 3947) vendor ID
2014-11-25T08:46:08.637357+00:00 test-server charon: 10[ENC] generating ID_PROT response 0 [ SA V V V ]
2014-11-25T08:46:08.637468+00:00 test-server charon: 10[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (136 bytes)
2014-11-25T08:46:08.687704+00:00 test-server charon: 12[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (228 bytes)
2014-11-25T08:46:08.687729+00:00 test-server charon: 12[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
2014-11-25T08:46:08.687733+00:00 test-server charon: 12[IKE] sending cert request for "CN=TestCA" 
2014-11-25T08:46:08.687737+00:00 test-server charon: 12[ENC] generating ID_PROT response 0 [ KE No CERTREQ NAT-D NAT-D ]
2014-11-25T08:46:08.687922+00:00 test-server charon: 12[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (440 bytes)
2014-11-25T08:46:08.781316+00:00 test-server charon: 07[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (1196 bytes)
2014-11-25T08:46:08.781336+00:00 test-server charon: 07[ENC] parsed ID_PROT request 0 [ ID CERT SIG CERTREQ N(INITIAL_CONTACT) ]
2014-11-25T08:46:08.781340+00:00 test-server charon: 07[IKE] ignoring certificate request without data
2014-11-25T08:46:08.781344+00:00 test-server charon: 07[IKE] received end entity cert "OU=Devices, CN=test" 
2014-11-25T08:46:08.781347+00:00 test-server charon: 07[CFG] looking for RSA signature peer configs matching 192.168.37.240...192.168.37.216[OU=Devices, CN=test]
2014-11-25T08:46:08.781351+00:00 test-server charon: 07[CFG] selected peer config "iphone2" 
2014-11-25T08:46:08.781354+00:00 test-server charon: 07[CFG]   using certificate "OU=Devices, CN=test" 
2014-11-25T08:46:08.781357+00:00 test-server charon: 07[CFG]   using trusted ca certificate "CN=TestCA" 
2014-11-25T08:46:08.781361+00:00 test-server charon: 07[CFG] checking certificate status of "OU=Devices, CN=test" 
2014-11-25T08:46:08.781364+00:00 test-server charon: 07[CFG]   fetching crl from 'file:///etc/ipsec.d/crls/crl.pem' ...
2014-11-25T08:46:08.781367+00:00 test-server charon: 07[CFG] crl fetching failed
2014-11-25T08:46:08.781612+00:00 test-server charon: 07[CFG] certificate status is not available
2014-11-25T08:46:08.781751+00:00 test-server charon: 07[CFG]   reached self-signed root ca with a path length of 0
2014-11-25T08:46:08.782078+00:00 test-server charon: 07[IKE] authentication of 'OU=Devices, CN=test' with RSA successful
2014-11-25T08:46:08.783629+00:00 test-server charon: 07[IKE] authentication of '192.168.37.240' (myself) successful
2014-11-25T08:46:08.783847+00:00 test-server charon: 07[IKE] IKE_SA iphone2[1] established between 192.168.37.240[192.168.37.240]...192.168.37.216[OU=Devices, CN=test]
2014-11-25T08:46:08.783924+00:00 test-server charon: 07[IKE] IKE_SA iphone2[1] state change: CONNECTING => ESTABLISHED
2014-11-25T08:46:08.784909+00:00 test-server charon: 07[IKE] scheduling reauthentication in 13533s
2014-11-25T08:46:08.785157+00:00 test-server charon: 07[IKE] maximum IKE_SA lifetime 14073s
2014-11-25T08:46:08.785291+00:00 test-server charon: 07[IKE] sending end entity cert "CN=192.168.37.240" 
2014-11-25T08:46:08.785505+00:00 test-server charon: 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
2014-11-25T08:46:08.785836+00:00 test-server charon: 07[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (1324 bytes)
2014-11-25T08:46:08.787851+00:00 test-server charon: 13[IKE] queueing MODE_CONFIG task
2014-11-25T08:46:08.787864+00:00 test-server charon: 13[IKE] activating new tasks
2014-11-25T08:46:08.787868+00:00 test-server charon: 13[IKE]   activating MODE_CONFIG task
2014-11-25T08:46:08.787871+00:00 test-server charon: 13[CFG] assigning new lease to 'OU=Devices, CN=test'
2014-11-25T08:46:08.787874+00:00 test-server charon: 13[IKE] assigning virtual IP 172.16.17.1 to peer 'OU=Devices, CN=test'
2014-11-25T08:46:08.787878+00:00 test-server charon: 13[ENC] generating TRANSACTION request 2679280518 [ HASH CPS(ADDR) ]
2014-11-25T08:46:08.787881+00:00 test-server charon: 13[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (76 bytes)
2014-11-25T08:46:08.787884+00:00 test-server charon: 13[IKE] delaying task initiation, TRANSACTION exchange in progress
2014-11-25T08:46:08.804114+00:00 test-server charon: 14[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (76 bytes)
2014-11-25T08:46:08.804134+00:00 test-server charon: 14[ENC] parsed TRANSACTION response 2679280518 [ HASH CP ]
2014-11-25T08:46:08.804138+00:00 test-server charon: 14[IKE] activating new tasks
2014-11-25T08:46:08.804142+00:00 test-server charon: 14[IKE] nothing to initiate
2014-11-25T08:46:08.804145+00:00 test-server charon: 14[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (172 bytes)
2014-11-25T08:46:08.804148+00:00 test-server charon: 14[ENC] unknown attribute type (28683)
2014-11-25T08:46:08.804151+00:00 test-server charon: 14[ENC] parsed TRANSACTION request 1295700345 [ HASH CPRQ(ADDR MASK DNS NBNS EXP VER U_BANNER U_DEFDOM U_SPLITDNS U_SPLITINC U_LOCALLAN U_PFS U_SAVEPWD U_FWTYPE U_BKPSRV (28683)) ]
2014-11-25T08:46:08.804154+00:00 test-server charon: 14[IKE] processing INTERNAL_IP4_ADDRESS attribute
2014-11-25T08:46:08.804158+00:00 test-server charon: 14[IKE] processing INTERNAL_IP4_NETMASK attribute
2014-11-25T08:46:08.804161+00:00 test-server charon: 14[IKE] processing INTERNAL_IP4_DNS attribute
2014-11-25T08:46:08.804164+00:00 test-server charon: 14[IKE] processing INTERNAL_IP4_NBNS attribute
2014-11-25T08:46:08.804256+00:00 test-server charon: 14[IKE] processing INTERNAL_ADDRESS_EXPIRY attribute
2014-11-25T08:46:08.804262+00:00 test-server charon: 14[IKE] processing APPLICATION_VERSION attribute
2014-11-25T08:46:08.804265+00:00 test-server charon: 14[IKE] processing UNITY_BANNER attribute
2014-11-25T08:46:08.804268+00:00 test-server charon: 14[IKE] processing UNITY_DEF_DOMAIN attribute
2014-11-25T08:46:08.804271+00:00 test-server charon: 14[IKE] processing UNITY_SPLITDNS_NAME attribute
2014-11-25T08:46:08.804274+00:00 test-server charon: 14[IKE] processing UNITY_SPLIT_INCLUDE attribute
2014-11-25T08:46:08.804277+00:00 test-server charon: 14[IKE] processing UNITY_LOCAL_LAN attribute
2014-11-25T08:46:08.804287+00:00 test-server charon: 14[IKE] processing UNITY_PFS attribute
2014-11-25T08:46:08.804290+00:00 test-server charon: 14[IKE] processing UNITY_SAVE_PASSWD attribute
2014-11-25T08:46:08.804293+00:00 test-server charon: 14[IKE] processing UNITY_FW_TYPE attribute
2014-11-25T08:46:08.804296+00:00 test-server charon: 14[IKE] processing UNITY_BACKUP_SERVERS attribute
2014-11-25T08:46:08.804446+00:00 test-server charon: 14[IKE] processing (28683) attribute
2014-11-25T08:46:08.804453+00:00 test-server charon: 14[IKE] peer requested virtual IP %any
2014-11-25T08:46:08.813517+00:00 test-server charon: 14[CFG] assigning new lease to 'OU=Devices, CN=test'
2014-11-25T08:46:08.813647+00:00 test-server charon: 14[IKE] assigning virtual IP 172.16.17.2 to peer 'OU=Devices, CN=test'
2014-11-25T08:46:08.815148+00:00 test-server charon: 14[ENC] generating TRANSACTION response 1295700345 [ HASH CPRP(ADDR) ]
2014-11-25T08:46:08.815217+00:00 test-server charon: 14[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (76 bytes)
2014-11-25T08:46:09.147948+00:00 test-server charon: 16[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (300 bytes)
2014-11-25T08:46:09.147974+00:00 test-server charon: 16[ENC] parsed QUICK_MODE request 2020033311 [ HASH SA No ID ID ]
2014-11-25T08:46:09.147978+00:00 test-server charon: 16[IKE] expected IPComp proposal but peer did not send one, IPComp disabled
2014-11-25T08:46:09.147982+00:00 test-server charon: 16[IKE] received 3600s lifetime, configured 1200s
2014-11-25T08:46:09.148755+00:00 test-server charon: 16[ENC] generating QUICK_MODE response 2020033311 [ HASH SA No ID ID ]
2014-11-25T08:46:09.148914+00:00 test-server charon: 16[NET] sending packet: from 192.168.37.240[500] to 192.168.37.216[500] (172 bytes)
2014-11-25T08:46:09.192801+00:00 test-server charon: 15[NET] received packet: from 192.168.37.216[500] to 192.168.37.240[500] (60 bytes)
2014-11-25T08:46:09.192830+00:00 test-server charon: 15[ENC] parsed QUICK_MODE request 2020033311 [ HASH ]
2014-11-25T08:46:09.310257+00:00 test-server charon: 15[IKE] CHILD_SA iphone2{1} established with SPIs ccaa44f7_i 0f45480c_o and TS 0.0.0.0/0 === 172.16.17.2/32 

#12 Updated by Martin Willi over 5 years ago

two IPs are allocated to the device - one during 'activating MOD_CONFIG task' and one after 'peer requested virtual IP %any'.

The problem here is that you have configured Mode Config in push mode, but your client uses pull mode. Interestingly, both the push and the pull exchange succeed, resulting in two virtual IPs assigned. Please try to set modecfg=pull.

Not sure though if we can or have to prevent such a dual mode assignment, at least it doesn't make much sense. Can you confirm that only one of the leases gets released if that client disconnects?

Regards
Martin

#13 Updated by Dave Lewthwaite over 5 years ago

If I set modeconfig=pull the connection fails entirely - the iPhone won't make it past Phase 1.

During a clean disconnect, one of the leases (the one actually used and shows up on the device as it's virtual ip) shows as 'offline' - I presume this is what you mean by released.

#14 Updated by Martin Willi over 5 years ago

iOS definitely uses pull mode, so probably something else is wrong. Please post your configuration, and the log output when using pull mode, preferably under a new ticket.

#15 Updated by Dave Lewthwaite over 5 years ago

Ok this looks like a client bug - switching to using modeconfig=pull when using RSA/XAuth works fine - IP's correctly allocated/released etc.

Switching to using modeconfig=pull with just plain RSA auth and the connection won't start - with otherwise the same config, using modeconfig=push causes it to work for some odd reason.

#16 Updated by Martin Willi over 5 years ago

Most likely the client handles that push mode as XAuth request; this is what XAuth expects in that state, and the exchanges look almost identical.

iOS requires an XAuth exchange, but you may try the xauth-noauth backend if you don't want to use it. Also you might consider switching to IKEv2 with iOS 8.

Regards
Martin

#17 Updated by Dave Lewthwaite over 5 years ago

Actually, you can turn XAuth off on iOS - but you need to use a configuration profile to configure the connection rather than the settings UI. It correctly sends an RSA only proposal and connects etc - this is what we were using on StrongSWAN 4 because we didn't have the xauth-noauth plugin.

Changing clients in the field wouldn't really be practical so our options are either to stick with StrongSWAN 4 (and lose lots of nice improvements) or hack up the code to make it work for us.

Thanks for the help and advice anyway though, it's much appreciated.

#18 Updated by Tobias Brunner over 5 years ago

  • Related to Issue #795: pool is full, unable to assign address problem added

#19 Updated by Tobias Brunner over 5 years ago

  • Related to deleted (Issue #795: pool is full, unable to assign address problem)

#20 Updated by Tobias Brunner over 5 years ago

  • Has duplicate Issue #795: pool is full, unable to assign address problem added

#21 Updated by Tobias Brunner over 5 years ago

  • Status changed from Feedback to Closed
  • Target version set to 5.2.2
  • Resolution set to Fixed

Also available in: Atom PDF