Resolving Connectivity Issues

The Need for Connectivity Resolution Features

While there are a few connectivity issues regarding VPN between Security Gateways, remote access clients present a special challenge. Remote clients are, by their nature, mobile. During the morning they may be located within the network of a partner company, the following evening connected to a hotel LAN or behind some type of enforcement or NATing device. Under these conditions, a number of connectivity issues can arise:

• Issues involving NAT devices that do not support fragmentation.
• Issues involving service/port filtering on the enforcement device

Check Point Solution for Connectivity Issues

Check Point resolves NAT related connectivity issues with a number of features:

• IKE over TCP
• Small IKE phase II proposals
• UDP encapsulation
• IPSec Path Maximum Transmission Unit (IPSec PMTU)

Check Point resolves port filtering issues with Visitor Mode (formally: TCP Tunneling).

Other Connectivity Issues

Other connectivity issues can arise, for example when a remote client receives an IP address that matches an IP on the internal network. Routing issues of this sort are resolved using Office mode. For more information see: Office Mode.

Other issues, such as Domain Name Resolution involving DNS servers found on an internal network protected by a Security Gateway, are resolved with Split DNS. For more information on Split DNS see: Remote Access Advanced Configuration.

Overcoming NAT Related Issues

NAT related issues arise with hide NAT devices that do not support packet fragmentation.

When a remote access client attempts to create a VPN tunnel with its peer Security Gateway, the IKE or IPSec packets may be larger than the Maximum Transmission Unit (MTU) value. If the resulting packets are greater than the MTU, the packets are fragmented at the Data Link layer of the Operating System's TCP/IP stack.

Problems arise when the remote access client is behind a hide NAT device that does not support this kind of packet fragmentation:

Hide NAT not only changes the IP header but also the port information contained in the UDP header. In Figure 31‑1, the UDP packet is too long so the remote client fragments the packet. The first fragment consists of the IP header plus the UDP header and some portion of the data. The second fragment consists of only the IP header and the second data fragment. The NATing device does not know how to wait for all the fragments, reassemble and NAT them.

When the first fragment arrives, the NAT device successfully translates the address information in the IP header, and port information in the UDP header and forwards the packet. When the second fragment arrives, the NATing device cannot translate the port information because the second packet does not contain a UDP header; the packet is dropped. The IKE negotiation fails.

During IKE phase I

To understand why large UDP packets arise, we need to take a closer look at the first phase of IKE. During IKE phase I, the remote access client and Security Gateway attempt to authenticate each other. One way of authenticating is through the use of certificates. If the certificate or Certificate Revocation List (CRL) is long, large UDP packets result, which are then fragmented by the operating system of the remote client.

IKE Over TCP

IKE over TCP solves the problem of large UDP packets created during IKE phase I. The IKE negotiation is performed using TCP packets. TCP packets are not fragmented; in the IP header of a TCP packet, the DF flag ("do not fragment") is turned on. A full TCP session is opened between the peers for the IKE negotiation during phase I.

During IKE phase II

A remote access client does not have a policy regarding methods of encryption and integrity. Remote access clients negotiate methods for encryption and integrity via a series of proposals, and need to negotiate all possible combinations with the Security Gateway. This can lead to large UDP packets which are once again fragmented by the remote client's OS before sending. The NAT device in front of the remote client drops the packet that has no UDP header (containing port information). Again, the IKE negotiation fails.

Why not use IKE over TCP again, as in phase I?

IKE over TCP solves the fragmentation problem of long packets, but in phase II there are times when the Security Gateway needs to initiate the connection to the remote client. (Only the remote client initiates phase I, but either side can identify the need for a phase II renewal of keys; if the Security Gateway identifies the need, the Security Gateway initiates the connection.)

If the Security Gateway initiates the connection, the Security Gateway knows the IP address of the NATing device, but cannot supply a port number that translates to the remote client behind the NATing device. (The port number used during previous connections is only temporary, and can quickly change.) The NATing device cannot forward the connection correctly for the remote client; the connection initiated by the Security Gateway fails.

