Website blocked on the company network: how to diagnose and fix it

TL;DR — If a website works on mobile data or a home connection but fails on the company network, the most likely cause is a company DNS filter, web proxy, or firewall policy blocking the domain or category. Start by testing the same URL on and off the company network, then check whether the block page names your security tool or whether DNS resolves differently; that usually tells you which fix path to use. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and you are trying to reach a vendor portal your team needs for billing, support, or a client handoff. The site opens fine on your phone over mobile data, but on office Wi‑Fi or the company VPN it either times out, shows a block page, or throws a certificate warning. You have a meeting in 20 minutes, someone says "it must be the website," and now you need a quick way to prove whether the company network is blocking it. You do not need deep networking theory here; you need a short path to the right team and the right evidence.

Symptoms

• The site loads on mobile data or a home network, but not on office Wi‑Fi or while connected to the company VPN.
• Browser shows one of these messages:
  • "This site can’t be reached"
  • "ERR_CONNECTION_TIMED_OUT"
  • "ERR_CONNECTION_RESET"
  • "ERR_NAME_NOT_RESOLVED"
  • "Your connection is not private"
  • "NET::ERR_CERT_AUTHORITY_INVALID"
  • "Access denied"
  • "This website is blocked by your organization"
• You see a branded block page from a security product, proxy, or firewall.
• The page redirects to an internal warning page instead of the site you requested.
• The URL works for coworkers off VPN, but fails for coworkers on the same office network.
• DNS lookup returns a private or unexpected IP, or no result at all.
• HTTPS (secure web traffic) fails, but plain HTTP may redirect to a block page.

Likely causes

Step-by-step diagnosis

1. Compare company network vs non-company network.

   • Action: Turn off Wi‑Fi on your phone and open the same URL on mobile data. If you are on a laptop, disconnect the company VPN and retry.
   • "This is your problem" output: The site works off the company network but fails on office Wi‑Fi or VPN.
   • Jump to: Continue to step 2.

2. Look for a block page or warning page.

   • Action: Open the URL in the browser and read the full page, including small text at the bottom.
   • "This is your problem" output: You see text like "blocked," "category," "acceptable use," "access denied," or a product-branded page.
   • Jump to: ## Fixes → ### DNS filtering or category-based web filtering or ### Company firewall or secure web gateway.

3. Check whether the browser is warning about the certificate.

   • Action: On the warning page, click the certificate details or padlock area if available.
   • "This is your problem" output: The certificate issuer is your company, a security appliance, or an unknown internal CA (certificate authority, the system that signs certificates), instead of a public issuer for that site.
   • Jump to: ## Fixes → ### TLS inspection is breaking the site certificate chain.

4. Check proxy settings in the operating system.

   • Windows: Settings → Network & internet → Proxy.
   • macOS: System Settings → Network → Wi‑Fi or Ethernet → Details → Proxies.
   • "This is your problem" output: A manual proxy is enabled, or an auto-config URL/PAC file (proxy auto-config script) is set and the site fails only when that proxy is active.
   • Jump to: ## Fixes → ### Proxy settings are forcing traffic through a corporate proxy.

5. Compare DNS results if you have a terminal.

   • Action: Run this on the company network, then again off the company network.

nslookup example.com

• "This is your problem" output: On the company network you get no answer, NXDOMAIN, a block-page IP, or a different result than off-network.
• Jump to: ## Fixes → ### DNS filtering or category-based web filtering.

1. Test whether VPN routing is the trigger.

   • Action: Disconnect the company VPN and reload the site.
   • "This is your problem" output: The site starts working as soon as VPN disconnects.
   • Jump to: ## Fixes → ### VPN split-tunnel or routing policy.

2. Gather evidence that the website may be blocking your company IP.

   • Action: In your provider's dashboard or by asking IT, get your office public IP, then ask the website owner whether it is blocked. If you have terminal access:

curl -I https://example.com/

• "This is your problem" output: You receive 403 Forbidden, a geo-block page, or the website owner confirms your company IP is denied.
• Jump to: ## Fixes → ### The website itself is restricting corporate IP ranges or geographies.

[Your Browser] ---- 1. request ----> [Company Network]
      |                                  |
      v                                  v
[Proxy/DNS/Firewall] ---- 2. allow? ----> [Website]
      |
      v
[Block Page or TLS Warning]

Fixes

DNS filtering or category-based web filtering

This is the most common cause when the domain works elsewhere but fails on the company network.

• Action in your provider's dashboard: open your DNS or web filtering policy and search for the domain. In many dashboards this is under a path like Security → DNS Filtering, Security → Web Filter, or Gateway → Policies.
• If the domain is miscategorized, add an allow rule for the exact hostname first, then the parent domain only if needed.
• If your IT team manages it, send them these exact details:

