Packet Flow Through the Check Point's INSPECT Engine

Internal user attempting to connect to the Internet through the firewall.

Physical layer - ingress interface
Data Link Layer/Ethernet
Inspect Driver [inspect Engine]
Network Layer/IP Routing
Inspect Driver
Data Link Layer/Ethernet
Physical layer - egress interface

Opening an SSH connection to the firewall itself

Physical layer - ingress interface
Data Link Layer/Ethernet
Inspect Driver
Network Layer/IP Routing
Transport Layer/TCP connectivity
Layers 5-7/SSHD process

--------------------------------------------

Longer Version with more Functions Enabled on the FW module: 

NIC hardware
-The network card receives electrical signalling from the link partner.

NIC driver
-Sanity checks
-The NIC hardware decodes the signal and passes it to the operating system's NIC driver via the PCI bus
-The frame is converted to an mbuf entry and the frame headers are stored for later use.
-NIC driver hands off the data to the operating system's mbuf memory space

Operating system IP protocol stack
-The OS performs sanity checks on the packet
-Hand off to SXL if enabled, or to Firewall Kernel if not

SecureXL (if enabled)
-SXL lookup is performed, if it matches, bypass the firewall kernel and proceed with (Operating system IP protocol stack, outbound side)

Firewall Kernel (inbound processing)
-FW Monitor starts here
-Connection state lookups, some protocol inspection, rulebase processing, antispoofing lookups etc
-Processing order can be seen via fw ctl chain
-Bypass complex inspection if not needed

Complex protocol inspection (AV is an example)
-Leave the kernel and process under userland.
-Enters back at this same stage if the traffic passed

(inbound processing stops here)

Firewall Kernel (outbound processing starts here)
-Route lookup
-Check Point sanity checks etc
-FW Monitor ends here
-Pass to operating system

Operating system IP protocol stack
-The OS performs sanity checks on the packet
-Pass the mbuf to the NIC driver for the appropriate outbound interface

NIC driver
-Tag the packet as an ethernet frame by adding MAC addresses for source and destination

NIC hardware
-The NIC hardware encodes the signal and transmits it via wire

----------

Between all the steps there are queues. These queues accumulate packets and on intervals flush them to the next step. All of this happens very very quickly in small CPU time slices.

The INSPECT engine itself is more to do specifically with protocol inspection rather than all of the other steps. INSPECT runs traffic against definitions, if the definitions match it usually means that it hit a protection and the appropriate action is to (drop, log) the traffic.

There are a LOT more steps in the sequence I posted above, for example any kind of VPN traffic gets different processing, which is done in chains. The chains look at the traffic type and determine the next step via a finite state machine.

CLusterXL or Nokia VRRP ? Which one should I use ? What is the difference?

You can use Nokia VRRP or Nokia Clustering or Checkpoint ClusterXL.

ClusterXL requires licence.
ClusterXL is for SPLAT/Linux/UNIX ONLY.

With the Nokias you dont have to use ClusterXL just VRRP or IP Clustering.
If you use Nokia VRRP you can have HA but the other box will act as HOT/STANDBY i.e ACTIVE/PASSIVE
.
If you use Nokia cluster then you can configure the boxes in Active-Active or Active-Passive mode.
On the Nokia's you are only using ClusterXL for the Check Point synchronization NOT for the actual FAILOVER information.

with Nokia Active/active clustering, you will need two state networks. One for Checkpoint state (fw) and one for Nokia state (ipso). It is not recommended to use the same network for both states.

With Nokia's you should not tick ClusterXL. You should configure under 3rd Party and select Nokia VRRP is if you want an active-passive or IPSO Clustering if running IPSO Cluster and an active-active environment.

Do not use a crossover cable between the two firewalls for state networks. If one firewall goes down the other will see that interface go down and they both try to leave the cluster.

If you have a Cisco switch between the firewalls using Vlans, make sure multicast is TURNED ON on the switch.  You can switch the Checkpoint state network to broadcast but not the Nokia state network. some Cisco switches would not listen to a gratuitous ARP from a VIP address.A simple static ARP entry i.e. MAC address of the firewalls VIP in to the switch ARP table will do the trick.

Check this link goo.gl/eua2R for CISCO swithes + multicast issues.

