FireWall-1 FAQ: Troubleshooting SecureClient Issues

Last Modified: 13 Dec 2002

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 :)

Here is a general list of things to check:

Situations Where SecuRemote Can Not Work
Encryption Setup on Firewall
Adding the New Site
Encapsulation
Ports SecuRemote Uses
NICs and Dial-Up Adapters
Windows NT and File Permissions

Situations Where SecuRemote Can Not Work

The following is a non-exhaustive list of places where SecuRemote will not work or will only work under a specific set of circumstances.

SecuRemote Client needs NAT

If your ISP only gives you one IP address and you are using a device like a Ascend Pipeline or a Linux machine running IP Masquerading to allow more than one machine to access the Internet, then you are using NAT (Network Address Translation). Even if you use an analog or ISDN modem to access the Internet, your ISP could be employing NAT. If you’re not sure, talk with your ISP.

3.x SecuRemote and FireWall-1 did not support NAT on the client side. 4 and later releases of both SecuRemote and FireWall-1 support this, albeit with a number of limitations. See Secure Client and NAT for more information.

SecuRemote Client requires Proxy for Internet Access

SecuRemote can not be used from behind a proxy server. See SecuRemote from Behind a Proxy Server for more details.

SecuRemote Communication Ports are Blocked

If any of the ports and protocols used by SecuRemote are blocked by a router or firewall, SecuRemote will not work.

ISP does not use Dial-Up Networking or NIC to Connect

SecuRemote only works with Microsoft’s Dial-Up Networking or a standard NIC. Anything else will not function with SecuRemote.

Encryption Setup on Firewall

I won’t completely explain all the details behind each item, but here is a list of things to check.

Your firewall must be set up for IKE encryption.
Make sure the IP address defined in your firewall object is the external, routable address. This IP should match the nodename IP address of your firewall machine. Both name and IP should be resolvable via the firewall’s local hosts file (and/or DNS).
If you are using version 4.1 or earlier, you can also set up FWZ, but it is not recommended.
Ensure the firewall object is marked as “Exportable”.
Ensure at least one “Client Encrypt” rule is present in your rulebase or that apporpriate rules are set up with the remote access community.
If using FireWall-1 4.0 with a SecuRemote 3.0 or earlier client, insure that “Respond to Unauthenticated Cleartext Rquests for Topology” is checked in the Encryption tab of the rulebase properties. This feature is only compatible with SecuRemote 4.0.
Ensure at least one user is defined in the User Database and that the user database has been installed after any changes.
If any changes were made above, re-install the security policy to make them effective.
Check to see if the UDP port 259 or UDP port 500 packets a SecuRemote client generates are making it to the external interface of the firewall. Use a tool like tcpdump, snoop, or NetXRay (packet sniffers) to verify.

Adding the New Site

When you are adding a new site, you will need to enter the IP address of the Management Console, not the firewall itself (unless, of course, the firewall is the management console). FireWall-1 4.0 and later allows you to enter the IP address of the firewall instead.

If you get the error message “connection to site x.y.z.w has failed”, ensure that your SecuRemote client can communicate to that IP via TCP port 256 or 264, depending on the version of SecuRemote (see below for more details).

When you “create a new site,” information about the encryption domain will be downloaded to the system and stored in a file called userc.C on the client. Check the userc.C file to insure that your internal network(s) are listed. If they are not, the firewall administrator needs to make sure that the “Exportable” flag is checked in the firewall’s network object under “Encryption.” Once that change has been made and the security policy has been re-installed, an “update” should update userc.C with the correct information.

Encapsulation

If you plan on using any Microsoft Networking services or any service that does not address translate very well and your firewall must perform address translation (because you’re using illegal or non-routable addresses), then the use of IKE or FWZ with encapsulation is required.

If your SecuRemote client is subject to NAT (even if you make the changes noted in Secure Client and NAT) , FWZ encapsulation will not work. Use IKE instead.

Encapsulation creates a problem with fragmentation. FWZ encapsulation adds 4 bytes to the size of the packet. IKE probably adds around 100 bytes (depending on options used). A packet with a size close to the TCP/IP stack’s MTU/MRU (Maximum Transmit/Receive Unit) will become greater than the supported MTU/MRU and will have problems in transit. If you use PPP over Ethernet (i.e. for a DSL connection), there is additional encapsulation. Most of the problems that happen with fragmentation seem to occur with FWZ encapsulation, though, not IKE. To determine what the maximum packet size for your particular situation, use ping as follows:

ping -f -l X a.b.c.d

where X begins at 1500 and a.b.c.d is an IP address in you encryption domain. Keep decreasing X until you find the value that works for you. We will then use this value to set our MTU value.

A related problem: if large packets with the don’t fragment bit set, SecuRemote and FireWall-1 will have problems. See the following FAQ for more details: VPNs fail when transferring large packets.

Secure Client build 4157 does some automatic adjusting of the MTU size. If you are not using this version, you can adjust the MTU/MRU sizes. In Windows NT 4.0 SP3 or later (with the appropriate hotfixes), you can modify the MTU size by modifying the following registry entry (thanks to Jim Richards for finding it and emailing it to me). The key is HKEY_Local_Machine\System\CurrentControlSet\Services\NdisWan\Parameters. Add or modify the following entries:

Value name:    IPMTU
Data Type:     REG_WORD
DATA           1500 decimal Value name:    TunnelMTU
Data Type:     REG_WORD
DATA           1500 decimal

On Windows 98 (or 95 with Dial-up Networking 1.3 installed), you can modify the parameters on the Dial-Up Adaptor. Set the Packet Size parameter to "High." For NICs, modify the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\netTrans\000n where n is the TCP/IP binding associated with your NIC. You will be able to easily tell as the IP address will be listed in this hive. Note that MaxMSS should be 40 less than MaxMTU.

