Advanced NAT Settings

This section includes advanced NAT settings.

Deployment Configurations

This section discusses how to configure NAT in some network deployments.

Automatic and Proxy ARP

Giving a computer on the internal network an IP address from an external network using NAT makes that computer appear on the external network. When NAT on the Security Gateway is configured automatically, the Security Gateway replies on behalf of translated network objects to ARP Requests that are sent from the external network for the IP address of the internal computer.

Item	Description
1	Computer on the internal network with IP address 10.1.1.3
2	Security Gateway with external interface IP address 192.168.0.2 responds to ARP Requests on behalf of translated internal objects
3	Translated IP Address 192.168.0.3 on the external network
4	External network

If you are using manual NAT rules, you must configure Proxy ARP entries to associate the translated IP address with the MAC address of the Security Gateway interface that is on the same network as the translated IP addresses.

See sk30197 for more information about configuring:

• Proxy ARP for IPv4 Manual NAT
• Proxy ARP for Scalable Platforms

See sk91905 for more about configuring Proxy NDP for IPv6 Manual NAT.

NAT and Anti-Spoofing

NAT is performed after Anti-Spoofing checks, which are performed only on the source IP address of the packet. This means that spoofing protection is configured on the interfaces of the Security Gateway in the same way as NAT.

Disabling NAT in a VPN Tunnel

When communicating within a VPN, it is normally not necessary to perform NAT. You can disable NAT in a VPN tunnel with a single click in the VPN community object. Disabling NAT in a VPN tunnel by defining a NAT rule slows down the performance of the VPN.

Connecting Translated Objects on Different Interfaces

The following sections describe how to allow connections in both directions between statically translated objects (hosts, networks or address ranges) on different Security Gateway interfaces.

If NAT is defined through the network object (as opposed to using Manual NAT Rules), then you must ensure that bidirectional NAT is enabled.

Internal Communication with Overlapping Addresses

If two internal networks have overlapping (or partially overlapping) IP addresses, Security Gateway enables:

• Communication between the overlapping internal networks.
• Communication between the overlapping internal networks and the outside world.
• Enforcement of a different security policy for each overlapping internal network.

Network Configuration

For example, assume both Network 2A and Network 2B share the same address space (192.168.1.0/24), therefore standard NAT cannot be used to enable communication between the two networks. Instead, overlapping NAT must be performed on a per interface basis.

Users in Network 2A who want to communicate with users in Network 2B must use the 192.168.30.0/24 network as a destination. Users in Network 2B who want to communicate with users in Network 2A must use the 192.168.20.0/24 network as a destination.

The Security Gateway (4) translates the IP addresses in the following way for each individual interface:

Interface 4A

• Inbound source IP addresses are translated to the virtual network 192.168.20.0/24.
• Outbound destination IP addresses are translated to the network 192.168.1.0/24.

Interface 4B

• Inbound source IP addresses are translated to the network 192.168.30.0/24.
• Outbound destination IP addresses are translated to the network 192.168.1.0/24.

Interface 4C

Overlapping NAT is not configured for this interface. Instead, use NAT Hide in the normal way (not on a per-interface basis) to hide source addresses behind the interface's IP address (192.168.4.1).

Communication Examples

This section describes how to enable communication between internal networks, and between an internal network and the Internet

Communication Between Internal Networks

If user 1A, at IP address 192.168.1.10 in Network 2A, wants to connect to user 1B, at IP address 192.168.1.10 (the same IP address) in Network 2B, user 1A opens a connection to the IP address 192.168.30.10.

Communication Between Internal Networks

Step	Source IP address	Destination IP address
Interface 4A — before NAT	192.168.1.10	192.168.30.10
Interface 4A — after NAT	192.168.20.10	192.168.30.10
Security Gateway enforces the security policy for packets from network 192.168.20.0/24 to network 192.168.30.0/24.
Interface 4B — before NAT	192.168.20.10	192.168.30.10
Interface 4B — after NAT	192.168.20.10	192.168.1.10

Communication Between an Internal Network and the Internet

If user 1A, at IP address 192.168.1.10 in network 2A, connects to IP address 192.0.2.10 on the Internet (3).

Communication Between an Internal Network and the Internet

Step	Source IP address	Destination IP address
Interface 4A — before NAT	192.168.1.10	192.0.2.10
Interface 4A — after NAT	192.168.20.10	192.0.2.10
The Security Gateway (4) enforces the security policy for packets from network 192.168.20.0/24 to the Internet (3).
Interface 4C — before NAT	192.168.20.10	192.0.2.10
Interface 4C — after NAT Hide	192.168.4.1	192.0.2.10

