Randomly getting ECH errors on self-hosted services.
https://lemmy.ca/post/29918830
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
Any chance you are both accessing your services locally with a local DNS, and publicly with something like Cloudflare?
=> More informations about this toot | More toots from bobslaede@feddit.dk
I do have external acces to Ombi via cloudflare; but the device I’m seeing this problem on is permanently connected to a VPN hosted from the same server machine as ombi/nginx with ‘block all connections without VPN’ enabled. And this testing has been done from within the same LAN.
It should never see/reach cloudflare for this service.
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
Try with nslookup and see if you’re resolving the domain to both your local ipv4 address, and the Cloudflare ipv6 at the same time. I am using pihole for my local DNS, and it would give me both my local address, and also the Cloudflare ipv6 address.
=> More informations about this toot | More toots from bobslaede@feddit.dk
Crap, looks like that’s exactly what it is.
Now how to fix that…
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
Added an AAAA record to pihole:
ombi.mydomain.example 0000:0000::0000:0000
Now nslookup returns the correct ipv4 address, and ‘::’ as the ipv6.
We’ll see if that works.
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
That unfortunately did not work. I am only getting the ipv4 address now, but I still get the same ECH error in chrome 1/5 tries.
Firefox now changed errors from ‘invalid certificate’ to ‘connection is insecure but this site has HSTS’. Still wont show the cert or provide any further info. (forgot to grab a screenshot before the below ‘solution’)
I’m really annoyed at this point and have just disabled cloudflare proxying for this service. That seems to have sorted it for all browsers. I may look further later, I may just say fuck it and leave it like this. Gotta walk away for a bit.
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
You should change to use cname in pihole. I will write up on my computer later for you.
=> More informations about this toot | More toots from bobslaede@feddit.dk
Can you verify with wireshark that the traffic is only going through your lan? I’m not hip enough for nginx but I used to have to run apache under gdb all the time to trace random errors from the server. That would be next, if the traffic is really local.
=> More informations about this toot | More toots from solrize@lemmy.world
I’ll look into that next if what I’ve done doesn’t work. (see other comments)
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
this issue is an ongoing discussin over at NPM too, very mysterious
https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3982
=> More informations about this toot | More toots from sk@hub.utsukta.org
Thanks. That seems to be a similar, but slightly different error. I think the below may apply though.
I believe I’ve tracked down more of my issue, but fixing it is going to be a hassle:
When cloudflare proxying is enabled, there are 3 DNS records involved; A record with cloudflares ipv4, AAAA record with cloudflares IPV6, and the key to this puzzle: an HTTPS record with cloudflares ech/https config.
With pihole I can set DNS records for A/AAAA, but I have no way of blocking/setting the HTTPS record so it gets through from cloudflare.
The A/AAAA records don’t match the HTTPS record, so browsers freak out.
Once I disabled cloudflares proxying, I no longer get HTTPS records returned and all works as intended.
I’ll either have to keep cloudflare proxying disabled, or switch pihole out for a more comprehensive DNS solution so I can set/block HTTPS records :(
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
I’ve fixed the same issue for me.
Originally I had this in my Local DNS settings in my Pi-Hole:
I changed that to this:
And then I added CNAME Records to the services like this:
This fixed the whole thing for me :)
=> More informations about this toot | More toots from bobslaede@feddit.dk
@bobslaede@feddit.dk I could kiss you. You’ve been invaluable my friend, thank you!
Just gave this a test: CNAME ombi.domain -> local.domain with cloudflares proxy re-enabled.
Now the HTTPS, A, and AAAA requests all receive the CNAME response and browsers are happy. I didn’t even have to modify ngnix to recognize local.domain like I thought I might.
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca
Awesome! I’m glad that it worked. It took me a while to figure out, when it happened to me. Glad that I could make your life easier :)
=> More informations about this toot | More toots from bobslaede@feddit.dk
I had a similar problem when using nginx proxy manager. In the end I just gave up and directly used cloudflare tunnels+cloudflare ssl
=> More informations about this toot | More toots from Moonrise2473@feddit.it
I think I’ve found the problem:
It seems my issue is pihole being unable to block/modify dns requests for HTTPS records, which don’t match the LAN IPs pihole handed out in A/AAAA records.
I’ve disabled cloudflare proxying so they don’t have HTTPS records to serve, but I’ll have to replace pihole with a better lan DNS solution if I want to turn that back on.
=> More informations about this toot | More toots from Darkassassin07@lemmy.ca This content has been proxied by September (3851b).Proxy Information
text/gemini