You setup the Nokia state network in Cluster voyager. You setup the checkpoint state network in smart dashboard.

(I think It is possible that IPSO 4.X allows you to switch from the default multicast to broadcast on the Nokia state network.) to be verfied.

Which Remote Access Client With Which Gateway?

The recent Remote Access Clients E75.10 release  actually released three separate clients:

* Endpoint Security VPN (a.k.a. replacement for Secure Client)
* Check Point Mobile for Windows (essentially Secure Client without desktop firewall)
* SecuRemote (with 64-bit support) 

All three clients are installed from the same MSI file.

Not every client is compatible with every version of Security Gateway/VSX/UTM-1 EDGE device. Currently none of these clients work with the SG80 device, but will be in the next software update.

The following is a definitive list of what will work with what and what licenses you will need. 

Endpoint Security VPN (a.k.a. the next generation of Secure Client) is supported with the following security gateways (available today, unless otherwise noted):

* R65.70 + hotfix from sk61286
* R70.40 + hotfix from sk61286
* R71.30
* R75 
* VSX R67.10 (to be released)
* Sofaware firmware 8.2.33 

Endpoint Security VPN requires an Endpoint Container + Remote Access Blade to cover each user. Licensing is per-seat (i.e. each user that could connect with Endpoint Security VPN must be licensed).

Check Point Mobile for Windows is supported with the following security gateways –

* R75 + hotfix from sk60940
* Sofaware firmware 8.2.33

Check Point Mobile for Windows requires Mobile Access Blade licenses (CPSB-MOB), which are licensed by number of concurrent users that connect. It will also work with all gateways that support Endpoint Security VPN if you have a Endpoint Container + Remote Access Blade license to cover the user. 

SecuRemote (for Windows 64-bit) is supported with the following security gateways -

* R65.70 + hotfix from sk61286
* R70.40 + hotfix from sk61286
* R71.30
* R75.10 (to be released)
* VSX R67.10 (to be released)
* Sofaware firmware 8.3 (to be released)

SecuRemote requires an IPSec VPN Blade license and has no per-user limits. It does not require a special license like it did in NGX and earlier.


credit:Phoneboy

Check Point SecureXL Mechanism

Traffic acceleration

When SecureXL is enabled, all traffic should be accelerated, except traffic that matches the following conditions:

• The first packets of any new TCP session, unless a "template" exists.
• The first packet of any new UDP session.
• All traffic that matches a service that uses a Resource.
• Certain traffic that matches a service that is inspected by a SmartDefence or Web Intelligence feature. For example, traffic on which SSH protections are activated is not accelerated. For more details, refer to sk42401: Factors that adversely affect performance in SecureXL.
• All traffic that is supposed to be dropped or rejected, according to the rule base.
• All traffic that matches a rule, whose source or destination is the Gateway itself.
• All traffic that matches a rule with a Security Server.
• All traffic that matches a rule with User Authentication or Session Authentication.
• Non-TCP/UDP/GRE/ESP traffic.
• All multicast traffic.
• All fragmented traffic.
• All traffic with IP options.
• RST packets, when the "Spoofed Reset Protection" feature is activated.
• When using ClusterXL, with Sticky Decision Function.
• Traffic that violates stateful inspection paradigm, or that is suspected to be spoofed.
• IPv6 traffic

Connection establishment acceleration ("templates" mechanism)

In order to enhance connection establishment acceleration, a mechanism attempts to "group together" all connections that match a particular service and whose sole discriminating element is the source port. This type of "grouping" enables even the very first packets of a TCP handshake to be accelerated. This is very useful on short connections, in which the percentage of TCP handshake traffic is very high.

The very first packets of the first connection on the same service, will be forwarded to the security gateway, which will then create a "template" of the connection and notify the SecureXL device. Any subsequent TCP establishments on the same service (where only the source port is different) will already be accelerated (as well as any other traffic, of course).

There are several conditions that will prevent a template from being created:

• All connections that cannot be discriminated ONLY by the source port cannot be templated.
• NATed traffic cannot be templated.
• VPN traffic cannot be templated.
• Complex connections (FTP, H323, etc.) cannot be templated.
• Non-TCP/UDP traffic cannot be templated.
• The following rules will prevent a template from being created. All subsequent rules below it will not be templated as well, regardless of the rule. It is advised that all rules that can be templated, be placed at the top of the rule base (unless of course, this will violate other optimization considerations): 
• Rules with the following objects:
  
  • Time object
  • Port range object
  • Dynamic object
• Rule with service 'Any'
• Rule with a service that has a handler (protocol type) enabled.
• Rules with "complex" services (i.e., services that have anything specified in the "Match" field, or "Enable reply from any port" of their "Advanced" section or source port is defined).
• Rules with RPC/DCOM/DCE-RPC services.
• Rules with Client Authentication or Session Authentication.
• When SYN Defender or Small PMTU features are activated

SecureXL commands:

nokia[admin]# fwaccel on                        Enables SecureXL 

nokia[admin]# fwaccel off                        Disable SecureXL 

nokia[admin]# fwaccel stat                      Checks overall SecureXL statistics 

nokia[admin]# fwaccel ver                       Shows SecureXL/FW version 

nokia[admin]# fwaccel cfg-configure        Shows SecureXL parameters 

nokia[admin]# fwaccel stats-print            Shows SecureXL statistics 

nokia[admin]# fwaccel conns-print           Shows SecureXL’s connection table 

nokia[admin]# fwaccel templates-print    Shows SecureXL’s templates table 

nokia[admin]# fwaccel dbg-set                Sets debug flags 

nokia[admin]# fwaccel help                      Shows full details of the options 

Updated SecureXL Whitepaper

Path MTU Discovery

Nice link about MTU  http://wiki.nil.com/Path_MTU_Discovery

fw monitor

Good reference
http://www.cpug.org/check_point_resources/fw_monitor_rev1_01.pdf

Examples:

# fw monitor -m i -e 'accept host(208.44.108.136) ;'
# fw monitor -e 'accept src=216.12.145.20 ;'  packets where source ip = 216.12.145.20 
# fw monitor -e 'accept src=216.12.145.20 or dst= 216.12.145.20;'  packets where source or destination ip = 216.12.145.20
# fw monitor -e 'accept port(25) ;'  packets where destination or source port = 25
# fw monitor -e 'accept dport=80 ;'  packets where destination port = 80
#fw monitor -e 'accept sport>22 and dport>22 ; '  packets with source and destination ports greater than 22
# fw monitor -e 'accept ip_len = 1477;'  packets where their length equals exactly 1477 bytes
# fw monitor -e 'accept icmp_type=ICMP_UNREACH;'  ICMP packets of Unreachable type
# fw monitor -e 'accept from_net(216.163.137.68,24);'  packets having source IP in the network 216.163.137.0/24
# fw monitor -e 'accept from_net(216.163.137.68,24) and port(25) and dst=8.8.8.8 ;'  packets coming from network 216.163.137.0/24 that are destined to the host 8.8.8.8 and hving source or destination port = 25
# fw monitor -m i -x 40,450 -e 'accept port(80);'  incoming packets before any rules are applied also
display contents of the packet starting at 40th byte of 450 bytes length 
# fw monitor -m i -pi -ipopt_strip -e 'accept host(66.240.206.90);'  incoming packets from/to host 66.240.206.90 , insert sniffer before module named ipopt_strip 
# fw monitor -D -m i -pi -ipopt_strip -e 'accept host(66.240.206.90);'  same as above but add debug info

Performance analysis for Security Gateway R65 / R70 / R71 / R75

Good article in Check Point's SecureKnowledge which points out how to analyze the system performance. See sk33781 for details.

The article isn’t only about performance, but also gives good troubleshooting hints and explanations about values and possible errors (especially true for the memory section).

Cisco Switching Products at different layers

Cisco Systems Inc. supports a broad range of local area network (LAN) switching architecture technologies and platforms.  The general minimal requirements that the Cisco switching platforms are designed to address include the following:

• High-performance switched Ethernet, capable of delivering 100 Mbps and 1Gbps to the desktop, and 1Gbps or 10Gbps uplinks.
• Quality of Service (QoS) features permitting prioritization of delay-sensitive traffic and control over packet delay and jitter.
• Simple, highly structured, and deterministic design (Predictable – in both normal and failure recovery modes).
• Support for both IP version 4 and IP version 6 protocols.
• Fault tolerance (Redundancy for critical components and links ‑ eliminating network single-points-of-failure).
• Flexibility (Network logically partitioned at Layers 2, 3 and 4, to direct traffic flow).
• Secured through authentication, authorization and accounting (AAA) controls.
• Modular design capable of supporting new applications and network growth without requiring “fork-lift” upgrades.
• Scalability for cost-effective delivery of the smallest to the largest telecommunications rooms and campuses
• Multicast protocol support for end-to-end management and optimization of streaming content delivery.
• Switches capable of powering IP telephones (via phantom power).
• Capable of being remotely monitored and managed using network management tools, such as HP Openview.

All Cisco switches are based on a distributed hardware architecture in which the LAN switching functions are separated from the “control plane” functions of switch management by utilizing both one or more general-purpose central processing chips and port or line card application-specific integrated circuits (ASICs).
The general-purpose CPU handles network management functions, like user logins, SNMP, and maintenance operations like operating system booting.  The general-purpose processor controls the configuration of the switch platforms with a command-line interface.  The ASICs optimize packet and frame switching at the port and line card level in order to reduce inter-frame delays and increase overall system throughput.
Older Cisco switches used an operating system called CatOS, with a command-line syntax based on set and clear statements.  Newer switch use an operating system referred to as the Cisco Internetwork Operating System (IOS), which is common across both switching and routing platforms.  The older CatOS is end-of-life and end-of-sale.  Only configurations involving IOS will be shown here.  A newer switching operating system based on the Cisco next-generation Nexus platforms is called NXOS, but is nearly identical to the IOS command syntax, and most of the Cisco switch product is based on IOS.
Cisco switching utilizes recommendations for a hierarchical design in switched network infrastructures, called core, distribution, and access layers.  It is acceptable to combine the functions of the core and distribution layers in smaller switched networks, which is called a collapsed core design.  The functions of each layer are as follows:
Core layer

• Links to WAN (Internet or other wide-area network)
• Links to distribution switches
• Additional Virtual Local Area Networks (VLANs) —Used by the system for routed ports as well as WAN ports

Distribution Layer

• Server connections
• Links to downstream (closet) access switches via layer 2 or layer 3 links.
• Site services, like wireless LAN controllers
• Service VLANs—To forward traffic to the service modules, such as the client VLAN of a content switch
• Fault tolerant VLANs—For redundancy with CSM, FWSM, CSS, and so forth

Access Layer

• Client connectivity at 10/100/1000Mbps

Checkpoint VPN Encryption/Decryption behavior

Checkpoint VPN Encryption/Decryption behavior

When the firewall receives a packet, one of the first things it does, before it even goes through the rulebase, is decide whether the packet should be encrypted or not. To do this, the firewall looks at its encryption domain and the encryption domains of all of its peers. It also checks to see if the packet arrived in encrypted form already (i.e., whether it came across a VPN). The decision-making in simplified mode is really straightforward.

If the packet was not encrypted, it makes these checks:

If the source is not in a peer's encryption domain or the destination is not in ours, let it through.(clear text)
If the source is in a peer's encryption domain and the destination is in my encryption domain, then why is it unencrypted? Drop the packet with the message "Received a cleartext packet within an encrypted connection".
If the source is not in my encryption domain or the destination is not in a peer's encryption domain, don't encrypt.

If the source is in my encryption domain and the destination is in a peer's encryption domain, flag the packet to be encrypted to that peer.

If the packet was encrypted, the checks are a bit easier:

If the source is in a peer's encryption domain, and the destination is in mine, decrypt it and let it go about its merry way.

If the source is not in a peer's encryption domain, or the destination is not in my encryption domain, why was it encrypted? Drop the packet with the message "According to the policy the packet should not have been decrypted".

VPN routing makes this a little weirder in that "my" encryption domain and the "peer's" encryption domain can contain the encryption domains of other gateways. Satellite gateways see the hub's encryption domain as containing all encryption domains other than their own.
Note that the decision on whether to encrypt or not happens before any address translation. If you are translating traffic that goes across a VPN, this is why you must have the untranslated address in the encryption domain. You must also have the translated address in the encryption domain because the actual encryption proposals are sent using ranges in the encryption domain.

