Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 17277 views
  • Users 0 members are here
Options
Suggested

Activating Letsencrypt fails when using IPv6 - outgoing packets blocked by firewall

MarkusGerstner

Hey there,

when trying to enable Let's Encrypt-Support, I also get the error "The previous attempt to enable Let’s Encrypt failed: Failed to retrieve the current Terms of Service link. Please try again or check the Internet connection if the problem persists." despite having corrected the permissions on /etc/ssl/certs.

tl;dr: skip to "Workaround" below. :)

I set the permissions as per NUTM-10315, but /var/log/letsencrypt.log shows:
2018:09:28-21:33:00 utm letsencrypt[8313]: I Create account: creating new Let's Encrypt acccount
2018:09:28-21:33:31 utm letsencrypt[8313]: E Create account: TOS_UNAVAILABLE: Failed to retrieve current Terms of Service from remote server: 500 Can't connect to acme-v01.api.letsencrypt.org:443 (timeout)
2018:09:28-21:33:31 utm letsencrypt[8313]: E Create account: failed to create account

Pinging the host works on either IPv4 or IPv6, but connecting on port 443 fails via IPv6, as also mentioned by scorpionking in community.sophos.com/.../let-s-encrypt-error

utm:/var/log # ping6 acme-v01.api.letsencrypt.org
PING acme-v01.api.letsencrypt.org(g2a02-26f0-6c00-0185-0000-0000-0000-3a8e.deploy.static.akamaitechnologies.com) 56 data bytes
64 bytes from g2a02-26f0-6c00-0185-0000-0000-0000-3a8e.deploy.static.akamaitechnologies.com: icmp_seq=1 ttl=61 time=26.7 ms


utm:/var/log # ping acme-v01.api.letsencrypt.org
PING e14990.dscx.akamaiedge.net (184.30.223.223) 56(84) bytes of data.
64 bytes from a184-30-223-223.deploy.static.akamaitechnologies.com (184.30.223.223): icmp_seq=1 ttl=57 time=21.3 ms


utm:/var/log # telnet acme-v01.api.letsencrypt.org 443
Trying 2a02:26f0:6c00:187::3a8e...

Connecting via IPv4 works just fine:

utm:/var/log # telnet 184.30.223.223 443
Trying 184.30.223.223...
Connected to 184.30.223.223.


It's not an issue with the tunnelbroker itself, since I can connect to the site just fine from my PC, also using IPv6 via the tunnel broker:



Unfortunately, I can not test with native IPv6, so I don't know if this problem also applies to native IPv6-connections, but I'm pretty sure it does (see "A little more information" below).

Edit: just noticed that it's the firewall dropping the packets:



Workaround

Add an explicit Firewall-Rule:

Source: IPv6-Address displayed on the IPv6 Global Tab (or "Any IPv6", I guess)
Service: HTTPS
Destination: DNS-Group acme-v01.api.letsencrypt.org

 

A little more information:

iptables -vL AUTO_OUTPUT lists

    0     0 CONFIRMED  tcp  --  any    any     anywhere             anywhere             tcp spts:tcpmux:65535 dpt:https

while a similar rule seems to be missing in

ip6tables -vL AUTO_OUTPUT:

utm:/var/log # iptables -nvL AUTO_OUTPUT | grep 443
    0     0 CONFIRMED  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spts:1:65535 dpt:443
utm:/var/log #


utm:/var/log # ip6tables -nvL AUTO_OUTPUT | grep 443
utm:/var/log #

 

Please let me know if you need further information to investigate the issue.

Best Regards
Markus


Parents
  • 0

    Thanks for reporting this. We're tracking this as NUTM-10332.

  • 0 in reply to ewadie

    No idea if Sophos is still tracking this, but somehow, this bug is not fixed in 9.600-5 - I just noticed when trying to renew my now 2-months-old cert. Outgoing IPv6-Connections to Let's Encrypt are still being blocked if not explicitly allowed.

  • 0 in reply to MarkusGerstner

    Hi Markus,

    MarkusGerstner said:
    No idea if Sophos is still tracking this, but somehow, this bug is not fixed in 9.600-5 - I just noticed when trying to renew my now 2-months-old cert. Outgoing IPv6-Connections to Let's Encrypt are still being blocked if not explicitly allowed.

    We are reading you, but we would need more details if you want us to help.

    As this is now impacting the GA release, If you are entitled for support, please consider also to reach out to our support.

    Best regards,
    mle

  • +1 in reply to mle

    Hi mle,

    thanks for the quick reply. As the issue is mostly as described in the first posting, I think there is plenty of details already. :-)
    This is not impacting a production environment as of now and I do have a workaround, but as I'm pretty sure other customers will face the same issue, I'll go the official way.

     

    edit:
    I did some more digging. NEW certificates are obtained just fine via IPv6, the following rule seems to allow packets through:

     2   160 CONFIRMED  tcp      any    any     anywhere             anywhere             match-set pTJ/cScuf0VveVLJzZzmFA dst tcp spts:tcpmux:65535 dpt:https owner UID match dehydrated owner GID match dehydrated

    However, RENEWING certificates does for some reason not match the afore-mentioned ip6tables-rule and therefore fails just as described in the initial post.

    Anyway, opening a ticket now (#8602438 just in case anyone needs a reference).

    Best Regards

    Markus Gerstner

Reply
  • +1 in reply to mle

    Hi mle,

    thanks for the quick reply. As the issue is mostly as described in the first posting, I think there is plenty of details already. :-)
    This is not impacting a production environment as of now and I do have a workaround, but as I'm pretty sure other customers will face the same issue, I'll go the official way.

     

    edit:
    I did some more digging. NEW certificates are obtained just fine via IPv6, the following rule seems to allow packets through:

     2   160 CONFIRMED  tcp      any    any     anywhere             anywhere             match-set pTJ/cScuf0VveVLJzZzmFA dst tcp spts:tcpmux:65535 dpt:https owner UID match dehydrated owner GID match dehydrated

    However, RENEWING certificates does for some reason not match the afore-mentioned ip6tables-rule and therefore fails just as described in the initial post.

    Anyway, opening a ticket now (#8602438 just in case anyone needs a reference).

    Best Regards

    Markus Gerstner

Children
Unfiltered HTML