It is possible to use IKE over TCP, but this demands a TCP connection to be always open; the open session reserves the socket on the Security Gateway, taking up valuable system resources. The more reasonable solution is to keep open the port on the NATing device by sending UDP "keep alive" packets to the Security Gateway, and then performing IKE phase II in the usual way. However, there is still a need to shorten the UDP packets to prevent possible fragmentation.

Small IKE Phase II Proposals

Both Security Gateway and remote peer start the IKE negotiation by proposing a small number of methods for encryption and integrity. The more common methods are included in the small proposals.

If proposals match between the remote client and the Security Gateway, the proposed methods are used; if no match is found, a greater number of proposals are made. Usually a match is found with the small proposals, and fragmentation is no longer an issue. However, there are cases where a match is not found, and a larger number of proposals need to be made. (This will most likely happen in instances where the remote Security Gateway uses AES-128 for encryption, and AES-128 is not included in the small proposals.)

A greater number of proposals can result in larger UDP packets. These larger packets are once again fragmented at the Data Link Layer of the TCP/IP stack on the client, and then discarded by the hide NAT device that does not support fragmentation. In the case of AES-128, this method of encryption can be included in the small proposals by defining AES-128 as the preferred method.

During IPSec

NAT Traversal (UDP Encapsulation for Firewalls and Proxies)

Having successfully negotiated IKE phases I and II, we move into the IPSec stage. Data payloads encrypted with (for example) 3DES and hashed (for integrity) with MD5, are placed within an IPSec packet. However, this IPSec packet no longer contains a TCP or UDP header. A hide NAT device needs to translate the port information inside the header. The TCP/UDP header has been encrypted along with the data payload and can no longer be read by the NATing device.

A port number needs to be added; UDP Encapsulation is a process that adds a special UDP header that contains readable port information to the IPSec packet:

The new port information is not the same as the original. The port number 2746 is included in both the source and destination ports. The NAT device uses the source port for the hide operation but the destination address and port number remains the same. When the peer Security Gateway sees 2746 as the port number in the destination address, the Security Gateway calls a routine to decapsulate the packet.

IPSec Path Maximum Transmission Units

IPSec Path MTU is a way of dealing with IPSec packet fragmentation. The Data Link layer imposes an upper limit on the size of the packets that can be sent across the physical network, the Maximum Transmission Unit, or MTU. Before sending a packet, the TCP/IP stack of the operating system queries the local interface to obtain its MTU. The IP layer of the TCP/IP stack compares the MTU of the local interface with the size of the packet and fragments the packet if necessary.

When a remote client is communicating across multiple routers with a Security Gateway, it is the smallest MTU of all the routers that is important; this is the path MTU (PMTU), and for remote access clients there is a special IPSec PMTU discovery mechanism to prevent the OS of the client from fragmenting the IPSec packet if the IPSec packet is too large.

However, the PMTU between the remote client and the Security Gateway will not remain constant, since routing across the Internet is dynamic. The route from Security Gateway to client may not be the same in both directions, hence each direction may have its own PMTU. VPN handles this in two ways:

• Active IPSec PMTU
• Passive IPSec PMTU

Active IPSec PMTU

After IKE phase II but before the IPSec stage, the remote access client sends special discovery IPSec packets of various sizes to the Security Gateway. The DF (do not fragment) bit on the packet is set. If a packet is longer than any router's MTU, the router drops the packet and sends an ICMP error message to the remote client. From the largest packet not fragmented, the remote client resolves an appropriate PMTU. This PMTU is not conveyed directly to the OS. Unknown to the operating system, during the TCP three-way handshake, the Maximum Segment Size (MSS) on the SYN and SYN-ACK packets are changed to reflect the PMTU. This is known as Active IPSec PMTU.

