the Pod in Mesh to VM : TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER #35870
Labels
area/networking
area/user experience
feature/Virtual-machine
issues related with VM support
lifecycle/automatically-closed
Indicates a PR or issue that has been closed automatically.
lifecycle/stale
Indicates a PR or issue hasn't been manipulated by an Istio team member for a while
Comments
istio-policy-bot
added
area/networking
area/user experience
feature/Virtual-machine
|
Can you check the supported tls version of your vm? |
there is no policy and the istio cni is disabled.
|
|
there are two case:
|
|
same question, istio 1.11.4 http://10.98.41.167:31614/productpage |
|
Looks like the mtls request is going directly to your app. Maybe iptables
isn't set up properly?
…On Thu, Nov 18, 2021 at 9:47 PM yuanxch ***@***.***> wrote:
*same question, istio 1.11.4*
cni:disable
[image: image]
<https://user-images.githubusercontent.com/10543069/142571796-ca56cf88-e0d4-47ed-b0e2-82ecdcffe6fc.png>
http://10.98.41.167:31614/productpage
upstream connect error or disconnect/reset before headers. reset reason:
connection failure, transport failure reason: TLS error: 268435703:SSL
routines:OPENSSL_internal:WRONG_VERSION_NUMBER
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#35870 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEYGXP3BXCZWKWYY3YADHTUMXQIFANCNFSM5HI5EPYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
@howardjohn Hello, I followed the documentation on the official website to operate the virtual machine. Once I started mtls for the service in the virtual machine, this problem occurred and the iptables rules were effective. Is there a case of accessing vm from mesh in the official document? Is the case of mutual authentication opened? thanks. |
It works when i add the codes into |
|
@yuanxch me too. |
|
I would check `sudo iptables-save`
…On Sun, Nov 21, 2021 at 8:02 PM 天马行空 ***@***.***> wrote:
@yuanxch <https://github.com/yuanxch> me too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35870 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEYGXNEK4WE7ARHXIZEX6LUNG6GPANCNFSM5HI5EPYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
thank you @howardjohn both results are same。
|
|
I mean in the pod and/or VM that has the issue |
|
I receive the same error when two pods are on the same mesh but one of them has the following annotations (all traffic bypasses istio). Error: Annotations on one of pods: To solve this currently it is needed to create a Is it correct behavior? |
I also met this tls error when configuring the annotation traffic.sidecar.istio.io/includeInboundPorts: "" to make inbound traffic bypass sidecar. This solution is useful and worked for me. |
|
We had the same issue and setting the tls block with mode |
|
@Dudesons I didn't change this setting and as I know by default it is |
|
This also affects the instructions for running prometheus in a (mostly) strict mesh: https://istio.io/latest/docs/ops/integrations/prometheus/ Grafana and Prometheus are running with sidecars using the above configurations and grafana is unable to talk to prometheus. Additionally, we're unable to route to it from a gateway using a virtualservice. Both scenarios get the ssl wrong version error. |
|
We are also getting same below error when we enable mTLS option in mesh. "268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER" Currently destination rule for each service is set as STRICT mode. Any other resolution other than disabling the TLS mode in destination rule |
|
@Dudesons I also use the default settings, it should be permissive mode |
|
I have a similar problem. And I add a PeerAuthentication， it's just solved. The value of mtls.mode ，both PERMISSIVE and STRICT are ok， UNSET is not work。 Ref：
|
That seems odd, PERMISSIVE mode is identical to unset |
|
@howardjohn Maybe I know why. I find my cluster(istio version: 1.8.4-r2) has a Globally PeerAuthentication, the mode is DISABLE and the tls.mode set in DestinationRule of myapp is ISTIO_MUTUAL, the two configurations are inconsistent, and I get the 'OPENSSL_internal:WRONG_VERSION_NUMBER' error. DR: |
|
By creating PeerAuthentication object with mTLS option disabled at Mesh level will solve the OpenSSL_internal:WRONG_VERSION_NUMBER problem? |
|
@nataraj24 I think the key point is the tls config in PeerAuthentication and DestinationRule should not be conflicting. |
so solve the problem or not ? |
|
|
I have the same issue here following the docs from (https://istio.io/latest/docs/setup/install/virtual-machine/#configure-the-virtual-machine). I can confirm also that if I DISABLE mTLS, then it works with docker on 'default' or on 'host' network. |
|
@sanwen Can you test it on master? 1.8.4 is not maintained. |
|
@andrevcf We canot figure out what's wrong with your info? You can show your WorkloadEntry ServiceEntry. And if you suspect the traffic is not intercepted, you can also run |
|
@hzxuzhonghu, my workloadentry is pointing to a vm with nginx running inside docker The service on k8s is pointing to two ports just for testing purpose: If I call the service inside the mesh with iptables-save WITHOUT =============================================================================
|
|
Can you check the inbound cluster type? I suspect you are using an old version istio. The inbound cluster type is not
|
|
@hzxuzhonghu , inside a pod running on the mesh (productpage of bookinfo) |
|
@hzxuzhonghu, this means that I must use the |
|
Envoy inbould cluster is Original_Dest type. it will send packet to |
|
From all your info, i think --net host is a requirement |
istio-policy-bot
added
the
lifecycle/stale
|
/stale |
istio-policy-bot
removed
the
lifecycle/stale
istio-policy-bot
added
the
lifecycle/stale
|
/stale |
istio-policy-bot
removed
the
lifecycle/stale
|
FWIW - I see the same TLS error/failure signature but my setup is very different. Documenting here in case it helps others. I am trying an IPv6 scenario and trying to curl from outside of the cluster to inside of the cluster. I am mostly following getting started sequence with some adjustments required for dual-stack and also accounting for #29076. When I define the istio-ingressgateway svc to be single stack IPv4 I can curl from outside just fine with an IPv4 loadbalance IP. When i define the svc to be single stack IPv6 (e.g. IPv6 load balance IP) I can't curl from outside and logs show the traffic is not hitting the side car but directly hitting the product page container. When I curl from the ingressgateway istio-proxy container using the product page pods IPv6 address it is successful and the traffic goes through the side car. Since this is sufficiently different than the initial compliant, I will open a different issue. |
istio-policy-bot
added
the
lifecycle/stale
|
🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2022-10-24. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions. Created by the issue and PR lifecycle manager. |
istio-policy-bot
added
the
lifecycle/automatically-closed
|
This just happened to me as well but in a little but different scenario than described here. The issue was that the Pod running web server didn't have the istio sidecar injected but the DestinationRule was specified for this workflow. Changing the DestinationRule with Specifying label |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Description
Mesh -> VM:
the log of bash:
bash-5.1# curl helloworld.vm-test.svc.cluster.local:8500/hello
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBERbash-5.1#
Traffic in this direction failed.
VM -> Mesh：
This is correct
Version
Additional Information
the yaml se of we:
I can access to it by ip + port:
the config of vm:
cluster.env
istio-token
mesh.yaml:
root-cert.pem:
the istio configmap:
The text was updated successfully, but these errors were encountered: