The PhoneBoy Blog

Simplifying Telecom, Mobile Phones, Gadgets, Health, and More!

FireWall-1 FAQ: Outbound Session to a SecuRemote Client

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

SecuRemote, in general, was really designed only to handle encrypted connections initiated from the client side. For some applications (like X Windows), it can be made to work in the other direction, but the trick is that the SecuRemote Client has to first initiate a connection to the machine that will be making a back connection.

Assuming that the SecuRemote client has “authenticated” with the firewall, anything normally allowed by the firewall out that is destined for the SecuRemote client will be encrypted before being transmitted to the client. This is because FireWall-1 keeps track of which hosts are currently authenticated via SecuRemote. If the SecuRemote client has recently initiated a connection inside the encryption domain, the machine’s IP address will be in the userc_rules table. FireWall-1 will automatically encrypt any data sent to that IP address from within the encryption domain provided it would normally be accepted by the rulebase.

If you want to allow certain services out, but only to those machines that have authenticated with SecuRemote (i.e. you wouldn’t want to permit these services outbound in an unencrypted fashion), you can make this work.

In FireWall-1 NG when using “Simplified” Mode (i.e. VPN Communities), you can simply create a rule permitting the necessary services outbound with the If-Via column is set to the Remote-Access community.

On FireWall-1 NG with “Traditional” Mode or FireWall-1 4.1 and earlier, you will need to create the service srMyApp of type other with the following stuff in the Match field (assuming for a moment that “myApp” is a TCP service on port 5555):

    tcp,dport=5555,<dst,0> in userc_rules

The rule that you would need to put in the rule base is:

Source Destination Service Action
HelpDesk-net Any srMyApp Accept

This match stuff means: the protocol has to be tcp, the “destination” port (which defines the service) has to be port 5555, and the destination IP address must be listed in the userc_rules table, which is the table where FireWall-1 keeps track of what IP addresses are currently authenticated with SecuRemote.

To “initiate” the connection from the laptop side, you should be able to have the client ping or otherwise connect to the helpdesk machine that is about to initiate the connection.

#Cybersecurity Evangelist, Podcaster, #noagenda Producer, Frequenter of shiny metal tubes, Expressor of personal opinions, and of course, a coffee achiever.