Clients are reporting a loopback address as the "Reported IP Address", causing Casper Remote to fail


Hi all,

For some reason, when a computer checks in to the JSS and there are multiple loopback addresses, the JSS picks up one of the loopback addresses from lo0 instead of the address listed for en0 or en1 as you would expect. We run OpenVPN, and some combination of that + Apple's implementation automatically adds loopback addresses from /etc/hosts as an alias in the network configuration.

Here are the loopback addresses on my computer from running ifconfig:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet netmask 0xff000000
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet netmask 0xff000000
inet netmask 0xff000000
inet netmask 0xff000000
nd6 options=1<PERFORMNUD>

My computer picks up instead of the expected address handed out by our DHCP server. This seems like a jamf agent bug to me - shouldn't it ignore the lo0 interface and go straight to en0 or en1? Is anyone else running into this issue?



Release Candidate Programs Tester

Which version of the JSS?

Contributor III

we've struggled with this as well. From what we've been able to figure out, OpenVPN relies on that loopback adapter as part of it's functionality, and logically has to sit in front of all the actual physical interface to function.

It's cosmetically quite ugly, it doesn't cause any issues when pulling policies from the JSS, which are client-initiated. Functionally, the issue is with trying to connect or push a policy through Casper Remote, because of that Reported IP Address, Casper Remote will keep trying to connect to that IP first, before it eventually gives up and moves onto the next IP, which takes quite a bit of time.

We've spent the time to isolate it, but we haven't really had much support from Casper on this issue.


@bentoms We're running 9.63.

@htse - Just heard back from my Account Manager, and there is indeed an open defect for this:

D-007695: Inventory on machines with OpenVPN installed incorrectly show Reported IP as

It's scheduled to be fixed in the next release, so I guess we'll have to hang tight until then.