Hi, I thought I should create a new topic for this.
I’m normally a Mac user so didn’t really notice this before:
It looks like the tunneling doesn’t work for my Windows machine. Does the Windows tunneler really not support intercepting IPv4 traffic as stated here? https://openziti.github.io/ziti/clients/windows.html
It sounds like it should in this guide though: https://support.netfoundry.io/hc/en-us/articles/360061111312-Collecting-Logs-Ziti-Desktop-Edge-for-Windows
The logs look like this:
[2022-10-19T17:54:46.777Z] INFO tunnel-cbs:ziti_tunnel_cbs.c:408 new_ziti_intercept() creating intercept for service[client_access.svc] with intercept.v1 = {"addresses":["01.ziti"],"dialOptions":{"connectTimeoutSeconds":5,"identity":""},"portRanges":[{"high":80,"low":80}],"protocols":["tcp"],"sourceIp":""}
[2022-10-19T17:54:46.777Z] INFO tunnel-cbs:ziti_dns.c:269 new_ipv4_entry() registered DNS entry 01.ziti -> 100.64.0.10
… which sounds kind of promising… 
You know - documentation... It's hard to keep it up to date. That doc is way out of date and wrong. You can totally intercept IPv4. I'll go update this doc
this should be something else entirely. Can you describe what's going on and what doesn't seem to work?
1 Like
I can’t even tell you how happy that answer makes me! Not being able intercept IPv4 traffic on Windows machines would kind of make it impossible for me to use OpenZiti.
Okay so I’m still on my use case of where I want to connect clients on port 80 to my remote server on tcp port 9000.
It works perfectly fine on Mac and even the mobile client.
I’ve created another identity for my Windows machines with the same attribute but somehow I can’t get a connection.
I do get the service, “01.ziti” and port 80 displayed but any try to establish a connection results in a “Error name not resolved”.
When testing for permissions in the Console I get
(Dial)
Everything is configured properly
Can you run this powershell command and verify “01.ziti” shows up?
Get-DnsClientNrptRule | findstr "01.ziti"
For example, I have an ‘http.ziti’ intercept so when I run Get-DnsClientNrptRule | findstr "http" I get:
Get-DnsClientNrptRule | findstr "http"
Namespace : {http.ziti}
DisplayName : ziti-edge-tunnel:http.ziti
Then - assuming you have this entry - can you run another powershell command (replace http.ziti with 01.ziti):
Resolve-DnsName "http.ziti"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
http.ziti A 60 Answer 100.64.0.71
Do all those checks work? If yes - let’s then look into the logs (which i was just writing up)
Logging
Logs for ZDEW are saved relative to the location of the installation. Normally this path will end up being:
C:\Program Files (x86)\NetFoundry, Inc\Ziti Desktop Edge. In that directory should be a logs directory.
Specifically the logs in logs/service/ziti-tunneler.log for any errors/hints
Executing
Get-DnsClientNrptRule | findstr "01.ziti
works, but resolving the name doesn’t. I also can’t find any DNS server starting with 10.xx.xx.xx when executing ipconfig /all
Interestingly enough I have the same with two separate Windows machines, a Dell XPS and a MacBook Pro. So looks like the DNS record somehow isn’t set?
Did you use Resolve-DnsName and not nslookup? The DNS server should be located at 100.64.0.2 by default, not 10.x.x.x and you won’t find it with ipconfig.
If you use nslookup you must provide the IP. You can find your DNS entry by the UI. Main Menu ->Advanced Settings->Tunnel Configuration
You can use nslookup like this:
C:\Program Files\Microsoft Visual Studio\2022\Community>nslookup http.ziti 100.64.0.2
Server: UnKnown
Address: 100.64.0.2
Non-authoritative answer:
Name: http.ziti
Address: 100.64.0.71
C:\Program Files\Microsoft Visual Studio\2022\Community>curl 100.64.0.71
<pre>
Hello World
## .
## ## ## ==
## ## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o _,/
\ \ _,'
`'--.._\..--''
</pre>
Yup, I used Resolve-DnsName.
The answer is
Resolve-DnsName : 01.ziti : DNS name does not exist
I’ve mistyped 100.xx.xx.xx for 10.xx.xx.xx - I’ve searched for any ip address starting with ‘100’.
Pinging 100.64.0.1 and 100.64.0.2 works!
fyi - Windows | Ziti is now updated. it’s not extensive, but it’s better than it was before. thanks for pointing it out.
So you’re saying Get-DnsClientNrptRule | findstr "01.ziti" returned a value but
Resolve-DnsName 01.ziti
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
01.ziti A 60 Answer 100.64.0.72
doesn’t work?
1 Like
Thanks for updating!
Exactly, here’s the exact output:
PS C:\Users\dm> Get-DnsClientNrptRule | findstr "01.ziti"
Namespace : {01.ziti}
DisplayName : ziti-edge-tunnel:01.ziti
PS C:\Users\dm> Resolve-DnsName 01.ziti
Resolve-DnsName : 01.ziti : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName 01.ziti
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (01.ziti:String) [Resolve-DnsName], Win32Exception
+ FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName
PS C:\Users\dm>
Strange… 
that is VERY strange indeed. what if you use nslookup:
nslookup 01.ziti 100.64.0.2
One more thing - don’t pipe into findstr… Just run Get-DnsClientNrptRule and let’s get “the whole rule”. Maybe it has the wrong dns server in it…
Here’s what mine looks like:
Name : {EC161BE3-7803-41F5-994B-9ED96AD30034}
Version : 2
Namespace : {01.ziti}
IPsecCARestriction :
DirectAccessDnsServers :
DirectAccessEnabled : False
DirectAccessProxyType :
DirectAccessProxyName :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired :
NameServers : 100.64.0.2
DnsSecEnabled : False
DnsSecQueryIPsecEncryption :
DnsSecQueryIPsecRequired :
DnsSecValidationRequired :
NameEncoding : Disable
DisplayName : ziti-edge-tunnel:01.ziti
Comment : Added by ziti-edge-tunnel
I’m wondering if the NameServers is somehow wrong for you
Also as an example… I’ve configured a service with three intercepts:
C:\Users\clint>curl http://01.ziti
<pre>
Hello World
## .
## ## ## ==
## ## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o _,/
\ \ _,'
`'--.._\..--''
</pre>
C:\Users\clint>curl http://1.2.3.4
<pre>
Hello World
## .
## ## ## ==
## ## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o _,/
\ \ _,'
`'--.._\..--''
</pre>
I hate the ‘works on my machine’ answer – but it does “work” for me… We’ll still keep trying to get to the bottom of what’s going wrong for you though
Strange, so nslookup 01.ziti 100.64.0.2 gives me
PS C:\Users\dm> nslookup 01.ziti 100.64.0.2
Server: UnKnown
Address: 100.64.0.2
*** UnKnown can't find 01.ziti: Query refused
And:
PS C:\Users\dm> Get-DnsClientNrptRule
Name : {0BC826D9-9E17-40E2-946B-DB61CBDC6D60}
Version : 2
Namespace : {01.ziti}
IPsecCARestriction :
DirectAccessDnsServers :
DirectAccessEnabled : False
DirectAccessProxyType :
DirectAccessProxyName :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired :
NameServers : 100.64.0.2
DnsSecEnabled : False
DnsSecQueryIPsecEncryption :
DnsSecQueryIPsecRequired :
DnsSecValidationRequired :
NameEncoding : Disable
DisplayName : ziti-edge-tunnel:01.ziti
Comment : Added by ziti-edge-tunnel
The awkward thing for me is: It works on Mac and iOS and I just installed Ziti Desktop Edge client, enrolled the JWT, that’s it! I didn’t even make any network changes
Thanks!
Out of curiosity, do you happen to have a virus scanner or other VPN active? I’ve honestly never seen this particular problem unless a virus scanner or other VPN is getting in the way.
Can you look into the windows event logs to see if anything is happening in there for clues?
This might be a tough one to crack…
Nope, no antivirus except for Defender, not even a VPN client
Let me check if I can find anything in the event logs…
If someone has the same problem - check if your name is actually NetBios compliant.
@TheLumberjack found the issue for me: my name was gl01 instead of e.g. gl01.ziti - that was the whole problem of Windows not resolving the name. Thanks again!
Glad we got it sorted! Thanks for sending me your feedback and letting me look through those logs. Yes, NetBIOS/unqualified domain names can be troublesome. Lots of confusing rules and corner cases and some Windows installs work as you’d expect - some don’t.
As a rule - we state we only fully support fully qualified domain names. That means they need to contain a period in the name. I think your gl01 intercept would work, but you have to use gl01. (with that trailing period). That’s confusing - so we highly recommend always using an intercept with at least one period in the intercept.
We did it!
2 Likes
That is a great point to emphasis.. not sure I have heard of that requirement before