Blocked URL: https://example.com/
Time tested: 2026-10-30 14:25 local time
Works on: mobile data
Fails on: office Wi‑Fi and company VPN
Observed message: ERR_NAME_NOT_RESOLVED / block page says "Category blocked"
Requested action: allowlist example.com and required subdomains

• If you have endpoint DNS software, reconnect after policy changes or restart the browser.

Verify it worked:

nslookup example.com

You should now get a normal public IP and the page should load.

Company firewall or secure web gateway is blocking the site by domain, IP, or category

• Action in your provider's dashboard: open the web access or firewall policy area, often under Security → Firewall Rules, Gateway → HTTP/S Policies, or Secure Web Gateway → Policy.
• Search for the blocked domain, URL category, or the user/group your account belongs to.
• Add a narrow allow rule for the required domain and port 443 before broader deny rules. If your tool supports FQDN objects (domain-name objects), use the exact hostname.
• If you cannot edit policy, send the block page screenshot and the full URL to IT.

Example policy intent to request from IT:

Allow HTTPS to example.com and api.example.com for Finance group
Reason: vendor billing portal required for monthly processing

Verify it worked:

curl -I https://example.com/

You should get a normal HTTP response such as 200 OK or 302 Found, not a block response.

Proxy settings are forcing traffic through a corporate proxy

• Windows: Settings → Network & internet → Proxy.
  • Turn off "Use a proxy server" for a quick test if your policy allows it.
  • If "Use setup script" is on, note the script URL and send it to IT with the failing site.
• macOS: System Settings → Network → your active network → Details → Proxies.
  • Temporarily uncheck the enabled proxy entries for a test if allowed.
• Browser-managed proxy: in managed environments, the browser may inherit OS settings and cannot be changed locally.

⚠️ If your company requires the proxy for security or compliance, do not leave it disabled. Use this only as a short test, then revert or ask IT for an exception.

Verify it worked: reload the site. If it opens only with proxy disabled, the proxy policy needs an allow rule.

TLS inspection is breaking the site certificate chain

Some companies inspect HTTPS by re-signing certificates. Some websites, apps, or login flows do not work correctly with that.

• Action: open the certificate details from the browser warning.
• If the issuer is your company or an internal security device, ask IT to bypass TLS inspection for that domain.
• If your company intentionally uses TLS inspection, also confirm the company root certificate is installed on the device. IT can usually push this through device management.

What to send IT:

Site: https://example.com/
Problem: certificate warning only on company network
Observed issuer: Company Security Inspection CA
Requested action: bypass TLS inspection for example.com and login subdomains

Verify it worked: the browser padlock should appear normally and the certificate issuer should match a public issuer for the site.

VPN split-tunnel or routing policy is sending the traffic the wrong way

Split tunnel means some traffic goes through VPN and some goes directly to the internet.

• Action: disconnect VPN and retry.
• If that fixes it, ask IT whether the domain should go direct or through VPN.
• In your VPN client, look for a route or traffic policy screen if exposed; many managed clients do not show this to users.
• If you administer the VPN, add or correct the route/domain handling so the site uses the intended path.

What to send IT:

URL works when VPN is disconnected and fails when VPN is connected.
Please check split-tunnel policy, DNS over VPN, and web filtering applied to VPN users.

Verify it worked: reconnect VPN and confirm the site still opens.

The website itself is restricting corporate IP ranges or geographies

• Ask the website owner or vendor whether they block datacenter, VPN, or corporate IP ranges.
• Provide your office public IP. If you have terminal access:

curl https://ifconfig.me

• Ask them to allowlist that public IP or remove the geo/IP restriction.
• If your company has multiple offices, test from another office or egress point.

Verify it worked:

curl -I https://example.com/

A previous 403 Forbidden should change to a normal response.

Prevention

• Add a simple reachability check from inside the company network and from outside it. Run both every 5 minutes and alert on differences.

curl -I https://example.com/ || echo "failed"

• Keep a small allowlist register for business-critical domains in your security policy repository.

{
  "critical_domains": [
    "example.com",
    "api.example.com",
    "login.example.com"
  ]
}

• In change reviews for DNS/web filtering, require a test from a managed device on office Wi‑Fi and on VPN before closing the ticket.

Checklist: office Wi‑Fi test / VPN test / mobile-data control test / screenshot attached

• If your company uses TLS inspection, maintain a bypass list for sites known to break under inspection, especially identity providers and vendor portals.

Bypass TLS inspection for: login.example.com, sso.example.com, billing.example.com

• Log and retain block events with user, domain, category, and policy name so support can answer "why was this blocked?" quickly.

Required fields: timestamp, username, source IP, destination domain, category, action, policy

This article was written by an AI system and published pending human review. Verify anything you intend to act on.