TestingOps.ai

Private networks · Private network

Check Point Remote Access and TestingOps: test runs behind a Check Point gateway

A gateway machine runs the open-source snx-rs client against your Check Point Remote Access gateway, signs in with a password or a certificate, asks for the SMS or OTP code on the TestingOps card and keeps the session, so a dropped tunnel comes back without a new code.

  • Private network
  • Available
Request a demo
Connection
Private network
Writes back
Test traffic only
Last checked
7 Nov 2026

In short

Check Point Remote Access and TestingOps in short

TestingOps reaches environments behind Check Point Remote Access through a gateway machine that runs snx-rs, an open-source Check Point client, signed in as a VPN user you provide with a password, a client certificate or both.

When the Check Point gateway asks for an SMS or authenticator code, the prompt appears on the TestingOps card and the code typed there goes to the client; the signed-in session is saved, so a dropped tunnel reconnects without a new code until the Check Point gateway ends the session.

With Check Point, the VPN's own encryption-domain routes stay in place and the ranges you list are added, while host patterns become search domains resolved by the VPN's DNS.

Check Point sign-in through an identity provider or the Mobile Access portal is not possible on the gateway machine.

What it does

What it does for your testing

  1. 1

    SMS codes typed in TestingOps

    Input
    A Check Point login option with a password and an SMS code
    TestingOps
    Runs the client on a terminal, shows the code prompt on the TestingOps card and types the code you enter into the client
    Output
    A connected tunnel without anyone logged in to the gateway machine
  2. 2

    Fewer codes after a drop

    Input
    A tunnel that drops during the day
    TestingOps
    Reconnects with the saved IKE session instead of signing in again
    Output
    Runs keep reaching the network without a new SMS until the Check Point gateway ends the session
  3. 3

    The encryption domain kept

    Input
    A Check Point gateway that publishes its own encryption domain, plus ranges you list
    TestingOps
    Keeps the encryption-domain routes, adds the listed ranges and keeps the default route out of the tunnel
    Output
    Addresses a run sends to the gateway machine use the routes your Check Point setup already defines

Step by step

How it works

  1. Describe the Check Point gatewayUnder Integrations → Private networks (VPN), choose Check Point Remote Access and enter the Gateway address, the Username and, if needed, a Login option. Left empty, the login option is picked from the gateway's list to match your sign-in method.
  2. Choose tunnel and certificate checkTunnel type IPsec (default) or SSL (TCP 443 only). Keep Server certificate on Verify (recommended) unless the Check Point gateway is reached by IP address or uses a self-signed certificate.
  3. Sign-in, routes and projectsChoose Username + password, Client certificate or Certificate + password, set Additional verification for SMS or authenticator codes, list internal ranges or host patterns and pick the projects.
  4. Set up the gateway machine and connectRunningOps can start the gateway machine for the connection, or you install it on a server of yours that the runners can reach; then select Connect.
  5. Type the code when askedThe card shows The VPN asks for a verification code; type the code there. Later drops reconnect with the saved session.

Login options that sign in on a web page (identity provider or Mobile Access) are never picked, because a gateway machine without a screen cannot complete them.

Connect

Setup

  1. Ask your network team for a Remote Access user for testing and the Check Point gateway's host name, and whether it sends SMS or authenticator codes.
  2. In TestingOps, open Integrations → Private networks (VPN) → Check Point Remote Access. Enter Gateway address, Login option (optional), Username, Tunnel type and Server certificate, then choose the sign-in method and Additional verification.
  3. Add the internal ranges or host patterns the test site uses under Networks and hosts to route through the VPN, then select the projects.
  4. Select Set up gateway and pick Let RunningOps set it up (recommended); Install on my own server is the alternative for an Ubuntu or Debian server the test runners can reach (on arm64, one with glibc 2.38 or newer).
  5. Select Connect and type the code when the card shows The VPN asks for a verification code.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → Check Point Remote Access

Use cases

Use cases

SMS-protected VPN for scheduled runs

