I was just about to put some FW Monitor templates on my blog for quick reference when I need to troubleshoot some issues in Check Point but I thought it would be a nice thing to explain this first (for myself too, as I keep forgetting this stuff :D).
When traffic flows through a Check Point Security Gateway (look here if you want to know about the architecture) it has to cross a series of inspection points. This post tries to explain what those inspection points are and how to troubleshoot traffic flows based on the inspection points. The next post will show how to use the FW Monitor.
Edit: Check the bottom of the post for an update version of the inspection point in R80.x
Inspection Points (in the order they are passed):
1st | i – Pre-inbound | rule/inspection is applied at this point |
2nd | I – Post-inbound | after being permitted by the rule/inspections |
3rd | o – Pre-outbound | route look up has been performed to determine the egress interface |
4th | O – Post-outbound | after egressing the correct firewall interface based on route lookup |
The above image shows how a firewall kernel protects the Check Point OS. The start and end depict the start and end of the originating traffic flow. The return traffic too goes through the same inspection points. The below diagram shows how a complete two-way traffic is treated by the inspection points.
For a complete two-way communicating traffic you should see 8 logs (also depends if you do want to see 8 or less)
So looking at the above diagram you see that a complete traffic flow of a two-way communication goes through 8 inspection points;
Originating traffic from A to B = 4 logs of iIoO
and the return traffic from B to A = 4 logs of iIoO
I you don’t want to see what is going on at the inspection points ‘I’ and ‘o’ then you only grep ‘i’ and ‘O’ and get 4 logs in total for a complete two-way traffic;
Originating traffic from A to B = 2 logs of iO
and the return traffic from B to A = 2 logs of iO
Sometimes you won’t see 8 logs for a complete two-way communicating traffic and will only see 4 logs
If you are grepping iIoO in your captures and you still don’t see a ‘I’ or ‘o’, but you do see a ‘i’ and an ‘O’, then most likely SecureXL is fast switching/accelerating the traffic because the initial packets of that flow were already allowed.
You can disable SecureXL while setting captures if you want to inspect them at that granularity (i.e ‘I’ and ‘o’). In my experience, disabling SecureXL hasn’t been a problem* and I haven’t seen any performance impact as such.
Right before the capture, turn off SecureXL on the gateway:
fwaccel off
Immediately after the capture, turn on SecureXL on the gateway:
fwaccel on
To turn on fw accel on multiple VSXs at once:
fwaccel on -a
*Do it at your own risk, I do not take any responsibility for anything going wrong with this as it does affect the live traffic immediately. Read the site disclaimer. :)
Troubleshooting the inspection points
Troubleshooting ‘i’ – When you don’t see any traffic on the ‘i’ inspection point:-
Traffic isn’t hitting your firewall. You won’t get back any captures and the console will just be a black blank screen (or any other background color you use on your terminal :D).
Troubleshooting ‘I’ – When you see traffic hitting the ‘i’ inspection point but don’t see it hitting ‘I’:-
The firewall is blocking that ingress traffic either by a rule, improper NAT, IP spoofing, Application Inspection or anything else that you can think of.
Troubleshooting ‘o’ – When you see an ‘i’ and ‘I’ but don’t see an ‘o’:-
I’m not very sure on this but in one case that I observed, there was a route missing for the destination in the routing table, so the route look up failed to determine an egress interface and I didn’t see the traffic hitting ‘o’ and it was stuck at ‘I’.
Troubleshooting ‘O’ – When you see an ‘i’, ‘I’ and ‘o’ but not an ‘O’:-
I too don’t know, please tell me what that would be and I’ll update it here. :) I think it might be some kind of inspection or something. But I’m quite sure it will be a very rare case.
FW Monitor
FW Monitor is the tool that can be used to see your traffic flowing through different inspection points. FW Monitor cannot give you the information what SmartviewTracker/Monitor can, because it is a wire capture. It just tells you what is on the wires and does not look into the rule base to see which policy allowed the traffic and was it NAT’d or not. So the Smartview Tracker and Monitor serves a slightly different purpose than the FW Monitor.
I’m writing a separate post on how to use the FW Monitor at it’s best and in different ways so you can be better at troubleshooting traffic flow issues in Check Point.
___________________________________________________________________________________________________________________________________________________________________________
If you see any mistakes in the post or have any suggestions to add to this post, please feel free to comment. Thank you!
____________________________________________________________________________________________________________________________________________________________________________
Thanks to Adrian Raiciu for sharing an updated version of the inspection points in R80.x in the comment section of this post.
In R80.x this changed. There are extra Fields
Credit > Heiko Ankenbrand
Source > https://community.checkpoint.com/thread/10363-r8020-new-fw-monitor-inspection-points
Related Articles:
Using FW Monitor to Capture Traffic Flows in Check Point (Cheat Sheet)
Analyzing FW Monitor Output on Console and Wireshark
[…] you understand the inspection points in Check Point and can use FW Monitor to get the required logs/captures then you can read further on how how to […]
Hi there,
Troubleshooting ‘O’ – When you see an ‘i’, ‘I’ and ‘o’ but not an ‘O’: in my case, this had to do with a proxy id error, in which case one must manually change the user.def file, as checkpoint is supernetting and therefore your packets can go the wrong way.
According to a colleague of mine, who is a checkpoint master, this can also be related to a NAT problem.
Cheers,
Adrian
Hey Adrian,
That’s awesome! Thank you for your contribution. :) I’ll update it soon.
Regards,
Shoaib
Hello friends,
I am also stuck in “Troubleshooting ‘O’” and I have no idea which way to go.
I would like to explore this NAT problem that’s causing this.
Hope to hear soon from you guys.
Thank you.
Jemel
[…] is a great post for understanding Checkpoint Inspection […]
One more thing…fw accel on doesn’t NECCESSARILLY turn acceleration on all VSX at once. it all comes down to what vsenv you are connected to.
Many Many Thanks sir.
A likely source of the issue with troubleshooting ‘O’ – When you see an ‘i’, ‘I’ and ‘o’ but not an ‘O’: it is probably due to NAT
In R80.x this changed. There are extra Fields
Inspection point Name of fw monitor inspection point Relation to firewall VM Available since version
i Pre-Inbound Before the inbound FireWall VM (for example, eth1:i) always
I Post-Inbound After the inbound FireWall VM (for example, eth1:I) always
id Pre-Inbound VPN Inbound before decrypt (for example, eth1:id) R80.20
iD Post-Inbound VPN Inbound after decrypt (for example, eth1:ID) R80.20
iq Pre-Inbound QoS Inbound before QoS (for example, eth1:iq) R80.20
iQ Post-Inbound QoS Inbound after QoS (for example, eth1:IQ) R80.20
o Pre-Outbound Before the outbound FireWall VM (for example, eth1:o) always
O Post-Outbound After the outbound FireWall VM (for example, eth1:O) always
e Pre-Outbound VPN Outbound before encrypt (for example, eth1:e) R80.10
E Post-Outbound VPN Outbound after encrypt (for example, eth1:E) R80.10
oq Pre-Outbound QoS Outbound before QoS (for example, eth1:oq) R80.20
oQ Post-Outbound QoS Outbound after QoS (for example, eth1:OQ) R80.20
Courtesy of Checkmates -> https://community.checkpoint.com/thread/10363-r8020-new-fw-monitor-inspection-points
Wow! I’m pretty much lagging with Check Point products! Thanks for keeping me updated. Will see if I can incorporate this into the blog. Thanks!
And one more thing:
SecureXL “fwaccel off” does not have to be disabled on R80.20 to run “fw monitor”. This is good for performance, so “fw monitor” does not affect performance any more.
The reason for this is that with R80.20, SecureXL runs in User space and not in Kernel space anymore. R80.20 Only!!!
Good post ..