Recently I've installed luci-app-banip on my OpenWrt router and blocked most countries from accessing my services on my network. Not seeing why I would want any of that traffic I also blocked the whole of the ARIN registry, responsible for IP addresses from Canada and the United States.
Edit: Note this is only for inbound traffic. Outbound traffic is allowed no matter the target country.
Fast forward a few weeks and my certbot renewals fail with the following error: Failed to renew certificate enter.domain.here with error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Read timed out. (read timeout=45)
Confused af I start looking for solutions and as so often only find useless or completely ridiulous solutions (lowering my MTU to 1300, what? WHY?). Finally I find some enlighted figure that says they recently enabled a blocklist for certain countries and that was the issue for them.
Now I make the connection to my use of banIP, re-allow the USA and my cert renewals start working again. Hooray!
However, there are two things bothering me:
- Why would such a block even interrupt my renewals? I'm using DNS challenges and the ACME servers should only check the DNS entries, not where those entries actually redirect to. The DNS server/root isn't in my home network, so isn't affected by any firewall shenanigans I do here.
- How can I make an exception for the Let's Encrypt ACME servers while blocking the rest of the ARIN IP space?
I see there's the option for ASN selection and external allowlists:
Does anybody have an idea on how to configure this so that Let's Encrypt continues to work without compromising on my network security?
(Edit: And just for clarity, I do not live in the US or anywhere on the American continent.)
AFAICT it is using DNS challenges, unless the cerbot netcup plugin somehow does stuff it shouln't need to do.
agreed. you are using DNS-01 challenges. so the workflow is...
your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.
the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let's encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.
even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.
the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let's encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.