Network interruption causes ziti-tunnel to fail to recover

1

Hello,

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:

  1. Long periods of inactivity causing the system to sleep/hibernate

  2. 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:

  1. Start ziti, open website service A, test OK

  2. Disable the network adapter, wait 1–2 minutes

  3. 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

2

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'. :frowning: