Here is a support call we get more often than you would think: “Our website is down.” Someone pulls it up on their phone, off Wi-Fi, and it loads fine. Back on the office network, it fails, throws a certificate warning, or lands on a router login page. The website isn’t down. The office network just can’t find its way back to a server that sits inside the same building.
We know this one well because it happened in our own office in Markham this past August. Our websites and a few internal tools run on our own hardware in the building, and from inside the office some of them started coming up with certificate errors while they loaded perfectly from home. Here is what causes it, how we fixed it, and the mistake we nearly made along the way.
What is actually going on: hairpin NAT
When you type your company’s web address, your computer asks DNS for the IP address. Public DNS hands back your office’s public internet address, the one the outside world uses. So your computer sends the request out to your own firewall’s front door and asks to be let back in to a server sitting twenty feet away.
That U-turn is called hairpin NAT (or NAT loopback). Some firewalls handle it cleanly. Many don’t, or handle it inconsistently: the request hits the firewall’s own management page, gets the wrong certificate, or just times out. Results also vary by device, which is why one person in the office says “it works for me” while the person next to them gets an error.
The fix: split-horizon DNS
The clean fix isn’t on the firewall. It’s on the office DNS server. You add local records so that when a computer inside the office asks for your website, it gets the server’s private, internal address and goes straight there. No trip out to the internet and back. Outside visitors still get the public address. Same name, two different answers depending on where you’re standing, hence “split horizon.”
Most offices already have something that can do this: a local DNS server, a Windows domain controller, or a filtering DNS box. It’s usually a five-minute change once you know which box your computers are really using.
Our mistake: checking the wrong DNS server
That last part tripped us up. Our first diagnosis came from a server whose default DNS setting went out to a public resolver, not the office one. From that server’s point of view, it looked like the office had no local DNS at all. That was wrong. The office computers were using a local DNS server the whole time. It just didn’t have records for every service.
The lesson: test from the same place your users are. If you check DNS from a server, a laptop on VPN, or a phone, you’ll get a different answer than the front-desk PC gets. Look up which DNS server the affected machine actually uses, then query that one directly.
Don’t fix one name. Audit all of them.
Once the first record was in, we didn’t stop there. We pulled every hostname our reverse proxy serves and compared that list against the records on the office DNS server. Seven names were missing.
We added three. We deliberately skipped four, and that part matters. Two of those names point to a website hosted at an outside hosting company, not on our hardware. The other two belong to a domain that still points to a registrar’s parking page. If we had added local records sending those names to our server, every computer in the office would have lost access to a live site we don’t even host, and it would have looked like a brand-new outage.
So the rule we wrote down for ourselves is simple: before adding a local override, look up the name’s public address. Only override names that actually point at your office. If it resolves somewhere else, it isn’t yours to redirect.
Signs your office has this problem
- Your website, client portal, or camera system works on cellular but not on office Wi-Fi.
- Browsers inside the office show certificate warnings for your own domain.
- Typing your web address in the office opens your router’s or firewall’s login page.
- It works for some people in the office and not others, or it “fixes itself” for an hour and then breaks again (that’s DNS caching).
- You recently moved a website, phone system, or file server onto hardware in your building.
None of these mean anyone hacked you or that your server failed. They mean the network needs to know where its own services live. It’s also a good reason to keep a written list of every hostname your business uses and where each one actually points. Most small offices don’t have that list until something breaks.
Want us to take a look?
Digitech handles this kind of network housekeeping for small businesses across the south suburbs: DNS, firewalls, internal servers, and the documentation that keeps the next problem from turning into a mystery. If something in your office only works from outside the building, call us at 708-596-2990 or email mknipper@digitech815.com. We’ll track down where the traffic is really going.