I (often) can't access Fastly servers using HTTPS+IPv6: RST packets received

Comments

4 comments

  • Justin

    The problem may to be related to my Technicolor TG788vn VDSL/ADSL modem router.

    It's very likely that is the root of the issue. We rely on certain parameters to be hashed on for TCP/IP flows to complete successfully, and we've seen certain routers that don't hash properly when using IPV6. If you have an alternative router try with that and it is likely to work.

  • Ludovic_Rousseau

    Thank you for your answer.

    It’s very likely that is the root of the issue. We rely on certain parameters to be hashed on for TCP/IP flows to complete successfully, and we’ve seen certain routers that don’t hash properly when using IPV6.

    Can you be more specific about which parameters are important for Fastly? I plan to report the problem upstream but need as much details as possible.

    If you have an alternative router try with that and it is likely to work.

    I have another ADSL modem but I don't think it has IPv6 support.

  • Justin

    Can you be more specific about which parameters are important for Fastly? I plan to report the problem upstream but need as much details as possible

    Sure. In order for the TCP flows to work correctly we need the source and destination IPs and ports as well as the protocol. If any of these are incorrect or inconsistent you're likely to see problems like the resets you've described. We've seen this happen with several models of that router brand on a few ISPs.

  • Leif Strickland

    Hey Justin. Technicolor modems are widely used by Spectrum (I used to have one in my home in Los Angeles), and according to their annual report, their home-connectivity division had €1 billion in sales last year, including an exclusive contract with Comcast. Are you working on a solution to support all modems? I am concerned if Fastly's position is that connections will intermittently fail for https/ipv6 for certain modems, especially ones that are widely used by U.S. ISPs. That is not a high-availability setup.

    I personally experienced these problems earlier this month during a two-week stay at an Airbnb in Lisbon. When trying to access fastly-hosted sites such as python.org, fastly.com, cnn, etc. in a browser, I would get a connection error for the first 10 or so loads. Then the page would finally load, and it would continue working for the duration of the session (but the errors would begin anew for later sessions). I experienced no similar errors for non-fastly sites during the duration of my use of that access point, despite very heavy browsing for work. I was not able to find out the brand of the modem.

    Recent testing with monitoring services makes me concerned that these https/ipv6 problems are even more widespread. I have been using several monitoring services (Site24x7, Uptrends, etc.) to test https/ipv6 for fastly-hosted websites (including my own), and am experiencing frequent TCP connection failures from various testing locations. However, I am seeing no such errors reported for my controls: fastly-hosted sites via https/ipv4, or Cloudflare-hosted sites accessed by https/ipv6.

    I am no networking expert, but is it not possible to recover from incorrect or inconsistent parameters from certain routers? If not, I feel like it's important for fastly to communicate to users that ipv6 should not be used if 99.999% reliability is desired.

    Again, in my limited testing, with all else being equal, it does not appear that other CDNs are experiencing these same errors. I really like Fastly and hope that these issues can be resolved.

Please sign in to leave a comment.