I’m currently deploying OpenZiti over a subnet in AWS and encountering an issue with DNS resolution.
Here’s the setup:
VPC Subnet: 10.0.0.0/16
AD DNS Server: 10.0.0.2 (within the same VPC)
Config Name: aws-server-intercept-dns.v1
Config Type: intercept-with-dns.v1
Port Range: 1–65535
dns: enabled
resolvers:- 10.0.0.2
suffixes: example.com
Protocols: tcp, udp
Addresses: 10.0.0.0/16
I’ve configured DNS interception expecting all DNS queries from clients to route through the AD DNS (10.0.0.2), but this is not working. earlier with normal intercept config without dns setting The rest of the OpenZiti setup appears to function correctly — I can access all other services via OpenZiti without issues.
Could you please help identify what might be missing or misconfigured for DNS routing through the AD DNS server?
I’ve attached a screenshot of my current configuration for reference.
As far as I know, the config type "intercept-with-dns.v1" is not a config type OpenZiti delivers. So I am at a loss for what you're doing or how to help.
i am sorry for this, we followed Chatgpt too hard, what we found is,By following this Conneting Remote Endpoints with a On-Prem AD - #6 by emoscardini we created another config, for the traffic to pass through AD domain using *.example.com. So whatever requests using .example.com comes it will go to the AD domain dns. we are yet to see a success on this matter.
Can you please update your configurations to follow the example in the post that you linked here? If that still isn’t working for you then we’ll look into what might be going wrong.
The Active Directory feature is enabled when you specify a wildcard domain in the intercept address list (e.g. “*.example.com”). When you have a wildcard domain, the intercepting tunneler’s DNS server looks for MX, TXT, and SRV queries on the specified domain(s), and forwards those queries to the hosting tunneler.
To be clear, A (address) queries for intercepted domains are not forwarded - the intercepting tunneler needs to answer those with an ip address that is routed to the tunneler’s tun interface so the ip connection can be intercepted.
all of your configurations (including the host.v1)
logs from the client and server tunnelers
your specific use case (e.g. what command are you running on the client to initiate a connection
what is your expected behavior, assuming that differs from what actually happened.
One thing stands out to me from seeing the pieces that you’ve shared so far.
You have port 53 in your intercept configuration. So you’re instructing the client tunneler to intercept traffic going to e.g. dns.my.domain.com:53. Keep in mind that any hostname in your wildcard domain is going to resolve to an IP in the tunneler’s DNS subnet - 100.64/10 by default. So unless you are configuring your host’s DNS resolver with a 100.64 IP then the client tunneler is simply never going to see packets on port 53.
In fact you almost certainly don’t want to intercept port 53. I briefly explained this in my previous post, but the client tunneler has a DNS server built into it, and it configures itself into the host’s resolver so any hostnames in your intercept.v1 address list will resolve to an ip that is routed to the client tunneler.
Regular hostname lookups on the client do not need to resolve to the same ip that is resolved on the server side of the connection. This is because (following the example post) your host.v1 configuration has forwardAddress enabled, which means that the client tunneler will send the hostname that the intercepted client was trying to connect to over to the hosting tunneler, and the hosting tunneler will use that hostname when it makes the final connection in the chain.
The client tunneler’s internal DNS server will look for TXT, MX, and SRV queries for the wildcard domains, and only these query types will be sent to the hosting tunneler. You do not need to arrange for this to happen by explicitly configuring your service with e.g. port 53. It happens automatically when you’re intercepting wildcard domains.
Use Case: Attempting to access Active Directory Domain Controller through Ziti overlay network
Domain: example.com (forwarding needed to DNS server at 10.0.0.2)
What I've Configured
Ziti Server DNS Configuration: Added DNS and domain entries in the systemd-resolved configuration on the Ziti server
Network Topology: Entire AWS subnet is configured behind Ziti
Client Setup: Ziti client installed and running on Windows PC
Current Behavior
When I ping the domain from my PC's command prompt, I receive responses showing the Ziti DNS is intercepting queries
This confirms traffic is being routed through the Ziti overlay network
However, the DNS queries don't appear to be reaching the Active Directory server
The Problem
Clients cannot execute gpupdate commands successfully. While DNS queries are intercepted by Ziti, they're not being properly forwarded to the AD Domain Controller, preventing Group Policy updates and domain operations.
What I Need
I need to configure Ziti such that:
DNS queries for example.com domain are intercepted by Ziti
These queries are forwarded to the DNS server at 10.0.0.2 (AD Domain Controller)
All AD-related traffic (DNS, LDAP, Kerberos, etc.) is properly routed through Ziti to allow full AD functionality including Group Policy updates
I have the same host and intercept config as above for now, What can i do to achieve this.
Are you still using the configuration that tries to intercept port 53? If so I think it’s unnecessary, at best. Also did you enable address forwarding in the host configuration? That’s an important piece of this solution.
Keep in mind that onlyMX, TXT, and SRV records will be forwarded over ziti. It sounds like you’re trying to forward address queries (for A records) over ziti, and this is most likely not what you want.
What IP do you get when you ping hostnames in your AD domain? I’d expect 100.64/10 addresses fyi.
When you said “yes” here, does that mean that you are seeing 100.64 addresses when you ping your AD hostnames? If so that’s good! The client tunneler needs the names to resolve to this range, so that it can intercept the ip connections that applications will initiate when the hostname is resolved.
The gpupdate command is going to make a different kind of DNS query - an SRV lookup - to determine where it should connect with the domain controller. You can test that query like this:
By the way, it’s important that the response to this SRV query contains your AD domain “example.com” in the “name” and “target” fields (the target field will be a subdomain). I mention this because if your SRVs target IP addresses then we’ll need to do more tweaking on your intercept configuration.
You can see the tunnelers on both sides of the connection handling these SRV queries. You’ll need to increase the ZDEW log level to DEBUG to see this on the client side. After running the query. The log message in the ZDEW tunneler log will have something like this in it:
We haven’t covered which tunneler you’re using to host this service yet, so I’ll assume you’re using the edge router as described in the example post. If so, you should see something like this in its log:
INFO github.com/openziti/edge/tunnel/intercept.(*resolvConn).Write: {name=[_ldap._tcp.dc._msdcs.example.com] service=[examplecom-ad] type=[33]} resolving
Can we verify that the SRV records are happening as they should? I’d also like to see the response from the Resolve-DnsName query above.
found out that if I use the Edge Router as the bind, everything works as it should.
When I use a tunneller (Edge Client) as the bind, I can’t perform SRV record lookups.
I’ve tried using tunneller (Edge Client) outside the domain that are correctly configured same config as with edge router as bind.
tunneller (Edge Client) using the Edge Client as the bind directly on the domain controllers.
Tunnels on a domain member server as the bind.
Only the setup following the guide with the Edge Router as the bind worked.
It’s worth mentioning that I really want to get the other setup working — it would make migration scenarios much easier, since I could just deploy a tunnel and use it to extend the domain.
I’d like to forward the OpenZiti Edge Client logs to you, but I’d prefer to send them to you one-on-one, just to make sure nothing sensitive gets shared
Sure thing. You can email a zip to scarey@netfoundry.io. Just so I’m clear, are you working with @anshjoshi on the particular setup that this tread was started for, or is this a separate instance of an active directory deployment?
No, I just read the thread, so it’s not @anshjoshi’s setup, but I think it’s the same issue.
We have three different AD configurations that we’ve tested with three different OpenZiti setups, mixing and matching across them.
What I’ve found is that the ZITI tunnel works as it should — I think the problem is SMB Signing failing when going through an OpenZiti edge client. Funny enough, it works fine through an edge router acting as a bind.
But it’s consistent and easy to reproduce the error.
Configured Ziti intercepts for *.example.com, including all required LDAP/SRV ports (389, 636, 3268, 3269).
Updated /etc/systemd/resolved.conf.d/ad.conf on the Ziti host to use our AD DNS server (10.0.0.23).
Verified that _ldap._tcp.dc._msdcs.example.com SRV lookups resolve correctly.
From the Ziti server (10.0.0.4), ldapsearch to ldap://10.0.0.23 successfully reaches AD and prompts for credentials.
AWS VPC Flow Logs show active traffic between the Ziti server and AD with no drops or rejects.
Additionally, the entire subnet is routed through Ziti — for example, Ziti runs on .4 and AD on .23 within the same subnet. I also created a separate host and intercept configuration specifically for AD, which effectively overlaps with the subnet intercept (a kind of double configuration). The main subnet intercept already allows all ports.
Given this setup, I’d like to confirm if gpupdate /force from a Windows client connected via Ziti should work as expected now, or if there are any additional configurations required (for Kerberos, SMB, or other AD-related services) to ensure full Group Policy processing.
Thanks for sending the client tunneler (ZDEW) logs! They reveal to me a detail that at least partially explains why your Active Directory services aren’t working. Specifically the log shows that your client tunneler is not intercepting your Active Directory domain.
First, I see references to a service named “*****-ad-service”, but the tunneler does not set itself up to intercept this service. This suggests that none of the identities that the tunneler is using have permission to dial the service. Can you please check your service permissions, and ensure that the associated identity is enabled in the tunneler configuration?
Secondly, I noticed that your controller hostname is in the domain that you intend to use for Active Directory. This will likely become a problem once your tunneler has permission to the service because the tunneler’s DNS server will be providing answers for the ‘*.example.com’ domain, and it won’t give correct answers for your controller. I suggest accessing your controller with a domain that doesn’t overlap with your Active Directory domain to avoid this conflict.
Earlier, I had configured my OpenZiti controller and router using the same FQDN as my Active Directory domain (for example, both were using example.com). After realizing this might cause conflicts, I changed the controller and router FQDNs to a different domain (for example, example.io). in a new EC2 instance.
However, even after making this change, Group Policy updates (gpupdate) on my domain-joined systems are still failing.
The traffic is going through ziti but SRV command still fails from client device.
If you need any more information regarding this, Please feel free.
That’s good that you fixed changed the controller hostname so that it doesn’t match your Active Directory wildcard. Can you send the logs from ZDEW while your identity is connecting to the controller at the .io address?
Also please make sure that the identity ZDEW is using has dial permission for your Active Directory service(the one with the `*.example.com’ intercept address).
