Hi All,
I am getting a lot of connections in the Firewall which showing same source address and port to random IP in my network (which are not in use). the protocol is TCP and state established.
Any one has similar issues? How could a TCP connection to non-existence IP has state “established” ?
est-hack.png
To random LAN IP address or random WAN’s ports ?
UDP 7124 is QuickTime Streaming Server but maybe it uses also TCP ?
Look at the first letter of those connections, U - Unreplied
I also have noticed this and the “stablished” TCP State puzzled me also because I also saw that on non running IPs belonging to our public subnet, from outside hosts scanning whole IP ranges for vulnerabilities…
A search on that returned some unconclusive matches, still looking for the issue.
In the meanwhile you can blackhole your most generic subnet route.
I tried recently to make a script that would remove the unreplied + established connections from conntrack but I haven’t succeeded so far. Looks like the selection doesn’t give back numbers to be removed…
I wonder what are these connections? How could it be its TCP state is established but unreplied? Why do they “phantom” mangle marking???
I’ve noticed these connections “build up” also from hosts in my LAN to https servers outside, and have three things in common:
Is this a bug, or something usual with iptables?
it’s public ip routing, all destination IP address are not in use, might consider make them honeypots.
can’t blackhole your entire subnet just because only 5% IP are being used.
can’t blackhole your entire subnet just because only 5% IP are being used.
5% used or unused?
What I meant is setting a blackhole route more general than the rest you should have for “active” IPs, that way traffic to unactive IPs will be blackholed.
5% used, a lot of unused IP that’s why Unreplied.
Assume we have 20k IPs where 10% (2k) are unused. Maintaining the blackhole routing will not be an easy job.
I tried (as mentioned before) such script:
:foreach i in=[/ip firewall connection find tcp-state=established assured=no] do={
/ip firewall connection remove $i};
But it does nothing. How can I automatically remove such records?
What concerns me more is why do those connections exist (when are initiated by legit hosts from inside to outside) to start, removing it is fixing the symptom not the cause.
I don’t know how to remove them apart from manually.
My connections are not suspicious by their addresses. They just seem to be forgotten traffic by their src side but not killed on router level. I don’t understand much how it happens.
Me neither… and why they seem to dodge through mangle marking rules.
Most are https connections, guess this is related?
An official word from mikrotik would be great to shed some light on this “X Files” issue.
Many of them in my case are from computer that has more interfaces connected to the lan. When used interface goes down its internal routing table is updated and traffic is redirected through the next interface. It has different ip so router probably keeps already opened connections for some time. Then the first interface goes up, but the programs initiate new connections as the previous were not existing within the computer anymore. Looks like error in conntrack management of ros.
Could this be related?
http://forum.mikrotik.com/t/connection-tracking-counters-wrong/85622/1
It looks so…
My conntrack is set to yes.
And this Unreplied/established TCP-state stale connections build up happens also with regular HTTP.
Indeed… In my case there isn’t any NAT in between, and hosts are connected through just one interface.
I can confirm that there is no difference whether the connection tracking is iset to “auto” or to “yes”. The effect is the same.
Has anyone created a ticket to mikrotik support about this error?
Try putting instead of assured=no seen-reply=no
My guess is this are invalid connections generated for whatever reason. If you put in firewall filter a rule with drop action for invalid connections you might see less of these connections.
I already have drop invalid for forward and input/output chains, making no difference.
I am also dropping invalid by default. And anyway I am dropping by default everything on the end of each chain. Of course I have no rule that would accept invalid packets before.
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.
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 .