Check Point Troubleshooting
From The sin within
SIC errors when trying to connect to the Management Server using Smart Dashboard
If you do a fresh install of NGX Management Server (and if the case, Enforcement Module) on a RHEL 3.0 box and after that you apply the latest HFA (HFA_02 at the time of this writing) without first connecting to the Management Server and instaling at least a Security Policy Rule and the fwm.elg file in $FWDIR/log says something like the sample output below:
[FWM 1252 3076384128]@fw-1.domain.com[1 Feb 17:33:01] opsec_new_auth_conn_to_server: conn from 10.255.255.2 to entity cpmi_server (0xb6dcc88) failed (313) SIC Error for cpmi: authentication methods are not initialized
you have to run the following command on the management server. Note: The fwm sic_reset command will destroy ALL user certificates and they all will have to be re-issued (note by Ray sixsigma44 [at] hotmail.com)
fwm sic_reset
to clear the current contents of the ICA and to reinitialize it:
cpconfig
and choose option 8 from the menu and say yes when it asks you to initialize the ICA
Restoring a failed VSX NGX cluster member
If by any chance a cluster member from a VSX NGX cluster fails, the restore procedure is as follows:
- do a clean install of SecurePlatform on the failed member (after you repaired it)
- make sure that at least the interface that has communication with the SmartCenter Server is configured correctly
- run cpconfig on the member, select CPHA component to be installed (and also SecureXL if you have the license for it)
- enter the activation key and leave it like that
- log into the SmartCenter Server (here I assume it runs on Linux)
- from the shell, as root, issue vsx_util reconfigure command
- follow the onscreen instruction for the SmartCenter Server IP address, username and password
- when asked what VSX gateway you want to restore, type the IP address of the newly restored member
- enter the activation key when asked for it (it's the same as the one you typed earlier on the VSX member)
- wait as the VSX cluster member is being restored and after is says it's finnished, log into the VSX member and issue reboot
- after the member is rebooted, log into it and check the HighAvailability using the cphaprob state command
Importing configuration with multiple policy revisions
If by any chance you try do do an upgrade_import from an archive that contains many revisions (more than 10 let's say) it's very possible that the import will fail. In this case it's adviseable to follow the steps below:
- do an upgrade_export with the full config
- logon to the smartdashboard and delete all the previous revisions
- do another upgrade_export with the now lesser revisions in it
- run the upgrade_import on the new target machine
- copy the archive with all the revisions on the new machine
- untar and ungzip it, and copy the revisions directory over the newly imported configuration
For some reason, the checkpoint upgrade script times out when importing many revisions.
"Infinite" timeout for a service
If for some reason you need to have a TCP or UDP service have a timeout longer than the max you can set in SmartDashboard, then you need to use dbedit in the following way:
infinte timeout for a service:
modify services <service name> timeout 2147483647 update services <service name>
Although not quite infinite timeout, but 16 years it's alot of time :)
Clearing the lichosts entries
In case your firewall starts giving messages such as: "too many internal hosts detected", you can clear the lichosts table with the following command:
fw tab -t hosts_table -x
upgrade_import fails on a new machine
If upgrade import fails to import files from NGX R60 or higher to NGX R65 on a new machine, please make sure that the machine has a network link on all interfaces (can be done with a standalone switch or crossover cables). It's the only way upgrade_import will work, otherwise will exit with the following error "Failed to read the configuration of the local machine".
fw monitor
When you have a Check Point firewall and you want to trace how packets flow through the kernel you must use the fw monitor utility to dump packets. tcpdump can also work but it cannot actually show where a packet has been dropped or modified inside the firewall kernel.
In this example I will discuss on how you can trace a FTP session from a host behind NAT to FTP server somewhere in the internet.
The network topology in this case is as follows:
The following will be asummed:
Client IP address is 192.168.1.211, firewall internal IP address is 192.168.1.200, firewall external IP address is 195.234.177.34, FTP server IP address is 193.47.162.10
In order to monitor all communications between the client and the server, the following monitor filter will be used:
fw monitor -e "accept ((src=192.168.1.211 , dst=193.47.162.10) or (src=193.47.162.10, dst=102.168.1.211));" -o example_out.pcap
The monitor filter will capture all accepted traffic between the client and the server.
The FTP session was the following:
# ftp cyclops.imacandi.net Connected to cyclops.imacandi.net. 220---------- Welcome to Pure-FTPd [privsep] [TLS] ---------- 220-You are user number 1 of 50 allowed. 220-Local time is now 14:42. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. 500 This security scheme is not implemented 500 This security scheme is not implemented KERBEROS_V4 rejected as an authentication type Name (cyclops.imacandi.net:root): test 331 User test OK. Password required Password: 230-User test has group access to: test 230 OK. Current directory is /home/test Remote system type is UNIX. Using binary mode to transfer files. ftp> dir 227 Entering Passive Mode (193,47,162,10,242,23) 150 Accepted data connection 226-Options: -l 226 0 matches total ftp> quit 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout.
After the session ended, type Control-C to stop capturing the packets.
To see what happened and how packets are being modified by the firewall to accomodate NAT between the client and the server, copy the example_out.pcap resulted file to a machine where you have a very recent copy of Wireshark.
Fire up Wireshark and before loading the file, make the following adjustments:
Edit -> Preferences -> Protocols -> Ethernet -> Attempt to interpret as Firewall-1 monitor file
Edit -> Preferences -> User interface -> Columns -> New -> FW-1 monitor if/direction
Load the file in Wireshark and you can see how packets have been modified by the firewall.
In FW1 monitor you can see the direction of the packets. In Check Point firewall-1, there are four big states where the packet might be in the firewall (basic information):
- on the inbound interface before the Virtual Machine (pre-inbound)
- on the inbound interface after the Virtual Machine (post-inbound)
- on the outbound interface before the Virtual Machine (pre-outbound)
- on the outbound interface after the Virtual Machine (post-outbound)
You might see duplicates in Wireshark, but this is because the same packet is being captured more than once as it passes through the firewall chains.
