It is my experience as well! The cause appears to be down in the Linux kernel, as other devices running Linux tend to do the same thing.
The most common problem is occuring at the end of a TCP session. When the TCP session is closed (FIN/FIN ACK) the NAT connection tracking entry is immediately deleted.
However, when the other side has not received the FIN ACK and re-transmits the FIN, the upper layer answers with an RST and it is not translated because it does not match the “new” filter.
This exhibits itself as 2 different problems:
- untranslated traffic sometimes being routed
- when you have a strict connection tracking firewall that allows all established/related and some new traffic, then drops or rejects everything with logging, you will get TCP FIN and RST packets logged in the firewall that are completely innocent (belong to successfully accepted connections)
To fix this, TCP connection tracking entries should get an extra timer to keep them lingering after connection close, maybe like 10 or 30 seconds, to catch any FIN re-transmits and RST responses.
However, that probably would have to go via the Linux developers to get it in the main kernel sources. It could be that this already has happened and a new kernel version would fix it, but I have no indications of that.