Is external traffic allowed to consul service mesh without consul ingress/api gateways

I am trying to understand consul service mesh as part of our service mesh evaluation at our org. I’ve a question for which I didn’t find a clear answer in Consul documentation. Is external inbound traffic allowed to Consul service mesh without some kind of consul gateways (Mesh/Ingress/API gateways).


Hi @ravsri,

Is external inbound traffic allowed to Consul service mesh without some kind of consul gateways

Not generally, no. The proxies within the service mesh generally validate that any inbound traffic is encrypted with a client certificate that is provisioned by the internal mesh CA, so unencrypted general traffic would not be allowed through the mesh. For services outside of the mesh you would generally want to use an Ingress Gateway or our new Beta-released API Gateways.

Both will allow you to ingress traffic over HTTP and over HTTPS without a client certificate, but ingress gateways really only support using mesh CA-signed certificates on their listeners, whereas API gateways allow you to bring your own listener certificates. Additionally, API gateways are modeled around Kubernetes’ API Gateway Spec and will likely eventually completely replace ingress gateways.

Let me know if I can clarify any other mesh use-cases.

Seems to be doable:

Not without its fair share of common problems though.

Thank you @andrewstucki. I expected the same.

How does Ingress Gateway/ API Gateway authenticate the external traffic before it is routed to the services in the service mesh?

So, the inbound traffic itself isn’t authenticated as gateways are meant for general purpose ingress from external sources. The gateway to backend service traffic will be encrypted and use mTLS for authentication though.

If you let me know a particular use-case you’re thinking of I might be able to help a bit easier.

Thank you @andrewstucki.

If I want to allow external traffic to use the consul ingress/api gateway, I believe there should be some way to authenticate. If not, anyone can make a call to the api gateway endpoints. please correct me if wrong. If ingress/api gateway doesn’t have ability to authenticate, should we have another internal service to authenticate/authorize incoming requests?

Hi @ravsi,

So, currently we have no way to terminate authentication at the gateway, you would have to allow the request go through the gateway and then do the authentication in the backend service itself. We have plans to eventually add something like JWT-based mechanisms for authentication into gateways, but nothing concrete on our roadmap as we have some other higher priority items we’re focusing on in the interim – my guess though is that we won’t have the capacity to begin addressing something like JWT for at least a couple releases.

Let me know if there’s anything else I can do to clarify.

Hi @andrewstucki,

This means if my service in a service mesh gets a request from outside through Consul API gateway, I should not trust it without authenticating. Is that correct? 

And if I have 5 services in my service mesh and I need to route external traffic to 3 of them, then I need to implement the authentication in all those 3 services. Please correct me if wrong.

Hi @andrewstucki,

Is the mTLS connection from outside mesh terminated at Ingress gateway or is it passed through to the service in the mesh?


I don’t know much about Service Mesh, but just to let you know, when you use code formatting blocks on text which isn’t code, like:

you make your messages very hard to read since the entire line is displayed without any line-wrapping, and requires horizontal scrolling to read.

Use code blocks for code only, for your readers’ sake.

Hi @ravsri,

Sorry, just saw your follow-up questions. We don’t currently support custom mTLS on the external listeners for ingress or api gateways, only general TLS termination via leaf certificates or a custom-built SDS server for ingresses, or with user-specified certificates with API gateways.

With regard to your other question, yes, because we don’t currently have a mechanism for offloading authentication to the gateway itself, any authentication to routable backends from an API gateway or ingress gateway will have to be handled by the backends themselves. You could stand up an additional authentication service/proxy that sits in front of every route to handle authentication in a single unified location, but that would be something that you would currently need to implement yourself.

Hi @andrewstucki,

Thanks for the response. I really appreciate for the support being provided.

But I think I didn’t clearly communicate the question.
Let me put it in a different way.

When we try to establish an mTLS connection between an external service and Service A (which is in Mesh) through Ingress Gateway, will Ingress gateway do an mTLS termination or mTLS passthrough?



If you set up a gateway, ingress or API, with a TLS listener using HTTP, it will terminate TLS and re-establish a connection to the backend with the standard mTLS connections that are leveraged for implementing intentions between services, meaning that you won’t actually be able to do mTLS directly between a client passing through the gateway and the backend service.

If you want passthrough I believe (but haven’t actually verified this configuration myself), that you might be able to create TCP-based listeners on either gateway type with no TLS settings specified and it will create a raw-TCP proxy that will allow you to do mTLS passthrough. That said, at the moment, it would come with the limitation of only being able to specify a single backend as the target service for either gateway (TCP-based load-balancing is not supported in either gateway for now) and you no longer have access to doing L7 rules for backend routes that you would using HTTP-based listeners.