Clarification on connection_security_policy=unknown

We are using Istio 1.24 in sidecar mode and have a slightly non‑standard deployment model: instead of placing ingress and egress gateways only at the mesh edge, we run a dedicated pair of ingress/egress gateways on the boundary of each namespace. Effectively, every namespace has its own ingress/egress gateways and Gateway/VirtualService configuration, and traffic between namespaces flows through these gateways.

A simplified traffic path for one of our flows looks like this:

• client -> sidecar (HTTP 80)
• sidecar -> egress-gateway (HTTPS 35000, ISTIO_MUTUAL)
• egress-gateway -> …route… -> ingress-gateway (HTTPS 443)
• ingress-gateway -> sidecar (HTTPS 18080, mTLS)
• sidecar -> server (HTTP 8088)

Sidecars For traffic between sidecars, we see both reporter="source" and reporter="destination" series. On the destination side, connection_security_policy="mutual_tls" is correctly set when mTLS is enabled (STRICT / ISTIO_MUTUAL).

Ingress gateway We see metrics with both reporter="source" and reporter="destination". For reporter="destination", connection_security_policy="mutual_tls" is present when ingress terminates or uses mTLS towards workloads, which matches the current documentation and is expected.

For reporter="source", connection_security_policy is unknown, which also seems to align with the documented semantics that client‑side reports often use unknown.

Egress gateway Here we only see metrics with reporter="source". There are no metrics with reporter="destination" for the hop sidecar -> egress-gateway, even though from a network point of view the egress gateway is clearly acting as the server for sidecars.

Consequently, we do not see connection_security_policy="mutual_tls" on the egress side, even though:

Sidecars call the egress gateway over ISTIO_MUTUAL (DestinationRule with tls.mode: ISTIO_MUTUAL for the egress service).

From the sidecar perspective, this is a normal mTLS hop and is reported correctly as such on the sidecar’s destination metrics.

Question Is the lack of reporter="destination" metrics (and thus lack of connection_security_policy="mutual_tls" from the egress point of view) a fundamental design decision / limitation for gateways (or Envoy configuration used by Istio gateways)?

Is it technically feasible to make egress gateways report destination‑side metrics for inbound traffic from sidecars in a way that is consistent with how sidecars and ingress gateways behave?

For example, to have istio_requests_total (and related metrics) with reporter="destination" and connection_security_policy="mutual_tls" for the hop sidecar -> egress-gateway when it is configured with ISTIO_MUTUAL.

If this is currently not supported, is there any plan to change this behavior in future versions, or is it considered out of scope for the gateway telemetry model?

Is there any recommended workaround (e.g. specific Telemetry API configuration, EnvoyFilter patterns, or best practices) to get server‑side visibility and a reliable indication of mTLS on the hop sidecar -> egress-gateway in setups where gateways are used as namespace boundaries, not only as mesh edges?