dns01 gateway renders a terminate and a passthrough listener under one SNI on the pinned Cilium #3718

A dns01 or existingSecret tenant Gateway renders https (terminate, port 443, hostname *.<apex>) alongside one tls-<svc> listener (passthrough, port 443) per tlsPassthroughServices entry. The wildcard's SNI match covers <svc>.<apex>, so the two carry an intersecting SNI. The shipped default puts three of them on every Gateway-enabled cluster: api, vm-exportproxy, cdi-uploadproxy.

This predates the TLS-passthrough listener work and needs none of it: the two fields involved are certMode and tlsPassthroughServices, both long-standing.

The pin is v1.19.5, from packages/system/cilium/images/cilium/Dockerfile. On that version desiredEnvoyListener in operator/pkg/model/translation/envoy_listener.go builds one Envoy listener for the whole Gateway and hangs the ports off AdditionalAddresses, and toFilterChainMatch in the same file matches on transport_protocol and server_names only. Upstream describes what that costs above NeedsCrossProtocolSplit in operator/pkg/model/model.go as of v1.19.6:

Filter chains from different Gateway listener ports must not share any SNI match because a combined Envoy listener would otherwise erase the original Gateway listener port boundary and route traffic for one listener to another.

Note that this pair shares a port rather than crossing two, and the same comment says the same-port case "cannot be fixed by per-port listeners and needs to be rejected before translation", so the v1.19.6 split does not close it either.

What is not verified. No cluster was involved. The claim that Envoy rejects or mis-routes a listener carrying two filter chains with identical match criteria is taken from reading the translation, not from Envoy's own source and not from observed behaviour. The intersection is established from the code above; the consequence is not. Someone with a dns01 gateway can settle it by reading the Gateway's listener conditions and the Envoy config dump.