FireWall-1 FAQ: Secure Client and NAT
Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.
I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.
If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)
If your SecuRemote client is behind a device that does any form of Address Translation (including another FireWall-1 firewall) and you are using a version of FireWall-1 prior to 4.0, this can not be made to work. FireWall-1 4.0 and later will support client that are being NATted with the following restrictions:
- The SecuRemote Client must be 4.0 or later (build 4003 or higher).
- You can not use Encapsulation with the FWZ key management scheme (you can use ISKAMP or unencapsulated FWZ however).
- If the client is subject to STATIC NAT (i.e. one to one translation), it will work provided you follow the steps listed below.
- If the client is subject to POOL NAT (i.e. a many to many translation done by Cisco PIX firewalls and other similiar devices), it will work fine so long as each client is given a unique IP addres and you follow the steps listed below.
- If the client is subject to HIDE NAT (i.e. a many to one translation), only one user at a time can use SecuRemote unless you use UDP Encapsulation Mode (more on this below). This should work fine for users that use a device that performs NAT for their home-office network (e.g. users with cable modems or those with Unix or Windows machines performing NAT).
HIDE NAT will only work correctly with IKE (it does not work with FWZ), provided the following is true:
- UDP port 500 on your NAT gateway should be mapped to the SecuRemote client. FireWall-1 tries to communicate via this port.
- Make sure your NAT gateway can pass IPSEC traffic (IP Protocol 50) if UDP Encapsulation is not used.
- If UDP Encapsulation Mode is used, make sure it can pass UDP Port 2746.
- If Gateway Clusters is used with UDP Encapsulation, you will need to upgrade to FireWall-1 4.1 SP3 or later for this to work correctly
- Make sure that each HIDE NAT client is using a different IP address. If two clients attempt to use SecuRemote and have the same non-routable address, neither client will be able to access the internal network correctly. Where this will commonly show up is if two or more clients use the same NAT router with the default configuration. If you use Office Mode in NG FP1 and above, this limitation does not apply.
- Make sure that ESP mode is configured for the affected users in their IKE Properties, encryption tab. AH will not work. This is generally the default.
- The users home network cannot use the same IP address space as your encryption domain. For example, if the encryption domain includes 192.168.1.x, then the client's home network must use a different network. If you use Office Mode in NG FP1 and above, this limitation does not apply.
If your HIDE NAT gateway is a Linux machine, see the following FAQ: Using Secure Client through Linux ipchains/iptables.
If you use a NAT router, consult the list of Routers known (not) to work with Secure Client.
You will also need to modify objects.C on the management console in FireWall-1 4.1 and earlier. Edit $FWDIR/conf/objects.C. For guidelines on editing objects.C, see How do I edit objects.C or objects_5_0.C? After the :props ( line, add or modify the following lines so they read:
:userc_NAT (true)
:userc_IKE_NAT (true)
FireWall-1 4.1 SP2 and Secure Client 4.1 SP2 and later have a “UDP Encapsulation” feature that uses UDP to encapsulate the encrypted data when IKE is used. This more should be far more compatible with NAT devices as all communication will occur over UDP instead of using IP Datagrams. Both FireWall-1 4.1 SP2 and Secure Client 4.1 SP2 (and later) are required to make use of this feature.
If UDP encapsulation does not work with the correct version of SecuRemote installed on the client, you will need to manually enable UDP Encapsulation. In NG, this is configurable in the GUI in the IKE Properties, Advanced page, and should be enabled by default. In FireWall-1 4.1, look for the section in your $FWDIR/conf/objects.C that has your firewall or gateway cluster object. It looks something like this (my object is called phoneboy-gc):
: (phoneboy-gc
:color (black)
:type (gateway_cluster)
:host_schemes_val (121)
:host_schemes_names (
: ("S/Key")
: ("Internal Password")
: (RADIUS)
: (Defender)
: (TACACS)
)
...
)
Note the object definition can actually go on for several screens. The important thing is to look for your firewall or gateway cluster object’s name in objects.C. Right before the “)” (which closes off the definition of phoneboy-gc), add this:
:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname
("#_VPN1_IPSEC_encapsulation")
)
:active (true)
)
The object definition will now look like:
: (phoneboy-gc
:color (black)
:type (gateway_cluster)
:host_schemes_val (121)
:host_schemes_names (
: ("S/Key")
: ("Internal Password")
: (RADIUS)
: (Defender)
: (TACACS)
)
...
:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname
("#_VPN1_IPSEC_encapsulation")
)
:active (true)
)
)
You will also need to create a service called VPN1_IPSEC_encapsulation, if it does not exist. It is a UDP service, port 2746.
Note that once these changes are made, re-install the security policy and have the SecuRemote client update or delete and re-add the site.
By default, FireWall-1 4.1 SP2 and later that has had these changes made will invoke this mode if the UDP port 500 packet coming from the SecuRemote client has a source port that is not port 500. This mode can be forced on the client by going into userc.C on the Secure Client and adding the following under the options section:
:force_udp_encapsulation (true)
Newer versions of the client (build 4199 and above) have this as a configurable option in the GUI.
It can also be disabled entirely on the firewall by changing :active to “false” instead of true in the above objects.C modification.
UDP Encapsulation is known to have an issue with Gateway Cluster, namely it picks the wrong IP address to source UDP encapsulation packets. This causes problems when the client is behind a NAT gateway. To resolve this issue, upgrade to FireWall-1 4.1 SP3 or later and apply the knowledge in the following FAQ: How do I set up a highly-available VPN?
If you are using split/encrypted DNS with SecuRemote, you might have problems with DNS. Set the “active_resolver” to false in userc.C on the SecuRemote client.
Some NAT gateways have problems with fragmented UDP packets, which can create problems when authenticating with Hybrid Mode Authentication or with Certificates. Build 4185 and above of the client along with FireWall-1 4.1 SP4 and above support IKE over TCP (TCP port 500). This allows the offending parts of the IKE negotiation (specifically, phase 1) to occur over TCP to get around this problem. This option must be enabled on the client (configurable in the Secure Client GUI) and on the firewall. It can be enabled globally for all managed firewalls by editing $FWDIR/conf/objects.C on the management console in FireWall-1 4.1 and earlier. For guidelines on editing objects.C, see How do I Edit Objects.C?. After the :props ( line, add or modify the following lines so they read:
:desktop_site_default_tcp_ike (true)
This may be also enabled on a per-gateway basis in 4.1 and earlier by adding the following to the gateway definition, similar to what was done with UDP Encapsulation above:
:supports_tcp_ike (true)
