Cannot reach external service with TLS (using or not an egress gateway)

Hello guys,

It’s now days I’m trying to configure Istio 1.22 to make a specific POD in the default namespace to contact and external service (it’s a SOAP endpoint on Internet), either using an egress gateway (which I would prefer), or without, as a simpler initial scenario.

My end goal would be to automatically authenticate to the service through TLS, making the gateway transparently add the client certificate and private key. But, for now, I’d be happy to get a 403 forbidden.
Instead, I always get either 503, or 35 (both in my curl and in the istio-proxy sidecar), regardless of the way I configure everything.

Let me underline that the curl works perfectly from any other computer outside this istio deployment, for example from my computer.

This is the command I use from other computers: curl -vvv --tlsv1.2 --key io.key --cert io.cer -X POST -d '<example>...</example>' https://DST_HOST -H "Content-Type: text/xml"

Normally, the server expects TLS 1.2 connections. If client keys, certs and ca-certs options are not provided, a user simply gets 403.

What I’ve been done with Istio:

  1. I’ve started following the tutorial about Egress Gateways with TLS origination. The default example for cnn works. I simply substitute my hostname (and resources names) to the demo ones, and nothing works…

  2. I’ve followed this other tutorial, which uses the PASSTHROUGH option. Also this one brings to the same results

  3. I’ve followed TLS origination (without egress gateways), here. Also this one brings to the same results.

I’ve activated logs to std out on all Istio PODs. I can share any (anonymized) configuration and log as requested.

Is there anything you could think about? Do you have any suggestion?

Thank you so much,

-Luca

One more thing.

I’ve started from scratch, deleted everything.

Then, I try to reach with a curl the external service, and I things work (I get 403, “as expected” - in this phase).

Then, I simply install the serviceentry and the same curl starts to return curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number.

I’ve googled (and Googled…) and I find many issues similar to this one, apparently with no clear answers.

I guess this should be fixed first, then I can move forward and think to the rest.

Thoughts?

One more step: the example here now works.
I had an old destination rule that was overlapping with others I was installing…

Unfortunately, things start to do not work anymore when I try to do the TLS origination in the gateway, following the guide here.

When I curl from the sleep pod (my client) to my external service I always get a 503 UC as a reply.

Also, I’m trying to understand what each component is supposed to do in the tutorial. Can anybody please explain what this destination rule is supposed to do? I see it like something matching a subset and a host, but not really doing anything…

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-cnn
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
  - name: cnn

Thanks again

Last update: it turns out that the host name only return the right result, but postfixing it with a path (i.e. /example/try) makes it return the 503.

Could be something related to the virtual host configuration or the destination rules configuration?

Thanks