VPN client suddenly stopped working with error: no socket implementation registered - StrongSwan 5.9.13 - Ubuntu 24.04 - Kernel 6.8.0 #2282

sergebouchut2 · 2024-06-10T18:47:00Z

sergebouchut2
Jun 10, 2024

Hello,

I recently made a fresh install of Ubuntu 24.04 on my laptop.
I reinstalled the VPN (with my previous configuration and certificate) using the command below and it worked fine until today when it suddenly stopped working with no further explanation.

System (please complete the following information):

OS: Ubuntu 24.04
Kernel version: 6.8.0
strongSwan version(s): 5.9.13
Tested/confirmed with the latest version: not tested with 5.9.14 (not available in apt repo)

Describe the bug
I have the following error in the journal: no socket implementation registered, but I don't know how to investigate further.
swanctl command outputs nothing anymore.

To Reproduce
Steps to reproduce the behavior:

sudo systemctl start strongswan
sudo swanctl -l

Logs/Backtraces

ps -aux | grep charon

root        2518  0.0  0.0   6832  2816 ?        Ss   20:03   0:00 /usr/lib/ipsec/starter --daemon charon --nofork
root        2530  0.0  0.0 1209304 16128 ?       Ssl  20:03   0:00 /usr/lib/ipsec/charon
root        4539  0.0  0.0 1209304 17792 ?       Ssl  20:05   0:00 /usr/sbin/charon-systemd

journalctl | grep "charon\|strongswan"

Jun 10 20:05:31 okn408 systemd[1]: Starting strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl...
Jun 10 20:05:31 okn408 charon-systemd[4539]: Starting charon-systemd IKE daemon (strongSwan 5.9.13, Linux 6.8.0-35-generic, x86_64)
Jun 10 20:05:31 okn408 charon-systemd[4539]: PKCS11 module '<name>' lacks library path
Jun 10 20:05:31 okn408 charon-systemd[4539]: providers loaded by OpenSSL: legacy default
Jun 10 20:05:31 okn408 charon-systemd[4539]: using '/sbin/resolvconf' to install DNS servers
Jun 10 20:05:31 okn408 charon[2530]: 01[KNL] interface xfrmi-test-1195 activated
Jun 10 20:05:31 okn408 charon[2530]: 08[KNL] fe80::72eb:d3a2:2911:8933 appeared on xfrmi-test-1195
Jun 10 20:05:31 okn408 charon[2530]: 11[KNL] interface xfrmi-test-1195 deactivated
Jun 10 20:05:31 okn408 charon[2530]: 15[KNL] fe80::72eb:d3a2:2911:8933 disappeared from xfrmi-test-1195
Jun 10 20:05:31 okn408 charon[2530]: 14[KNL] interface xfrmi-test-1195 deleted
Jun 10 20:05:31 okn408 charon-systemd[4539]: unable to bind socket: Address already in use
Jun 10 20:05:31 okn408 charon-systemd[4539]: could not open IPv6 socket, IPv6 disabled
Jun 10 20:05:31 okn408 charon-systemd[4539]: unable to bind socket: Address already in use
Jun 10 20:05:31 okn408 charon-systemd[4539]: could not open IPv4 socket, IPv4 disabled
Jun 10 20:05:31 okn408 charon-systemd[4539]: could not create any sockets
Jun 10 20:05:31 okn408 charon-systemd[4539]: unable to create IPv4 routing table rule
Jun 10 20:05:31 okn408 charon-systemd[4539]: unable to create IPv6 routing table rule
Jun 10 20:05:31 okn408 charon-systemd[4539]: using forecast interface wlp9s0
Jun 10 20:05:31 okn408 charon-systemd[4539]: joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading ca certificates from '/etc/ipsec.d/cacerts'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading aa certificates from '/etc/ipsec.d/aacerts'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading attribute certificates from '/etc/ipsec.d/acerts'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading crls from '/etc/ipsec.d/crls'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loading secrets from '/etc/ipsec.secrets'
Jun 10 20:05:31 okn408 charon-systemd[4539]: loaded 0 RADIUS server configurations
Jun 10 20:05:31 okn408 charon-systemd[4539]: HA config misses local/remote address
Jun 10 20:05:31 okn408 charon-systemd[4539]: loaded plugins: charon-systemd test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl gcrypt pkcs8 af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac kdf ctr ccm gcm ntru drbg curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters
Jun 10 20:05:31 okn408 charon-systemd[4539]: dropped capabilities, running as uid 0, gid 0
Jun 10 20:05:31 okn408 charon-systemd[4539]: spawning 16 worker threads
Jun 10 20:05:31 okn408 charon-systemd[4539]: no socket implementation registered, receiving failed
Jun 10 20:05:32 okn408 charon-systemd[4539]: loaded certificate 'O=Forcepoint, CN=fw-par-martel - Primary'
Jun 10 20:05:32 okn408 charon-systemd[4539]: loaded EAP shared key with id 'eap-user' for: 'sbouchut'
Jun 10 20:05:32 okn408 charon-systemd[4539]: added vici connection: ikev2-eap
Jun 10 20:05:32 okn408 charon-systemd[4539]: initiating 'ikev2-eap'
Jun 10 20:05:32 okn408 charon-systemd[4539]: initiating IKE_SA ikev2-eap[1] to 178.208.19.11
Jun 10 20:05:32 okn408 charon-systemd[4539]: generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jun 10 20:05:32 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)
Jun 10 20:05:32 okn408 charon-systemd[4539]: no socket implementation registered, sending failed
Jun 10 20:05:32 okn408 swanctl[4564]: loaded certificate from '/etc/swanctl/x509/certificate.crt'
Jun 10 20:05:32 okn408 swanctl[4564]: loaded eap secret 'eap-user'
Jun 10 20:05:32 okn408 swanctl[4564]: no authorities found, 0 unloaded
Jun 10 20:05:32 okn408 swanctl[4564]: no pools found, 0 unloaded
Jun 10 20:05:32 okn408 swanctl[4564]: loaded connection 'ikev2-eap'
Jun 10 20:05:32 okn408 swanctl[4564]: successfully loaded 1 connections, 0 unloaded
Jun 10 20:05:32 okn408 systemd[1]: Started strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
Jun 10 20:05:32 okn408 charon[2530]: 08[NET] using forecast interface wlp9s0
Jun 10 20:05:32 okn408 charon[2530]: 08[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
Jun 10 20:05:36 okn408 charon-systemd[4539]: retransmit 1 of request with message ID 0
Jun 10 20:05:36 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)
Jun 10 20:05:36 okn408 charon-systemd[4539]: no socket implementation registered, sending failed
Jun 10 20:05:43 okn408 charon-systemd[4539]: retransmit 2 of request with message ID 0
Jun 10 20:05:43 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)
Jun 10 20:05:43 okn408 charon-systemd[4539]: no socket implementation registered, sending failed
Jun 10 20:05:56 okn408 charon-systemd[4539]: retransmit 3 of request with message ID 0
Jun 10 20:05:56 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)
Jun 10 20:05:56 okn408 charon-systemd[4539]: no socket implementation registered, sending failed
Jun 10 20:06:19 okn408 charon-systemd[4539]: retransmit 4 of request with message ID 0
Jun 10 20:06:19 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)
Jun 10 20:06:19 okn408 charon-systemd[4539]: no socket implementation registered, sending failed
Jun 10 20:07:01 okn408 charon-systemd[4539]: retransmit 5 of request with message ID 0                                                                                                        
Jun 10 20:07:01 okn408 charon-systemd[4539]: sending packet: from 192.168.1.198 to 178.208.19.11[500] (304 bytes)                                                                             
Jun 10 20:07:01 okn408 charon-systemd[4539]: no socket implementation registered, sending failed                                                                                              
Jun 10 20:08:17 okn408 charon-systemd[4539]: giving up after 5 retransmits                                                                                                                    
Jun 10 20:08:17 okn408 charon-systemd[4539]: establishing IKE_SA failed, peer not responding

