[strongSwan] iOS client doesn't close CHILD_SA but Windows does?
G J
bls3427 at outlook.com
Mon Jul 4 22:22:01 CEST 2022
Thanks, Noel, but that makes setting up a small strongSwan server even more complex. I was hoping for a simple solution that would integrate with the logwatch script for strongSwan. A quick look at the logwatch freeradius script indicates that it doesn't print the accounting information, whereas the strongSwan logwatch script nicely prints it, if it's available:
IKE_SA Connections:
conn-windows:
192.168.92.5[windows.mydomain.com]...166.176.185.31[C=US, O=pvn-strongSwan, CN=bls-bsurf-pvn at myvpn.net]
Established 1 Time(s)
Destroyed 1 Time(s)
CHILD_SA Connections:
net:
0.0.0.0/0 === 10.92.10.2/32
Established 2 Time(s)
Destroyed 2 Time(s)
Data In 4.759M
Data Out 185.714M
-----Original Message-----
From: Users <users-bounces at lists.strongswan.org> On Behalf Of Noel Kuntze
Sent: Monday, July 4, 2022 10:35 AM
To: users at lists.strongswan.org
Subject: Re: [strongSwan] iOS client doesn't close CHILD_SA but Windows does?
Hello,
I presume it could. However if you want accounting, you are supposed (at least according to some old discussions about similiar issues with using the logs for accounting purposes) to use a RADIUS server for that. The RADIUS server will receive accounting information for all IKE_SAs, not just the ones using eap-radius or xauth.
Kind regards
Noel
Am 04.07.22 um 16:08 schrieb G J:
> I use both iOS and Windows clients to connect to my strongSwan server, and have observed that when a Windows client closes the connection, the following log entries are written:
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: received DELETE for ESP CHILD_SA with SPI 44bf3ff8
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: closing CHILD_SA net{4} with SPIs c6d196ed_i (3210654 bytes) 44bf3ff8_o (153861005 bytes) and TS 0.0.0.0/0 === 10.92.10.2/32
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: sending DELETE for ESP CHILD_SA with SPI c6d196ed
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: CHILD_SA closed
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: generating INFORMATIONAL response 2 [ D ]
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: sending packet: from 192.168.92.5[4500] to 166.176.185.31[9914] (80 bytes)
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: received packet: from 166.176.185.31[9914] to 192.168.92.5[4500] (80 bytes)
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: parsed INFORMATIONAL request 3 [ D ]
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: received DELETE for IKE_SA conn-windows[9]
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: deleting IKE_SA conn-windows[9] between 192.168.92.5[windows.mydomain.com]...166.176.185.31[C=US, O=pvn-strongSwan, CN=bls-bsur>
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: IKE_SA deleted
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: generating INFORMATIONAL response 3 [ ]
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: sending packet: from 192.168.92.5[4500] to 166.176.185.31[9914] (80 bytes)
>
> Jul 03 12:50:26 pvn charon-systemd[39509]: lease 10.92.10.2 by 'C=US, O=pvn-strongSwan, CN=bls-bsurf-pvn at myvpn.net <mailto:CN=bls-bsurf-pvn at myvpn.net>' went offline
>
> But when an iOS client closes the connection, there is no “closing CHILD_SA” log entry, thus the bytes transferred information is not there.
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: received DELETE for IKE_SA conn-ios[5]
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: deleting IKE_SA conn-ios[5] between 192.168.92.5[ios.mydomain.com]...166.176.186.243[bls-biphone-pvn at myvpn.net]
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: IKE_SA deleted
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: generating INFORMATIONAL response 10 [ ]
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: sending packet: from 192.168.92.5[4500] to 166.176.186.243[53457] (80 bytes)
>
> Jul 02 19:11:22 pvn charon-systemd[39509]: lease 10.92.10.1 by 'bls-biphone-pvn at myvpn.net' went offline
>
> Presumably this is because the Windows client is a bit more fastidious and actually closes the CHILD_SA, but iOS doesn’t?
>
> Is there a reason that strongSwan can’t log an implicit CHILD_SA close when the DELETE is received so that the bytes transferred information can be logged? Or, am I missing something in my configuration to cause this to be logged?
>
> Thanks!
>
> Configuration:
>
> conn-defaults {
>
> version = 2
>
> send_certreq = yes
>
> send_cert = always
>
> unique = never
>
> fragmentation = yes
>
> # Force esp encapsulation for restrictive firewalls
>
> encap = yes
>
> dpd_delay = 120s
>
> rekey_time = 0s
>
> pools = primary-pool-ipv4
>
> local {
>
> auth = pubkey
>
> cacerts = strongSwanCACert.pem
>
> }
>
> }
>
> remote-defaults {
>
> remote {
>
> id = %any
>
> }
>
> }
>
> child-defaults {
>
> net {
>
> dpd_action = clear
>
> rekey_time = 0s
>
> updown = /usr/lib/ipsec/_updown iptables
>
> }
>
> }
>
> connections {
>
> conn-android: conn-defaults, remote-defaults {
>
> proposals = aes256-aes192-aes128-sha384-sha256-sha1-modp3072-modp2048-modp1536
>
> local {
>
> certs = android-strongSwanVPNCert.pem
>
> id = android.mydomain.com
>
> }
>
> children {
>
> net : child-defaults {
>
> local_ts = 0.0.0.0/0
>
> esp_proposals = aes256-sha256
>
> }
>
> }
>
> }
>
> conn-windows: conn-defaults, remote-defaults {
>
> proposals = aes256-sha256-modp1024
>
> local {
>
> certs = windows-strongSwanVPNCert.pem
>
> id = windows.mydomain.com
>
> }
>
> children {
>
> net : child-defaults {
>
> local_ts = 0.0.0.0/0
>
> esp_proposals = aes256-sha256-sha1-modp1024
>
> }
>
> }
>
> }
>
> conn-linux: conn-defaults, remote-defaults {
>
> proposals = aes192-sha256-modp3072
>
> local {
>
> certs = linux-strongSwanVPNCert.pem
>
> id = linux.mydomain.com
>
> }
>
> remote {
>
> auth = pubkey
>
> }
>
> children {
>
> net : child-defaults {
>
> local_ts = 0.0.0.0/0
>
> esp_proposals = aes128gcm128-x25519
>
> }
>
> }
>
> }
>
> conn-ios : conn-defaults, remote-defaults {
>
> proposals = aes256-sha256-modp2048, aes256-sha256-modp1024,aes256-sha1-modp1024
>
> local {
>
> certs = ios-strongSwanVPNCert.pem
>
> id = ios.mydomain.com
>
> }
>
> remote {
>
> auth = eap-tls
>
> }
>
> children {
>
> net : child-defaults {
>
> local_ts = 0.0.0.0/0
>
> esp_proposals = aes256-sha256
>
> }
>
> }
>
> }
>
> }
>
> pools {
>
> primary-pool-ipv4 {
>
> addrs = 10.92.10.0/24
>
> dns = 192.168.92.3
>
> }
>
> }
>
> Thanks
>
More information about the Users
mailing list