Virtual Service and mutual tls

Networking
1

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?

2

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?

3

Hi @rob,
thanks for repling.
The “helloworld” example that is working is this https://pastebin.com/eUXv74L7
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 https://pastebin.com/hH6bFAap on the same gateway.
Now the only way I’m able to reach nginx with vs is by disabling the tls with a destinationrule.

4

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).

5

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?

6

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 - "10.233.64.0" "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:
HOST:PORT STATUS SERVER CLIENT AUTHN POLICY DESTINATION RULE
nginx.demo.svc.cluster.local:80 OK mTLS mTLS default/demo disable-mtls/demo

7

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

8

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.

9

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?

10

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