Inconsistent hostname matching in HTTPRoute with wildcards

[zeisich]

Description:
We have an HTTPRoute that is supposed to catch all traffic of a Gateway with a certain path, regardless of the host. Our Gateway has two listeners, one for a main domain, e.g. dev.business.domain.io and one for all of its subdomains *.dev.business.domain.io. We always get a 404 when we

1. Specify the hostnames of both listeners in the HTTPRoute
2. Don't specify any hostnames in the HTTPRoute

Routing is successful when we specify the subdomains explicitly. To me it seems like a bug that both cases above do not resolve.

Repro steps:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: wildcard-gateway
  namespace: envoy
spec:
  gatewayClassName: eg
  listeners:
  - hostname: '*.dev.business.domain.io'
    name: https-wildcard
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: dev.business.domain.io-gcp-publicca-dns-prod-subdomains
      mode: Terminate
  - hostname: dev.business.domain.io
    name: https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: dev.business.domain.io-gcp-publicca-dns-prod
      mode: Terminate
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: authz-3bcb14-wildcard-gateway
  namespace: envoy
spec:
  hostnames:
    - *.dev.business.domain.io
    - dev.business.domain.io
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: wildcard-gateway
      namespace: envoy
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: authserver-3bcb14-wildcard-gateway
          namespace: envoy
          port: 8080
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /_authz

Environment:
Gateway 1.2.4 with corresponding envoy version

Logs:

{
  "start_time": "2025-02-20T20:46:25.057Z",
  "method": "GET",
  "x-envoy-origin-path": "/_authz/callback?code=1.AXkACEMRLuwUd022EEkDJPoYRFcjCYRAPMJKvSVJSWF....",
  "protocol": "HTTP/2",
  "response_code": "404",
  "response_flags": "NR",
  "response_code_details": "route_not_found",
  "connection_termination_details": "-",
  "upstream_transport_failure_reason": "-",
  "bytes_received": "0",
  "bytes_sent": "0",
  "duration": "0",
  "x-envoy-upstream-service-time": "-",
  "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0",
  "x-request-id": "3dfa6870-a376-4170-9293-94513623ce7e",
  ":authority": "dev1.dev.business.domain.io",
  "upstream_host": "-",
  "upstream_cluster": "-",
  "upstream_local_address": "-",
  "requested_server_name": "dev1.dev.business.domain.io",
  "route_name": "-"
}

[arkodg]

hey this is a dup of #2675, there are some workarounds mentioned in that ticket

[zeisich]

I'm not sure this is a duplicate. I'm aware of the issue and already implemented the workaround of having dedicated certificates for both listeners, in order to get around the connection coalescing.

[arkodg]

are there any errors in the status for the Gateway or HTTPRoute ?

[zeisich]

All "green", accepted, programmed, scheduled and refs resolved.

[arkodg]

in case anyone is interested in further triaging this one, next steps here would be to add this config into the gateway-api testdata folder https://github.com/envoyproxy/gateway/tree/main/internal/gatewayapi/testdata and see what IR it generates