Strangeness with UDP packets filtering by src port

[fewizz_]

Good day!

I have virtual CheckPoint - Open Server, SMS + SG R81.20 take 634 with Jumbo take 98 installed, with interfaces/topology:

Then I have 2 access rules (ignore first 2):
1. Drop, UDP service: dst port - 1-65535, src port - 5566
2. Accept, any

Example case:
Traffic is sent by host 1.0.0.2, consists of 10 UDP packets, src IP - 1.0.0.1X, dst IP - 2.0.0.2, src MACs are randomized, dst MAC is MAC of eth0; ports used for packets:
src port dst port
  3745      8823
  5566      8823
  2346      8899
  1026      7478
  5566      8899
  9328      8899
  5566      5478
  5566      8899
  1239      2348
  8345      8899

We expect that 4 packets should be dropped (with src port = 5566) and 6 packets should be accepted

In reality, sometimes first access rule (according to logs) drops other packets too. Amount of falsely dropped packets varies - from 0 (i.e., works as expected) to 4 (worst case yet)

Notes:
* Looks like it doesn't depend on Topology choosen for eth0 and eth1 (tried other variants)
* It works just fine if there are no repeating dst ports (like 8899 and 8823 in the example above)
* Doesn't look like sending those packets with time gap changes anything (tried from 1 ms to 1 s)

Question is - is this expected?
And if so, where can i learn why this happens?

Thank you.

[PhoneBoy]

We track connections via five-tuple (IP protocol. Source IP, Source Port, Destination IP, destination port).
You are repeating the usage of source ports for both the source and destination in a short period of time, which means it looks like the same connection attempt.
These logs are suppressed per the "Excessive Log Grace Period" set in Global Properties.

This is expected behavior
In any case, you should be able to confirm with a tcpdump or similar the traffic is not getting through the firewall.

[fewizz_]

Thank you for the response!

I should have clarified (sorry for that) that `X` in src IP 1.0.0.1X varies from 0 to 9 for all 10 packets,

i. e. there should be collisions no between five-tuples:

, so I don't think that `Excessive log grace period` option is related

And traffic is actually getting through (listening on 2.0.0.2):

Dropped packets:

Example of falsely dropped packet:

[PhoneBoy]

I assume the reason this is happening is a bug of some sort.
Your best bet is to open a TAC case.