Firewall – Google IP sends a TCP (ACK, PSH) to the router. Known why

firewallnetworkingrouting

I am monitoring my traffic and noticed several TCP (ACK, PSH) connection attempts on my router's input chain, which gets dropped by my firewall.

The log looks like that:

Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115

Obviously this is dropped because my last rule on my input chain is to drop packets.

I do not understand the TCP protocol well enough, so sorry if this is a bit naive, but why is the request directed to my router?

I have various devices that uses google services and probably third party software as well, but it is very confusing to me, why the packet is actually sent to the router and not nat'ed to a device in my network (which would be the forward chain, right?).

I have not yet noticed a degraded experience with my devices regarding google products. Software updates, push notifications etc all seem to work correctly.

Best Answer

The phenomenon is somewhat more complex. I did some research in the according logs and want to share my guess here for all whom wondering too.

The related log entries showing drops in the input chain with TCP flags ACK and PSH (push). This indicates that some service in the network is awaiting messages from the google servers (via. push). But wait - why the package is logged in the input chain? Thats rather easy to explain - if the router (or as @chexum already mentioned - the conntrack) has no connection information about NATed/PATed traffic the package looks like traffic for the router and not for any devices behind it. So that explains why "google is sending traffic to the router".

But the question is why the router has no connection information for these packages. And here i can only speculate for now: The drops are observed in times where most users are at the internet. My guess is that googles replies took to long (mybe because it prior push traffic lower than other) so that the connection times out. The timeouts on this particular router are about 10s for TCP packages and 5s for SYN. After some more time the conntrack will remove his memory about old "invalid" traffic and from that time on every traffic from this connection looks like input traffic. Thats also one possible explanation why the invalid rules are not triggered.

I think @samuel should observe it a little more and see if any pattern is recognizable. But generally i sare @chexum oppinion that these drops are ignorable.

Related Topic