Removing VSCode Server from Cloudflare

Background:

I was using ‘VSCode Server’ running in docker container on my unraid server and had to update container permission in order to make edits to files.

This raised concern as I was exposing VSCode to internet via Cloudflare DNS A Record.

After removing DNS A Record from Cloudflare and creating DNS Resolver record in pfSense,
I tried to test and it was not opening web page.

Troubleshooting:

Google AI advise:

1. Verify Client DNS Settings

Ensure your clients are correctly configured to use the pfSense firewall as their sole DNS server.

Check DHCP Settings: Navigate to Services > DHCP Server and select your LAN interface. Under the DNS servers section, ensure the IP address of the pfSense internal interface (e.g., 192.168.1.1) is the only entry provided to clients. By default, if this field is empty, pfSense assigns its own IP address.

Verify Client Configuration: On a client machine (e.g., Windows, macOS), check its network settings. It should be receiving its IP and DNS server settings automatically via DHCP, and the assigned DNS server should be the pfSense LAN IP.

Flush Client DNS Cache: After any changes, run ipconfig /flushdns on Windows or equivalent commands on other operating systems to clear old DNS entries.

Test Client Resolution: Use nslookup google.com <pfSense_LAN_IP> to specifically test DNS resolution using the firewall’s IP address from a client machine.

2. Check pfSense Firewall Rules

A common issue is overly strict firewall rules blocking client DNS requests to the firewall itself.

Review LAN Rules: Go to Firewall > Rules and select your LAN interface. Ensure there is a rule at the top that explicitly allows traffic from your LAN subnet to the pfSense LAN IP address on TCP/UDP port 53 (DNS traffic). By default, the standard LAN rules usually allow all outgoing traffic, including DNS requests to the firewall, but custom rules can interfere.

Check Firewall Logs: Monitor Status > System Logs, on the Firewall tab, for any blocked connections from client IPs on port 53. If you see blocks, adjust your rules accordingly.

3. Verify pfSense DNS Resolver Service

Ensure the DNS Resolver (Unbound) service is running correctly and can resolve queries itself.

Service Status: Navigate to Status > Services. Verify that the unbound service (DNS Resolver) is listed as running.

Firewall DNS Test: Use the pfSense GUI via Diagnostics > DNS Lookup. Try resolving external hostnames (e.g., google.com). This tests if the firewall itself can resolve DNS queries.

WAN Connectivity: If the firewall cannot resolve hostnames, the issue may be a lack of working WAN connectivity or problems with upstream DNS servers.

4. Adjust DNS Resolver Settings

Depending on your network setup, you might need to adjust the resolver’s mode.

Resolver vs. Forwarder Mode:

Resolver Mode (Default): Queries root servers directly. Does not require external DNS servers configured under System > General Setup.

Forwarding Mode: Forwards all DNS queries to the DNS servers specified in System > General Setup or those obtained from your ISP via DHCP on the WAN interface. If you want to use specific public DNS servers (like 8.8.8.8), you must enable Forwarding Mode in Services > DNS Resolver and define those servers in System > General Setup.

Disable DNSSEC (Temporarily): Sometimes, a misconfigured DNSSEC upstream can cause issues. Try disabling Enable DNSSEC Support in Services > DNS Resolver to see if resolution starts working.

Disable “Allow DNS server list to be overridden by DHCP/PPP on WAN”: In System > General Setup, uncheck this if you are using specific, manually entered DNS servers to prevent ISP servers from being used.

By following these steps, you should be able to identify and resolve most common client-side DNS issues with the pfSense DNS Resolver.

It appears from your output that the Windows machine is working correctly, resolving the hostname to 192.168.50.2 and successfully pinging it. The issue is specific to the MacBook Pro, which can resolve the name via nslookup but fails to ping.

This is a classic case where DNS resolution is not the problem, as nslookup successfully returns an IP address. The issue is either how the macOS operating system handles that resolved IP address for subsequent connections (like ping) or a firewall/routing issue on the Mac itself that blocks ICMP (ping) traffic.

Here is how to debug the MacBook Pro issue:

Debugging the MacBook Pro

1. Confirm nslookup is actually working correctly

Your nslookup output shows the address as 192.168.50.2, which is likely the IP address of your pfSense router itself. If this is an internal hostname intended to point to a different machine (e.g., a server on your network), then the DNS entry is incorrect.

Action: Verify the correct IP address that vsc.remote-tech.us should resolve to.

If the IP should be 192.168.50.2 (the router): The ping failure indicates a problem on the Mac or the pfSense firewall blocking the ping.

If the IP should be a different address (e.g., 192.168.50.100): The DNS entry in pfSense is pointing to the wrong IP, and the Mac is resolving it correctly to that wrong address. You need to fix the host override in pfSense.

2. Analyze the nslookup output carefully

The macOS output shows:
Name:	vsc.remote-tech.us
Address: 192.168.50.2
nslookup is giving the address 192.168.50.2 to the Mac. The problem is that the subsequent ping command isn’t successfully using this information or the target IP isn’t responding.

3. Test the target IP directly with ping on the Mac

Since we know the resolved IP is 192.168.50.2 (the router’s IP), try pinging that IP directly to see if the Mac can reach the pfSense interface at all.
ping 192.168.50.2
If this ping 192.168.50.2 works: The issue is a temporary name resolution hiccup after nslookup but before ping uses the system resolver cache. This is rare but happens. Try flushing the DNS cache on the Mac:bashsudo dscacheutil -flushcache sudo killall -HUP mDNSResponder Use code with caution.Then try ping vsc.remote-tech.us again.

