Ziti Tunneler on Windows not working

I am trying to deploy OpenZiti in a production environment. The idea is to use an OpenZiti Tunneler (as a reverse proxy) so I can access private apps that only the tunneler can access.

Currently, I have 80 users using it, but the App is not closing sessions how it should, and I have to reboot the tunnelers constantly. Right now I am load-balancing traffic between 4 tunnelers and I am rebooting them almost every day.
More information can be found here: Tunneler stop working

In order to fix this I am trying to deploy the tunneler in Windows instead of Linux, however, I can not make it work.

I have 2 identities:

ziti edge create identity device Tunneler_6 -a server_test -o Tunneler_6.jwt

ziti edge create identity device Laptop -a networks -o Laptop.jwt

Then I configured the following on the controller:

ziti edge create config vault.host host.v1 '{"protocol":"tcp", "address":"myapp.com", "port":'443'}'
ziti edge create config vault.intercept intercept.v1 '{"protocols":["tcp"],"addresses":["myapp.com"], "portRanges":[{"low":'443', "high":'443'}, {"low":'80', "high":'80'}]}'

ziti edge create service vault.service --configs "vault.host,vault.intercept"

ziti edge delete service-policy vault.bind

ziti edge create service-policy vault.bind Bind --service-roles '@vault.service' --identity-roles '#server_test'

ziti edge create service-policy vault.dial Dial --service-roles '@vault.service' --identity-roles '#networks' 

I then created a Windows VM on AWS, installed Windows Ziti Edge, and added the “Tunneler_6” identity.
And on my laptop (MacOS), I added the “Laptop” identity.

I can see both services on both devices but I cannot access “myapp.com” from my laptop.

I thought it could be a Firewall issue so I disabled the Windows firewall and I am allowing all traffic in the AWS security group. However, it is still failing.


As part of my troubleshooting, I tried using the IP of “myapp.com” instead of the URL.
Let’s assume that the DNS record for myapp.com is 9.9.9.9 so I configured this service instead:


ziti edge create config vault2.host host.v1 '{"protocol":"tcp", "address":"9.9.9.9","port":'443'}'
ziti edge create config vault2.intercept intercept.v1 '{"protocols":["tcp"],"addresses":["9.9.9.9"], "portRanges":[{"low":'443', "high":'443'}]}'

ziti edge create service vault2.service --configs "vault2.host,vault2.intercept"

ziti edge create service-policy vault2.bind Bind --service-roles '@vault2.service' --identity-roles '#server_test'

ziti edge create service-policy vault2.dial Dial --service-roles '@vault2.service' --identity-roles '#networks' 

And then I deleted the old “vault” service.

Now, when I open a browser on my laptop and go to https://9.9.9.9 it works. That means that the issue has to be DNS since when I use the IP instead of the URL it works fine.

Any idea what could it be?

Hello,

I’m speculating a little bit here without tunneler logs from both sides, but my best guess is that the server for your service isn’t actually reachable by “myapp.com” from the VM that’s running your hosting tunneler?

The hostnames in the ziti intercept configurations will only be resolvable on the client (intercepting) tunneler. Hostnames in host configurations are not mapped by the DNS server in the hosting tunneler. So “myapp.com” is probably resolving to 42.81.192.183 on your hosting tunneler (at least that’s what I get from here). Is this what you expect?

If not, I’m guessing you want to change the address in your host.v1 configuration to the (probably private) hostname or IP of the box that’s running your server.

Hey, thanks for the quick response.

Just FYI, “myapp.com” is the name that I am using here, the URL of my app is different.

The VM hosting the tunneler can reach the app, which is why when I use the IP address instead of the URL in the service config it works fine.
Also, the app has a public DNS record and it is accessible over the internet, there are no private URLs or IPs in this environment.

On the app side, there is a firewall rule allowing traffic only to the public IP of the VM where OpenZiti is hosted.
It is the same scenario as: Tunneler stop working - #15 by Foles_90

I checked the logs and this is the error that I am seeing:

ERROR tunnel-cbs:ziti_hosting.c:394 on_hosted_client_connect() hosted_service[vault.service], client[Laptop]: getaddrinfo(myapp.com,443) failed: No such host is known. 

