Auto-reconnect on edge desktop internet disconnect or reboot?

Hello, does the latest ziti desktop edge client from the App store automatically reconnect on an internet outage or after reboot?

If not, is there a recommended way to do this?

Also, after enrolling the Desktop Edge client and verifying the service is working, I don’t see the service name or details in the “Services” section of the GUI. Is this expected? Screenshot follows. Thanks!

It will automatically connect after an Internet outage but not after a reboot. One of our users has configured auto-connect using the command networksetup -connectpppoeservice "Ziti Desktop Edge"

Services that are dialable by this identity should show on the UI, but services that are hosted are not currently displayed (there’s an Issue for this)

Edit: scutil --nc start "Ziti Desktop Edge" can also be used to connect

Hi Dave,

Yup, this is a host service on the Mac running Ventura, so that issue makes sense for why the details aren’t showing, thanks for the link.

I tried the connectpppoeservice but the Ziti Desktop Edge (aka “ZDE”) hasn’t registered itself as a pppoeservice to begin with, so didn’t have any luck with that – the command succeeded but had no effect.

The scutil approach does work, but so far only when I also have a GUI login session running (ex: via remote desktop). If no GUI user is logged in, and I’m only logged in via ssh and run the command, it returns with no error code (rc: 0), but the status of the vpn service stays as disconnected.

The same is true if I set up a script with the scutil start command and put it into a launch daemon in /Library/LaunchDaemons/, launchctl bootstrap it to the system domain and enable it for auto start on boot. Then on reboot, I can see in the output that the command runs, does not return an error code, but Ziti remains in disconnected state.

There is probably some gating factor, like maybe logging in via GUI triggers some network dependency which Ziti needs to start and then Ziti can enter the connected state. Looking for a workaround because without Ziti being able to start automatically on boot there is a chicken/egg problem with how to access the machine to start Ziti so that we can access the machine remotely in the first place :slight_smile:

I’m looking at some other references, like wireguard, for how to start a daemon automatically at boot time (example link). I’ve tried this approach (steps 9 and 10) customized for Ziti and the scutil command and the only difference seems to be that the scutil --nc start command isn’t getting the VPN into connected state without that GUI session present.

Will see if I can find some other way…

Maybe Ziti Desktop Edge wasn’t designed to be run as a system daemon, and must have a GUI logged in user to run?

Ah, so there is per mac user enrollment state so that user A only connects to their user A enrollment(s), and user B will only connect to user B enrollment(s). And when a user logs out from the GUI, the VPN state immediately goes to a disconnected scutil configuration until the next person does a GUI login. Maybe there is a way to get shared enrollments across users, but the GUI login requirement would still be problematic.

Hmm. So it’s looking to me like the ability set up a ZDE macos system daemon might not be possible.

To get system daemon functionality, maybe I need to look at the Ziti edge tunneler, compiled for darwin, example: Also, I think I recall seeing a PR somewhere for ZET on Darwin ARM several months ago. Are there any plans to produce release binaries for that? I was hoping to use the Desktop Edge app to start with, but if there is no system daemon functionality and there is in ZET, then I’ll probably be trying that next on MacOS.

Yes - ZDE is sandboxed to the user, including the keys in the keychain. Quitting the GUI should not affect whether or not you stay connected to Ziti, though - there are two separate processes. Logging out the user will disconnect from Ziti.

I looked at the Sandbox entitlements to see if it looks straightforward to use a non-user directory for storing keys/identities, and all of the file-related entitlements require a logged-in user. These entitlements are required for the Apple app store. We’ve considered moving away from distributing via the app store but haven’t made that decision yet.

regarding ziti-edge-tunnel. @scareything, can you chime in here for viability on macOS?

Ah, ok, the entitlements requirement makes sense for the login/logout connection/disconnection observations, thanks.

I gave the Dawin x86_64 ZET a quick try on intel mac… It worked on command line as root nicely, but as soon as I stuck it in a launchdaemon process, it is aborting:

(3460)[        0.000]    INFO ziti-sdk:utils.c:173 ziti_log_set_level() set log level: root=3/INFO
(3460)[        0.000]    INFO ziti-edge-tunnel:instance-config.c:86 load_tunnel_status_from_file() Loading config file from /tmp/config.json
(3460)[        0.000]    INFO ziti-sdk:utils.c:173 ziti_log_set_level() set log level: root=3/INFO
/bin/sh: line 1:  3460 Abort trap: 6           ./ziti-edge-tunnel run -I identity/

This appears to be an issue having to do with re-use of a /tmp/config.json file. If I remove those files prior to startup of ZET in the launchctl daemon, so that it’s like it is starting for the first time every time, it works. There is probably a much better way to be doing this, but at least I have it working on boot now! :slight_smile:

The /Library/LaunchDaemons/com.startup.ziti.plist file I’m using is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
        <string>echo "Starting ZET at $(/bin/date)"; rm /tmp/config.json*; cd /var/root/ziti; ./ziti-edge-tunnel run -I identity/</string>

Then enabling it for boot auto-start with:

launchctl bootstrap system /Library/LaunchDaemons/com.startup.ziti.plist
launchctl enable system/com.startup.ziti