What phone do you use? I have an old iPad that can't use email anymore because the client doesn't support modern TLS, which mail providers require nowadays. And all clients are required to use the internal outdated TLS library.
I have a Redmi Note 8 Pro, but this issue only started happening fairly recently. Also: this partially also happens on my computer now when using Zen. For some reason serves the default cert for Nextcloud, although it's not supposed to. I have tried the debug log and here is what I got:
traefik | 2024-10-14T16:58:37+02:00 DBG github.com/traefik/traefik/v3/pkg/tls/tlsmanager.go:228 > Serving default certificate for request: "cloudflare-ech.com"
traefik | 2024-10-14T16:58:37+02:00 DBG log/log.go:245 > http: TLS handshake error from 192.168.178.43:48564: remote error: tls: bad certificate
I am not sure as to what might be causing this issue.
That seems to be the domain requested. You need to have it in Host() to work.
The second line is the error message when a client connection fails because of untrusted TLS.
That's not what I intend, though. I want to directly access my Nextcloud internally, and it shouldn't go through cloudflare-ech first. This is the wrong behavior. It should be available fully locally without intervention by Cloudflare.
Let's go back to start.
-
Can you supply more info how you would like to handle remote and local access? Regarding domain names and IP resolution. All your
<redacted>does not help, we don't know where you want to use a sub-domain, etc. -
Do you use Cloudflare just for creating TLS certs or is it also used to proxy traffic to your Traefik? Are you using a Cloudflare tunnel?
-
Enable and check Traefik debug log (doc) and Traefik access log in JSON format (doc).
-
Not sure if some of your very special settings actually make any sense, like ProxyProtocol, http3 and
volumes: traefik-logs: null. Why don't you start with a simple config?
- Remote access should (at least for now) be handled by Cloudflare Tunnels. The request firstly goes to Cloudflare, then through cloudflared to my Traefik, to my service and back the entire route. Local access should only involve the client, my network gear, Traefik and the service. The main domain is knoll-family.de and sans the wildcard for its subdomains. Nextcloud is routed to with nextcloud.knoll-family.de. It works fine via Cloudflare, but has issues internally
- I use Letsencrypt to issue certificates, while Cloudflare has the nameservers for my domain. I also use Cloudflare Tunnels to route external traffic, but not internal one, when I'm at home. Internal traffic should directly go to my homelab, which I have made sure with internal DNS entries in my network's PiHole DNS.
- I already checked the debug log, which shows that the client is requesting cloudflare-ech.com. It's weird that my server picks up a request for that, although I haven't overridden any behavior in that regard. The access log includes the following information:
"GET /push/ws HTTP/1.1" 0 0 "-" "-" 1596 "nextcloud@file" "http://192.168.178.70:11000" 3597ms, but not in the json format. I have reasons for this... - I think that ProxyProtocol might be unnecessary, but http3 would be better to use for security and usability reasons. The volume is for the logs to be accessible for crowdsec to parse the Traefik logs. I added it as an additional security layer, so that if someone malicious passed Cloudflare somehow, they would possibly be stopped by Crowdsec. The aspect with the simple config though: I basically built this config from scratch, following the documentation and adding options as I figured necessary or useful. This config has worked the entire time, but when I set up Cloudflare, things started going wrong.
1 Like
I'm having the exact same issues since 2-3 months. In this case, not Nextcloud but Vaultwarden.
Also using CF Tunnel and cloudflarewarp.
cloudflarewarp:
plugin:
cloudflarewarp:
disableDefault: false
Using MS Edge and going to a different subdomain and back to Vaultwarden domain the issue is temp. fixed.
This applies to both Android phone and Windows 11 PC.
So you want nextcloud.example.com to resolve externally to Cloudflare IP (tunneling traffic to your Traefik instance) and internally to resolve to your local network IP.
That shouldn’t make a difference to Traefik, it will just resolve host/domain and path, TLS is set on entrypoint.
I am out of ideas, just remove all your additional setting (proxprotocol, http3, middlewares) to get the basics running. Then add them back.
Compare to simple Traefik example.
When sending the request, somehow a lot of devices and browsers seem to send a request with some header making it appear like it tries connecting to cloudflare-ech.com or something, which is not correct and therefore has no valid certificate and service and borks the connection. Somehow cloudflare is causing this behavior.
1 Like
Should I move this to Cloudflare support forums? This doesn't appear to be a problem with Traefik or my configuration for it, but rather some odd behaviour with Cloudflare tunnels, which causes certain clients (devices, browsers, apps, ...) to always want to connect with cloudflare-ech.com first, but somehow redirected to the local IP which causes problems.
Could it perhaps be the Traefik plugin cloudflarewarp? We both use it.
I haven't tested it without the plugin as I stopped using CF Tunnel and disabled cloudflarewarp for the time being, my Vaultwarden instance was constantly not accessible.
- Were you hosting Vaultwarden publically? I have that too, but don't think it's quite safe enough to give public access. (Even with proper authentication)
- The actually important thing is that I doubt that cloudflarewarp has anything to do with this. It just reads the HTTP headers and if it can find the Cloudflare source IP header it puts that into the X-Real-IP header. That's all it does I think.
- Yes, publically but I have /admin behind Authelia and fail2ban to check failed logins. I think this is probably enought security.
- OK, I'll just try CF Tunnel 1 or 2 months from now again and see if it's working as intended. Although, this might be a good time to consider stop using CF Tunnel...
What could I do except for port forwarding as an alternative to CF tunnels though?
I've been using port forwarding for ages, was just using CF Tunnels to hide IP but because some other services aren't through CF Tunnels it doesn't make much sense using it.
For sensitive data, perhaps using Tailscale?
I don't know whether the issue would persist with proxied DNS entries and conditional port forwarding. Smthere has to be some solution without having to stop using tunnels. (Maybe I technically could rent a cheap server and make a wireguard relay)
I found some info here: ECH Protocol | Cloudflare SSL/TLS docs
For some reason, when I have a tunnel, it forces ECH to use that outer domain, but for some reason it just connects to the wrong server with the wrong ECH outer domain. Cloudflare enforces that ECH somehow with maybe a hidden DNS entry or something, which is not overriden and causes my clients to wrongfully execute the ECH with that cloudflare domain.
I got it! I asked on the Cloudflare Discord server whether anyone knows what might cause this odd behaviour and I was told that it is likely HTTPS entries Cloudflare uses for opportunistic https to https upgrade, ECH and more that cause an outer layer to be added to the ECH request with the cloudflare-ech.com domain. So I looked around how to block those HTTPS entries/queries for my domain and it's subdomains and added a regex blacklist filter for it. For anyone else with this issue, the regex filter looks something like this: ^.*\.<domain>\.<tld>$;querytype=HTTPS and for the main domain ^<domain>\.<tld>;querytype=HTTPS. Just replace and respectively. Especially if you have a longer domain, you may to add more text and dots and just remember to add a backslash \ before each dot of the actual domain.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.