When an intercept.v1 config uses a wildcard address (e.g. *.example.internal), ZDE correctly intercepts DNS queries and allocates a 100.0.0.x address for each resolved hostname. However, the corresponding host route is never added to the utun interface routing table. TCP connections to those addresses silently hang indefinitely. No error is logged anywhere - not in the ZDE appex.log, not on the controller, and not on the bind-side tunneler.
Changing the intercept from a wildcard to explicit individual hostnames resolves the issue immediately.
Interestingly enough, this works on another identical Mac, same client version, at another location.
- ZDE version: 2.53 (579)
- MacOS 26.1
- Controller: self-hosted, 1.6.13 (with 1.6.13 router on the same machine)
Intercept config (wildcard - broken):
{
"addresses": ["*.example.internal"],
"portRanges": [{"low": 22, "high": 22}],
"protocols": ["tcp"]
}
Intercept config (explicit - works):
{
"addresses": ["host-01.example.internal", "host-02.example.internal"],
"portRanges": [{"low": 22, "high": 22}],
"protocols": ["tcp"]
}
switching it back to wildcard breaks it again. Routes do not get added.
DNS query succeeds and address is allocated:
INFO tunnel-cbs:ziti_dns.c:349 new_ipv4_entry() registered DNS entry host-01.example.internal -> 100.0.0.8
INFO tunnel-cbs:ziti_dns.c:567 format_resp() found record[100.0.0.8] for query[1:host-01.example.internal]
But no route is ever installed:
$ netstat -rn | grep "100\.0\.0"
100.0.0.1/32 link#31 UCS utun6
100.0.0.2/32 link#31 UCS utun6
100.0.0.6/32 link#31 UCS utun6
100.0.0.8 is absent. After attempting the TCP connection, re-checking netstat -rn confirms the route is still never added.
No dial attempt, session creation request, or error appears in appex.log at the time of the TCP connection attempt.
Additional observations:
- The wildcard DNS allocation itself works correctly — each new hostname gets a unique
100.0.0.xaddress - Other services using literal hostname intercepts on the same identity work perfectly
The bind side is healthy - identical service works from another macOS identity on a different machine (same ZDE version) - Policy advisor confirms: Dial: Y, Bind: Y, Common Routers: 1/1 for the affected identity
Manually adding the missing route (sudo route add -host 100.0.0.8 -interface utun6) immediately makes the connection work, confirming this is purely a missing route installation step
I’m not finding any forum results about this issue, so I’m not sure if you’ve seen it or if anyone else is experiencing it. I’m going to give the machine a reboot shortly to see if that resolves it (since my machine at the office is working as expected).
Update:
reboot did not resolve it. I did just realize that the IP it is returning is 100.0.x.x, while the config is set up for 100.64.0.1/255.64.0.0. The machine that does work is returning an IP within that configured range, but this one is not. I do see two routes for 100.64.x.x, to the same utun6 interface, so it seems to be kind of using them?
But perhaps that is related?
% netstat -rn|grep 100.64
100.64.0.1 100.64.0.1 UH utun6
100.64.0.2 link#28 UHWIig utun6
Update 2:
Completely uninstalling ZDE and reinstalling it seemed to have work. My identities were still there, so I did not need to re-enroll any, but it’s handing out the 100.64.x.x IPs now, and the wildcard works. No idea what that was all about, but thanks for listening 
