"launch at login" doesn't auto-connect previous used profile after reboot

[efef]

the previous macOS Appstore App, when "launch at login" was enabled, did auto-connect the previous used VPN profile after a macOS reboot.

The current 3.0.2 app does start the eduVPN app, but doesn't automatically connect the VPN profile that was active before reboot.

maybe it is because of the #431 change

[roop]

@efef:

the previous macOS Appstore App, when "launch at login" was enabled, did auto-connect the previous used VPN profile after a macOS reboot.

Looking at the code, it looks like that was the behaviour even before #431. The app always turned the tunnel off and unset on-demand on exit (which also applied on shutdown / restart), so it wouldn't auto-connect on reboot.

Commit 53d9ac1 (from PR #114) added a prompt to check, but before that, it simply disconnects the VPN and quits.

Now, because we don't ask the user on shutdown / reboot, do we want to keep track of what we were connected to previously and automatically connect back? Should we ask the user if he wants to connect (I think no)? Should we do it only if auto-launched on login (I think yes)?

[efef]

thanks for looking at this.
Maybe I was confused because the windows app automatically connects after a reboot to the last used VPN profile.
Would be appreciated if the macOS app also auto connects the before-boot active VPN profile. So I agree with the answers you thought.

[roop]

Okay, thanks for confirming.

When auto-connecting like that, should we just reuse the last-used OpenVPN / WireGuard config, or should we follow the API flow?

Doing the API flow would take time, so the system would be unprotected at that time. However, if we don't use the API, there's a chance that the config has expired / revoked, so it might not work. I think we should just use the last-used config (because turning on the VPN asap should be the priority).

If re-using the config is ok, I can explore if we can turn off the tunnel and leave on-demand on when quitting the app for a shutdown. (That might be a problem if multiple users are using the Mac, but I think we’re not worried about that use case, right?)

[ghost]

Regarding whether or not to call the API on disconnect we have this document describing it:

https://github.com/eduvpn/documentation/blob/v3/API.md#disconnect

Perhaps the wording here is not clear? We could improve it there and specify more precisely when /disconnect is called? To me it seems pretty clear though...

[ghost]

To clarify, there is no configuration available on the next application start to (re)use:

• the application calls /disconnect when the user manually stops the VPN and thus deletes/invalidates the config
• the application calls /disconnect when the application quits (either by user action, or system reboot) and thus deletes/invalidates the config

So the only reason you still MAY have a config lingering around (that is still valid on the server) is when the application crashes, or the network is somehow unavailable to reach the API endpoint for the /disconnect call.

Whether or not you re-use existing configs is irrelevant for this discussion. If there is any desire to reuse existing configs across application restarts/reboots/user disconnect events, that should then be a new issue...

[roop]

• the application calls /disconnect when the application quits (either by user action, or system reboot) and thus deletes/invalidates the config

The "/disconnect" documentation says:

However, it MUST be called on "application exit" when the user closes the VPN application without disconnecting first, unless the VPN connection can also be persisted outside the VPN application.

In this case, the user did not close the VPN application. It was closed by the OS because the user shutdown the machine. The user might or might not be aware of our VPN app at the time of shutdown. The VPN connection can actually be persisted outside of our app in this case, and whether we should do that or not is what I want to discuss. So from the documentation, it's not clear what the behaviour should be for shutdown / restart, and it's better we discuss it explicitly before I implement it.

Another part of the documentation says:

if the application implements some kind of "auto connect" on (device or application) start-up that of course MUST call /info and /connect as well! The /info call to be sure the profile is still available (for the user) and the /connect to obtain a configuration. This does NOT apply when the application configures a "system VPN" that also runs without the VPN application being active.

The current issue is about auto connect at device startup, in the scenario where the VPN was on when the device was shutdown. It's not clear from the documentation what the app should do, and I'd like to discuss what is required first.

I think we have two options on what the app can do in the scenario where the machine is shutting down and launch-at-login is enabled:

1. Before shutdown, turn off the VPN (without asking the user), remove on-demand, and call "/disconnect" (without waiting for the server response). When launched at login, open the app window (currently, the window remains hidden) and start the connection flow from the beginning ("/info", then "/connect").

   • Disadvantages:
     • Any network access at startup (by the OS or by other apps launched at login) will not go through the VPN.

2. On shutdown, don't turn off the VPN's on-demand and let the app exit. When launched at login, keep the window hidden. The VPN will be started automatically by the OS when necessary using the last-used configuration, because of on-demand. (So this means restart will behave similar to sleep/wake.)

   • Disadvatanges:
     • The configuration might not be valid at restart time
     • The configuration might remain unreleased for an extended period of time
     • Sometimes, on shutdown, our app might quit, but some other app might block the shutdown, so we'll be left in a state where the app is not running but the VPN is on.

(If launch at login is disabled while the device is shutting down, we should just turn off the VPN and quit without asking the user. The VPN will not be auto-connected when the app launches next time.)

@fkooman: I think you prefer Option 1, but I want to discuss our options before I implement something.

[ghost]

In this case, the user did not close the VPN application. It was closed by the OS because the user shutdown the machine. The user might or might not be aware of our VPN app at the time of shutdown.

It was always intended that when the OS closes the app, it should also stop the VPN (on application exit). I'll clarify the text.

Yes, clearly option (1) is what is desired, particular for this reason: "The configuration might remain unreleased for an extended period of time", this is important for WireGuard.

Any network access at startup (by the OS or by other apps launched at login) will not go through the VPN.

Well, on macOS (and iOS?) most traffic to Apple services will go outside the VPN, no matter what. If you want no traffic to leak you need e.g. a wireless access point that sends all traffic over a VPN where macOS/iOS can't override it. So we can forget about this "leakage", nothing you can really do about it.

If the VPN is to be active across reboots, i.e. without user interaction or the launching of the app we should call that a system VPN and this either has to be an explicit step taken by the device administrators, or the user, never automatically.

On shutdown, don't turn off the VPN's on-demand and let the app exit.

We implement "on demand" on macOS/iOS only because of bugs in the Tunnelkit implementation, right? Normally this is not something we'd need and does not apply to WireGuard if I am not mistaken? Also something like "on demand" should be a user / admin choice, not the default (if the VPN works properly).

[ghost]

eduvpn/documentation@6d1f370

[roop]

Yes, clearly option (1) is what is desired, particular for this reason: "The configuration might remain unreleased for an extended period of time", this is important for WireGuard.

Okay, we'll go with option (1).

Well, on macOS (and iOS?) most traffic to Apple services will go outside the VPN, no matter what.

Some of Apple's network access seems to bypass content-filter apps (that use the Content Filter Provider API). From what I've heard, it does not seem to bypass apps like ours that use the Packet Tunnel Provider API.

If the VPN is to be active across reboots, i.e. without user interaction or the launching of the app we should call that a system VPN and this either has to be an explicit step taken by the device administrators, or the user, never automatically.

Thanks for clarifying that for me.

We implement "on demand" on macOS/iOS only because of bugs in the Tunnelkit implementation, right? Normally this is not something we'd need and does not apply to WireGuard if I am not mistaken? Also something like "on demand" should be a user / admin choice, not the default (if the VPN works properly).

I'm not sure if we can call it a bug. That's how TunnelKit is designed. For consistency we use the same for our WireGuard tunnels as well. I think this is an unintended use of on-demand, but not harmful per-se. (If it was a few years back, I would have called it "abusing of on-demand".) Also, setting on-demand on shutdown is probably the only way ensure the device's during-startup network access goes through the VPN.