Routing Considerations

To allow routing from Network 2A to Network 2B, routing must be configured on the Security Gateway.

These sections contain sample routing commands for Windows and Linux operating systems (for other operating systems, use the equivalent commands).

On Windows

• route add 192.168.30.0 mask 255.255.255.0 192.168.3.2
• route add 192.168.20.0 mask 255.255.255.0 192.168.2.2

On Linux

• route add -net 192.168.30.0/24 gw 192.168.3.2
• route add -net 192.168.20.0/24 gw 192.168.2.2

Object Database Configuration

To activate the overlapping NAT feature, use GuiDBedit Tool (see sk13009), or dbedit (see skI3301). In the sample network configuration, the per interface values for interface 4A and interface 4B are set in the following way:

Sample Network Configuration: Interface Configuration

Parameter	Value
enable_overlapping_nat	true
overlap_nat_dst_ipaddr	The overlapping IP addresses (before NAT). In the sample network configuration, 192.168.1.0 for both interfaces.
overlap_nat_src_ipaddr	The IP addresses after NAT. In the sample network configuration, 192.168.20.0 for interface 4A, and 192.168.30.0 for interface 4B.
overlap_nat_netmask	The net mask of the overlapping IP addresses. In the sample network configuration, 255.255.255.0.

Security Management Behind NAT

The Security Management Server sometimes uses a private IP address (as listed in RFC 1918) or some other non-routable IP address, because of the lack of public IP addresses.

NAT (Static or Hide) for the Security Management Server IP address can be configured in one click, while still allowing connectivity with managed gateways. All gateways can be controlled from the Security Management Server, and logs can be sent to the Security Management Server. NAT can also be configured for a Management High Availability server and a Log Server.

Note - Security Management behind NAT is not supported for deployments where the Security Management Server also acts as a gateway and must be addressed from outside the NATed domain, for example, when it receives SAM commands.

In a typical Security Management Behind NAT scenario: the Security Management Server (1) is in a network on which Network Address Translation is performed (the "NATed network"). The Security Management Server can control Security Gateways inside the NATed network, on the border between the NATed network and the outside world and outside the NATed network.

Item	Description
1	Primary_Security_Management object with IP address 10.0.0.1. Translated address 192.168.55.1

In ordinary Hide NAT configurations, connections cannot be established from the external side the NAT A Security Gateway. However, when using Hide NAT on the Security Management Server, gateways can send logs to the Security Management Server.

When using the Security Management behind NAT feature, the remote gateway automatically selects the Security Management address to be addressed and simultaneously applies NAT considerations.

To enable NAT for the Security Management Server:

• From the NAT page of the Security Management Server object, define NAT and select Apply for A Security Gateway control connections.

Non-Corresponding Gateway Addresses

Sometimes the gateway contacts the Security Management Server with an address that does not correspond to the deployment of the remote gateway. For example:

• When the automatic selection of the gateway does not conform with the routing of the deployment of the gateway. In this case, define the masters and loggers manually, to allow the remote gateway to contact the Security Management Server using the required address. When an inbound connection from a managed gateway enters the Security Gateway, port translation is used to translate the hide address to the real IP address of the Security Management Server.

To define masters and loggers, select Use local definitions for Log Servers and Use local definitions for Masters and specify the correct IP addresses on the gateway.

This solution encompasses different scenarios:

• The remote gateway addresses the NATed IP when you want it to address the real IP.
• The remote gateway addresses the real IP when you want it to address the NATed IP. In this case, specify the SIC name of the Security Management Server in the masters file.

Notes:

• Only one object can be defined with these settings, unless the second object is defined as a Secondary Security Management Server or as a Log Server.
• Ensure that you properly define the Topology settings on all gateways. All workarounds required for previous versions still function with no changes in their behavior.

Configuring the Security Management Server Object

To configure the Security Management Server object:

1. From the NAT page on the Primary_Security_Management object, select either Static NAT or Hide NAT. If using Hide NAT, select Hide behind IP Address, for example, 192.168.55.1. Do not select Hide behind Gateway (address 0.0.0.0).
2. Select Install on Gateway to protect the NATed objects or network. Do not select All.
3. Select Apply for Security Gateway control connections.

Configuring the Security Gateway Object

