TLS Passthrough Query #5177
-
|
Goodnight all, I've noticed that when setting up TLS Passthrough that the only consistent pattern is I deploy a solution ( Deployment + Service + TLSRoute )in one namespace with a TLSRoute. If I try to set up multiple solutions in the same namespace, the routing behaves like a load balanced solution even if I specify different hostnames. I've almost noticed if I have the same hostname with different ports (433, 10443) I've noticed that the 443 port would work and not the 10443. This is on NGF 2.5.0 with Gateway API CRDs 1.5.0 on the standard channel. Has anyone else observed this behaviour? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
|
@TPSKaizen would you be able to provide the Gateway/TLSRoute configurations you're using? We can attempt to reproduce the issue. |
Beta Was this translation helpful? Give feedback.
-
OS InformationWSL version: 2.7.3.0 Windows Host File Configuration127.0.0.1 brian-dev.personapp.com WSL Resolve ConfThis file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:[network]generateResolvConf = falsenameserver 10.255.255.254 Minikube Versionminikube version: v1.38.1 Docker Desktop Version ( Windows )Version 4.55.0 (213807) Engine: 29.1.3 Compose: v2.40.3-desktop.1 Credential Helper: v0.9.4 Kubernetes: v1.34.1 Gateway.yaml :apiVersion: v1
Frontend YAML - SITapiVersion: gateway.networking.k8s.io/v1
Sun May 24 08:23:05 PM -04 2026 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I tried to reproduce this on NGF 2.6.3 with the following setup: A Gateway in the I ran a continuous curl loop against The generated NGINX stream config also looked correct with separate unix sockets and upstreams per hostname, with the SNI map correctly isolating each route. It's possible this was a bug in an earlier version that has since been fixed. I'd recommend upgrading to 2.6.3 and seeing if the behavior goes away. |
Beta Was this translation helpful? Give feedback.
Hi, I tried to reproduce this on NGF 2.6.3 with the following setup:
A Gateway in the
gatewaysnamespace with 4 TLS Passthrough listeners on port 443 forbrian-dev.personapp.com,brian-sit.personapp.com,api.brian-dev.personapp.com, andapi.brian-sit.personapp.comTwo backend deployments (
personappfe-devandpersonappfe-sit) both in the samepersonappfenamespace, each serving TLS on port 8443 with self-signed certs.Two TLSRoutes also in the same
personappfenamespace, each pointing to their respective backend and listener via sectionNameI ran a continuous curl loop against
brian-dev.personapp.comand consistently got responses only from the DEV pod, no responses from the SIT pod at all.…