Its always good to ask your partner first, but what if you dont have one / they are not responding properly?? - Checkpoint - Policy Synchronisation

How you will update the changes happened when you were out of home...

I would say its always good* to ask your better half .. Dont worry if they are not reponding / you dont have one, its temporary,,,!!! You can ask someone you trust (in Checkpoint its SCS)....

The same thing is happening when your cluster member returns/recovers in clustered environment of checkpoint..

When a failed cluster member recovers, it will first try to take a policy from one of the other cluster members. The assumption is that the other cluster members have a more up to date policy. If this does not succeed, it compares its own local policy to the policy on the SmartCenter server. If the policy on the SmartCenter server is more up to date than the one on the cluster member, the policy on the SmartCenter server will be retrieved. If the cluster member does not have a local policy, it retrieves one from the SmartCenter server. This ensures that all cluster members use the same policy at any given moment.

*Applicable for only who trust their partner :-p

Checkpoint : fw ctl pstat - Thanks Shanawazzzzz

Yeas.... I remember his name, "Shanawaz", asked me a bloody question (at least for me that time) .. What is the command “fw ctl pstat” used for.. I was clarifying the question by asking him fw ctl p???? what.. (As if am another PhoneBOY)

Literally he was laughing at me in the video conferencing…. Ofcoz I was thinking what to laugh….. !!! In a way I was happy, at least he was laughing at me just in front. Thank God…. that laugh ended up with my CCSA Certification.. of coz they told me a sorry at the end of our discussion.. haha .. Nothing new... as am in TRANS of another "Sorry"..

Now what is fw ctl pstat??

According to me, its nothing but a fw command with which we can monitor the heath of your CP box., especially Syc Status.. Am sure that you will love this command and say thanks for CP for this……


As I have mentioned in my previous post, SYC is so important (at least this time not start but to CONTINUE)

Am taking an example to explain the same.. here we go…….

Sync:
Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
retrans reqs : 37462, received 175 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Delta Sync memory usage: currently using XX KB mem
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
Number of Pending packets currently held: 1
Packets released due to timeout: 18


Explanation:

Version: new
This line must appear if synchronization is configured (versions above 4.1)

Status: Able to Send/Receive sync packets
If sync is unable to either send or receive packets, there is a problem

Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
TOTAL number of sync packets is non-zero and increasing
RETRANS REQS may increase under load

Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
QUEUED value never decreases - A non-zero value does not indicate a problem
DROPPED BY NET number may indicate network congestion

The “dropped by net” counter is incremented when the cluster member receives a sync packet with a sequence number which is higher than the expected seq num. This means packets with lower seq where lost somewhere along the way, and we need to find out where.

retrans reqs : 37462, received 175 acks
RETRANS REQS growing very fast may indicate that the load is becoming too high

retrans reqs for illegal seq : 0
May indicate a sync problem

dropped updates as a result of sync overload: 0
In a heavily loaded system, the cluster member may drop synchronization updates sent from another cluster member

Delta Sync memory usage: currently using XX KB mem
This statistic only appears for a non-zero value.
It requires memory only while full sync is occurring at other times, Delta sync requires no memory

Callback statistics: handled 138 cb, average delay : 2, max delay : 34
This statistic only appears for a non-zero value.
AVERAGE DELAY should be 1-5 packets, otherwise indicates an overload of sync traffic

Number of Pending packets currently held: 1
This statistic only appears for a non-zero value.

Packets released due to timeout: 18
This statistic only appears for a non-zero value.
If the it is large (more than 100 pending packets), and the "Number of Pending packets currently held" is small, you should take action to reduce the number of pending packets.
To tackle this problem, try google "Reducing the Number of Pending Packets".


Hey.. Now who is shanawaz….!!!

He was my interviewer (Not revealing his company), Anyway.. Thanks Dude for asking me that….

Avoid Breakup... By Any Means : CheckPoint : Check Firewalls in Sync

Every "TRUE" Relation needs syncronisation..

Most of the relations are breaking up just because of lack of Communication, May be a Sync Problem..

The same problem which we face/faced in normal life can happen in a clustered environment, will lead into misbehaviour in cluster node... So before the "BreakUP" happens try the following in case of checkpoint... However am not good to give a similar solution in real LIFE...

