Thanks, fix makes logical sense but just for awareness there are a few specific cases where Cilium currently requires ip(6)tables, tracked by #12879.

You will need to rebase against main and force-push (no merge commits please). For more info see the development guide (but note it's OK if you can't change labels, that's normal until you're a member of the org).

/test

@javiercardona-work would you mind dropping the merge commit, rebase against main and force-push to update? Then we can run the tests & mark to merge.

/test

@joestringer Can someone help me understand the failing test? I do not think it is related to this change.

Sure. I'll demonstrate the steps below that you can follow along for future reference. Ginkgo test results present in their own slightly different way from the other failures, but the general GitHub UI navigation stuff should be a common pattern for understanding failures. This should be pretty similar to the CI Triage guide for developers in the docs.

Triage

• Followed the link to the ci-ginkgo failing test
• Clicked the left hand side navbar link that reported the failure for E2E Test
• Scrolled up to see the summary failure for [Fail] K8sDatapathLRPTests Checks local redirect policy [AfterEach] LRP connectivity
• Scrolled up to find the actual test failure result:

• Failure in Spec Teardown (AfterEach) [234.830 seconds]
K8sDatapathLRPTests
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
  Checks local redirect policy
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
    LRP connectivity [AfterEach]
    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515

    Found 1 io.cilium/app=operator logs matching list of errors that must be investigated:
    2026-01-30T19:05:15.489552351Z time=2026-01-30T19:05:15.48931064Z level=error source=/go/src/github.com/cilium/cilium/pkg/logging/klog_bridge.go:175 msg="\"Error initially creating lease lock\" err=\"leases.coordination.k8s.io \\\"cilium-operator-resource-lock\\\" already exists\" lock=\"kube-system/cilium-operator-resource-lock\"" subsys=klog

    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:413

Check for existing failures

• Searched the error Error initially creating lease lock in the Issues tab, found CI: Conformance Ginkgo: cilium-operator-resource-lock already exists #44082.
• Newly reported, seems like maybe there's a generic issue that exists in the tree already which affects multiple Ginkgo tests, first seen as part of a BGP library update PR deps, bgp: Bump GoBGP version to most recent v3.37 fork #44073 (cc @YutaroHayakawa)
• Notably, this failure seems related to k8s control plane coordination at L7 but this PR is about mutating iptables / L3 connectivity.

Is this codepath exercised?

• Back to the main failure link, scroll to the bottom to find artifacts
• cilium-sysdumps-bugtool-1.34-f18-datapath-lrp has a full dump of state at the time of the failure
• For Ginkgo failures the failure itself inside the zip in nested directories for the specific test has a cilium-sysdump.zip, which has a more comprehensive set of info
• cilium-configmap-*.yaml file has enable-ipv6: true but no install-iptables-rules.
• git grep for InstallIptRules, condition checked in the PR, shows that the field is enabled by default
• Conclusion: For the failing test, the same code was exercised both before and after the change; the change should effectively be a noop for this scenario. (Anecdotally we do not test the --install-iptables-rules=false so this is expected)

We can follow up on the failure in #44082, it doesn't need to block this PR. I've retriggered the failing test.