Our Website Worked Everywhere Except the Office. How Did You Find the Fault?

This question has been published anonymously. Details that could identify the person or organisation have been removed.

Why This Type of Fault Produces a Three-Way Blame Cycle

A website that works externally but not from a specific office involves at least three separate systems: the DNS infrastructure, the network path between the office and the server, and the web server itself. Each supplier looks at the part they are responsible for, finds it functioning, and reasonably concludes the problem must sit somewhere else.

The telecoms provider checks that the office has an internet connection — and it does. The web developer checks that the website loads from their location — and it does. The IT company checks the office network internally — and finds nothing obviously broken. All three assessments are individually correct. None of them proves what actually happens on the path between the office and the website.

This is why the symptom — 'the website doesn't work' — is not enough information to resolve the problem. It needs to be broken into testable components.

The Three Things to Test Separately

A working website connection requires three things to function correctly in sequence. Testing each one independently tells you which layer is broken.

Layer 1: DNS — Does the domain resolve to the correct IP address?

DNS translates a domain name — such as example.com — into the IP address of the server hosting the website. If DNS is broken, the browser cannot find the server at all and will typically show a 'DNS_PROBE_FINISHED_NXDOMAIN' or 'server not found' error rather than 'site can't be reached'.

Testing DNS from two locations is simple. On Windows, open a command prompt and type: nslookup yourdomain.com. On macOS or Linux: dig yourdomain.com. If both locations return the same IP address, DNS is working correctly on both. If the results differ, or one location cannot resolve the name at all, the DNS configuration is the fault.

Layer 2: Network path — Can the office reach the server on port 443?

A browser accessing a website over HTTPS connects to the server on TCP port 443. If the DNS resolves correctly but the connection times out or is refused, something on the network path is blocking it. That could be a firewall rule at the office, a rule at the telecoms provider, or a block further up the network.

The test is: can the office establish a TCP connection to the server on port 443? This can be tested with: Test-NetConnection yourdomain.com -Port 443 (PowerShell on Windows) or nc -vz yourdomain.com 443 (macOS/Linux). A timeout or connection refused result from the office, when the same test succeeds from outside the office, isolates the fault to the network path.

Critically: test this using both the domain name and the server's raw IP address. If both fail, DNS is ruled out as the cause. The connection is being blocked regardless of how the server is addressed.

Layer 3: Web response — Does the server return the website?

Once a TCP connection succeeds, the server should respond with HTTP headers and page content. If the connection completes but the server returns an error, the fault is in the web server configuration or hosting — not the network. A tool like curl -I https://yourdomain.com will show the HTTP status code and headers returned by the server.

If this test works from an external connection but not from the office, and the TCP connection itself times out from the office, you already know the fault is in layer 2 — the network path. You do not need to reach layer 3.

What the Tests Showed in This Case

Working through the three-layer test from both the affected office and a separate external connection produced the following results.

The DNS test produced identical results from both locations. That ruled out a split-DNS problem and any DNS-related cause entirely.

The TCP connection tests told the real story. Port 443 was unreachable from the office, and the result was the same whether tested by domain name or raw IP address. This meant the block was not DNS-related — something was actively preventing the TCP connection from completing, regardless of how the server was addressed.

That combination of results could only be explained by something between the office and the web server — a firewall, a content filter, or a routing policy — blocking outbound connections to that specific IP address or port.

With that evidence in hand, the telecoms provider was given something specific to investigate: a firewall rule affecting outbound TCP connections to this destination. The block was traced to a misconfigured firewall rule on the telecoms side. Once corrected, the website became accessible from the office.

Common Causes of This Type of Fault

A website that is unreachable from one office only, while working everywhere else, usually has one of these underlying causes.

• A firewall rule at the office perimeter or within the telecoms provider's network blocking outbound connections to specific IP addresses, ports or domains — sometimes introduced by a policy change or equipment update
• Content filtering software configured to block a category that has incorrectly classified the website — IT security tools that filter web traffic can block sites based on category, reputation score or domain age
• A web application firewall on the hosting side that has geo-blocked or rate-limited the office's public IP address — sometimes triggered by scanning activity from that IP
• A routing or BGP change that has redirected traffic from the office through a different path where a block exists
• CGNAT (Carrier-Grade NAT) situations where the office shares a public IP with many other customers, and one of those customers has caused the IP to be blocked by a security service
• Split-DNS misconfiguration that causes internal users to resolve the domain to a different address from external users — typically an internal server that is not running the website

In this case the fault was a telecoms firewall rule. The TCP test from both domain name and raw IP address was the key — it proved the block existed independently of DNS, which directed attention to the right place.

How to Give Suppliers Something Concrete to Investigate

The problem with 'the website doesn't work' as a support ticket is that every supplier can correctly demonstrate their own system is functioning and hand it on. Evidence replaces that dynamic.

In this case the evidence was: DNS resolves correctly from both locations to the same IP address. Port 443 connection times out from the office, tested against both the domain name and the raw IP address. The same test succeeds from an external connection. This means the fault lies in the network path between the office and the server.

That statement cannot be argued with by either the web developer (their server is reachable externally) or the IT company (their internal network is fine — the block is further out). It directs responsibility to the only remaining candidate: the network path, which is the telecoms provider's domain.

A Practical Sequence for Diagnosing Office Connectivity Problems

1. 1Confirm the symptom is consistent — test from multiple devices on the same office network and from a mobile device on the office Wi-Fi versus mobile data. This confirms it is the network, not a single device.
2. 2Note the exact error message — 'ERR_CONNECTION_TIMED_OUT' and 'ERR_NAME_NOT_RESOLVED' point to different layers. Timed out means the connection is not reaching the server. Name not resolved means DNS failed first.
3. 3Run the DNS test from inside and outside the office — confirm whether both return the same IP address.
4. 4Run the TCP port test from inside and outside — test against port 443 using both domain name and raw IP address.
5. 5If the port test fails from inside the office, note your public IP address and contact the telecoms provider with specific evidence of where the block occurs.
6. 6If the port test succeeds but the website still does not load, the fault is in the web server or hosting — contact the web developer with the HTTP response or error returned by curl.

IT Club View

The three-layer diagnostic approach — DNS, connectivity, web response — works for almost any 'website doesn't work from here' problem. It is not technically complex; the tools are available on any business computer. The value is not in the tools themselves but in the discipline of testing each layer separately and comparing results from two different connections.

When all three suppliers are confident the problem is not theirs, it usually means none of them has tested the full path. Two targeted tests from the office — DNS resolution and a TCP connection to port 443 — produce evidence that cannot be argued with. They turn a vague multi-supplier dispute into a one-line instruction to the correct party.

It is also worth noting what the tests ruled out quickly. DNS was confirmed correct within seconds. The web server was confirmed working from outside. That left only one explanation: something between the office and the server was blocking the connection. The rest of the investigation was a matter of working with the telecoms provider to find it.