|
|
In This Section: |
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:
Check Point resolves NAT related connectivity issues with a number of features:
Check Point resolves port filtering issues with Visitor Mode (formally: TCP Tunneling).
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 type are resolved using 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.
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:
Item |
Description |
|---|---|
1 |
Server |
2 |
Security Gateway |
3 |
Internet |
4 |
Router |
5 |
Remote Client |
Hide NAT not only changes the IP header but also the port information contained in the UDP header. For example, if the UDP packet is too long, 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.
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.
Note - If the VPN peers authenticate each other using pre-shared secrets, large UDP packets are not created; however, certificates are more secure, and thus recommended.
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.
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.
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.
Having successfully negotiated IKE phases I and II, we move into the IPsec stage. Data payloads encrypted with AES and SHA, for example, 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.
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:
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 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.
Note - From the system administrator perspective, there is nothing to configure for PMTU; the IPsec PMTU discovery mechanism, both active and passive, runs automatically.
In the following figure, the remote client is behind a NATing device and connecting to a Security Gateway or cluster:
Item |
Description |
|---|---|
1 |
LAN |
2 |
Internal Switch |
3 |
Security Gateway or cluster |
4 |
External Switch |
5 |
Internet |
6 |
NATing Device |
7 |
Remote Access client |
This is also true if the NATing is performed on the Security Gateway side.
Usually to communicate with hosts behind a Security Gateway, remote access VPN client must initialize a connection to the VPN Security Gateway. However, once a remote access VPN client has opened a connection, the hosts behind the VPN Security Gateway can open a return or back connection to the remote access VPN client. For a back connection to succeed, the remote access client's details must be maintained on all the devices between the remote access VPN client and the VPN Security Gateway, and on the VPN Security Gateway itself.
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 tunnels all client-to-gateway communication through a regular TCP connection on port 443.
Item |
Description |
|---|---|
1 |
Host Server |
2 |
Check Point gateway |
3 |
Internet |
4 |
Non-Check Point peer gateway that works with Visitor Mode to allow traffic to the client |
5 |
Remote Access Client |
All required VPN connectivity 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.
To obtain optimal performance of the Visitor Mode server:
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.
Note - All partner Security Gateways must agree on the same allocated port, since the visitor Mode server on the peer gateway will be listening on only one port.
If you change the port for Visitor Mode, see sk103107 for how to create an Endpoint Security VPN site.
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.
Item |
Description |
|---|---|
1 |
TCP Server |
2 |
Security Gateway |
3 |
Internet |
4 |
Remote location's non-Check Point peer gateway |
5 |
Remote location's proxy server |
6 |
Remote Access Client |
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:
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 also works in a MEP environment. For more information, see: Visitor Mode and MEP.
For interface resolution in a Visitor Mode environment, it is recommended to use static IP resolution or dedicate a single interface for Visitor Mode.
This section describes how to configure Remote Access connectivity in SmartDashboard and DBedit.
Small phase II IKE proposals always include AES-256, but not AES-128. Suppose you want to include AES-128 in the small proposals:
Visitor Mode requires the configuration of both the Server and the Client. See also: Visitor Mode and MEP.
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.
Remote Access clients can read any of the Visitor Mode settings, but only if:
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".
If a Remote Access client is on a LAN\WLAN and a proxy server is configured on the LAN, the client 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.
When a Remote Access client 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:
Windows proxy replacement is configured either on the Security Gateway or on the Remote Access client.
To configure the Security Gateway to support Visitor Mode:
The Advanced Configuration window opens:
For more about the VPN CLI commands, see the R80.20 CLI Reference Guide.
