Checking dmesg and the Messages File
The output of the dmesg command and the /var/log/messages file should be examined for tell-tale messages:
‘Neighbour table overflow’
If this message is seen it indicates that the default limit of the kernel ARP cache (1024) is set too low. This will only occur if there is a large subnet connected directly to the firewall or cluster. If the message is seen it is possible to increase the size of the table by editing the /etc/sysctl.conf file to include the lines:
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096
This will increase the ARP cache to 4096 after the firewall has been re-booted.
‘FW-1: State synchronization is in risk. Please examine your synchronization network to avoid further problems!’
If this message is seen it indicates that there is an issue with the state synchronization network which can impede network performance. Consult the „State Synchronization‟ section in the „Firewall Application Checks‟ for further information.
By default all services are state synchronized but some services do not need syncing and may cause excessive load on the sync network (e.g. DNS). Disable state sync for all short lived connections and/or services which don‟t require state full failover.
‘FW-1: SecureXL: Connection templates are not possible for the installed policy (network quota is active). Please refer to the documentation for further details.'
If this message is seen it indicates that there is a SmartDefense option active (in this case „network quota‟) that has disabled templating of connections in SecureXL. Disabling SecureXL templates restricts the performance of SecureXL and is therefore undesirable. In this case, disabling the „network quota‟ option would restore the ability to produce templates and increase the performance of the firewall.
‘Out of Memory: Killed process
()’
If this message is seen it means there is no more memory available in the user space. As a result, SecurePlatform starts to kill processes.
From time to time other messages of a similar nature may appear in dmesg, the /var/log/messages file and on the console. It is always a good idea to research the message in the Check Point Secure Knowledge if you are unsure of the meaning.
For further information see: sk33219: Critical error messages and logs
Processes
A list of processes running on the firewall can be displayed with the following commands:
top
ps auxw
Use the ‘top’ command to check if any process is hogging CPU or Memory and to see if there are any
Zombie processes.
Example output:
[Expert@Zulu]# top
09:46:44 up 24 days, 9:40, 1
user, load average: 0.30, 0.19, 0.14
55 processes: 50
sleeping, 2 running, 3 zombie, 0 stopped
CPU states: cpu
|
user
|
nice
|
system
|
irq
|
softirq
|
iowait
|
idle
|
total
|
15.0%
|
0.0%
|
1.0%
|
10.0%
|
24.0%
|
0.0%
|
150.0%
|
cpu00
|
7.0%
|
0.0%
|
0.0%
|
0.0%
|
1.0%
|
0.0%
|
92.0%
|
cpu01
|
8.0%
|
0.0%
|
1.0%
|
10.0%
|
23.0%
|
0.0%
|
58.0%
|
Mem: 4091376k av, 1390028k used, 2701348k
free, 0k shrd, 90864k
buff
786476k active, 140320k
inactive
Swap: 4192944k
av, 0k used, 4192944k
free 278224k
cached
PID
1526
|
USER
root
|
PRI
25
|
NI
0
|
SIZE
97280
|
RSS
95M
|
SHARE
11396
|
STAT R
|
%CPU
15.8
|
%MEM
2.3
|
TIME
2590m
|
CPU
1
|
COMMAND
fw
|
1
|
root
|
15
|
0
|
512
|
512
|
452
|
S
|
0.0
|
0.0
|
0:17
|
0
|
init
|
2
|
root
|
RT
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
0
|
migration
|
3
|
root
|
RT
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
1
|
migration
|
4
|
root
|
15
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
1
|
keventd
|
5
|
root
|
34
|
19
|
0
|
0
|
0
|
SWN
|
0.0
|
0.0
|
0:00
|
0
|
ksoftirqd
|
6
|
root
|
34
|
19
|
0
|
0
|
0
|
SWN
|
0.0
|
0.0
|
0:00
|
1
|
ksoftirqd
|
9
|
root
|
25
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
1
|
bdflush
|
7
|
root
|
15
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:10
|
0
|
kswapd
|
8
|
root
|
15
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:12
|
0
|
kscand
|
10
|
root
|
15
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:14
|
0
|
kupdated
|
17
|
root
|
25
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
0
|
scsi_eh_0
|
22
|
root
|
15
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:14
|
0
|
kjournald
|
90
|
root
|
25
|
0
|
0
|
0
|
0
|
SW
|
0.0
|
0.0
|
0:00
|
1
|
khubd
|
The above example output indicates there are 3 zombie processes but there are no resource
hogging processes. The Zombie processes should be identified to see if there is any cause for action.
Use ‘ps auxw | more’ to examine the value in the START column of the process INIT, check the START column of cpd, fwd and vpnd processes
and other
daemons to see if they have restarted since the last boot. Identify any Zombie
processes.
Example output:
[Expert@Zulu]# ps
auxw | more
USER PID %CPU %MEM VSZ RSS
TTY STAT START TIME COMMAND
root 1 0.0 0.0 1524 512
? S Jun13 0:17 init
root 731 0.0 0.0 1524 476
? S Jun13 0:00
klogd -x -c 1
root 1174 0.0 0.0 3040
1348
? S Jun13 0:00
/usr/sbin/sshd -4
root 1212 0.0 0.0 1572 620
? S Jun13 0:00
crond
root 1265 0.0 0.0 2724 904
? S Jun13 0:00
/bin/sh
/opt/spwm/bin/cpwmd_wd
root 1269 0.0 0.1
34412 7348
? S Jun13 0:18
cpwmd -D -app SPLATWebUI
root 1389 0.0 0.1 7948
4608
? S Jun13 0:00
/opt/CPshrd-R65/bin/cprid
root 1402 0.0 0.0 9120
3908
? S Jun13 2:30
/opt/CPshrd-R65/bin/cpwd
root 1416 0.2 4.9
331348 204012 ? S Jun13 88:42 cpd
root 1526 7.3 2.3
422392 97280 ? S Jun13 2590:42 fwd
root
|
1578
|
0.0
|
1.6
|
220252
|
66864
|
?
|
S
|
Jun13
|
0:42
|
in.asessiond 0
|
root
|
1579
|
0.0
|
1.6
|
220220
|
66800
|
?
|
S
|
Jun13
|
0:43
|
in.aufpd 0
|
root
|
1580
|
0.1
|
1.7
|
240988
|
69844
|
?
|
S
|
Jun13
|
57:51
|
vpnd 0
|
root
|
1586
|
0.2
|
0.1
|
11508 6172 ?
|
|
S
|
Jun13
|
95:09
|
dtlsd 0
|
root
|
1680
|
0.0
|
2.0
|
273760 82716
|
?
|
S
|
Jun13
|
15:20
|
rtmd
|
No daemons in the ps auxw output have restarted.
Any daemon processes that have restarted may not necessarily indicate
a fault because somebody may
have
restarted it, for example by performing cpstop;cpstart. Normally the cause of a process restart can be determined by looking at the /var/log/messages file or by examining the daemon‟s error log file (cpd.elg, fwd.elg, vpnd.elg etc).
In the above example of ‘top’ output there were 3 Zombie processes. Zombie processes do not consume resources but should not be present. Check the process list to identify the Zombie (Stat: z) processes and determine if action is required.
[Expert@Zulu]# ps
auxw | more
USER PID %CPU %MEM VSZ RSS
TTY STAT START TIME COMMAND
root
|
18374
|
0.5
|
0.0
|
4680
|
1932 ttyp0
|
S
|
09:46
|
0:00 cpinfo
-n -z -o BCCF-CWH-EXT.cpinfo
|
root
|
18399
|
0.0
|
0.0
|
0
|
0 ttyp0
|
Z
|
09:46
|
0:00 [cpprod_util
]
|
root
|
18403
|
0.2
|
0.0
|
0
|
0 ttyp0
|
Z
|
09:46
|
0:00 [cpprod_util
]
|
root
|
18413
|
0.4
|
0.0
|
0
|
0 ttyp0
|
Z
|
09:46
|
0:00 [cpprod_util
]
|
The process „cpprod_util‟ was called by a process used by CPinfo to gather Ethernet stats. The „Zombie‟ process is also marked „defunct‟ which means the same as „Zombie‟. A defunct or Zombie process is a process that has finished but still depends on a „parent‟ which is still alive. After the completion and
termination of the parent process
these Zombie processes should terminate and no longer be shown in the process list.
If the Zombie processes
are still there after completion of the CPinfo, killing
the parent process will be required to remove them from the process list.
Sometimes Zombie processes
are the result of
an error in the daemon coding. For example if a
Zombie vpnd process is seen there is a hotfix for it,
refer to:
sk33941: "Zombie" vpnd process
Capacity Optimization
The maximum number of concurrent connections that a firewall can
handle is configured in the Capacity Optimization section
of the firewall
or cluster object. It is recommended under normal circumstances to use
the „automatic hash table size and memory pool‟ configuration when increasing or decreasing the number of maximum concurrent connections (default 25,000).
To check what value the maximum number
of concurrent connections has been set to either check the setting in the GUI firewall/cluster object or run the following command on the firewall:
fw tab –t connections | grep limit
Example output:
[Expert@Zulu] #fw tab –t connections | grep limit
dynamic, id 8158, attributes: keep, sync, aggressive aging, expires 25, refresh, limit 100000, hashsize 534288, kbuf 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31, free function c0b98510 0, post sync handler c0b9a370
The number (100000) directly after ‘limit’ is the maximum value
as set in the „Capacity Optimization‟
page
on the firewall or cluster object (GUI).
To check the number
of concurrent connections
(#VALS) and the peak value (#PEAK) use the following command on the firewall:
fw tab –t connections –s
Example output:
[Expert@Zulu]# fw tab –t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 23055 77921 29141
[Expert@Zulu]#
The values that
we are interested in are the „limit‟ and „peak‟ values. Ensure that there is about 15-20%
headroom before Aggressive Ageing is activated to ensure there is adequate spare capacity in the connections table to cope
with an increase in connections. If necessary, change the value in the capacity optimization section on the firewall
object and push the policy to make it effective. Greatly over-prescribing
the maximum concurrent connections is not recommended as it can lead to inefficient use of memory.
In the above example, a maximum of 100,000 concurrent connections has
been set in the
Capacity Optimization section for the firewall and the peak number
of connections (#PEAK) was
77,921 over the last 124 days (uptime).
The headroom above the #PEAK is set too low because the Aggressive Ageing default threshold of 80% will
be activated
at 80,000. Increase the concurrent connections limit to around
120,000 connections to give
between 15-20% head-room before Aggressive Ageing becomes active.
If NAT is performed on the module check the fwx_cache table using the command:
fw tab –t fwx_cache -s
Example output:
[Expert@Zulu]# fw tab –t fwx_cache -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost fwx_cache 8116 10000 10000 0
[Expert@Zulu]#
In the above example,
the value of #PEAK is equal to 10,000 it indicates that the
NAT cache table (default 10,000) was full
at some time. (#VALS equal to 10,000 indicates that the NAT cache table is still full.)
For improved NAT cache performance the size of the NAT cache should be increased or the time entries are held in the table decreased. For further information see:
sk21834: How to modify the values of the properties related to the NAT cache table
ClusterXL and State Synchronization
The health of ClusterXL can be examined using
a number of different commands:
cphaprob –a if cphaprob state cphaprob list
cpstat ha –f all | more
fw ctl pstat
Use the ‘cphaprob –a if’ command on the cluster members to check which interfaces have been configured for state synchronization and verify the sync mode is consistent on the cluster members:
Example output:
[Expert@Zulu]# cphaprob –a if eth1c0 non sync(non secured) eth2c0 non
sync(non secured) eth3c0 non sync(non secured) eth4c0 sync(secured), multicast
Virtual cluster interfaces: 3
eth1c0 192.168.1.1
eth2c0 192.168.2.1
eth3c0 10.1.1.1 [Expert@Zulu]#
[Expert@Shaka]# cphaprob –a if
eth1c0 non sync(non secured) eth2c0 non sync(non secured) eth3c0 non sync(non secured) eth4c0 sync(secured), broadcast
Virtual cluster interfaces: 3
eth1c0 192.168.1.1
eth2c0 192.168.2.1
eth3c0 10.1.1.1 [Expert@Shaka]#
In the above example, interface eth4c0 has been configured on both cluster members for state sync but the sync mode is inconsistent, one is using multicast and the other broadcast mode. Ensure the cluster members use the same mode. (The default mode is multicast.)
The following document explains how to change between broadcast and multicast
mode:
sk20576: How
to set ClusterXL Control Protocol (CCP) in broadcast mode in ClusterXL
Use the ‘cphaprob state’ command to check if state sync is up and running. The local and remote state synchronization IP addresses should be displayed and their state should be shown as ‘Active’ on the HA Master and ‘Standby’ on the HA Backup.
In a load-sharing
cluster the state should be shown as
‘Active’ on both the local and remote firewalls:
Example output
- HA:
[Expert@Zulu]# cphaprob state
Cluster Mode: New High Availability (Active Up)
Number
|
Unique Address
|
Assigned
|
Load
|
State
|
1 (local)
|
1.1.1.1
|
100%
|
|
Active
|
2
|
1.1.1.2
|
0%
|
|
Standby
|
[Expert@Zulu]#
In a HA cluster configuration (above), one member should be Active and the other Standby.
Example output – Load-Sharing:
[Expert@Dingaan]# cphaprob state
Cluster Mode: New High Availability (Active Up)
Number
|
Unique Address
|
Assigned
|
Load
|
State
|
1 (local)
|
1.1.1.3
|
50%
|
|
Active
|
2
|
1.1.1.4
|
50%
|
|
Active
|
[Expert@Dingaan]#
In a load-sharing cluster configuration (above), both members should be shown as Active.
Example output – HA or Load-Sharing:
[Expert@Zulu]# cphaprob state
Cluster Mode: New High Availability (Active Up)
Number Unique Address Assigned Load State
1 (local) 1.1.1.1 100% Active
[Expert@Zulu]#
Remote cluster partner is missing!
If the remote partner is not shown it will be usually be due to one of the following:
· There is no network connectivity between the members of the cluster on the state sync network
· The partner does not have state synchronization enabled
· One partner is using
broadcast mode and the other is using multicast mode
· One of the monitored processes has
an issue, such as no policy loaded
· The partner firewall is down.
Example output
- HA or Load-Sharing:
[Expert@Zulu]# cphaprob state
Cluster Mode: New High Availability (Active Up)
Number
|
Unique Address
|
Assigned
|
Load
|
State
|
1 (local)
|
1.1.1.1
|
100%
|
|
Active
|
2
|
1.1.1.2
|
0%
|
|
Ready
|
[Expert@Zulu]#
Partner is in the ‘Ready’ state. If one of the partners is in the ‘Ready’ state it indicates that there is an issue with state synchronization.
The ‘Ready’ state is normally caused by another member of the cluster running
a higher version of code or HFA, for example, as would happen
during
an upgrade. This state is also seen when CoreXL has been configured to use a different number
of cores on the individual cluster members.
For further information see:
sk42096: Cluster member with CoreXL is in 'Ready' state
The ‘Ready’ state can also occur if a cluster member receives state synchronization
traffic from a different cluster that is using the same mac magic number
and the
other cluster is running a higher version of code. For further information see:
sk36913: Connecting several clusters on the same network
Example output
- HA or Load-Sharing:
[Expert@Zulu]# cphaprob state
Cluster Mode: New High Availability (Active Up)
Number
|
Unique Address
|
Assigned
|
Load
|
State
|
1 (local)
|
1.1.1.1
|
100%
|
|
Active
|
2
|
1.1.1.2
|
0%
|
|
Down
|
[Expert@Zulu]#
A remote cluster member is in the ‘Down’ state indicates
that there is either a problem on the remote member or the state synchronization network between the cluster members is broken.
To investigate why a member shows itself to be locally ‘Down’ use the ‘cpstat ha –f all | more’ command on the firewall that shows ‘Down’. This command displays the „Problem Notification Table‟ and the state of health of the monitored
processes:
Example output (truncated):
[Expert@Zulu]# cpstat ha –f all | more
Problem Notification table
-------------------------------------------------
|Name |Status |Priority|Verified|Descr|
-------------------------------------------------
|Synchronization|OK | 0| 3383| |
|Filter
|
|OK
|
|
|
0|
|
3383|
|
|
|
|cphad
|
|OK
|
|
|
0|
|
0|
|
|
|
|fwd
|
|OK
|
|
|
0|
|
0|
|
|
|
-------------------------------------------------
All monitored processes have the ‘OK’ status.
Example output (truncated):
[Expert@Shaka]# cpstat ha –f all | more
Problem Notification table
-------------------------------------------------
|Name |Status |Priority|Verified|Descr|
-------------------------------------------------
|Synchronization|problem| 0| 3383| |
|Filter |problem| 0| 3383| |
|cphad |OK | 0| 0| |
|fwd |OK | 0| 0| |
-------------------------------------------------
State synchronization is in a problem state because the policy is unloaded on this cluster member. Installing the policy will fix
this issue.
Alternatively, the ‘cphaprob list’ command displays the same information plus some additional details:
Example output:
[Expert@Zulu]# cphaprob list
Registered Devices:
Device Name: Synchronization
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 12139.6 sec
Device Name: Filter
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 12124.5 sec
Device Name: cphad
Registration number: 2
Timeout: 5 sec
Current state: OK
Time since last report: 0.6 sec
Device Name: fwd
Registration number: 3
Timeout: 5 sec
Current state: OK
Time since last report: 0.6 sec
All monitored processes
are shown
as ‘OK’.
Assuming that state synchronization on the cluster is healthy, use the following command to check if the state tables are synchronized:
fw tab –t connections –s
Simultaneously execute the command on both cluster members; compare the values
of #VALS. The values on both firewalls should be similar if the state synchronization mechanism is working unless
a lot of delayed notification is in use.
Example output:
[Expert@Zulu]# fw tab –t connections -s
HOST NAME ID
#VALS #PEAK #SLINKS
localhost connections 8158 3222 38026 9820 [Expert@Zulu]#
[Expert@Shaka]# fw tab –t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 3187 38026 9808 [Expert@Shaka]#
The #PEAK may be different depending on the uptime and when the last peak number of connections occurred.
The #VALS on a
HA pair should always be similar.
Examine the output of
the sync section of ‘fw ctl pstat’.
Example output:
Sync: Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 13880231, retransmitted : 5, retrans reqs : 524, acks : 70
Sync packets received:
total : 692409645, were queued : 720, dropped by net : 517
retrans reqs : 5, received 43019 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Callback statistics: handled 42940 cb, average delay : 1, max delay : 4
If the „dropped by net‟ counter has incremented then some sync
packets have been lost and the
problem
needs
to be investigated to find the cause.
For further information please refer to:
sk34476: Explanation of Sync section in
the output of fw ctl pstat command
SecureXL
For optimum gateway performance SecureXL needs to be enabled, the SmartDefense and Web-Intelligence or IPS options
that are enforced do not interfere
with SecureXL and the extent that templating is performed
is maximized by careful rulebase ordering.
For further information, refer to:
sk42401: Factors that adversely affect performance in
SecureXL
The following command can be used to determine that SecureXL is turned on and the creation of templates
has not been disabled:
fwaccel stat
Example output showing SecureXL turned on and templating is enabled:-
[Expert@Zulu]# fwaccel stat Accelerator
Status : on Accept Templates : on
Accelerator Features : Accounting, NAT, Cryptography, Routing,
HasClock, Templates, VirtualDefrag, GenerateIcmp,
IdleDetection, Sequencing, TcpStateDetect, AutoExpire,
DelayedNotif, McastRouting,
WireMode
Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL,
3DES, DES, AES-128, AES-256, ESP, LinkSelection,
DynamicVPN, NatTraversal, EncRouting
[Expert@Zulu]#
If SecureXL is disabled it can be turned on from ‘cpconfig’.
Note: SecureXL is incompatible with FloodGate and will be disabled if FloodGate is active.
The following command can be used to examine the SecureXL statistics to get an understanding on how well SecureXL is configured and performing:
fwaccel stats
Examine the output of ‘fwaccel stats’:
· Check that templates are being created – this number rises
and falls as templates are created and expire.
· Examine the ratio of F2F packets to packets being accelerated - for best performance the firewall should be accelerating the majority of the packets; the amount of
packets being forwarded to the firewall (F2F) should be minimal.
Example output showing the SecureXL statistics:-
Templates
are being formed and only a small amount of F2F packets to accel packets.
Aggressive Ageing
Aggressive Aging helps manage
the connections table capacity and memory consumption of the firewall to increase durability and stability; allowing the gateway machine to handle large amounts of unexpected traffic, especially during a Denial of Service attack.
Aggressive Aging
uses short timeouts called aggressive timeouts. When a connection is idle for more than its aggressive timeout it is marked as "eligible for deletion". When the connections table or memory consumption reaches a certain user defined threshold (highwater mark), Aggressive Aging begins to delete “eligible for deletion” connections, until memory consumption or connections capacity decreases back to the desired level.
The user defined
thresholds
are set in the GUI for the specific protection enforced by the firewall
(SmartDefense > Network Security > Denial
of Service > Aggressive Ageing).
To check the state of Aggressive Ageing on the firewall
use the „fw ctl pstat‟ command:
Example output:
[Expert@Zulu]# fw ctl pstat | grep Aggressive
Aggressive Ageing is not active
[Expert@Zulu]#
The above output indicates that Aggressive Ageing
has been set in SmartDefense to „Protect‟ but the
thresholds have not been reached to make it aggressively close connections that are eligible for deletion.
If Aggressive Aging
has been set in SmartDefense to „Inactive‟ the output will say that
Aggressive Ageing is „disabled‟:
[Expert@Zulu]# fw ctl pstat | grep Aggressive
Aggressive Ageing is disabled
[Expert@Zulu]#
If Aggressive Aging is in Detect mode the
output will say it is „monitor only‟:
[Expert@Zulu]# fw ctl pstat | grep Aggressive
Aggressive Ageing is in monitor only
[Expert@Zulu]#
There were some issues with the Aggressive Ageing mechanism which are fixed in R65 HFA_50:
Improved SecureXL notifications to the firewall resolve a connectivity issue that occurs when the Sequence
Verifier is enabled together with
the Aggressive Aging mechanism.
Implementation: An immediate workaround is to disable either the Sequence Verifier or the Aggressive
Aging mechanism.
HFA Patching
Use the „fwm ver‟ and „fw ver –k‟ commands to inspect
the patching
on the management station
and the
firewall modules.
Check that the HFA patching on the module is the same version (HFA_50) or lower that the patching on the Provider-1 management station. The firewall module must never be patched with a higher version than the management station.
Ensure patching on cluster members is identical.
Example output: Provider-1 Management:-
[Expert@Manager]# fwm verThis is Check Point SmartCenter Server NGX (R65) HFA_50, Hotfix 650 - Build 011
Installed Plug-ins: Connectra NGX R62CM [Expert@Manager]#
Cluster:-
[Expert@Zulu]# fw ver –k
This is Check Point VPN-1(TM) & FireWall-1(R) NGX (R65) HFA_40, Hotfix
640 - Build 091
kernel: NGX (R65) HFA_40, Hotfix 640 - Build 091
[Expert@Zulu]#
[Expert@Shaka]# fw ver –k
This is Check Point VPN-1(TM) & FireWall-1(R) NGX (R65) HFA_40, Hotfix
640 - Build 091
kernel: NGX (R65) HFA_40, Hotfix 640 - Build 091
[Expert@Shaka]#
Versions
on the clustered firewalls (HFA_40) are identical and the versions are not above the
Provider-1 version (HFA_50)
Although the patching is good in the above example it is out of date. Check Point always recommends applying the latest HFA and Security Hotfixes on the SmartCenter and firewall modules.
The latest HFAs and Security Hotfix
release notes are available on the Check Point website:
http://www.checkpoint.com/downloads/latest/hfa/index.html
CPinfo Package:
For troubleshooting purposes Check Point TAC will require a CPinfo taken from the firewall and SmartCenter Server or CMA. Ensure the CPinfo package is higher than 911000023 so the full set of diagnostics from the appliance can be gathered successfully.
CPinfo version 911000023 often hangs during
gathering the firewall‟s connection tables
and produces a
truncated
output so it should be replaced
with the latest version.
The version installed on the appliance can be determined by running the following command:
cpvinfo /opt/CPinfo-10/bin/cpinfo |grep Build
Example output:
[Expert@Zulu]# cpvinfo /opt/CPinfo-10/bin/cpinfo |grep Build
Build number = 911000023
[Expert@Zulu]#
The above version is problematic and should
be upgraded.
The most up to date version of CPinfo can be downloaded using
the following link:
sk30567: The CPinfo utility
