When should I turn off loose TCP tracking?

AlohaSpark · Thu Mar 02, 2023 10:56 am

I am implementing sticky connections using connection and routing marks. I'm wondering if loose TCP tracking has any effect on mangles.

1. What is it for?
2. When should I turn off loose TCP tracking?
3. Does it impact performance? By how much?

R1CH · Thu Mar 02, 2023 7:07 pm

It's for picking up existing connections.

E.g.:

User opens connection to tcp.example.com port 22, sends and receives data. Router has NAT entry to handle outbound / inbound packets.
Disaster! Router crashes or reboots for some reason. Or the router has NAT timeouts too low and the NAT entry expires before the connection is closed.
User sends more data over their connection:
- With loose tracking: Router sees that it's part of a connection, re-establishes NAT entry. Connection continues fine. User is happy.
- Without loose tracking: Router ignores packet as it's not part of an existing NAT entry. Connection is in INVALID state. User's connectivity is disrupted.

No performance impact.

anav · Fri Mar 03, 2023 3:01 am

My understanding ( and ensuring we are talking about connections tracking, loose TCP tracking checkbox ) is that better security is provided by ENSURING loose tracking is NOT selected.
In this way the default drop rules with INVALID ( in both chains) is even better able to discern and capture invalid packets and drop them.

Amm0 · Fri Mar 03, 2023 3:42 am

They're done at different places in the kernel. So it's more a "belt-and-suspenders" approach to do both. "loose" likely doesn't do much, however, since the default route is included also a "connected route". See viewtopic.php?t=141545&hilit=rp+filter.

I generally leave it on, since "loose" is generally the default in Linux. Now argument for not doing that is IF rp-filter is actually dropping packets, that likely be invisible to connection tracking – potentially a difficult thing to troubleshoot – or even know since it's likely not tracked in firewall counters. (haven't verify it, but imagine rp-filter kicks in before packet get to the firewall, but dunno for sure)

And "strict" can cause issues if you NAT/mangle anything, since the strict reverse path check might fail. This one I can't recommend since lots of ways "strict" checks would block perfectly fine/safe routing.

anav · Fri Mar 03, 2023 4:49 pm

RP filter strict if I recall correctly is not a good plan with multi-wan.

Amm0 · Fri Mar 03, 2023 5:05 pm

RP filter strict if I recall correctly is not a good plan with multi-wan.

"Strict" is really bad plan for any "multiwan" setup. It will certainly break with any dynamic routing protocol like BGP, OSPF. rp-filter is very old feature, designed for clients as a basic firewall since early desktop TCP stacks didn't come with any system firewalls.

"Loose" does very little, if anything because the default route is includes. I really only enable because with Verizon LTE, ANY packet without wrong src-addr will drop the connection – so "loose" covers any milliseconds where a packet might escape firewall/conntrack because of masquerade re-recalculation. I just leave it on, since it might help if you're using "masquerade".

There is a kernel feature to enable logging of drops (fun name, "log_martians") but AFAIK that's not enabled – so very hard to know if it kicks in, in either "strict" or "loose"...

DarkNate · Sat Mar 04, 2023 1:36 am

You should turn off loose TCP tracking when you want to burn your CPU and performance.

AlohaSpark · Sat Mar 04, 2023 3:36 am

You should turn off loose TCP tracking when you want to burn your CPU and performance.

I had it off to begin with. I turned it on 2 days ago. CPU usage did not decrease.

Actually, turning on loose TCP tracking seems to have solved my RDP/Remote Desktop issues. The connection doesn't drop anymore (which might be an issue with TCP timings, as the post I marked as answer suggests).

anav · Sat Mar 04, 2023 10:16 pm

Disagree,

I always ensure TCP connection tracking is strict.......... for better security.

TCP CONNECTION TRACKING STRICT
"if a TCP packet with a given unique combination of source and destination addresses and ports does not match any existing connection, it is new if it contains the SYN flag (and has zero payload length), otherwise it is invalid

TCP CONNECTION TRACKING LOOSE (default)
"if a TCP packet with a given unique combination of source and destination addresses and ports does not match any existing connection, it is new, regardless if it has SYN flag etc......). ALL packets will be considered new and the INVALID rule is thus basically transparent............ However the MT docs also use the terminology of a packet not having any state OR the packet cannot be identified, it then matches for invalid, so there may be some small advantage to the invalid default rule and thus we keep it regardless in the usual firewall rule setup.

R1CH · Sat Mar 04, 2023 10:23 pm

The INVALID rule will still function to prevent non-NATted connections from going out. It offers no extra "security" to use strict tracking, it only causes users grief when their valid connections get dropped by over-aggressive timeouts or router reboots. How is a client sending an ACK to reestablish a NAT entry any different from them sending a SYN? Either you trust the clients behind your NAT or you don't...

There's a reason it defaults to enabled.

anav · Sun Mar 05, 2023 3:12 am

Sorry RICH1, understand your points but unless SOb and MKX state its harmful I will keep it strict. I think it does more good and no harm.

DarkNate · Sun Mar 05, 2023 4:51 am

