I am encountering an issue when using ziti-tunnel. After a network interruption and when the network returns to normal, the ziti network fails to recover for unused service.
This type of network interruption may occur in the following scenarios:
Long periods of inactivity causing the system to sleep/hibernate
Network adapter disabled/enabled
On another computer, I couldn't reproduce the issue.
What could be the reason for this?
Software versions:
Ziti 2.0
ziti-tunnel-sdk-c v1.18.1, v1.15.1
Ziti Desktop Edge: 2.11.2.4
OS: Windows 10
Test method:
Start ziti, open website service A, test OK
Disable the network adapter, wait 1–2 minutes
Enable the network adapter, open website service B and service C, test fails (NG)
Services A, B, and C are all services for which I have permission. In testing, there is a certain probability that it will work, but in most cases it does not.
Tunnel log:
[2026-07-03T08:39:19.245Z] ERROR tunnel-cbs:ziti_tunnel_cbs.c:128 on_ziti_connect() ziti dial failed: connection is closed
[2026-07-03T08:39:19.497Z] ERROR ziti-sdk:connect.c:1100 connect_reply_cb() conn1.452/EtCORhOF/Connecting failed to connect, reason=failed to create service token from JWT: token is unverifiable: error while executing keyfunc: public key not found
[2026-07-03T08:39:19.497Z] ERROR tunnel-cbs:ziti_tunnel_cbs.c:128 on_ziti_connect() ziti dial failed: connection is closed
[2026-07-03T08:39:19.751Z] ERROR ziti-sdk:connect.c:1100 connect_reply_cb() conn1.453/Hq68hP4m/Connecting failed to connect, reason=failed to create service token from JWT: token is unverifiable: error while executing keyfunc: public key not found
[2026-07-03T08:39:19.751Z] ERROR tunnel-cbs:ziti_tunnel_cbs.c:128 on_ziti_connect() ziti dial failed: connection is closed
Hi @maika, this is not something I've personally seen happen unless you are perhaps reusing a DNS name that resolves to a legitimate IP. For example, lots of people try to shadow a public FQDN. So for example if you have something like chat.openzit.io and it resolves to some public IP 3.1.3.1 and you then make a service using openziti and shadow that name, when you turn the tunneler on it'll make up an IP such as 100.64.0.4. I've found numerous browser/electron type apps are caching the IP address somehow and never re-resolving the address leading to misrouted packets.
It's not a common setup but it happens, so maybe that's what's going on. If the app you're using is caching the wrong IP address that would cause this sort of behavior.
The only way to know for sure is to have some short set of steps that is very reproducible that we could perform and witness the issue.
I've also seen "endpoint protection software" cause these sorts of problems. I've seen AV terminate connections that it shouldn't be. so that might be a reason why "On another computer, I couldn't reproduce the issue". Did one run endpoint protection software (AV) of some type?
Unfortunately this isn't something I've seen or know about as any sort of 'known issue'.
Hi @TheLumberjack ,Today I tested on another computer: I connected to Ziti first, then put the computer into sleep mode, and after more than an hour, when I woke it up, the Ziti network was no longer working.
You'll have to capture all the logs from the tunneler at DEBUG level and share them with us for us to have a chance to help. Many of our customers, users, colleagues do exactly this and we don't end up with issues. If you're in a different situation, the logs would likely give us an indication as to what's going on.
Hi @TheLumberjack ,
Attached is the log with url redacted.
I'm wondering if this might be due to my network architecture. I have 6 controllers and 8 routers, but in the current network environment, I can only connect to a few of them.
Does Ziti recommend that clients be able to connect to all controllers?
Hi @maika, looking at the logs it looks like this client can't authenticate to me. Is this a nascent deployment or has it been deployed for a while?
If this was me I could (you might not be able to), I would start by stopping all the controllers and routers I could and I would bring just one controller and one router back online. That would rule out some sort of problem with the quorum formation. If this device reconnects that'd be useful information. If it doesn't, the logs on the one running controller or the router would likely point to the problem.
With six controllers, I would at a minimum stop three controllers just to reduce how many logs you need to look through but you likely need to look through all the controller and router logs looking for errors from this tunneler I think.
I expect you are running 2.0 because you have more than one controller running but I suppose we should confirm that and also confirm all your routers are 2.0.
Another thing to check, make sure you put the identity into the default auth policy if it's not already. Sometimes people make new auth policies and get that step wrong (or possibly hit a bug) so if there's another auth policy change it back to the default.
One more thing comes to my mind after rereading the reply again and writing all this... "I can only connect to a few of them" does this mean you can only connect to a few controllers? Are some of them available and some not? That might mean you can't form a quorum. Can you run ziti list controllers and verify there's a leader?
