ipsec.secrets identity and left|rightid confusion

[joshuadugie]

At issue is the "Gateway ID" field under the "IPsec Settings..." dialog for the VPN. If the VPN server is configured with leftid set to a FQDN, e.g., vpn.example.com, within its ipsec.conf and is using IKEv1...

• If the Gateway ID field on the client is set to the same FQDN:

  • When bringing up the VPN connection, /etc/ipsec.secrets is replaced with the template of %any @vpn.example.com : PSK "The_VPN_PSK"

  • Unfortunately, strongSwan as documented here will not use the FQDN for identification:

    When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded, so the ID used will be the IP address.

  • Therefore, the following error is logged in syslog by strongSwan:

    Jan 01 00:00:00 localhost charon: 09[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ] Jan 01 00:00:00 localhost charon: 09[NET] sending packet: from 192.162.1.2[500] to 93.184.216.34[500] (372 bytes) Jan 01 00:00:00 localhost charon: 10[NET] received packet: from 93.184.216.34[500] to 192.162.1.2[500] (372 bytes) Jan 01 00:00:00 localhost charon: 10[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ] Jan 01 00:00:00 localhost charon: 10[ENC] generating INFORMATIONAL_V1 request 4112651576 [ N(INVAL_KE) ] Jan 01 00:00:00 localhost charon: 10[NET] sending packet: from 192.162.1.2[500] to 93.184.216.34[500] (56 bytes)

  • strongSwan is not using the FQDN as also indicated at https://wiki.strongswan.org/issues/981:

    The only code path that produces no additional log message seems to be if no pre-shared secret is found.

• Alternatively, if the Gateway ID field is set to the global IP address of the server, or if the Gateway ID field unset, in which case the IP address is used instead, the following occurs:

  • When bringing up the VPN connection, /etc/ipsec.secrets is replaced with the template of %any %any : PSK "The_VPN_PSK"
  • For some reason, strongSwan does not accept this as a true "any" and it does not match the server's reported identity
  • The following error is logged in syslog by strongSwan:

    Jan 01 00:00:00 localhost charon: 14[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ] Jan 01 00:00:00 localhost charon: 14[IKE] local host is behind NAT, sending keep alives Jan 01 00:00:00 localhost charon: 14[IKE] remote host is behind NAT Jan 01 00:00:00 localhost charon: 14[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] Jan 01 00:00:00 localhost charon: 14[NET] sending packet: from 192.162.1.2[4500] to 93.184.216.34[4500] (108 bytes) Jan 01 00:00:00 localhost charon: 11[NET] received packet: from 93.184.216.34[4500] to 192.162.1.2[4500] (92 bytes) Jan 01 00:00:00 localhost charon: 11[ENC] parsed ID_PROT response 0 [ ID HASH ] Jan 01 00:00:00 localhost charon: 11[IKE] IDir 'vpn.example.com' does not match to '93.184.216.34' Jan 01 00:00:00 localhost charon: 11[IKE] deleting IKE_SA nm-ipsec-l2tp-2615[1] between 192.162.1.2[192.162.1.2]...93.184.216.34[%any]

In both cases, the connection fails since the strongSwan client does not recognize the server's reported identity of the FQDN. This can be fixed by commenting out lines 994 to 1016 in order to make the overwritten ipsec.secrets file instead be the template of : PSK "The_VPN_PSK". In this case, strongSwan does use the global PSK for the server and the connection is established.

To fix this, either this client could:

1. detect IKEv1 being used
2. if "Gateway ID" is used for other purposes, create another field separate from "Gateway ID" to be used for the server identity in ipsec.secrets
3. ignore "Gateway ID" entirely and always use the : PSK "The_VPN_PSK" template if "Gateway ID" is a FQDN
4. allow the user to specify that no identity should be used in ipsec.secrets, resulting in the correct template of : PSK "The_VPN_PSK"

[dkosovic]

Apologies for my tardiness, been on holiday leave with little Internet access and no Linux.

Will try and work on it tommorow and also think about it a bit more.

[dkosovic]

Thanks for the bug report.

No ID is used now in the temporarily generated ipsec.secrets

[joshuadugie]

Thank you.