A certbot instance inside a LXC container cannot renew certificates (with the webroot method) since the update to TOS 7.1.
Let’s Encrypt try to contact my http server (running in the same container) for the webroot challenge, from the server outbound2p.letsencrypt.org (23.178.112.215) or outbound2l.letsencrypt.org (23.178.112.211), but the router firewall contains this in the set dynfw_4 (“IPv4 addresses blocked by Turris Sentinel”):
This is surely a problem in Sentinel. We filter out LE accesses (based on metadata, because IP addresses may vary), but it obviously fails due to an unknown reason. We will investigate and fix it.
They use much more addresses. The most of them are from the 23.178.112.0/24 range, but we have already detected some different addresses (probably related to their “multi-perspective validation”). Because of this, we don’t use IP addresses for LE detection at all, we use HTTP request metadata instead.
The implementation of the Let’s Encrypt filter in Sentinel has been fixed and improved. It should no longer block IP addresses used by Let’s Encrypt. We apologize for the problems.
Does your container have a public address or forwarded ports (80, 443) from the router (that must have a public address of course)? Does your ISP allow to access the given ports from the Internet?
It worked when I disabled the http minipot in sentinel. That means the minipot was hijacking LE requests to my server whereas other http requests were correctly forwarded to my server.
Since TOS 7.1, iptables have been replaced by nftables and the Sentinel components have been modified a bit. Therefore it need not be the same problem.
Hi! I’m just commenting to report that disabling the HTTP minipot in Sentinel solved my problems.
I have a server behind my Turris router, it was having problems with the certbot renew command. The renewal response from the Let’s Encrypt servers was a 401, “unauthorized” status. It couldn’t complete the check request to my router on port 80.
