Firewall Connection, TCP established to non-existent IPs

[pukkita]

@Caci99

This is a topic about understanding very well ip tables, which I don’t .
Anyway, an established connection is not the same with an established tcp. What could be happening is, if the client closes the http connection without sending an ack packet (or something like that), so the router considers the connection established because it was there before, but unreplied because it is kept alive only from one side of the connection. This is my guess.

The only scenario would be an established (I refer to TCP state) connection where the client sends an ACK,FIN or an ACK which is later not replied by the server, or (most probably) a hiccup in conntrack leaving these orphan connections as-is with a 24Hour timeout…

I don’t think it is a bug, but rather the nature of how router deals with the connections.
This needs a very thorough analyze of the whole connection from the begin to the end of it, in both sites, client and server from someone who has time and good knowledge of how ip tables works > > .

I don’t know what is it, but… why doesn’t these connections get marked properly?

90% connections get marked properly and behave as expected, w/o these “stalled” connections. Then, amongst the “stalled” ones, only a 5% of these Unreplied, TCP state established “orphan” connections are marked properly, the rest seem to “jump” to the latest marking mangle rule…

[Caci99]

@pukkita

I don’t know what is it, but… why doesn’t these connections get marked properly?

90% connections get marked properly and behave as expected, w/o these “stalled” connections. Then, amongst the “stalled” ones, only a 5% of these Unreplied, TCP state established “orphan” connections are marked properly, the rest seem to “jump” to the latest marking mangle rule…

That, again, would depend on how the router considers these connection. As we know, the mangle will apply mark according to the chain. In which chain they will belong is kind of mystery to me, or if they do even skip the chain process at all, because the router itself does not know where to put them (maybe?).

[pukkita]

Let’s put it in a clear way:

Public IP -----> Router ------> Internet
a.b.c.d:54321 -------------------> f.g.h.i:443

All connections traversing the router go through the forward chain.
I’m marking on the forward chain based on that criteria (destination port tcp 443).

Say in connections, there are 1000 connections from a.b.c.d to f.g.h.i; what I am seeing is:

• About 9500 of these connections will have consistent TCP states, and would have been marked correctly.
• 50 of these connections will have unconsistent TCP state, BUT still are marked correctly.
• 450 of these connections will have an unconsistent tcp state (established while being unreplied), AND won’t be correctly marked.

[irufan]

any one found a fix for this issues.
i have the same problem but connection status confirmed and timeout of 24hr.

[sysPanda]

Somewhat old topic but it might help someone.
Not really a solution but a workaround based on some of the upper posts:

:foreach i in=[/ip firewall connection find protocol=udp seen-reply=no timeout<00:59:30] do={/ip firewall connection remove $i};
:foreach i in=[/ip firewall connection find protocol=tcp seen-reply=no timeout<23:59:30] do={/ip firewall connection remove $i};

This drops all connections that had not received a reply for 30 seconds. Values are based on the default timeout settings.
I have scheduled this to run every minute and it works without problems so far.

Cheers.