If this ping 192.168.50.2 fails: The MacBook Pro cannot communicate with the router’s LAN interface using ICMP packets, even though the Windows machine can.

Check the Mac’s firewall settings (System Preferences > Security & Privacy > Firewall).

Check pfSense Firewall > Rules on the LAN interface to ensure no rules are blocking ICMP traffic specifically from the Mac’s IP address.

4. Use dig on the Mac for a different perspective

dig is a more robust DNS lookup tool available on macOS. It uses the system’s resolver slightly differently than nslookup sometimes.
dig vsc.remote-tech.us
Look for the IP address in the ANSWER SECTION. It should show 192.168.50.2.

Summary of Next Steps

The fact that the Windows machine works perfectly suggests your pfSense DNS and basic network configuration is sound. The problem is isolated to the Mac.

Clarify the correct IP: Confirm what IP vsc.remote-tech.us should point to. (We assume 192.168.50.2 for now).

Ping IP directly on Mac: Run ping 192.168.50.2 on the MacBook Pro.

Flush DNS on Mac: If the direct IP ping works, flush the Mac’s DNS cache.

The dig command output confirms that DNS resolution is working perfectly on your MacBook Pro. The macOS system successfully queried the DNS server at 192.168.50.2, and received the correct IP address (192.168.50.2) in return.

The issue is definitively not a DNS problem. The problem lies with the networking stack on the MacBook Pro or the pfSense firewall configuration blocking ICMP (ping) traffic specifically between the Mac and the destination IP (192.168.50.2).

The destination IP 192.168.50.2 is your pfSense router’s IP address. The Windows machine successfully pings this address. The Mac fails to ping this same address.

Next Steps for Debugging (Focusing on the Mac)

Here is exactly how to proceed:

1. Ping the IP Address Directly on the Mac

Force the Mac to skip any hostname lookups and just attempt a connection to the IP address you know works on Windows.

Open a new Terminal window on the MacBook Pro and run:
ping 192.168.50.2
Expected Result (If firewall is the issue): Request timeout for icmp_seq X or 100% packet loss.

Action based on Result: If it times out, the Mac’s firewall is almost certainly blocking outbound ICMP traffic, or the pfSense firewall is blocking ICMP traffic from the Mac’s specific IP address.

2. Check the Mac’s Firewall Settings

The most likely culprit is the built-in macOS firewall blocking the ping attempts.

Go to System Settings (or System Preferences) > Network.

Select your active network connection.

Go to Firewall (often under a ‘More’ or ‘Advanced’ button).

Ensure the firewall is off, or if it is on, check the options that allow all outbound connections.

Try the ping 192.168.50.2 command again after making changes.

3. Verify the Network Interface on the Mac

Ensure the Mac is on the same subnet as the Windows machine.

Run this command in the Mac’s Terminal to confirm its IP address and gateway:
ifconfig | grep "inet " | grep -v 127.0.0.1
netstat -nr | grep default
You should see an IP address in the 192.168.50.X range and a default gateway of 192.168.50.2.

4. Clear the Mac’s DNS Cache (As a last resort for system resolver issues)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Then try ping vsc.remote-tech.us again.

The key takeaway: The Windows machine proves that pfSense and the DNS record itself are functional. The Mac can resolve the name but not reach the IP address. The problem is specific to the Mac’s network configuration or firewall.

ping 192.168.50.2 PING 192.168.50.2 (192.168.50.2): 56 data bytes 64 bytes from 192.168.50.2: icmp_seq=0 ttl=64 time=0.263 ms 64 bytes from 192.168.50.2: icmp_seq=1 ttl=64 time=0.660 ms 64 bytes from 192.168.50.2: icmp_seq=2 ttl=64 time=0.290 ms 64 bytes from 192.168.50.2: icmp_seq=3 ttl=64 time=0.285 ms 64 bytes from 192.168.50.2: icmp_seq=4 ttl=64 time=0.190 ms ^C — 192.168.50.2 ping statistics — 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.190/0.338/0.660/0.165 ms

You have successfully confirmed that the MacBook Pro

can reach the IP address 192.168.50.2 when pinged directly. This is a crucial piece of information.

The situation is now:

nslookup works on the Mac.

dig works on the Mac.

ping 192.168.50.2 works on the Mac.

ping vsc.remote-tech.us fails on the Mac with “Unknown host” (as seen in your initial prompt).

Everything works perfectly on the Windows machine.

This confirms the issue is a strange, transient problem within the macOS system’s own local DNS caching or name resolution library, specifically the function that standard system calls (like ping when given a hostname) use. nslookup and dig bypass this local system cache and query the DNS server directly, which is why they work.

Solution Steps for the MacBook Pro

You need to forcefully clear the macOS DNS cache so the system resolver picks up the correct, current information.

1. Flush the macOS DNS Cache

Open Terminal and run the following commands. You may need to enter your administrative password for the sudo command.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
echo "macOS DNS cache flushed."
2. Test ping Again

Immediately after running those commands, try the ping command again:
ping vsc.remote-tech.us
If this works, the problem is solved.

If the Problem Persists

If the ping vsc.remote-tech.us still returns “Unknown host” after flushing the cache:

