Virtual Service and mutual tls

Hi, I’ve tried the helloworld task from the istio examples and all is working fine.
Now I’ve tried with a nginx deployment and then expose the service with gateway e vs like before.

But, until I apply a destinationrule that disable the tls mode I cant’t reach the service.
Why have I this behavior?
With the helloworld example I don’t need a destinationrule to reach the vs.
What I’m missing?

Hi @mcastro,

I can’t say what’s going wrong from your description, but can you add the yaml so I can take a look at it, or point me to a repo where I can see it?

Hi @rob,
thanks for repling.
The “helloworld” example that is working is this
Then I’ve tried a similar configuration doing this (in an istio injection enabled namespace):
kubectl create deploy --image=nginx nginx
kubectl expose deploy nginx --port=80 --type=NodePort

and then I’ve applied this virtual service on the same gateway.
Now the only way I’m able to reach nginx with vs is by disabling the tls with a destinationrule.

I send you an update @rob, I tried the same nginx configuration on gke and it works fine.
It could be possible it is related to che cluster conf (the first environment is a multi-cluster installation with Shared control plane (multi-network).

Hey, sorry for the delay @mcastro, I tried this as well on minikube too and it worked. I’ve never tried a multi cluster scenario. It might help to look at the envoy proxy logs for the ingress gateway and nginx to see if there is a clue in there as to why it’s not working without disabling mtls. If you’d like to get some of the logs I can take a look since I can’t reproduce your cluster setup.

One question here that might be relevant is the placement of the pods. In your initial scenario are the gateway and nginx pods in different clusters?

Hi @rob,
all the gw, virtual service and pods are on the main cluster.
On the ingress-geteway logs I’ve got this:
[2019-10-09T07:30:07.564Z] "GET /nginx/ HTTP/1.1" 503 UF,URX "-" "TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER" 0 91 71 - "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36" "c8b0410c-a5e6-46ae-a5c0-0d596ec36394" "X.X.X.X" "X.X.X.X80" outbound|80||nginx.demo.svc.cluster.local - X.X.X.X:80 X.X.X.X:55512 -

I also have this output for tls-check:
nginx.demo.svc.cluster.local:80 OK mTLS mTLS default/demo disable-mtls/demo

Hi @rob,
I did the same test on GKE with istio “strict” and on minikube.
On minikube it works, on gke it does not.

I find out it was a problem with the istio version. Version 1.2.5 has some kind of issue with exposing vs and mTLS.

Sorry @mcastro, I had access to a GKE cluster, but I no longer do. That’s interesting though. When I had been using 1.2.5 on my prior GKE cluster (i installed it manually, not using the version that GKE can install), I had mTLS enabled everywhere, except on a database due to other constraints. Is there an Istio bug with this issue described in it that you know of?

I did not find anything about it, but once I updated to version 1.3.3 the issue was gone.