strongSwan Connection Status with Windows User Certificates

Starting the strongSwan Daemon

The strongSwan charon-systemd daemon is started with

sudo systemctl start strongswan

The start of the strongSwan systemd service is usually done automatically during system boot. The journal log shows the following startup activities

Starting strongSwan IPsec IKEv1/IKEv2 daemon using swanctl...
loaded plugins: charon-systemd nonce pem openssl curl revocation vici eap-identity eap-tls kernel-netlink socket-default
spawning 16 worker threads
loaded certificate 'C=CH, O=strongSec GmbH, CN=vpn.strongswan.org'
loaded certificate 'C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA'
loaded ECDSA private key
added vici pool ipv4: 10.10.1.64, 62 entries
added vici pool ipv6: 2a02:168:4407:1::, 62 entries
added vici connection: win
added vici connection: eap-tls
Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.

The configured connection definitions can be listed with the swanctl --list-conns

eap-tls: IKEv2, reauthentication every 10800s, no rekeying
  local:  %any
  remote: %any
  local public key authentication:
    id: vpn.strongswan.org
    certs: C=CH, O=strongSec GmbH, CN=vpn.strongswan.org
  remote EAP_TLS authentication:
    eap_id: %any
    cacerts: C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA
  eap-tls: TUNNEL, rekeying every 3600s
    local:  0.0.0.0/0 ::/0
    remote: dynamic

Windows Client Connecting

IKE_SA_INIT Request

An IKE_SA_INIT request from a Windows client is received

received packet: from 212.51.148.80[63721] to 10.10.0.150[500] (632 bytes)
parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
received MS NT5 ISAKMPOAKLEY v9 vendor ID
received MS-Negotiation Discovery Capable vendor ID
received Vid-Initial-Contact vendor ID
received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
212.51.148.80 is initiating an IKE_SA

This is the IKE crypto proposal selected by the strongSwn gateway

selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

Based on the NAT_S_IP and NAT_D_IP notifies at least two NAT routers were detected in the communications path

local host is behind NAT, sending keep alives
remote host is behind NAT

IKE_SA_INIT Response

The strongSwan gateway sends its IKE_SA_INIT response to the Windows client

sending cert request for "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
sending packet: from 10.10.0.150[500] to 212.51.148.80[63721] (481 bytes)

IKE_AUTH Request

A fragmented IKE_AUTH request from the Windows client is received

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (580 bytes)
parsed IKE_AUTH request 1 [ EF(1/3) ]
received fragment #1 of 3, waiting for complete IKE message
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (580 bytes)
parsed IKE_AUTH request 1 [ EF(2/3) ]
received fragment #2 of 3, waiting for complete IKE message
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (532 bytes)
parsed IKE_AUTH request 1 [ EF(3/3) ]
received fragment #3 of 3, reassembled fragmented IKE message (1520 bytes)
parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]

Certificate requests for the strongSec CA and 52 additional unknown CAs are received

received cert request for "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
received 52 cert requests for an unknown ca

Since the first connection definition win for machine-certificate-based client authentication doesn’t match (the Windows client doesn’t include an AUTH payload in the IKE_AUTH request), the strongSwan gateway switches to the eap-tls connection definition

looking for peer configs matching 10.10.0.150[%any]...212.51.148.80[10.10.1.52]
selected peer config 'win'
peer requested EAP, config unacceptable
switching to peer config 'eap-tls'

IKE_AUTH Response

As a first step in the EAP negotiation the strongSwan gateway requests an EAP Identity from the Windows client

initiating EAP_IDENTITY method (id 0x00)

The gateway also includes its public key signature generated with its ECDSA private key and the gateway certificate in the first IKE_AUTH response

peer supports MOBIKE
authentication of 'vpn.strongswan.org' (myself) with ECDSA-256 signature successful
sending end entity cert "C=CH, O=strongSec GmbH, CN=vpn.strongswan.org"
generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (1200 bytes)

IKE_AUTH Request 2

In the second IKE_AUTH request the Windows client sends its EAP Identity

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (96 bytes)
parsed IKE_AUTH request 2 [ EAP/RES/ID ]
received EAP identity 'Andreas Steffen'

IKE_AUTH Response 2

In the second IKE_AUTH response the strongSwan gateway requests an EAP-TLS negotiation from the Windows client

initiating EAP_TLS method (id 0xD6)
generating IKE_AUTH response 2 [ EAP/REQ/TLS ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)

IKE_AUTH Request 3