To configure the Security Gateway object:

1. Open the Security Gateway Network Management page
2. Create the Interface. Click Actions > New interface.
3. In the General page of the Interface window, define the IP address and the Net Mask.
4. In the Topology section, click Modify.
5. Select Override.
6. Select Network defined by the interface IP and Net Mask.

IP Pool NAT

An IP Pool is a range of IP addresses (an address range, a network or a group of one of these objects) that is routable to the gateway. IP Pool NAT ensures proper routing for encrypted connections for the following two connection scenarios:

• Remote Access Client to MEP (Multiple Entry Point) gateways
• Gateway to MEP gateways

When a connection is opened from a Remote Access Client or a client behind a gateway, to a server behind the MEP Gateways, the packets are routed through one of the MEP gateways. Return packets in the connection must be routed back through the same gateway in order to maintain the connection. To ensure that this occurs, each of the MEP gateways maintains a pool of IP addresses that are routable to the gateway. When a connection is opened to a server, the gateway substitutes an IP address from the IP pool for the source IP address. Reply packets from the server return to the gateway, which restores the original source IP address and forwards the packets to the source.

IP Pool Per Interface

You can define a separate IP address pool on one or more of the gateway interfaces instead of defining a single pool of IPs for the gateway.

Defining an IP pool per interface solves routing issues that occur when the gateway has more than two interfaces. Sometimes it is necessary that reply packets return to the gateway through the same gateway interface. This illustration shows one of the MEP Gateways in a Remote Access Client to MEP (Multiple Entry Point) gateway deployment.

Item	Description
1	Packets from source host: Source: Original Destination:
2	VPN tunnel through the Internet
3	MEP Gateway
3A	IP Pool 1 packets: Source: 10.55.8.x Destination:
3B	IP Pool 2 packets: Source: 10.55.10.x Destination:
4	Internal network 10.8.8.0
5	Target host in internal network 10.10.10.0

If a remote client opens a connection to the internal network, reply packets from hosts inside the internal networks are routed to the correct gateway interface through the use of static IP pool NAT addresses.

The remote client's IP address is NATed to an address in the IP pool on one of the gateway interfaces. The addresses in the IP pool can be routed only through that gateway interface so that all reply packets from the target host are returned only to that interface. Therefore, it is important that the IP NAT pools of the interfaces do not overlap.

When the packet returns to the gateway interface, the gateway restores the remote peer's source IP address.

The routing tables on the routers that lie behind the gateway must be edited so that addresses from a gateway IP pool are returned to the correct gateway interface.

Switching between IP Pool NAT per gateway and IP Pool NAT per interface and then installing the security policy deletes all IP Pool allocation and all NATed connections.

NAT Priorities

IP Pool NAT can be used both for encrypted (VPN) and non-encrypted (decrypted by the gateway) connections.

Note - To enable IP Pool NAT for clear connections through the gateway, configure INSPECT changes in the user.def file (see sk98239). Contact Check Point Technical Support.

For non-encrypted connections, IP Pool NAT has the following advantages over Hide NAT:

• New back connections (for example, X11) can be opened to the NATed host.
• User-to-IP server mapping of protocols that allow one connection per IP can work with a number of hosts instead of only one host.
• IPsec, GRE and IGMP protocols can be NATed using IP Pool NAT (and Static NAT). Hide NAT works only with TCP, UDP and ICMP protocols.

Because of these advantages, you can specify that IP Pool NAT has priority over Hide NAT, if both match the same connection. Hide NAT is only applied if the IP pool is used up.

The order of NAT priorities are:

1. Static NAT
2. IP Pool NAT
3. Hide NAT

Since Static NAT has all of the advantages of IP Pool NAT and more, it has a higher priority than the other NAT methods.

Reusing IP Pool Addresses For Different Destinations

IP Pool addresses can be reused for different destinations, which makes more efficient use of the addresses in the pool. If a pool contains N addresses, then any number of clients can be assigned an IP from the pool as long as there are no more than N clients per server.

Using IP Pool allocation per destination, two different clients can receive the same IP from the pool as long as they communicate with different servers (connections 1 and 2). When reusing addresses from the IP Pool, back connections are supported from the original server only (connection 3). This means that connections back to the client can be opened only from the specific server to which the connection was opened.

