Buggy? IKEv2 configured, but status shows IKEv1

larsen · 27 August 2021 10:58

I have an site2site IPsec connection configured with IKEv2 as can be seen in “/var/ipfire/vpn/config”, but the status shows IKEv1:

ipsec statusall | grep othercompany
     othercompany:  vpn.ourselves.de...185.xxx.xxx.xxx  IKEv1, dpddelay=30s

This used to work with IKEv1 before, and has been switched to IKEv2 recently (on both sites). We were not able to establish a connection despite having restarted IPsec.

Can anyone reproduce this?
Maybe it’s only occuring when the connection was initially setup with IKEv1 and only later switched to IKEv2?

Lars

pmueller · 30 August 2021 11:39

Hi,

could you post the log messages to this incident? They’ll have the charon prefix in /var/log/messages, so a

grep "charon:" /var/log/messages

should do the trick. Feel free to redact any sensitive information, if necessary.

I am unaware of such a bug, but that does not necessarily mean there is none involved.

Thanks, and best regards,
Peter Müller

larsen · 30 August 2021 14:46

I have uploaded the log to pastebin from the most recent try. We tested several settings but afair this should have been IKEv2 on both sides.

EDIT: Log messages copied from Pastebin below.

Aug 27 11:48:17 ipfire charon: 01[NET] received packet: from <customerIP>[500] to <our IP>[500] (1282 bytes) 
Aug 27 11:48:17 ipfire charon: 01[ENC] parsed IKE_SA_INIT request 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) V ] 
Aug 27 11:48:17 ipfire charon: 01[IKE] received Cisco Delete Reason vendor ID 
Aug 27 11:48:17 ipfire charon: 01[IKE] received Cisco Copyright (c) 2009 vendor ID 
Aug 27 11:48:17 ipfire charon: 01[IKE] received FRAGMENTATION vendor ID 
Aug 27 11:48:17 ipfire charon: 01[IKE] <customerIP> is initiating an IKE_SA 
Aug 27 11:48:17 ipfire charon: 01[IKE] <customerIP> is initiating an IKE_SA 
Aug 27 11:48:17 ipfire charon: 01[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 
Aug 27 11:48:17 ipfire charon: 01[IKE] DH group ECP_384 unacceptable, requesting MODP_2048 
Aug 27 11:48:17 ipfire charon: 01[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] 
Aug 27 11:48:17 ipfire charon: 01[NET] sending packet: from <our IP>[500] to <customerIP>[500] (38 bytes) 
Aug 27 11:48:17 ipfire charon: 08[NET] received packet: from <customerIP>[500] to <our IP>[500] (1442 bytes) 
Aug 27 11:48:17 ipfire charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) V ] 
Aug 27 11:48:17 ipfire charon: 08[IKE] received Cisco Delete Reason vendor ID 
Aug 27 11:48:17 ipfire charon: 08[IKE] received Cisco Copyright (c) 2009 vendor ID 
Aug 27 11:48:17 ipfire charon: 08[IKE] received FRAGMENTATION vendor ID 
Aug 27 11:48:17 ipfire charon: 08[IKE] <customerIP> is initiating an IKE_SA 
Aug 27 11:48:17 ipfire charon: 08[IKE] <customerIP> is initiating an IKE_SA 
Aug 27 11:48:17 ipfire charon: 08[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 
Aug 27 11:48:17 ipfire charon: 08[IKE] sending cert request for "C=DE, O=ourcompany - IPsec, CN=ourcompany - IPsec CA" 
Aug 27 11:48:17 ipfire charon: 08[ENC] 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) ] 
Aug 27 11:48:17 ipfire charon: 08[NET] sending packet: from <our IP>[500] to <customerIP>[500] (481 bytes) 
Aug 27 11:48:17 ipfire charon: 09[NET] received packet: from <customerIP>[500] to <our IP>[500] (288 bytes) 
Aug 27 11:48:17 ipfire charon: 09[ENC] parsed IKE_AUTH request 1 [ V IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ] 
Aug 27 11:48:17 ipfire charon: 09[CFG] looking for peer configs matching <our IP>[%any]...<customerIP>[<customerIP>] 
Aug 27 11:48:17 ipfire charon: 09[CFG] no matching peer config found 
Aug 27 11:48:17 ipfire charon: 09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Aug 27 11:48:17 ipfire charon: 09[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] 
Aug 27 11:48:17 ipfire charon: 09[NET] sending packet: from <our IP>[500] to <customerIP>[500] (80 bytes)

