FireWall-1 FAQ: Secure Client through a FireWall-1 Firewall
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 firewall is not performing any address translation on the SecuRemote client, then it will work with the information provided below. If your firewall is doing address translation for the SecuRemote client (because the client has a non-routable or illegal IP address), then read the following FAQ to determine if such a configuration will be possible: Secure Client and NAT
Assuming you are not doing address translation or can workaround it, part of what needs to be done will depend on whether or not the remote FireWall-1 is configured to use encapsulation for SecuRemote connections or not.
General Configuration
In all cases, you will need to permit the following traffic through your local firewall (note only use IKE for FireWall-1 4.0 and above when IKE is used for SecuRemote, in 4.0 the service is named ISAKMP):
Source Destination Service Action
SecuRemote-Client Remote-Mgmt-Server FW1 Accept
FW1_topo
FW1_pslogon
SecuRemote-Client Remote-FireWall RDP Accept
IKE
Remote Site Uses FWZ Encapsulation
If the remote site is using encapsulation for SecuRemote clients, the following additional rule needs to be added:
Source Destination Service Action
SecuRemote-Client Remote-FireWall FW1_Encapsulation Accept
Remote-FireWall SecuRemote-Client
FW1_Encapsulation is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with “ip_p=94” in the Match field.
Remote Site Uses IKE
If the remote site is using IKE for SecuRemote clients, the following additional rule needs to be added:
Source Destination Service Action
SecuRemote-Client Remote-FireWall ESP Accept
Remote-FireWall SecuRemote-Client
ESP is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with “ip_p=50” in the Match field.
Remote Site Uses UDP Encapsulation
If the remote site is using UDP Encapsulation on their clients, the following additional rule needs to be added:
Source Destination Service Action
SecuRemote-Client Remote-FireWall VPN1_IPSEC_encapsulation Accept
Remote-FireWall SecuRemote-Client
VPN1_IPSEC_encapsulation is pre-defined on FireWall-1 4.1 SP3 and above. If it is not pre-defined on yours, then create it as service of type UDP, port 2746.
Remote Site uses FWZ without Encapsulation
If the remote site does not use encapsulation, then you will need to permit the necessary traffic to and from the remote site by your local firewall’s rulebase. You need to make sure that none of the traffic is processed through the security servers or an intermediary proxy or you might get unreliable or unpredictable results. The following rule near the top of your rulebase should suffice:
Source Destination Service Action
SecuRemote-Client Remote-Servers Any Accept
The “any” above can be replaced with the specific services the SecuRemote client needs to use.
Remote Site uses NG, Policy Server, and Office Mode
If you are using Office Mode on FireWall-1 NG and/or using the Policy Server for NG, you will need the following rules:
Source Destination Service Action
SecuRemote-Client Remote-FireWall FW1_pslogon_NG Accept
IKE
VPN1_UDP_Encapsulation
Tunnel-Test
FW1_pslogon_NG is TCP port 18231. Tunnel-Test is UDP Port 18234.
