[strongSwan] Duplicate IP address conflict with DHCP Plugin and unique=replace

[Laurent Bouchard]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171005/103ad9b0/attachment.html>