firewall: flush stale UDP conntrack entries on port_forward setup/teardown

[shivkr6]

Add a new netlink_netfilter module to interact with the kernel's conntrack table using the netlink_packet_netfilter crate. This module allows dumping and deleting conntrack entries. All firewall drivers now call the new flush_udp_conntrack() function during port forwarding setup and teardown.

When a container with a UDP port mapping is started, stale conntrack entries can prevent traffic from reaching the new container instance. This change proactively deletes these stale entries for the mapped UDP ports, ensuring that new connections are not dropped by the kernel.

Fixes: #1045

NOTE: This PR cannot be merged right now because:
1) I'm waiting for my PRs to be merged in the netlink-packet-netfilter crate. [DONE]
2) I have to write integration tests to test this functionality. [DONE]
3) netlink-packet-netfilter new release

CC: @Luap99 @mheon

[shivkr6]

The unit tests seem to be failing because conntrack-tools is not installed in CI/CD

[shivkr6]

Finished writing the integration tests for flushing conntrack entries.

Question: Is it possible to install conntrack-tools in the CI/CD test environment? conntrack-tools is needed for some of the unit tests.
CC: @Luap99 @mheon

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[shivkr6]

I moved the conntrack entries flushing code to the end of all setup_port_forward and teardown_port_forward functions, instead of keeping it at the start, to avoid a potential race condition where a new conntrack entry is created after the flush but before the port forwarding rules are completely set up.

[Luap99]

Question: Is it possible to install conntrack-tools in the CI/CD test environment? conntrack-tools is needed for some of the unit tests.

Yes we can do that. I make that happen.

[Luap99]

#1363 this should include conntrack now

(once that merges you can rebase)

[Luap99]

#1363 was merged so CI should have access to conntrack I hope.

[shivkr6]

I'll do the remaining changes tomorrow Done.

[mheon]

I have an error message nit, but on the whole LGTM

[Luap99]

just so it is not overlooked, we cannot merge this while the upstream lib isn't merged so I mark as changes requested

[Luap99]

Forgot to say overall great work!

[shivkr6]

I have no idea why the firewalld: receive udp traffic with pre-existing stale conntrack entry (range) test is failing even after successfully the flushing the conntrack entries. IDK why socat inside the container still cannot receive the udp traffic :(

Please help @Luap99 @mheon

[shivkr6]

Forgot to say overall great work!

Thanks! The appreciation from you and Matt really keeps my motivation and confidence high

[shivkr6]

It's extremely weird that the firewalld: receive udp traffic with pre-existing stale conntrack entry (range) integration test passes when I change the container_port from 8081 to 8080.
This passes successfully:

@test "firewalld: receive udp traffic with pre-existing stale conntrack entry (range)" {
    setup_firewalld
    export NETAVARK_FW="firewalld"
    # Explicitly add a rule to trigger connection tracking.
    run_in_host_netns firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -p udp -m state --state NEW -j ACCEPT
    run_ct_udp_flush_test "${TESTSDIR}/testfiles/bridge-udp-stale-conntrack-range.json" "127.0.0.1" "10081" "8080"
}

[shivkr6]

I skipped the firewalld: receive udp traffic with pre-existing stale conntrack entry (range) test because port forwarding range seems to be broken with firewalld. All the traffic gets redirected to the first container port no matter which host range port you pick. It's not an issue related to conntrack.

[mheon]

Tests green, just waiting on that upstream library now. Nice work @shivkr6

[shivkr6]

Thanks @mheon. The bigger PR, rust-netlink/netlink-packet-netfilter#12, got merged. The remaining smaller PRs yet to be merged are rust-netlink/netlink-packet-netfilter#14 and rust-netlink/netlink-packet-netfilter#15

CC @Luap99

[polarathene]

The remaining smaller PRs yet to be merged are rust-netlink/netlink-packet-netfilter#14 and rust-netlink/netlink-packet-netfilter#15

Those two appear to be merged now. Any other blockers?

EDIT: Crate needs to publish a new release, since there doesn't seem to be any activity there pushing that along I've opened an issue requesting that.

[shivkr6]

@polarathene , the maintainer of the rust-netlink crates, said:
“I don't want to release the current codebase as a new version because I dislike the current Subsystem layout.”

He wants the subsystem layout of netlink-packet-netfilter to be similar to netlink-packet-route.
We had this discussion in the rust-netlink Matrix channel.

I’m open to doing the subsystem layout rewrite around February or March 2026; I have some exams right now.

[polarathene]

@polarathene , the maintainer of the rust-netlink crates, said:
“I don't want to release the current codebase as a new version because I dislike the current Subsystem layout.”

I don't see how that's a release blocker 🤔

• 0.3.0 / 0.2.1 could be released in the interim (it's been 2 years since that crate really saw any activity until your contributions)
• New version bump for the subsystem layout refactor.

No worries though, thanks for chiming in with an update! 😁

[Luap99]

@polarathene That is not up for us to decide but the maintainer of that crate though.