I love the weapon of choice for taking out Batman: a bat.

I have to wonder how effective those nets/fences/cages are; especially with the vastly varying build quality. (everything from plastic construction fencing, to metal chicken wire, to steel gratings.)

If I remember right, it was just over 2 weeks; but it’s been a couple years since I ordered.

I’ve ordered my last 2 sets from there, and had at least 3 family members ordering from there too. We’ve never had any issues aside from one poorly fitting set, which they returned and got fresh ones free of charge. I really couldn’t be happier with goggles4u.

I’ve really got to get around to seeing the optometrist and getting a fresh prescription… Time flies.

https://www.goggles4u.com/

Code at checkout: BOGO

Last time I bought glasses there, it cost me ~60$ for 2 pairs. Both with scratch resistant coatings, and one with a photochromic coating (auto tint in sunlight).

So… Add high-contrast uniquely identifiable markings to yourself?

Seems counterproductive.

@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.

I’m always a bit put off when she shows off her dick.

But, look at that perspective shot; that thing is HUGE! You definitely want to sleep with me now right? Right??

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.

Yes, obviously that’s always been an option.

I dont see a good solution for the topic we were actually talking about: creating high-power public use charging ports.