Mac Ziti Desktop Edge randomly loosing authentication

1

Hi,

we are running Ziti Edge Tunnel and Controller v.1.6.12.
We have discovered that some identities just loose connection inrecoverably. The only way is to recreate the identity. When re-enrolling the JWT, this happens again after a week or so. Any ideas?

[2026-02-01T15:22:54:094Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:167 loadConfig() ProviderConfig <PacketTunnelProvider.ProviderConfig: 0xba9038a00>
ipAddress: 100.64.0.1
subnetMask: 255.192.0.0
mtu: 4000
dns: 100.64.0.2
fallbackDnsEnabled: false
fallbackDns: 1.1.1.1
interceptMatchedDns: true
lowPowerMode: false
logLevel: 3
logTlsuv: false
logRotateDaily: true
logRotateCount: 5
logRotateSizeMB: 50
[2026-02-01T15:22:54:095Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:87 startTunnelAsync() Setting log level to INFO
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:utils.c:196 ziti_log_set_level() set log level: root=3/INFO
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:utils.c:196 ziti_log_set_level() set log level: tlsuv=1/ERROR
[2026-02-01T15:22:54:095Z]    INFO PacketTunnelProvider:Logger.swift:242 updateRotateSettings() Updating log rotate config to daily:true, count:5, sizeMB:50
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:176 seed_dns() DNS configured with range 100.64.0.0 - 100.127.255.255 (4194302 ips)
[2026-02-01T15:22:54:103Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:330 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53
[2026-02-01T15:22:54:115Z]    INFO CZiti:ZitiTunnel.swift:208 loadAndRunZiti() Starting ltZ0RYeNwc:"Optional("dm_mb")" at https://zt.deltasecure.de:8441
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:utils.c:196 ziti_log_set_level() set log level: root=3/INFO
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:utils.c:167 ziti_log_init() Ziti C SDK version 1.8.5 @gca0d903(HEAD) starting at (2026-02-01T15:22:54.124)
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:ziti.c:512 ziti_start_internal() ztx[1] enabling Ziti Context
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:ziti.c:529 ziti_start_internal() ztx[1] using tlsuv[v0.38.1/OpenSSL 3.5.0 8 Apr 2025]
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:ziti_ctrl.c:637 ziti_ctrl_init() ctrl[https://zt.deltasecure.de:8441] controller initialized
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:ziti.c:606 ztx_init_controller() ztx[1] Loading ziti context with controller[https://zt.deltasecure.de:8441]
(44978)[2026-02-01T15:22:54.074Z]    INFO ziti-sdk:ziti.c:2048 version_pre_auth_cb() ztx[1] connected to Legacy controller https://zt.deltasecure.de:8441 version v1.6.12(5afd4d7837fc 2025-12-04T23:23:51Z)
(44978)[2026-02-01T15:22:54.074Z]   ERROR ziti-sdk:ziti_ctrl.c:525 ctrl_body_cb() ctrl[https://zt.deltasecure.de:8441] API request[/authenticate?method=cert] failed code[INVALID_AUTH] message[The authentication request failed]
(44978)[2026-02-01T15:22:54.074Z]   ERROR ziti-sdk:ziti_ctrl.c:389 ctrl_login_cb() ctrl[https://zt.deltasecure.de:8441] INVALID_AUTH(The authentication request failed)
(44978)[2026-02-01T15:22:54.074Z]    WARN ziti-sdk:legacy_auth.c:183 login_cb() failed to login to ctrl[https://zt.deltasecure.de:8441] INVALID_AUTH[-14] The authentication request failed
(44978)[2026-02-01T15:22:54.074Z]    WARN tunnel-cbs:ziti_tunnel_ctrl.c:1018 on_ziti_event() ziti_ctx controller connections failed: failed to authenticate
[2026-02-01T15:22:55:163Z]    INFO PacketTunnelProvider:ZitiTunnelDelegate.swift:222 tunnelEventCallback() ZitiTunnelEvent: <CZiti.ZitiTunnelContextEvent: 0xba9010ae0>
   identity: dm_mb:"ltZ0RYeNwc"
   status: failed to authenticate
   name: 
   version: 
   controller: 
   code: -14
[2026-02-01T15:22:59:129Z]    WARN CZiti:ZitiTunnel.swift:232 loadAndRunZiti() Timed out waiting for zidToLoad == 0 (1 of 1 identities have not returned any services
[2026-02-01T15:22:59:132Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:211 updateTunnelNetworkSettings() route: 100.64.0.1 / 255.192.0.0
[2026-02-01T15:22:59:132Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:384 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     14: name:en0, type:wifi 
     14: name:en0, type:wifi
[2026-02-01T15:22:59:147Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:330 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
[2026-02-01T15:22:59:147Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:369 startNetworkMonitor() Setting fallback DNS to 192.168.1.1
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53
[2026-02-01T15:22:59:271Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:384 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     14: name:en0, type:wifi 
     14: name:en0, type:wifi 
     26: name:utun4, type:other
[2026-02-01T15:22:59:290Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:330 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
[2026-02-01T15:22:59:290Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:369 startNetworkMonitor() Setting fallback DNS to 192.168.1.1
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53
[2026-02-01T15:22:59:485Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:384 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     14: name:en0, type:wifi 
     14: name:en0, type:wifi 
     26: name:utun4, type:other
[2026-02-01T15:22:59:492Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:330 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
[2026-02-01T15:22:59:492Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:369 startNetworkMonitor() Setting fallback DNS to 192.168.1.1
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53
[2026-02-01T15:23:03:019Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:384 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     14: name:en0, type:wifi 
     14: name:en0, type:wifi 
     26: name:utun4, type:other
[2026-02-01T15:23:03:041Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:330 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
[2026-02-01T15:23:03:041Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:369 startNetworkMonitor() Setting fallback DNS to 192.168.1.1
(44978)[2026-02-01T15:22:54.074Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53

image
image1658×1106 66 KB

2

@dmuensterer and I have been been in communication on this topic via direct message. I just wanted to share a quick update here for the public, so anyone else who might be seeing the same issue can follow along or chime in.

The identities that are losing authentication are enrolled with the OpenZiti controller and authenticated with an external provider. Eventually the tunneler starts trying to use OpenZiti internal authentication for the identities, as can be seen in the log excerpt posted above. This is clearly a bug at one or more layers of the stack.

That’s all we really know at this point. We’ll try to start migrating our DM conversation to this thread. Thanks!

1 Like
3

Hi @dmuenster. We’ve been setting this issue aside while your other thread was explored. Since that has been resolved now I’d like to continue with this issue, assuming you’re still seeing it after squaring up your CAs on the controller. (I’m assuming that the macOS clients mentioned here are connecting to the same controller as the ziti-edge-tunnels in the other thread).

It’s definitely odd that Ziti Desktop Edge is preferring to use legacy authentication despite your controller being configured to use internal OIDC authentication. ziti-sdk-c 1.8.5 was relatively early in terms of oidc development, so it’s possible that you’re seeing a bug here that was unnoticed by us and already fixed in the current ziti-sdk-c release.

The next version of Ziti Desktop Edge for Mac (2.53) uses the same version of ziti-sdk-c as the ziti-edge-tunnels that are working for you. Our testing of 2.53 has been going well, and I’m getting ready to promote it to the App Store next week.

If you’re interested in trying 2.53 on any of your macOS hosts before it hits the App Store, I can send a test flight invitation to you. In order to do this you would need to use the Test Flight application from the macOS App Store, and I’d need your Apple ID email so I could send you an invitation.

Outside of trying the next version, the next thing I can think of here is to enable tlsuv/TRACE logging on a client so we can see details about the interactions between the tunneler and the controller.

Thanks!

1 Like
4

Hi Shawn,

thanks! Yes, would be nice to test the TestFlight version. I'll PM you my Apple associated email address!