Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
FrankXie
Participant
Jump to solution

Checkpoint anti-spoof and state inspection

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

0 Kudos
2 Solutions

Accepted Solutions
_Val_
Admin
Admin

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

View solution in original post

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

0 Kudos
7 Replies
emmap
Employee
Employee

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.

0 Kudos
FrankXie
Participant

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.)

0 Kudos
emmap
Employee
Employee

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.

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
FrankXie
Participant

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

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
FrankXie
Participant

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events