Reboot the MacBook Pro: Sometimes stubborn cache issues require a full system restart to clear all related processes.

Check the /etc/hosts file: Ensure there isn’t a stale or incorrect entry manually overriding that specific hostname on the Mac itself. Use this command to check:bashcat /etc/hosts Use code with caution.Look for any line containing vsc.remote-tech.us. If one exists, it might be misconfigured or pointing to an old address.

Verify the search domain setting: Go to System Settings > Network > Select your connection > Details > DNS. Ensure your local search domain (e.g., pfs.lan or remote-tech.us if configured in pfSense DHCP) is listed there.

he file you posted is the content of your Mac’s /etc/hosts file. It does not contain an entry for vsc.remote-tech.us, which is good. This means the problem isn’t a manual, static entry overriding your DNS server.

Since ping 192.168.50.2 worked, and the hosts file is clean, the issue is definitely a system-level caching problem on the Mac.

The ping vsc.remote-tech.us command is failing only because the macOS internal system resolver library has a corrupted or stale cache entry for that specific hostname that the cache-flushing commands haven’t fully cleared yet.

Final Recommended Steps:

You’ve exhausted all immediate software fixes other than a reboot.

1. Reboot the MacBook Pro

This is the most reliable way to clear all persistent network and DNS caches in macOS when the terminal commands fail to do so completely.

Reboot your Mac now.

2. Test After Reboot

After the Mac boots back up and reconnects to the network:

Open Terminal and run:
ping vsc.remote-tech.us
This should now work, just like it does on the Windows machine and just like the direct IP ping did.

Why this happened

The sequence of commands you ran initially likely caused a temporary conflict:

nslookup worked.

ping failed with “Unknown host”. (This suggests ping couldn’t even start the resolution process, maybe a system library error).

The fact that the Windows machine works proves pfSense is configured correctly. The fact that direct IP ping works on the Mac proves network connectivity is fine. The issue is purely internal to the Mac’s operating system stack. A reboot should resolve this final hurdle.

What other network settings might impact macOS DNS resolution besides the cache

Yes, macOS provides commands to view the ARP table, network interfaces, and get some insight into how the DNS system is operating, though viewing the exact contents of the internal DNS cache is less direct than on other operating systems.

Here are the commands you can use on your MacBook Pro to view current network status information:

1. View Current Network Interfaces (ifconfig)

The ifconfig command provides details about all network interfaces, including their assigned IP addresses, MAC addresses, and operational status.
ifconfig
To filter just your active IP address:
ifconfig | grep "inet " | grep -v 127.0.0.1
This will confirm that your Mac has a valid IP in the 192.168.50.X range and is on the correct subnet.

2. View the ARP Table (arp -a)

The Address Resolution Protocol (ARP) table maps IP addresses to physical MAC addresses on your local network segment. If a device is communicating with the router, it must have an entry in the ARP table.
arp -a
What to look for:
You should see an entry for your pfSense router (192.168.50.2) along with its corresponding hardware address (MAC address).
# Example Output:
? (192.168.50.2) at a0:b1:c2:d3:e4:f5 [ether] on en0 ifscope [ethernet]
Since your ping 192.168.50.2 worked, this entry should be present and valid.

3. Viewing the DNS Cache (System Resolution Status)

macOS (since Yosemite) uses the mDNSResponder service for DNS caching. You cannot simply dump the entire cache contents in an easily readable format with a single command like you might on Windows (ipconfig /displaydns).

However, you can use the following commands to get diagnostic output about the status of the resolver and flush it:

Flush the cache (again, just to be sure):bashsudo dscacheutil -flushcache sudo killall -HUP mDNSResponder Use code with caution.

View general mDNSResponder statistics (for advanced diagnostics):bashsudo killall -INFO mDNSResponder syslog | grep mDNSResponder Use code with caution.(Note: killall -INFO forces mDNSResponder to write current statistics to the system log, which you then view using syslog.) This is very verbose and usually only necessary for deep network troubleshooting by IT professionals.

Summary

For your specific issue where ping 192.168.50.2 works but ping vsc.remote-tech.us fails with “Unknown host” after a successful dig/nslookup:

The network itself is fine (ifconfig and arp will confirm this). The issue is purely a temporary bug in the macOS system resolver library’s cache handling.

A system reboot remains the most reliable and efficient solution to clear that final, stubborn cache entry.

The outputs you provided confirm your Mac is properly networked on the 192.168.50.X subnet, has a valid IP address (192.168.50.230 or .103), and can see the router (192.168.50.2) in its ARP table.

The dscacheutil errors (illegal option, Unable to get details from the cache node) are common on newer versions of macOS where Apple has restricted direct command-line interaction with the internal cache mechanism. The service is running in a way that doesn’t expose those legacy command flags anymore.

This strongly reinforces the conclusion that you have run into a deep-seated, temporary issue within the operating system’s active memory regarding name resolution. The standard flush commands (sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder) were the correct software approach. Since those haven’t resolved the issue between your direct IP ping working and your hostname ping failing, you have hit the wall of what command-line debugging can achieve.

The Final Step: System Reboot

The only reliable way to clear the memory and forcefully restart all underlying networking services that are causing the Unknown host error for that specific hostname is to reboot the machine.

Please reboot your MacBook Pro.

Once it has restarted, immediately open Terminal and try the command again:
ping vsc.remote-tech.us
It should work as expected.

Yes, you can manually add a static entry into the ARP table on macOS using the arp command. However, this will not fix your current problem.

