MikroTik

I came across the following in Mikrotik log:

invalid forward: in:bridge out:ether1, src-mac xx..., proto TCP (RST), 10.0.0.204:57914->23.3.109.12:443, len 40
(iphone to an Akamai)
invalid forward: in:bridge out:ether1, src-mac ...., proto TCP (ACK,FIN), 10.0.0.152:60806->54.173.8.102:80, len 52
(amazon stick to amazon)

this is logged by "drop forward state=invalid" rule.
NAT is configured to "masquerade" everything going through WAN port.

Could you tell me what is "invalid" about that? (I've read that it is mostly about badly NAT-ed packets... but the devices in question have no issues connecting to the internet, on top of masquerade rule simply saying "whatever goes through WAN")



Second question, unexpected inputs (SYN):

src-mac ....., proto TCP (SYN), 89.248.162.161:42541-> mikrotik:13413, len 40
...

I see a number of those, is it someone scanning my net? Curious is that those come in packs from various IPs:

invalid forward: in:bridge out:ether1, src-mac xx..., proto TCP (RST), 10.0.0.204:57914->23.3.109.12:443, len 40
invalid forward: in:bridge out:ether1, src-mac ...., proto TCP (ACK,FIN), 10.0.0.152:60806->54.173.8.102:80, len 52

Really depends on context ... It is expected to happen right after router reboot because then it doesn't have any notion of existing (before reboot) end-to-end connections and any packet belonging to those connections will be seen as invalid. This state should recover as clients establish new connections.
Another possibility is packet loss ... so router already changed its connection status while client did not ... this would imply packet loss inside LAN, such as dropped packets due to wifi woes (e.g. client changing serving AP or some such) .

I see a number of those, is it someone scanning my net?

There's always somebody (something) scanning net. Personally I don't care about packets being dropped (unless debuging some connectivity issues), I care more aboout packets not dropped.

I came across the following in Mikrotik log:

invalid forward: in:bridge out:ether1, src-mac xx..., proto TCP (RST), 10.0.0.204:57914->23.3.109.12:443, len 40
(iphone to an Akamai)
invalid forward: in:bridge out:ether1, src-mac ...., proto TCP (ACK,FIN), 10.0.0.152:60806->54.173.8.102:80, len 52
(amazon stick to amazon)

this is logged by "drop forward state=invalid" rule.

Thus is caused by the premature deletion of the connection entry for TCP in Linux.
When the router sees a close of the TCP session (FIN/ACK FIN) it immediately deletes the connection entry, instead of setting it to a timeout of say 30 seconds.
The result is that when the ACK FIN is not received by the other side, due to packetloss in the network, it will be re-transmitted, the packet will not match a connection entry, and it will be deemed "invalid".
This same thing can happen with a superfluous RST that is transmitted by some operating systems as a final packet after FIN/ACK FIN/ACK sequence.

It really is a bug. But as others write, best is to not log invalid packets, just live with them. You could also decide to pass invalid packets when the protocol is TCP and the TCP flags are RST or ACK FIN, or not to log that case.

Thus is caused by the premature deletion of the connection entry for TCP in Linux.
When the router sees a close of the TCP session (FIN/ACK FIN) it immediately deletes the connection entry, instead of setting it to a timeout of say 30 seconds.
The result is that when the ACK FIN is not received by the other side, due to packetloss in the network, it will be re-transmitted, the packet will not match a connection entry, and it will be deemed "invalid".
This same thing can happen with a superfluous RST that is transmitted by some operating systems as a final packet after FIN/ACK FIN/ACK sequence.

It really is a bug. But as others write, best is to not log invalid packets, just live with them. You could also decide to pass invalid packets when the protocol is TCP and the TCP flags are RST or ACK FIN, or not to log that case.

Would it be OK to simply ignore (not drop) invalid packets originating from my LAN (drop incoming)?

What do you mean with "ignore (not drop)"?
As I said, the easiest is to remove the log flag on that rule.
In a NAT router, you can also consider removing the entire rule. It does not really accomplish much: invalid traffic from WAN would be blocked because of the NAT anyway.

Future reference:
- https://www.alibabacloud.com/blog/tcp-c ... ess_595798
- viewtopic.php?t=85039