Usually you'd get an immediate "Connection refused" error if there isn't anything listening on a port and it isn't firewalled, not a timeout.
Also, unless /proc/sys/net/ipv6/bindv6only
is set to 1
, the socket listening on :::80
is also accepting IPv4 connections, so nothing strange there. See linux - Semantics of :: and 0.0.0.0 in dual-stack OSes - Server Fault for more info. However, even if bindv6only
is set, certbot will correctly listen on IPv4 and on IPv6, as demonstrated by:
server ~ # cat /proc/sys/net/ipv6/bindv6only
0
server ~ # netstat -tulpen | grep python
tcp6 0 0 :::80 :::* LISTEN 0 17943545 23547/python3.9
server ~ # echo "1" > /proc/sys/net/ipv6/bindv6only
server ~ # cat /proc/sys/net/ipv6/bindv6only
1
server ~ # netstat -tulpen | grep python
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 17947075 23578/python3.9
tcp6 0 0 :::80 :::* LISTEN 0 17947074 23578/python3.9
server ~ #
(In a different screen
window I used certbot certonly --staging --standalone --debug-challenges -d example.com
to have certbot listen on port 80..)
So no problem with certbot nor Let's Encrypt if you'd ask me. Highly likely this is a firewall and/or router issue.