How can I check that my Checkpoint Cluster is in Sync ?

In order to ensure that the State Tables of all your nodes within your Checkpoint Cluster are syncronised you will need to check the #VALS of your State Table summary on each node.

You may find that these figures aren`t identical but this is just down to the delay/latancy in which occurs between State Syncronisations. You should only be concerned if the values are hunreds or even thousands out.

The best way to view the State Table summaries (on SPLAT based firewalls) is to run the command watch 'fw tab -t connections -s'.

Check the State Tables on both nodes, checking for the #VAL totals. It should be somewhat same.. Linearly same.. :-)

So whenever possible, check SYNC Regularly to avoid BREAKUP....

SPLAT - Forgot Standard Password

SecurePlatform Administrator password (Standard mode) lost Cannot reboot SecurePlatform to Standard mode ??

Note: Following steps are not used for recovering "Expert Password"

Solution

Maintenance mode should be used in rare system emergencies, such as when there is a problem rebooting the system, or the standard Administrator password is lost.

To reboot in this mode:

1) Select “SecurePlatform with Application Intelligence [Maintenance Mode]” at the boot-loader screen, after SecurePlatform reboots.

2) Enter Expert password.

The Maintenance Mode boot option in SecurePlatform is known on UNIX systems as “single-user mode”. In this mode, SecurePlatform boots to runlevel 1. The local file systems will be mounted, but the network will not be activated. The SecurePlatform Administrator can have an usable system-maintenance shell.

In Maintenance mode, the Administrator password can be reset as follows:

1) At the bash shell prompt, type "passwd ":

sh-2.05#passwd newadmin (The name 'newadmin' is an example).
Changing password for user newadmin
New UNIX password:
Retype new UNIX password:

The message "passwd: all authentication tokens updated successfully" appears.

2) After the new Administrator password is reset, reboot the SecurePlatform machine (as follows), and log in to Standard mode using the new password:

sh-2.05#reboot

3) When the boot-loader menu appears, select the default option.

4) Enter Administrator name and new password to log in to Standard mode.

Finding Smartcenter Server - from Gateway

It will be easy for you when you troubleshoot / isolate issues, ofcourse you will be knowing your object name of your smartcenter server in small deployments, but what about big deployements,

Attimes we may need to issue "fw fetch [SCSobjectname]" from your gateway..

how we can find the SCS (SmartCenter Server) object name from gateway..

Here is the magic..

go to gateway and issue

more $FWDIR/conf/masters

You will find the policy server, logserver and alert server.. Happy???

Checkpoint Important Ports

VPN-1 binds to some well-known ports and a few not-so well known ports. This document will explain what ports these are, what they are used for, and, if applicable, how to disable them.

Various parts of FireWall-1 bind to various ports on the system. Typically, they intercept connections traversing through the firewall, but in order for this to work correctly, they must bind to their own port and listen. In general, the services bound to these ports do not pose any sort of security risk. If no policy is in place or the policy permits access to these ports inadvertenly, the processes themselves are smart enough to reject direct requests to these ports. In the case of the SAM and LEA ports (see below), these ports require authentication in much the same way that remote management does, so it is not believed to be a security risk.

TCP Port 256 is used for three important things:

Exchange of CA and DH keys in FWZ and SKIP encryption between two FireWall-1 Management Consoles

SecuRemote build 4005 and earlier uses this port to fetch the network topology and encryption keys from a FireWall-1 Management Console

When instaling a policy, the management console uses this port to push the policy to the remote firewall.

TCP Port 257 (FW1_log) is used for logging purposes.

TCP Port 258 is used by the fwpolicy remote GUI. FireWall-1 will only listen to this port on a management console.

TCP Port 259 is used for Client Authentication via telnet. FireWall-1 will only listen to this port on a firewall module.

UDP Port 259 is used in FWZ encryption to manage the encrypted session (SecuRemote and FireWall-1 to FireWall-1 VPNs).

UDP Port 260 and UDP Port 161 are used for the SNMP daemon that Check Point FireWall-1 Provides.

TCP Port 262 is used by netsod, which is the Single Sign-on Daemon. This can be disabled by commenting out the line that contains netsod in $FWDIR/conf/fwauthd.conf.

TCP Port 264 is used for Secure Client (SecuRemote) build 4100 and later to fetch network topology and encryption keys from a FireWall-1 Management Console. FireWall-1 will only listen to this port on a management console.

UDP Port 500 is used for ISAKMP key exchange between firewalls or between a firewall and a host running Secure Client. FireWall-1 will only listen to this port on a firewall module.

TCP Port 900 is used by FireWall-1's HTTP Client Authentication mechanism. This can be disabled by commenting the appropriate line in $FWDIR/bin/fwauthd.conf.

TCP Port 4532 is used for the Session Auth agent, asessiond.

TCP Ports above 1024, other than the ones listed below, are generally any Security Servers that are active. The actual ports used by these servers will vary. 1024 is the lowest & 65535 is the highest port a Security Server process will use for a connection. If you wish to minimize the number of ports listening, comment out the appropriate lines from $FWDIR/conf/fwauthd.conf. Note that if you disable a security server in this fashion, you can not use its capabilities (like content security or authentication), so make sure you only do it for the security servers you know you are not using.

TCP Port 18181 is used for CVP (Content Vectoring Protocol, for anti-virus scanning). FireWall-1 will not listen on this port.

TCP Port 18182 is used for UFP (URL Filtering Protocol, for WebSense and the like). FireWall-1 will not listen on this port.

TCP Port 18183 is used for SAM (Suspicious Activity Monitoring, for intrusion detection). If you do not use these features, you can comment out the appropriate lines in $FWDIR/conf/fwopsec.conf.

TCP Port 18184 is used for Log Export API (lea). If you do not use these features, you can comment out the appropriate lines in $FWDIR/conf/fwopsec.conf.

TCP Port 18186 (FW1_omi-sic) is used for Secure Internal Communications (SIC) between OPSEC certified products and a NG FireWall module.

TCP Port 18190 (CPMI) is used by the FireWall Management process (FWM) to listen for NG Management Clients attempting to connect to the management module.

TCP Port 18191 (CPD) is used by the CPD process for communications such as policy installation, certificate revocation, and status queries.

TCP Port 18192 (CPD_amon) is used by the CPD process FireWall Application Monitoring.

TCP Port 18196 is used for CPEPS which is part of User Monitor.

TCP Port 18207 is used by polsrvd, which is the Single Sign-on Daemon. This can be disabled by commenting out the line that contains polsrvd in $FWDIR/conf/fwauthd.conf.

TCP Port 18210 (FW1_ica_pull): The CPD process, on the management module, is listening on TCP port 18210 for certificates to be "pulled" by a FireWall module from a management module.

TCP Port 18211 (FW1_ica_push): The Check Point Daemon (CPD) process, running on the FireWall module, listens on TCP port 18211 for certificate creation and for the "push" of the certificate to the FireWall module from the management module.

Should you make any changes above, the 'fwd' process will need to be restarted as follows:

nokia[admin]# fw kill fwd

nokia[admin]# fwd `cat $FWDIR/conf/masters`

Change Date in Linux

Login to Linux box as root and enter root's password:
[me@mybox me]$ su
password:

Check the current date and time of the Linux box by entering:
[root@mybox me]# date
Linux yields the current settings:

[root@mybox me]# Wed Apr 7 12:03:45 EDT 2004
Change the current time and date of the Linux box by entering:
[root@mybox me]# date 040713032004
would change the time and yield:
[root@mybox me]$ Wed Apr 7 13:03:00 EDT 2004


====================================================


One more option:

Linux Set Date

Use the following syntax to set new data and time:date set="STRING"

For example, set new data to 2 Oct 2006 18:00:00, type the following command as
root user:# date -s "2 OCT 2006 18:00:00"

CheckPoint Splat - Setting up SCP

I found this article in internet (Following are not my scripts), am just copy pasting.. :) Nothing but for easyness to access..

This article is intended to help users setup SCP (SecureCopy) on their SPLAT gateways. This is the secure and preferred method of file transfers to and from gateways, as opposed to unsecured FTP. I use putty for SSH and WinSCP for SCP, they are both free programs, but you can use whatever clients you want.NOTE: represents the username(s) you will be adding. For example, my username will be xxxx

1) Add users to each gateway you manage
a) SSH (or console) to gateway and enter expert mode
b) At the command prompt, type: adduser
c) Enter and confirm password for this user
d) Repeat steps a though c for each user to be added
NOTE: If you are unfamiliar with operating in the vi editor, please search for a command list or call your support vendor for assistance

2) Add users to the scpusers file
a) At the command prompt, type: vi /etc/scpusers
b) Type: i <== to enter insert mode
c) Type: <== repeat adding usernames - 1 per line
d) Exit insert mode with the [ESC] key
e) Type: :wq! <== The colon enters command mode and then writes and quits the editor

f) Verify the changes at the command prompt by typing: cat /etc/scpusers <== You should see your users there, one per line

3) Change the new SCP enabled user's default shell to always be in expert mode. At the command prompt, type: chsh -s /bin/bash That's it! Using your preferred SCP software and provided you have the appropriate rules in place for your IP to access the box, you should now be able to complete secure file transfers to your SPLAT gateways.

Checkpoint Logging Issue

The following article is a list of steps one should go through when troubleshooting logging related issues in a distributed setup.

1. Ensure that you have not run out of disk space on the hard disk that the logs are being sent to. If this is the case, delete or move the logs to an external storage device.

2. Is there communication between the MS and the Module? Test using ping to the MS from the module and then from the Module to the MS (your rules must allow for this). If this fails, and your rules allow for this, then it is most likely a routing issue.

3. Check to see if the fw.log file is growing on the module. It should be if the logs are not going to the MS. From the console run these commands:

cd $FWDIR/log

ls -la

ls -la

Verify that the fw.log file is increasing. If it is increasing then the modules are logging locally instead of forwarding the traffic to the MS. This could be a connectivity issue, or it could be the way the logging is setup. Check the FW object to ensure it is setup to send logs to the MS.


4. Can you fetch a policy? Verify that you can fetch using the hostname and IP address. If this fails then you probably have a SIC issue. To test this run the following commands:

fw fetch hostname_of_MS

fw fetch IP_Addr_of_MS (fetch by IP address also to ensure it is not a DNS issue)

5. Check the masters file. The hostname or IP address of the management station should be listed in there. To check this run the following commands:

cd $FWDIR/conf

cat masters

It should be look like this:

[Policy]

hostname_of_MS

[Log]

hostname_of_MS

[Alert]

hostname_of_MS

6. Run tcpdumps on the module, listening for port 257 on the interface facing the MS, to see if it is attempting to send logs. To check this run the following command:

tcpdump -i eth-facing-MS port 257 (use the Ctrl+C to break out of the dump)

You should see traffic leaving the FW and heading to the IP address of the MS.

You should also see traffic coming back from the MS.


7. The log file may have gotten corrupt. Run a log switch on the MS and reboot the MS to create a new log file. If logswitch does not work, move all contents of the log directory (do not move the directory itself) to a temp folder outside of the log directory. Reboot and see if the logs start again.

8. Delete the $FWDIR/log files and $FWDIR/state directory files on the module; reboot the module.

Reboot and see if the logs start again.

9. Look to see if there is a listening port for logging. Run the following command on the MS and the module:

netstat -na

You should see the *.257 LISTEN for logging connections. You should also see the IP address of the MS :257 associated with the IP address of each module, and showing an ESTABLISHED connection.

10. Check the log settings for the FW object and make sure the 'Log Server' is set to the MS that should be receiving the logs. This is usually done by default, but may have been changed by a user.


If after going through these steps you are still experiencing logging issues, please open a ticket with Corresponding TAC for further troubleshooting and ofcoz try your way with help of our all time Gaint Mr. Google.. :-)

Checkpoint Troubleshooting - Debugging

Checkpoint Common debugging


Kernel debugging

Usage

% fw ctl debug -buf [buffer size]
% fw ctl debug [-x] [-m ] [+|-]
% fw ctl kdebug –f >

To disable the Kernel debugging, execute:
% fw ctl debug –buf 0
% fw ctl debug x
Common Syntax
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop ld packet if
% fw ctl kdebug –f >

The ld option may cause high CPU usage. It is advised to use it for short session debugging
only.
To execute the kernel you can also use fw ctl zdebug to allocate the buffer (where the
buffer can only be 1024).

% fw ctl zdebug
% fw ctl kdebug -f >

TDERROR_ALL_ALL=
CPD is treated differently from the other User Mode processes and will be executed
differently

Debugging CPD

CPD is a high in the hierarchichal chain and helps to execute many services, such as Secure
Internal Communcation (SIC), Licensing and status report.
For CPD debug, execute: % cpd_admin debug on TDERROR_ALL_ALL=5
The debug file is located under $CPDIR/log/cpd.elg
To stop the CPD debug, execute: % cpd_admin debug off TDERROR_ALL_ALL=1

Debugging FWM

The FWM process is responsible for the execution of the database activities of the
SmartCenter server. It is; therefore, responsible for Policy installation, Management High
Availability (HA) Synchronization, saving the Policy, Database Read/Write action, Log
Display, etc.

For FWM debug, execute:

% fw debug fwm on TDERROR_ALL_ALL=5
% fw debug fwm on OPSEC_DEBUG_LEVEL=9
The debug file is located under $FWDIR/log/fwm.elg
To stop the FWM debug, execute:
% fw debug fwm off TDERROR_ALL_ALL=1
% fw debug fwm off OPSEC_DEBUG_LEVEL=1

Debugging FWD

The FWD process is responsible for logging. It is executed in relation to logging, Security
Servers and communication with OPSEC applications.
For FWD debug, execute: % fw debug fwd debug on TDERROR_ALL_ALL=5
The debug file is located under $FWDIR/log/fwd.elg
To stop the FWD debug, execute: % fw debug fwd off TDERROR_ALL_ALL=1

FireWall Monitor Network Capturing

The FireWall Monitor is responsible for packet flow analysis.
To execute: % fw monitor –e “accept;” –o

Security Server debugging

Debugging User Authentication

Usage

Debugging is done on the service itself (in.ahttpd, in.atelnetd, in.aftpd etc.)
% fw debug on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahttpd.elg* or $FWDIR/log/aftpd.elg* or
$FWDIR/log/atelnetd.elg* depending on the service that you are debugging.

HTTP Security Server

For HTTP Security Server debug, execute:
% fw debug in.ahttpd on TDERROR_ALL_ALL=5
% fw debug in.ahttpd on OPSEC_DEBUG_LEVEL=3
The debug file is located under: $FWDIR/log/ahttpd.elg*
If more than one HTTP Security Server process is running, execute:
% fw kill fwd
% setenv TDERROR_ALL_ALL=5
% setenv OPSEC_DEBUG_LEVEL=3
% fwd –d >&

&
Note - The setenv commands used above correlate with Unix environment. For other platforms, execute
the relevant command.

SMTP Security Server

To debug the SMTP Security Server, execute:
% fw debug in.asmtpd on TDERROR_ALL_ALL=5.
The debug file is located under $FWDIR/log/asmtpd.elg*
To debug the mdq, execute the following commands:
% fw debug mdq on TDERROR_ALL_ALL=5.
The debug file is located under $FWDIR/log/mdq.elg*

Debugging Session Authentication

To debug Session Authentication, execute:
% fw debug in.asessiond on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/asessiond.elg*

Debugging Client Authentication

For HTTP to port 900, execute:
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 5
% fw debug in.ahclientd on TDERROR_ALL_ALL=5
For Telnet to port 259, execute:
% fw debug in.aclientd on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahclientd.elg*

VPN debugging

On the Module

To start, execute:

% vpn debug trunc.
This command is equivalent to these two commands: vpn debug on, vpn debug ikeon.
To stop, execute:
% vpn debug off; vpn debug ikeoff.
The debug file is located under $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg

FireWall Monitor for packet flow analysis
% fw monitor –e “accept;” –o

Client Side

The Client side can only run under the root directory (C :/…)
To start, execute:
% sc debug on
To stop, execute:
% sc debug off
The debug file is located under sr_service_tde.log, under the SecuRemote installation
folder, for example: C:\Program files\CheckPoint\SecuRemote.
For packet capture from the Client side, execute:
% srfw monitor -e "accept;" -o

Provider-1 debugging

MDS Level

Most of the MDS actions are performed by the MDS’s fwm process, execute:
% mdsenv
% fw debug mds on TDERROR_ALL_ALL=5
% fw debug mds on OPSEC_DEBUG_LEVEL=9
The debug file is located under /opt/CPsuit-R60/fw1/log/mds.elg
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 6

ClusterXL debugging

For ClusterXL debugging for Clustering, Synchronization, High Availability, Fail-over,
execute:
% cphaprob state
% cphaprob -ia list
% cphaprob -a if
% fw ctl pstat
Kernel debug for packet filter analysis
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop packet if sync
% fw ctl debug –m cluster all
% fw ctl kdebug –f >

Connectra debugging

For Connectra debugging issues relating to Web, files, Webmail, OWA, iNotes, Citrix, the
httpd process should be debugged:
To turn the debug on, under: $CVPNDIR/conf/httpd.conf change LogLevel to debug.
You should execute the process: cvpnrestart
The output is located at: $CVPNDIR/log/httpd.log
For debugging authentication issues, execute: Debug cvpnd
Run: cvpnd_admin debugset TDERROR_ALL_ALL=5
To start, execute: % cvpnrestart
The debug file is located under $CVPNDIR/log/cvpnd.elg
To stop debug, run:
% cvpnd_admin debug off

FireWall-1 GX debugging

Kernel debug for packet filter analysis
Check Point Troubleshooting and Debugging Tools for Faster Resolution.

% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop ld packet filter
% fw ctl kdebug –T –f >

InterSpect debugging

Kernel debug for packet filter analysis
% fw ctl debug –buf 12288
% fw ctl debug –m fw conn drop packet if
% fw ctl kdebug –f >

Additional kernel debug options for InterSpect:
• portscan, for port scanning issues
• dynlog, for dynamic logging
• mail, for mail security in the kernel
• sam, for SAM IP address blocking
Kernel debug for Packet Drop, execute:
% fw ctl zdebug + drop
Kernel debug for SmartDefense TCP Streaming, execute:
% fw ctl zdebug + tcpstr + cifs
Kernel debug for Dynamic list (SAM), execute:
% fw tab -t sam_requests_v2 -u -f
% fw samp

SNX – SSL Network Extender debugging

Server Side

% vpn debug trunc
% vpn debug on slim=5
Debug can be found at $FWDIR/log/vpnd.elg.
You should execute vpn debug on [DEBUG_TOPIC=5]. The relevant debug topics are:
proxy, rasta, rasta_protocol and slim.)

Client Side

For the service:
Type regedit at the command prompt and set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpextender\parameters\d
bg_level to 5
Open the Command Line interface window and execute:
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — January 24, 2006 8
% net stop cpextender
% net start cpextender (or kill slimsvc.exe)
The debug file is located under:
%Program Files%\CheckPoint\SSL Network Extender\slimsvc.log
For the ActiveX: (only when using ActiveX with Internet Explorer), type regedit at the
command prompt and set the following:
% set HKEY_CURRENT_USER\Software\CheckPoint\SSL Network
Extender\parameters\dbg_level to 5
The debug file is located under %APPDATA%\Check Point\extender\activex.log.
For the Applet: (when using the Applet version) SNX can be used by Microsoft JVM or by
other vendors (SUN, IBM…). To view the Java console when using Microsoft JVM you
need to check Java console enabled (requires restart) in the Internet Options Advanced tab
and restart Internet Explorer. You can also switch between the different JVMs (in case you
have two or more) in the same tab.

Further Debugging – Memory Diagnostics

The following utilities applies to all non-Windows systems supported by Check Point:
% free
% vmstat 2 10
% sar –k 2 10
% top
% ps -auxw
% cat /proc/meminfo
% cat /proc/slabinfo

Routing information

% arp –a
% netstat –ie

TCP Flags

There are 6 TCP Flags.

Connection Establishment
==========================
1.SYN --- Client to Server
2. SYN ACK ---Server to Client
3. ACK--------- Client to Server

Connection Established

Termination
+++++++++++++

Termination requires four packets as TCP is full duplex, connection should be terminated from both the ends.

1. FIN ACK - Client to Server
2. ACK - Server to Client
3. FIN ACK - Server to Client
4. ACK -- Client to Server

Pls note that this is a Graceful termination where "RST" is not

More info can be available @ http://support.microsoft.com/kb/172983