however, if I do a “nslookup myapp.com” from the VM hosting the tunneler it can resolve the name without any issues

Can you please try the lookup from the command line with ping, arp or some other system utility that uses gethostbyname? nslookup and dig can bypass the system resolver. Thanks.

ping works fine as well

Latency is <1ms because all this is hosted in AWS, but the connection is over the internet.

I’m still trying to come up with an explanation for why the hosting tunneler doesn’t resolve the hostname in your host.v1 configuration, but other utilities do.

One thing that raised my suspicions for a sec was the way you quoted your ziti cli command:

ziti edge create config vault.host host.v1 '{"protocol":"tcp", "address":"myapp.com", "port":'443'}'

The ticks around 443 looked odd to me (since the port is a numeric value), but when I tried it myself from zsh it worked - I’m assuming because zsh concatenates the quoted and unquoted portions together. Anyway…

I feel a little bad about asking you to confirm that the hostname in your config is spelled correctly? I don’t want to lead you through a bunch of hoops, but I can’t see the actual hostname in question here (which is more than understandable) and I do have a knack for spotting config errors, transposed chars, etc. Could you copy the string from the error message in the logs and paste it into your shell when you ping (assuming you haven’t already)? Thanks again.

Please don’t feel bad, you are helping me a lot! :smile:

One thing that I forgot to mention is that all this works when the tunneler is hosted in a Linux VM instead of Windows. I am using the same exact configuration on both.

I did a ping to the URL from the Error message (copy and paste) and the ping works fine.

Seems like something strange is going on. Shanwn and I just tried basically the same thing on my windows machine using a publicly available url (wttr.in).

Here’s the five commands to run (replace #all with whatever identities you want to bind/dial)

ziti edge create config wttr.in.host host.v1 '{"protocol":"tcp", "address":"wttr.in", "port":443}'
ziti edge create config wttr.in.int  intercept.v1 '{"protocols":["tcp"],"addresses":["my.wttr.ziti"], "portRanges":[{"low":443, "high":443}]}'
ziti edge create service wttr --configs wttr.in.host,wttr.in.int
ziti edge create service-policy wttr.bind Bind --service-roles '@wttr' --identity-roles '#all'
ziti edge create service-policy wttr.dial Dial --service-roles '@wttr' --identity-roles '#all' 

After running that, you can see I was able to use curl: curl -sk https://my.wttr.ziti:443

1196

What OS is running? I am on Windows 11, are you on Windows server maybe? or something else? If you try to access wttr.in via my.wttr.ziti using the commands above, are you successful?

Hi @Foles_90. I’m sorry you seem to keep running into issues that are difficult for us to reproduce. For this one, I’m going to try hosting a service from a Windows server instance (since I assume that’s what you are running). I’ll let you know how that works out here.

I should also mention that I don’t expect the Windows build to address the file descriptor leak that you encountered with the Linux tunneler. I’m going to take another look at that once I try the hosted service test on Windows server.

So I tried the setup that Clint posted in this thread, but with the hosting tunneler running on Windows Server 2019. The tunneler was able to resolve wttr.in.

It would be somewhat interesting to see if this wttr service works for you on your windows box. If so, that suggests the problem is specific to the hostname that you’re using for your server.

Oh, if you want to work around the dns issue on your windows box, the dns problem that you’re seeing is only observed by the hosting tunneler. So you could just change the host.v1 configuration to use the IP address:

ziti edge create config vault.host host.v1 '{"protocol":"tcp", "address":"9.9.9.9", "port":'443'}'
ziti edge create config vault.intercept intercept.v1 '{"protocols":["tcp"],"addresses":["myapp.com"], "portRanges":[{"low":'443', "high":'443'}, {"low":'80', "high":'80'}]}'

Anyway I’ll focus on the file descriptor leak in the other thread for now.

Thanks to both!
I tried the commands sent by @TheLumberjack and it works fine, now I am more confused :sweat_smile:

It has to be an issue with my URL then, but I can’t figure out why.
Anyways this was a test trying to solve the other issue (the file descriptor leak) so I will leave it like that for now and continue working on the other topic.