Quick Primer on How to Configure your Gateway for SecuRemote

[PhoneBoy]

We've written a fair bit about Mobile Access Blade and Endpoint VPN over the last several days. However, there's another solution that every Check Point customer has access to, provided you have a VPN gateway license, which almost every customer does. It's called SecuRemote, and it's a free IPsec VPN client you can use on Windows.

In general, Mobile Access Blade and/or Endpoint VPN (sold with Harmony Endpoint) are better suited for enterprise use cases than SecuRemote and are what we generally recommend to customers. However, there are some use cases where SecuRemote can still work, thus this quick primer.

SecuRemote has a few important limitations:

• It's Windows only (L2TP clients can be used on other platforms, but their configuration is out of the scope of this document)
• No Desktop Firewall or Compliance Checks such that you can get with Check Point Mobile or Endpoint VPN
• No Office Mode (gateway will see traffic coming from an external IP even after decryption)
• No user-level Identity Awareness for SecuRemote clients

Office Mode assigns your remote client an IP address, DNS and WINS information as if the client were on the local network. Without Office Mode, the client only has its IP address on the local network it is connected to. If the client is sitting behind a NAT device, this is the client's non-routable IP address. This creates a number of problems, including IP address conflicts, client IPs overlapping with the encryption domain, and others.

The lack of Office Mode can be at least partially worked around using a feature called IP Pool NAT. This will allow inbound connectivity where the client presents a predictable IP to your internal network, but will not allow reverse connections to the client. Applications that tend to break when subject to Address Translation will also break when used with IP Pool NAT as well.

For DNS, it is possible to forward queries for specific domains inside the encryption domain and everything else will go to the Internet as normal. 

Again, for the vast majority of customers, we recommend using Mobile Access Blade or SandBlast Agent/Endpoint VPN licenses. Both of these licenses include support Office Mode. However, if your specific use case will work within these limitations, SecuRemote is an option. 

A Word About Versions

I am going to show screenshots and steps from R80.40. It shouldn't be that different in any modern version of Check Point. It's certainly not that different than it was back in 2000 when I wrote Essential Check Point FireWall-1.

The High Level Steps

• Configure the gateway object for SecuRemote.
• Configure the Global Properties.
• Configure the IP Pool NAT Pool.
• Create SecuRemote users.
• Define Remote Access community rules.
• Create a SecuRemote DNS Object.
• Install the security policy.
• Install SecuRemote on a Windows client.
• Add the site to SecuRemote and connect.

Configuring the Gateway Object for SecuRemote

Several areas of the configuration relate to SecuRemote and other clients. I am going to touch on only what is necessary for basic SecuRemote functionality. Similar to site-to-site encryption, you must configure the firewall object with the appropriate encryption types and encryption domain.

Go to Gateways and Servers in SmartConsole and double-click on the relevant object. In the General Properties, ensure that IPSec VPN is enabled.

Click Ok to save this change.

Next, we'll make sure the gateway is added to the RemoteAccess VPN Community. Go to the Objects Pane in SmartConsole and navigate to VPN Communities > Remote Access. Add your gateway object to the VPN Domain.

Now go back and open the gateway object again. Navigate to Network Management > VPN Domain and set the settings accordingly. 

Generally speaking "All IP Address behind Gateway based on Topology information" is the appropriate setting, provided you have defined the topology with all the relevant IP addresses. You can also set a specific set of networks for Remote Access that is different. 

In IPSEC VPN > VPN Advanced, make sure that NAT Traversal is enabled:

In VPN Clients, ensure SecuRemote is enabled:

And finally in VPN Clients > Advanced, ensure that Visitor Mode is enabled:

Now you can click Ok and save the Gateway object. 

Global Properties

Access the Global Properties in SmartConsole by pulling down the relevant option from the menu:

From Global Properties, we're going to do a couple of things:

• Enable IP Pool NAT (which makes SecuRemote usable in more scenarios)
• Enable Encrypt DNS Settings
• Review the Encryption settings

To enable IP Pool NAT, go to the NAT section of Global Properties, enable the checkbox, and set the logging as desired.

Note, I've also checked the box to Merge Manual Proxy ARP Configuration, which I needed in my specific configuration and, depending on the IPs you use for IP Pool NAT, you might need as well.

Next, we want to make sure we will encrypt particular DNS queries and have them set inside the encryption domain. This is done in the Remote Access section of Global Properties. We will configure which queries are forwarded internally later on.

To change the encryption settings, go to Remote Access > VPN - Authentication and Encryption and click on the Edit button under Encryption Algorithms. Set the settings to your desired settings. 

Click ok, then ok to exit Global Properties.

Configure the IP Pool NAT Pool

You will need to pick a subnet or range of IPs to use as a pool for NAT. Ideally, this is a subnet not used in your internal network and one that would be routed to your gateway as a result of being the default route in your network. You can also use an Address Range for this. Create the relevant type of object in the Object Explorer.

In my case, I used an Address Range:

In my case, I specifically used IPs on the same subnet as my gateway. Should you do this, you will need to configure Proxy ARP entries in the Gaia OS (these are not done automatically) and you will need to have the Merge Manual Proxy ARP setting set that I showed earlier.

Now you need to go back to your Gateway object and configure it to use this object. Also check the Use IP Pool NAT for VPN Connections:

Create SecuRemote Users

To keep this document relatively simple, I'm just going to create manual users with a fixed password. You can configure users authenticating with Certificates, LDAP, RADIUS, and other mechanisms by following the steps in the User and Client Authentication for Remote Access section of the R80.40 Remote Access VPN Guide.

In the Objects Pane, click New > More > User > User. Choose the Default template unless you've defined one you wish to use. Give the user a name and set the authentication type. In this example, I chose to use Check Point Password (an internal fixed password). 

Repeat the above for each user you wish to define. 

Define Remote Access Community Rules

You will need rules that look similar to the following

The first rule allows those in the RemoteAccess community to access your internal network. The second rule allows you Security Gateway to be reachable via HTTPS, which will be required to allow your users to add your site to the SecuRemote client.  

Create a SecuRemote DNS Object

With Office Mode, we can assign the client an IP address and establish DNS and WINS settings. With SecuRemote, we do not have access to this feature. Instead, you can forward requests for certain domains to go to specific DNS servers inside the encryption domain. This would allow you to use your ISP's DNS servers for Internet-based lookups but would forward all lookups for specific domains to DNS servers inside the encryption domain.

In the Objects Pane, go to New > More > Server > More > SecuRemote DNS. 

Give the object a name and set the host that serves as your DNS server. If more than one host contains these DNS entries, you can define another SecuRemote DNS object for each host. In this example, MyDNS is a host object that represents the DNS server.

Then click on Domains:

 

Here, you can define which DNS domains this object represents. The term Label is used to refer to the individual words in a domain name starting with a period. For instance, phoneboy.com has two labels: phoneboy and com; community.checkpoint.com has three labels: community, checkpoint, and com. When you enter a domain, it must start with a period.

Only certain DNS requests will be forwarded. Using this example, if you select "Match only *.suffix," it means that a DNS request for www.phoneboy.com would get forwarded inside the encryption domain, but mysupersecret.site.phoneboy.com would not get forwarded. If you select "Match up to N labels preceding the suffix," DNS requests for the specified domain that contain the specified number of labels would get forwarded. Using the pictured example, with the option set to match up to 2 labels before the suffix, intranet.phoneboy.com (1 label preceding the suffix .phoneboy.com) would get forwarded and mysuper.secret.phoneboy.com would get forwarded (2 labels preceding the suffix), but my.super.secret.phoneboy.com (3 labels preceding the suffix) would not.

Publish Changes and Install the Security Policy

Hit the Publish button in SmartConsole and hit Publish in the dialog box. Then install the Security Policy.

Installing SecuRemote

You can download the client from the Remote Access VPN page on checkpoint.com. Scroll down until you find Remote Access for Windows and click the download button. Once downloaded, open the MSI, click Next, and choose the SecuRemote option.

Click Next, then click Install, which requires Administrator rights on the client PC.

Adding Site and Connecting

Once the app has finished installing, double-click on the Lock icon in the taskbar. Click Yes to create a new site. Enter the DNS name or IP address of the site. Note that DNS will only be used initially when creating the site. The IP of the site will always be used in the future. Accept the site fingerprint by clicking Trust and Continue. Select the preferred login method of Default. Then select the desired authentication method:

Click Next then Finish. Then select Yes to connect.

If all goes well, you should hear the connect sound and see a popup to that effect. You can verify connectivity by double-clicking on the lock in the taskbar:

I see a VPN interface on my SecuRemote Client with an IP address. Can I change this?

No.

When SecuRemote is used, we still need an IP address on the VPN tunnel interface to satisfy Windows routing. For Office Mode clients, the client IP is assigned either through ipassignment.conf or through the Office Mode pool. In the case of SecuRemote, a fake IP is used. This IP address is chosen by the client and it should not overlap with locally attached networks or the encryption domain. 

That's It, The End!

This is something I scribbled down after working through it. It's been quite a while since I set up SecuRemote so it's possible I missed a step. Let me know how this worked for you in the comments! 

[Danny]

Great work!

[Julian_Sanchez]

Excelent information. 

Good job

[Julian_Sanchez]

Hello, 

I read that you said "In general, Mobile Access Blade and/or Endpoint VPN (sold with SandBlast Agent currently)", I have a question about this. If I have a licences of Enpoint VPN in SandBlast is necesary have licences of Mobile Access in the gateway for obtain office mode ip address or not? 

The escenarie is: The customer have 800 licences of Endpoint VPN, but they havent licences of Mobile Access. Is works fine for received IP address of office mode?

Thanks

[PhoneBoy]

Both Mobile Access Blade and Endpoint VPN licenses include support for Office Mode.

[Julian_Sanchez]

OK. I understand. 

But if I use Endpoint Security with Sandblast, is necessary the licence of Sanblast mobile or is enough with licences Sanblast?

[PhoneBoy]

The current SandBlast Agent packages all include a license for Endpoint VPN.

SandBlast Mobile is a security product for Mobile Phones/Tablets and is not for Remote Access.

[Martin_Raska]

Thx for this excellent explanation, does SecureRemote support two-factor authentication?

[PhoneBoy]

It supports the same authentication methods as other clients, yes.

[dt7]

I understand that using SecuRemoteDNS is necessary when using SecuRemote as the VPN client for handling split DNS, as it does not support office mode.

Can I ask if SecuRemoteDNS can also to be used for enterprise VPN clients like Mobile VPN or Endpoint Security VPN with office mode? The real question behind is I want to enable and use split DNS with Endpoint Security VPN client, and on the documentation it is only indicated to enable the setting on the gateway (done on my case) and setup SecuRemoteDNS objects with the domains to resolve internally (also done). But from what I can test after enabling it, it does not work very well with the VPN client .. Hence my question on how to handle split DNS when using Endpoint Security VPN with office mode.

[PhoneBoy]

You can enable Split DNS for non-SecuRemote clients according to: https://sc1.checkpoint.com/documents/RemoteAccessClients_forWindows_AdminGuide/Content/Topics-RA-VPN... 

[LostBoY]

Very informative link..i was able to setup Securemote but client is picking up IP from i dont know where.. the pool i defined is completly different..sounds like somewhere DHCP is enabled but cant put a finger on it.

[PhoneBoy]

The DHCP Pool is a function of Office Mode and is not relevant for SecuRemote.
Not exactly sure in the logic used by the client for deciding what IP is used.
However, the gateway will never see that IP and will only see the client’s external (public IP).

[LostBoY]

Thanks for reply.. my issue is that the VPN clients are being assigned IP from the Network i have defined in VPN Domain. Clients are not getting ip from the IP NAT Pool which i have configured in Gateway.

eg. i have an internal nw object in VPN domain with 192.168.9.0/24 and 192.168.10.0/24 and my IP NAT POOL is 172.18.20.0/24 

but every time my vpn client is getting an ip from 192.168.9.X segment 

[PhoneBoy]

The IP address you see on the SecuRemote client's virtual interface itself is not relevant.
However, this IP should not overlap with either your local network or your encryption domain.
If you find this is happening, then I recommend a TAC case: https://help.checkpoint.com

More background:

The virtual VPN interface has to have an IP to satisfy Windows routing.
When Office Mode is used, the VPN interface is assigned to the relevant IP per the Office Mode configuration.
In the case of SecuRemote, we use a fake IP on the virtual tunnel interface.
The client will NAT to the user's actual IP before encrypting.
The gateway does not see the private address of the user in this case, only the public IP they appear as (after NAT).
IP Pool NAT will change this to the relevant IP.
However, this IP Pool NAT IP will NOT show anywhere on the client.

Hope this clarifies things.