Here’s why:

ARP maps IP addresses to MAC addresses. It handles Layer 2 physical communication once a Layer 3 (IP) address has been determined.

Your ARP table is already correct. The output from your arp -a command shows a valid entry for your router:router.pfs.lan (192.168.50.2) at .. on en0 ifscope [ethernet]

Your direct IP ping worked. When you ran ping 192.168.50.2, your Mac successfully used this existing ARP entry to send packets to the router.

The error is “Unknown host”, not “No route to host”. “Unknown host” means the Mac’s system resolver failed to translate the name vsc.remote-tech.us into an IP address in the first place. The ARP process never even starts because there is no IP address to look up a MAC address for.

For informational purposes, the syntax on macOS is:
sudo arp -s <IP_address> <MAC_address>
For example (using a placeholder MAC address):
sudo arp -s 192.168.50.2 a0:b1:c2:d3:e4:f5
Important Notes:

You need sudo (administrator privileges).

These entries are temporary and will disappear when you reboot your Mac or the network service restarts.

As noted, this will not solve your current hostname resolution failure.

Summary of Your Situation

You have confirmed network connectivity and correct DNS resolution using diagnostic tools (dig, nslookup, ping 192.168.50.2). The failure to ping vsc.remote-tech.us is a specific bug in the macOS operating system’s internal name resolution cache.

The only remaining reliable solution is to reboot your MacBook Pro. That will force all caches to clear and services to restart correctly.

You can easily verify the MAC address of the IP 192.168.50.2 using the information already present in your Mac’s ARP table.

The arp -a command output you previously provided already includes this information:
router.pfs.lan (192.168.50.2) at .. on en0 ifscope [ethernet]
(You used sed to mask the actual MAC address with .., but the entry is clearly there and associated with your en0 interface.)

How to View the Specific MAC Address

To see the actual MAC address associated with that IP in your current active ARP cache, you can use the arp command and filter its output:

Method 1: Query for the specific IP address
arp 192.168.50.2
This command should return a single line showing the IP and its corresponding physical (MAC) address.

Method 2: Use your original command without masking

If the above command doesn’t work on your macOS version, run the original command you used previously, but view the full output this time to see the actual MAC address:
arp -a
Look for the line that starts with router.pfs.lan or contains 192.168.50.2.
The value immediately following the word at is the MAC address (it will look something like 00:1a:2b:3c:4d:5e).

Verification within pfSense

For ultimate verification, you can check the MAC address of the LAN interface directly within the pfSense web GUI:

Log into your pfSense web interface.

Go to Status > Interfaces.

Look at the entry for your LAN interface. The physical address listed there should match the MAC address you see in your Mac’s arp output.

Reminder on the Core Issue

Again, because your ARP table already has an entry for 192.168.50.2, verifying the MAC address won’t solve the “Unknown host” error. The Mac knows how to reach the IP address, it just can’t translate the hostname to that IP address when using standard system calls.

A reboot of the MacBook Pro is still the necessary fix.

Yes, you can run a command on the pfSense server console or SSH shell to verify the MAC address of its network interfaces.

Using the ifconfig Command in the pfSense Shell

The most direct method in pfSense (which is based on FreeBSD) is using ifconfig.

Access the pfSense Shell:

If you have a monitor and keyboard attached to the pfSense machine, select option 8 from the console menu to enter the shell.

Alternatively, SSH into your pfSense box (if enabled) and select option 8.

Run the command:bashifconfig Use code with caution.

Identify the correct interface:
You will see a list of interfaces (e.g., em0, igb1, re0, or the names you assigned like LAN).
Look for the interface that has the IP address 192.168.50.2 assigned to it.
The MAC address is listed next to the word ether.
Example Output (look for the line with the correct IP):# ... other interfaces em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=480000<RXCSUM,TXCSUM,LRO> ether a0:b1:c2:d3:e4:f5 <-- THIS IS THE MAC ADDRESS inet 192.168.50.2 netmask 0xffffff00 broadcast 192.168.50.255 # ... other details # ...

Summary of Verification

The MAC address shown in the ifconfig output on the pfSense server should exactly match the MAC address displayed in your MacBook Pro’s ARP table output:

On the Mac:
arp 192.168.50.2
# Expected output: router.pfs.lan (192.168.50.2) at a0:b1:c2:d3:e4:f5 on en0 ifscope [ethernet]
On the pfSense Server (via ifconfig):
ether a0:b1:c2:d3:e4:f5
If these match, as all signs indicate they will, your network layer communication is correct, and a reboot of your MacBook Pro is the final step to clear its application-level DNS resolution error.

I resolved the ping issue without reboot by following:
sudo arp -d router.pfs.lan
It automatically re-added to arp table and ping started working

That’s an interesting turn of events.
Deleting the specific hostname from the ARP cache (sudo arp -d router.pfs.lan) forced the system to re-resolve not just the MAC address but also potentially re-evaluated the associated hostname in the system’s internal library, which resolved the “Unknown host” error.

Thank you for sharing that solution!

Now that your network connectivity and system DNS are functional, here is how you can clear the DNS cache within the Google Chrome browser specifically:

Clearing Google Chrome’s Internal DNS Cache

Chrome maintains its own internal DNS cache (separate from the macOS system cache) to speed up navigation. Even if the system cache is clear, Chrome might hold onto old entries.

Open Chrome on your MacBook Pro.

