VPN certificates

[Nik_Bloemers]

Hello CheckMates,

Does anyone know how to control which certificate gets sent in a certificate-based site-to-site VPN?
There's a nice repository of certificates available on the gateway, but it always seems to send the ICA signed certificate. We only want to use the ICA certificate for CP<->CP VPN's that are managed by the same management. We also have some third-party DAIP gateways we want to use another PKI infrastructure for (that already has CRL publicly available, unlike the CP ICA).

Any ideas how to accomplish this? Browsing the documentation and SK's for half a day didn't seem to reveal a solution.

Kind regards,

Nik

[mihaime]

The Aviatrix generated cert does not publish a CRL field and when I imported the Trusted CA I disabled the LDAP and HTTPs checkboxes for validating CRL.

I grepped the whole log dir for "OSCP: could not connect" and no entry popped up.

Good point though !! I did not know this. Thank you!

As a matter of fact this is my 2nd day touching a Checkpoint in high speed learning mode. 

I do have a linux/unix background.

[mihaime]

After a lot of back and forth and pulling my brains out I reached a conclusion 🙂 

There is an issue with Cloudguard and ECDSA based CA.

I created my own CA, cert, all with RSA, imported it as OPSEC Trusted CA, disabled CRL -> all worked, I got IPSEC up.

I created my own CA, cert, all with ECDSA (prime256v1), imported it as OPSEC Trusted CA, disabled CRL -> vpnd process keeps restarting.

Initially I had a trust chain on Aviatrix (Root CA, Intermediate). When I built my custom ones I did it directly Root CA -> client cert, no more Intermediate to also eliminate this from the variables.

In the log dir ($FWDIR/log) 4 files see changes constantly:

-rw-rw---- 1 admin root   118557 May 17 13:56 fwd.elg
-rw-rw---- 1 admin root  1563209 May 17 13:56 vpnd.elg
-rw-r--r-- 1 admin root    58000 May 17 13:56 core_uploader.elg --> has just one bash.11759.core (I see Checkpoint runs separate bash shells to start its own processes)
-rw-rw---- 1 admin root  7034033 May 17 13:56 sxl_statd.elg

vpnd.elg logs:

 Unable to open '/dev/fw6v0': No such file or directory
 fw_get_kernel_instance_num: Invalid instance num 0 - return 0

 Unable to open '/dev/fw6v0': No such file or directory

fwd.elg

[17 May 14:16:37] fwd: restarting vpnd
restarting in 4 seconds
[17 May 14:16:46] fwd: restarting vpnd
restarting in 4 seconds
[17 May 14:16:57] fwd: restarting vpnd
restarting in 4 seconds
[17 May 14:17:06] fwd: restarting vpnd
restarting in 4 seconds

On the positive side it does not coredump, it does seem not to like something while it probably loads the Trusted Imported ECDSA CA though and keep restarting in a loop. 

Restarting the GW stopped the loop with the processing being reloaded.

tp_events.elg

05/17/23 14:14:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:15:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:16:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:17:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:18:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:19:03;****CI:0, IPS:0, MALWARE:0, TP:0****
05/17/23 14:20:03;****CI:0, IPS:0, MALWARE:0, TP:0****

(these log entries grow at a rapid rate)

P.S. I used the same fields in both RSA and ECDSA Trusted CA + certificate case to be sure that I narrow down the behaviour:

# with custom fields
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
commonName = Common Name (e.g. server FQDN or YOUR name)

# Optionally, specify some defaults.
countryName_default = CH
stateOrProvinceName_default = Bern
localityName_default = Bern
organizationName_default = Fooling around
commonName_default = mihaigw.com
organizationalUnitName_default = research
emailAddress_default = mihai@mihaigw.com

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = mihai.mihaigw.com
DNS.2 = 10.1.0.36

Checkpoint sees the imported Trusted CA as:

Subject: Email=info@aviamix.com,CN=aviamix.com,OU=IT,O=Aviamix,L=Bern,ST=Bern,C=CH
Issuer: Email=info@aviamix.com,CN=aviamix.com,OU=IT,O=Aviamix,L=Bern,ST=Bern,C=CH
Not Valid Before: Wed May 17 16:33:08 2023 Local Time
Not Valid After:  Fri Jan  1 16:33:08 2038 Local Time
Serial No.:  0085d75319cc2ea55b
Public Key: ECDSA (256 bits)
Signature: ECDSA with SHA256
Basic Constraint:
	is CA
MD5 Fingerprint:
   BD:5C:77:56:73:4A:A1:1E:3D:3E:CA:1B:8A:75:C5:11
SHA-1 Fingerprints:
1. D4:F8:BA:4E:8F:1F:05:69:39:CC:55:B9:20:DA:B3:5F:06:C9:63:7A
2. RUSS NOSE HANS IQ TRUE LUST SAC CALL CUTS TOO LAUD LIND

On the Aviatrix/Strongswan side I can see:

198[CFG] added vici connection: gw-10_1_0_36-137_117_143_50
198[CFG] initiating 'net-0_0_0_0_0-0_0_0_0_0'
198[IKE] initiating IKE_SA gw-10_1_0_36-137_117_143_50[25] to 10.10.10.4
198[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
198[NET] sending packet: from 10.1.0.36[500] to 10.10.10.4[500] (330 bytes)
211[IKE] retransmit 1 of request with message ID 0
211[NET] sending packet: from 10.1.0.36[500] to 10.10.10.4[500] (330 bytes)
216[IKE] retransmit 2 of request with message ID 0
216[NET] sending packet: from 10.1.0.36[500] to 10.10.10.4[500] (330 bytes)
221[IKE] retransmit 3 of request with message ID 0
221[NET] sending packet: from 10.1.0.36[500] to 10.10.10.4[500] (330 bytes)

226[IKE] giving up after 3 retransmits
226[IKE] establishing IKE_SA failed, peer not responding

so the Cloudguard does not send anything back.

At some point (before all tests) I thought it was an MTU problem and I decreased (I know, better to activate MSS clamping) the MTU on the physical interface to 1400 (both sides).
I did not look in Wireshark to see the packet length, was a bit lazy with having to disable RX/TX offloading in order to see the real packet size and not huge values.

Activating vpn debug trunc ALL=5 shows:

[vpnd 4335 4071397376]@checkpointgw2[17 May 15:00:34][io] [NEGOTIATIONS]: Adding negotiation to peer: <my remote ip>. Current negotiations=2

[vpnd 4335 4071397376]@checkpointgw2[17 May 15:00:34] findSAByPeer: Find SA with cookies 9ed9034f6bdbf05c,0000000000000000 from packet
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:00:34] findSAByPeer: Valid ISAKMP SA was not found.  me=0, peer=1404818e
..
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:07:22] find_sa_by_ike_peer: Find IKE SA for IKE peer <<my remote ip>,0000000000000000>
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:07:22] find_sa_by_ike_peer: No IKE SA for this IKE peer found
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:07:22][ikev2] vpn1IKEConfiguration::hasExchangeFailed: Identified peer <my remote ip> in failed exchanges list
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:07:22][ikev2] getIkeVersion: ikev2 exchange has failed. try ikev1 (peer: <my remote ip>), failoverFromIKEv2: -1
[vpnd 4335 4071397376]@checkpointgw2[17 May 15:07:22][tunnel] RequestByMethods_ikev1: enter

IKEview shows "waiting for arriving message", final status: failure, on Proposal 1. 
I do know it's not Aviatrix not sending them...as when I switch to the RSA CA, then it all works.

Now here I got stuck and I have a feeling this is more for support / TAC :).

[nedomskiy]

We've got the same issue on R80.20. Only ICA certificate is sent toward interoperable device.
Is there a solution to fix this behavior?

Regards,
Ivan

[nedomskiy]

We've got the same problem.
Is there a solution to fix this behavior?