Item	Description
1	Gateway with IP Pool addresses A to Z
2	Clients. Source: Original Destination:
3A	NATed packet from connection 3. Source: A Destination:
4A	NATed packet from connection 4. Source: A Destination:
5A	NATed packet from reply connection 5. Source: Original Destination: A
6A	This server cannot open a connection with Destination A back to the client.

The default Do not reuse IP Pool NAT behavior means that each IP address in the IP Pool is used once (connections 1 and 2 in the following illustration). In this mode, if an IP pool contains 20 addresses, up to 20 different clients can be NATed and back connections can be opened from any source to the client (connection 3).

Item	Description
1	Gateway with IP Pool addresses A to Z.
2	Clients. Source: Original Destination:
3A	NATed packet from connection 3. Source: A Destination:
4A	NATed packet from connection 4. Source: Z Destination:
5	Connection. Source: Original Destination: A

Switching between the Reuse and Do not reuse modes and then installing the security policy, deletes all IP Pool allocations and all NATed connections.

Configuring IP Pool NAT

To configure IP Pool NAT:

1. From the SmartConsole Menu, select Global Properties.
2. In the Global Properties > NAT page, select Enable IP Pool NAT and the required tracking options.
3. In the gateway General Properties page, ensure the gateway version is specified correctly.
4. For each gateway or gateway interface, create a network object that represents its IP pool NAT addresses. The IP pool can be a network, group, or address range. For example, for an address range, do the following:
   1. From the Objects Bar (F11), In the network objects tree, select New > More > Network Object > Address Range > Address Range.

      The Address Range Properties window opens.

   2. In the General tab, enter the first and last IP of the address range.
   3. Click OK. The new address range appears in the Address Ranges branch of the network objects tree.
5. Edit the gateway object, and select NAT > IP Pool NAT.
6. In the IP Pool NAT page, select one of the following:
   1. Allocate IP Addresses from and then select the address range you created to configure IP Pool NAT for the whole gateway, or
   2. Define IP Pool NAT on Gateway interfaces to configure IP Pool NAT per interface.
7. If required, select one or more of the following options:
   1. Use IP Pool NAT for VPN client connections
   2. Use IP Pool NAT for gateway to gateway connections
   3. Prefer IP Pool NAT over Hide NAT to specify that IP Pool NAT has priority over Hide NAT, if both match the same connection. Hide NAT is only applied if the IP pool is used up.
8. Click Advanced.
   1. Return unused addresses to IP Pool after: Addresses in the pool are reserved for 60 minutes (default), even if the user logs off. If the user disconnects from their ISP and then redials and reconnects, there will be two Pool NAT addresses in use for the user until the first address from the IP Pool times out. If users regularly lose their ISP connections, you may want to decrease the time-out to prevent the IP Pool from being depleted.
   2. Reuse IP addresses from the pool for different destinations: This is a good option unless you need to allow back connections to be opened to clients from any source, rather than just from the specific server to which the client originally opened the connection.
9. Click OK.
10. Edit the routing table of each internal router so that packets with an IP address assigned from the NAT pool are routed to the appropriate gateway or, if using IP Pools per interface, the appropriate gateway interface.

IP Pool NAT for Clusters

IP Pools for gateway clusters are configured in two places in SmartConsole:

• In the gateway Cluster object NAT > IP Pool NAT page, select the connection scenario.
• In the Cluster member object IP Pool NAT page, define the IP Pool on the cluster member. A separate IP pool must be configured for each cluster member. It is not possible to define a separate IP Pool for each cluster member interface.

Site-to-Site VPN

The basis of Site-to-Site VPN is the encrypted VPN tunnel. Two Security Gateways negotiate a link and create a VPN tunnel and each tunnel can contain more than one VPN connection. One Security Gateway can maintain more than one VPN tunnel at the same time.

Sample Site-to-Site VPN Deployment

Item	Description
A, B	Security Gateways
2	VPN tunnel
3	Internal network in VPN domain
4	Host 4
5	Host 5

In this sample VPN deployment, Host 4 and Host 5 securely send data to each other. The Security Gateways perform IKE negotiation and create a VPN tunnel. They use the IPsec protocol to encrypt and decrypt data that is sent between Host 4 and Host 5.

VPN Workflow

Host 4 sends packet to Host 5		Firewalls A & B create VPN tunnel		Firewall A encrypts data
Host 5 receives unencrypted data		Firewall B decrypts data		Encrypted data is sent through VPN tunnel

VPN Communities

