Checkpoint anti-spoof and state inspection

[FrankXie]

Hello expert

Recently we noticed an issue in our network.

The communication between client and server cross 2 firewalls. I can see by log and packet capture TCP syn from client pass through and reach  server and server responded.

But server response TCP SYNACK dropped by first firewall anti spoofing module. (This looks like just triggered by recently upgrade from version 80.10 to 81.10) This raise a interesting discussion within our team. What is the process sequence of difference inspection module?

Here is my understanding, please correct me if I am wrong.

1, for the first packet

anti spoof first then access rules and hold state of connection, wait for syn ack

2, for the ack

Don't know how firewall handle this one

3, for the following traffic

Check session table first, if session is there, it bypass all other modules. Otherwise follow 1.

Can you please share some insight about this?

Thanks

Frank

[emmap]

It would be similar, all packets must pass through anti-spoofing before we check for state etc. So in this case it seems like you need to check the anti-spoofing settings on the interface receiving the SYN-ACK.

[FrankXie]

Though I think once session established, there's not necessary to check anti spoofing anymore. 

This only happens after upgrading, looks like behavior a little inconsistent between different version. (We have another dc with old version still running without problem.)

[emmap]

If the SYN-ACK is being dropped, the session is not establishing. Pretty sure anti-spoofing is always checked, but given that packets have to pass both ways before a session can come up it already has to have been accepted both ways before the session is in the table anyway.

[Timothy_Hall · Accepted solution]

Assuming it is not manually disabled, anti-spoofing is always checked for all inbound packets regardless of connection state against whatever the anti-spoofing configuration is calling for on the inbound interface.  This next fact is not well known, but anti-spoofing is also applied against all traffic on the outbound interface by checking the routing table to make sure traffic is leaving the right way.  It is likely that at some point in the upgrade (SIC reestablishment maybe) a "Get Interfaces with Topology" happened, possibly before the firewall's Gaia OS routing table was fully or correctly populated, which this operation relies on heavily.

Fortunately since you are running R80.20+ your anti-spoofing configuration will be quite simple going forward:

1) On all interfaces defined as Internal, set the new "Network defined by routes" option.  No need to define byzantine groups of "specific" networks that will inevitably get screwed up at a future date leading to massive anti-spoofing drops of traffic.

2) Make sure your external interface is properly set

That's it.  If you are still experiencing anti-spoofing drops in the logs at that point, your routing table in the Gaia OS on the firewall is incorrect.  Period.  Full stop.

[FrankXie]

Thanks Tim

Yes I am new to Checkpoint.  That's all make sense. We do have specific group, maybe we change it to follow your suggestion. 

Frank

[_Val_ · Accepted solution]

Check that you do not have an asymmetric routing situation after an upgrade. 

[FrankXie]

Asymmetric usually dropped by checking session state with message like first packet not syn.