Hello
latest long-term
WAN and LAN
I see in the conntrack table a lot of connection to not-active IPs
they are in conntrack
established
but on the class 185.208.44.xxx there are NOT IP active.
only the router has the first ip of the class, the other are currently unallocated.
why I see them established and inserted in the conntrack ?
thank you
If you take a closer look, you’ll notice several things in common to all those connections:
Although a TCP session is not actually established until the initial “three-way handshake” is completed, the connection tracking sets connection-state to established immediately when the initial packet is accepted by /ip firewall filter. So as you say “currently unallocated”, I guess your firewall rules do not drop incoming packets towards 185.208.44.0/24, hence their arrival creates tracked connections in connection tracking.
Since the initial packets are larger than a normal SYN one would be, I’d assume their arrival is caused by some malicious activity. If they weren’t for unallocated addresses, I would think these are hangovers of connections which you terminate on the firewall before they actually end (your reduction of tcp-established-timeout), but that’s clearly not the case here.
Hello
I have seen that the reply is 0.
The ip addresses are currently unallocated.
I dont have a rule to drop packets to that network since it will be allocated in the future.
So how should I do to avoid these connections builing in the conntrack table?
You may disable loose TCP tracking (so TCP packets without a SYN flag which do not belong to already existing connections will be marked with connection-state=invalid and thus dropped before they reach any permissive rule), or you may implement a similar measure manually (action=drop protocol=tcp tcp-flags=!syn after the action=accept connection-state=established,related).
Maybe “Sniffer” can tell what is actually sent.
Any connection or business with South Korea from Ravenna Italy?
Hello
for sure they are romaing packets of some kind of scanner or similar else.
however not legit traffic.
I tried with loose = no to see what happens.
This is the internet as it is today. You will have to live with it!
All over the place there are “scanners” which try all possible IP addresses to see what is there.
Both small scans that try to find something that is vulnerable at that time, but also broad scans that simply scan everything (all ports) and build databases of the results.
Such results can then be browsed by paying members of the service.
It sure is a nuisance, especially when you have a lot of public IP addresses. But when you have routable IP space on internet, you will have to live with it.
For now, you can build an address list like “unallocated-addresses” and add all addresses to it that you have not yet used for something.
Then you can drop all incoming traffic to those addreses in a “ip firewall raw prerouting” entry.
Remember when using an address for something, you need to remove it from that address list.
And of course at that time the problem will return.
Hello
I know that that is the internet.
My only concern was “how to AVOID filling up the conntrack table with non existent connections?”
Now I have disabled LOOSE TCP Tracking .
I’m curious if that will change anything. I expect that it won’t.
(AFAIK “loose” TCP tracking only means that connections are setup for every packet, not only for SYN packets. so in “loose” mode it will pickup an existing established connection when the router is rebooted, and in “strict” mode it will not)
Well.
what happens if the router is rebooted in NAT mode?
every connection will be dropped, so no issue.
I just dont want to have the conntrack table full of connections towards unconnected ip.
I have dropped on my border router the number of connection considerably. I have seen that now the request just timeouts after a couple of seconds since the SYN is unanswered.
I think that is a better setting now.
Ok but when you have a larger number of addresses, you would normally not be using NAT mode (at least not on the border router).
In the general case of a router that does not do NAT, a reboot of the router would not interrupt a TCP connection with loose tracking, but it would do so with strict tracking.
(all connections have to be setup again after a router along the path is rebooted)
That can be a reason to use loose tracking. When that does not apply to your network configuration, by all means use strict tracking.
I did not know that a SYN packet would be handled differently in loose and strict tracking.
I agree.
In my personal situation I have set the strict tracking on all the tower routers (not on the customer’s router) and on the border router where I have also fasttrack on some networks.
In the tower router, I conntrack only who has NAT and also public IP, but I love now seeing the conntrack tables that after a couple of seconds deletes the entry of a rogue syn packet (port scan or similar).
In loose tracking I see a lot of unaccounted connections there pending…
When I reboot a router, I have to restart the connection, so I dont see an issue for now.
I will try with strict all the way then I will report here.
The only drawback, I am no longer able to do nmap -sS scans!