A VPN Domain is a collection of internal networks that use Security Gateways to send and receive VPN traffic. Define the resources that are included in the VPN Domain for each Security Gateway. Then join the Security Gateways into a VPN community - collection of VPN tunnels and their attributes. Network resources of different VPN Domains can securely communicate with each other through VPN tunnels that terminate at the Security Gateways in the VPN communities.

VPN communities are based on Star and Mesh topologies. In a Mesh community, there are VPN tunnels between each pair of Security Gateway. In a Star community, each satellite Security Gateway has a VPN tunnel to the central Security Gateway, but not to other Security Gateways in the community.

Mesh Topology

Star Topology

Item	Description
1	Security Gateway
2	Satellite Security Gateways
3	Central Security Gateway

Sample Star Deployment

This section explains how to configure a VPN star community. This deployment lets the satellite Security Gateways connect to the internal network of the central Security Gateway. The internal network object is named: Internal-network.

To create a new VPN Star Community:

1. In SmartConsole, go to the Security Policies page.
2. In the Access Tools section, click VPN Communities.
3. Click New and select Star Community.

   The New Star Community window opens.

4. Enter the name for the community.
5. From the navigation tree, select Encryption.
6. Configure the VPN encryption methods and algorithms for the VPN community.
7. Click OK.

To configure star VPN for the Security Gateways:

For each Security Gateway in the VPN community, follow these configuration steps.

1. In SmartConsole, go to the Gateways & Servers page and double-click the Security Gateway object.

   The gateway properties window opens.

2. In the Network Security section of the General Properties page, select IPsec VPN.
3. From the navigation tree, go to Network Management > VPN Domain.
   • For the central Security Gateway, click Manually defined and select the Internal-network object
   • For a satellite Security Gateway, select All IP addresses
4. From the navigation tree, click IPsec VPN.
5. Configure the Security Gateway as a member of a VPN star community.
   1. In the This Security Gateway participates in the following VPN Communities section, click Add.

      The Add this Gateway to Community window opens.

   2. Select the VPN Community and click OK.
6. Click OK.

After you create a community and configure Security Gateways, add those Security Gateways to the community as a center or as a satellite gateway.

To add a Security Gateway to a new star community:

1. In SmartConsole, go to the Security Policies page.
2. In the Access Tools section, click VPN Communities.
3. Select the new star community and click Edit.

   The Star Community window opens.

4. In the Gateways page, add Security Gateways to the community:
   • Center Gateways - Click Add and select center gateways. Select Mesh center gateways, if necessary.
   • Satellite Gateways - Click Add and select satellite gateways.
5. Click OK.

Sample Combination VPN Community

Item	Description
1	London Security Gateway
2	New York Security Gateway
3	London - New York Mesh community
4	London company partner (external network)
5	London Star community
6	New York company partner (external network)
7	New York Star community

This deployment is composed of a Mesh community for London and New York Security Gateways that share internal networks. The Security Gateways for external networks of company partners do not have access to the London and New York internal networks. However, the Star VPN communities let the company partners access the internal networks of the sites that they work with.

Allowing VPN Connections

To allow VPN connections between Security Gateways in specific VPN communities, add Access Control rules that accept such connections.

To allow all VPN traffic to hosts and clients on the internal networks of a specific VPN community, select these options in the Encrypted Traffic section of the properties configuration window for that VPN Community:

• For a meshed community: Accept all encrypted traffic
• For a Star Community: Accept all encrypted traffic on Both center and satellite gateways, or Accept all encrypted traffic on Satellite gateways only.

Sample VPN Access Control Rules

This table shows sample VPN rules for an Access Control Rule Base. (The Action, Track and Time columns are not shown. Action is set to Allow, Track is set to Log, and Time is set to Any.)

No.	Name	Source	Destination	VPN	Service	Install On
1	-	Any	NEGATED Member Gateways	BranchOffices LondonOffices	Any	BranchOffices LondonOffices
2	Site-to-site VPN	Any	Any	All_GwToGw	FTP-port HTTP HTTPS SMTP	Policy Targets
3	Remote access	Any	Any	RemoteAccess	HTTP HTTPS IMAP	Policy Targets

1. Automatic rule that SmartConsole adds to the top of the Implied Rules when the Accept All Encrypted Traffic configuration option is selected for the BranchOffices VPN community and the LondonOffices VPN community. This rule is installed on all the Security Gateways in these communities. It allows all VPN traffic to hosts and clients on the internal networks of these communities. Traffic that is sent to the Security Gateways in these VPN communities is dropped.

   Note - This automatic rule can apply to more than one VPN community.

