Be careful about formatting when you save the modified file. The first time my formatting got hosed and the FW would not load. This happend with notepad. I used DOS and it worked perfectly the second time. Luckily I copied the file into 2 places and just re-performed the fix, and put the file in.
By the way, Nokia, Checkpoint, and Microsoft worked on this with us for several days before an overly studious Checkpoint support person heard something in our conversation that tipped him off to the root cause.
From Checkpoint Support
How to increase the TCP Established connection Grace Period
Fact: FireWall-1
Fact: TCP
Fact: Connections Table
Fact: Established TCP Connections
Fact: TCP Established connection Grace Period
Symptom: Packets from Established TCP Connections are being dropped
Symptom: Error in Log viewer:
Symptom: Error: "proto tcp src <IP_Address> dst <IP_Address> service
<Service_name> s_port <Port_number> rule 0 reason: unknown established TCP packet"
Change: A new Security Policy was installed.
Cause: A connection is not present, both in the connection table and in the old connections table. When a new Security Policy is installed, the connections table is cleared. Established connections are then moved to old connections table for the remainder of their TCP timeout. When this timeout reaches its end, packets arriving to the VPN/FireWall Modules that are not from an established connection entry in either of the tables, are dropped. In other words, only TCP SYN (TCP connection initiation) packets and connections present in the old connection table are allowed to be matched to the Rule Base. Non-SYN packets that do not belong to any known connection are dropped.
Fix: 1. Close all VPN-1/FireWall-1 GUI clients.
2. Edit the $FWDIR/conf/objects.C file on the management (Use a simple text editor such as Notepad/Wordpad. Do not use a Word processor).
3. Under the :props section of $FWDIR/conf/objects.C, add the following line:
:tcpestb_grace_period (XX)
Note: I made this (75) Tim
All non TCP SYN packets that are not part of an established connection in either table will be matched against the Rule Base for XX seconds after a Security Policy installation.
See also <a href="primus://:sk294">How to edit the objects.C file</a>.
4. Save the changes to the objects.C file
5. Reinstall the security policy 6. For properties that involve the security servers, VPN-1/FireWall-1 must be restarted
FireWall-1 4.1 SP2
Fact: FireWall-1 Gateway object
Fact: Connections table
Fact: Non SYN packet
Fact: Rule 0
Symptom: Error message in the Log viewer
Symptom: Error: "proto tcp src <IP_Address> dst <IP_Address> service
<Service_name> s_port <Port_number> rule 0 reason: unknown established
TCP packet"
Symptom: Connections which have been inactive for a longer period than the TCP timeout are blocked Symptom: All TCP connections established before starting the FireWall-1 are blocked
Symptom: All TCP connections established before installing the first
Security Policy after the upgrade from 4.1 FCS/SP1 to 4.1 SP2 are blocked
Symptom: unknown established TCP packet
Cause: This is the result of a security enhancement property implemented in FireWall-1 4.1 SP2. Only TCP SYN (TCP connection initiation) packets are allowed to be matched against the rule base.
Non-SYN connections that do not belong to any known established connection are dropped.
Fix: To disable this security enhancement and allow "Non SYN" packets to be matched against the rule base follow these steps:
1. On the Management Server, open the file $FWDIR/lib/fwui_head.def 2.
Find the line
/*#define ALLOW_NON_SYN_RULEBASE_MATCH*/
3. Uncomment the line. Change it to
#define ALLOW_NON_SYN_RULEBASE_MATCH
3. Install the Policy.
**NOTE** You should consider all security implications when allowing this kind of traffic to be matched against the Security Policy
* Please refer to <a href="primus://:skI1788">Solution skI1788</a> to find how to disable only the logging of this security enhancement to the Log Viewer
Tim
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Mike
Carroll
Sent: Friday, July 20, 2001 7:58 AM
To:
'nbt41'
Cc:
'[EMAIL PROTECTED]'
Subject: RE: [FW1]
Windows Terminal Server through Secure Remote VPN
problems
FYI: I'm on the same release, it effects both Win terminal server and UNIX X windows the same way. Checkpoint has admitted a bug in SP4 to us.Will you please let me know if you get a solution that works and I'll do the same for you.Thanks,Mike Carroll-----Original Message-----
From: nbt41 [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 14, 2001 2:41 AM
To: Subject: [FW1] Windows Terminal Server through Secure Remote VPN problemsI am having performance and/or communication issues with Windows Terminal Server over Secure Remote 4.1 SP4 3des build 4185Users connect the Secure Remote Client, connect to the Terminal Server, and do their work. Within a minute to 3, the sessions start randomly pausing screen transfers, or just gives an error message that "The Windows Terminal Server has ended the Connection" like a communication timeout.This work properly through the Lan only, or Dial-up behind the FW.The FW is VPN-1 4.1 sp-3 on Nokia IP330 IPSO 3.3-FCS3I have seen WTS running through this configuration elsewhere, but this one has me stumped. I did not find anything in the Nokia or Checkpoint Knowledge Bases.Any assistance will be greatly appreciated.Tim
******************************************************************
This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have
received this message in error, please notify the sender and
delete all copies from your system. Any other use, retention,
dissemination, forwarding, printing or copying of this e-mail is
strictly prohibited.
******************************************************************
