You could modify the settings under "/ip firewall connection tracking". Most connections will implement a keep-alive if they need it open for a long time. I'm using est timeout of 30m with no issues

This works well. I use a 5 minute time and have no issues. There is almost nothing doing a keep-alive quicker than that.

Thanks for the replies! So if I am downloading a file from the Internet, say CentOS 7 DVD or something larger that takes a few hours on slower Internet, would it kill that after 30 minutes? If not, maybe it would work.

This works well. I use a 5 minute time and have no issues. There is almost nothing doing a keep-alive quicker than that.

... but users who use SSH to get a terminal on a remote system will hate you for it.
It is possible to set a keepalive in the server config but usually it isn't done by default.

ssh -o ServerAliveInterval=30

Code: Select all

ssh -o ServerAliveInterval=30

(without any change on server side) will send keep-alive packet every 30 seconds. Keeps even the most zealous firewalls from breaking idle connection.
N.b.: the above command works with OpenSSH, I'm not sure about other implementations.

TCP sessions should be able to last days without a router breaking them.

What is the use-case here of opening a ssh session and letting it sit for 30 minutes with NO data flowing in either direction? The established timeout is after last packet sent...

Edit: actually that would even be a security issue!

• the boss interrupting me for half an hour in the middle of a long task. By far the most common.
• monitoring of a log that has little activity. So I do a less xxx ->F or a tail -F xxx and wait for something nasty to happen, looking into it from time to time in the hope to react on time to something bad.
• Slow ssh session establishment due to GSS API timeouts or other flukes... and I have a standby session to be ready for intervention. Not so common.

Hello, i would like to extend this topic further, i have similar situation where lots of connections are established toward my client with 0/0 orig rate and bytes. I see that these connections are established backward only when client established connection to some https server. How i can filter such behavior and not brake client connection?
Any ideas why it's happening?
Personally i suppose, that this is some malicious behavior on client side and i want hold this number of unneeded connections low as possible on my router.
fw1.PNG

Hello, i would like to extend this topic further, i have similar situation where lots of connections are established toward my client with 0/0 orig rate and bytes. I see that these connections are established backward only when client established connection to some https server. How i can filter such behavior and not brake client connection?
Any ideas why it's happening?
Personally i suppose, that this is some malicious behavior on client side and i want hold this number of unneeded connections low as possible on my router.

/ip firewall connection remove [find where !seen-reply timeout>"30s" protocol=tcp src-address~":443"];

I have to start from quite a faraway point. One would expect that a firewall would only allow a TCP connection to establish when it receives a SYN packet from a client towards the server. But this requires a bit more resources to analyse the packets, so the connection tracking module allows to reduce the load by reducing the requirements, through setting /ip ipsec connection tracking loose-tcp-tracking to yes. And this setting is a default one, and for years it even was not available as a configuration item. With this setting, any TCP packet, even a mid-connection one, will create a tracked connection in the firewall.

Now you can see in your table that the source port is 443 (https), which is not the usual way how TCP connections are established - normally, the TCP server listens at a given port (443), and TCP clients use arbitrary ports above 10000 (depends on OS and settings), so the first packet's source port is, say, 54321 and destination port is 443.

But if someone else sends a SYN packet to 2.18.76.90:443 from the public IP address of your client, the server responds to the source address and port of that request, so the response lands at your client's WAN interface. With loose-tcp-tracking set to no, such packets will be dropped (because they are SYN,ACK ones); with loose-tcp-tracking set to the (default)yes, it creates a connection with a 5-minute lifetime.

So one explanation is that someone is running a SYN-flood attack to 2.18.76.90:443, spoofing the address of your client, and your firewall creates tracked connections due to this.

Setting loose-tcp-tracking to no should hide this issue from you. Even if your client doesn't need to connect to 2.18.76.90:443, the worst that can happen is that the admin of 2.18.76.90:443 will send your client's address to some list of spammers so the client will be denied access to other sites as well.

Another explanation is that your client actually does connect to 2.18.76.90:443, but the server doesn't respond, so the connection times out on both the client PC and the firewall, and when the response comes from the server, the client PC already ignores it.

If nothing helps then you could use a scheduled script every one minute and one second like this to remove those stale connections:

Code: Select all

/ip firewall connection remove [find where !seen-reply timeout>"30s" protocol=tcp src-address~":443"];

Hello, i would like to extend this topic further, i have similar situation where lots of connections are established toward my client with 0/0 orig rate and bytes. I see that these connections are established backward only when client established connection to some https server. How i can filter such behavior and not brake client connection?
Any ideas why it's happening?
Personally i suppose, that this is some malicious behavior on client side and i want hold this number of unneeded connections low as possible on my router.
fw1.PNG