strongSwan EAP Connection Status with Passwords
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 eap-mschapv2 eap-dynamic 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 loaded EAP shared key with id 'eap-andi' for: 'andi' 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 Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
The configured connection definitions can be listed with the
swanctl --list-conns
eap: 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_DYNAMIC authentication:
eap_id: %any
eap: 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[63770] to 10.10.0.150[500] (612 bytes) parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V ] received MS NT5 ISAKMPOAKLEY v9 vendor ID received MS-Negotiation Discovery Capable 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[63770] (481 bytes)
IKE_AUTH Request
A fragmented IKE_AUTH request from the Windows client is received
received packet: from 212.51.148.80[63771] 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[63771] 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[63771] to 10.10.0.150[4500] (548 bytes) parsed IKE_AUTH request 1 [ EF(3/3) ] received fragment #3 of 3, reassembled fragmented IKE message (1536 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
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'
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[63771] (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[63771] to 10.10.0.150[4500] (80 bytes) parsed IKE_AUTH request 2 [ EAP/RES/ID ] received EAP identity 'andi'
IKE_AUTH Response 2
In the second IKE_AUTH response the strongSwan gateway requests a default
EAP-TLS negotiation from the Windows client
EAP_TLS method selected sending EAP_TLS start packet (6 bytes) initiating EAP_TLS method (id 0x01) generating IKE_AUTH response 2 [ EAP/REQ/TLS ] sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
IKE_AUTH Request 3
In the third IKE_AUTH request the Windows client sends an EAP-NAK message
requesting a different EAP method
received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) parsed IKE_AUTH request 3 [ EAP/RES/NAK ] received EAP_NAK, selecting a different EAP method
IKE_AUTH Response 3
In the third IKE_AUTH response the strongSwan gateway requests an EAP-MSCHAPV2
authentication by sending a challenge
EAP_MSCHAPV2 method selected generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ] sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (112 bytes)
IKE_AUTH Request 4
In the fourth IKE_AUTH request the Windows client sends the EAP-MSCHAPv2
response
received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (144 bytes) parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
IKE_AUTH Response 4
In the fourth IKE_AUTH response the strongSwan gateway sends some more EAP
messages to the Windows client
generating IKE_AUTH response 4 [ EAP/REQ/MSCHAPV2 ] sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (144 bytes)
IKE_AUTH Request 5
In the fifth IKE_AUTH request the EAP-MSCHAPv2 negotiation is successfully
finalized
received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) parsed IKE_AUTH request 5 [ EAP/RES/MSCHAPV2 ] EAP method EAP_MSCHAPV2 succeeded, MSK established
IKE_AUTH Response 5
In the fifth IKE_AUTH response the strongSwan gateway sends an EAP-SUCCESS
message to the Windows client
generating IKE_AUTH response 5 [ EAP/SUCC ] sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
IKE_AUTH Request 6
In the sixth IKE_AUTH request from the Windows client the EAP-based IKE_SA is
successfully established
received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (112 bytes) parsed IKE_AUTH request 6 [ AUTH ] authentication of '10.10.1.52' with EAP successful authentication of 'vpn.strongswan.org' (myself) with EAP IKE_SA eap[3] established between 10.10.0.150[vpn.strongswan.org]...212.51.148.80[10.10.1.52] scheduling reauthentication in 9809s maximum IKE_SA lifetime 10889s
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 'andi' assigning virtual IP 10.10.1.67 to peer 'andi' peer requested virtual IP 2a02:168:4407:1::3 assigning new lease to 'andi' assigning virtual IP 2a02:168:4407:1::3 to peer 'andi'
IKE_AUTH Response 6
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 sixth and final IKE_AUTH response to the Windows
client
CHILD_SA eap{3} established with SPIs c2713224_i 36ce686c_o and TS 0.0.0.0/0 ::/0 === 10.10.1.67/32 2a02:168:4407:1::3/128
generating IKE_AUTH response 6 [ 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[63771] (368 bytes)
IKEv2 Message Count
The IPsec tunnel has been established with 7 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: #3, ESTABLISHED, IKEv2, fdf1be328afa3c75_i 465f125679bdfd7e_r*
local 'vpn.strongswan.org' @ 10.10.0.150[4500]
remote '10.10.1.52' @ 212.51.148.80[63771] EAP: 'andi' [10.10.1.67 2a02:168:4407:1::3]
AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, reauth in 9784s
eap: #3, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
installed 25s ago, rekeying in 3306s, expires in 3935s
in c2713224, 25075 bytes, 167 packets, 1s ago
out 36ce686c, 44193 bytes, 105 packets, 1s ago
local 0.0.0.0/0 ::/0
remote 10.10.1.67/32 2a02:168:4407:1::3/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=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
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' 10.10.1.67 online 'andi' 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' 2a02:168:4407:1::3 online 'andi'
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.
09:58:20: received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) 09:58:20: parsed INFORMATIONAL request 7 [ ] 09:58:20: generating INFORMATIONAL response 7 [ ] 09:58:20: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
09:58:29: received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) 09:58:29: parsed INFORMATIONAL request 8 [ ] 09:58:29: generating INFORMATIONAL response 8 [ ] 09:58:29: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
...
09:59:05: received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) 09:59:05: parsed INFORMATIONAL request 10 [ ] 09:59:05: generating INFORMATIONAL response 10 [ ] 09:59:05: sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (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[63771] to 10.10.0.150[4500] (80 bytes)
parsed INFORMATIONAL request 11 [ D ]
received DELETE for ESP CHILD_SA with SPI 36ce686c
closing CHILD_SA eap{3} with SPIs c2713224_i (45329 bytes) 36ce686c_o (72297 bytes) and TS 0.0.0.0/0 ::/0 === 10.10.1.67/32 2a02:168:4407:1::3/128
sending DELETE for ESP CHILD_SA with SPI c2713224
CHILD_SA closed
generating INFORMATIONAL response 11 [ D ]
sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
received packet: from 212.51.148.80[63771] to 10.10.0.150[4500] (80 bytes) parsed INFORMATIONAL request 12 [ D ] received DELETE for IKE_SA eap[3] deleting IKE_SA eap[3] between 10.10.0.150[vpn.strongswan.org]...212.51.148.80[10.10.1.52] IKE_SA deleted generating INFORMATIONAL response 12 [ ] sending packet: from 10.10.0.150[4500] to 212.51.148.80[63771] (80 bytes)
Virtual IP Address Release
The IPv4 and IPv6 virtual IP addresses are released.
lease 2a02:168:4407:1::3 by 'andi' went offline lease 10.10.1.67 by 'andi' 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' 10.10.1.67 offline 'andi' 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' 2a02:168:4407:1::3 offline 'andi'
The offline addresses will be re-assigned to the same Windows client as long as the strongSwan daemon is not restarted.