We've seen different roadwarrior users with the same IP address on ESTABLISHED
connections in swanctl --list-sas. I'm posting here the details of our setup
and what we think the problem is in case someone might have a different idea or
in case this could be useful for someone else. We are probably going to retry
enabling the DHCP plugin in a testing environment at a later date.
We're using a Strongswan 5.5.3 vpn gateway on Linux (Centos 7) with Android
clients road-warriors .
We rely on unique=replace in swanctl.conf to clean up old dead connection from
clients which ended their connection while not able to reach the gateway.
(The next time this client connects the old connection is replaced.) We are not
using dead peer detection or rekeys on the gateway.
We are using the DHCP plugin to assign IP addresses. Our DHCP server is not
configured to ping an IP address before making an assignment.
Some of our users were complaining about connectivity issues. When we checked
"swanctl --list-sas" we could see that the users complaining were on
"ESTABLISHED" connections and shared an IP address with another user.
We reviewed the logs of our DHCP server and it did not seem to assign IP
addresses unless they had been previously released.
We looked at strongswan's log and it seemed like "deleting duplicate IKE_SA for
peer ..." was often followed by a DHCP release a few minutes later.
We think we managed reproduce with the following steps:
1. RW1 connects to the gateway
2. RW1 roams to a wifi where the gateway is unreachable
3. RW1 ends its VPN connection in the Android UI
4. RW1 roams to a wifi where the gateway is reachable
5. RW1 connects to the gateway again -- this triggers "deleting duplicate
IKE_SA for peer ..."
6. With swanctl --list-sas we can see that RW1 has two connection (one is
ESTABLISHED, the other one is on its way for deletion)
7. A few minutes later we can see a DHCP release for RW1's address.
8. RW2 connects later and is assigned the same IP address RW1 is still using.
9. With swanctl --list-sas we can see that RW1 and RW2 have the same IP address.
We switched to using a pool in the swanctl configuration file and have not seen
any problems so far.
Here are the some of the configuration we are using. I've also included some
logs but I have redacted hostnames and IP addresses as this gateway has a
public facing IP address.
dhcp.conf:
dhcp {
# Always use the configured server address.
force_server_address = yes
# Derive user-defined MAC address from hash of IKE identity.
identity_lease = yes
# Interface name the plugin uses for address allocation.
interface = ens192
# Whether to load the plugin. Can also be an integer to increase the
# priority of this plugin.
load = yes
# DHCP server unicast or broadcast IP address.
server = 255.255.255.255
}
swanctl.conf:
connections {
# connection for Android mobile users
EnrollmentAndroidUsers {
local {
auth = pubkey
certs = enrollment.ecdsa.pem
id = gw1.somedomain.com
}
remote {
auth = pubkey
id = %any
revocation = strict
}
children {
net {
local_ts = 0.0.0.0/0
start_action = none
rekey_time = 0
esp_proposals = aes128gcm64-ecp384, aes128-sha256-ecp256,
aes128-sha
ipcomp = no
}
}
encap = yes
local_addrs = <gw1 public ip>
pools = dhcp
version = 2
dpd_delay = 0
rekey_time = 0
unique = replace
fragmentation = yes
proposals = aes256-sha384-ecp384, aes256-sha256-ecp256,
aes256-sha384-modp2048, aes256-sha384-modp1024
send_cert = always
}
}
#### Roadwarrior rw1 reconnects after beeing offline
Sep 29 08:49:52 gw1 charon-systemd: <info> received packet: from <some public
ip>[27258] to <gw1 public ip>[500] (306 bytes)
#### Skipping most authentication logs
Sep 29 08:49:52 gw1 charon-systemd: <info> authentication of
'CN=device.rw1.enroll.somedomain.com' with RSA_EMSA_PKCS1_SHA2_256 successful
Sep 29 08:49:52 gw1 charon-systemd: <info> received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Sep 29 08:49:52 gw1 charon-systemd: <info> peer supports MOBIKE
Sep 29 08:49:52 gw1 charon-systemd: <info> authentication of
'gw1.somedomain.com' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful
Sep 29 08:49:52 gw1 charon-systemd: <info> deleting duplicate IKE_SA for peer
'CN=device.rw1.enroll.somedomain.com' due to uniqueness policy
#### unique=replace previous connection is queued for deletion
Sep 29 08:49:52 gw1 charon-systemd: <notice> deleting IKE_SA
EnrollmentAndroidUsers[2] between <gw1 public ip>[gw1.somedomain.com]...<some
public ip>[CN=device.rw1.enroll.somedomain.com]
Sep 29 08:49:52 gw1 charon-systemd: <info> sending DELETE for IKE_SA
EnrollmentAndroidUsers[2]
Sep 29 08:49:52 gw1 charon-systemd: <info> generating INFORMATIONAL request 0 [
D ]
Sep 29 08:49:52 gw1 charon-systemd: <info> sending packet: from <gw1 public
ip>[4500] to <some public ip>[3133] (88 bytes)
Sep 29 08:49:52 gw1 charon-systemd: <notice> IKE_SA EnrollmentAndroidUsers[65]
established between <gw1 public ip>[gw1.somedomain.com]...<some public
ip>[CN=device.rw1.enroll.somedomain.com]
Sep 29 08:49:52 gw1 charon-systemd: <info> sending end entity cert "ST=Quebec,
L=Longueuil, O=Radio-IP, OU=Dev, CN=gw1.somedomain.com-enrollment.ecdsa"
Sep 29 08:49:52 gw1 charon-systemd: <info> peer requested virtual IP %any
Sep 29 08:49:52 gw1 charon-systemd: <info> sending DHCP DISCOVER to
255.255.255.255
Sep 29 08:49:52 gw1 charon-systemd: <info> received DHCP OFFER 192.168.1.3 from
192.168.1.1
Sep 29 08:49:52 gw1 charon-systemd: <info> sending DHCP REQUEST for 192.168.1.3
to 192.168.1.1
Sep 29 08:49:52 gw1 charon-systemd: <info> received DHCP ACK for 192.168.1.3
Sep 29 08:49:52 gw1 charon-systemd: <info> assigning virtual IP 192.168.1.3 to
peer 'CN=device.rw1.enroll.somedomain.com'
#### minutes later, strongswan seems to give up trying to delete the first
connection cleanly
Sep 29 08:52:37 gw1 charon-systemd: <info> giving up after 5 retransmits
Sep 29 08:52:37 gw1 charon-systemd: <info> proper IKE_SA delete failed, peer
not responding
Sep 29 08:52:37 gw1 charon-systemd: <info> sending DHCP RELEASE for 192.168.1.3
to 192.168.1.1
#### 192.168.1.3 is released! Its still beeing used by the new connection of rw1
#### Later, a different user connects and is assigned 192.168.1.3
Sep 29 09:43:13 gw1 charon-systemd: <info> authentication of
'gw1.somedomain.com' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful
Sep 29 09:43:13 gw1 charon-systemd: <notice> IKE_SA EnrollmentAndroidUsers[66]
established between <gw1 public ip>[gw1.somedomain.com]...<some public
ip>[CN=device.rw2.enroll.somedomain.com]
Sep 29 09:43:13 gw1 charon-systemd: <info> sending end entity cert "ST=Quebec,
L=Longueuil, O=Radio-IP, OU=Dev, CN=gw1.somedomain.com-enrollment.ecdsa"
Sep 29 09:43:13 gw1 charon-systemd: <info> peer requested virtual IP %any
Sep 29 09:43:13 gw1 charon-systemd: <info> sending DHCP DISCOVER to
255.255.255.255
Sep 29 09:43:13 gw1 charon-systemd: <info> received DHCP OFFER 192.168.1.3 from
192.168.1.1
Sep 29 09:43:13 gw1 charon-systemd: <info> sending DHCP REQUEST for 192.168.1.3
to 192.168.1.1
Sep 29 09:43:13 gw1 charon-systemd: <info> received DHCP ACK for 192.168.1.3
Sep 29 09:43:13 gw1 charon-systemd: <info> assigning virtual IP 192.168.1.3 to
peer 'CN=device.rw2.enroll.somedomain.com'
#### At this point in time we have two active "ESTABLISHED" connections using
192.168.1.3
Laurent