Additional context

Install command:

sudo apt install strongswan strongswan-swanctl charon-systemd libstrongswan-extra-plugins libcharon-extra-plugins

Configuration file:

connections {
    ikev2-eap {
        keyingtries = 1
        rekey_time = 1440m
        version = 2
        proposals = aes256-sha256-ecp384
        remote_addrs = 178.208.19.11
        vips = 0.0.0.0,::
        local {
            auth = eap
            id = sbouchut
            eap_id = %any
        }
        remote {
            auth = pubkey
            id = 178.208.19.11
        }
        children {
            ikev2-eap {
                remote_ts = 0.0.0.0/0,::0
                esp_proposals = aes256-sha256
                start_action = start
            }
        }
    }
}
secrets {
    eap-user {
        id = sbouchut
        secret = ***
    }
}

ip link show          

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether e8:80:88:9d:7c:b6 brd ff:ff:ff:ff:ff:ff
3: wlp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 04:7b:cb:bc:4a:4a brd ff:ff:ff:ff:ff:ff
5: br-019518ea4f6f: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:34:a3:95:2a brd ff:ff:ff:ff:ff:ff
6: br-12e4bc00aa5c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:e0:fc:d1:90 brd ff:ff:ff:ff:ff:ff
7: br-82e95c156750: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:f2:4c:7d:6b brd ff:ff:ff:ff:ff:ff
8: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:7c:46:54:d5 brd ff:ff:ff:ff:ff:ff
9: br-a301ad1410c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:16:7f:d5:0e brd ff:ff:ff:ff:ff:ff

sudo ipsec statusall

