Hi all

From some time on I've got the feeling that there is something wrong in my soho network configuration, as I might be browsing the Internet and sometimes it seems that network transactions are broken. I enabled logging on my RB750Gr3 version 4, and I'm seeing a lot of messages in the logfile that I suspect might not be simple external network scans.

I mostly see two type of strange log lines. All examples here use my at the time public IP of 79.155.36.196.

DROP_INPUT_INVALID :

I have set the firewall rule just to block invalid incoming connections. For example, I've got the following log lines that appear to be legit answers from Google and Facebook to my NATted ports, as they originate from port 443 and seem to be part of an ongoing TCP transaction.

3 ;;; defconf: drop invalid connections
chain=input action=drop connection-state=invalid log=yes log-prefix="DROP_INPUT_INVALID"

16:50:37 firewall,info DROP_INPUT_INVALID input: in:internet out:(unknown 0), connection-state:invalid src-mac 9c:cc:83:cf:20:b6, proto TCP (ACK,FIN,PSH), 34.117.65.55:443->79.155.36.196:53633, len 100
16:50:38 firewall,info DROP_INPUT_INVALID input: in:internet out:(unknown 0), connection-state:invalid src-mac 9c:cc:83:cf:20:b6, proto TCP (ACK,FIN,PSH), 34.117.65.55:443->79.155.36.196:53632, len 100
16:51:04 firewall,info DROP_INPUT_INVALID input: in:internet out:(unknown 0), connection-state:invalid src-mac 9c:cc:83:cf:20:b6, proto TCP (ACK,FIN,PSH), 34.117.65.55:443->79.155.36.196:53633, len 100
16:51:05 firewall,info DROP_INPUT_INVALID input: in:internet out:(unknown 0), connection-state:invalid src-mac 9c:cc:83:cf:20:b6, proto TCP (ACK,FIN,PSH), 34.117.65.55:443->79.155.36.196:53632, len 100
16:51:43 firewall,info DROP_INPUT_INVALID input: in:internet out:(unknown 0), connection-state:invalid src-mac 9c:cc:83:cf:20:b6, proto TCP (ACK,FIN,PSH), 157.240.5.61:443->79.155.36.196:46820, len 91


DROP_FWD_INVALID :

Another rule similar to the previous one, but in this case drops invalid outgoing connections. All requests seem to be legit, from devices in my network going to HTTPS port to addresses belonging to Facebook, Akamai, Apple or Amazon in the following examples.

4 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=yes log-prefix="DROP_FWD_INVALID"

16:39:51 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 42:9f:76:4e:79:e6, proto TCP (ACK,FIN,PSH), 192.168.81.222:46820->157.240.5.61:443, len 52
16:39:54 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 42:9f:76:4e:79:e6, proto TCP (ACK,FIN,PSH), 192.168.81.222:46820->157.240.5.61:443, len 52

16:55:57 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 98:50:2e:82:50:6b, proto TCP (RST), 192.168.81.35:56266->92.123.57.151:443, len 40
16:55:57 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 98:50:2e:82:50:6b, proto TCP (RST), 192.168.81.35:56266->92.123.57.151:443, len 40

17:11:14 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 98:50:2e:82:50:6b, proto TCP (RST), 192.168.81.35:56343->17.253.122.199:443, len 40
17:11:14 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 98:50:2e:82:50:6b, proto TCP (RST), 192.168.81.35:56343->17.253.122.199:443, len 40
17:11:14 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 98:50:2e:82:50:6b, proto TCP (RST), 192.168.81.35:56344->17.253.122.199:443, len 40

17:28:05 firewall,info DROP_FWD_INVALID forward: in:bridge out:internet, connection-state:invalid src-mac 14:98:77:77:05:45, proto TCP (RST), 192.168.81.32:54174->52.84.66.100:443, len 40


So, my question is why is this happening. My best guess is that the connections might be timing out on the router before they do in the public servers, and then, on the DROP_INPUT_INVALID I can see that is rejecting the FIN because the connection is already dead in the router conntrack. Same way on the DROP_FWD_INVALID because the RST might be trying to recover an already dead connection in the router conntrack. Is this what could be happening?

I'd love to hear your thoughs and possible solutions. There are about 1000 log lines of this every 4 hours, so I wonder if this issue is the problem affecting the perceived connection failures I have while surfing the web.

Just for more info, single ISP WAN connection with no intermediate ISP router, I'm using a RB750Gr3 v4 firmware 7.9.2 behind a UniFi UFiber LoCo. Here are the configured timeouts

[admin@MikroTik] > /ip/firewall/connection/tracking/print
enabled: auto
tcp-syn-sent-timeout: 5s
tcp-syn-received-timeout: 5s
tcp-established-timeout: 1d
tcp-fin-wait-timeout: 10s
tcp-close-wait-timeout: 10s
tcp-last-ack-timeout: 10s
tcp-time-wait-timeout: 10s
tcp-close-timeout: 10s
tcp-max-retrans-timeout: 5m
tcp-unacked-timeout: 5m
loose-tcp-tracking: yes
udp-timeout: 10s
udp-stream-timeout: 3m
icmp-timeout: 10s
generic-timeout: 10m
max-entries: 225280
total-entries: 100

Thanks!!

This is "just normal", it is a problem in the Linux kernel that has been present for many many years.
A normal ending for a TCP connection is FIN / FIN_ACK / ACK but sometimes the last ACK may be lost and after a timeout the FIN ACK is retransmitted.
But then, as you guessed, the conntrack entry has already been deleted and the packet is not belonging to any connection and is seen as invalid.
(of course, the conntrack entry should have been kept for another 3 minutes to allow to recognize such extra packets)

Also, some systems have modified the sequence to FIN / FIN ACK / RST (I think this is Windows only). But the same problem occurs.

So there is not really something you can do, except not logging these events and not worrying about it.

Thanks a lot for the answer!

If I might ask for some more questions, I have updated my original post with the conntrack timeouts, I would say those are the router defaults, but do they seem ok?

Thanks!!

It is not possible to fix this issue with timeout settings. In some cases conntrack rules are deleted immediately.
Just remove the logging on the "invalid" rule, or insert extra rules before it that match the cases you see (and that do no logging) so you can still log invalid packets without cluttering the log with these.

Got the same problem. For packets incoming from LAN, I add "reject: tcp reset" just before the default invalid filter.
It's clean up the "intended" invalid flag we want.

Lokamaya