Regards,
Ivan

[PhoneBoy]

As suggested elsewhere in this thread, best to open a TAC case.

[spottex]

Hi All,

Did anyone get a resolution for this?

It would be good to know as our issue is even more retarded.

We have the ICA plus 3 PKI certs from different root CA's. 
We updated the cert at the bottom of the list that was expiring

 In the previous packet within a debug we see the third party requesting a cert from the correct root CA.

Passing the ICA and the first PKI cert the Check Point sends the cert from a different CA (from the request), that is directly above the new cert. 

Just interested while I call TAC.

[Tobias_Moritz]

Unfortunately, none of the previous posters here updated this thread with their (TAC) findings.

So it would be really nice, if you would do this after you got this figured out with TAC so that we all can learn from it (and TAC gets fewer support cases for the same question). 🙂

Thank you in advance!

[_Val_]

Second that. Community is for sharing, especially when it comes to resolving your own issues.

[nedomskiy]

In our case TAC hadn't been able to provide a solution during the months of dialog and we moved IPSec configuration to another vendor's equipment. 
It took long time to explain the problem with 3rd party device certificate-based IPSec authentication (corporate CA) and we got no relative answer. 

[spottex]

Will do.
Case is logged but hasn't passed the "uploaded the requested more info"  stage so far.

[spottex]

After a bit of testing these are the results that helped me understand what was happening a lot better.

Our issue Ikev1 was used.

Ikev1 has 6 packets for the phase1.
packet 3 and packet 4 are certificate requests.
5 and 6 are the certificates responses.

Packet 3 initiator request -> packet 6 peer response
Packet 4 peer request -> packet 5 initiator response

Packet 5 and 6 should have the cert and all subordinate certs listed.
If all subordinates are not installed or are not in the correct section (Trusted CA and Subordinate CA) one gateway most likely will fail the auth

Specifying which cert you want the other gateway to send
When you set matching criteria in an interop device you choose the Root CA for the certificate that you wish the other end to send
Whoever initiates the VPN will use packet 3 for cert request and this will contain the Root CA from the Matching criteria
The responding peer gateway will reply with packet 4 cert request containing the root CA specified in their matching criteria.
If it is a 3rd party device, then they will need to have a way to change their certificate request. Setting an IKE-ID is not enough as that is just a check when the cert arrives at the gateway. (only having one cert installed will work. Until you add a second then CP may use that and the VPN will fail)

Packet 5 will be the initiators certificate sent to the peer that if correct will be from the chain of the root CA in cert request packet 4

If the Peer gateway accepts the cert it will respond with Packet 6 with the certificate from the chain of the root CA in request packet 3.

If there is no Matching Criteria set.
Any Interop device not configured with a Matching Criteria i.e. ANY, That gateway will send a list of all Root CA's installed in Trusted CA's in its cert request.
The peer will choose one of its certificates that match one of the chains containing one of those root certs.
If more than one.. I cannot work out how it chooses without a lot more tests. It would be necessary for the peer to trust all the certs that potentially will be sent.

No Trusted CA to match the certificate received.
If a gateway cannot match one of the Root CA’s on the cert recvied, it will send one of its installed certs. If it only has the internal cert it will send that.
I cannot work out how it chooses without a lot more tests.

If the peer responds to a cert request but has a subordinate installed in the Trusted CA section.
The initiator will fail the auth with an error found in normal logs:
Main Mode Expected to get certificate whose root CA is Example_rootCA, got certificate whose root CA is Example_sub_CA_installed_in_trusted_CA

If initiator installs a subordinate in the Trusted section of Check Point
The peer will fail the auth and not send packet 6
Unless it also has the subordinate in the trusted section. This can cause issue down the track when other certificates are used so recommended not to save headaches later.

If the peer sends the wrong CA in its cert request
The peer may have an insufficient way to specify a cert request and it uses a default CA it has install etc.
Your gateway would just choose one of the certs installed, if none installed it will send the ICA cert.