Checkpoint Web Visualization only provides part of the policy

Firewalls - Checkpoint

When using the Checkpoint Web Visualization tool and trying to obtain the policy for a Cluster object you may receive one of the following errors/issues :

1. The policy is saved as an .html file but it is only showing part of the policy.
2. You receive one of the following errors when running the Web Visualization syntax:

Querying tables...

Error Reason: Inconsistency problem: table communities is not recognized by serv
er.

An error occurred while synchronizing with server tables.

        1 file(s) copied.
        1 file(s) copied.

XSLT warning: Fatal Error at (file <unknown>, line 0, column 0): An exception oc
curred! Type:RuntimeException, Message:The primary document entity could not be
opened. Id=file:///d:/temp/temp/Security_Policy.xml (, line -1, column -1)

Querying tables...

Failed to open DB.
Error Reason: A disk error occurred during a read operation

Failed to get data from the management server "10.18.10.6"!

Solution

To resolve the issue use the cluster object name rather then the individual cluster node name when using the Web Visualization command. An example would be :

C:\Program Files\CheckPoint\SmartConsole\R65\PROGRAM>cpdb2html.bat . C:\temp\ [manager ip] [username] [pw] -o fw-policy.html -m [cluster object name]

Running a packet capture on a SourceFire Sensor

IDS - Snort / Sourcefire

Below shows you the required steps for running a packet capture on a SourceFire Sensor.

Which Interfaces are Sniffing ?

First of all we get a list of interfaces that is are sniffing for malicious traffic. Note : the fps normally relate to eth. Though you still use the fps reference within the tcpdump.

ps -ef | grep snort | grep fp | awk -F -i ' { print $2 } ' | awk '{print $1}' | head -n1

Tcpdump the Interface

Using the interface numbers output from the last command you can now use these to run a tcpdump.

root@3d:/#tcpdump -ni <interface>

root@3d:/#tcpdump -ni fp2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on fp2, link-type EN10MB (Ethernet), capture size 68 bytes
 15:35:51.477839 802.1d config 8001.00:15:13:de:a9:80.8001 root 8001.00:15:a3:ee:h5:80 pathcost 0 age 0 max 20 hello 2 fdelay 15 

We can also get an overview of the traffic by running the following command,

root@3d:/# watch 'netstat -ani'

File download fails through Netscreen when using IE6 with Passive FTP

Firewalls - Juniper - Netscreen

You may find when trying to download a file from your FTP server using Internet Explorer 6 with "Folder View Enabled" when using Passive FTP the file download transfer will fail after a short time period.

This can be down to Internet Explorer sending TCP packets with sequence numbers which are outside that of the current TCP window. This in turn causes the FTP file transfer to fail. This can be caused by vendors using non-RFC methods to verify a packets validity or the host sending back badly number packets expecting a return.

You can confirm whether the Netscreen is dropping packets due to this with the following command,

netscreen(M)-> get counter statistics | i (Total|seq)
Total flow counters for interface mgt:

tcp out of seq         0 | mac relearn            0 | no frag sess           0
Total flow counters for interface ethernet1/1:

tcp out of seq    38321 | mac relearn            0 | no frag sess           0
Total flow counters for interface ethernet1/2:

Solution

The Netscreen is working by design so you have 3 options :

1. Disabling TCP sequence checking on the firewall using the command 'set flow no-tcp-seq-check'
2. Using an alternative client for Passive FTP downloads.
3. Using Active FTP

I am unable to clear the VPN SA`s using the vpn tu command

Firewalls - Checkpoint

If you are unable to clear the VPN SA`s using the "vpn tu" command you may want to try using the following commands

vpn shell /show/tunnels/ike/peer/[remote gw ip]
vpn shell /show/tunnels/ipsec/peer/[remote gw ip]
vpn shell /tunnels/delete/IKE/peer/[remote gw ip]
vpn shell /tunnels/delete/IPsec/peer/[remote gw ip] 

The reason to this can be down to a number of issues and bugs with the Checkpoint software which they supply Hotfix`s for. Further details can be found on the Checkpoint site.

encryption failure: According to the policy the packet should not have been decrypted

Firewalls - Checkpoint

When trying to establish a VPN tunnel you may find that the tunnel is built but you receive the error message :

            encryption failure: According to the policy the packet should not have been decrypted

Of which you may also see that the traffic not encapsulated on the 1st Inspection point of the Inbound VPN-1 Kernel (or on the "i").

This can be down to either :

• Overlapping encryption domains for that of the local and remote endpoints.
• The local and remote encryption domains added to either end the wrong way round.
• Routing issues causing the non-encapsulated traffic to hit the Checkpoint outside of the VPN tunnel.