SecureRemote from behind a NAT device

How to encrypt data between an SR Client behind a NAT device and the LAN behind FW-1,

You have to distinguish 2 situations

1) Static NAT, Pool NAT, 1 user behind a Hide NAT

2) Hide NAT with multiple users

In the following configuration you solve it for situation 1) :

SR Client ------ NAT device (FW or other) ----- Internet ------ FW-1--- LAN

For this configuration you need VPN-1 version 4.1.

It it supported with FW-1 4.0 (and SR versions above SR4003) by making the following modifications

Stop FireWall-1 with the command

fwstop

Edit the $FWDIR/conf/objects.C file and add (or modify) the following lines which are under the property

set props : :userc_NAT (true) for FWZ,

and :userc_IKE_NAT (true) for ISAKMP (IKE).

Restart FireWall-1 with the command fwstart Install the policy.

Confirm that these changes appear both in $FWDIR/conf/objects.C and in $FWDIR/database/objects.C For Static NAT and Pool NAT, this configuration works fine with the FWZ and IKE encryption schemes.

This works with Static NAT and Pool NAT fine. For Dynamic NAT, it will only work if there is a single SR client behind each hiding IP address.

2) If you are subject to address translation, it is highly recommended to use IKE instead of FWZ. Both encapsulated and unencapsulated FWZ are known not to work with HIDE NAT at all. Static NAT (1-to-1 address mapping) should work with FWZ in either mode provided you allow IP Protocol 94, UDP Port 259, and other services if you use FWZ in unencapsulated mode. However, most NAT gateways will reject unencapsulated FWZ packets because the checksums are changed to support the FWZ encryption scheme.

If you are subject to any form of NAT, IKE is your best bet. However, most NAT gateways can not be configured to perform HIDE NAT on generic IP Datagrams. Provided you can forward UDP Port 500 packets and IP Protocol 50 (IPSEC) packets with your NAT gateway, you can use IKE with NAT.

Secure Client 4.1 SP2 and later when used with FireWall-1 4.1 SP2 and later support a 'UDP Encapsulation Mode' for IKE. Instead of using IP Protocol 50, UDP port 2746 is used. Most NAT gateways can perform address translation on UDP packets and it is designed to work with HIDE NAT, meaning multiple users can make use of SecuRemote behind a HIDE NAT gateway. Provided your clients are able to use TCP port 264 to fetch the topology, UDP port 500 to perform an IKE key exchange, and UDP port 2746, this should work.

You will need to modify objects.C on the management console to permit FireWall-1 to accept connections from NATted SecuRemote users. Edit $FWDIR/conf/objects.C. After the props: line, add:

:userc_NAT (true)
:userc_IKE_NAT (true)

To configure the UDP Encapsulation Mode for FireWall-1 4.1 SP2, create a service called VPN1_IPSEC_encapsulation if it does not already exists. Create it with port UDP 2746. Then add the following section to the section with your gateway object to objects.C:

:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname
("#_VPN1_IPSEC_encapsulation")
)
:active (true)
)

You have to add this in between the properties defined for your firewall object. Search the Objects.C file for the name of the firewall object ( through which you would like to the UDP encapsulation enabled ) and add these lines in between the various features configured for your firewall object.

Re-install the policy.

Note that in the default configuration, FireWall-1 will determine whether or not to use this mode based on the source port of the incoming UDP 500 packet. If it comes from source port 500, it will not use the UDP encapsulation mode. If it comes from a different source port, UDP encapsulation mode will be used. More details and instructions for disabling or forcing this mode can be found in the Secure Client 4.1 SP2 Release Notes.

Description of UDP Encapsulation. Seeing UDP encapsulation is a new feature and I was concerned about it affecting the users with older securemote software, here is a quick and dirty explanation of UDP Encapsulation. 

1. SR sends IKE packet to VPN-1, one of the IKE proposals it sends to the gateway is to use UDP encapsulation. Note, only SP2 clients can send this UDP encap proposal, SP1 or earlier clients, cannot. 

2. If IKE negotiation (port UDP-500/500) packet's SRC PORT has NOT been translated, then no UDP encapsulation, it just operates like normal SR IKE session (thus SP2 and SP1 and earlier SR's can run side by side against a single gateway): a standard proposal is selected and a VPN tunnel is established. 

3. If IKE SRC PORT != 500, then the gateway assumes that a NAT HIDE device is between the gateway and SR. Then, and only then, does it accept the UDP encapsulation proposal. This selection is communicated to the client. 

4. The client takes note of the selected IKE Proposal (encap or a "normal" one) and if encap, wraps the IPSEC traffic in a UDP packets. It is actually quite an elegant solution, as it is end user transparent and encapsulation (i.e., the extra overhead) is only used when needed... when the SR client is behind such a NAT device. When the SR client is moved to another non-NATed network, no encap takes place.