I had it off to begin with. I turned it on 2 days ago. CPU usage did not decrease.

Actually, turning on loose TCP tracking seems to have solved my RDP/Remote Desktop issues. The connection doesn't drop anymore (which might be an issue with TCP timings, as the post I marked as answer suggests).

You are not pushing 300Gbps traffic full duplex. When we deploy large scale CGNAT boxes delivery 100Gs of traffic, strict TCP tracking = millions of dollars required to invest in more powerful hardware. We always use loose TCP tracking.

DarkNate · Sun Mar 05, 2023 4:52 am

The INVALID rule will still function to prevent non-NATted connections from going out. It offers no extra "security" to use strict tracking, it only causes users grief when their valid connections get dropped by over-aggressive timeouts or router reboots. How is a client sending an ACK to reestablish a NAT entry any different from them sending a SYN? Either you trust the clients behind your NAT or you don't...

There's a reason it defaults to enabled.

I only have “drop invalid” on input chain. Never in forward chain even if everything is a public /22 (IPv4) and public /32 (IPv6). We've observed it breaks legitimate traffic such as WireGuard (UDP) for the customers.

Sob · Sun Mar 05, 2023 5:05 am

@anav: It might break your heart, but did I mention that I don't know everything?

anav · Sun Mar 05, 2023 3:05 pm

Sob you are officially retired......

So breaking this up...... and Sob, although you are now officially fired, feel free to regain some courage to provide input on this post ..... ;-P

Invalid rule:
Are folks saying that it can get in the way of connectivity (wg was noted) if used in the forward chain, but it can remain on the input chain as traffic to the router is not similarly harmed by the invalid rule?

TCP strict connection Tracking ( and its application to or in combination with invalid )
Another reason to avoid in the forward chain is the volume of traffic and load on the CPU, for no appreciable gain
It can be kept on the input chain because the volume is LOW, and the added security for traffic to the router is not a bad thing.

R1CH · Sun Mar 05, 2023 6:28 pm

I only have “drop invalid” on input chain. Never in forward chain even if everything is a public /22 (IPv4) and public /32 (IPv6). We've observed it breaks legitimate traffic such as WireGuard (UDP) for the customers.

If everyone is on a public IP, then I agree that DROP INVALID in forward is unnecessary, its main purpose in a NAT setup is to prevent leakage of private IPs onto the internet. Ideally you would not do any kind of conntrack when using public IPs.

Amm0 · Sun Mar 05, 2023 6:43 pm

Just make sure we're talking about the same things... there are TWO different "loose things" in play, not sure everyone is talking about the same ones here...

I always ensure TCP connection tracking is strict.......... for better security.

1 - /ip/firewall/connection/tracking set loose-tcp-tracking=yes

Disable picking up already established connections

2. - /ip/settings/set rp-filter=loose

Disables or enables source validation.
[...] The current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDoS attacks. If using asymmetric routing or other complicated routing or VRRP, then the loose mode is recommended.
Warning: strict mode does not work with routing tables

I wish I knew where the rp-filter one fits in the packet flow diagram that's something I've never understood. Now the exact interplay with them and firewall's invalid and/or NAT get complex, so I'm not sure there is some hard-and-fast rule here... Maybe?

DarkNate · Sun Mar 05, 2023 8:10 pm

If everyone is on a public IP, then I agree that DROP INVALID in forward is unnecessary, it's main purpose in a NAT setup is to prevent leakage of private IPs onto the internet. Ideally you would not do any kind of conntrack when using public IPs.

If you're using NAT, you should drop using the raw table.
https://help.mikrotik.com/docs/display/ ... d+Firewall

/ip fi raw
add action=drop chain=prerouting comment="defconf: drop non global from WAN" src-address-list=not_global_ipv4 in-interface-list=WAN
add action=drop chain=prerouting comment="not LAN" src-address-list=!lan_subnets in-interface-list=LAN

Linux's "invalid" state mechanism is imperfect from day 1:
https://superuser.com/questions/1713555 ... tion-assur

NAT or no NAT, dropping "invalid" risks dropping valid packets. I've seen happening too often, by simply logging the rule and checking out each dropped packet with WireShark.

DarkNate · Sun Mar 05, 2023 8:12 pm

I wish I knew where the rp-filter one fits in the packet flow diagram that's something I've never understood. Now the exact interplay with them and firewall's invalid and/or NAT get complex, so I'm not sure there is some hard-and-fast rule here... Maybe?

In vanilla Linux, rp-filter likely occurs before or immediately after sk_buff.

On ASIC offloaded hardware like Juniper, it occurs on the ASIC itself, hardware offloading.

anav · Sun Mar 05, 2023 10:30 pm

Okay it does seem to appear to be some consensus to not use the invalid rule in the forward chain for sure.
So we are left to the merits of
A. use of the invalid rule in the input chain
B. use of tcp connection tracking strict on its own
C. use of tcp connection tracking strict in conjunction with the invalid rule in the input chain.

When should I turn off loose TCP tracking? [SOLVED]

When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking? [SOLVED]

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Re: When should I turn off loose TCP tracking?

Who is online