Blocked Links - Websites Won't Open

[btovar071]

One of our customers is having some issues accessing various websites, and we’re having trouble isolating the issue. I’ve included some details below, including some of the steps we’ve tried so far, and some screenshots. I’d sincerely appreciate some help from the community!

Specs:
· Dell PowerEdge R440 rackmount server running as a domain controller:
o Windows Server 2019 Essentials x64, Version 1809, OS Build 17763.5936
o SQL Server 2019 Essentials installed and running
o Threatdown Endpoint Detection and Response on Server
o Running DHCP
o Running DNS
o Running ADDS
· Network Equipment:
o Ubiquiti Dream Machine Pro, UniFi OS version 4.0.21, UniFi Network version 8.6.9, not running DHCP
o Ubiquiti 24-port PoE Switch (USW-24-POE)
· Workstation(s)
o Windows 10 Pro x64, with 22H2 installed, Build 19045
o Threatdown Endpoint Detection and Response on each workstation
· Network Type: Domain
· Browsers:
o Chrome (latest version)
o Edge (latest version)

Two related issues:
1. Links in Emails:
a. When you click on a link in several different emails (just a select few from various senders, NOT every email), it opens up a browser with the following error message (see screenshot)
2. Websites in Browsers:
a. When you navigate to a website (some require that you log in, some do not), it returns the following error message (see screenshot)
b. When you click on a Sponsored search result in Google, it returns the following error message (see screenshot)

What we’ve done regarding both issues above:
1. Reconfigured Threatdown Endpoint agent running on that computer
2. Removed Threatdown Endpoint agent from computer
3. Disabled Malwarebytes Browser Guard and Adblock Plus extensions along with any other browser extensions that could be causing an issue.
4. Temporarily disabled all security settings in Chrome
5. Temporarily turned off UAC
6. Removed said browser extensions
7. Restarting computer several times
8. Ran each of the following commands:
a. DISM /online /cleanup-image /scanhealth
b. sfc /scannow
c. netsh winsock reset
d. net stop winmgmt then press Y, then press Enter,
e. winmgmt /resetrepository press Enter, Restart PC
f. netsh advfirewall reset
g. ipconfig /flushdns > Restart PC
9. Confirmed IP is dynamically assigned.
10. Left DNS 1: 192.168.x.x (our server), but changed DNS 2 from 8.8.8.8 to 1.1.1.1, flushed DNS, tried again
11. Cleared SSl within Internet Options in Control Panel
12. Checked Outlook settings to make sure the link options are set to open with default browser
13. Used Whois Lookup to see if the links are bad players, they look legit

 

[ChatGPT]

Issue Recap​

You’re seeing these errors across multiple endpoints:

• Inconsistent access to sites (some don’t work, others do).
• Email links and Google sponsored links often fail.
• The error codes are typically ERR_ADDRESS_INVALID, ERR_CONNECTION_TIMED_OUT, or DNS_PROBE_FINISHED_NXDOMAIN.
• You’ve ruled out browser extensions, security software, IP assignment, alternate DNS, and have reset Windows sockets, DNS cache, SSL cache, and firewall rules.

Likely Causes (Based on Your Details & Community Insights):​

1. DNS and Domain Controller Configuration​

Given that your server is providing DNS and is the DC, problems here can easily create the mix of “address invalid,” NXDOMAIN, and timeouts you’re seeing:

• Split DNS: If your internal DNS zone (e.g., domain.com) matches a public site, clients may get internal (non-routable) IPs when trying to browse the public versions. This issue can affect main domains as well as subdomains and tracking/click URLs found in email links and ad links.
• DNS Forwarders: If your server’s forwarders or root hints are not configured to resolve Internet names reliably, clients may randomly lose public DNS lookups, causing timeouts and NXDOMAIN errors.
• Malformed/misconfigured DNS entries can result in “Address Invalid” when a bogus or incomplete DNS record is fed to browsers.

2. Network Security/Filtering​

• Your Unified Threat Management (UTM), EDR (Threatdown), or firewall may be aggressively filtering outbound HTTP/S, especially dynamic ad/tracking links. However, since you fully disabled these as a test, this is less likely unless there’s a network-level block unrelated to Threatdown.

3. DHCP and IP Assignment Glitches​

• If your DHCP settings are inconsistent, especially with reserved IPs or DNS fields (especially on devices that move on and off the network, or users with static config overrides), clients could have conflicting or bad DNS results. Unresolved or intermittent DNS can cause timeouts and NXDOMAIN.

4. Certificate or SSL/HTTPS Filtering Issues​

• If you have “HTTPS inspection” or SSL filtering features enabled on your Ubiquiti or security appliance, and the root/intermediate CA is missing from clients, you may see sporadic failures on secure links—especially “sponsored” ad links or email tracking links with unusual URLs.

---

Actionable Troubleshooting Steps​

A. Verify Internal DNS Zone Configurations​

1. Check if you have internal zones for domains that overlap with public sites (e.g., your company.com, google.com, etc).
2. Open DNS Manager on your DC:
   • Expand Forward Lookup Zones.
   • Is there a zone for a domain that matches a public site? If so, delete it if not needed, or make sure it has appropriate forwarding records (e.g., www as an A record with the PUBLIC IP).
3. Try resolving DNS from a client:
   • nslookup [www.google.com](http://www.google.com)
   • nslookup <problem-link-domain>
   • Confirm that the output matches what you see from an external network (test on a phone, off WiFi for comparison).

B. Review DNS Forwarder/Root Hint Settings​

1. In DNS Manager, check that you have reliable public DNS in the forwarders list (1.1.1.1 or 8.8.8.8 are fine).
2. Try clearing and re-adding these settings.
3. Ipconfig /flushdns and restart DNS on the server and workstations.

C. Test Direct IP Access and Check for Network Blockage​

• Can you access public sites by IP (e.g., [url]http://172.217.8.238[/url] for Google)?
• If yes, DNS is at fault. If not, consider routing/firewall issues.
• Also, try traceroute (tracert <problem-domain>) to see where connections are failing.

D. Check for HVAC or wildcard DNS entries​

• If you have wildcard A records, these can cause external emails and links to resolve to your server.

E. Try an Outside DNS​

• Temporarily set a laptop's DNS to 8.8.8.8 and 1.1.1.1 only (do not use internal DNS at all) and REMOVE the system from the domain. If the sites work, the DNS design needs to change.

F. Check Security Devices for HTTPS Inspection or Decryption​

• Look in your Ubiquiti or other security appliances for "SSL/HTTPS Inspection" features. If enabled, try disabling them.

G. Review DHCP Scope & Leases​

• Confirm all devices are receiving correct, non-conflicting, up-to-date IP, gateway, and DNS info.

---

Reference Solutions from the Community​

• Bad DNS internal zone: "when trying to access our website from DC computers, it wouldn't load due to the conflicting DNS records (pointed to the server rather than the correct web address)." Solution: Rename domain or fix zone records.
• DNS troubleshooting: Use nslookup/ping/traceroute when issue occurs; try alternate DNS to confirm whether your own DNS is the source.
• Wildcard or incomplete DNS records can result in “ERR_ADDRESS_INVALID”—especially on oddball tracking/ad URLs that often get embedded in emails or ads.

---

Summary Diagnosis​

Root Cause is likely DNS misconfiguration resulting from internal DNS zones overlapping public domains, improper forwarders, or corrupted DNS caches.

---

Final Checklist​

• Delete/rename conflicting internal DNS zones.
• Use proper DNS forwarders.
• Test with a device on external-only DNS.
• Check specific email/ad link failures with nslookup, ping, and traceroute.
• Review UTM/Firewall/SSL inspection settings.

If you have internal DNS overlaps (especially for your public company domain), fix those and you should see these issues resolved. If not, please provide the actual nslookup/traceroute results and whether a completely external DNS fixes the browsing issues.
Let me know if you want more granular step-by-step walkthroughs for any of these, or if you're able to share nslookup/traceroute output for failing domains!