FireWall-1 FAQ: SecuRemote and DHCP
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 :)
For some people, DHCP-related SecuRemote problems are solved with Build 4005 or later of SecuRemote.
SecuRemote has to bind to the network interface before TCP/IP is usable. On NT, the SecuRemote service and the DHCP Client service conflict with each other. On Windows 9x, the initial DHCP request never gets sent out because SecuRemote has not bound to the interface at that time, thus no IP address is obtained from the DHCP Server. This issue also arises when DHCP is used with the “Secure Domain Logon” functionality of Secure Client build 4153 and later.
The following documents some workarounds:
Windows 95/98
Invoke DHCP ‘renew’ manually. Run the winipcfg program and click on renew. Alternatively, you could add it to a batch job that runs from the startup group as “winipcfg /renew_all /batch” (Thanks to David Potelle for the tip)
Windows 98 Issues
Windows 98 has some peculiar behaviour with DHCP in that the leased IP is retained across a reboot. This can cause a problem if your DHCP IP address is in the encryption domain. This IP address can be “released” on reboot with the help of a couple of registry hacks documented in Microsoft’s Knowledge Base Article 217035:
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
Value name: ReleaseLeaseOnShutdown
Type: DWORD
Value data: 0x00000001 (1)
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Shutdown
Value name: FastReboot
Type: STRING
Value data: 0
Note that you must disable FastReboot in order for “ReleaseLeaseOnShutdown” to actually work. You should also disable IPAutoconfiguration via the following registry entry (you will need to create this one), which will prevent Windows from assigning an IP address in the 169.254 address space:
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
Value name: IPAutoconfigurationEnabled
Type: DWORD
Value data: 0x00000000 (0)
Windows NT Workaround (contributed by Roy Santos)
Using NT from the office, the telecommuter needs to disable DHCP client service before they shutdown and go home in the evening. This seems to work well and they don’t get the DHCP timeout when they turn on their computer and connect to their ISP.
Once they are ready to come back to the office, just simply connect the LAN connection again, boot up the system and login. Kill SecuRemote in the taskbar (of course you can leave it on but you’ll then have to enter a login and passwd), then startup DHCP client in manual mode and start the service. Don’t reboot.
Windows NT Registry Hack
The purpose of the registry hack is to make DHCP dependent on the start up of SecuRemote. This means that DHCP will not try and get an IP address until after SecuRemote has bound to the interface, which should cause DHCP to function as expected.
To make this change, go into regedit and look at the value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\DependOnService.
The value will come up in a window displaying both hexadecimal and ASCII. The ASCII will look something like:
Tcpip.Afd.NetBT..
You will need to change this to:
Tcpip.Afd.NetBT.FW0.FW1..
Note: The ‘.’s here are null characters (which you will need to enter in as 00 on the hexadecimal side of the window). You will also need two nulls at the end of the string.
Once you’ve made the registry change, reboot.
