Skip to content

fix(xds): don't create empty filter chain for a gateway #15532

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
lukidzi wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(xds): don't create empty filter chain for a gateway #15532

lukidzi wants to merge 1 commit into from

Conversation

@lukidzi
Copy link
Contributor

@lukidzi lukidzi commented Feb 4, 2026

Motivation

Delegated gateways with transparent proxy enabled were failing with:

  xds.nack-backoff    config was previously rejected by Envoy. Applying backoff before resending it {"reason": "Error adding/updating listener(s) inbound:passthrough:ipv4: error adding listener '0.0.0.0:15006': no filter chains specified\n..."}

The issue occurs when all these conditions are met:

  • Delegated gateway (no inbounds defined)
  • Transparent proxy enabled
  • mTLS with STRICT CA backend mode
  • FeatureStrictInboundPorts feature flag enabled (default in newer versions)

In CreateInboundPassthroughListener, the condition if useStrictInboundPorts would enter a loop over proxy.Dataplane.Spec.Networking.Inbound to create per-port filter chains. For delegated gateways with no inbounds, this loop produces zero filter chains, causing Envoy to reject the listener.

Implementation information

  • Modified the condition in CreateInboundPassthroughListener from if useStrictInboundPorts to if useStrictInboundPorts && len(proxy.Dataplane.Spec.Networking.Inbound) > 0
  • When no inbounds exist, the code now falls through to the else branch which creates a default passthrough filter chain
  • Updated the test case to properly cover the delegated gateway scenario with strict mTLS and FeatureStrictInboundPorts enabled

@lukidzi lukidzi marked this pull request as ready for review February 4, 2026 15:41
@lukidzi lukidzi requested a review from a team as a code owner February 4, 2026 15:41
@lukidzi lukidzi requested review from Automaat and slonka February 4, 2026 15:41
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2026

Reviewer Checklist

🔍 Each of these sections need to be checked by the reviewer of the PR 🔍:
If something doesn't apply please check the box and add a justification if the reason is non obvious.

  • Is the PR title satisfactory? Is this part of a larger feature and should be grouped using > Changelog?
  • PR description is clear and complete. It Links to relevant issue as well as docs and UI issues
  • This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as an image registry)
  • IPv6 is taken into account (.e.g: no string concatenation of host port)
  • Tests (Unit test, E2E tests, manual test on universal and k8s)
    • Don't forget ci/ labels to run additional/fewer tests
  • Does this contain a change that needs to be notified to users? In this case, UPGRADE.md should be updated.
  • Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@slonka slonka Awaiting requested review from slonka slonka is a code owner automatically assigned from kumahq/kuma-maintainers

@Automaat Automaat Awaiting requested review from Automaat Automaat is a code owner automatically assigned from kumahq/kuma-maintainers

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@lukidzi