MacOS – Unable to connect to a website on some WiFi networks

internetmacossafariwifi

I'm unable to connect to nytimes.com as of now with these WiFi networks in my college: secure, secure High-speed(5-GHz) and Eduroam recently (All are one time Sign-on and show lock icon in WiFi list). I could do that last week and I have not changed anything in network settings.

The error is standard offline error in Safari “You’re not connected to Internet” and sometimes “Server unexpectedly dropped the connection”. However I'm able to access a lot of other websites at the same time. I have tried this and got the same condition in multiple buildings.

On network say "X" (doesn't show lock icon in WiFi but requires authentication), I can visit the website after logging into Fortinet popup.

After switching back to the aforementioned networks and typing the IP address instead of textual URL, I got an error which said something like unrecognised domain. and some cache info.

What can the reasons behind this and what can I do to solve this?

Edit: The said WiFi "X" is also an college network.

Best Answer

It's a fairly common practice for schools and universities to block sites that they deem inappropriate. For example here's a snippet from Azusa Pacific University's Internet Filtering policy:

Background

APU’s internet filtering is performed through a subscription service. The hardware and database, referred to as an application in this policy, is developed and maintained by a nationally recognized, publicly held company.

How Filtering Works

The internet filtering mechanism uses several categorization technologies to group URLs. These include human review, a licensed contextual URL filtering engine, internally developed neural net analysis programs, and automated recognition of content labels generated by the Internet Content Rating Association that web developers often put on their sites. In addition, to ensure that categories are continually refreshed with new URLs, the mechanism relies on a technology called adaptive filtering, which automatically logs accesses by existing users to URLs that are not included in the existing categorized database. These URLs are then sent to a central repository, where they are reviewed along with the requests of other filtering appliances that subscribe to this service on a daily basis. The URLs are then categorized, added to the database, and an updated database is automatically sent to APU’s filtering appliance. The same process works similarly in reverse when a legitimate website has been labeled inappropriately—the customer appliance marks the URL as legitimate, and the URL is uploaded to the central repository and evaluated.

So your blocking is likely being done by your College.

If you're still unsure you can also use an online service such as downforeveryoneorjustme to also confirm if the website you're trying to access is actually down or if it's just your college that's blocking it.

Eduroam

Based on one of your updates to your question I was able to find some additional information regarding Eduroam. Here's an excerpt from their FAQ.

Does eduroam monitor or filter access?

eduroam provides authenticated network access at any location where the service is enabled.

Each participating organisation offering network access to authenticated users is able to apply its own filtering policies as long as it is clearly informing users about the filtering rules.

And also from their legal disclaimer:

GÉANT may add, revise or remove any content, and vary the site’s navigational structure, without notice.

Methods to further test

To investigate your supposed filtering you can attempt to look up the IP address of the website's domain and then use ping and curl to verify if you're being filtered at a particular point or if you're having a legitimate technical difficulty.

For example, using the command host to look up the IP:

$ host nytimes.com
nytimes.com has address 151.101.65.164
nytimes.com has address 151.101.129.164
nytimes.com has address 151.101.1.164
nytimes.com has address 151.101.193.164
nytimes.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.com.
nytimes.com mail is handled by 10 ASPMX3.GOOGLEMAIL.com.
nytimes.com mail is handled by 1 ASPMX.L.GOOGLE.com.
nytimes.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.com.
nytimes.com mail is handled by 10 ASPMX2.GOOGLEMAIL.com.

And you could also use ping to see if you're able to ping the IP addresses and/or hostname of the domain you're attempting to view.

$ ping -c 3 151.101.65.164
PING 151.101.65.164 (151.101.65.164): 56 data bytes
64 bytes from 151.101.65.164: icmp_seq=0 ttl=56 time=26.398 ms
64 bytes from 151.101.65.164: icmp_seq=1 ttl=56 time=20.649 ms
64 bytes from 151.101.65.164: icmp_seq=2 ttl=56 time=21.376 ms

--- 151.101.65.164 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.649/22.808/26.398/2.556 ms

Lastly you can use curl to see if you have physical access to the website's ports 80 and 443 which are where web content is typically served.

$ curl -v telnet://151.101.65.164:443
* Rebuilt URL to: telnet://151.101.65.164:443/
*   Trying 151.101.65.164...
* TCP_NODELAY set
* Connected to 151.101.65.164 (151.101.65.164) port 443 (#0)
^C

NOTE: Use Ctrl+C to stop the curl command. If you see Connected ... then you know you at least have physical access to the server's port 443.