Print Download PDF Send Feedback

Previous

Next

VPN Routing - Remote Access

In This Section:

The Need for VPN Routing

Check Point Solution for Greater Connectivity and Security

Configuring VPN Routing for Remote Access VPN

The Need for VPN Routing

There are a number of scenarios in which a Security Gateway or remote access clients cannot connect directly to another Security Gateway (or clients). Sometimes, a given Security Gateway or client is incapable of supplying the required level of security. For example:

In all cases, a method is needed to enhance connectivity and security.

Check Point Solution for Greater Connectivity and Security

VPN routing provides a way of controlling how VPN traffic is directed. VPN routing can be implemented with Security Gateway modules and remote access clients. Configuration for VPN routing is performed either directly through SmartDashboard (in simple cases) or by editing the VPN routing configuration files on the Security Gateways (in more complex scenarios).

In the figure above, one of the host machines behind Security Gateway A needs to connect with a host machine behind Security Gateway B. For either technical or policy reasons, Security Gateway A cannot open a VPN tunnel with Security Gateway B. However, both Security Gateways A and B can open VPN tunnels with Security Gateway C, so the connection is routed through Security Gateway C.

As well as providing enhanced connectivity and security, VPN routing can ease network management by hiding a complex network of Security Gateways behind a single Hub.

Hub Mode (VPN Routing for Remote Clients)

VPN routing for remote access clients is enabled via Hub Mode. In Hub mode, all traffic is directed through a central Hub. The central Hub acts as a kind of router for the remote client. Once traffic from remote access clients is directed through a Hub, connectivity with other clients is possible as well as the ability to inspect the subsequent traffic for content.

When using Hub mode, enable Office mode. If the remote client is using an IP address supplied by an ISP, this address might not be fully routable. When Office mode is used, rules can be created that relate directly to Office mode connections.

Note - Office mode is not supported in SecuRemote.

Allowing Clients to Route all Traffic Through a Security Gateway

In the following figure, the remote client needs to connect with a server behind Security Gateway 2. Company policy states that all connections to this server must be inspected for content. For whatever reason, Security Gateway 2 cannot perform the required content inspection. When all the traffic is routed through Security Gateway 1, connections between the remote client and the server can be inspected.

Monitoring Traffic to a

Suppose the same remote client needs to access an HTTP server on the Internet. The same company policy regarding security still applies.

Remote client to internet

The remote client's traffic is directed to the Security Gateway where it is directed to the UFP (URL Filtering Protocol) server to check the validity of the URL and packet content, since the Security Gateway does not possess URL-checking functionality. The packets are then forwarded to the HTTP server on the Internet.

NATing the address of the remote client behind the Security Gateway prevents the HTTP server on the Internet from replying directly to the client. If the remote client's address is not NATed, the remote client will not accept the clear reply from the HTTP server.

Remote Client to Client Communication

Remote client to client connectivity is achieved in two ways:

Routing all Traffic through the Security Gateway

Two remote users use VoIP software to hold a secure conversation. The traffic between them is directed through a central Hub, as shown in the following figure.

Hub

For this to work:

If the two remote clients are configured for Hub mode with different Security Gateways, the routing takes place in three stages - each remote client to its designated Security Gateway, then between the Security Gateways:

Remote Clients to Different Hubs

In the figure above, remote client 1 is configured for Hub mode with Security Gateway A. Remote client 2 is configured for Hub mode with Security Gateway B. For the connection to be routed correctly:

Configuring VPN Routing for Remote Access VPN

Common VPN routing scenarios can be configured through a VPN star community, but not all VPN routing configuration is handled through SmartDashboard. VPN routing between Security Gateways (star or mesh) can be also be configured by editing the configuration file $FWDIR/conf/vpn_route.conf

VPN routing cannot be configured between Security Gateways that do not belong to a VPN community.

Enabling Hub Mode for Remote Access clients

  1. On the Remote Access page of the Security Gateway properties window, Hub Mode configuration section, select Allow SecureClient to route all traffic through this Security Gateway.
  2. On the Properties window of the Remote Access community, Participating Security Gateways page, set the Security Gateway that functions as the "Hub".
  3. On the Participant User Groups page, select the remote clients.
  4. Create an appropriate access control rule in the Security Policy Rule Base. VPN routing traffic is handled in the Security Policy Rule Base as a single connection, matched to one rule only.
  5. Configure the profile on the remote client to route all communication through the designated Security Gateway.

Configuration of Client to Client Routing by Including the Office Mode Range of Addresses in the VPN Domain of the Security Gateway

Add the Office mode range of addresses to the VPN domain of the Security Gateway.

To configure VPN routing for remote access clients with the VPN domain:

  1. In SmartDashboard, create an address range object for the Office Mode addresses.
  2. Create a group that contains both the VPN domain and Office mode range.
  3. On the General properties window of the Security Gateway object > Topology page > VPN domain section, select Manually defined.
  4. Select the group that contains both the VPN domain of the Security Gateway and the Office mode addresses.

The remote clients must connect to the site and perform a site update before they can communicate with each other.

Client to Client via Multiple Hubs Using Hub Mode

The figure below shows two remote clients each configured to work in Hub mode with a different Security Gateway:

Remote Clients with Different Hubs

Remote Client 1 works in Hub mode with Hub 1. Remote Client 2 works in Hub mode with the Hub 2. In order for VPN routing to be performed correctly:

Destination

Next hop router interface

Install On

Hub1_OfficeMode_range

Hub1

Hub2

Hub2_OfficeMode_range

Hub2

Hub1

When Remote Client 1 communicates with Remote Client 2: