Loop prevention drops

[okatsladz454]

Good afternoon.


We are faced with the following problem - some of the packets going to certain Internet addresses are dropped at the kernel level with an error (find it in zdebug + drop):

resume_inbound_from_vm_reinject: dropping packet of for vsid=0 due to loop prevention (nloops=4, pkt_type VM Reinject, prev state Lookup, next state Lookup, in flags 0x4). 

Gaia version: R82 take 44 Maestro (Any problems with distribution and asymmetric excluded)

There are two connections - intranet and extranet, both transmit routes via BGP.

The problem occurs only on a part of the connections and only to connections at certain white addresses. There are no problems with other connections that use the same access control policy rules and the same logic.


Questions:

1. What does loop prevention even mean? Does this apply to STP? Or to routing and loop protection in BGP? fwaccel stats -d showing huge amount of drops caused by Loop prevention

2. Any clues, how to fix this?

[the_rock]

I cant seem to open image you attached (this seems to be an issue with everyone lately, anything attached shows virus scan in progress...maybe @_Val_ or @PhoneBoy can comment on that part).

Now, as far as your issue...definitely STP can be related...is it enabled or not?

[PhoneBoy]

Will check on the virus scan issue.

[the_rock]

Not a huge issue, but I did notice it for everyone whose attachments I tried opening last few days...

[PhoneBoy]

Seems to be a known issue that is in the process of being addressed.

[okatsladz454]

Thanks for the reply. I don't think STP has any effect - if it did, then loop protection would occur on all traffic, and not just on a very specific one. I need to understand specifically what loop prevention generally refers to.

[the_rock]

Usually, should be enabled.

[Chris_Atkinson]

Are these drops for legitimate traffic flows or just something that you've observed?

How is the routing configured for the subnet in question on the Firewall and downstream device...

[okatsladz454]

Good morning.

This directly affects the third party of VPN tunnels going through the firewall. Not all of them, just not a very large part, but we don't have an answer as to why these particular tunnels are affected and other are not. 

Routing is set up very simply - down (to the LAN of the organization) via BGP, up (to the provider) also via BGP, but using a public ASN.

[the_rock]

Is there any difference with those tunnels? route or domain based?

[okatsladz454]

I see no diffrence. 

They re all transit, check point just making a translation/ 

[the_rock]

Might be worth TAC case then to check further.

[the_rock]

Hey mate,

Were you able to make any progress with this?

[okatsladz454]

Good afternoon. The case in TAC was just started yet. We were waiting for the installation to be updated to the new JHF, but unfortunately it didn't help.

[_Val_]

Please open a TAC request for this via https://help.checkpoint.com

[Gennady]

Good day!

As a guess, I recommend to check output of "fwaccel ranges" command to find out if the problematic white IP-addresses are present in more than one range.

1. use "fwaccel ranges -l" to list all the ranges associated with interfaces.

2. use "fwaccel ranges -p" to see the list of networks as your SGM see it in Topology for an interface. It may be a very long list for your Internet facing interface.

The loop prevention seems to be related more to routing decision function performed in SecureXL before sending a packet out of an interface. The problem may occur in case if the same network/IP is present in more than one "anti-spoofing" range. Another way to check the same would be to analyze your routes carefully but it would not exclude any bug in topology calculation. "fwaccel ranges" from the other hand will show you exactly how routing is seen by SecureXL topology and may help to find the problem.

[Claudio_Bolcato]

Did you manage to fix the issue?
I'm experiencing the same problem and I've a TAC case open and they gave me an hotfix but the kernel debug is keep showing drops due to loop prevention. I'm running R82 take 44

[TINTIN8]

We have the same issue. TAC instructed us to upgrade to Take 60. But now take 73 is out. But its not recommended yet. Looking at the timetable and how things have changed in the past, we should expect a new version coming up pretty soon, which will be the recommended version.  It's such a pain for us, as the entire project now depends on this. 

Version	Released Date	Became Recommended upgrade	No of days between release and becoming recommended
Take 33	08 July 2025	Recommended on 16 July 2025	8 days
Take 34	23 July 2025	Recommended on 27 July 2025	4 days
Take 36	31 July 2025	Never became recommended
Take 39	27 August 2025	07 September 2025	11 days
Take 41	03 September 2025	Never became recommended
Take 43	19 October 2025	Recommended on 29 October 2025	10 days
Take 44	05 November 2025	Recommended on 23 November 2025	18 days
Take 60	29 December 2025	Recommended on 19 January 2026	21 days
Take 73	17 February 2026

[the_rock]

Take 73 seems to be stable so far.

[kamilazat]

We opened a case and TAC provided us with a hotfix and then recommended setting the parameter fwmultik_dispatcher_in_tap_mode=1. Apparently this needs to be done 'after' installing the fix. Now the issue seems to be resolved. Also there seems to be a new sk about it:

https://support.checkpoint.com/results/sk/sk184805

[TINTIN8]

Thanks @kamilazat !!! I'll get the same from TAC. So, the solution is not to upgrade to Take 60/73. We were given absolutely wrong fixes. Well, then again, this SK only came out on the 17th of March. 

[TINTIN8]

TAC gave a different solution. Run in expert mode.  It didn't break anything, so it looks safe to run during business hours.

[Expert@xxxxxxxxxxxx]# fw ctl get int dispatch_port_tap_is_activated -a
FW:
dispatch_port_tap_is_activated = 0
PPAK 0: dispatch_port_tap_is_activated = 0
dmd_mgmt: dispatch_port_tap_is_activated = 0
dmd_worker: dispatch_port_tap_is_activated = 0
[Expert@Qxxxxxxxxxxxx]# fw ctl get int dispatch_port_1_tap -a
FW:
dispatch_port_1_tap = -1
PPAK 0: dispatch_port_1_tap = -1
dmd_mgmt: dispatch_port_1_tap = -1
dmd_worker: dispatch_port_1_tap = -1
[Expert@xxxxxxxxxxx]#

[Expert@xxxxxxxxxx]# fw ctl set -f int dispatch_port_tap_is_activated 1
"fwkern.conf" was updated successfully
[Expert@xxxxxxxxxx]# fw ctl set -f int dispatch_port_1_tap 500
"fwkern.conf" was updated successfully
[Expert@xxxxxxxxxx]#

This is only valid for new connections. So you will need to delete the affected connection from the connection table 
fw ctl conntab -dport=500 -dip=51.x.x.x
If its there,
fw ctl conntab -x -dport=500 -dip=51.x.x.x
Our tunnel behind the firewall came back up immediately after deleting the stale connection above. 

We tried it, and so far so good. Didn't need to install the patch.