Iptables (UFW). ufw-before-input. limit not working

Hi.
I have a Debian 12 server.
I am trying to switch from UFW to pure iptables.
I read a couple of books, but I don't know where to look for answers to some questions.

Here is the code from the UFW "rules.before" file.
The last line is a test rule:

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

-A ufw-before-input -p icmp --icmp-type echo-request -m limit --limit 3/minute --limit-burst 5 -j DROP
...

Why it doesn't drop my pings?

I found this. (An error occurred: Sorry you cannot post a link to that host.).
Addited rules like this:

-A ufw-before-input -p icmp --icmp-type any -s MyIP -m limit --limit 10/minute -j ACCEPT
-A ufw-before-input -p icmp --icmp-type any -s MyIP -j DROP

Checked policy DROP.

Chain INPUT (policy DROP 336 packets, 17659 bytes)
num      pkts      bytes target     prot opt in     out     source               destination
1    39807145 12087771749 ufw-before-logging-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
2    39807145 12087771749 ufw-before-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
3    29742002 9111642453 ufw-after-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
4     1016273 58759815 ufw-after-logging-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
5     1016273 58759815 ufw-reject-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
6     1016273 58759815 ufw-track-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0

Checked chain ufw-before-input.

Chain ufw-before-input (1 references)
num      pkts      bytes target     prot opt in     out     source               destination
1           0        0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
2        1739   105738 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
3           3      120 ufw-logging-deny  0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
4           3      120 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
5           0        0 ACCEPT     1    --  *      *       MyIP        0.0.0.0/0            icmptype 255 limit: avg 10/min burst 5
6           0        0 DROP       1    --  *      *       MyIP        0.0.0.0/0            icmptype 255
7           0        0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
8       10991  3298318 ufw-not-local  0    --  *      *       0.0.0.0/0            0.0.0.0/0
9           0        0 ACCEPT     17   --  *      *       0.0.0.0/0            224.0.0.251          udp dpt:5353
10          0        0 ACCEPT     17   --  *      *       0.0.0.0/0            239.255.255.250      udp dpt:1900
11      10991  3298318 ufw-user-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0

I used the online ping tool and the source part of the rule works fine.. Nobody accept me can ping my server.
--- MyIP ping statistics ---

It is so simple. I don't understand what can be wrong.

I installed and configured nftables. Along the way, I learned to use conntrack and understood the problem.
ICMP gets into the conntrack table as related and hangs there for 30 seconds, and the next request passes according to the rule estalished, related.
But for some reason I thought that if there is an ICMP request and an ICMP reply, then after the reply the connection is closed and the next request passes as a new connection. And this is a mistake.