TLS PASSTHROUGH config results in TLS negotiation errors

Hello,

We are using Istio for several services advertised via a Gateway using TLS simple mode to route traffic to several services from the same Gateway IP.
We wish to also employ TLS passthrough in order to reverse-proxy external services alongside our internal kubernetes Pod-hosted services. We would consider using TLS origination if passthrough was not an option alongside our existing HTTPS simple mode services.
So far I have been referring to this PR for details of how to perform this configuration: https://github.com/istio/istio.io/pull/3180/files

I’m aware that there are some issues in our config, as although I can get the httpbin example to work for plain HTTP redirection, when moving to HTTPS I cannot get a connection; TLS negotiation fails like this:

    * ALPN, offering http/1.1
    * gnutls_handshake() failed: The TLS connection was non-properly terminated.
    * Closing connection 0
    curl: (35) gnutls_handshake() failed: The TLS connection was non-properly terminated.

I will follow up and attach our config. Shortly. Using Istio 1.0.2 I believe.

Here’s my tests so far:

  $ curl --resolve host-to-proxy.com:443:10.0.0.111 https://host-to-proxy.com:443 -vvv -k
* Added host-to-proxy.com.com:443:10..0.0.111 to DNS cache
* Hostname host-to-proxy.com.com was found in DNS cache
*   Trying 10.0.0.111...
* Connected to host-to-proxy.com (10.0.0.111) port 443 (#0)
* found 398 certificates in /etc/ssl/certs/ca-certificates.crt
* found 1454 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: The TLS connection was non-properly terminated.
* Closing connection 0
curl: (35) gnutls_handshake() failed: The TLS connection was non-properly terminated.

Here’s the relevant config:

[EDIT - renamed ports from “https” and “https-ext” to “tls” and “tls-ext” to reflect requested change on live system.]

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: front-proxy
  namespace: howels
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - host-to-proxy.com
    port:
      name: tls-ext
      number: 443
      protocol: TLS
    tls:
      mode: PASSTHROUGH

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: howels
spec:
  gateways:
  - front-proxy
  - mesh
  hosts:
  - host-to-proxy.com
  tls:
  - match:
    - sni_hosts:
      - host-to-proxy.com
    route:
    - destination:
        host: backend-host-to-proxy.com
        port:
          number: 9443

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext-https
  namespace: howels
spec:
  hosts:
  - backend-host-to-proxy.com
  location: MESH_EXTERNAL
  ports:
  - name: tls
    number: 9443
    protocol: TLS
  resolution: DNS

Can you rename the TLS ports to be prefixed by tls? e.g. tls, tls-ext etc. Istio takes the port name prefixes into account.

I renamed the ports to “tls-ext” in the gateway and “tls” in the serviceentry.

No change in TLS behaviour.

ServiceEntry works from within Kubernetes using a simple sleep container with curl, external requests fail.

@howardjohn i thought your recent changes should fix this? you add a filter chain with empty filter chain match for this IIRC.

I don’t think my change is related, it just makes it so external traffic is not blocked when ALLOW_ANY (default) is configured

I am observing the same behavior with TLS passthrough. It is unfortunately really blocking me.

We never got this working and abandoned our attempts to use istio as a reverse proxy for external services. Any additional information would be great! Documentation is lacking and I don’t know enough about the internals of envoy to piece it together.

1 Like

Hi,

I am working on trying to combine passthrough and simple over tls 443 and https 443 respectively.

I can’t get the combination to work, is it supported for different hosts and services in the same gateway?

Seems like you had a similar use case to us. We are using 1.47

Ant