All incoming traffic on Spark 1800 blocked by implied rule 0

[Alex-]

1800 running R81.10.05.

Remote Access blade is enabled as well as S2S VPN and there are some incoming NAT pointing to DMZ services.

Since a few days, the firewall decided that all incoming traffic should be blocked on implied rule 0 except for the S2S VPN.

The firewall itself has been running OK since a year.

All DMZ traffic stopped, Remote Access isn't possible anymore and we see in the logs that this traffic is dropped on Implied rule 0.

Disabling and enabling the RA blade doesn't help, rebooting the firewall neither as well as changing policy mode, disabling IPS and whatnot.

Also tried to add a permissive rule for incoming traffic but same thing about the implied rule.

This is likely not a network issue. All outbound traffic is working perfectly and NATted behind the same general public IP of the firewall. S2S VPN works anyway.

Checked advanced options and everything around, no dice. CLI debug also show drop from implied rule 0 for any incoming traffic that should be allowed (DMZ, Remote Access).

Any advice is appreciated. I can't make a TAC case for now as the customer is going through renewal but the blades themselves are covered until 2025.

[G_W_Albrecht]

Looks like you will need TAC to resolve this - also, you provided no details at all that could help to find a reason for the issue...

[Chris_Atkinson]

Can you confirm if the appliance is locally or centrally managed?

Sharing the output of your debugs would also be helpful...

[Alex-]

Locally managed.

It's a classical network setup, LAN to WAN (IPv4 public IP directly on the FW) and S2S/RA blades. S2S keeps working, outbound traffic works, inbound RA doesn't as well as inbound DMZ.

Each time in the logs of the firewall, as well as the CLI debug, all incoming traffic except S2S is dropped by Blocked by implied rule 0. Since I can't open an SR in the short term because of the renewal process, I'm thinking of factory default the appliance since everything else has been checked but all incoming traffic except S2S. 

The closest I found was sk168516 but the scenario is different, it's R81.10.05 and not R80.20.X and the incoming traffic isn't blocked by the cleanup but by the implied rule.

[Chris_Atkinson]

The CLI debugs aren't usually that brief - implied rule 0 could be anti-spoofing but equally other things for which there are generally hints in the output.

[Alex-]

I don't get much more than that, the line repeats for any incoming traffic.

@;2933810;[cpu_9];[fw4_9];fw_log_drop_ex: Packet proto=6 <SRC IP>:57302 -> <PUBLIC FW IP>:80 dropped by fw_send_log_drop Reason: Rulebase drop - rule 0 (Internal);

[Chris_Atkinson · Accepted solution]

Further to the NAT suggestion from @PhoneBoy please check the contents of the  following:

Users & Objects tab> Network Object Groups> Blocked_infected_hosts

[Alex-]

Thanks Chris, for some reasons every single object was present in that group even though the customer told me they never modified that group. On top of that, debugs don't point to the group as a cause of blocked traffic and its content doesn't appear under the blocked items list.

In any case, the issue is solved.

[the_rock]

Good job! @Chris_Atkinson to the rescue 🙌. Im so glad @PhoneBoy provided me info on how to set up quick SMB spark demo thats good for 4 hours, so I also learned lots about some features of those appliances I never knew existed.

Thanks again everyone!

[Chris_Atkinson]

Glad it's resolved.

My next thought (specifically if 80/443 were the predominant affected services) was going to be to check if there was a NAT conflict with the Web UI or VPN visitor mode device "Advanced' settings e.g.

VPN Remote Access - Remote Access port

VPN Remote Access - Reserve port 443 for port forwarding

Traffic targeting the gateway external IP is a special case in some instances further to the above. See also: sk165937 / sk105740 / sk65028

[the_rock]

Hey @Alex- 

See if below helps.

Andy

https://community.checkpoint.com/t5/SMB-Gateways-Spark/Implied-Rules-SMB/td-p/155044

[PhoneBoy]

The NATs are to the public IP of the gateway itself, correct?
Are these being done by Server objects (which is the way to do it) or Manual NAT Rules (which may not work in this case)?

[Alex-]

The NAT is done by policy and not server objects as the DMZ entries are custom ports, the policy is in Strict mode. The fact that S2S still works but not RA/Incoming NAT after a year points to internal FW logic from my point of view, but debugs and logs don't give anymore information than this rule 0.

@Chris_Atkinson There were a couple of reported infected hosts which have been blocked, taken offline then removed from the list. In any case, they were inside and not outside. Inside traffic to outside works without issue.

@the_rock I wonder if you might be onto something. I saw that post during my search for a solution but the SK referred to older releases and hardware. Now I remember there were a few issues with the FTW out of the box (R80.20.05 if I remember correctly), it finally went through and then I'd upgrade the FW. Maybe a recent change triggered that behaviour. At that point and still unable to open an SR for that account, that might be my last option before a factory reset.

[Tom_Hinoue]

By any chance you can temporary change the firewall policy mode back to [Standard] to see if the issue resolves?
If so, you may need to involve TAC regarding the behavior with strict mode. Btw, I think we had a similar case on 700s in the past using strict mode...

[the_rock]

I think what @Chris_Atkinson was referring to is below. I honestly dont think this needs factory reset, its probably some minor setting we are missing here.

Andy

 

[G_W_Albrecht]

Opening SR# with TAC should not be an issue !