2. Site-to-site VPN - Connections between hosts in the VPN Domains of all Site-to-Site VPN communities are allowed. These are the only protocols that are allowed: FTP, HTTP, HTTPS and SMTP.
3. Remote access - Connections between hosts in the VPN Domains of Remote Access VPN community are allowed. These are the only protocols that are allowed: HTTP, HTTPS, and IMAP.

To Learn More About Site-to-Site VPN

To learn more about site-to-Site VPN, see the R80.20 Site-to-Site VPN Administration Guide.

Remote Access VPN

If employees remotely access sensitive information from different locations and devices, system administrators must make sure that this access does not become a security vulnerability. Check Point's Remote Access VPN solutions let you create a VPN tunnel between a remote user and the internal network. The Mobile Access Software Blade extends the functionality of Remote Access solutions to include many clients and deployments.

VPN Connectivity Modes

When securely connecting remote clients with the internal resources, organizations face connectivity challenges, such as these:

• The IP addresses of a remote access client might be unknown
• The remote access client can be connected to a LAN with internal IP addresses (such as, at hotels)
• It is necessary for the remote client to use protocols that are not supported

The Check Point IPsec VPN Software Blade provides these VPN connectivity modes to help organizations resolve those challenges:

• Office Mode

  Remote users can be assigned the same or non-routable IP addresses from the local ISP. Office Mode solves these routing problems and encapsulates the IP packets with an available IP address from the internal network. Remote users can send traffic as if they are in the office and avoid VPN routing problems.

• Visitor Mode

  Remote users can be restricted to using only HTTP and HTTPS protocols. Visitor Mode lets these users tunnel all protocols through regular TCP connections on port 443.

Sample Remote Access VPN Workflow

Here is an example of a Remote Access VPN workflow:

1. Use SmartConsole to enable Remote Access VPN on the Security Gateway.
2. Add the remote user information to the Security Management Server:
   • Create and configure an LDAP Account Unit
   • Enter the information in the SmartConsole user database

   Optional - Configure the gateway for remote user authentication (optional).

3. Define the gateway Access Control and encryption rules.
4. Create the group objects to use in the gateway rules:
   • LDAP Group object - for an LDAP Account Unit
   • User Group object - for users configured in the SmartConsole user database
5. Create and configure the encryption settings for the VPN community object in Global Properties > Remote Access > VPN - Authentication and Encryption.
6. Add Access Control rules to the Access Control Rule Base to allow VPN traffic to the internal networks.

		Enable remote access VPN
Configure LDAP Account Unit	LDAP	Manage Users?	R80 Smart Console	Configure users
Configure user authentication				Configure user authentication
Create LDAP user group object		Create VPN Community		Create user group object
		Configure rules for VPN access in Access Control Rule Base
		Install policy

Configuring the Security Gateway for a Remote Access Community

Make sure that the VPN Software Blade is enabled before you configure the Remote Access community.

To configure the Security Gateway for Remote Access:

1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

   The gateway window opens and shows the General Properties page.

2. From the navigation tree, click IPsec VPN.

   The page shows the VPN communities that the Security Gateway is participating.

3. To add the Security Gateway to a Remote Access community:
   1. Click Add.
   2. Select the community.
   3. Click OK.
4. From the navigation tree, click Network Management > VPN Domain.
5. Configure the VPN Domain.
6. Configure the settings for Visitor Mode.
7. From the navigation tree, click VPN Clients > Office Mode.
8. Configure the settings for Office Mode.

   Note - Office Mode support is mandatory on the Security Gateway side.

9. Click OK and publish the changes.

To Learn More About Remote Access VPN

To learn more about Remote Access VPN, see the R80.20 Remote Access VPN Administration Guide.

Mobile Access to the Network

Check Point Mobile Access lets remote users easily and securely use the Internet to connect to internal networks. Remote users start a standard HTTPS request to the Mobile Access Security Gateway, and authenticate with one or more secure authentication methods.

The Mobile Access Portal lets mobile and remote workers connect easily and securely to critical resources over the internet. Check Point Mobile Apps enable secure encrypted communication from unmanaged smartphones and tablets to your corporate resources. Access can include internal apps, email, calendar, and contacts.

To include access to Mobile Access applications in the Rule Base, include the Mobile Application in the Services & Applications column.

To give access to resources through specified remote access clients, create Access Roles for the clients and include them in the Source column of a rule.