2
1
I've got a bit of a weird problem and a stack of symptoms that I can't make sense of.
I have a .com domain that points to my home IP address. Inside my LAN, I use external DNS resolution, so if I perform an nslookup internally, I get my external IP rather than the LAN IP.
Here's what happens:
- When I am at home (on a device that has an internal IP, say 10.0.0.20)
- AND I am running Chrome for Windows (running Chrome 35 atm)
- AND I try to reach a resource using my external domain name via HTTP (e.g. http://www.homedomain.com)
... then Chrome immediately converts the protocol to https (in the address bar) and complains about an SSL error. I can't reach the target.
It works as expected if I use the same Chrome build on an external machine (e.g. same user profile on my PC at the office). It also works locally using Internet Explorer and Firefox. It is only an issue running Chrome internally. I can reproduce this on 2 different machines, one running Windows 8.1 and the other Windows 7, and can reproduce it both on wifi and wired.
My home server runs Windows Server Essentials 2012 and I have an internal domain, but I don't think the server is involved in my issue.
I've configured my router to forward port 1880 to a Raspberry Pi device, where I have an http server listening. Outside of Chrome, I can hit http://www.homedomain.com:1880 and it will resolve perfectly. When I try it in Chrome, it instantly converts to https and fails (because the RPi isn't accepting SSL connections). When I use the LAN IP in Chrome it also works.
The router is running the Tomato firmware.
What's going on here?
- It can't be a blatant Chrome setting/bug, because the same Chrome profile/version works when I am outside the LAN.
- It can't be a local PC setting, because IE and Firefox work fine.
- It can't be my Windows Server, because the router itself is handling the port forwarding.
- It can't be the router, because IE and Firefox work fine.
I'm out of ideas - clearly one of my above assumptions is incorrect. Does Chrome have fancier network code that is causing unexpected behaviour in my situation? Can I have some kind of loopback issue that IE/FF are gracefully handling?
I've run out of ideas. If anyone has a suggestion for where to investigate I'd appreciate it.
Update: Another piece of data - Chrome (using the same user profile) behaves correctly when run inside a Hyper-V VM hosted on an affected machine.
Update 2: This behaviour goes away when I create a new Chrome user profile. The moment I log that profile into my Google account, however, the problem returns. It seems to be "something in the Chrome user profile" that is tied to my Google account.
dunno and this may be irrelevant but does it make a difference whether you are logged in to google or not? I find if I go to www.google.com it goes https if i am logged in. I also have an issue with a win xp sp2 machine running chrome, that when it tries to go to twitter it goes to https and gives en error. other browsers are fine – barlop – 2014-06-06T19:50:49.533
Good suggestion, @barlop! Being signed into Google or not (I used Incognito mode to test) didn't make a difference, but in checking that I discovered that this problem doesn't affect Chrome when it's run in a Hyper-V VM hosted on an affected computer. – Stefan Mohr – 2014-06-06T20:34:29.057
ah I just tested without being logged in (whether normal window or incognito window) and it went to https google.com About a year ago it only went to https when logged in. – barlop – 2014-06-06T20:43:58.610