Configure Remote Access VPN on a Check Point Gateway

Before you run this

This guide turns on Check Point Remote Access VPN so staff can connect from outside with the Check Point Endpoint Security VPN / Check Point Mobile client and reach internal networks over an encrypted IPsec tunnel. You do it in SmartConsole, not on the gateway shell — enabling the IPsec VPN blade, putting the gateway in the RemoteAccess community, assigning client IPs with Office Mode, adding an access rule, and installing policy.

Privileges: you need a SmartConsole administrator account with read/write access to the policy and gateway objects. Installing policy pushes the whole rule base — treat it as a production change.

This changes production. Enabling a blade and adding an access rule is a policy install; a wrong rule, a bad Office Mode subnet that overlaps an existing network, or a NAT mistake can break existing traffic or lock you out of management. So:

• Keep an out-of-band path open — an SSH/console session to the Gaia gateway, or physical console access — before you install anything.
• Back up first. Publish the current session in SmartConsole (this creates a revision you can revert to), and take a Gaia snapshot of the gateway (Gaia Portal → Maintenance → Snapshot Management, or add snapshot <name> in clish). Also export the management database per Check Point's backup procedure.
• Do it in a maintenance window.
• Rollback path: in SmartConsole you can install a previous policy revision (Security Policies → Installation History → Install a specific version), and worst case revert the Gaia snapshot. Know which one you'll use before you start.

Read the whole thing first, and if you have a lab management server or a spare gateway, build it there once before touching production. I'm writing for R81.20 (SmartConsole and gateway both R81.20), a single standalone gateway (not a cluster — cluster VIP and sync add steps I don't cover here), authenticating against local Check Point users first, with a note on AD/LDAP. Menu names move between versions; if a path below doesn't match yours, check the Remote Access VPN Administration Guide for your exact release rather than guessing.

1. Enable the IPsec VPN blade on the gateway

In SmartConsole:

1. Gateways & Servers, double-click your gateway object (call it GW-01).
2. On General Properties, in the Network Security blade list, tick IPsec VPN.
3. Click OK.

Turning on the blade doesn't move traffic yet — the community and rules do that.

2. Create the Office Mode IP pool

Office Mode hands each connected client an internal IP. Pick a subnet that does not overlap any existing internal network or another VPN pool.

1. In the object bar, create a new Network object, e.g. RA-OfficeMode-Pool, network 10.20.30.0, mask 255.255.255.0. Substitute a range that's free in your environment.
2. Reopen GW-01 → VPN Clients → Office Mode.
3. Choose Allow Office Mode to all users (or restrict to a group), and set the allocation method to manual using an IP pool, selecting RA-OfficeMode-Pool.
4. Set DNS/WINS for clients here if you need name resolution across the tunnel (point DNS at your internal resolver).

The exact wording of the pool/DHCP options is on the Office Mode page; use whichever your version shows and leave the rest at defaults.

3. Create the users (or connect AD)

For a first stand-up, local users are simplest:

1. In the object bar → Users (New → User), create a test user, e.g. vpntest.
2. Give it a Check Point Password as its authentication method and set the password.
3. Create a User Group, e.g. RA-Users, and add vpntest to it.

For production against Active Directory, don't use local users — configure an LDAP Account Unit pointing at your domain (example.com) and use Access Role objects instead. That setup is its own procedure; follow the LDAP/Identity Awareness section of the admin guide for the exact wizard.

4. Set the gateway's authentication method

1. Open GW-01 → VPN Clients → Authentication.
2. Confirm the allowed authentication method matches how your users log in (username/password for the local vpntest case).

I'm deliberately not naming a specific radio-button value here because the labels differ across R81.x builds and I won't risk a wrong one — the Authentication page is where it lives; match it to your users.

5. Add the gateway and users to the RemoteAccess community

R81.20 ships a default RemoteAccess VPN community.

1. Security Policies → open VPN Communities (or via the Object Explorer), double-click RemoteAccess.
2. Under Participating Gateways, add GW-01.
3. Under Participating User Groups, add RA-Users.
4. Click OK.

6. Add an access rule for remote users

Add a rule to your Access Control policy that permits the community into your internal networks:

• Source: RA-Users (or an Access Role if you went the LDAP route)
• Destination: your internal network object(s)
• VPN: set this column to the RemoteAccess community (this is what scopes the rule to tunnel traffic)
• Services & Applications: the services staff actually need — don't open Any if you can avoid it
• Action: Accept
• Track: Log

Place it where it will be matched (above any broad cleanup/drop). Keep it tight — this rule is what remote clients can reach.

7. Install policy

Security Policies → Install Policy, select GW-01, install. Watch the progress and the logs. This is the reversible-via-revision step from the safety note.

8. Set up the client

On a test laptop outside the network:

1. Install Check Point Endpoint Security VPN (or Check Point Mobile) — download the matching version from Check Point's support site.
2. Create a new site, entering the gateway's public IP or FQDN (e.g. vpn.example.com, which must resolve and be reachable on the VPN ports).
3. Choose Username and password authentication, finish the wizard, and Connect as vpntest.
4. On first connect you'll be asked to trust the gateway's certificate fingerprint — verify it matches the gateway before accepting.

Verify it worked

On the client: it shows Connected, and ipconfig (Windows) or ifconfig/ip addr (macOS/Linux) shows an address from your 10.20.30.0/24 Office Mode pool. Ping or open an internal service that your access rule allows.

In SmartConsole: Logs & Monitor → Logs, filter on blade VPN — you should see the IKE negotiation and the Office Mode IP assignment for vpntest, plus Accept logs for the traffic hitting your rule.

On the gateway (Gaia CLI, expert mode) — read-only checks:

vpn tu        # interactive tunnel utility: list/monitor remote-access tunnels
cpstat vpn    # VPN blade statistics, including active tunnels

vpn tu opens a menu; use the option to list Remote Access / IKE tunnels to confirm the user's session is up. Gateways & Servers monitoring in SmartConsole also shows connected remote users.

Undo / roll back

Cleanly, in reverse order:

1. In SmartConsole, disable the access rule (or delete it), remove GW-01 and RA-Users from the RemoteAccess community, and untick IPsec VPN on the gateway if you're fully backing out.
2. Install Policy again to apply the removal.

If a policy install caused trouble, the fastest recovery is Installation History → install the previous version. If the gateway itself is misbehaving after the change, revert the Gaia snapshot you took in step 0 — that returns the box to its pre-change state but drops anything else changed since, so use it as the last resort, not the first.