@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.
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.
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 LAN A/AAAA records don't match the HTTPS record from cloudflare, 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 :(
Thank you @bobslaede@feddit.dk for pointing me in the right direction.
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' (true). 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.
I'll look into that next if what I've done doesn't work. (see other comments)
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.
Crap, looks like that's exactly what it is.
Now how to fix that...
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.
/edit; I've also disabled 'use secure DNS' in chrome. I host a local DNS within that lan/vpn network.
You've done enough, keeping it behind your routers firewall.
You could block LAN access and require a VPN connection to that specific machine if you really wanted more, but I'm not that concerned about it.
Yup. Point is; if you're not depending on just its login page to keep it secure, there's not a whole lot needing 'security patches', so I wouldn't be all that concerned about slow updates. As long as it remains bug free, I'm happy.
And security patches
Something with the power of dockge should be behind a seprate form of authentication imo.
I only access it via VPN, it's not exposed to WAN.
I tend to rip music videos from youtube with yt1s.com
It's manual and tedious, but works. I'd like a solution like the arrs, but I also don't keep many music videos so ๐คท