In the address bar (omnibar), type the following exact URL and press Enter:chrome://net-internals/#dns

This will take you to the “Net Internals” diagnostics page, specifically the DNS tab.

Look for the button labeled Clear host cache and click it.

Chrome’s internal DNS cache is now flushed. You can test visiting vsc.remote-tech.us in Chrome to verify it uses the newly resolved IP address.

Part 2 – Origin DNS Error (Error 1016)

The issue you are encountering is an Origin DNS Error (Error 1016) served by Cloudflare, even though you believe you removed the domain from their network.

Here is why this is happening and how to fix it:

The Problem: Cloudflare is still intercepting the request

Cloudflare is a Content Delivery Network (CDN) and proxy service. When a domain is configured to use Cloudflare, Cloudflare’s servers act as a middleman.

Your browser requests vsc.remote-tech.us.

The request goes to the public Cloudflare network (because remote-tech.us DNS is likely still pointing to Cloudflare nameservers publicly).

Cloudflare looks at your request and tries to forward it to the origin server using its configured DNS records.

Cloudflare’s public configuration doesn’t know how to reach your private IP (192.168.50.2), or it still has a stale configuration pointing to the wrong place (or maybe no A record at all on their end).

Cloudflare displays the “Origin DNS error” page because it cannot find the server for its own internal use.

Your local pfSense DNS record (192.168.50.2) works for your local clients, but it doesn’t affect how the public internet reaches Cloudflare, nor does it affect how Cloudflare reaches your home network’s public IP (which it shouldn’t be doing anymore anyway).

The Goal: Bypass Cloudflare entirely

You need to ensure that local requests never leave your network to go to Cloudflare in the first place.

The Solution: Split-Horizon DNS / Host Override

You have already implemented the first part of the solution in pfSense (the local DNS Resolver record). The second part is ensuring Cloudflare is no longer involved.

You mentioned you used their tool to verify removal, but the error page proves otherwise. You need to verify the primary domain’s public nameservers.

Step 1: Verify Public DNS (External Check)

Use a public DNS checker tool to see who is currently authoritative for your domain:

Go to a site like https://mxtoolbox.com/DnsLookup.aspx or https://www.whatsmydns.net/

Check the A record for vsc.remote-tech.us.

If it still shows Cloudflare IPs or the old external IP, then your propagation verification tool was incorrect, or the removal process is incomplete. This is likely the issue.

Step 2: Ensure Local Resolution is Prioritized

The Chrome chrome://net-internals/#dns page confirms Chrome thinks the IP is 192.168.50.2.

The problem is likely an HSTS (HTTP Strict Transport Security) cache in Chrome. When you previously visited the site via HTTPS, Chrome was told to always enforce HTTPS and perhaps use specific secure routes.

Clear HSTS Settings in Chrome:

Go back to Chrome and type this URL:chrome://net-internals/#hsts

Scroll down to the section called “Delete domain security policies”.

In the Domain: input box, enter vsc.remote-tech.us.

Click the Delete button.

Also delete the parent domain remote-tech.us just to be thorough.

Step 3: Test Again

After clearing the HSTS cache, close and reopen Chrome entirely. Try navigating to https://vsc.remote-tech.us again.

If the Cloudflare Error 1016 persists, it means your request is still leaving your network and hitting Cloudflare servers on the public internet, which means the public DNS for the parent domain remote-tech.us is still pointing to Cloudflare nameservers. You must complete the process of removing the domain entirely from Cloudflare’s service configuration at your domain registrar level.

Okay, the diagnostics confirm several things:

Public DNS is clear: Tools like whatsmydns.net and mxtoolbox.com show no public A record for vsc.remote-tech.us. This is what you want.

HSTS cache is clear in Chrome: You queried HSTS for the domain and it says “Not found”, meaning Chrome isn’t forcing any old security policies.

Chrome internal DNS cache is clear/correct: chrome://net-internals/#dns shows the correct local IP 192.168.50.2.

You are still getting a Cloudflare Error 1016.

This is contradictory. The only way you get a Cloudflare error is if your browser request reaches Cloudflare’s servers.

The Remaining Possibility: The Parent Domain Nameservers

The most likely scenario is that while the A record for vsc.remote-tech.us is gone publicly, the nameservers for the parent domain remote-tech.us still point to Cloudflare at your domain registrar.