Passive IPSec PMTU

Passive IPSec PMTU solves the problem of dynamic Internet routing. Passive IPSec PTMU is a process that occurs when either side receives an ICMP error message resulting from a change in the routing path. Since routes change dynamically on the Internet, if a different router needs to fragment the packet that has the DF bit set, the router discards the packet and generates an ICMP "cannot fragment" error message. The error message is sent to the VPN peer that sent the packet. When the peer receives this error message, the peer decreases the PMTU and retransmits.

NAT and Load Sharing Clusters

In the following figure, the remote client is behind a NATing device and connecting to a load-sharing cluster:

For the connection to survive a failover between cluster members, the "keep alive" feature must be enabled in Global Properties > Remote Access > Enable Back connections from gateway to client

This is also true if the NATing is performed on the Security Gateway cluster side.

Overcoming Restricted Internet Access

When a user connects to the organization from a remote location such as hotel or the offices of a customer, Internet connectivity may be limited to web browsing using the standard ports designated for HTTP, typically port 80 for HTTP and port 443 for HTTPS. Since the remote client needs to perform an IKE negotiation on port 500 or send IPSec packets (which are not the expected TCP packets; IPSec is a different protocol), a VPN tunnel cannot be established in the usual way. This issue is resolved using Visitor Mode, formally known as TCP Tunneling.

Visitor Mode

Visitor Mode tunnels all client-to-Security Gateway communication through a regular TCP connection on port 443.

All required VPN connectivity (IKE, IPsec, etc.) between the Client and the Server is tunneled inside this TCP connection. This means that the peer Security Gateway needs to run a Visitor Mode (TCP) server on port 443.

Number of Users

To obtain optimal performance of the Visitor Mode server:

• Minimize the number of users allowed Visitor Mode if performance degrades
• Increase the number of sockets available on the OS by editing the appropriate values, for example the socket descriptor on Linux systems

Allocating Customized Ports

The organization decides that it would like to use a customized port for the Visitor Mode Server other than the typically designated port 443. In this scenario, another port that is mutually agreed upon by all the remote locations and the home organization, can be used for Visitor Mode. This solution works well with business partners; the partner simply agrees to open a port for the visitor Mode connections. If the chosen port is not represented by a pre-defined service in SmartDashboard, this service must be created in order for the port to be used. If a port has been mutually agreed upon, and there is a proxy, configure the proxy to allow traffic destined to this port.

Visitor Mode and Proxy Servers

Visitor Mode can still be utilized in instances where the remote location runs a proxy server. In this scenario, the remote user enables Visitor Mode connections to pass through the proxy server.

Visitor Mode When the Port 443 is Occupied By an HTTPS Server

If the designated port is already in use, for example reserved for HTTPS connections by a Server at the organization's Security Gateway, a log is sent "Visitor Mode Server failed to bind to xxx.xxx.xxx.xxx:yy (either port was already taken or the IP address does not exist)" to Security Management server.

If the peer Security Gateway is already running a regular HTTP server that also listens on the standard HTTPS port 443, then it must be set up with two external interfaces, both of which have public IP addresses — one for the HTTP server, and one for the Visitor Mode server. This second routable address can be achieved in two ways:

• installing an additional network interface for the Visitor Mode server, or
• by utilizing a virtual IP on the same network interface which is blocking the port.

On the Security Gateway object running the Visitor Mode server, General Properties > Remote Access page > there is a setting for Allocated IP address. All the available IP addresses can be configured to listen on port 443 for Visitor Mode connections.

Visitor Mode with SecurePlatform/IPSO

SecurePlatform running on Linux and IPSO boxes are installed with a pre-configured HTTPS server; the server runs on the Security Gateway and listens on port 443. Installing an additional network interface or utilizing a virtual IP for the Visitor Mode server is not relevant since these HTTPS servers automatically bind to all available IP addresses.

