• Check Point
  • How to Configure a VPN for DAIP Gateway Connected to Internet Using USB 3G-Modem

How to Configure a VPN for DAIP Gateway Connected to Internet Using USB 3G-Modem

Find detailed steps required to configure and troubleshoot a VPN for the DAIP gateway connected to the Internet using USB 3G-modem. Read more …

INTRODUCTION

This document describes the specific configuration of Check Point appliances as a DAIP gateway (with Dynamically Assigned IP Address). It connects to the Internet using a USB 3G modem. As Check Point 2012 appliances do not support USB modems, an additional router will be used which supports USB 3G modems converting them to RJ-45.

Specific to this configuration is an additional Hide NAT which prevents the connection from the Check Point Smart Center to the private IP address of the DAIP gateway in order to send the configuration and initiate a VPN connection.

This document is based on Check Point appliance 2200, TP-LINK TL-MR 3040 which supports various 3G and 4G modems and USB 3G-modem Teleofis RX301 R4. Other modems and routers could be freely used.

LAB CONFIGURATION

As a central gateway we use a virtual machine with the Check Point version R77.30. Its name is «DK-CPSG». The external interface is connected to the Internet and has a public IP address. There are also two internal interfaces to a management network (192.168.48.0/24) and a test segment (192.168.114.0/24).

 [gap height=”30px”]

Firewall and IPSec VPN software blades must be active. IPS and others are optional.

 

Enterprises generally prefer a distributed configuration with a dedicated management server. So we use yet another virtual machine with the same R77.30 version named «DK-CPSM». It is connected to the management network (192.168.48.0/24, see eth0 of the DK-CPSG).

As a remote gateway to establish a VPN with we use a Check Point appliance model 2200. Its name is «DK-CPSG-2200». Its external interface is connected to a TP-Link router. And a 3G USB modem Teleofis RX301 R4 is connected to TP-Link providing an Internet connectivity.

The IP address of the external interface of the DK-CPSG-2200 is configured as «Dynamic».

There are also two internal test segments.

At least Firewall and IPSec VPN blades should be activated.

As we use a 3G modem connected (USB) to the TP-Link router which is connected (RJ-45) to a 2200 appliances there are 2 NAT:

  • Mobile operator assigns a private IP address to a 3G modem and translates it to a public one (sometimes Hide NAT, sometimes static NAT);
  • TP-LINK translates this IP provided by a mobile operator to its own private one on its RJ-45 connection to a 2200 appliance.

PLANNING AND PREPARATION

In order to avoid future IP address conflicts let’s plan IP addresses for a network between 2200 appliances and a TP-Link. For simplicity we can use a C-class network in this case. You may use a smaller mask (say /30). The only requirement – every remote gateway (2200 in our case) would have a unique IP address. It is mandatory for the correct communication between the DAIP gateway and a Check Point management server.

Let’s assign and IP address 192.168.0.1 to the router TP-LINK. Its DHCP server will assign 192.168.0.2 to the 2200 and the default gateway will be 192.168.0.1. When 2200 connects to a Smart Center it will be identified by this IP address (192.168.0.2). That’s why they should be unique for every DAIP gateway.

As we use a distributed configuration and our management server resides behind the central gateway, it will be configured with a private IP address from the management network (192.168.48.0/24 in our case). And it will be statically translated to a public IP address by the central gateway (DK-CPSG). So the remote gateway will connect to the public IP of the Smart Center.

Note: Management network (192.168.48.0/24) should be excluded from the VPN domain!

The connection between remote gateways and the Smart Center will be protected by Secure Internal Communication (SIC protected by SSL) but not encrypted with IPSEC.

3G MODEM TELEOFIS RX301 R4 CONFIGURATION

Teleofis RX301 R4 used in this scenario does not require any special configuration. It’s enough to insert a SIM card and connect it to a USB port of the router.

WI-FI ROUTER TP-LINK TL-MR 3040 CONFIGURATION

TP-LINK TL-MR 3040 looks like:

Connect to its Ethernet port or Wi-Fi (if it was preconfigured). By default you obtain an IP-address from 192.168.0.0/24. Later you will change this network according to your network plan. Web configuration is done by connecting to http://192.168.0.1 (default login/password:  admin/admin).

For 3G modem configuration proceed «Network / 3G/4G»:

Add your mobile operator and settings provided by them in the «Advanced Settings»:

Example:

Ensure that your modem was properly initialized. Check the «Status» in the 3G/4G section:

SMART CENTER NAT CONFIGURATION ON THE CENTRAL GATEWAY

 

To access the Smart Center from the remote gateway let’s configure the static NAT (at least for CPD and FW1_log). Access rules which allow CPD and FW1_log to the Smart Center from the external interface should also be configured.

DAIP GATEWAY CONFIGURATION

After the GAIA installation starts the first time wizard on the remote gateway, answer “Yes” to the question “Is this a Dynamically IP Address gateway installation”?

Connect DAIP gateway to the Smart Center

As there is no way to connect from the Smart Center to the remote gateway behind 2 Hide NAT there are several steps:

1.  Temporarily connect the DAIP gateway directly to the Internet. This way a public IP address should be temporarily assigned to the remote gateway.

2.  Connect this gateway to the Smart Center and configure the VPN.

3.  Change this temporary scheme to the permanent (DAIP, router, 3G modem) as we can now establish communication between the remote gateway and the Smart Center over VPN tunnel.

 

Download our free ultimate runbook to Proactive Alerting of your Check Point Firewalls

 

SIC establishing and initial configuration

1.  Create a new gateway in the Smart Dashboard and configure a public IP address temporarily assigned to our remote “DAIP” gateway.

2 .  Establish SIC

3.  Configure a simple policy for the remote gateway (2200 in our case). It might be even “Permit Any Any”.

4.  Install policy. It will be successfully pushed from the SmartCenter to the remote gateway.
5.  It’s time to fetch the policy from the SmartCenter. Unfortunately if you issue the command ‘fw fetch -n -f’ on the remote gateway you will get an error. It’s because SmartDashboard knows about the private IP address of the SmartCenter (before NAT), which is unreachable from the Internet. The solution is described in the sk98312 – «DAIP Gateway cannot perform ‘fw fetch -n -f‘ when Management Server is hidden behind NAT». We’d activate the option “Use local definitions for masters” and modify the file «masters». (If you forget to activate this option this file will be overwritten after each policy install).

5.  Configure VPN between the central and remote gateways.

Create the Community, choose «Star» topology, add both gateways to this Community:

Assign the “main” IP address from the range 0.0.x.x to the DAIP gateway (0.0.0.8 in this case). If several DAIP gateways were accidently assigned with the same IP you’d follow the sk103523 «VPN traffic issues caused by devices with Dynamically Assigned IP (DAIP)».

6.  Configure encryption algorithms in the VPN properties of the central gateway:

7.  Repeat them for the remote gateway. Please note that IPSec settings of Phase 1 and Phase 2 should be the same both for the central and remote gateways:

8.  Additional configuration for the proper interaction between gateways:

You may not need this configuration for newer versions as this issue was fixed in R77.30. But for earlier versions you may need sk101911 «IKE Phase 1 with DAIP device fails after IP address of DAIP device was changed».

Starting from Check Point R77.10 a DPD (Dead Peer Detection) is supported. It is important as our DAIP gateway is not aware of its public IP due to double NAT (under which it is actually known to the central gateway). Thus it will not be aware of changes of this public so old SA (Security Associations) may hang. Dead Peer Detection should be used to avoid this. The VPN Admin Guide describes this. Also pay attention to the sk108600 «VPN Site-to-Site with 3rd party».
9.  Configure a VPN domain for the central gateway.

Create a network object for the test segment (192.168.114.0/24 in our case).

Configure «Topology» for this VPN domain as “Manually defined” and choose this network object (or group of objects):

 

 

10.  Configure a VPN domain for the DAIP gateway. Create another network object (192.168.110.0/24 in this case).

Note: Also create a network object for the IP address assigned to the external interface of the DAIP gateway (192.168.0.2 in our case – assigned by the TP-Link router).

Choose “Manually defined” in the VPN domain topology and choose the group of objects (192.168.110.0/24 and 192.168.0.2 in our case).

11.  Install policy.

12.  Verify that the VPN tunnel was established. Use Ping to check accessibility of the IP addresses in the test segment (for example 192.168.114.1). As a source IP address choose the IP address from the VPN domain of the remote gateway (192.168.110.5).

13.  Verify that the Smart Center is available as well and policy can be successfully fetched by the remote gateway with the command ‘fw fetch -n -f’.

14.  Change properties of the remote gateway in the Smart Dashboard. It was fixed for previous steps and now it’s time to set it as Dynamic Address as expected. Save the policy. Install Policy will not work after this change. It’s a normal behavior for the DAIP gateways to fetch the policy from the Smart Center periodically.

 

 

15.  Verify that the Smart Center is still available and policy can be fetched (run the command ‘fw fetch -n -f’ on the remote gateway).

16.  You may change the remote gateway connection from the temporary (direct connection to the Internet, with a public IP on its external interface) to the real one (2200 – TP Link router – USB 3G modem).

Change the IP address on the external interface on the remote gateway and its default gateway, verify that VPN tunnels are active and ‘fw fetch -n -f’ works properly.

Note: If the VPN connection can’t be established you may use a ‘vpn tu’ command to delete the old SA both on the central and remote gateways.

Use ping to reach some IP address from the test segment (192.168.114.1) using as a source an IP address from the VPN domain (192.168.110.5).

That’s it. Quite simple
Good luck!

 

Anton Razumov is a Security Engineer Team Leader at Check Point Software Technologies. He has been working with Check Point firewalls for years. If you want to contribute as well, click here.

BlueCat has acquired LiveAction

It’s official! BlueCat has acquired LiveAction’s network observability and intelligence platform, which helps large enterprises optimize the performance, resiliency, and security of their networks.