Hey Checkyourlogs Fans,

In the intricate world of IT troubleshooting, encountering peculiar challenges is par for the course. Recently, I had the opportunity to assist a client grappling with a DNS Split Brain issue – a perplexing dilemma that had plagued their organization for years. Allow me to share the journey of unravelling this enigma and discovering a surprisingly straightforward solution that relieved both the client and myself.

Picture this: the client’s internal domain bore the name “company.com,” mirroring their external domain. While this setup might seem innocuous at first glance, it inadvertently gave rise to many complications. The crux of the issue lies in the developers’ endeavour to enhance SEO optimization by configuring a redirector on the corporate website. This redirector, intended to guide users from “www.company.com” to “company.com seamlessly,” inadvertently collided with the internal DNS configuration.

In Active Directory, “company.com” serves as the domain name, facilitating round-robin distribution across all domain controllers. Consequently, any attempts to access “company.com” from within the organization inadvertently led users to internal resources rather than the intended external website. This conundrum persisted for years, underscoring the importance of a swift and effective resolution.

Enter the solution: a stroke of ingenuity in the form of port proxy configuration on the domain controllers. By implementing a port proxy function, we could intercept internal traffic destined for “company.com” and seamlessly redirect it to the external website. While this approach necessitates caution, as it could potentially be exploited for nefarious purposes, in our case, it proved to be the silver bullet we’d been seeking.

This elegant workaround offered a pragmatic solution to the DNS Split Brain issue, alleviating the client’s longstanding frustration and paving the way for seamless navigation between internal and external resources. As with any troubleshooting endeavour, understanding the intricacies of the problem is paramount. Even the most perplexing challenges can be overcome with creativity, perseverance, and a dash of caution.

This was a smaller organization, and the problem had existed for several years. Well, I found a simple way to fix the issue: to configure a port proxy on the domain controllers so that if they saw internal traffic, they would use a port proxy function to redirect to the external website. This should obviously be used with caution as it could be used for nefarious action, but it did the trick in our case.

#Code Grabs all of the domain controllers in the domain and configures the port proxy on them
#Obviously use with caution it does work though tested on 2019 and 2022 domain controllers.

Source code for the fix --> Setting up NAT 443 to external for company.com

# Define the external IP address of the hosting service
$externalIP = "1.1.1.1"

# Get a list of all domain controllers in the domain
$domainControllers = Get-ADDomainController -Filter *

# Define scriptblock for configuring netsh command and firewall rule
$scriptBlock = {
    param($dcIP, $externalIP)

    # Configure netsh command
    $netshCommand = "netsh interface portproxy set v4tov4 listenport=443 listenaddress=$dcIP connectport=443 connectaddress=$externalIP"
    Invoke-Expression $netshCommand

    # Create firewall rule to allow inbound traffic on port 443
    New-NetFirewallRule -DisplayName "Allow HTTPS inbound from $externalIP" -Direction Inbound -LocalPort 443 -Protocol TCP -Action Allow

    # Verify configurations using netsh
    $verificationCommand = "netsh interface portproxy show all"
    Invoke-Expression $verificationCommand
}

# Iterate through each domain controller and execute the scriptblock remotely
foreach ($dc in $domainControllers) {
    $dcIP = $dc.IPv4Address
    Invoke-Command -ComputerName $dc.Name -ScriptBlock $scriptBlock -ArgumentList $dcIP, $externalIP
}

I hope you enjoy the post,

Dave