In this case, it is preferable to reserve 443 for Visitor Mode, since users connecting, for example, from a hotel, may only be allowed to connect via ports 80 and 443. These pre-configured HTTPS servers need to be allocated ports that do not conflict with the Visitor Mode server.

Visitor Mode in a MEPed Environment

Visitor Mode also works in a MEPed environment. For more information, see: Visitor Mode and MEP.

Interface Resolution

For interface resolution in a Visitor Mode environment, it is recommended to use static IP resolution or dedicate a single interface for Visitor Mode.

Configuring Remote Access Connectivity

The following section describe how to configure Remote Access connectivity in SmartDashboard and DBedit.

Configuring IKE Over TCP

1. For the Security Gateway, open Global Properties > Remote Access page > VPN-Basic sub-page > IKE over TCP section. Select Gateways support IKE over TCP.
2. Enable IKE over TCP in a connection profile; the remote user works in connect mode to automatically receive the profile. To configure:
   1. From the file menu, Manage > Remote Access > Connection profiles... the Connection Profiles window opens. Click New...
   2. Connection Profile Properties window opens. On the Advanced tab, select Support IKE over TCP.

If the user is not working in connect mode, the user has to manually enable IKE over TCP on the client.

When IKE over TCP is enabled on the Security Gateway, the Security Gateway continues to support IKE over UDP as well. For remote clients, IKE over TCP is supported only for as long as the client works with a profile that enables IKE over TCP.

Configuring Small IKE phase II Proposals

Small phase II IKE proposals always include AES-256, but not AES-128. Suppose you want to include AES-128 in the small proposals:

1. Open the command line database editing tool DBedit. There are two properties that control whether small proposals are used or not, one for pre-NG with Application Intelligence, the other for NG with Application Intelligence.
   • phase2_proposal - determines whether an old client (pre-NG with Application Intelligence) will try small proposals - default "false".
   • phase2_proposal_size - determines whether a new client (for NG with Application Intelligence) will try small proposals - default "true".
2. In Global Properties > Remote Access page > VPN -Advanced subpage > User Encryption Properties section, select AES-128. This configures remote users to offer AES-128 as a small proposal.

Configuring NAT Traversal (UDP Encapsulation)

To configure Nat Traversal on a Security Gateway:

1. In SmartDashboard > General Properties > Remote Access page > NAT Traversal section, select Support NAT traversal mechanism (UDP encapsulation).
2. From the Allocated port drop-down box, select a port. VPN1_IPSec_encapsulation is the default.
3. IKE phase II proposals are offered both with and without UDP encapsulation when dealing with remote access. (There is no UDP encapsulation between Security Gateways). There is no need to enable UDP on the client unless you want to shorten the existing small IKE phase II proposals. Enable UDP encapsulation in a connection profile; the remote user works in connect mode to automatically receive the profile. To configure:
   1. From the file menu, Manage > Remote Access > Connection profiles... the Connection Profiles window opens. Click New....
   2. Connection Profile Properties window opens. On the Advanced tab, select Force UDP Encapsulation.

If the user is not working in connect mode, the user has to manually enable UDP Encapsulation on the client. On the client's file menu, Tools > Advanced IKE Settings, select Force UDP Encapsulation.

Selecting UDP encapsulation on the Security Gateway means that the Security Gateway supports both encapsulated VPN traffic and traffic that is not encapsulated.

Configuring Visitor Mode

Visitor Mode requires the configuration of both the Server and the Client. See also: Visitor Mode and MEP.

Server Configuration

To enable the TCP tunneling feature on the Security Gateways:

On the Security Gateway object running the Visitor Mode Server, IPsec VPN > Remote Access > Visitor Mode Configuration section, select Support Visitor Mode.

