Hello Team,
I apologize because my question might be ridiculous. 
I'm still discovering Ziti and, starting from Quickstart, I would like to build a very simple scenario: the Host access "4. Client to Host A Deployment" one. I believe I must remove the tunneler role from the router but when I do it, the router becomes off-line and I'm not able to put it on-line again.
Can you explain why removing the tunneler role makes the router down?
Thanks!
You would have to check the logs, but my guess is that the router can't configure itself according to the config file. Having the tunneler role means it has a tunneler listener configured. If that isn't allowed by the controller, the router may be in a rolling restart.
There is also no need to remove the tunneler in that example. The Edge Router can egress fine with the tunneler active and this is a common configuration. You do need to be careful to make sure that the policies are configured so that the tunneler is not able to dial the service, as that can cause a loop in some cases. The router outputs the packets, they are intercepted by the tunneler, emitted again, intercepted again, etc.
Hi Michael, thanks for your reply. Please let me explain my scenario further, which is very simple actually. On one hand, a web server with the tunneler app installed. On the other hand the client with a browser and the tunneler app installed. Between them, a Debian server with the controller and the sole router in the scenario.
As the overlay ends on each host with the tunneler app, I was thinking that removing tunneling feature from the router was mandatory. When you write " You do need to be careful to make sure that the policies are configured so that the tunneler is not able to dial the service", you're talking about the tunneler feature in the router?
OK, so you have the tunneler app on each end and the router in the middle. So the common loop isn't a problem, though you still need to make sure the Edge Router doesn't have Dial permissions to the service. The tunneler feature won't impede the router process acting in any other way, it's an AND, not an OR, so while you wouldn't need it in the scenario you've described, it is also not mandatory to remove it.
When you say you removed the tunneler feature from the router, how, exactly, did you do that?
If you look at the log or journalctl for the router process, what do you see?
Hi Michael,
To remove the tunneler feature, I taped on the tunneler switch in the Ziti console options for the router. I also tried to modify the .yaml file. In both cases, the router becomes off-line. But as you say that removing this feature is not mandatory, there must be something wrong elsewhere.
To test the connexion, I open a browser on the client and type http://montest.mydomain.com/test.zip to download a 450 MB file. Download works well but I don't think I use the overlay.
In the log ile, the lines I got at the download time are:
| [2024-03-13T05:40:19.197Z] INFO | ZitiDesktopEdge.MainMenu | opening service logs at: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\service\ziti-tunneler.log.202403130000.log | |
|---|---|---|---|
| [2024-03-13T05:40:19.477Z] INFO | ZitiDesktopEdge.MainMenu | showing service logs. file: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\service\ziti-tunneler.log.202403130000.log | |
| [2024-03-13T05:40:39.672Z] INFO | ZitiDesktopEdge.MainMenu | opening service logs at: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\service\ziti-tunneler.log.202403130000.log | |
| [2024-03-13T05:40:39.843Z] INFO | ZitiDesktopEdge.MainMenu | showing service logs. file: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\service\ziti-tunneler.log.202403130000.log | |
| [2024-03-13T05:40:46.259Z] INFO | ZitiDesktopEdge.MainMenu | opening UI logs at: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\UI\ZitiDesktopEdge.log | |
| [2024-03-13T05:40:46.446Z] INFO | ZitiDesktopEdge.MainMenu | showing UI logs. file: \?\C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\UI\ZitiDesktopEdge.log |
so nothing interesting I guess.
Here are the settings I entered during Quickstart:
export http_server="montest.mydomain.eu"
ziti edge create identity pcv-el -a 'http-clients' -o pcv-el.jwt
ziti edge create identity montest -o montest.jwt
export http_server_id="D08-zGdVW7"
ziti edge create config http.intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["montest.mydomain.eu"], "portRanges":[{"low":80, "high":80}]}'
ziti edge create config http.host.v1 host.v1 '{"protocol":"tcp", "address":"'"${http_server}"'", "port":80}'
ziti edge create service http.svc --configs http.intercept.v1,http.host.v1
ziti edge create service-policy http.policy.dial Dial --service-roles "@http.svc" --identity-roles '#http-clients'
ziti edge create service-policy http.policy.bind Bind --service-roles '@http.svc' --identity-roles "@${http_server_id}"
Then I enrolled the server (montest) and the client host (pcv-el) with no issue.
I'm not yet comfortable with Ziti settings but I spent many hours to read the docs and search for the problem in my configuration but got no result at this time. . Hopefully, it will be obvious for you. 
A strange thing maybe: when I ping montest.mydomain.eu from the client host, returned IP is 100.64.0.4 and delay is <1ms. It should be around 20ms. Other strange thing: ipconfig done on montest server returns 100.64.0.1 on tun0 interface. So why do I see 100.64.0.4 in ping described above?
Wow, all 100.64.. answer to ping requests! I'm completely lost!
The 100.64.0.0 space is used by OpenZiti to create local targets for services. Any DNS names for services are given an IP out of that space, and the OpenZiti tunneler replies to the DNS requests. This brings the traffic to the software for transport, it is how it is intercepted. You get the super short pings because the IP is local to the machine, it doesn't go anywhere. The fact that it is the response you get would indicate everything is working. The logs I was referring to earlier were the logs from the router process, it looks like you pulled the logs from the client UI.
OpenZiti is a large and complex space, so it isn't surprising that you are finding things as you go, but that is the nature of experiments, right?
I agree. Anyway, this is not my main problem! Any idea why it does not work? Do you see mistakes in my configuration?
The config appears to be correct. Since you are getting the 100.64.0.4 return, that seems like it is working.
Do you have the events and metrics enabled for logging on the controller, similar to the config of the JSON logger on this page Controller Configuration Reference | OpenZiti ?
If so, you could search them for the call events (namespace fabric.circuits) to see if they succeeded or failed. If they succeeded, you can search for the utilization if you have that enabled, using the circuitId from the created event. Or, you can just look for the utilization. If the Dial fails, the fabric.circuits event will say failed, and it will give a failure cause that could be very useful in determining what happened.
I will do that and tell you. Thanks!
Hi Michael,
I have added events section to ziti.yaml. I did not see any error. When I try (and fail) to access the web server, I only see one log related to it:
{"namespace":"edge.sessions","event_type":"created","session_type":"Dial","id":"cltts27xa0091hudkwnvh8qq9","timestamp":"2024-03-16T08:39:45.696794893+01:00","token":"03bd31b2-4b53-4eb8-bc84-c01177334d9f","api_session_id":"clttrvd2q0003hudkz7tkdgjh","identity_id":"ua8-zGnBW","service_id":"63CQoqsHc9YFqTwLYFIIWq"}
I don't have the skills to understand what that means but it looks like there is no error. On the other hand, I'm surprised not seeing other logs related to my request. Does it mean something to you?
Hi Michael,
At last, it's working. It was an issue with the http_server value. I entered the fqdn of the web server but it failed. After entering its private IP address, it's working. I can now move forward with my tests! Thanks a lot for your help.