| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Outbound Session to a SecuRemote Client SecuRemote, at least historically, was 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, in userc_rules The rule that you would need to put in the rule base is: Source Destination Service ActionHelpDesk-net Any srMyApp AcceptThis 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. -- PhoneBoy - 05 Apr 2004 FAQForm FAQs.Class: SecureClientFAQs FAQs.OS: FAQs.Version: |
![]() |
| Thread Tools | |
| Display Modes | |
| |