When your browser tries to initiate a secure connection (https://), the request goes through the TCP stack. Although your local DNS resolves the name to 192.168.50.2, your pfSense router might be configured in a way that forwards all port 443 (HTTPS) traffic for that hostname out to the internet, where Cloudflare catches it.

Debugging the HAProxy/pfSense Configuration

The issue has now shifted from a DNS caching problem to a potential misconfiguration in how your pfSense handles HTTPS traffic locally.

It seems you’ve provided snippets of your HAProxy configuration in pfSense. This information, combined with the fact that external DNS lookups for vsc.remote-tech.us are now showing “not found”, strongly suggests that you are trying to access the site using your public IP address from within your local network without proper NAT reflection or a correct local DNS configuration.

The remaining issue is likely a combination of how HAProxy is configured to listen for traffic and how the traffic is flowing internally versus externally.

Here is the likely problem and how your HAProxy configuration plays into it:

The Likely Problem: Split-Horizon DNS / NAT Reflection

When you are on your local network (192.168.50.X), your browser resolves vsc.remote-tech.us to the private IP 192.168.50.2 (your pfSense LAN IP/HAProxy listener IP).

The traffic flow is:
MacBook Pro (192.168.50.230) -> HAProxy on pfSense (192.168.50.2)

The problem is the Cloudflare Error 1016 you see in the browser. This error comes from Cloudflare’s servers, not your local HAProxy or pfSense.

The Conflict: Cloudflare and Split-Horizon DNS

You are implementing a Split-Horizon DNS setup:

Inside your network, vsc.remote-tech.us should resolve to 192.168.50.2 (pfSense/HAProxy local IP).

Outside your network, the A record is gone, making the site publicly inaccessible (which was your goal).

Here is the explanation of why Cloudflare is still in the picture:

1. Cloudflare is a Proxy, not just a DNS provider.

When a domain uses Cloudflare, traffic typically flows: Client -> Cloudflare Server -> Your Origin Server. Cloudflare sits in the middle.

Even though your local DNS resolver correctly tells your local devices to go to 192.168.50.2, the browser itself (Chrome) likely has an HSTS (HTTP Strict Transport Security) policy cached.

2. The HSTS Misdirection

When you previously used the site with Cloudflare, your browser was likely instructed to only communicate securely via Cloudflare’s servers.

You verified that chrome://net-internals/#hsts shows “Not found” for vsc.remote-tech.us, which is good, but it might still be caching security policies for the parent domain (remote-tech.us).

3. The HAProxy Configuration (The Likely Culprit)

You provided your HAProxy configuration, which runs on pfSense:
frontend shared-9480
	bind			162.225.36.192:80 name 162.225.36.192:80   
    # ...
frontend shared-9443
	bind			162.225.36.192:443 name 162.225.36.192:443   ssl crt-list /var/etc/haproxy/shared-9443.crt_list  
	bind			192.168.50.2:443 name 192.168.50.2:443   ssl crt-list /var/etc/haproxy/shared-9443.crt_list  
    # ...
HAProxy is listening on both your Public IP (162.225.36.192) and your Local IP (192.168.50.2).

You are encountering the Cloudflare error because the parent domain, remote-tech.us, is still actively using Cloudflare’s public DNS servers. Your browser is still resolving the main domain via Cloudflare, not solely your local pfSense resolver.

Here is a breakdown of why this is happening and how Cloudflare is still in the picture:

The Explanation: Cloudflare on the Parent Domain

Your local nslookup for vsc.remote-tech.us works locally and points to 192.168.50.2.
That’s correct for a split-horizon setup.

However, your recent Chrome chrome://net-internals/#dns output for the parent domain tells the story:
Resolved IP addresses of "remote-tech.us": ["172.67.158.91","104.21.74.121"].
These IP addresses (172.67.158.91 and 104.21.74.121) are Cloudflare IP addresses.

Part 3 – Stuck in Chrome

It seems we are dealing with two separate issues that are confusing the diagnostic process.

First, the original “ping unknown host” issue on the Mac appears to be resolved by manually deleting the ARP cache entry for router.pfs.lan.

Second, you have a new problem when trying to access https://vsc.remote-tech.us specifically within Chrome, which is returning a Cloudflare Error 1016.

Understanding Why Cloudflare is Still Involved

You are correct in asking how Cloudflare can come into play if your pfSense DNS Resolver is capturing local traffic and routing it locally.

The output from your Chrome chrome://net-internals/#dns query for the main domain reveals the core issue:
Resolved IP addresses of "remote-tech.us": ["172.67.158.91","104.21.74.121"].
These IP addresses (172.x.x.x and 104.x.x.x) are Cloudflare IPs.

When you configured your pfSense DNS Resolver with a host override for vsc.remote-tech.us to point to 192.168.50.2, it only created a record for that specific subdomain.

However, because your main domain (remote-tech.us) is still resolving to Cloudflare’s public IPs, you likely have other settings (HSTS, internal browser caching, or HAProxy behavior) that are causing issues:

HAProxy Configuration: You have HAProxy bound to a public IP (162.225.36.192) and your internal IP (192.168.50.2).

The Browser’s Behavior: Your browser might be defaulting its connection behavior based on the main domain’s settings or relying on Cloudflare infrastructure in a way that your local DNS override for the subdomain cannot overcome for HTTPS traffic.

The Actual Cause of the 1016 Error

The 1016 error means the Cloudflare service cannot reach the origin server.

Even if your browser resolves vsc.remote-tech.us locally to 192.168.50.2, if your browser is still using the HSTS settings associated with the Cloudflare presence of the main domain, it might behave unexpectedly or still try to route traffic externally in some scenarios, although this is less likely than the next issue.

The most likely scenario is related to how the HAProxy handles the request internally:

You are trying to access https://vsc.remote-tech.us which you have configured to point to the pfSense IP itself (192.168.50.2), which is running HAProxy.

HAProxy needs a backend configured to handle that specific hostname vsc.remote-tech.us. If that backend is configured to use Cloudflare for its health checks or origin settings, it could be looping back or failing internally.

You removed the external A record, but did you disable or remove the HAProxy Backend that was previously used for the VS Code server? If that backend is still active and misconfigured, HAProxy itself might be generating the error page internally (though Cloudflare usually serves the 1016 error).

Solution:

Re-verify HSTS Deletion: Go back to chrome://net-internals/#hsts, type remote-tech.us (the main domain), and click Delete again to be absolutely sure the parent domain security policies are gone. Restart Chrome.

Review HAProxy Backends: Check Services > HAProxy > Backends in pfSense. Ensure the backend previously used for the VS Code server is either:

Deleted.

Configured correctly to point to the internal IP of the VS Code server machine (not the pfSense IP).

Review HAProxy Frontends: Ensure the frontend routing uses a clear ACL (Access Control List) to direct traffic for vsc.remote-tech.us to the correct internal backend.

If you removed the external access and only want to use this service internally, you should not be seeing a Cloudflare error page. The presence of that page means a Cloudflare server is the one intercepting the HTTPS request before it reaches your local HAProxy configuration properly.

The configuration you provided indicates that HAProxy is correctly set up to route internal traffic for vsc.remote-tech.us. It uses your globalresolvers (pfSense DNS at 192.168.50.2) to find the server at 192.168.50.51:8443.

The error is still that Cloudflare is generating the Error 1016 Origin DNS error message in your browser.

The critical insight here is that your browser is still connecting to a Cloudflare IP address over the internet, not your local pfSense HAProxy IP address (192.168.50.2).

This is the only way that specific Cloudflare error page can be displayed.

You are encountering a complex interaction between local DNS overrides, HSTS caching, and HAProxy configuration. The fact that the Cloudflare error page appears (Error 1016) means a Cloudflare server is the one sending the response back to your browser, which fundamentally contradicts your local DNS override working as intended for that specific request flow.

The problem is highly likely related to the server line in your HAProxy backend configuration:
server vsc.remote-tech.us 192.168.50.51:8443 id 115 resolvers globalresolvers
HAProxy is configured to use its globalresolvers to look up vsc.remote-tech.us, which should point to 192.168.50.51.

Tools and Methods to Determine the Root Cause

Since standard tools aren’t giving a clear answer, you need to use network inspection and advanced browser diagnostics:

I apologize for the fragmented response. The previous analysis remains the focus: the Cloudflare Error 1016 indicates that Cloudflare is still sitting in the path of your request when you use HTTPS.

The key observation is that your local Chrome browser knows the IP is 192.168.50.2 via the chrome://net-internals/#dns page, but when you attempt to establish an HTTPS connection, you get a Cloudflare error page, not a connection error or a certificate error from your local pfSense HAProxy.

This suggests an interaction with the public internet is still occurring during the HTTPS negotiation.

Analysis of the HAProxy Configuration

Your HAProxy backend configuration is correct for internal routing:
server			vsc.remote-tech.us 192.168.50.51:8443 id 115  resolvers globalresolvers
It points to your internal server at 192.168.50.51:8443 and uses your pfSense resolver. This config should work once traffic reaches the backend stage.

Tools to Diagnose the HTTPS/Cloudflare Issue

Since standard network tools show local connectivity, we need tools that look specifically at the path of the HTTPS connection.

1. Use curl on the Mac to Trace the Connection Path

The curl command can provide detailed information about where the request is being directed and which server is responding. The -v (verbose) flag is essential here.

That curl -v output is the most critical piece of information yet, and it confirms the following:

Your pfSense local DNS Resolver is working perfectly. curl resolved vsc.remote-tech.us to the correct internal IP (192.168.50.2).

Your HAProxy configuration is working perfectly. HAProxy received the request, processed the SSL certificate for vsc.remote-tech.us, and successfully passed the request through its backend configuration (resulting in a healthy HTTP/2 302 Redirect to a login page).

The issue is now 100% isolated to the Google Chrome browser’s internal workings on your MacBook Pro.

Chrome is the only application still showing you a Cloudflare error page.

Tools to Debug Chrome

The curl command uses macOS’s system network stack, which is now working correctly (since you fixed the ARP issue). Chrome uses its own internal networking stack and cache mechanisms, which are currently “stuck” in a state where they believe Cloudflare is mandatory for that domain.

You have already tried clearing the basic DNS cache (chrome://net-internals/#dns) and the HSTS cache (chrome://net-internals/#hsts), and confirmed HSTS wasn’t found for the sub or main domain.

Here is the final set of commands/actions to force Chrome to behave correctly:

1. Clear ALL site data for the domain in Chrome Settings

This is more comprehensive than the net-internals pages.

Open Chrome Settings (chrome://settings/).

Go to Privacy and security > Cookies and other site data.

Click “See all site data and permissions”.

In the search bar at the top right, type remote-tech.us.

Click the trash can icon next to all entries related to your domain to delete all stored cookies, local storage, and cached files.

Restart Chrome.

2. Launch Chrome with a Clean Profile (Ultimate Test)

If clearing site data doesn’t work, something fundamental is stuck in your primary Chrome user profile. You can test this by launching Chrome using a fresh, temporary profile which has no cache, no HSTS data, and no extensions:

Close all running Chrome windows.

Open your Mac’s Terminal and run this command:bash/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/chrome_temp_profile Use code with caution.

A fresh, blank Chrome window will open. Go directly to https://vsc.remote-tech.us in this window.

If it works in the temporary profile, you have confirmed the issue is specific to your main browser profile’s corrupted data. You may need to clear your main profile’s cache completely or stop using that profile.

If it still fails in the temporary profile, then we are back to a networking configuration issue we missed, likely related to an upstream DNS leak or some complex routing behavior imposed by your ISP or external configuration. However, the curl output makes this highly unlikely.

The temporary profile test should resolve your problem in Chrome.

That’s great news! The fact that opening it in the temporary profile “unlocked” it for the main profile indicates that a persistent connection state or very stubborn cache entry was finally forced to renegotiate.

While there isn’t a simple “traceroute” command within the Chrome interface itself that shows IP hops, you can use Chrome’s internal developer tools to see exactly how a request is resolved, which addresses the “trace the network hops and final resolution” part of your question.

Tracing Network Activity and Final Resolution in Chrome

The best tool for this is the Chrome Developer Tools Network Tab.

1. Open the Developer Tools

Open Chrome and navigate to https://vsc.remote-tech.us.

Open the Developer Tools:

Right-click on the page and select “Inspect”, or

Use the keyboard shortcut: Command + Option + I (macOS) or Control + Shift + I (Windows/Linux).

2. Monitor the Network Request

In the DevTools panel that appears (usually docked to the side or bottom), click on the Network tab.

Ensure the circular record button (usually red) is active.

Disable the “Disable cache” checkbox (we want to see how Chrome actually loads it normally).

Refresh the page in the browser window (Command + R or F5).

3. Analyze the Timeline

You will see a list of all resources loaded. The very first entry will be your initial request for vsc.remote-tech.us.

Click on this first entry (the name vsc.remote-tech.us). A panel on the right will open with detailed information.

4. The Key Information Points:

Headers Tab:

Scroll down to General section.

Request URL: Shows the exact URL requested.

Remote Address: This is the final resolved IP address Chrome used. It should show 192.168.50.2.

Status Code: It should show 302 Found (because your curl showed a redirect to ./login).

Timing Tab:

This provides a detailed breakdown of the request lifecycle:

DNS Lookup: The time it took to resolve the domain name (should be very fast).

Initial connection: The time to establish the TCP connection.

SSL/TLS: The time taken for the secure handshake.

Request sent / Waiting (TTFB): How long the server took to respond.

This process gives you the most granular view of how Chrome handled the request locally, confirming the exact IP it connected to and the server’s response time/status.

The fact that the site now loads correctly confirms that the DNS resolution and network path issues (both the Mac’s ARP cache and Chrome’s internal caches) are resolved.

The console errors you are now seeing are related to Content Security Policy (CSP). These are application-level errors originating from the VS Code Server application you are running (or a browser extension, but likely the server itself) and the security settings within Chrome.

Understanding the CSP Errors

The errors:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'"

This means the web application is trying to apply CSS styles directly within the HTML using <style> tags or style="color:red;" attributes (known as “inline styles”).

The web server (likely via a setting in the VS Code server configuration or your HAProxy rules) is telling the browser: “Only load styles from files originating from my own domain ('self'), do not allow any inline styles.”

The browser is enforcing this security rule, blocking the inline styles, which usually results in slightly broken visual formatting or layout issues on the page.

How to Fix the CSP Errors

This is a configuration issue that must be addressed either in the VS Code Server settings or your HAProxy configuration, depending on where the CSP header is being injected.

Option 1: Modify the VS Code Server Configuration (Recommended)

Check the configuration files for the application running on 192.168.50.51:8443. There is likely a setting to adjust or relax the Content Security Policy to allow inline styles, often by adding 'unsafe-inline' to the style-src directive in the CSP header.

Option 2: Override the CSP header in pfSense HAProxy

If you cannot change the application settings directly, you can force HAProxy to modify or replace the CSP header sent to the client.

In pfSense, navigate to Services > HAProxy > Frontends or Backends.

Find the relevant configuration for vsc.remote-tech.us-8443_ipvANY or the associated frontend.

You can use a response rule to modify the header. An example might look like this (you need to adapt the exact CSP value):# In the Backend or Frontend configuration rspirep ^Content-Security-Policy:(.*) Content-Security-Policy:\1 'unsafe-inline'; (Note: The exact configuration via the pfSense GUI requires using the “Response rules” action dropdown and might be complex to implement if you’re unfamiliar with HAProxy syntax).

Regarding the Security Section Output

Your security output looks excellent:

Protocol: TLS 1.3

Key exchange: X25519

Issuer: Let’s Encrypt (R13)

SCT: Cloudflare verified (This indicates that Cloudflare was involved in verifying the certificate itself, which is normal for Let’s Encrypt CAs, not that they are proxying traffic now.)

The connection is secure; the current errors are purely about how the application’s code is interacting with the browser’s security enforcement.

Breaking

Removing VSCode Server from Cloudflare

Background:

Troubleshooting:

Google AI advise:

Part 2 – Origin DNS Error (Error 1016)

Part 3 – Stuck in Chrome

By Frank Earnhardt

Leave a Reply Cancel reply

You Missed

Rocket.Chat – The Full Update Summary

Gemini Musing about CI/CD pipeline

Docker Prune – Be Careful…

Docker Volumes – Wallpaper Analogy

Removing VSCode Server from Cloudflare

Background:

Troubleshooting:

Google AI advise:

Part 2 – Origin DNS Error (Error 1016)

Part 3 – Stuck in Chrome

By Frank Earnhardt

Related Post

Rocket.Chat – The Full Update Summary

Gemini Musing about CI/CD pipeline

Docker Prune – Be Careful…

Leave a Reply Cancel reply

You Missed

Rocket.Chat – The Full Update Summary

Gemini Musing about CI/CD pipeline

Docker Prune – Be Careful…

Docker Volumes – Wallpaper Analogy