Help with Script - Don't deploy Package if on VPN

[vmalapati_mu]

Hello Jamfers,
Hope you are doing well.

Need your expertise/suggestion on one issue: we would like to deploy CiscoVPN to all users who are only connected on office LAN. The package shouldn't install when they are on VPN, this should give a pop-up to connect to Office LAN to install. How can this be achieved?

Thanks in advance.
VM

[patgmac]

You shouldn't need to script that. Scope your policy to only install when on your network segments.

[donmontalvo]

If you have many subnets would it work to have the script exit if the VPN app is open?

Might need to get creative on policy frequency if a computer runs the policy and exits without installing.

[sdagley]

@vmalapati_mu Do the client machines need to be connected to Office Lan to complete install, or are you just concerned about killing the VPN connection if the user is offsite and connected via VPN? Before our Jamf Pro system was upgraded to be accessible from the public Internet my approach was to wrap the VPN installer into a .pkg that dropped it in /var/tmp then run a postinstall script that checked to see if the VPN was active. If it was not, it ran the VPN installer then. If the VPN was active, it created a LaunchDaemon that would wait for the VPN to drop and run the installer then.

[tlarkin]

I don't think checking if the app is running is a good test, I have both my VPN clients running in the menu bar, but they are not connected at all

>>> from Cocoa import NSRunningApplication
>>> app = NSRunningApplication.runningApplicationsWithBundleIdentifier_('com.paloaltonetworks.GlobalProtect')
>>> app
(
    "<NSRunningApplication: 0x7fb5436211f0 (com.paloaltonetworks.GlobalProtect - 38103) LSASN:{hi=0x0;lo=0x318318}>"
)

So my clients are definitely running, but are idle. I would say to make this simple, try to access an internal app/site that is only available via VPN. If you have like an intranet home page or something a simple GET request to see if you can access the page would be enough of a test. Otherwise, you can go down the road of coding around subnet ranges or trying to use jamf network segments, and both of those have their own set of caveats

[sdagley]

By "if the VPN was active" I did mean that it had a tunnel open, not just that the VPN app was running. For the VPN my org uses that test involved querying the name of the active network service. The problem with testing for an internal only server is that if someone is on the office LAN then they would presumably be able to reach all internal resources whether or not the VPN was connected, so that's not necessarily a good test to determine if it's ok, or not ok, to install the VPN software.

[tlarkin]

@sdagley Yeah really there is no "great way" to do it, I was just tossing out ideas. Network segments and testing IP ranges can be unwieldy, testing network service may or may not work. Our VPN apps self update and notify the user there is an update and that is how we have been doing it. Some VPN clients have a binary included which you can poll for connection stats, but not all solutions have this.

It is similar to web conference software, the app may be running, but now can you tell if someone is on a conference call? This is why I also prompt users if the app is running, if not I silently patch. Worst case Ontario, I catch them when they reboot or run software update and reboot. Best case, they actually click on the prompt and quit and update.

EDIT - if your network is managed to this level, sometimes VPN subnet ranges are for VPN only, and separated from any type of Intranet. So, if that is the case, then you should know what subnets are available to what specific IP ranges.

[sdagley]

@tlarkin Agreed. I think we all go through some crazy gymnastics to avoid user abrasion, and this is definitely a case where there is no singular answer.

[tlarkin]

totally agree, which is why I just silently auto patch everything that I can with static policies/code. The user gets prompted, and our SLA is 30 days for patching. Right now we are hitting 95%-99% compliance rates with this model. So, it is not perfect, but I have data to back it up. So, that is what we are going with for now. I would need to look at my policy data, but I am going to bet (by spot checking jamf logs) 90% of my updates/patches are from the silent update policy. My users also rarely use self service and they prefer to have "IT just do it for them," which is also completely understandable, and I honestly agree with that approach more than anything else.

So, to sum it up, my answer is to just prompt the user their app is open and there is an update. If you want to get all crazy and track deferrals or end dates where it is forced, that is also doable as well. I have code for that, but am trying to avoid it for a better UX given we have pretty good results as is.

[vmalapati_mu]

@sdagley, I have a working package now where it is installing package from /var/tmp, however I am looking at more granular way to deploy package when user connected on office LAN, just to avoid any further interruption to service.

[tlarkin]

I would just prompt to quit the app if it is open, users can decide if they want to disconnect from VPN and update

[bcbackes]

I know this is an old post, however, wanted to comment on what I've just recently started doing. I have my package created with that places the installer in the tmp folder. Then, a preinstall script kicks off and uninstalls the previous version of AnyConnect if it's installed. Then a post install script kicks off the new version installer for AnyConnect. I did test deploying this out to a Mac on a VPN connection and I found that it killed the VPN connection during the uninstall. Then, when it finished the installation, it prompted the end user to connect to the VPN since we have it setup for always on VPN. I was able to reestablish that connection without any issues.