WDE Breaks Windows DNS on DC

So I have been debugging an unexpected behaviour where WDE would create a DnsClientNrptRule when the identity only allowed to host a service.

I am currently working on trying to serve a Windows DC over a ziti network, and got into a very nasty issue where as soon as the identity enabled with the respective host config taken from here[1] it would break the DC DNS making it unable to make a query to a DC DNS while being on the DC.
Manually deleting DnsClientNrptRule which is automatically created by the WDE fixes the issue.
It goes without saying the the network is functional, and I cant telnet to ports 389 and so on.

Is this behaviour of creating DnsClientNrptRule expected if identity only has host.v1 config? Also seems related to [2].

[1] Conneting Remote Endpoints with a On-Prem AD - #6 by emoscardini
[2] Windows Edge Client - DNS not working - #4 by TheLumberjack

WDE: 2.4.0.0
Windows: Windows Server 2022

Steps to reproduce:

  1. Create and initialize a DC with a DNS server
  2. Run a WDE with identity able to host the necessary ports
  3. Open a powershell on that very same DC and execute:
Resolve-DnsName _ldap._tcp.dc._msdcs.mydomain.com -Type SRV

Expected behaviour:
After running a WDE with an identity as per[1] I expect for the above DNS query to be proxied on the host to the 'upstream' DNS server which would be Windows DNS Server in this case.

Actual behaviour:
I believe there is happenning a routing mess with the DNS query specifically. As DnsClientNrptRule exist at the moment of routing the request, I believe it just getting recursed.

Related logs:

Logs and debug data
ziti edge list service configs 1NaVms2ov3JhbNYZMLdOAp
โ•ญโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ
โ”‚ ID                     โ”‚ NAME                           โ”‚ CONFIG TYPE  โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚ 1aXbn9XkxZW7ps8UzzCerg โ”‚ windows-bayfut-dc.intercept.v1 โ”‚ intercept.v1 โ”‚
โ”‚ VvU0ijDuYCBpCBX4YtP7K  โ”‚ windows-bayfut-dc.host.v1      โ”‚ host.v1      โ”‚
โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฏ
intercept.v1
{
    "addresses": [
        "*.bayfut.net"
    ],
    "portRanges": [
        {
            "high": 138,
            "low": 138
        },
        {
            "high": 53,
            "low": 53
        },
        {
            "high": 389,
            "low": 389
        },
        {
            "high": 445,
            "low": 445
        },
        {
            "high": 65535,
            "low": 1024
        },
        {
            "high": 88,
            "low": 88
        },
        {
            "high": 636,
            "low": 636
        },
        {
            "high": 123,
            "low": 123
        },
        {
            "high": 135,
            "low": 135
        }
    ],
    "protocols": [
        "udp",
        "tcp"
    ]
}
host.v1
{
    "allowedAddresses": [
        "*.bayfut.net"
    ],
    "allowedPortRanges": [
        {
            "high": 138,
            "low": 138
        },
        {
            "high": 53,
            "low": 53
        },
        {
            "high": 389,
            "low": 389
        },
        {
            "high": 445,
            "low": 445
        },
        {
            "high": 65535,
            "low": 1024
        },
        {
            "high": 88,
            "low": 88
        },
        {
            "high": 636,
            "low": 636
        },
        {
            "high": 123,
            "low": 123
        },
        {
            "high": 135,
            "low": 135
        }
    ],
    "allowedProtocols": [
        "udp",
        "tcp"
    ],
    "forwardAddress": true,
    "forwardPort": true,
    "forwardProtocol": true
}

Hi @nenkoru

Sorry you're running into trouble, I'm trying to replicate this setup now. Just to make sure I understand, you're installing the WDE on the DC itself to host the service? The reason I'm asking is I've never tested a setup like this before. All the guides we've written up use an Edge Router that's able to reach the DC to host the services.

@TheLumberjack Do you know if WDE is supposed to create DnsClientNrptRule when hosting a service?

Yeah, exactly.
I am trying to serve DC using WDE installed right on the machine. And possibly connect other DCs together using WDE.

I have replicated the same setup twice, thinking I had done something wrong, the same result of DnsClientNrptRule breaking the SRV request.

I have confirmed both that a DnsClientNrptRule is created when hosting the service & the lookup only works if that rule is removed.

Here's the example of the rule being created on the hosting side:

PS C:\Users\Administrator> Get-DnsClientNrptRule


Name                             : {E230E4BA-97E7-4441-8187-9A0087076CC7}
Version                          : 2
Namespace                        : {.contoso.com}
IPsecCARestriction               :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessProxyName            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      : 100.64.0.2
DnsSecEnabled                    : False
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         :
DnsSecValidationRequired         :
NameEncoding                     : Disable
DisplayName                      : ziti-edge-tunnel:.contoso.com
Comment                          : Added by ziti-edge-tunnel

From a remove machine running WDE with policies allowing access to the service, I'm only able to perform the lookup Resolve-DnsName _ldap._tcp.dc._msdcs.ziti.contoso.com -Type SRV once the above rule is removed from the hosting side. This can be replicated simply by restarting the hosting side WDE & allowing it to re-create the above rule.

1 Like

@scareything/@TheLumberjack What's the purpose of adding the DnsClientNrptRule on the hosting side. Could this be a bug? I was under the impression those rules were strictly used for interception.

Yeah, sounds like a bug to me. I would only expect an NRPT rule on intercept, not dial. If the identity only has bind, I would not expect an NRPT rule

1 Like

I opened an issue for this: DnsClientNrptRule is being created on hosting service identity OS ยท Issue #971 ยท openziti/ziti-tunnel-sdk-c ยท GitHub

1 Like