Magitech.ca written by Wyatt Zacharias

Checkpoint Client VPN Certificate Enrollment Fails

Checkpoint’s Mobile Access VPN Blade is what Checkpoint calls their client VPN function where external users can tunnel their traffic into the corporate network and access the services within. A variety of authentication mechanisms can be configured for clients to use when they connect, including the use of their active directory credentials. Most organisations won’t consider a single user credential sufficient authentication for allowing connectivity into the internal networks from an external source. The mobile access blade supports a second factor of authentication, in this case a client certificate signed by a trusted certificate authority. By default the checkpoint management server has a certificate authority running on it, which can be used to issue certifcates to clients that will be trusted by the gateways. Instead of using CSR files or exporting certificates as PKCF files checkpoint VPN clients include a certificate enrollment function the uses a one time key to securely connect to the CA and request and issue the certificate onto the client in a single step. Additionally once a certificate is issued, it can be securely renewed through the same process without the need for a new one time key each time.

Issues with certificate enrollment arise when client machines are connected internally and traffic routes abnormally when communicating with the gateway that is running the mobile access blade, and the management server that performs the certificate authority functions. When a client starts the enrollment externally it will initiate communication with the external IP address that is configured for the VPN site, which will be the gateway running the mobile access blade on port 18264. The gateway then dNAT’s the traffic to the address of the management server which performs the enrollment and communicates back to the client, being routed through the gateway device. This is where internal issues arise. If the source address of the client performing the enrollment is directly accessible to the management server, or the return route bypasses the gateway, traffic will be out of state and not route back to the client correctly.

This is a fairly standard case of asymmetric routing, but is difficult to isolate since the steps of enrollment are not documented by Checkpoint, and thus the administrator is stuck looking through packet captures trying to understand the flow of traffic and where it is wrong. In our case the problem was resolved by creating a new Hide NAT rule with the original source being our workstation subnets, the original destination being the IP of the management server and the original destination port being 18264. The translated source should be set to the internal IP address of the gateway that faces the managment server and the NAT method should be Hide. This tricks the management server into sending traffic back to the gateway instead of back to the client directly. Because the source address is never changed, the return traffic will be properly routed by the gateway, back to the client.

See Also:

I couldn’t find any Checkpoint SK that exactly described this issue, but here are a couple that pointed me in the right direction (support entitlement required): SK109993 SK114266