Troubleshooting
Troubleshooting SecuRemote can be somewhat tricky. Many problems with SecuRemote are a result of bad interactions with Windows, although there are also plenty of ways to misconfigure settings.
12.11 SecuRemote Communication Ports Are Blocked
See FAQ 12.4 for the list of ports and protocols that might need to be enabled.
12.12 ISP Uses a Custom Adapter to Connect
This situation applies to anyone who uses anything other than a standard Ethernet NIC or Microsoft's Dial-up Adapter to connect to the Internet.
It is becoming increasingly common, particularly with cable or DSL providers, to require PPP over Ethernet (PPPoE) to connect. PPPoE effectively treats your connection to the Internet like a dial-up connection. However, it adds additional protocols and virtual adapters to the TCP/IP stack, not to mention additional overhead due to the PPP encapsulation. This means that SecuRemote either will not bind to the PPPoE stack properly or will experience performance problems due to encapsulation (see FAQ 12.15).
The bindings for PPPoE and SecuRemote look something like this:
Ethernet adapter
PPPoE adapter
You should not have TCP/IP bound to your Ethernet adapter or your PPPoE adapter.
12.13 Problems Adding the New Site
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 264. A simple Telnet from a client without SecureClient installed should validate whether or not this is being blocked at the firewall.
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 ensure that your internal networks 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 the Encryption tab. Once that change has been made and the security policy has been reinstalled, a site update should update userc.C with the correct information. You can update the site either by double-clicking the site icon in SecureClient or by removing and adding the site again in SecureClient.
12.14 Determining the IP Address When Using IP Pool NAT
You can't tell what your IP address is when using IP Pool NAT without the help of a Web server or some other server inside the network that can tell you what IP address you were assigned. For example, I have a simple CGI script that simply prints out the environment it is passed; one of those items is the remote IP address.
One advantage to Office Mode is that it gives you a virtual adapter on your PC, which you can query with the ipconfig command. This shows what address you were assigned.
12.15 Encapsulation, Packet Sizes, and Failing Applications
IPSec is an encapsulated protocol. However, encapsulation creates a problem with fragmentation. IPSec adds 100 bytes to the size of the packet. A packet with a size close to the TCP/IP stack's Maximum Transmit Unit/Maximum Receive Unit (MTU/MRU) becomes greater than the supported MTU/MRU once it is encapsulated in IPSec. Furthermore, some applications (most notably Microsoft Outlook and Lotus Notes) appear to send large packets with the Don't Fragment bit set. This isn't a problem per se, except that FireWall-1 copies this bit from the original packet into the encapsulated one. To resolve this problem, implement the suggestion in FAQ 11.20.
Another problem that comes up, particularly with some of the lower-end NAT routers, is with fragmented UDP packets. Some applications like to use large packets. They may or may not have the Don't Fragment bit set. Even if FireWall-1 or SecureClient doesn't end up copying this bit to the encrypted packet, there's still the business of passing a fragmented packet. Many low-end routers, particularly D-Link and SMC routers, do not appear to deal with fragmented UDP packets at all. Fragmented packets are considered a "bad thing" by these routers, and they refuse to pass these packets. You can troubleshoot this problem by using ping from your SecureClient machine.
In some cases, you may need to make an MTU adjustment on your client. This may be necessary if you are using PPPoE or having problems with fragmented packets. ping from the SecureClient machine can be used to troubleshoot this problem as well.
So how does ping help both these issues? With two specific flags in the Windows version: -l size, which simply refers to the size of the data portion of the packet, and ?f, for setting the Don't Fragment bit. Simply specifying a size for the ping can test the fragmented UDP packets theory. In a standard Ethernet environment with a client-to-site VPN and SecureClient, fragmentation occurs with a packet larger than 1,400 bytes. Because the encryption and IP headers take a total of 128 bytes, this means the ?l parameter should be set to 1373 or higher (e.g., ping ?l 1373 host-in-encdomain). You might have to gradually increase this number until you find the point at which this "breaks"; I found for my D-Link router that it took a slightly larger packet to cause a failure.
For MTU-related issues, it is vital that you set the Don't Fragment bit. This allows you to determine the largest possible MTU that can be used. Similar to the previous example, the largest nonfragmented packet you can send across the VPN is 1,400 bytes. This means that the command ping ?l 1373 ?f host-in-encdomain should fail, but ping ?l 1372 ?f host-in-encdomain should succeed. If neither command succeeds, try using lower and lower values for ?l until your command succeeds. Whatever value you find works for you, set the MTU to that value plus 128 bytes. For example, if you find that the largest ping that works is ping ?l 1364 ?f, set your MTU to 1,492 bytes.
How can you set the MTU? FireWall-1 NG FP3 and above comes with a utility called MTUAdjust in C:\Program Files\CheckPoint\SecuRemote\bin. When you run this program, you will be able to adjust the MTU on all interfaces (see Figure 12.45).
Figure 12.45. MTU Adjuster
12.16 Windows NT and File Permissions
As a nonprivileged user, you might receive the SecuRemote authentication dialog and the successful authentication message but then cannot connect to the internal network. No incoming packets from the SecuRemote client can be seen at the firewall. If you restart SecuRemote and authenticate again, everything works splendidly.
To resolve this issue, change the rights to the directory %SystemRoot%\system32\drivers\etc to RWX:RWX. You can do this only if Windows is installed on an NTFS partition under Windows NT/2000.
12.17 Mixing NICs and Dial-up Adapters
If you have a NIC configured with an IP address inside the encryption domain, SecuRemote will not work correctly unless you use Office Mode. This happens most often with laptops used on the road as well as in the office. The following subsections contain a list of potential configurations, the problems associated with them, and workarounds.
NIC Uses Static IP and Has IP in the Encryption Domain
This particular problem occurs 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 because it will attempt to use the NIC directly. This is not a SecuRemote-specific issue.
You can remove the route associated with the network on which the NIC is configured. 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 the next subsection.
SecuRemote Is Bound to All Adapters
You need to bind SecuRemote to all adapters only in the following cases:
When a NIC is used to access the Internet (e.g., for DSL and cable modems)
If you use Windows NT (you do not have a choice)
Binding SecuRemote to all adapters can cause additional problems in the previously mentioned cases (e.g., the NIC has an IP address inside the encryption domain). If you bind SecuRemote to all adapters, it is advisable to keep your NIC cards plugged in at all times. Sometimes, removing and reinstalling a NIC will hose the TCP/IP stack entirely. A reboot is the only way to recover. For physically uninstalled but configured NICs (e.g., a laptop's unplugged PCMCIA card), the routing table shows the uninstalled NICs' routing information. Without SecuRemote installed on all interfaces, the information related to the removed NIC card will not be shown in the routing table (i.e., when you type route print).
12.18 NG FP1/FP2 System Status Viewer Shows No Response for Desktop Policy Server
If this problem occurs, the Desktop Policy Server DLLs did not get installed correctly. Execute the following commands on the firewall module to resolve this in NG FP2:
# cpstop # amon_config cpstatdll add polsrv /opt/CPdtps-50-02/lib polsrvstatagent # cpstart
In NG FP1, replace CPdtps-50-02 with CPdtps-50-01 in the appropriate command above.
Here's another approach that also solves this problem:
# cpstop # cp /opt/CPdtps-50-02/lib/* $FWDIR/lib # amon_config cpstatdll add polsrv $FWDIR/lib polsrvstatagent # amon_config oidqfile add polsrv $FWDIR/conf dtps polsrv # cpstart
