3.2 Interoperating with Third-Party Gateways (Pre-Shared Keys & Digital Certificates)

3.2 Interoperating with Third-Party Gateways (Pre-Shared Keys & Digital Certificates)

In modern enterprise networks, Security Gateways must frequently form Site-to-Site IPsec VPN tunnels with third-party vendors (such as Cisco ASA/Firepower, Palo Alto Networks, Fortinet FortiGate, or AWS Virtual Private Gateways). Because non-Check Point devices cannot be managed natively by SmartConsole or receive policy installations directly from the Security Management Server (SMS), Check Point R82 utilizes specialized Interoperable Device objects and standard IPsec interop frameworks to establish secure communications.

Achieving seamless interoperability requires a meticulous understanding of object creation, authentication mechanisms (Pre-Shared Keys vs. PKI Digital Certificates), Certificate Revocation List (CRL) and OCSP validation routines, IKE peer identity matching, and strict cryptographic proposal alignment.

---

1. Interoperable Device Objects & SmartConsole Workflow

To include a non-Check Point gateway in a Site-to-Site VPN community, an administrator must create an Interoperable Device object in SmartConsole.

SmartConsole Configuration Steps

1. Navigate to Objects -> New -> Network Object -> More -> Interoperable Device.
2. General Properties: Assign a descriptive name (e.g., AWS-VGW-East) and enter the external static IPv4/IPv6 address of the third-party gateway.
3. Topology Configuration: Unlike Check Point gateway objects where topology is automatically fetched, Interoperable Device topology must be defined manually:
   • Define the external interface facing the internet.
   • Define the VPN Domain (Encryption Domain). Select User-defined and assign a Network object or Network Group object that contains all internal subnets residing behind the third-party device.
4. Add to VPN Community: Open the target Star or Meshed VPN Community object, navigate to Participating Gateways, and add the Interoperable Device.

SmartConsole Object Path:
Objects -> New -> Network Object -> More -> Interoperable Device
  ├── General Properties (Name, IPv4/IPv6 Address)
  ├── Topology -> Manual Definition (Interface IP, Netmask)
  └── VPN Domain -> User-defined (Assign Subnet/Group Object)

---

2. Authentication Methods: Pre-Shared Keys vs. Digital Certificates

Mutual authentication between the Check Point gateway and the third-party device during IKE Phase 1 can be accomplished using Pre-Shared Keys (PSK) or PKI Digital Certificates (X.509).

Pre-Shared Key (PSK) Authentication

Pre-Shared Keys are shared secret strings configured identically on both peer gateways.

• Community Default PSK: In SmartConsole, opening VPN Community Properties -> Shared Secret allows defining a single PSK applied to all interop devices in the community.
• Peer-Specific PSK Overrides: When different third-party peers require distinct secrets, check Use shared secret names for peer gateways under Community Properties and define a unique string for each specific pair of gateways.
• Security Warnings: PSKs must be high-entropy strings (at least 20+ alphanumeric characters). Avoid special non-ASCII characters or space delimiters, as different operating systems process character encodings differently, resulting in IKE Phase 1 authentication failures.

Digital Certificates (PKI & X.509)

For enterprise interop, digital certificates eliminate the security risks of static PSKs and scale effortlessly across multi-vendor environments.

• Internal Certificate Authority (ICA): Every Check Point Management Server features an embedded ICA that automatically issues certificates to managed Check Point gateways. For third-party gateways, the ICA can issue certificates via SCEP (Simple Certificate Enrollment Protocol) or manual PKCS#10 requests.
• External CA Integration: When using an external PKI (e.g., Microsoft CA, EJBCA, Digicert):
  1. Export the CA's Root and Intermediate certificates in .crt or .pem format.
  2. In SmartConsole, create a Trusted CA object under Objects -> Network Objects -> More -> Certificate Authority.
  3. Upload the Root CA certificate to establish the trust chain.
  4. Generate a Certificate Signing Request (CSR) on the local Check Point gateway, submit it to the external CA, and import the signed certificate back into the gateway's object properties under VPN -> Certificates.

---

3. Certificate Revocation & Verification: CRL vs. OCSP

During IKE Phase 1 authentication via digital certificates, the receiving gateway must verify that the remote peer's certificate has not been revoked prior to its expiration date.

Certificate Revocation Lists (CRL)

A CRL is a signed, time-stamped list published periodically by a Certificate Authority containing serial numbers of revoked certificates.

• Retrieval Protocols: Check Point gateways retrieve CRLs using HTTP or LDAP via URLs specified in the certificate's CRL Distribution Points (CDP) extension.
• Caching Mechanism: To minimize latency, the gateway caches retrieved CRLs in local memory. The cache duration is governed by the Next Update field published inside the CRL.
• Fallback Configuration: In the Trusted CA object properties in SmartConsole, administrators can configure CRL retrieval timeout actions—specifying whether to reject the connection (strict enforcement) or allow the tunnel if the CRL distribution point is temporarily unreachable.

Online Certificate Status Protocol (OCSP)

OCSP (RFC 6960) provides real-time certificate validation by querying an online OCSP responder service directly.

• Mechanics: The gateway sends a lightweight request containing the certificate serial number. The OCSP responder returns a signed response indicating status: Good, Revoked, or Unknown.
• Advantage over CRL: Avoids downloading large CRL files over WAN links, eliminating stale revocation windows between CRL publishing cycles.

---

4. Technical Proposal Matching & IKE Responder Configuration

For an IPsec tunnel to negotiate successfully with a non-Check Point device, all cryptographic parameters across Phase 1 and Phase 2 must align exactly.

Proposal Alignment Checklist

1. IKE Version: Ensure both peers are explicitly configured for IKEv2 (recommended) or IKEv1.
2. Phase 1 Parameters:
   • Encryption Algorithm (e.g., AES-256)
   • Hash / Integrity Algorithm (e.g., SHA-256)
   • Diffie-Hellman Group (e.g., DH Group 14 or DH Group 19)
   • SA Lifetime (e.g., 86,400 seconds / 24 hours)
3. Phase 2 Parameters:
   • ESP Encryption (e.g., AES-256-GCM or AES-256-CBC)
   • ESP Integrity (e.g., HMAC-SHA256)
   • Phase 2 SA Lifetime (e.g., 3,600 seconds / 1 hour)
   • Perfect Forward Secrecy (PFS): If enabled on Check Point, PFS forces a new Diffie-Hellman key exchange during Phase 2. Both peers must agree on PFS status and DH group; otherwise, Phase 2 Quick Mode negotiation will fail with a Payload Mismatch error.

IKE Peer Identity Matching (IKE Responder Settings)

When a third-party gateway initiates an IKE connection, the Check Point gateway acts as the IKE Responder. It must match the incoming peer identity against an object in its database:

• IP Address: Default matching mode; compares the peer's public IP address against the Interoperable Device object IP.
• Domain Name (FQDN) / User FQDN: Required when the third-party peer resides behind a dynamic IP (DAIP) or NAT device.
• Distinguished Name (DN): Required when using Digital Certificates; matches the Subject DN string inside the remote peer's X.509 certificate.