Passthrough not working after upgrading Traefik to 2.6.3

Traefik Traefik v2 (latest)
, ,
1

Hello Everyone, I'm using Traefik 2.6.3 and ingressRoute kind as below. Passthrough for pathprefix rule is not working after upgrading the Traefik to 2.6.3. The same configuration was working earlier prior to Traefik 2.6.3. Is any configuration is missing?

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
annotations:
kubernetes.io/ingress.class: traefik
app.kubernetes.io/managed-by: {{ .Release.Service }}
meta.helm.sh/release-namespace: {{ .Values.namespace }}
labels:
app.kubernetes.io/managed-by: Helm
{{- range $key, $value := .Values.ingressLabels }}
{{ $key }}: {{ $value }}
{{- end }}
name: {{ template "tls-ingress-name" . }}
namespace: {{ .Values.namespace }}
spec:
entryPoints:
- websecure
routes:
- kind: Rule
match: PathPrefix(/orchestration/{{ printf "%s%s%s" .Values.project "/" .Values.instance }}/tmf-api, /health, /metrics)
services:
#- name: project1-dev
- name: {{ template "svc-name" . }}
namespace: {{ .Values.namespace }}
port: 8443
tls:
# TLS Passthrough
passthrough: true
secretName: {{ template "ingress-tls-cert-secret-name" . }}

2

Hi @sgundadi,
Thanks for your interest in Traefik.

I see several misunderstandings in your configuration.

  • TLS passthrough is not available on IngressRoute (or any HTTP based routers for that matter). This option prevents Traefik to look at the request content, so it is not possible for the proxy to look at any part of the (possibly) HTTP request. The only routing rule available with TLS passthrough is HostSNI (see IngressRouteTCP).

  • As well, it does not make sense to use both passthrough and secretName as the latter is used when Traefik does the TLS termination.

To sum up, your configuration never used TLS passthrough as the option does not exist on IngressRoute. I think you had a "false-positive" because you were providing a certificate.

If you need any help, could you please let me know what you are trying to achieve?

3

Thanks Moutom for the reply. Could you please help me with path based rule for the ingressRouteTCP because our requirement is to use the path based routing.

Another one, I would like to have TLS reencryption at the ingress level. Is there any such configuration available. Could you point me.

Thanks,
Srinivas

4

To me, you have 2 options:

  1. You use Traefik as a TCP reverse proxy. To do so, you use IngressRouteTCP to forward your traffic coming from a specific host to your server, and you enable TLS passthrough. Your backend should handle TLS termination and route the request based on the path.

  2. You use Traefik as an HTTP reverse proxy. Traefik then handle the TLS termination, read the HTTP packet and can perform routing based on your PathPrefix rule. You can then create a dedicated server transport to re-secure the traffic between Traefik and your backend.

In any case, you CANNOT use path based routing if the request is encrypted. Traefik MUST be able to read the HTTP packet before doing any HTTP routing.
In the case of TLS routing (passthrough with host SNI), the TLS header contains the domain (domain only; no path nor query params) for which the request is sent, which explains why we can still do routing without reading the packet.

5

Hi Moutoum,

As suggested in previous thread, I have configured the ingressRoute as per option 2. Here I have configured ingressRoute TLS Termination at ingress. Configured Service port 443 for https connection between Traefik and backend microservice pod. And ServersTransport to resecure traefik between Traefik to backend.

I have used self signed certificates for ingress, serverstransport and application microservice pod.
I'm able to receive the response using the https and verified the same in traefik logs.

Here are the some of the questions.

  • I'm not sure which certificate is being used by Traefik to reencrypt and communicate with backend. Is there a way to validate the same.
  • Do we need serversTransport kind since we have enabled Service port 443 for https connection between Traefik and backend?
  • How to monitor the Traefik and back end communication in detail. Like what is the certificate used for Traefik and backend connection. SSL handshake details etc.

Here is the configuration.

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  annotations:
    kubernetes.io/ingress.class: traefik
    app.kubernetes.io/managed-by: {{ .Release.Service }}
    meta.helm.sh/release-namespace: xyznamespace
  labels:
    app.kubernetes.io/managed-by: Helm
    {{- range $key, $value := .Values.ingressLabels }}
    {{ $key }}: {{ $value }}
    {{- end }}
  name: xyzingress
  namespace: xyznamespace
spec:
  entryPoints:
    - websecure
  routes:
    - kind: Rule
      match: PathPrefix(`/xyz`, `/health`, `/metrics`)
      services:
        - name: xyzservice
          namespace: xyznamespace
          port: 8443
          serversTransport: mytransport
  tls:
    secretName: abdsecret
    options:
      name: tls-options-name
      namespace: xyznamespace
---
apiVersion: traefik.containo.us/v1alpha1
kind: ServersTransport
metadata:
  name: mytransport
  namespace: xyznamespace

spec:
  serverName: serername
  insecureSkipVerify: true
  certificatesSecrets: 
    -  "internal-secret" 
---
apiVersion: v1
kind: Service
metadata:
  name: xyzservice
  namespace: xyznamespace
  labels:
    app: "app-name"
spec:
  selector:
    app: "app-name"
  ports:
    - name: https
      protocol: TCP
      port: 8443
      targetPort: 8443
  type: ClusterIP
---
6

Hi @sgundadi,

Traefik will use your application certificate to encrypt data.

The ServersTransport is used to customize the way Traefik communicates with your backend. So you can configure insecureSkipVerify if you have self-signed certificates on your backend. Or you can configure root CAs to verify the server certificates. One option is certificates which is use for mTLS. In your example, if you have valid certificates (e.g: provided by Let's Encrypt), you don't need the custom transport.

Actually, I don't know. I never had to do this.