If you are expecting traffic to go across a VPN, and it is hitting a different rule further down in the rulebase, check your encryption domains. Chances are that the source is missing from yours or the destination is missing from your peer's.

How to use Linux DD (Data Destroyer) command

Syntax:


dd if= of= bs=skip= seek= conv=


bs = "USUALLY" some power of 2, and usually not less than 512 bytes (ie, 512, 1024, 2048, 4096, 8192, 16384, but can be any reasonable whole integer value.) 


Example:
This command will backup the existing drive


Plug the external drive into the USB port, and boot with The Knoppix live CD. Launch a terminal. :


dd if=/dev/hda of=/dev/sda bs=64k conv=notrunc,noerror



This series will make a DVD backup of hard drive partition:


dd if=/dev/hda3 of=/home/sam/backup_set_1.img bs=1M count=4430 
dd if=/dev/hda3 skip=4430 of=/home/sam/backup_set_2.img bs=1M count=4430  
dd if=/dev/hda3 skip=8860 of=/home/sam/backup_set_3.img bs=1M count=4430




This command will overwrite the drive with zeroes
dd if=/dev/zero of=/dev/sda bs=4k conv=notrunc

How to use ISO image on SPLAT to upgrade

1- df -h # command to see where you have enough space.

2- mkdir /var/temp/ISO_folder #create folder

3-cp/ftp/scp the CD image to /var/temp/ISO_folder # Transfer the file to the folder

4- mount -t iso9660 -o loop /var/temp/ISO_folder/ISO_file".iso /mnt/cdrom

5- ls /mnt/cdrom. # verify that the ISO_file".iso is listed

6- patch add #to start upgrading

Changing the HA status of the Management station from command line

1. Run the cpstop command.



2. To find out the current status, run:
   
   cpprod_util FwIsActiveManagement
   
   0 - means Standby.
   1 - means Active.



3. To set the Management station to Standby status, run:
   
   cpprod_util FwSetActiveManagement 0



4. To set the Management station to Active status, run:
   
   cpprod_util FwSetActiveManagement 1

How to troubleshoot failovers in ClusterXL

Troubleshooting the ClusterXL Failovers

To identify the root cause of the ClusterXL failovers:
In this step, we use several methods to understand what is causing the ClusterXL failovers.

• SmartView Tracker - to filter all ClusterXL messages.
• ClusterXL CLI - to understand the current status of the cluster members and the reason for that.
• Analyze the Syslog messages which were generated at the time of the failovers.

Step 1: Using SmartView Tracker:

To facilitate analysis of what happens at the time of the failover, the relevant messages should be exported to a Text file, after modifying the filter:
To export the cluster messages in SmartView Tracker:

• Go to the right-most column "Information"
• Right-click on the name of the column
• Click on "Edit filter"
• Under "Specific" choose "Contains"
• In "Text" type the word "cluster" (do not check any boxes)
• Click on "OK"
• Go to all the empty columns - "Source", "Destination", "Rule", "Curr Rule Number", "Rule Name", "Source Port", "User"
• Right-click on the name of the column
• Click on "Hide Column" (these columns will re-appear after closing and re-opening SmartView Tracker)
• Save all the Cluster messages - go to menu "File" - click on "Export..."

Troubleshooting Method:
Open the exported file you have just saved, look for the ClusterXL messages during the time of the failover and see if there are messages indicating a problem of one or more critical devices (pnotes).

Examples - if you see problems on:

• "Filter" critical device, most likely the policy was unloaded form that member, which caused the failover.
  Investigate and understand why the policy was unloaded form that member.
• "Interface Active Check" critical device, it means that on one or more interfaces, CCP traffic was not heard on the specified default time configured. This can be a result of networking issues, high latency, physical interface problems, drivers, etc.
  Try to eliminate networking issues, drivers, etc. before you change something in the ClusterXL configurations.
  Use the ClusterXL Admin Guide for further help on this topic.

Step 2: Using ClusterXL CLI:

There are several commands that can help us to see the ClusterXL status. The most useful commands while a failover took place, are the following:

• # cphaprob state
• # cphaprob -ia list
• # cphaprob -a if
• # fw ctl pstat

# cphaprob state:
The following is an example of the output of cphaprob state from Load Sharing Multicast cluster:



Cluster mode can be:

• Load Sharing (Multicast)
• Load Sharing (Unicast, a.k.a Pivot)
• High Availability New Mode (Primary Up or Active Up)
• High Availability Legacy Mode (Primary Up or Active Up)
• For 3rd-party clustering products: "Service"

The number of the member indicates the Member ID in Load Sharing mode, and the Priority in High Availability mode.
In Load Sharing configuration, all members in a fully functioning cluster should be in 'Active' state.
In High Availability configurations, only one member in a properly functioning cluster must be in 'Active' state, and the others must be in the 'Standby' state.
3d-party clustering products show 'Active'. This is because this command only reports the status of the Full Synchronization process. For Nokia VRRP, this command shows the exact state of the Firewall, but not the cluster member (for example, the member may not be working properly, but the state of the Firewall is active).
Explanations on the ClusterXL members' status:

• Active - everything is OK.
• Active Attention - problem has been detected, but the cluster member still forwarding packets, since it is the only machine in the cluster, or there are no active machines in the cluster.
• Down - one of the critical devices is having problems.
• Ready -
  • When cluster members have different versions of Check Point Security Gateway, the members with a new version have the ready state and the members with the previous version have the active state.
  • Before a cluster member becomes active, it sends a message to the rest of the cluster, and then expects to receive confirmations from the other cluster members agreeing that it will become active. In the period of time before it receives the confirmations, the machine is in the ready state.
  • When cluster members in versions R70 and higher have different number of CPU cores and/or different number of CoreXL instances, the member with higher number of CPU cores and/or higher number of CoreXL instances will stay in Ready state, until the configuration is set identical on all members.
• Standby - the member is waiting for an active machine to fail in order to start packet forwarding. Applies only in high availability mode.
• Initializing - the cluster member is booting up, and ClusterXL product is already running, but the Security Gateway is not yet ready.
• ClusterXL inactive or machine is down - Local machine cannot hear anything coming from this cluster member.

# cphaprob -ia list
When a critical device (pnote) reports a problem, the cluster member is considered to have failed. Use this command to see the status of the critical devices (pnotes).
There are a number of built-in critical devices, and the administrator can define additional critical devices. The default critical devices are:

• Interface Active Check - monitors the cluster interfaces on the cluster member
• Synchronization - monitors if Full Synchronization completed successfully.
• Filter - monitors if the Security Policy is loaded.
• cphad - monitors the ClusterXL process called 'cphamcset'.
• fwd - monitors the FireWall process called 'fwd'.

For Nokia IP Clustering, the output is the same as for ClusterXL Load Sharing.
For other 3rd-party products, this command produces no output.
Example output shows that the fwd process is down:


In these cases, check if 'fwd' process is up, using the following commands:

• # ps auxw
• # pidof fwd
• # cpwd_admin list


If it is not up and running,you need to investigate why.
Check $FWDIR/log/fwd.elg file, try to locate the reason why the fwd process crashes.
Open a case with Check Point support to keep the investigation.
# cphaprob -a if
Use this command to see state of the cluster interfaces.
The output of this command must be identical to the configuration in the cluster object Topology page.
For example:

The state of interfaces is critical to operation of ClusterXL. ClusterXL checks the number of working interfaces at boot and sets a value of 'Required interfaces' to the maximum number of 'good' interfaces seen since the last reboot. If the number of working interfaces changes and becomes less, than the 'Required interfaces', ClusterXL initiates failover from this member to other members. The same applies to 'Required secured interfaces', where only the good synchronization interfaces are counted.
For 3rd-party clustering products, except in the case of Nokia IP Clustering, cphaprob -a if should always show cluster Virtual IP addresses.
When a state of an interface is DOWN, it means that the ClusterXL on the local member is not able to receive and/or to transmit CCP packets withing pre-defined timeouts. This may happen when an interface is malfunctioning, is connected to an incorrect subnet, is unable to pick up Multicast Ethernet packets, CCP packets arrive with delay, and so on. The interface may also be able to receive, but not transmit CCP packets, in which case the status field should be checked. The displayed time is the number of seconds that have elapsed since the interface was last able to receive/transmit a CCP packet.
See: "Defining Disconnected Interfaces" section - in the ClusterXL_Admin_Guide.
# fw ctl pstat
Use this command in order to get FW-1 statistics.
When troubleshooting ClusterXL issues, use this command in order to see the Sync network status and statistics.
At the bottom of this command output, are the Sync network statistics.
If that status is in "off", you will see the 'Synchronization' critical device reporting a problem, when running the # cphaprob -i list command.
That means that the Full Sync in the cluster (when a member is booting up or the cluster is configured) did not succeed.
In these cases, refer to the following SK articles:

• Forcing Full Sync in Cluster
• Debugging Full Sync in Cluster

Step 3: Analyzing Syslog Messages:

In Linux environment, like SPLAT, go to /var/log/messages files, and search for the time of the failover.
In Solaris environments, go to /var/adm/messages and search for the time of the failover.
Look for possible issues that can cause the problem - Link on interfaces going Down, lack of resources like CPU/memory, etc.
When opening Service Request with Check Point support, please attach all these messages to the case, and specify the exact time and date this issue happened, so we can correlate the failover with the logs.

Completing the Procedure

If after following the steps in this guide the failovers are not resolved, open a Service Request with Check Point and provide the following information:

• CPinfo files from all cluster members (make sure to use the latest CPinfo utility installed per sk30567)
• CPinfo file from the MGMT server (make sure to use the latest CPinfo utility installed per sk30567)
• /var/log/messages* from ALL the cluster members --- please supply all the messages files in this directory
• $FWDIR/log/fwd.elg* from ALL the cluster members --- please send all the fwd.elg files in this directory
• $CPDIR/log/cpwd.elg* from ALL the cluster members --- please send all the cpwd.elg files in this directory
• An export of all cluster messages from SmartView Tracker (see Step 1 above)

If you need to set custom fail conditions, you can use the cphaprob command. Secureknowledge sk55081 has a good summary of the process for this. You can associate a critical device to some sort of interface or network polling script, and do whatever monitoring you require there.

Demo Fortinet devices

Links to the demo Forigate firewall, ForiAnalyzer and FortiManager open to access from anywhere . So that you can
familiarize yourself with the Management GUI look and feel.

Links for Documentation: http://docs.fortinet.com/fgt.html

NOTE: Access is read-only.

http://www.fortigate.com

Fortigate 300 :
user:demo
password: fortigate


http://www.fortianalyzer.com
ForiAnalyzer 800:
user:demo
password: fortianalyzer

http://www.fortimanager.com

FortiManager 400:
user:demo
password: fortimanager

Troubleshooting Checkpoint VPNS with IKEVIEW

sing IKEVIEW for VPN debugging

IKEVIEW is a Checkpoint Partner tool available for VPN troubleshooting purposes. It is a Windows executable that can be downloaded from Checkpoint.com. Ikeview was originally only available to Checkpoint's CSP partners however they will gladly supply you a copy of thie file if you have a licensed Checkpoint product. This file parses the IKE.elg file located on the firewall.

To use IKEVIEW for VPN troubleshooting do the following:

1. From the firewall type the following:

vpn debug ikeon

This will create the IKE.elg file located in $FWDIR/log


2. Attempt to establish the VPN tunnel. All phases of the connection will be logged to the IKE.elg file.


3. SCP the file to your local desktop.
WINSCP works great

4. Launch IKEVIEW and select File>Open. Browse to the IKE.elg file.


Understanding the IKE.elg output

All Phase I packets will either be labeled Main Mode or Aggressive Mode.

Phase II packets will be labeled QM or Quick Mode.

An arrow pointing to the left (<) indicates IPSEC packets that the Checkpoint firewall (local) receives from the remote Peer. An arrow pointing to the right (>) represent IPSEC packets that the Checkpoint firewall is sending to the remote peer.

Ikeview Phase I Main Mode exchange:

If your encryption fails in Main Mode Packet 1, then you need to check your VPN proposal (encryption/hash/lifetime).


Packet 2 ( MM Packet 2 in the trace ) is from the responder to agree on one encryption and hash algorithm


Packets 3 and 4 aren’t usually used when troubleshooting. They perform key exchanges and include a large number called a NONCE. The NONCE is a set of never before used random numbers sent to the other part, signed and returned to prove the parties identity.


