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.)
So I am pretty sure that error is happening because certbot can’t retrieve the certificate which is coming from that API no matter what type of challenge you are using (this is what ACME is).
Now when you say you are blocking inbound traffic, have you made an exception for established outbound session return traffic? If not then you your inbound rule will block all traffic because without that exception the explicit deny will typically override any session/stateful based rules your firewall might have by default (this applies to most firewall vendors I have run into).
That said, I’m not sure what your goal is but blocking outbound traffic to those ASN might be more effective for you anyway because your firewall should already be dropping any inbound traffic that isn’t otherwise allowed so I’m not sure blocking inbound traffic really gains you anything but I’m just guessing. Hope that all makes sense!
Well, blocking inbound traffic from these countires is part of my firewall. I have some services that are exposed on the internet, but I don’t want the whole world to hammer these services, scrape them and potentially exploit vulnerabilities on them. I know a VPN would be more effective here, but that’s not an option for every service.
Firewalls are typically built using ‘in’ rules, but it’s not referring to ‘wan > lan’ but rather if the rule is processed on the ingress of the firewall or the egress.
Stateful firewalls sessions are always going to allow responses, the old request that someone needs a rule ‘both directions’ is something of a running joke at this point honestly.
A pcap would explain a lot, the fact that the error cites a specific domain does sound like an outbound attempt, but if it was a specifically inbound region block that wouldn’t add up.