Custom conntrack timeouts not working
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	ryanzuwala
	May 23 2025, 7:20 PM

Description

While working on T7456, I noticed that custom timeout rules do not work at all.

For example, suppose I have a server with IP address 172.16.99.2, and I want custom timeouts for specific types of traffic originating from this server. So I configure the following:

configure

# UDP rule using DNS as an example
set system conntrack timeout custom ipv4 rule 1 destination port '53'
set system conntrack timeout custom ipv4 rule 1 protocol udp replied '700'
set system conntrack timeout custom ipv4 rule 1 protocol udp unreplied '700'
set system conntrack timeout custom ipv4 rule 1 source address '172.16.99.2'

# TCP rule using HTTPS as an example
set system conntrack timeout custom ipv4 rule 2 destination port '443'
set system conntrack timeout custom ipv4 rule 2 protocol tcp close '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp close-wait '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp established '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp fin-wait '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp last-ack '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp syn-recv '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp syn-sent '700'
set system conntrack timeout custom ipv4 rule 2 protocol tcp time-wait '700'
set system conntrack timeout custom ipv4 rule 2 source address '172.16.99.2'

commit ; save

This produces the correct configuration in nftables.

The correct jumps are happening in the firewall table, because when I generate traffic, the correct counters are incrementing.
For instance, if I run dig @8.8.8.8 facebook.com on my server, I see the following in nft:

chain VYOS_CT_TIMEOUT {
                ip saddr 172.16.99.2 udp dport 53 counter packets 1 bytes 81 ct timeout set "ct-timeout-1" comment "timeout-1"
                ip saddr 172.16.99.2 tcp dport 443 counter packets 0 bytes 0 ct timeout set "ct-timeout-2" comment "timeout-2"
                return
        }

As you can see, the counter for my DNS rule incremented, so the rule is matching the packet flow as expected. But when I inspect the conntrack table, the timeout is incorrect:

vyos@vyos:~$ show conntrack table ipv4 | grep 172.16.99.2
1077743376  172.16.99.2:49126    8.8.8.8:53             8.8.8.8:53             192.168.1.136:49126  udp                      27         0

It's showing 27 seconds, meaning the record was inserted with the default 30 seconds for unreplied UDP traffic, when I had specifically configured it for 700 seconds for this matching rule.

The same is true for TCP traffic. If I run conntrack -E | grep "172.16.99.2" on VyOS, and run wget on the server:

conntrack -E shows events like this:

tcp      6 120 SYN_SENT src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 [UNREPLIED] src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634
tcp      6 60 SYN_RECV src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634
tcp      6 432000 ESTABLISHED src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634 [ASSURED]
tcp      6 120 FIN_WAIT src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634 [ASSURED]
tcp      6 60 CLOSE_WAIT src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634 [ASSURED]
tcp      6 10 CLOSE src=172.16.99.2 dst=X.X.X.X sport=52634 dport=443 src=X.X.X.X dst=192.168.1.136 sport=443 dport=52634 [ASSURED]

The timeouts are incorrect - they are using the default global timeouts.

But the nft table shows the counter incremented as expected, so the traffic rule did match:

chain VYOS_CT_TIMEOUT {
                ip saddr 172.16.99.2 udp dport 53 counter packets 3 bytes 207 ct timeout set "ct-timeout-1" comment "timeout-1"
                ip saddr 172.16.99.2 tcp dport 443 counter packets 1063 bytes 66515 ct timeout set "ct-timeout-2" comment "timeout-2"
                return
        }

At first I thought maybe a kernel module isn't being properly loaded into memory before the firewall rules are loaded, such as nfnetlink_cttimeout.ko.

I'm still investigating this, and will hopefully have a PR containing the fix soon. Unless someone else in here has more knowledge about this and wants to submit a PR.