In the third IKE_AUTH request the Windows client sends its TLS 1.2 client hello message

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (336 bytes)
parsed IKE_AUTH request 3 [ EAP/RES/TLS ]
using key of type ECDSA
negotiated TLS 1.2 using suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

IKE_AUTH Response 3

In the third IKE_AUTH response the strongSwan gateway sends its TLS server certificate and requests a TLS client certificate

sending TLS server certificate 'C=CH, O=strongSec GmbH, CN=vpn.strongswan.org'
sending TLS cert request for 'C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA'
generating IKE_AUTH response 3 [ EAP/REQ/TLS ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (1104 bytes)

IKE_AUTH Request 4

In the fourth IKE_AUTH request some more TLS handshake messages are received from the Windows client

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
parsed IKE_AUTH request 4 [ EAP/RES/TLS ]

IKE_AUTH Response 4

In the fourth IKE_AUTH response the strongSwan gateway sends some more TLS handshake messages to the Windows client

generating IKE_AUTH response 4 [ EAP/REQ/TLS ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (464 bytes)

IKE_AUTH Request 5

In the fifth fragmented IKE_AUTH request some more TLS handshake messages are received from the Windows client

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (580 bytes)
parsed IKE_AUTH request 5 [ EF(1/3) ]
received fragment #1 of 3, waiting for complete IKE message
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (580 bytes)
parsed IKE_AUTH request 5 [ EF(2/3) ]
received fragment #2 of 3, waiting for complete IKE message
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (484 bytes)
parsed IKE_AUTH request 5 [ EF(3/3) ]
received fragment #3 of 3, reassembled fragmented IKE message (1472 bytes)
parsed IKE_AUTH request 5 [ EAP/RES/TLS ]

IKE_AUTH Response 5

In the fifth IKE_AUTH response the strongSwan gateway sends some more TLS handshake messages to the Windows client

generating IKE_AUTH response 5 [ EAP/REQ/TLS ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)

IKE_AUTH Request 6

In the sixth fragmented IKE_AUTH request the Windows client sends its TLS user certificate

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (580 bytes)
parsed IKE_AUTH request 6 [ EF(1/2) ]
received fragment #1 of 2, waiting for complete IKE message
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (132 bytes)
parsed IKE_AUTH request 6 [ EF(2/2) ]
received fragment #2 of 2, reassembled fragmented IKE message (624 bytes)
parsed IKE_AUTH request 6 [ EAP/RES/TLS ]
received TLS peer certificate 'C=CH, O=strongSec GmbH, CN=Andreas Steffen'
  using certificate "C=CH, O=strongSec GmbH, CN=Andreas Steffen"
  using trusted ca certificate "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
checking certificate status of "C=CH, O=strongSec GmbH, CN=Andreas Steffen"
  using trusted certificate "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  crl correctly signed by "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  crl is valid: until Mar 13 10:00:01 2022
  reached self-signed root ca with a path length of 0

IKE_AUTH Response 6

In the sixth IKE_AUTH response the strongSwan gateway sends some more TLS handshake messages to the Windows client

generating IKE_AUTH response 6 [ EAP/REQ/TLS ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (144 bytes)

IKE_AUTH Request 7

In the seventh IKE_AUTH request the EAP-TLS negotiation is successfully finalized

parsed IKE_AUTH request 7 [ EAP/RES/TLS ]
EAP method EAP_TLS succeeded, MSK established

IKE_AUTH Response 7

In the seventh IKE_AUTH response the strongSwan gateway sends an EAP-SUCCESS message to the Windows client

generating IKE_AUTH response 7 [ EAP/SUCC ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)

IKE_AUTH Request 8

In the eighth IKE_AUTH request from the Windows client the EAP-based IKE_SA is successfully established

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (112 bytes)
parsed IKE_AUTH request 8 [ AUTH ]
authentication of '10.10.1.52' with EAP successful
authentication of 'vpn.strongswan.org' (myself) with EAP
IKE_SA eap-tls[2] established between 10.10.0.150[vpn.strongswan.org]...212.51.148.80[10.10.1.52]
scheduling reauthentication in 10376s
maximum IKE_SA lifetime 11456s

The Windows client requested both an IPv4 and IPv6 virtual IP address so that one IP address from each pool is assigned.

peer requested virtual IP %any
assigning new lease to 'Andreas Steffen'
assigning virtual IP 10.10.1.66 to peer 'Andreas Steffen'
peer requested virtual IP %any6
assigning new lease to 'Andreas Steffen'
assigning virtual IP 2a02:168:4407:1::2 to peer 'Andreas Steffen'

IKE_AUTH Response 8

This is the ESP crypto proposal selected by the strongSwan gateway

selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ

The strongSwan gateway sends its eighth and final IKE_AUTH response to the Windows client

CHILD_SA eap-tls{2} established with SPIs caf527c5_i 9bcd9c12_o and TS 0.0.0.0/0 ::/0 === 10.10.1.66/32 2a02:168:4407:1::2/128
generating IKE_AUTH response 8 [ AUTH CPRP(ADDR ADDR6 DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_6_ADDR) ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (368 bytes)

IKEv2 Message Count

The IPsec tunnel has been established with 9 IKEv2 request/response pairs which is much larger than the 2 request/response pairs needed for a connection setup with Windows machine certificates.

Connection Status

The swanctl --list-sas shows the details of the established IPsec tunnel

eap-tls: #2, ESTABLISHED, IKEv2, 8ab17b513b1c1514_i 80fd1986e5c0e179_r*
  local  'vpn.strongswan.org' @ 10.10.0.150[4500]
  remote '10.10.1.52' @ 212.51.148.80[63720] EAP: 'Andreas Steffen' [10.10.1.66 2a02:168:4407:1::2]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  established 57s ago, reauth in 10319s
  eap-tls: #2, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 57s ago, rekeying in 3216s, expires in 3903s
    in  caf527c5,  28317 bytes,   188 packets,     3s ago
    out 9bcd9c12,  40788 bytes,   110 packets,     0s ago
    local  0.0.0.0/0 ::/0
    remote 10.10.1.66/32 2a02:168:4407:1::2/128

X.509 Certificates

The swanctl --list-certs command shows all the X.509 certificates involved in the establishment of the IPsec tunnel.

List of X.509 End Entity Certificates

  subject:  "C=CH, O=strongSec GmbH, CN=Andreas Steffen"
  issuer:   "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  validity:  not before Mar 19 16:55:13 2020, ok
             not after  Mar 19 16:55:13 2024, ok (expires in 740 days)
  serial:    5c:80:aa:97:72:36:c8:23
  altNames:  andreas.steffen@strongsec.net, andreas.steffen@strongsec.com
  flags:
  CRL URIs:  http://www.strongsec.com/ca/strongsec.crl
  authkeyId: 6d:c2:af:37:49:41:b9:fd:f4:45:8b:aa:e0:03:3b:b9:e5:7b:9c:b5
  subjkeyId: b4:4c:ce:9f:22:ff:03:5a:c4:3a:7b:fd:a4:42:25:9a:d6:71:1d:d1
  pubkey:    RSA 3072 bits
  keyid:     79:8a:9f:79:91:e8:6d:da:12:f4:c2:86:ff:f0:ef:01:9a:91:32:02
  subjkey:   b4:4c:ce:9f:22:ff:03:5a:c4:3a:7b:fd:a4:42:25:9a:d6:71:1d:d1

  subject:  "C=CH, O=strongSec GmbH, CN=vpn.strongswan.org"
  issuer:   "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  validity:  not before Jul 12 13:01:02 2021, ok
             not after  Jul 12 13:01:02 2026, ok (expires in 1585 days)
  serial:    32:b3:25:3c:b4:f4:78:be
  altNames:  vpn.strongswan.org
  flags:     serverAuth
  CRL URIs:  http://www.strongsec.com/ca/strongsec.crl
  authkeyId: 6d:c2:af:37:49:41:b9:fd:f4:45:8b:aa:e0:03:3b:b9:e5:7b:9c:b5
  subjkeyId: cc:83:49:87:2b:9e:f3:cb:b8:35:12:02:87:ff:14:89:28:44:a6:04
  pubkey:    ECDSA 256 bits, has private key
  keyid:     ba:64:37:a4:0e:c8:42:67:8c:55:5a:f9:1b:2a:eb:ff:5f:40:c3:e3
  subjkey:   cc:83:49:87:2b:9e:f3:cb:b8:35:12:02:87:ff:14:89:28:44:a6:04

All X.509 end entity certificates were issued by the strongSec CA

List of X.509 CA Certificates

  subject:  "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  issuer:   "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  validity:  not before Sep 02 10:25:01 2016, ok
             not after  Sep 02 10:25:01 2026, ok (expires in 1637 days)
  serial:    7c:24:43:4b:b7:dc:ef:7e
  flags:     CA CRLSign self-signed
  pathlen:   1
  subjkeyId: 6d:c2:af:37:49:41:b9:fd:f4:45:8b:aa:e0:03:3b:b9:e5:7b:9c:b5
  pubkey:    RSA 4096 bits
  keyid:     6c:79:f3:7a:b0:df:ac:69:03:b2:ac:6a:ed:82:3a:d2:66:93:b1:21
  subjkey:   6d:c2:af:37:49:41:b9:fd:f4:45:8b:aa:e0:03:3b:b9:e5:7b:9c:b5

The current Certificate Revocation List (CRL) was fetched from an HTTP server

List of X.509 CRLs

  issuer:   "C=CH, O=strongSec GmbH, CN=strongSec 2016 Root CA"
  update:    this on Mar 06 04:00:01 2022, ok
             next on Mar 13 10:00:01 2022, ok (expires in 3 days)
  serial:    01:15
  authKeyId: 6d:c2:af:37:49:41:b9:fd:f4:45:8b:aa:e0:03:3b:b9:e5:7b:9c:b5
  1 revoked certificate:
    0f:96:79:30:de:9e:c5:90: Jul 07 21:24:36 2021, key compromise

Virtual IP Address Leases

The swanctl --list-pools --leases command shows the defined virtual IP address pools and the addresses that have already been assigned.

ipv4                 10.10.1.64                           1 / 1 / 62
  10.10.1.65            offline 'C=CH, O=strongSec GmbH, CN=mijas.strongsec.com'
  10.10.1.66            online  'Andreas Steffen'
ipv6                 2a02:168:4407:1::                    1 / 1 / 62
  2a02:168:4407:1::1    offline 'C=CH, O=strongSec GmbH, CN=mijas.strongsec.com'
  2a02:168:4407:1::2    online  'Andreas Steffen'

Dead Peer Detection

The Windows client uses Dead Peer Detection (DPD) to check on the liveness of the strongSwan gateway by sending an INFORMATIONAL request that has to be answered by the gateway with an INFORMATIONAL response.

08:26:35: received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
08:26:35: parsed INFORMATIONAL request 9 [ ]
08:26:35: generating INFORMATIONAL response 9 [ ]
08:26:35: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)
08:26:44: received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
08:26:44: parsed INFORMATIONAL request 10 [ ]
08:26:44: generating INFORMATIONAL response 10 [ ]
08:26:44: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)
...
08:29:35: received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
08:29:35: parsed INFORMATIONAL request 19 [ ]
08:29:35: generating INFORMATIONAL response 19 [ ]
08:29:35: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)

Windows Client Disconnecting

The Windows client is disconnecting and sends DELETE notifies in INFORMATIONAL messages to the strongSwan gateway to delete both the CHILD SA and IKE SA

received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
parsed INFORMATIONAL request 20 [ D ]
received DELETE for ESP CHILD_SA with SPI 9bcd9c12
closing CHILD_SA eap{2} with SPIs caf527c5_i (58423 bytes) 9bcd9c12_o (103479 bytes) and TS 0.0.0.0/0 ::/0 === 10.10.1.66/32 2a02:168:4407:1::2/128
sending DELETE for ESP CHILD_SA with SPI caf527c5
CHILD_SA closed
generating INFORMATIONAL response 20 [ D ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)
received packet: from 212.51.148.80[63720] to 10.10.0.150[4500] (80 bytes)
parsed INFORMATIONAL request 21 [ D ]
received DELETE for IKE_SA eap[2]
deleting IKE_SA eap[2] between 10.10.0.150[vpn.strongswan.org]...212.51.148.80[10.10.1.52]
IKE_SA deleted
generating INFORMATIONAL response 21 [ ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63720] (80 bytes)

Virtual IP Address Release

The IPv4 and IPv6 virtual IP addresses are released.

lease 2a02:168:4407:1::2 by 'Andreas Steffen' went offline
lease 10.10.1.66 by 'Andreas Steffen' went offline

The swanctl --list-pools --leases command shows that the assigned virtual IP address leases are now offline.

ipv4                 10.10.1.64                           0 / 1 / 62
  10.10.1.65            offline 'C=CH, O=strongSec GmbH, CN=mijas.strongsec.com'
  10.10.1.66            offline 'Andreas Steffen'
ipv6                 2a02:168:4407:1::                    0 / 1 / 62
  2a02:168:4407:1::1    offline 'C=CH, O=strongSec GmbH, CN=mijas.strongsec.com'
  2a02:168:4407:1::2    offline 'Andreas Steffen'

The offline addresses will be re-assigned to the same Windows client as long as the strongSwan daemon is not restarted.