21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW

dwood9100

@jimp Didn't realize that one previously. Tried it and still no bueno.

Feb 22 14:29:31	charon	23877	02[MGR] <con100000|34731> tried to checkin and delete nonexistent IKE_SA
Feb 22 14:29:31	charon	23877	02[CFG] <con100000|34731> configuration uses unsupported authentication
Feb 22 14:29:31	charon	23877	02[IKE] <con100000|34731> no private key found for 'O=fwmgmt..6smz2n'
Feb 22 14:29:31	charon	23877	02[IKE] <con100000|34731> initiating Main Mode IKE_SA con100000[34731] to xxx.xxx.xxx.xxx
Feb 22 14:29:31	charon	23877	15[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {5}
Feb 22 14:29:22	charon	23877	14[MGR] <con100000|34730> tried to checkin and delete nonexistent IKE_SA
Feb 22 14:29:22	charon	23877	14[CFG] <con100000|34730> configuration uses unsupported authentication

jimp

I tried breaking my tunnel which uses certs in various ways but the only way I could do it was to use identifiers which were not a part of the certificate, or to not have the correct matching CAs present on one side or the other.

hb_nmedia

@dwood9100 Have the same issue upgraded pfSense 2.4.5 p1 to 2.5.1 -> Checkpoint FW.

Just curious did you resolve it anyway or downgraded?

bart79

similar problem here (not to checkpoint but to cisco asa).
i have two similiar IPsec VPNs: one on 2.5.1, one on 2.4.5-RELEASE-p1
both of them pointing to the same endpoint but with different cert (same CA though)

the one on 2.4.5-RELEASE-p1 is ok
the one one 2.5.1 is KO

Jun 1 10:27:45 charon 16438 11[CFG] <con400000|313> configuration uses unsupported authentication
Jun 1 10:27:45 charon 16438 11[IKE] <con400000|313> no private key found for 'xy.xyz.125.253'

xy.xyz.125.253 is my IP (configured as "My identifier")

bart79

it seems working setting my identifer as asn.1, but using as DN the output of the command:
ipsec listcerts

that output is different from the DN shown in GUI (system/certificate manager/certificates)

the "ipsec listcetrs" command shows this order
C O OU CN
in the subject row

system/certificate manager/certificates, instead, shows this order
OU O CN C

on 2.4.5-RELEASE-p1 the ipsec works with "my ip address" as my identifier
is there a way to make it works with ip as identifier also on 2.5.1?

jimp

The Distinguished Name identifier type is for a fully qualified domain name (FQDN, hostname). For a certificate subject you would want to use the ASN.1 Distinguished Name type.

Getting mutual certificate auth working is about two things, primarily:

Making sure both sides can properly identify each other
Making sure both sides use identifiers which exist in the certificates exactly

I made a fresh setup and made new CA and cert entries for a pair of systems which had never connected. I created a certificate for each, with a generic CN and then SAN entries for the system hostname and IP address.

I was able to connect using the certificates any way I tried:

Using My IP Address / Peer IP Address worked because I had the IP addresses in the certificates, obviously this isn't viable for dynamic connections but you could use a static address in the cert so long as the peer identifier is hardcoded to the same address in the cert.
Using Distinguished Name works by the CN of the certificate or the hostname in the SAN entry
Using ASN.1 Distinguished Name works so long as your DN matches what is in the certificate exactly (check the DN as reported in the certificate details, not the list, or as shown in OpenSSL directly or ipsec listcerts)

In each of these cases, do not add your own quotes in the GUI field. For example, use a DN of mycertname or host.example.com, an ASN.1 DN of CN=mycertname, or an IP address like 1.2.3.4, all without quotes.

It's unclear why/how previously working tunnels might have stopped working, but it may be a change in strongSwan which fixed checks which may have been too loose before.

I'll try to get all of this in the docs before too long with an up-to-date example.

My basic process was:

Create a new CA on each system, A-CA and B-CA
Create a new user cert on each system, A-cert and B-cert, with a CN of hostname, FQDN SAN of hostname.example.com, IP Address SAN of its WAN IP address
Export the CAs
Import the opposing system CAs (e.g. on B, import A-CA)
Setup the tunnels with the correct identifiers and using the appropriate My Certificate (e.g. A-cert) and Peer Certificate Authority (e.g. B-CA) selections

In each case it was easy to test and get output from the CLI using swanctl --initiate --ike con100000 so it outputs the relevant logs in the terminal directly, so no need to sort through other log data.

jimp

I have all the relevant info massaged into the docs now. There was an existing document but it was light on specifics, this new one is more accurate and informative.

https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-tls.html

bart79

@jimp Hi Jimp, thanks for your support
the problem is that the other endpoint expects my IP as my identifier altough using a cert that they have issued for authenticate the phase1.

pfsense version 2.4.5 allows that kind of conf
instead 2.5 have some stricter measures problably

JeGr

@bart79 If you change Phase 1 proposal to mutual certificate, you can still send "My identifier" as your IP address. That is nothing that has changed in 2.4->2.5
It's still the same: PSK shows PSK form field, cert switches the PSK field to two dropdowns for CA and certificate. The only addition is that 2.5 now also can run with PKCS11 certs.

So I don't understand the problem with using the certificate?

bart79

@jegr hi Jegr
yes you can change it, but pfsense/strongswan won't find a private key, since the ip is not the CN or a SAN of the cert

previously with 2.4/strongSwan 5.8.4 you can chose my ip as identifier without that ip as cn or san of the cert

bart79

@jegr the new strongswan/pfsense version, in case of cert ipsec vpn, will look for a private key that corresponds exactly to the identifier

previouly this check wasn't done, in the previous version you can choose also the ip as identifier although it was not "stated" as CN or SAN in the cert used for authentication