R80.10 and tcpdump

[Godfrey_Bennett]

HI, can someone please confirm that no firewall services will do anything to any packets before tcpdump (on the incoming interface) captures the packets?  I am looking to prove that a packet which is consistently missing from a tcpdump cannot be possibly dropped by any firewall processes - in other words, that some or other IPS on the internal network must be interfering with matters.

I do know that fw monitor won't work without disabling acceleration, but this is tcpdump only which I am referring to.

Thanks

[Kaspars_Zibarts]

In short you are correct in your assumption

[Timothy_Hall]

Yes libpcap/tcpdump is receiving a copy of the frames before they are being processed by SecureXL or the INSPECT driver on the inbound side.  The outbound side is a lot more complicated though depending on SecureXL and you may or may not see the packets leaving with tcpdump. 

However there are four exceptions I can think of that would cause packets not to appear on the inbound interface via tcpdump:

1) A SAM/ADP card is in use on a 23000 series, in this case the NIC and firewall processing silicon are tightly integrated and tcpdump may not be able to see the inbound packets at all.  Not sure if this will still apply with the new Falcon cards.

2) The incoming frame is errored due to framing/CRC/runt/jabber/etc.  In this case the relevant error counters visible with ethtool -S and netstat -ni (RX-ERR) will be incremented, but the errored frame will not be passed up to libpcap/SecureXL/INSPECT at all.

3) The frame was dropped due to a hardware overrun in the NIC (++RX-OVR) or no ring buffer slots were available during hardware interrupt frame processing (++RX-DRP).  You can view these two counters and RX-ERR with netstat -ni, as long as they don't move during your tcpdump capture exceptions 2 and 3 are not happening.

4) At the conclusion of your tcpdump the reported value of "dropped by kernel" is nonzero.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[HeikoAnkenbrand]

Hi Godfrey,

I agree with Timothy!

Inbound libpcap/tcpdump works between layer 2 and layer 3. The SecureXL or IINSPECT driver is not yet effective here. Therefore you can see all packages here.

Outbound looks a little different. Here the SecureXL driver can bypass the libpcap code in the Linux kernel under certain conditions. Therefore not all packages are 100% visible. If you want to be 100% sure that you see all outbound packetes, you must switch off SecureXL "fwaccel off". It is a historical discussion whether SecureXL must be switched on or off. When I want to be 100% sure I switch SecureXL off.

You can see more in my flowchart in the following article:

R80.x Security Gateway Architecture (Logical Packet Flow) 

Here is also a description of how the packets pass through the firewall.

Regards

Heiko

[Timothy_Hall]

> If you want to be 100% sure that you see all outbound packetes, you must switch off SecureXL "fwaccel off".

Right, but in general I don't recommend doing this on a production firewall with more than 8 cores as the performance impact can be noticeable.  Would always recommend disabling SecureXL selectively for the IP address(es) you want to capture ahead of time, then you can use tcpdump and/or fw monitor to see all inbound and outbound traffic:

sk104468: How to disable SecureXL for specific IP addresses

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Yuri_Slobodyany]

As the question got fully qualified answers I will only go astray a bit and tell how I introduce networking to the newcomers (with simplification) - "Look, there is nothing magical about Checkpoint, it is just a bunch of clever kernel modules working on Layer 3,4 and 7 of OSI, below or above that it is just good old Linux. So forget for a second about Checkpoint - ethernet speed/duplex, NIC errors, routing, bringing up/down interfaces, top, tcpdump is still very basic Linux stuff you already know".