Trigger
The VPN sends an SMS code at every sign-in
Uses
Code relay and the saved session
Agent activity
A team member types the code once on the card; drops later in the day reconnect without a new code
Result
Scheduled runs keep their tunnel without an SMS for every drop
Condition
When the Check Point gateway ends the session, someone types a new code

Only TCP 443 is open towards the VPN

Trigger
IPsec traffic to the Check Point gateway is blocked on the way
Uses
Tunnel type: SSL (TCP 443 only)
Agent activity
The client builds the tunnel over TCP 443
Result
A working tunnel where an IPsec tunnel would not come up

Certificate login with a passphrase

Trigger
The VPN issues user certificates protected by a passphrase
Uses
Client certificate (PEM) with Certificate key passphrase
Agent activity
The gateway machine repacks the certificate for the client without writing your passphrase into the client's configuration
Result
Certificate sign-in, with a password as well when the login option needs both

Capabilities

Capabilities and limits

What is read

Addresses a run sends to the gateway machine that fall in the VPN's encryption domain or in the ranges you list; names under your host patterns resolve through the VPN's DNS.

What is produced

A tunnel and a proxy for web test runs, and code prompts on the TestingOps card when the Check Point gateway asks for one.

Where it can write

Test traffic only. On the gateway machine the password sits in a client configuration file that only root can read, never on a command line; TestingOps keeps secrets encrypted and never returns them.

How it connects

snx-rs, an open-source Check Point client in a pinned, checksum-verified release, on the gateway machine, with an IPsec or SSL tunnel; test browsers reach the gateway machine through a proxy

Account and permissions

  • A Check Point Remote Access user for the gateway machine, ideally test-only
  • Username + password, Client certificate (PEM, with an optional key passphrase) or Certificate + password
  • SMS or authenticator codes typed on the TestingOps card when the Check Point gateway asks

Limits

  • No SSO: identity provider and Mobile Access sign-in pages cannot be completed by the gateway machine
  • Verify fails when the Check Point gateway is addressed by IP; use its host name or Do not verify
  • On an arm64 server of your own, the client needs glibc 2.38 or newer, for example Ubuntu 24.04
  • Up to 50 route entries: IPv4 ranges or host patterns; no IPv6
  • Only web runs use the tunnel; real phones and iOS devices do not

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's partner portal sits behind a Check Point gateway that sends an SMS code at every sign-in. The team adds the gateway with Username + password and SMS code, lists the 172.20.0.0/16 range and lets RunningOps set up the gateway machine.

In the morning a tester types the SMS code on the TestingOps card. When the tunnel drops at lunchtime, the gateway machine reconnects with the saved session, and the afternoon runs continue without another code.

Frequently asked questions

Do we have to type an SMS code for every run?

No. A code is needed when the gateway machine signs in. The session is saved, so a dropped tunnel reconnects without a new code until the Check Point gateway ends it. A refused or unanswered code waits for Retry instead of sending SMS after SMS.

Can we sign in through our identity provider?

No. Login options that sign in on a web page, through an identity provider or the Mobile Access portal, cannot be completed on a gateway machine without a screen. Use a password, a certificate or both.

Which client runs on the gateway machine?

snx-rs, an open-source Check Point Remote Access client. The installer pins its release and checks its checksum before installing it.

IPsec or SSL?

IPsec is the default. Choose SSL (TCP 443 only) when only TCP 443 is open towards the Check Point gateway.

Why does certificate verification fail?

A server certificate is issued for a name. If you enter the Check Point gateway by IP address, verification cannot match; enter its host name, or choose Do not verify.

Which addresses go into the tunnel?

The VPN's own encryption domain stays routed and your listed ranges are added; the default route stays outside the tunnel. Test browsers send the listed entries, the run's environment and case addresses and names they cannot resolve to the gateway machine; everything else goes directly.

Next step

Ask in a demo how runs would reach an environment behind your Check Point gateway, codes included.

Request a demoMore private networks integrations