Posted on 06-30-2014 12:52 PM
Hey guys..so this is a bit of a weird issue. Basically, we are migrating to use Cisco AnyConnect v. 3.1.05152 as our VPN solution. Problem is, the JSS (8.73 and 9.32) does not grab the IP address AnyConnect broadcasts.
Instead, the JSS, both/either version(s), grabs the IP address in system preferences > network and displays that as inventory information. Even if the JSS has a forced check in from terminal, it still only grabs the IP there and not the one actually being broadcasted by AnyConnect.
For example, IP A and B are being displaying in system preferences and are usually from the user's home router or where ever they are. AnyConnect is displaying IP Address C and it is not being caught at all by the JSS. Therefore, when you try to remote into any Mac with Casper Remote, it tries to SSH through their home network IP (i.e.; 192.168.1.10 or 10.1.0.10) instead of the corporate IP. IP Address C aka the IP from the AnyConnect client isn't getting to the JSS at all.
Has anyone seen this at all? I opened a case with JAMF but they don't have a solution as of now. Any help would be appreciated.
Solved! Go to Solution.
Posted on 06-30-2014 02:03 PM
This happens because AnyConnect creates user tunnels (UTUNs) and the jamfagent only reports actual network interfaces and not UTUNs.
If we run ifconfig while connected via AnyConnect, you'll see an entry for, most likely, utun0 – this will have the client's VPN IP address that you are looking for.
You could also get the client's VPN IP address using the AnyConnect client itself, as in the below extension attribute script (which would would ensure we get the client's AnyConnect IP address and eliminate the risk that we might pull the IP address of the wrong UTUN if using ifconfig because there can exist multiple tunnels per actual interface):
#!/bin/bash
clientIPV4=$(/opt/cisco/anyconnect/bin/vpn stats | grep "Client Address (IPv4):" | awk '{print $4}')
if [[ "$clientIPV4" != "" ]]; then
echo "<result>$clientIPV4</result>"
else
echo "<result>NON-VPN</result>"
fi
Because the IP address field of the computer record is updated at each check-in, and extension attributes like the above are updated only at each recon inventory, we are more likely to have stale information in the extension attribute.
Posted on 06-30-2014 02:40 PM
I hear you on this. I wasn't implying the workaround was at all easy or intuitive. I actually seem to recall seeing some info that Casper Suite 9 now reports on "actual" IP as opposed to reported IP, or something like that, but it may be that Casper Remote is still using the other IP that isn't the actual one it can connect to. Have you seen if there is an existing Feature Request already to address this? If there isn't, it would be a good idea to add one. I'm not certain if its even possible for Casper to get the right IP under the user tunnels scenario as @nicktong describes, but perhaps.
Posted on 06-30-2014 01:00 PM
More details....production JSS is 8.73 and pre-production in a brand new environment is 9.32. Have tested with both. This seems to happen on both 10.8.x and 10.9.x clients.
Posted on 06-30-2014 02:03 PM
This happens because AnyConnect creates user tunnels (UTUNs) and the jamfagent only reports actual network interfaces and not UTUNs.
If we run ifconfig while connected via AnyConnect, you'll see an entry for, most likely, utun0 – this will have the client's VPN IP address that you are looking for.
You could also get the client's VPN IP address using the AnyConnect client itself, as in the below extension attribute script (which would would ensure we get the client's AnyConnect IP address and eliminate the risk that we might pull the IP address of the wrong UTUN if using ifconfig because there can exist multiple tunnels per actual interface):
#!/bin/bash
clientIPV4=$(/opt/cisco/anyconnect/bin/vpn stats | grep "Client Address (IPv4):" | awk '{print $4}')
if [[ "$clientIPV4" != "" ]]; then
echo "<result>$clientIPV4</result>"
else
echo "<result>NON-VPN</result>"
fi
Because the IP address field of the computer record is updated at each check-in, and extension attributes like the above are updated only at each recon inventory, we are more likely to have stale information in the extension attribute.
Posted on 06-30-2014 02:23 PM
@nicktong][/url Thanks so much for the info. I figured it was something like that.
The problem is getting the IP address from AnyConnect into Casper Remote. Based off what you said, I'm assuming that isn't possible?
I know how to get it from the client itself but I'll also employ this EA you provided to show it in computer info when looked up in the JSS web app. Thanks again.
Posted on 06-30-2014 02:31 PM
Yeah, although its certainly possible to report on the actual IP in an Extension Attribute, Casper Remote will not use that, and as far as I know, there is no way to make Casper Remote use a different IP than what Casper natively captures.
However, if Casper Remote fails, there is always ssh and ScreenSharing, both of which may work in this state. Since the Mac should be operating as if within the network, you may be able to initiate a ScreenSharing session. But assuming this even works for you, the session will not get logged into the JSS as it would with Remote.
Posted on 06-30-2014 02:36 PM
@mm2270 yea screen sharing works fine, as long as I use AnyConnect's IP.
We are deploying, or really, have deployed AnyConnect widely throughout our environment and this is more for our support team who use Remote on occasion. We try to keep it as simple as we can for them but if someone is using AnyConnect for VPN, then Remote is a no go. They just see it as failing and aren't really able to do ssh through command line or anything.
Posted on 06-30-2014 02:40 PM
I hear you on this. I wasn't implying the workaround was at all easy or intuitive. I actually seem to recall seeing some info that Casper Suite 9 now reports on "actual" IP as opposed to reported IP, or something like that, but it may be that Casper Remote is still using the other IP that isn't the actual one it can connect to. Have you seen if there is an existing Feature Request already to address this? If there isn't, it would be a good idea to add one. I'm not certain if its even possible for Casper to get the right IP under the user tunnels scenario as @nicktong describes, but perhaps.
Posted on 06-30-2014 02:43 PM
@mm2270 yea I know ha.
When I contacted JAMF, they didn't have an answer (as of now). I opened a case with them and I'll put in a feature request as well. Thanks.
Posted on 09-04-2016 12:44 PM
This still hasn't been fixed.
It would be trivial for JAMF to implement one of several methods put on display in JAMF Nation. Something so important as obtaining the client's correct IP address should have been implemented a LONG time ago, like way back in Casper 8.
Posted on 09-04-2016 09:46 PM
@nicktong, thanks for your suggestion about how to find the current IP address.
I've devised the following script to update the IP address with the current VPN IP address using the API, but only if the VPN is connected. This technique requires Cisco AnyConnect; you'll need to modify it for your preferred VPN solution if there is a command-line utility available.
To be effective this policy needs to run as soon as possible and as often as possible. Since we're not doing a full inventory update, this will not be resource intensive on the JSS.
#!/bin/sh
vpn_ip=$(/opt/cisco/anyconnect/bin/vpn stats | grep "Client Address (IPv4)" | awk '{ print $NF }')
udid=$(/usr/sbin/system_profiler SPHardwareDataType | grep UUID | awk 'BEGIN { FS = " " } ; { print $3 }')
jss_url=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url)
if [[ -z $vpn_ip ]]; then
echo “Not Connected to VPN”; exit 0;
else
curl "$jss_url"JSSResource/computers/udid/$udid --user "apiuser:password" -H "Content-Type: text/xml" -X PUT -d "<computer><general><ip_address>$vpn_ip</ip_address></general></computer>"
fi
Posted on 09-04-2016 11:16 PM
That's cool, basing it on network state changes.
Small world, I also ran Casper and the Macs at Mattel - 2010 to 2012 was my tour of duty there.
Posted on 09-05-2016 05:36 PM
@nicktong , thanks!
Did you work with @garryfresh before leaving? My coworker is a friend of his.
Posted on 07-05-2017 10:57 AM
is there a feature request that I could vote up?
Posted on 07-05-2017 11:05 AM
The VPN thing has been an outstanding issue for a long time. The main problem is that each solution uses a slightly different means of connecting to the network and setting up the network interface, which means that detecting the IP address would be somewhat unreliable.
FYI, there are 3 big players in the enterprise VPN space:
Then of course you have Apple's own L2TP VPN offering with the built-in server.