Client browsers on my IPv6-enabled home network hang and time out when attempting to load https:// URLs from specific IPv6 sites, such as ones operated by CloudFlare. In those situations, the live log on my firewall shows it is silently dropping lots of inbound RST packets from the remote HTTPS server. Other IPv6 sites such as https://ipv6.google.com load immediately without any problem, sending little or no RST packets to my network. The only successful workaround I have right now is a firewall policy that blocks outbound HTTPS access to specific IPv6 address ranges, effectively forcing browsers to reach the problematic HTTPS servers over IPv4. A less attractive option is to turn off IPv6 entirely by disabling 6rd and radvd.
Here are some pertinent details of the environment:
- Internet connection is CenturyLink ADSL2+ PPPoE with single static IPv4 address
- DSL modem is Actiontec C1000A with latest firmware applied
- Firewall is Sophos UTM v9.2, which handles DHCP, DNS forwarding, packet filter, and inside radvd
- Modem handles NAT for IPv4 and 6rd for IPv6
- Networks shared by modem LAN and firewall external interface are 192.168.0.0/24 and fd00::/64
- Networks shared by client machines and firewall internal interface are 192.168.1.0/24 and 2602:xxxx:xxxx:xxxx::/64
- Traffic is routed from modem LAN to firewall external interface via static routes on modem instead of NAT on firewall
When it comes to HTTPS over IPv6, Google sites load fine for me, while CloudFlare-hosted sites invariably fail. Both are big companies with teams of networking experts, so I'm not even sure if CloudFlare is doing anything wrong here.
Is anyone else seeing CloudFlare's HTTPS servers sending lots of reset packets on IPv6 but not on IPv4?
Could my ISP, CenturyLink, be forging the RST packets in some misguided attempt to help or protect me?
Are the resets being sent because my browser is unhappy with some aspect of the server's SSL implementation?