• If port 443 is the assigned port for TCPT server, do not change the tcp https default in the Allocated Port section.
• If a customized port (other than the default port) is agreed upon, from the drop-down menu select the service that corresponds to this port. If the chosen port is not represented by a pre-defined service in SmartDashboard, create this service. If Mobile Access is enabled on the gateway, this setting cannot be changed.
• In Allocated IP Address the default is All IPs. To avoid port conflicts, select the appropriate routable valid IP for the Visitor Mode server. If the server has Dynamic Interface Resolving Configuration... enabled (on the VPN - Advanced page) it is recommended to allocate a specific address for visitor mode instead of All IPs. If Mobile Access is enabled on the gateway, this setting cannot be changed

  Note - When Visitor Mode is activated on the gateway, the RDP interface discovery mechanism does not work. A Visitor Mode handshake is used instead.

These settings configure a Visitor Mode server to run on the Security Gateway.

Visitor Mode and Gateway Clusters

Cluster support is limited. The high availability and Load Sharing solutions must provide "stickiness". That is, the visitor mode connection must always go through the same cluster member.

Failover from cluster member to cluster member in a High Availability scenario is not supported.

Enabling Visitor Mode Using a Connection Profile

Create a customized connection profile for Visitor Mode users. This profile enables the Visitor Mode feature on the Client side.

To create the profile:

1. In SmartDashboard, Manage > Remote Access > Connection profiles... the Connection Profiles window opens.
2. Click New... to create a new connection profile or Edit... to alter an existing profile. The Connection Profile Properties window opens.
3. On the Advanced tab, select Visitor Mode.

On the remote client, configure the user to work in connect mode.

Configuring Remote Clients to Work with Proxy Servers

1. In SecureClient, select Detect Proxy from Internet Explorer Settings

   

   In previous versions, the proxy had to be manually defined.

2. Enter a username and password for proxy authentication. This information is later transferred with the "connect" command to the proxy server.

   

Now Secure Client can read any of the Visitor Mode settings, but only if:

• SecureClient is connected to a LAN or WLAN (not dial-up)
• Secure Domain Logon (SDL) is not enabled.

  Note - Visitor mode attempts to connect to the proxy server without authenticating. If a user name and password is required by the proxy, the error message "proxy requires authentication appears".

Windows Proxy Replacement

If SecureClient is on a LAN\WLAN and a proxy server is configured on the LAN, SecureClient replaces the proxy settings so that new connections are not sent to the VPN domain via the proxy but go directly to the LAN\WLAN's Security Gateway. This feature works with and without Visitor Mode. SecureClient must be on a WAN\WLAN and not using a dial-up connection.

When SC replaces the proxy file, it generates a similar plain script PAC file containing the entire VPN domain IP ranges and DNS names (to be returned as "DIRECT"). This file is stored locally, since the windows OS must receive this information as a plain script PAC file. This file replaces the automatic configuration script as defined in Internet Explorer:

Special Considerations for Windows Proxy Replacement

Sensitive information regarding the site's IP Address and DNS settings are contained in SecureClient's userc.C file. For this reason, the file is obfuscated by an algorithm that hides the real content (but does not encrypt it). When the proxy replacement feature is used, the same information is written to the plain text PAC file. For this reason, administrators should be aware that the Windows Proxy Replacement feature exposes the VPN domain by writing Site IP addresses and DNS settings as Java Script code in this plain text PAC file, which can be viewed by any end user.

Configuring windows Proxy Replacement

Windows proxy replacement is configured either on the Security Gateway or on the SecureClient client.

On the Security Gateway:

1. Global Properties > SmartDashboard Customization
2. Click Configure

   The Advanced Configuration window opens:

   

3. Select either:
   • ie_proxy_replacement. If option is selected, windows proxy replacement is always performed, even if visitor mode is not enabled.
   • ie_proxy_replacement_limit_to_tcpt. If this option is selected, then proxy replacement takes place only when visitor mode is enabled.

When SecureClient performs an update, the policy regarding windows proxy replacement is downloaded and put into effect.

On SecureClient

Alternatively, these two properties can be set in the userc.C file on the remote client: