Buckle up… We’re going deep…
Ok so bringing it back to what I think “the problem” is. I’m still worried that somehow “windows” itself is somehow in this mix. I’m gonna recap my understanding and hopefully clarify the setup in my own head.
ziti-edge-tunnel running in WSL, using “wsl-identity”, providing access to “*.xyz.local” from within WSL only.
You have ZDEW running in Win11, using “win11-identity”, providing access ONLY to personal service “service.abc.com”. Please confirm this identity only has access to a single service and doesn’t also have access to the wildcard service?
Then, from WSL, when you curl to
http://blah.xyz.local, you’re getting access to
I think I might know why. I don’t have an environment with all this setup to test it, but I my WSL ziti-edge-tunnel and my windows ZDEW are assigned both 100.64.0.0 addresses. If that’s the case, the VERY FIRST wildcard service you access will be assigned to 100.64.0.3 — BUT — your windows ZDEW will also assign 100.64.0.3 (in windows) to service.abc.com.
Can you confirm that the tun in linux – and the wintun adapter (adapter ziti-tun0) are both getting the 100.64.0.0 address space assigned to them? I bet that is what happens… I think that’s the case. Assuming it is… Why wildcard is important.
Wildcard IP assignment
When using a wildcard service, for every service you resolve, you will get a new IP address starting at TUN + 1, and that’s why this seems to be ‘random’ to you, because it’ll be dependent on the order in which you access the wildcard services.
Let me illustrate:
- turn on ZDEW – notice (via ipconfig)
- turn on linux ziti-edge-tunnel
- notice both get 100.64.0.0 IP addresses (shown below)
blah.xyz.local and then dig it:
dig blah.xyz.local and it’ll be assigned IP 100.64.0.3. Now access some OTHER service,
foo.xyz.local and dig THAT. you’ll see it’ll be assigned IP 100.64.0.4 and so on…
At this time, using cmd.exe in windows you can try to nslookup…
nslookup service.abc.com 100.64.0.2 and I assuming it’s the only service, it will come back as 100.64.0.3…
IMPORTANT NOTE. You now have two services, in two networking spaces, assigned to 100.64.0.3 based on “how OpenZiti works”… And THIS is where I think the problem comes. So depending on what wildcard service you’re accessing after turning ziti on in WSL land, that first service will overlap the ZDEW service…
Is this all making sense??? It makes sense to me but it’s definitely an intricate web and I’m doing a bunch of hand-waving and assuming. lol
How do you fix this
Ok, so the easiest solution to fix this would be to move your
ziti-edge-tunnel to a different IP space
sudo ./ziti-edge-tunnel run /mnt/v/temp/id.json --dns-ip-range 100.64.100.100/16
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 100.64.100.100 netmask 255.255.255.255 destination 100.64.100.100
I think that’s all you need to do… Assuming my hand-waving and assuming is correct
looking forward to hearing back from you