Fun problem here... anyone want a crack at this?

I'm staying at a hotel for a few days. Hotel's network connects upstream to CenturyLink. Both ethernet and wifi are available, both go to the same network on the back end. Both require the usual portal page where you enter the hotel's "secret code" to get onto the network, and then for a few days after that, your device is authorized. (These usually use the mac address to track which devices are authorized, don't they?)

Anyway, it mostly works, in fact, I'm typing this message while on this very network. So far so good. Most web browsing works to most web sites. Gmail works, google works, connecting to my company's various Microsoft-hosted resources works (outlook email, azure hosted services, etc), all good so far...

Until I try to use "sheets.google.com" or "docs.google.com" and then the browser hangs with ERR_CONNECTION_TIMED_OUT.

Diagnostics I have done:
- Traceroute to "sheets.google.com" hangs after the first hop (which is the hotel's 10.x.x.x gateway).
- Traceroute to "google.com" is fine.
- Same issue is reproducible on the following systems: Safari on Mac, Chrome on Mac, Safari on iOS, Chrome on Windows, IE on Windows, traceroute on Mac, third party traceroute tool on iOS.
- Issue is equally reproducible on hotel ethernet or hotel wifi.
- Issue is equally reproducible whether I'm directly connected to the hotel network, or I've connected through my travel router. Basically, I'm thinking the problem is upstream of my hotel room, but not far upstream (one hop at most).
- Weird side note: The "Google Sheets" app on iOS works correctly and I can get to my files that way. I can only assume that it works because it's not using "sheets.google.com" for its connectivity, it must use some other addressing scheme. And as mentioned above, surfing to sheets.google.com from my iOS device's browser encounters the same hang.
- Clearing cache on the browser does not help. Opening an incognito window on the browser does not help. Restarting the computer does not help.

I can work around the issue by tethering to my iPhone and having the iPhone use cellular data. But I'd prefer not to have to do that workaround while I'm here, if I don't have to. Using the (working) iOS app is not a valid workaround at all, because the app is very feature-limited and it's a pain to use.

I don't understand why it would route fine to google.com but not to sheets.google.com. If the hotel or their ISP is blocking the address deliberately... why would they block that, specifically? I'd think they'd want their guests to be able to like, reach their documents or something. Why would they allow gmail but not google docs?

I wonder if there is a different URL I could type in, perhaps whatever it is that the iOS app is using. Not sure how I could figure out what that is.

Traceroute output looks like this:

tonyfabris@MonkeyMac ~ % traceroute google.com
traceroute to google.com (172.217.14.206), 64 hops max, 52 byte packets
1 10.17.7.250 (10.17.7.250) 8.512 ms 9.158 ms 2.298 ms
2 * * *
3 63-145-202-33.dia.static.qwest.net (63.145.202.33) 4.090 ms 9.676 ms 10.017 ms
4 tuk-edge-14.inet.qwest.net (63.145.195.129) 10.004 ms 9.286 ms 10.257 ms
5 sea-edge-15.inet.qwest.net (67.14.41.158) 9.434 ms 13.059 ms
sea-edge-15.inet.qwest.net (67.14.41.162) 10.079 ms
6 72.14.221.110 (72.14.221.110) 9.439 ms
72.14.221.108 (72.14.221.108) 9.104 ms
72.14.221.110 (72.14.221.110) 7.565 ms
7 * 74.125.243.177 (74.125.243.177) 7.462 ms
74.125.243.193 (74.125.243.193) 4.705 ms
8 209.85.254.171 (209.85.254.171) 8.901 ms
108.170.245.97 (108.170.245.97) 9.465 ms
209.85.254.237 (209.85.254.237) 8.986 ms
9 108.170.245.123 (108.170.245.123) 14.565 ms
sea30s01-in-f14.1e100.net (172.217.14.206) 9.070 ms 9.410 ms

tonyfabris@MonkeyMac ~ % traceroute sheets.google.com
traceroute to www3.l.google.com (142.251.33.110), 64 hops max, 52 byte packets
1 10.17.7.250 (10.17.7.250) 9.608 ms 7.546 ms 1.502 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
(...)

Here, sheets.google.com resolves to 142.251.33.174.

You can probably bypass whatever part of the hotel firewall is causing the issue, by using a VPN.

EDIT: traceroute gives me totally different routes to 142.251.33.110 and 142.251.33.174, though both work from here.

https://digwebinterface.com/?hostnames=s...mp;nameservers=

I'm also getting a different IP address. You can try to edit your host file to override the DNS for sheets.google.com and see if that will work. Just don't forget to remove it later.

https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/

Hosts file hacking is a good idea.

I can ping 142.251.33.174, so I tried adding these to my /etc/hosts file, but it does not solve the problem:

142.251.33.174 sheets.google.com
142.251.33.174 www3.l.google.com

I can tell the modified hosts file is working because when I type "ping sheets.google.com" it pings the updated address. It just still doesn't allow that page to load in the browser.

On the other hand, "sheets" isn't the only page that loads, it might need to connect to "docs.google.com" too so I'll poke at changing that as well.

Aha, this worked:

/etc/hosts

142.250.191.174 docs.google.com
142.250.191.238 sheets.google.com
142.250.191.238 www3.l.google.com

Pages load fine now.

I'll have to remember to revert this hack after I leave the hotel.

Thanks guys! That was a great idea!

Not to beat the dead horse, but why not just fire up a VPN like Mark suggested?

Pretty much even either way.

Recent wisdom says "always use a VPN when in a public location" (eg. coffee shop or hotel room) to protect one's communications.

But then.. very few VPN providers are "trustworthy" these days -- most of them are now owned by the same historically untrustworthy individual, who's been buying them up left and right.

So.. pick your poison.

windscribe.com is supposedly one of the good ones, with decent rates too.

You can always roll your own VPN
https://www.linode.com/content/how-to-roll-your-own-vpn-openvpn-easy-setup/

I'm sure you can find details on how to setup the same with AWS or Azure.

Good question about the VPN option.

I used to work for a company that makes corporate VPNs, so I'm intimately familiar with them. It's true that a VPN would likely have solved the problem as well. I should have at least tried it for another diagnostic data point.

It was mostly the principle of the thing, I felt like the hotel network should have worked. (Maybe I'll report this as a bug to them or something: The DNS server on their gateway needs to be reset, it seems.)

Other reasons that I didn't want to try a VPN:

I had my company's corporate VPN ready to go, and I figure it would have worked, but it would only have functioned on my company PC, not the other devices.

I don't trust those "personal use" VPNs for the reasons Mark cited, and also because they have very deceptive advertising practices, trying to convince home users that they need a VPN for security (they don't).

I have occasionally considered activating the VPN hosting software on my Synology NAS and using that; it would occasionally be useful for dialing into my home network to get stuff done there. But with the pandemic I'm hardly ever away from home (today was an exception) and so it's not set up.

I looked into this. The compatibility matrix for it is problematic. Most things these days support IKEv2, but the Synology software doesn't. Android 12 dropped support for L2TP and only supports IKEv2. OpenVPN is just ... bad. The UI is bad; the configuration is bad.

I was going to set it up on SRM, rather than DSM, but the risk involved in messing around with it in a house full of people also using the internet made me pause.

I'm planning on port-forwarding to a Wireguard instance (possibly on an RPi4) instead.

I am considering using it for point-to-point VPN to my mother's house, though (once I've switched out her default router for a Synology one).

+5 for WireGuard. I have a different solution that I've been using for a while, but my ASUS router now has WireGuard inside, though not yet exposed in the WebGUI. The next firmware release will probably have the WebGUI for WireGuard, at which point I'll definitely configure it!

And yeah, OpenVPN.. config nightmare. I don't use it.

My occasional-when-necessary VPN solution: my desktop computer, in my Rice office, has a public-facing IP address and is running an ssh daemon. It's configured to only allow public-key authentication, so I'm pretty happy with the security story. ssh allows you to use the -D flag to create a SOCKS proxy. So, I'll just ssh to my desktop with the proxy enabled, then tweak the browser setting to use it, and then everything works.

If you don't have a handy machine like this, you could create one on the fly with Amazon EC2 or equivalent, which I'd trust far more than any of the VPN vendors. I'd probably trust that more than our campus's own Cisco-branded VPN gateway.