Cisco AnyConnect 3.1.05152 reports different IP than JSS reports

perrycj
Contributor III

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.

2 ACCEPTED SOLUTIONS

nicktong
New Contributor III

@perrycj

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.

View solution in original post

mm2270
Legendary Contributor III

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.

View solution in original post

13 REPLIES 13

perrycj
Contributor III

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.

nicktong
New Contributor III

@perrycj

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.

perrycj
Contributor III

@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.

mm2270
Legendary Contributor III

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.

perrycj
Contributor III

@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.

mm2270
Legendary Contributor III

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.

perrycj
Contributor III

@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.

bradtchapman
Valued Contributor II

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.

bradtchapman
Valued Contributor II

@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.

  1. Add this script to the JSS (see below).
  2. Create a policy that runs this script on check-in and network state changes.
  3. Scope the policy to all computers.

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

nicktong
New Contributor III

@bradtchapman

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.

bradtchapman
Valued Contributor II

@nicktong , thanks!

Did you work with @garryfresh before leaving? My coworker is a friend of his.

mapurcel
Contributor III

is there a feature request that I could vote up?

bradtchapman
Valued Contributor II

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:

  • Junos Pulse
  • F5 Networks SSL VPN
  • Cisco AnyConnect

Then of course you have Apple's own L2TP VPN offering with the built-in server.