Disclaimer: I am mostly clueless regarding IPsec. Customer is the one with some knowledge =)

Do you have any IKEv2 connection and can see IKEv2 in the output of “ipsec statusall”?

pmueller · 30 August 2021 15:13

Hi,

thanks for reporting back.

So the remote device wants some crypto your IPFire machine does not know anything about (or has not configured for this connection). Just bumped across this, but that is nothing serious…

larsen:

Aug 27 11:48:17 ipfire charon: 09[NET] received packet: from <customerIP>[500] to <our IP>[500] (288 bytes) 
Aug 27 11:48:17 ipfire charon: 09[ENC] parsed IKE_AUTH request 1 [ V IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ] 
Aug 27 11:48:17 ipfire charon: 09[CFG] looking for peer configs matching <our IP>[%any]...<customerIP>[<customerIP>] 
Aug 27 11:48:17 ipfire charon: 09[CFG] no matching peer config found

This is where the error happens: The customer’s VPN device sends you an IKE authentication packet containing a peer configuration (i. e. which networks should be routed through that IPsec connection) not matching to anything configured on you IPFire machine.

Please ensure the networks configured for this connection are the same on both your and the customers and (as described here). Perhaps there was some Copy & Waste involved when creating an IKEv2 connection…

Yes:

[root@maverick ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.2, Linux 5.10.55-ipfire, x86_64):
  uptime: x hours, since Aug 30 xx:xx:xx 2021
  malloc: sbrk x, mmap 0, used x, free x
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11
  loaded plugins: charon aes des sha2 sha3 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm drbg curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth dhcp counters
Listening IP addresses:
  10.x.x.x
  10.x.x.x
  85.x.x.x
Connections:
      BRANCHA:  %any...x  IKEv2, dpddelay=10s
      BRANCHA:   local:  [x] uses public key authentication
      BRANCHA:    cert:  "C=AT, O=ACME, Inc. - Branch A, CN=x"
      BRANCHA:   remote: [C=BE, O=ACME, Inc. - Branch A, CN=x] uses public key authentication
      BRANCHA:    cert:  "C=BE, O=ACME, Inc. - Branch A, CN=x"
      BRANCHA:   child:  10.x.x.x/32 === 10.x.x.x/32 TUNNEL, dpdaction=clear
      BRANCHB:  %any...x  IKEv2, dpddelay=10s
      BRANCHB:   local:  [x] uses public key authentication
      BRANCHB:    cert:  "C=AT, O=ACME, Inc. - Branch A, CN=x"
      BRANCHB:   remote: [x] uses public key authentication
      BRANCHB:    cert:  "C=AT, O=ACME, Inc. - Branch B, CN=x"
      BRANCHB:   child:  10.x.x.x/24 === 10.x.x.x/24 10.x.x.x/24 TUNNEL, dpdaction=restart
      BRANCHC:  %any...x  IKEv2, dpddelay=10s
      BRANCHC:   local:  [x] uses public key authentication
      BRANCHC:    cert:  "C=AT, O=ACME, Inc. - Branch A, CN=x"
      BRANCHC:   remote: [x] uses public key authentication
      BRANCHC:    cert:  "C=AT, O=ACME, Inc. - Branch C, CN=x"
      BRANCHC:   child:  10.x.x.x/24 === 10.x.x.x/24 10.x.x.x/24 TUNNEL, dpdaction=restart
Security Associations (3 up, 0 connecting):
      BRANCHC[20]: ESTABLISHED 37 minutes ago, 85.x.x.x[x]...x[x]
      BRANCHC[20]: IKEv2 SPIs: 03c14572ca94b3b5_i* cc5d75436a73d38f_r, public key reauthentication in 119 minutes
      BRANCHC[20]: IKE proposal: CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_25519
      BRANCHC{62}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: ca9ebe4f_i c6efc783_o
      BRANCHC{62}:  CHACHA20_POLY1305, 962509 bytes_i (4902 pkts, 0s ago), 1323253 bytes_o (6573 pkts, 0s ago), rekeying in 9 minutes
      BRANCHC{62}:   10.x.x.x/24 === 10.x.x.x/24 10.x.x.x/24
      BRANCHB[21]: ESTABLISHED 22 minutes ago, 85.x.x.x[x]...x[x]
      BRANCHB[21]: IKEv2 SPIs: 0f6add2f8902bd63_i* 30e2ce021a8ecf9f_r, public key reauthentication in 2 hours
      BRANCHB[21]: IKE proposal: CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_25519
      BRANCHB{63}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: c9154df6_i cc6400f0_o
      BRANCHB{63}:  CHACHA20_POLY1305, 0 bytes_i, 0 bytes_o, rekeying in 21 minutes
      BRANCHB{63}:   10.x.x.x/24 === 10.x.x.x/24 10.x.x.x/24
      BRANCHA[19]: ESTABLISHED 44 minutes ago, 85.x.x.x[x]...x[C=BE, O=ACME, Inc. - Branch A, CN=x]
      BRANCHA[19]: IKEv2 SPIs: f7b54aeddf6dd76c_i 4f80de8c4622808d_r*, public key reauthentication in 2 hours
      BRANCHA[19]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512/CURVE_25519
      BRANCHA{61}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cf8bf933_i c42346ef_o
      BRANCHA{61}:  AES_GCM_16_256, 9137 bytes_i (122 pkts, 5s ago), 9595 bytes_o (136 pkts, 5s ago), rekeying in 12 seconds
      BRANCHA{61}:   10.x.x.x/32 === 10.x.x.x/32

Thanks, and best regards,
Peter Müller

larsen · 30 August 2021 16:19

Hmm, will have to consult the customer on this. I only switched from IKEv1 to IKEv2 so nothing was changed on the network part.

Then it really seems like a bug that I get IKEv1 in this output, when it’s configured to use IKEv2.

I just realized that I should check the strongswan config that is generated and noticed that it doesn’t change there, even after restarting IPsec via GUI.
After I manually edited /etc/ipsec.conf and restarted IPsec, status output also showed “IKEv2”.

grep customer -A23 /etc/ipsec.conf | grep ike

Could you please try to reproduce this behaviour?

Have an existing connection
grep like stated above
Change IKEv1 to IKEv2 (or vice versa) via GUI
grep like stated above

Edit: Just noticed that the config is also in “/var/ipfire/vpn/ipsec.conf” and there it indeed is changed…
Is it possible that the etc file should be a symlink to the var file?

mangrove · 30 August 2021 16:50

Exactly, the /etc/ipsec.conf should be a symlink to /var/ipfire/vpn/ipsec.conf !

larsen · 30 August 2021 17:41

Ah ok, then it’s not a bug. We recently switched our ISP, so I had to replace the old external IP with the new one. Didn’t notice that file was a symlink when I grepped /etc and used sed to replace the value afterwards. I always found it unfortunate that sed replaces a symlink with an actual file.

Does the rest look ok?

ipfire:# cd /etc && ll -d ipsec.*
lrwxrwxrwx 1 root root   26 Aug 30 19:36 ipsec.conf -> /var/ipfire/vpn/ipsec.conf
drwxr-xr-x 7 root root 4.0K May  4 13:15 ipsec.d
lrwxrwxrwx 1 root root   29 Dec 14  2016 ipsec.secrets -> /var/ipfire/vpn/ipsec.secrets
-rw-r--r-- 1 root root   65 Jan 14  2016 ipsec.user.conf
-rw-r--r-- 1 root root  396 Oct  9  2017 ipsec.user-post.conf
-rw-r--r-- 1 root root  306 Sep 20  2017 ipsec.user.secrets

mangrove · 30 August 2021 17:49

I don’t have that file at all, but otherwise it looks right. And looking at ipfire-2.x/html/cgi-bin/vpnmain.cgi at master · ipfire/ipfire-2.x · GitHub it should be there so you should be all set.

larsen · 30 August 2021 18:13

Alright. Thank both of you!