[BUG] incorrect SSL handling for kubernetes on frontend container behind reverse proxy

[prutseltje]

Describe the bug Default ingress TLS settings in kubernetes results in a 301 redirect loop

Environment

• K3S

Additional context TLS_FLAVOR is set to cert on kubernetes, causing the nginx container to listen on port 443, instead of port 80 Setting ingress.tlsFlavorOverride=mail seems to resolve it.

From my values.yml:

front:
    externalService:
        enabled: true
        externalTrafficPolicy: Local
        loadBalancerIP: 1.2.3.4
        type: LoadBalancer
    hostPort:
        enabled: false
hostnames:
    - mail.mydomain.com
    - imap.mydomain.com
ingress:
    annotations:
        cert-manager.io/cluster-issuer: letsencrypt
        nginx.ingress.kubernetes.io/proxy-body-size: 52m
    enabled: true
    ingressClassName: nginx
    realIpFrom: 10.0.0.0/16
    tlsFlavorOverride: mail

[marinko-lognium]

Having the same issue. The problem happens when ingress is enabled. If ingress is enabled, then in the old charts the service is not exposing port 443. In this not yet published version port 443 is always exposed independent of the ingress being enabled or not. So Please publish a new version of the helm charts.

The actual version of the front is doing always a redirect to https and ingress is sending the http request to the front so we are ending in the endlos loop. https://github.com/Mailu/Mailu/blob/master/core/nginx/conf/nginx.conf#L75

[prutseltje]

Having the same issue. The problem happens when ingress is enabled. If ingress is enabled, then in the old charts the service is not exposing port 443. In this not yet published version port 443 is always exposed independent of the ingress being enabled or not. So Please publish a new version of the helm charts.

The actual version of the front is doing always a redirect to https and ingress is sending the http request to the front so we are ending in the endlos loop. https://github.com/Mailu/Mailu/blob/master/core/nginx/conf/nginx.conf#L75

Removing the redirect is not the solution, I have the redirect still in my configuration, but the other server block listening on port 80. Now my frontend is working as expected

[marinkobabic]

The reason your solution works fine is you are using an older version of the nginx configuration. Changing TLS FLAVOR is fixing temporary the solution, because in the old config then the redirect is not being performed.

Anyway we need the new helm chart version getting published to make all also working with ingress enabled. I just don't know if from the design perspective the intention is to run front container always on https. Currently looking at the charts and config, it looks so.

[prutseltje]

The reason your solution works fine is you are using an older version of the nginx configuration. Changing TLS FLAVOR is fixing temporary the solution, because in the old config then the redirect is not being performed.

Anyway we need the new helm chart version getting published to make all also working with ingress enabled. I just don't know if from the design perspective the intention is to run front container always on https. Currently looking at the charts and config, it looks so.

Perhaps some background information would be helpful to understand this (my) issue:

I have mailu running at home, with only a single external IP. But with multiple websites. In my router I can forward http(s) traffic only once, so this is forwarded to my default ingress controller. For SMTP and other mail related ports I have a rule to forward traffic to the mailu-front-ext service.

Perhaps it is possible to make the mailu-front service configurable with a ingress so the mailu-front-ext can stay as is.

[fastlorenzo]

If you don't change the default for ingress.tls, it should set the TLS_FLAVOR variable to cert and there should be no need to set it to mail. The intent is to have the web service (80/443) exposed through the ingress, and the other ports via a LoadBalancer through mailu-front-ext service. If you want to expose 80/443 as well through mailu-front-ext, we'll need to make a change in the chart to work that way. Please note as well that 80/443 is exposed on the internal service mailu-front, in case that helps.

[prutseltje]

My ingress is pointing to the mailu-front:http service, which is handled by the mailu-front-XXXXXX-XXXX pod. I have no ingress.tls setting, but the default values.yml is set to true.

I'm running helm.sh/chart=mailu-2.0.0 mailu-front image: ghcr.io/mailu/nginx:2024.06.3

I think the issue is in the nginx config, but I have no clear overview of all the dependencies

[long2ice]

So how can I fix this? I can't access the admin dashboard.

[long2ice]

Looks like this change: https://github.com/Mailu/helm-charts/commit/3fa16db195f3361388c4b9cee329c0e67970dc9a#diff-2758e848974fbab88ccd1fea4e689743388c4b27c02e4861b3f14bdeae7190edR37

[prutseltje]

So how can I fix this? I can't access the admin dashboard.

You can do a helm upgrade with this extra option in your values file: ingress.tlsFlavorOverride=mail

[long2ice]

So how can I fix this? I can't access the admin dashboard.

You can do a helm upgrade with this extra option in your values file: ingress.tlsFlavorOverride=mail

Not work, I need manual edit https to http:

        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: mailu-front
                port:
                  name: http # https to http

[prutseltje]

So how can I fix this? I can't access the admin dashboard.

You can do a helm upgrade with this extra option in your values file: ingress.tlsFlavorOverride=mail

Not work, I need manual edit https to http:

        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: mailu-front
                port:
                  name: http # https to http

Did you upgrade or is it a fresh installation?

My mailu-front container only listens on HTTP, not HTTPS. The mailu-front service exposes both 80 and 443..

[long2ice]

Both I tried

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.