0

Running IIS 10 on Windows Server 2016, I have encountered an issue where an IPv6 binding has mysteriously stopped working.

When connecting from the server via IPv6 or connecting from any system via IPv4, everything works fine and the site loads as expected.

When connecting to the hostname with no subdomain or when connecting to another domain bound to the same site, IPv6 works fine, however when attempting to connect with a www subdomain or several other previously working subdomains, the connection times out over HTTPS. HTTP (which is setup just to redirect to HTTPS) also is working fine regardless of hostname.

Both working and unworking bindings are going to the same IPv6 addresses and both the working IPv4 bindings and the IPv6 bindings are on the same IIS site. I have rebuilt the bindings without any luck.

I'm running out of ideas on what to check. What could be causing HTTPS over IPv6 to time out on only some subdomains? (I've also tried with simple text files to ensure that it isn't a scripting issue. I've also tried clearing the web.config without any luck.)

The site in question is ajhenderson.com. robots.txt is available on the root and can be used for seeing the behavior.

Other sites on the same IIS instance but using different IPv6 addresses and IIS sites are working fine. Attempting to use the IPv6 address for ajhenderson.com with one of the other sites had the same failure (moved the www.ajhenderson.com binding to another IIS site).

Update: It appears whatever was causing the problem resolved itself. I had run tests in both Chrome and Firefox from both Windows machines and Android from 4 different devices with 4 different internet connections in 2 different states. They were all showing the same behavior earlier, but now have mysteriously corrected themselves.

Update again: It appears to be a somewhat intermittent problem, however it is back at this time, though it looks like maybe it is IPv4 not working and IPv6 working this time around. Here is a line from httperr.log:

2018-05-04 18:44:52 x.x.x.x 27313 74.208.155.100 443 - - - - - - ClientCancel -
AJ Henderson
  • 369
  • 3
  • 15
  • What do you mean by "not working"? All three of those URLs load fine via IPv6 for me. – Michael Hampton Apr 11 '18 at 21:26
  • Indeed they are now working... Most of the afternoon today, they were not working over IPv6 from 4 different geographically disbursed locations on 4 different devices and multiple different browsers. Now they are working fine again... This scenario just keeps getting weirder, though at this point I'm doubting I'll find an answer to it since I can't prove an answer right anymore. Perhaps someone else will have something similar in the future and be able to add more details. – AJ Henderson Apr 11 '18 at 22:56
  • "Time out" is probably not what the web browser error message is. So if you do hope to help/warn someone in the future, you should revise the question to include the exact error messages (so they can search and find this post). – Lex Li Apr 16 '18 at 12:37
  • @LexLi - good point. Updated title to include the specific Chrome message, though the message differs based on browser given that the browser is indicating that the server did not respond in time. – AJ Henderson Apr 16 '18 at 20:43
  • I just tried your URLs again and they seem to be working fine on IPv6. – Michael Hampton May 04 '18 at 18:20

1 Answers1

1

I think you have a typo in your DNS records.

$ host ajhenderson.com
ajhenderson.com has address 74.208.155.100
ajhenderson.com has IPv6 address 2607:f1c0:841:39e6:2bda:14a7:47f:5b92
$ host www.ajhenderson.com
www.ajhenderson.com has address 74.208.115.100
www.ajhenderson.com has IPv6 address 2607:f1c0:841:39e6:2bda:14a7:47f:5b92

It looks liike the IPv4 address of www.ajhenderson.com has been mistyped.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • Indeed there is a typo there. It's odd that it was working before, but maybe it had to do with the browser I was using sometimes connecting on IPv4 and other times on IPv6. It also explains why the hosts record test I did made it work properly. Not sure why I'm getting client cancels on the HTTPERR log, but might just have something to do with the redirects I have going on. Might also be that I previously had a different problem and then typo'd while trying to get it working and redid my DNS records... oh well, hopefully this fixes it. – AJ Henderson May 04 '18 at 19:01