21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW

dwood9100

I've had a working ipsec configuration in place for several years between two remote offices (Netgate SG-4860 and pfsense CE) and our headquarter office (Checkpoint FW). This week we upgraded both pfsense firewalls to 21.02 and 2.5 respectively and their connection to our Checkpoint FW no longer works.

Based on some of the other posts that we have researched, I can provide the following details:

The contents of the /var/etc/ipsec/swanctl.conf:

# This file is automatically generated. Do not edit
connections {
	bypass {
		remote_addrs = 127.0.0.1
		children {
			bypasslan {
				local_ts = 192.168.110.0/23
				remote_ts = 192.168.110.0/23
				mode = pass
				start_action = trap
			}
		}
	}
	con100000 {
		fragmentation = yes
		unique = replace
		version = 1
		aggressive = no
		proposals = aes256-sha1-modp1024
		dpd_delay = 10s
		dpd_timeout = 60s
		reauth_time = 1296s
		over_time = 144s
		rand_time = 144s
		encap = no
		mobike = no
		local_addrs = 172.16.30.1
		remote_addrs = xxx.xxx.xxx.xxx
		pools = 
		send_cert = always
		local {
			id = 172.16.30.1
			auth = pubkey
			cert {
				file = /var/etc/ipsec/x509/cert-1.crt
			}
		}
		remote {
			id = xxx.xxx.xxx.xxx
			auth = pubkey
			cacerts = /var/etc/ipsec/x509ca/d88c081a.0
		}
		children {
			con0 {
				dpd_action = trap
				mode = tunnel
				policies = yes
				life_time = 3600s
				rekey_time = 3240s
				rand_time = 360s
				start_action = trap
				local_ts = 172.16.30.0/24
				remote_ts = 192.168.106.0/24
				esp_proposals = aes128-sha1
			}
			con1 {
				dpd_action = trap
				mode = tunnel
				policies = yes
				life_time = 3600s
				rekey_time = 3240s
				rand_time = 360s
				start_action = trap
				local_ts = 172.16.30.0/24
				remote_ts = 10.0.1.0/24
				esp_proposals = aes128-sha1
			}
			con2 {
				dpd_action = trap
				mode = tunnel
				policies = yes
				life_time = 3600s
				rekey_time = 3240s
				rand_time = 360s
				start_action = trap
				local_ts = 172.16.30.0/24
				remote_ts = 10.11.0.0/22
				esp_proposals = aes128-sha1
			}
			con3 {
				dpd_action = trap
				mode = tunnel
				policies = yes
				life_time = 3600s
				rekey_time = 3240s
				rand_time = 360s
				start_action = trap
				local_ts = 172.16.30.0/24
				remote_ts = 10.12.1.0/24
				esp_proposals = aes128-sha1
			}
			con4 {
				dpd_action = trap
				mode = tunnel
				policies = yes
				life_time = 3600s
				rekey_time = 3240s
				rand_time = 360s
				start_action = trap
				local_ts = 172.16.30.0/24
				remote_ts = 10.13.0.0/24
				esp_proposals = aes128-sha1
			}
		}
	}
}
secrets {
	private-0 {
		file = /var/etc/ipsec/private/cert-1.key
	}
}

swanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1

loaded certificate from '/var/etc/ipsec/x509/cert-1.crt'
loaded certificate from '/var/etc/ipsec/x509ca/d88c081a.0'
loaded RSA key from '/var/etc/ipsec/private/cert-1.key'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'bypass'
loaded connection 'con100000'
successfully loaded 2 connections, 0 unloaded

ipsec log:

Feb 19 09:17:31	charon	23877	06[MGR] <con100000|7086> tried to checkin and delete nonexistent IKE_SA
Feb 19 09:17:31	charon	23877	06[CFG] <con100000|7086> configuration uses unsupported authentication
Feb 19 09:17:31	charon	23877	06[IKE] <con100000|7086> no private key found for '172.16.30.1'
Feb 19 09:17:31	charon	23877	06[IKE] <con100000|7086> initiating Main Mode IKE_SA con100000[7086] to xxx.xxx.xxx.xxx
Feb 19 09:17:31	charon	23877	10[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {3}
Feb 19 09:17:31	charon	23877	13[CFG] vici initiate CHILD_SA 'con1005'
Feb 19 09:17:31	charon	23877	07[CFG] vici terminate CHILD_SA 'con1004'
Feb 19 09:17:31	charon	23877	13[CFG] vici initiate CHILD_SA 'con1004'
Feb 19 09:17:31	charon	23877	13[CFG] vici terminate CHILD_SA 'con1005'
Feb 19 09:17:31	charon	23877	06[CFG] vici initiate CHILD_SA 'con1003'
Feb 19 09:17:31	charon	23877	12[CFG] vici terminate CHILD_SA 'con1003'
Feb 19 09:17:30	charon	23877	12[CFG] vici terminate CHILD_SA 'con1002'
Feb 19 09:17:30	charon	23877	12[CFG] vici initiate CHILD_SA 'con1002'
Feb 19 09:17:30	charon	23877	15[CFG] vici terminate CHILD_SA 'con1001'
Feb 19 09:17:30	charon	23877	08[CFG] vici initiate CHILD_SA 'con1001'
Feb 19 09:17:30	charon	23877	09[CFG] vici initiate CHILD_SA 'con1000'
Feb 19 09:17:30	charon	23877	07[CFG] vici terminate CHILD_SA 'con1000'
Feb 19 09:17:29	charon	23877	10[NET] <con100000|7085> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (92 bytes)
Feb 19 09:17:29	charon	23877	10[ENC] <con100000|7085> generating INFORMATIONAL_V1 request 1575427003 [ HASH N(AUTH_FAILED) ]
Feb 19 09:17:29	charon	23877	10[IKE] <con100000|7085> no RSA private key found for '172.16.30.1'
Feb 19 09:17:29	charon	23877	10[IKE] <con100000|7085> authentication of 'xxx.xxx.xxx.xxx' with RSA_EMSA_PKCS1_NULL successful
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> reached self-signed root ca with a path length of 0
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> certificate status is not available
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> crl fetching failed
Feb 19 09:17:29	charon	23877	10[LIB] <con100000|7085> libcurl request failed [56]: Recv failure: Connection reset by peer
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> fetching crl from 'http://fwmgmt.trondent.net:18264/ICA_CRL3.crl' ...
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> crl fetching failed
Feb 19 09:17:29	charon	23877	10[LIB] <con100000|7085> unable to fetch from O=fwmgmt..6smz2n, CN=ICA_CRL3, no capable fetcher found
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> fetching crl from 'O=fwmgmt..6smz2n, CN=ICA_CRL3' ...
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> checking certificate status of "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> using trusted ca certificate "O=fwmgmt..6smz2n"
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7085> using certificate "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:17:29	charon	23877	10[CFG] <7085> selected peer config "con100000"
Feb 19 09:17:29	charon	23877	10[CFG] <7085> looking for RSA signature peer configs matching 172.16.30.1...xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Feb 19 09:17:29	charon	23877	10[IKE] <7085> received end entity cert "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:17:29	charon	23877	10[ENC] <7085> parsed ID_PROT request 0 [ ID CERT SIG ]
Feb 19 09:17:29	charon	23877	10[NET] <7085> received packet: from xxx.xxx.xxx.xxx[500] to 172.16.30.1[500] (940 bytes)
Feb 19 09:17:29	charon	23877	10[NET] <7085> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (228 bytes)
Feb 19 09:17:29	charon	23877	10[ENC] <7085> generating ID_PROT response 0 [ KE No CERTREQ ]
Feb 19 09:17:29	charon	23877	10[IKE] <7085> sending cert request for "O=fwmgmt..6smz2n"
Feb 19 09:17:29	charon	23877	10[IKE] <7085> received cert request for 'O=fwmgmt..6smz2n'
Feb 19 09:17:29	charon	23877	10[ENC] <7085> parsed ID_PROT request 0 [ KE No CERTREQ ]
Feb 19 09:17:29	charon	23877	10[NET] <7085> received packet: from xxx.xxx.xxx.xxx[500] to 172.16.30.1[500] (216 bytes)
Feb 19 09:17:29	charon	23877	10[NET] <7085> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (144 bytes)
Feb 19 09:17:29	charon	23877	10[ENC] <7085> generating ID_PROT response 0 [ SA V V V ]
Feb 19 09:17:29	charon	23877	10[CFG] <7085> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Feb 19 09:17:29	charon	23877	10[IKE] <7085> xxx.xxx.xxx.xxx is initiating a Main Mode IKE_SA
Feb 19 09:17:29	charon	23877	10[ENC] <7085> received unknown vendor ID: f4:ed:19:e0:c1:14:eb:51:6f:aa:ac:0e:e3:7d:af:28:07:b4:38:1f:00:00:00:01:00:00:13:8d:60:2f:d6:89:00:00:00:00:18:29:00:00
Feb 19 09:17:29	charon	23877	10[IKE] <7085> received FRAGMENTATION vendor ID
Feb 19 09:17:29	charon	23877	10[ENC] <7085> parsed ID_PROT request 0 [ SA V V ]
Feb 19 09:17:29	charon	23877	10[NET] <7085> received packet: from xxx.xxx.xxx.xxx[500] to 172.16.30.1[500] (152 bytes)
Feb 19 09:17:29	charon	23877	10[MGR] <con100000|7084> tried to checkin and delete nonexistent IKE_SA
Feb 19 09:17:29	charon	23877	10[CFG] <con100000|7084> configuration uses unsupported authentication
Feb 19 09:17:29	charon	23877	10[IKE] <con100000|7084> no private key found for '172.16.30.1'
Feb 19 09:17:29	charon	23877	10[IKE] <con100000|7084> initiating Main Mode IKE_SA con100000[7084] to xxx.xxx.xxx.xxx
Feb 19 09:17:29	charon	23877	02[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {6}
Feb 19 09:17:10	charon	23877	08[MGR] <con100000|7083> tried to checkin and delete nonexistent IKE_SA
Feb 19 09:17:10	charon	23877	08[CFG] <con100000|7083> configuration uses unsupported authentication
Feb 19 09:17:10	charon	23877	08[IKE] <con100000|7083> no private key found for '172.16.30.1'
Feb 19 09:17:10	charon	23877	08[IKE] <con100000|7083> initiating Main Mode IKE_SA con100000[7083] to xxx.xxx.xxx.xxx
Feb 19 09:17:10	charon	23877	09[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {3}
Feb 19 09:16:56	charon	23877	12[MGR] <con100000|7082> tried to checkin and delete nonexistent IKE_SA
Feb 19 09:16:56	charon	23877	12[CFG] <con100000|7082> configuration uses unsupported authentication
Feb 19 09:16:56	charon	23877	12[IKE] <con100000|7082> no private key found for '172.16.30.1'
Feb 19 09:16:56	charon	23877	12[IKE] <con100000|7082> initiating Main Mode IKE_SA con100000[7082] to xxx.xxx.xxx.xxx
Feb 19 09:16:56	charon	23877	02[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {6}
Feb 19 09:16:47	charon	23877	13[MGR] <con100000|7081> tried to checkin and delete nonexistent IKE_SA
Feb 19 09:16:47	charon	23877	13[CFG] <con100000|7081> configuration uses unsupported authentication
Feb 19 09:16:47	charon	23877	13[IKE] <con100000|7081> no private key found for '172.16.30.1'
Feb 19 09:16:47	charon	23877	13[IKE] <con100000|7081> initiating Main Mode IKE_SA con100000[7081] to xxx.xxx.xxx.xxx
Feb 19 09:16:47	charon	23877	11[KNL] creating acquire job for policy 172.16.30.1/32|/0 === xxx.xxx.xxx.xxx/32|/0 with reqid {3}
Feb 19 09:16:42	charon	23877	15[NET] <con100000|7080> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (92 bytes)
Feb 19 09:16:42	charon	23877	15[ENC] <con100000|7080> generating INFORMATIONAL_V1 request 3757443218 [ HASH N(AUTH_FAILED) ]
Feb 19 09:16:42	charon	23877	15[IKE] <con100000|7080> no RSA private key found for '172.16.30.1'
Feb 19 09:16:42	charon	23877	15[IKE] <con100000|7080> authentication of 'xxx.xxx.xxx.xxx' with RSA_EMSA_PKCS1_NULL successful
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> reached self-signed root ca with a path length of 0
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> certificate status is not available
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> crl fetching failed
Feb 19 09:16:42	charon	23877	15[LIB] <con100000|7080> libcurl request failed [56]: Recv failure: Connection reset by peer
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> fetching crl from 'http://fwmgmt.trondent.net:18264/ICA_CRL3.crl' ...
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> crl fetching failed
Feb 19 09:16:42	charon	23877	15[LIB] <con100000|7080> unable to fetch from O=fwmgmt..6smz2n, CN=ICA_CRL3, no capable fetcher found
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> fetching crl from 'O=fwmgmt..6smz2n, CN=ICA_CRL3' ...
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> checking certificate status of "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> using trusted ca certificate "O=fwmgmt..6smz2n"
Feb 19 09:16:42	charon	23877	15[CFG] <con100000|7080> using certificate "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:16:42	charon	23877	15[CFG] <7080> selected peer config "con100000"
Feb 19 09:16:42	charon	23877	15[CFG] <7080> looking for RSA signature peer configs matching 172.16.30.1...xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Feb 19 09:16:42	charon	23877	15[IKE] <7080> received end entity cert "O=fwmgmt..6smz2n, CN=extfw-cluster VPN Certificate"
Feb 19 09:16:42	charon	23877	15[ENC] <7080> parsed ID_PROT request 0 [ ID CERT SIG ]
Feb 19 09:16:42	charon	23877	15[NET] <7080> received packet: from xxx.xxx.xxx.xxx[500] to 172.16.30.1[500] (940 bytes)
Feb 19 09:16:42	charon	23877	06[NET] <7080> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (228 bytes)
Feb 19 09:16:42	charon	23877	06[ENC] <7080> generating ID_PROT response 0 [ KE No CERTREQ ]
Feb 19 09:16:42	charon	23877	06[IKE] <7080> sending cert request for "O=fwmgmt..6smz2n"
Feb 19 09:16:42	charon	23877	06[IKE] <7080> received cert request for 'O=fwmgmt..6smz2n'
Feb 19 09:16:42	charon	23877	06[ENC] <7080> parsed ID_PROT request 0 [ KE No CERTREQ ]
Feb 19 09:16:42	charon	23877	06[NET] <7080> received packet: from xxx.xxx.xxx.xxx[500] to 172.16.30.1[500] (216 bytes)
Feb 19 09:16:42	charon	23877	06[NET] <7080> sending packet: from 172.16.30.1[500] to xxx.xxx.xxx.xxx[500] (144 bytes)
Feb 19 09:16:42	charon	23877	06[ENC] <7080> generating ID_PROT response 0 [ SA V V V ]
Feb 19 09:16:42	charon	23877	06[CFG] <7080> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Any thoughts or help would be greatly appreciated. Thanks.

jimp

It looks like it's having a problem locating the private key for your certificate.

What does swanctl --load-creds --file /var/etc/ipsec/swanctl.conf show?

dwood9100

@jimp said in 21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW:

swanctl --load-creds --file /var/etc/ipsec/swanctl.conf

loaded certificate from '/var/etc/ipsec/x509/cert-1.crt'
loaded certificate from '/var/etc/ipsec/x509ca/d88c081a.0'
loaded RSA key from '/var/etc/ipsec/private/cert-1.key'

jimp

Hmm, ok. What about the output of swanctl --list-certs | grep -i private?

You can look at the full output of swanctl --list-certs but most of its output will be the contents of the certificates themselves which may not be interesting here (and could be sensitive).

dwood9100

@jimp said in 21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW:

swanctl --list-certs

pubkey: RSA 2048 bits, has private key

jimp

Hmm, strange. My RSA key tunnels here work, but for mine I am using the full cert subject as the identifier (set to ASN.1 Distinguished Name).

It looks like it's not associating that particular cert with the ID despite it being listed properly there.

santi

@dwood9100 said in 21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW:

@jimp said in 21.02 and 2.5 upgrade breaks ipsec to Checkpoint FW:

swanctl --list-certs

pubkey: RSA 2048 bits, has private key

dwood9100

@jimp I opened a ticket with Checkpoint today. According to them, pfsense is trying to send a PSK which is odd because both sides have always been configured to use certificates which is the configuration that was previously working for the past few years. Any thoughts on this?

jimp

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?

dwood9100

@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.

jimp

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.

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?