Packets 5 and 6 perform the authentication between the peers. The peers IP address shows in the ID field under MM packet 5. Packet 6 shows that the peer has agreed to the proposal and has authorised the host initiating the key exchange.
If your encryption fails in Main Mode Packet 5, then you need to check the authentication - Certificates or pre-shared secrets

Phase I Main Mode example:

In the example below, we see that Phase I is failing after the first packet (Main mode Phase I takes 6 packets to complete). After the first packet (the initial proposal packet), we see that the remote peer responds with No Proposal Chosen. In this example, the remote peer rejected the local proposal of AES/SHA1 with a lifetime of 86400 seconds and the provided Preshared key.

Phase II Quick Mode exchange:

Next is Phase II - the IPSec Security Associations (SAs) are negotiated, the shared secret key material used for the SA is determined and there is an additional DH exchange. Phase II failures are generally due to a misconfigured VPN domain. Phase II occurs in 3 stages:

1. Peers exchange key material and agree encryption and integrity methods for IPSec.
2. The DH key is combined with the key material to produce the symmetrical IPSec key.
3. Symmetric IPSec keys are generated.


In IkeView under the IP address of the peer, expand Quick Mode packet 1:
> "P2 Quick Mode ==>" for outgoing or "P2 Quick Mode <==" for incoming > QM Packet 1

> Security Association

> prop1 PROTO_IPSEC_ESP

> tran1 ESP_AES (for an AES encrypted tunnel)

You should be able to see the SA life Type, Duration, Authentication Alg, Encapsulation Mode and Key length.
If your encryption fails here, it is one of the above Phase II settings that needs to be looked at.

There are two ID feilds in a QM packet. Under

> QM Packet 1

> ID

You should be able to see the initiators VPN Domain configuration including the type (ID_IPV4_ADDR_SUBNET) and data (ID Data field).

Under the second ID field you should be able to see the peers VPN Domain configuration.

Packet 2 from the responder agrees to its own subnet or host ID, encryption and hash algorithm.

Packet 3 completes the IKE negotiation.


Phase II Quick Mode example:

Below is a screenshot of a failed VPN connection for Phase II. From this example, we can see that Phase I(Main Mode) completed successfully. Phase II (Quick Mode) shows a Failed status.

As indicated below, there is an Outgoing proposal (local peer) for AES/SHA1 with a lifetime of 3600 seconds. After the failed Phase II packet, there is an Info packet from the remote peer indicating “Invalid ID Information”. This is an indication that the remote peer rejected our proposal. If the tunnel were being initiated on the Remote End, we would also see the remote peer’s proposal and can compare that to the local proposal.

Common errors indicated in Ikeview

No Proposal Chosen:

A common error that can be easily identified in IKEVIEW is “No Proposal Chosen”.

In the Quick Mode section that is followed by the info line displaying the “No Proposal Chosen” message should display the network mask used for the VPN handshake. Compare the mask used in the local encryption domain with the mask sent by the remote peer. This is a common error when establishing tunnels with non-Checkpoint firewalls. Checkpoint, by default, supernets networks contained in the encryption domain. The method for resolving this issue on the Checkpoint firewall differs depending on if the firewall is R55, R61 simple mode, or R61 classic mode. In R55 there is an option in the VPN section of the Interoperable firewall object that tells the Firewall for “One tunnel per pair of hosts, or one tunnel per pair of subnets”. In R61 Simple mode, there is an option in the VPN Community that says “exchange key per host”. In R61 Classic mode you will need to do the following during non-business hours:

CP Stop

Modify the $FWDIR/lib/user.def.

Change the parameter "IKE_largest_possible_subnet" from true to "false".

CP start.



Aggressive Mode failure:

Aggressive mode uses 3 packets instead of 6 during the Phase I negotiations. Therefore if 1 side of the tunnel is configured for Aggressive Mode and the other side is configured for Main Mode, the 2 peers will not agree with the contents of the first packet during the exchange. If the local peer is mistakenly configured to use Aggressive Mode (which is a less secure method), the outgoing packet will be labeled Aggressive Mode.



Invalid ID-Information:

This is an indication that the remote peer rejected either the Phase I or Phase II proposal from the local peer.



PROTO_IPCOMP in the QM packet

This is an indication that IP Compression is enabled for this tunnel.