21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW
-
I'm not sure why it would be sending a PSK unless it believes it to be a better match for the remote ID.
Can you try using the certificate DNs as the IDs instead of hostnames?
-
@jimp The only problem with that is that Checkpoint certs only have the "O" element of the DN and pfsense wants a fully qualified DN.
-
pfsense wants a fully qualified DN.
Where do you see that?
I was able to save a P1 entry with the peer ID set to ASN.1 Distinguished Name and a value of
O=foo
. I didn't do a connectivity test though. -
@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
-
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.
-
@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?
-
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 KOJun 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")
-
it seems working setting my identifer as asn.1, but using as DN the output of the command:
ipsec listcertsthat 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 rowsystem/certificate manager/certificates, instead, shows this order
OU O CN Con 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? -
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
orhost.example.com
, an ASN.1 DN ofCN=mycertname
, or an IP address like1.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 ofhostname.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. -
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
-
@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 -
@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?
-
@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 certpreviously with 2.4/strongSwan 5.8.4 you can chose my ip as identifier without that ip as cn or san of the cert
-
@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