Status of IKE charon daemon (strongSwan 5.9.13, Linux 6.8.0-35-generic, x86_64):
  uptime: 6 minutes, since Jun 10 22:24:00 2024
  malloc: sbrk 3170304, mmap 0, used 1258672, free 1911632
  worker threads: 12 of 16 idle, 4/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon-systemd test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl gcrypt pkcs8 af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac kdf ctr ccm gcm ntru drbg curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters
Listening IP addresses:
  192.168.1.198
  2a01:e0a:20e:3720:ec0d:58bc:42d4:e752
  172.18.0.1
  192.168.49.1
  172.17.0.1
  192.168.58.1
  172.19.0.1
Connections:
   ikev2-eap:  %any...178.208.19.11  IKEv2
   ikev2-eap:   local:  [sbouchut] uses EAP authentication with EAP identity '%any'
   ikev2-eap:   remote: [178.208.19.11] uses public key authentication
   ikev2-eap:   child:  dynamic === 0.0.0.0/0 ::/128 TUNNEL
Security Associations (0 up, 0 connecting):
  none

Answered by tobiasbrunner

Jun 11, 2024

Besides the charon-systemd daemon controlled by the strongswan systemd unit, you also have the starter and charon daemons running that compete for the same ports. The latter two daemons are controlled by the strongswan-starter systemd unit, so either disable that or just uninstall the strongswan-starter package.

View full answer

tobiasbrunner · 2024-06-11T07:35:12Z

tobiasbrunner
Jun 11, 2024
Maintainer

Besides the charon-systemd daemon controlled by the strongswan systemd unit, you also have the starter and charon daemons running that compete for the same ports. The latter two daemons are controlled by the strongswan-starter systemd unit, so either disable that or just uninstall the strongswan-starter package.

10 replies

corsac-s Jun 11, 2024

As far as I know the packaging is different between Debian and Ubuntu (Ubuntu split the packages a lot more than we do) so I think it'd be best to first ask Ubuntu people.

If there really is a conflict betwen charon-systemd and strongswan-starter we might have to express it in Debian but that looks a bit weird to me. There's obviously no need to have both but why their coinstallation is suddenly a problem?

sergebouchut2 Jun 12, 2024
Author

I am wiling to help, but as a simple user, I am not sure to have the required knowledge (about the services and the packages) to handle this request to the OS maintainers. Thanks @corsac-s for taking over this issue, feel free to ask if you need further information.

tobiasbrunner Jun 12, 2024
Maintainer

As far as I know the packaging is different between Debian and Ubuntu (Ubuntu split the packages a lot more than we do) so I think it'd be best to first ask Ubuntu people.

Ah, I thought they stopped doing that a while ago (I know they previously split individual plugins into separate packages).

There's obviously no need to have both but why their coinstallation is suddenly a problem?

If both are enabled/running it was a problem before as both daemons open and bind UDP sockets on the same ports (by default). But before 5.9.8, there was no error because SO_REUSEADDR was set on the sockets. That allowed both daemons to bind them, however, packets were not actually received by both, which lead to more subtle issues (sending packets worked fine, but no response was received when the other daemon got them). So I dropped that flag to get errors logged when a second daemon tries to open its sockets on the same ports (83da133).

corsac-s Jun 12, 2024

Ok so it's more the daemons which should conflict with each other, not the starter (so strongswan-charon and charon-systemd)?

tobiasbrunner Jun 13, 2024
Maintainer

Technically yes, but starter and charon are generally used together and it's the strongswan-starter package that provides the strongswan-starter (and ipsec) systemd unit. The strongswan-charon package on its own isn't all that useful (charon doesn't deamonize and there is no systemd unit). And it's also the starter daemon that reads the ipsec.conf file, so using charon directly only works via vici/swanctl. However, that can be an option e.g. in containers without systemd where charon-systemd can't be used and ipsec.conf and starter aren't required.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VPN client suddenly stopped working with error: no socket implementation registered - StrongSwan 5.9.13 - Ubuntu 24.04 - Kernel 6.8.0 #2282

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 10 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

VPN client suddenly stopped working with error: no socket implementation registered - StrongSwan 5.9.13 - Ubuntu 24.04 - Kernel 6.8.0 #2282

sergebouchut2 Jun 10, 2024

Replies: 1 comment · 10 replies

tobiasbrunner Jun 11, 2024 Maintainer

corsac-s Jun 11, 2024

sergebouchut2 Jun 12, 2024 Author

tobiasbrunner Jun 12, 2024 Maintainer

corsac-s Jun 12, 2024

tobiasbrunner Jun 13, 2024 Maintainer

sergebouchut2
Jun 10, 2024

Replies: 1 comment 10 replies

tobiasbrunner
Jun 11, 2024
Maintainer

sergebouchut2 Jun 12, 2024
Author

tobiasbrunner Jun 12, 2024
Maintainer

tobiasbrunner Jun 13, 2024
Maintainer