This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Create a Post
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Are you a member of CheckMates?

×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
Northy
Contributor
‎2019-07-24 12:55 AM

NAT traffic dropped

Hi all, 

 

I am hoping you will help me decipher what I have stumbled across. 

 

So we have a firewall that we are replacing with a new model, the policy is going to remain the same and 90% of the interfaces have remained the same and the static routes have been optimized. 

 

When I tried to perform the swap over the other night, I simply shifted the cables to the appliance below and the theory was that it would just operate the same as the current appliance. 

 

However, I was seeing issues where traffic was being dropped once it had been NAT'd. In the Smart Console, I could see accepted connections and traffic being NAT'd along the way. however, the traffic never got a response. 

 

digging deeper, I performed a zdebug drop from the CLI and could see the output for the traffic that was being permitted is being dropped due to no rule existing. I have included the output a little further down, Rule 129 is the cleanup rule at the bottom. 

 

192.168.209.1 is the interface it is leaving on.

192.168.209.17 is a server in a DMZ.

I have attached the permitted log in smart view

This firewall is operating R80.10 with the latest GA jumbo hotfix that is available through cpuse. 

This firewall only has the IPS and Firewall blade enabled.

 

;[cpu_1];[fw4_13];fw_log_drop_ex: Packet proto=6 192.168.209.1:10100 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_4];[fw4_7];fw_log_drop_ex: Packet proto=6 192.168.209.1:10200 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10000 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_5];[fw4_5];fw_log_drop_ex: Packet proto=6 192.168.209.1:10100 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_3];[fw4_9];fw_log_drop_ex: Packet proto=6 192.168.209.1:10200 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10100 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_13];[fw4_4];fw_log_drop_ex: Packet proto=6 192.168.209.1:10000 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_3];[fw4_9];fw_log_drop_ex: Packet proto=6 192.168.209.1:10200 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_7];[fw4_1];fw_log_drop_ex: Packet proto=6 192.168.209.1:10000 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10100 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10200 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_15];[fw4_0];fw_log_drop_ex: Packet proto=6 192.168.209.1:10300 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_14];[fw4_2];fw_log_drop_ex: Packet proto=6 192.168.209.1:10400 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_12];[fw4_6];fw_log_drop_ex: Packet proto=6 192.168.209.1:10500 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_14];[fw4_2];fw_log_drop_ex: Packet proto=6 192.168.209.1:10400 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10300 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_4];[fw4_7];fw_log_drop_ex: Packet proto=6 192.168.209.1:10500 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_6];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.209.1:10300 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_4];[fw4_7];fw_log_drop_ex: Packet proto=6 192.168.209.1:10400 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;
;[cpu_12];[fw4_6];fw_log_drop_ex: Packet proto=6 192.168.209.1:10500 -> 192.168.209.17:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW_Policy" rule 129;

 

 

Preview file
31 KB
0 Kudos
3 Replies
PhoneBoy
Admin
Admin
‎2019-08-04 10:18 PM

Was it all connections to this server being dropped in this manner or just some?
Note that when you swap cables to a new set of appliances, established connections will be dropped as they will be "out of state" on the new appliance.
0 Kudos
Northy
Contributor
‎2019-08-05 01:41 AM
In response to PhoneBoy

At that time of night there was not a lot of traffic that was being passed through the firewall. I had waited over an hour trying to troubleshoot and restarted my own connection attempts several times to no avail

 

rule 41 is simply

 

src: internal networks          dst: 192.168.209.0/24              service:any                action:allow 

 

This particular piece of traffic does not use an automatic NAT currently there is no specific rule that has been created for this traffic to pass after it has been NAT'd.

However, this traffic passes after NAT without issues and does not need a rule on the current firewall.

I have searched the policy for 192.168.209.1 in the source field permitting the destination network of 192.168.209.17

here is a capture that i had gotten from the working FW 

bond20.6:i0 (IP Options Strip (in))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:i1 (Stateless verifications (in))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:i2 (fw multik misc proto forwarding)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:i3 (SecureXL conn sync)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:i4 (fw VM inbound )[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I5 (SecureXL inbound)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I6 (fw SCV inbound)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I7 (passive streaming (in))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I8 (TCP streaming (in))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I9 (IP Options Restore (in))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond20.6:I10 (Chain End)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:o0 (IP Options Strip (out))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:o1 (TCP streaming (out))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:o2 (passive streaming (out))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:o3 (Stateless verifications (out))[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:o4 (fw VM outbound)[1500]:10.30.185.17 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:O5 (SecureXL outbound)[1500]:192.168.209.1 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:O6 (TCP streaming post VM)[1500]:192.168.209.1 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:O7 (IP Options Restore (out))[1500]:192.168.209.1 -> 192.168.209.17 (TCP) len=1500 id=24939;
bond10.609:O8 (Chain End)[1500]:192.168.209.1 -> 192.168.209.17 (TCP) len=1500 id=24939;

 

As you can see it appears to process correctly and passes the traffic on without issues and i get the web page to return.

 

However if you look at the capture i have from the non working fw below

bond20.6:i0 (IP Options Strip (in))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i1 (Stateless verifications (in))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i2 (fw multik misc proto forwarding)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i3 (SecureXL conn sync)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i4 (fw VM inbound )[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I5 (SecureXL inbound)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I6 (fw SCV inbound)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I7 (passive streaming (in))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I8 (TCP streaming (in))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I9 (IP Options Restore (in))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:I10 (Chain End)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:o0 (IP Options Strip (out))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:o1 (TCP streaming (out))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:o2 (passive streaming (out))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:o3 (Stateless verifications (out))[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:o4 (fw VM outbound)[52]:10.30.185.17 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:O5 (SecureXL outbound)[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:O6 (TCP streaming post VM)[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:O7 (IP Options Restore (out))[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:O8 (Chain End)[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;


bond20.6:i0 (IP Options Strip (in))[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i1 (Stateless verifications (in))[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i2 (fw multik misc proto forwarding)[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i3 (SecureXL conn sync)[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;
bond20.6:i4 (fw VM inbound )[52]:192.168.209.1 -> 192.168.209.17 (TCP) len=52 id=26209;

 

It appears to successfully go through the firewall in the first section of the capture then immediately after i see it looks like it is processed against the chain again and ultimately dropped against the FW VM Inbound which i presume is the no rule drop. 

 

If it does require a specific rule due to being a manual NAT then i dont understand how the current firewall operates and passes the traffic.

 

open to further comments and being told im wrong, at least then i can fix it. 

 

TIA 

 

 

0 Kudos
Wolfgang
Authority
Authority
‎2019-08-04 11:05 PM

Northy,

can you please show us allowing rule number 41.

Regarding your writing and screenshot the first part of your connection is allowed (10.30.185.15 => 192.168.209.17:443) and 10.30.185.17 is source NATed to 192.168.209.1.

But your NATed connection is not allowed, because there exists no rule for these. If you don't use automatic NAT you have to allow 10.30.185.17 and 192.168.209.1 as source in your rule for allowing this traffic.

best regards

Wolfgang

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

View All ≫
Upcoming Events

    CheckMates Events