Endpoint-independent-nat 100% CPU

RouterOS General
1

We have noticed an issue with endpoint-independent-nat slowly using up all CPU on the router. When the NAT sules are enabled, CPU will run about 12% across all corfes and slowly ram up over 2-4 hours until it hits 100% across all cores. We have looked at the profiler and it’s the firewall process using up all the CPU. Tried creating a supout when the issue was happening and it hung at 19% for about 10 min until saying complete with no file created. Has anyone else seen this issue?

CCR2004-16G-2S+ running 7.15.3

add action=endpoint-independent-nat chain=srcnat comment=EIM-NAT disabled=yes out-interface-list=WAN protocol=udp randomise-ports=no src-address-list=cgnat_subnet src-port=1024-65535 to-addresses=x.x.x.32/30
add action=endpoint-independent-nat chain=dstnat comment=EIM-NAT disabled=yes dst-address=x.x.x.32/30 dst-port=1024-65535 in-interface-list=WAN protocol=udp randomise-ports=no to-addresses=100.96.0.0/11
add action=netmap chain=srcnat comment="CGNAT Rule" disabled=yes dst-address-list=!not_in_internet ipsec-policy=out,none out-interface-list=WAN src-address-list=cgnat_subnet to-addresses=x.x.x.32/30
add action=masquerade chain=srcnat comment="Hairpin for CGNAT clients" disabled=yes dst-address-list=cgnat_subnet src-address-list=cgnat_subnet

cgnat_subnet list has a single entry 100.96.0.0/11
WAN has 2 interfaces, we use ECMP for the uplinks to our core routers for redundancy

2

Didn’t have a deal with e-i-n, but you can probably try to supout when CPU is already high but not 100% yet (around 95%+)

3

I have the same issue. After disabling the rules, the CPU becomes normal.

CCR1009-7G-1C-1S+
7.16

4

Same situation with Mikrotik V7.19.4 after a while the CPU goes up to 100%. It would be good if Mikrotik paid attention to this problem. If one wants to create the file with the error, there's no time to do so.

5

Maybe the pool of available ports is nearing exhaustion?

6

I thought about it, but Mikrotik's endpoint-independent solution only works with UDP. And I'd like to believe that's not the problem

7

Yep. Still, each internally initiated udp connection needs its own port.

If some pretty advanced additional data structures weren't implemented, this would mean hard cpu thrashing as the number of connections approaches the limit...

It would be relatively easy to verify at least a trend towards this by counting the connections in the conntrack table...