Multiple TLSRoute on shared Gateway do not work

[abhijith-darshan]

kgateway version

v2.1.2

Kubernetes Version

v1.33.7

Describe the bug

When creating a shared gateway and applying multiple TLSRoutes only the first TLSRoute is accepted where as the others are ignored

Example Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: virtual-gateway
  namespace: gitops-system
spec:
  gatewayClassName: kgateway
  listeners:
    - protocol: HTTPS
      port: 8443
      hostname: "*.virtual.gitops.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - name: virtual-gateway-tls
            kind: Secret
            group: ""
      name: https
      allowedRoutes:
        namespaces:
          from: All
    - name: tls
      protocol: TLS
      port: 443
      tls:
        mode: Passthrough
      allowedRoutes:
        namespaces:
          from: All
status:
  addresses:
  - type: IPAddress
    value: 10.237.149.136
  conditions:
  - lastTransitionTime: "2026-02-02T15:22:18Z"
    message: ""
    observedGeneration: 2
    reason: ListenerSetsNotAllowed
    status: Unknown
    type: AttachedListenerSets
  - lastTransitionTime: "2026-02-02T15:22:18Z"
    message: Successfully accepted Gateway
    observedGeneration: 2
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2026-02-02T15:22:18Z"
    message: Successfully programmed Gateway
    observedGeneration: 2
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2026-02-02T15:22:18Z"
      message: Successfully accepted Listener
      observedGeneration: 2
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2026-02-02T15:22:18Z"
      message: Successfully verified that Listener has no conflicts
      observedGeneration: 2
      reason: NoConflicts
      status: "False"
      type: Conflicted
    - lastTransitionTime: "2026-02-02T15:22:49Z"
      message: Successfully resolved all references
      observedGeneration: 2
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2026-02-02T15:22:49Z"
      message: Successfully programmed Listener
      observedGeneration: 2
      reason: Programmed
      status: "True"
      type: Programmed
    name: https
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
  - attachedRoutes: 2
    conditions:
    - lastTransitionTime: "2026-02-02T15:22:18Z"
      message: Successfully accepted Listener
      observedGeneration: 2
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2026-02-02T15:22:18Z"
      message: Successfully verified that Listener has no conflicts
      observedGeneration: 2
      reason: NoConflicts
      status: "False"
      type: Conflicted
    - lastTransitionTime: "2026-02-02T15:22:18Z"
      message: Successfully resolved all references
      observedGeneration: 2
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2026-02-02T15:27:33Z"
      message: Successfully programmed Listener
      observedGeneration: 2
      reason: Programmed
      status: "True"
      type: Programmed
    name: tls
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: TLSRoute

First TLSRoute with Accepted status

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: TLSRoute
metadata:
  name: simon-admin
  namespace: greenbox-simon
spec:
  hostnames:
  - simon-admin.virtual.gitops.example.com
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: virtual-gateway
    namespace: gitops-system
    sectionName: tls
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: simon-admin
      port: 443
      weight: 1
status:
  parents:
  - conditions:
    - lastTransitionTime: "2026-02-02T15:27:33Z"
      message: ""
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2026-02-02T15:27:33Z"
      message: Successfully resolved all references
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    controllerName: kgateway.dev/kgateway
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: virtual-gateway
      namespace: gitops-system
      sectionName: tls

Second TLSRoute is ignored

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: TLSRoute
metadata:
  name: simon-remote
  namespace: greenbox-simon-remote
spec:
  hostnames:
  - simon-remote.virtual.gitops.example.com
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: virtual-gateway
    namespace: gitops-system
    sectionName: tls
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: simon-remote
      port: 443
      weight: 1

Of course when trying to access the endpoint you receive -

Unable to connect to the server: tls: failed to verify certificate: x509: certificate is valid for simon-admin.virtual.gitops.example.com, not simon-remote.virtual.gitops.example.com

The only way I can achieve successful request routing is I create Per TLSRoute a Unique Gateway.

This feels a little too expensive and I hoped following the blog - https://kgateway.dev/blog/shared-gateways/ would help out for TLSRoutes but only works for HTTPRoutes.

Expected Behavior

Both TLSRoutes should be accepted and ready for request routing.

Steps to reproduce the bug

1. Apply Gateway
2. Apply simon-admin TLSRoute
3. Next Apply simon-remote TLSRoute
4. Observe only the first TLSRoute has accepted status and the second one is ignored.

Additional Environment Detail

No response

Additional Context

No response

[nXtCyberNet]

Hi, can I work on this issue if it hasn’t been assigned to anyone yet?

[abhijith-darshan]

Hi, can I work on this issue if it hasn’t been assigned to anyone yet?

Hey @nXtCyberNet If you are asking me, I am just a consumer for now, running POCs of Gateway implementation for ingress-nginx migration and I encountered this issue and reported it. It would be great if the maintainers accept this issue as a Bug and someone can start the work on it soon.

[sheidkamp]

See also #13458