Cilium gateway api wildcard hostname bug #44118

Is there an existing issue for this?

• I have searched the existing issues

Version

equal or higher than v1.18.6 and lower than v1.19.0

What happened?

What happened?

Gateway API wildcard hostname matching between Gateway listeners and HTTPRoute hostnames does not work. When a Gateway listener has a wildcard hostname (e.g. *.lab.inqbeo.org) and an HTTPRoute specifies a concrete hostname (e.g. testweb.lab.inqbeo.org), the route is accepted by the control plane (Accepted: true) but never programmed into the CiliumEnvoyConfig. No virtualHosts are generated for the route, resulting in a 404.

Per the [Gateway API specification](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.Listener), wildcard hostnames are interpreted as a suffix match:

Hostnames that are prefixed with a wildcard label (*.) are interpreted as a suffix match. That means that a match for *.example.com would match both test.example.com, and foo.test.example.com, but not example.com.

And the [HTTPRoute hostnames spec](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec) states:

If both the Listener and HTTPRoute have specified hostnames, any HTTPRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the HTTPRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match.

This means a listener with *.lab.inqbeo.org and a route with testweb.lab.inqbeo.org must result in a match. Cilium currently does not match them, silently dropping the route.

Root Cause Analysis

Note: This analysis was done with the help of Claude AI by reading the Cilium source code on Fossies and GitHub. The conclusions below may be inaccurate — please verify against the actual code.

The bug is in the route filtering logic in gateway_reconcile.go. The filterHTTPRoutesByGateway function calls:

len(computeHostsForListener(listener, route.Spec.Hostnames, nil)) > 0

This function computes the intersection of the listener hostname and route hostnames. It appears to perform exact string comparison rather than wildcard-aware matching. Since *.lab.inqbeo.org != testweb.lab.inqbeo.org, the intersection returns empty and the route is filtered out before it ever reaches the ingestion/translation stage.

This is why the control plane reports Accepted: true (the route check validations pass independently) but the route is never translated into Envoy configuration.

A secondary concern exists in the Envoy translation layer: if wildcard hostnames are passed into filterChainMatch.serverNames, Envoy rejects them (see #27099). The translation layer would also need to handle wildcard-to-concrete hostname resolution correctly.

Expected Behavior

• Listener *.lab.inqbeo.org + HTTPRoute testweb.lab.inqbeo.org → intersection is testweb.lab.inqbeo.org, route is programmed
• Listener *.lab.inqbeo.org + HTTPRoute foo.bar.lab.inqbeo.org → no match (wildcard only covers one level), route is correctly rejected
• Listener *.lab.inqbeo.org + HTTPRoute with no hostnames → intersection is *.lab.inqbeo.org, route is programmed

Related Issues

• Cilium Gateway API Not Working - App Inaccessible Externally #38606 — Identical scenario (*.domain.dev listener + argocd-gateway.domain.dev HTTPRoute), reported as "not working" but root cause not identified
• Gateway API: serverNames should be unset if hostname not specified in Gateway config #27099 — Envoy rejects * in serverNames (secondary translation-layer issue)
• Gateway API - RequestRedirect loops indefinately scheme change from http to https #28796 — Hostname matching issues (different scenario, but touches same code path)
• Gateway: Combining listeners with HTTPS and TLS protocol #32292 — Combining HTTPS and TLS listeners with wildcard hostnames
• Error using multiple allowedRoutes.namespaces.from selectors on a gateway #34288 — Fixed reordering of computeHostsForListener checks, but did not fix the intersection logic itself

How can we reproduce the issue?

Minimal Reproducer

Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: lab-gateway
  namespace: gateway-api
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: "*.lab.inqbeo.org"
      allowedRoutes:
        namespaces:
          from: All

HTTPRoute (BROKEN — accepted but not programmed):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: testweb
  namespace: default
spec:
  parentRefs:
    - name: lab-gateway
      namespace: gateway-api
      sectionName: http
  hostnames:
    - testweb.lab.inqbeo.org
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: testweb
          port: 80

Result: The HTTPRoute shows Accepted: true in status, but the generated CiliumEnvoyConfig contains no virtualHosts for testweb.lab.inqbeo.org. Traffic returns 404.

Cilium Version

Tested on Cilium 1.18.1. Based on code review and issue history, this has been broken since at least v1.14.

Kernel Version

6.x (not kernel-dependent — this is operator-level logic)

Kubernetes Version

v1.35.0 (RKE2)

Regression

No response

Sysdump

No response

Relevant log output

No errors in operator logs — the route is silently filtered out. The only observable symptom is missing virtualHosts in the CiliumEnvoyConfig output.

Anything else?

No response

Cilium Users Document

• Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

• I agree to follow this project's Code of Conduct