Value Name:    MaxMTU
Data Type:     String
DATA           1500
Value Name:    MaxMSS
Data Type:     String
DATA           1460</blockquote>
On Windows 2000, the appropriate registry settings are (thanks to Frank Boch for these):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<adapter ID>
MTU=1418 (REG_DWORD Decimal)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnablePMTUDiscovery=0 (REG_DWORD Decimal) </blockquote> ### Ports SecuRemote Uses SecuRemote requires the following ports and protocols to be allowed by any intermediary device (routers, firewalls). If one of these devices is a FireWall-1 box, see Secure Client through a FireWall-1 Firewall : * TCP port 264 (FireWall-1 4.1 and beyond) or TCP port 256 (FireWall-1 4.0 and earlier) between client and Management Console. This is only needed to fetch and update the site information and will always originate from the SecuRemote client. * TCP Port 18231 (FireWall-1 NG) or TCP Port 18207 (FireWall-1 4.1) is used if Secure Client needs to authenticate with a policy server * UDP port 259 to negotiate encryption and authentication information for FWZ. * UDP port 18234 (FireWall-1 NG) is used for testing VPN tunnel availability in NG FP1 when Office Mode is enabled. * UDP port 500 to negotiate encryption keys when IKE is used. * UDP port 2746 when UDP Encapsulation is used. * IP Protocol 94 bi-directionally when FWZ encapsulation is used. * IP Protocol 50 bi-directionally when IKE is used. ### NICs and Dial-Up Adapters If you have a NIC configured with an IP address inside the encryption domain, SecuRemote will not work correctly. This happens most often with laptops used both on the road and in the office. Here is a list of potential configurations, the problems associated with them, and workarounds. #### NIC uses Static IP, has IP in the Encryption Domain This particular problem shows up whether or not your NIC is using DHCP. If your NIC has an IP address in the encryption domain and you either dial up to the Internet or use the local LAN, SecuRemote will not attempt to talk to your internal network in an encrypted fashion as it will attempt to use the NIC directly. This is not a SecuRemote-specific issue. You can remove the route associated with the network the NIC is configured to be on. For instance, if your IP address is 172.17.55.10 and your netmask is 255.255.255.0, you can remove the route by typing the command 'route delete 172.17.55.0 mask 255.255.255.0 172.17.55.10'. If SecuRemote is installed on all NICs and the NIC in question is not physically installed at the time, this command will fail. See SecuRemote Bound to All Adaptors below for more details. #### NIC uses DHCP, has IP in the Encryption Domain SecuRemote can have problems with DHCP, either in obtaining an IP address, or because the IP address (previously) obtained is part of the encryption domain. See SecuRemote and DHCP for more details. #### SecuRemote Bound to All Adaptors You only need to bind SecuRemote to all adaptors in the following cases: * A NIC is used to access the Internet (i.e for DSL, Cable modems) * If you use Windows NT (You don't get a choice. ;-) Binding SecuRemote to all adaptors can cause extra problems in the above mentioned cases (i.e. the NIC has an IP address inside the encryption domain). If you bind SecuRemote to all adaptors, it is advisable to keep your NIC cards plugged in at all times. I have heard reports that removing and re-installing a NIC will hose the TCP/IP stack entirely. A reboot is the only way to recover from this. For the physically uninstalled but configured NICs (e.g. a laptop's unplugged PCMCIA card), the routing table will show the un-installed NICs routing information. Without SecuRemote installed to all interfaces, the information related to the removed NIC card would not be shown in the routing table (i.e. when you type "route print"). If the NIC were plugged in, if the NIC had an IP address in the encryptoin domain, I would expect problems. However, if the NIC is not plugged in, then you really don't have an IP address in the encryption domain, so it should work. However, the uninstalled NIC's routing information is in the routing table (as if it were installed), so it doesn't work. Trying to remove the bogus routing information with 'route delete' commands don't work because the NIC is really not installed. Check Point has confirmed this is a bug and it appears to be fixed in Secure Client build 4153. ### Windows NT and File Permissions Riccardo Valente sends me this interesting tip, which has to do with file permissions on the directory containing the HOSTS file. Thus, this is only relevant on NT systems where the WINNT directory is on an NTFS partition. The symptoms can be described as follows: As a non-privileged user, you get the SecuRemote authentication dialog, then the successful authentication message, but you can't connect to the internal network. No incoming packets from the SecuRemote client can be seen at the firewall. If SecuRemote is restarted and authenticate again, everything works splendidly. To resolve this issue, change the rights to the Directory %SystemRoot%\system32\drivers\etc to RWX:RWX. ### Respond to Unauthenticated Cleartext Requests in NG In FW-1 NG the option "Respond to nauthenticated Cleartext Rquests for Topology" is no longer available. One has to change allow_clear_gettopo in 'objects_5_0.C'. Prefered way is to use dbedit or GUIDbedit.
taken from http://www.firewall-1.org/2002-05/msg00328.html:
1. Download the dbedit or guidbedit utility to the Management Server from
   www.checkpoint.com 
2. Close the Policy Editor GUI 3. Use the dbedit utility to set allow_clear_gettopo in the
   firewall_properties table to false Go to the command window of the
   Management Server:
      C:\>dbedit 
      Enter Server name (ENTER for 'localhost'):
      Enter User Name: fwadmin
      Enter User Password: ******
      Please enter a command, -h for help or -q to quit:
      dbedit> modify firewall_properties allow_clear_gettopo false
      dbedit> quit

   You will be prompted if you want to save and update. Enter yes.
4. Install the policy in order for the dbedit modification to take effect on the firewall module

The PhoneBoy Blog