Services inside a Consul service mesh must call a third-party API and a legacy database that will never run a sidecar. What does a Consul terminating gateway do for that traffic, and what control do you keep once the traffic leaves it?

## The problem it solves A mesh gives you identity, encryption and authorization *between mesh members*. The moment a service must call something that will never run a sidecar — a payment provider, a mainframe, a database appliance — the model runs out. You have three unattractive options: let sidecars dial straight out (no policy, no visibility), poke holes in the network layer (policy exists but is expressed in addresses, not services), or route the traffic through something that belongs to the mesh on one side and to the outside world on the other. The **terminating gateway** is that third option. ## How it fits together The gateway is itself a registered Consul service running a proxy, typically started with `consul connect envoy -gateway=terminating -register -service my-terminating-gateway`. On the inbound side it is an ordinary mesh peer: a calling service's sidecar opens a mutual-TLS connection to it exactly as it would to any other mesh service. What it may forward to is declared in a config entry: ```hcl Kind = "terminating-gateway" Name = "my-terminating-gateway" Services = [ { Name = "stripe-api" CAFile = "/etc/ssl/certs/ca-bundle.crt" SNI = "api.stripe.com" }, { Name = "legacy-oracle" } ] ``` The names in that list refer to services registered in the Consul catalog as **external** services — catalog entries with an address and port but no local agent and no sidecar. Registering them is what lets the rest of the mesh talk about `stripe-api` as a first-class destination rather than as a URL buried in application configuration. ## The two TLS legs This is the part worth being precise about, because "terminating" is easy to misread. The gateway **terminates** the mesh's mTLS from the caller — that leg ends here. It then makes a second, entirely separate connection outward. If the entry supplies `CAFile` (and optionally `CertFile`/`KeyFile` for client certificates) plus an `SNI`, the gateway originates TLS on that outbound leg and validates the destination against the given CA. If you supply nothing, the outbound leg is whatever the destination expects — often plaintext, which is fine for a database on a trusted network and not fine for anything crossing the internet. Being able to say "mesh identity ends at the gateway; the outbound leg is a fresh connection with its own trust settings" is the answer an interviewer is listening for. ## What you keep Intentions still apply, with the external service as destination: ```hcl Kind = "service-intentions" Name = "stripe-api" Sources = [ { Name = "billing", Action = "allow" }, { Name = "*", Action = "deny" } ] ``` So "only the billing service may reach the payment provider" becomes a written, reviewable rule keyed on service identity rather than on which pods happen to sit behind which NAT address. You also gain a single place that sees all outbound traffic: gateway metrics and access logs give you an inventory of what your platform actually depends on externally, which is usually more surprising than teams expect. And because all egress leaves from a known set of hosts, the third party's IP allowlist has a small, stable set of addresses to hold. ## What you lose Everything downstream of the gateway is anonymous. The provider sees the gateway, so if you need per-service attribution at the destination you must carry it in the request itself — an API key, a token, a header — and that is application-level work the mesh will not do for you. The gateway is also a genuine chokepoint. It needs to be run redundantly and sized for aggregate egress; a single instance is a single point of failure for every external dependency at once. It holds credentials — client certificates, and its own ACL token — making it a higher-value target than an ordinary sidecar. And it introduces a hop, which means one more place where a timeout can be misconfigured relative to the caller's. ## The alternative worth naming Not all egress has to go through a gateway. Consul can also model external destinations directly on `service-defaults` with a `Destination` block giving addresses and a port, letting a transparent-proxy sidecar dial out to a known external endpoint without a gateway hop. That is simpler for a handful of well-known destinations and avoids the chokepoint, but it gives up the central inventory, the shared client credentials and the stable egress addresses. Relatedly, the `mesh` config entry can set `TransparentProxy { MeshDestinationsOnly = true }`, which makes traffic to anything not modelled fail loudly instead of leaking out silently — the setting that turns "we have a gateway" into "the gateway is actually the only way out".