Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 

We’ve seen an increasing number of F5 customers who use (and love) APM asking for greater integration with their favorite Mobile Device Management systems, and now the first integration is here. We’re proud to launch this iApp to the DevCentral community, not only as a potentially useful tool in your APM bag of tricks, but also as an example of the ease with which you can use iApps and iRules to add virtually any type of functionality you can dream up to Access Policy Manager!

In the past, some of you have taken data from your MDM systems and imported it into data groups on your BIG-IP. This solution does still work, but you lose much of the real-time status of which modern MDM systems like MobileIron rely upon to keep their managed devices continually assessed for compliance to enterprise security policy. To truly ensure that we’re not admitting devices to the network that don’t comply (or, even worse, devices that aren’t even under our MDM’s management), we need our checks to be done as near real-time as possible.

Luckily, this is BIG-IP – the land of possibilities. And we have iRules and sideband connections!


Figure 1 – MobileIron integration in a nutshell (or a sideband, really).

MobileIron has an Application Programming Interface (API) that allows us to query for information about a connecting device and learn what the MobileIron VSP knows about it. Edge Client has the ability to inform APM of the connecting device’s MAC address – so we’ll connect the dots through a sideband connection and make the data from MobileIron’s API available for your access policy. First, a list of requirements:

  1. You’ll need to be running MobileIron VSP 5.5 or later, or be using the MobileIron Cloud VSP service. Earlier versions of VSP don’t support the API calls we’ll be doing.
  2. If you’re running a firewall between your BIG-IP and your MobileIron VSP or MobileIron Cloud instance, you should ensure that the BIG-IP can communicate to the VSP on port 443 through the firewall.
  3. Because we’re going to connect outward from the BIG-IP to a host, we’re going to use DNS to resolve the hostname every so often so we don’t have to reconfigure anything should you move your VSP. Because of this, the BIG-IP will need to be able to communicate to a resolver that knows the VSP’s hostname.
  4. It should go without saying, but you need to be licensed for APM at your BIG-IP.
  5. You need to create a user at your MobileIron VSP that has API rights. Consult your MobileIron documentation regarding how to accomplish this.
  6. Your BIG-IP needs a route defined to follow to reach the MobileIron VSP. Make sure your BIG-IP’s routing table has an entry that allows for this.

Got it? Firewall rules ready? Resolver identified? Versions verified? Great! Let’s get started.

Step 1: Use the iApp


Figure 2 – The MobileIron/APM iApp template (hosted Cloud mode)

Start by downloading the latest version of the iApp from here:

Once you have the iApp template installed, create a new application and select the template from the list. You will see a screen like the one in Figure 2. The iApp will assist you in creating both the sideband iRule we will use to send and receive information from MobileIron, and a “helper” virtual server that will be used to apply SSL encryption to the API queries we’ll be making from that iRule.

First, you’ll need to define what type of MobileIron infrastructure you’ll be using. There are two types: Standalone and Hosted. If you’re using the MobileIron Cloud VSP, select Hosted, otherwise your configuration will be using the Standalone type. If you select Hosted, you will choose your VSP hostname from the dropdown list; in Standalone mode, you’ll enter the hostname manually. If you selected Hosted, you will need to enter your MobileIron Cloud “Enterprise Name”. Your Enterprise Name is found in your MobileIron cloud container under Settings -> Preferences -> Enterprise Preferences. You must enter it exactly as it appears.

Next, you’ll need to enter the username and password for the API account you created to support this sideband connectivity. This will complete the setup related to MobileIron VSP.

We now need to collect information to allow us to configure the sideband helper. By default, the iApp will attempt to automatically assign an IP address for the sideband helper VS. It will choose a random IP address in the 192.168/16 range, but it won’t assign anything that it finds to be in use or visible on the network on any VLAN. In addition, it will remove this Virtual Server from all VLANs by default so that it cannot be used outside of the BIG-IP itself – this is okay because we’re only using it to handle self-initiated sideband connections OUTBOUND, so we don’t really want it to accept any inbound connections. If you’re uncomfortable letting the iApp pick an address, that’s no problem – just select “No” and configure your own.

As previously mentioned, we need a DNS resolver in order to query for the MobileIron VSP’s hostname. In a scenario where the VSP is internally hosted, you may want to configure an internal resolver in order to get an internal network address – that’s why this is a configurable option. Enter a single IP in the field provided (we’re not going to query for it very often, so a single server should be sufficient).

Finally, by default the BIG-IP will use a SNAT Automap address to initiate connections out to VSP (for those not aware, this will be one of the Self IP addresses on the interface that the BIG-IP follows to route the traffic to the destination). If for some reason you want to manually assign this address, you can select “No” and enter your own.

0151T000003d5b2QAA.png Figure 3 – iApp-created components

Once you’ve entered everything, all of the necessary components will be automatically created as shown in Figure 3. This includes the helper virtual (e.g., “customer1_mobileiron_cloud_sideband_80”), the actual APM event iRule (“mobileiron_apm_support”), and all supporting profiles. Now you’re ready to enable your existing APM virtual servers to understand how to talk to MobileIron.

Step 2: Enable MobileIron for your APM Virtual Server

0151T000003d5b3QAA.png Figure 4 – Add the created iRule to your existing APM virtual server

This is the easiest step to perform. For any APM virtual server that you want to be able to make outbound calls to MobileIron, you’ll need to enable the iRule we created via the iApp on it. To find it, look for the iRules created in the folder named the same as the name you gave the application, and select the one ending in “apm_support” (Figure 4). This will enable you to use certain iRule Agent Events in your access policy.

Don’t worry too much about applying the iRule before you’ve had a chance to work on your access policy! Because it contains nothing but ACCESS_POLICY_AGENT_EVENTs, it won’t be activated unless you tell it to do so in your access policy. Which brings us to…

Step 3: Construct/Modify an Access Policy to Use MobileIron

Now that you’ve attached the iRule, we need to create some access policy hooks to take advantage of our new API access. This is done by creating iRule Agent Events in your VPE. At the moment, there are four main actions you can perform (more will be added in future releases):

iRule EventWhat It Does

Wake up the MobileIron engine on the connecting device and prompt it to execute an inventory. Wake up success can be checked by examining the variables inside the “session.mobileiron.wakeup.*” tree.


Send a PNS message via the MobileIron infrastructure using the content set in the APM custom session variable "session.mobileiron.message.content". Message success can be checked by variables stored inside the “session.mobileiron.message.*” tree.


Retrieve all known device-level info previously collected by MobileIron VSP. This is the main information-gathering routine and will likely be the only one you need to call to check compliance status. The details will be stored inside “session.mobileiron.device.*”


Collect information about all apps loaded on the connecting device. This will return a full list of all applications on the device inside “session.mobileiron.inventory.*”  WARNING: The retrieved application inventory can be quite sizable and should NOT be pulled unless policy evaluation at APM absolutely requires it for a VPE decision.


These events will execute the sideband API call, and, if successful, will return an entire tree full of session variables for you to use in later VPE policy. Figure 5 demonstrates how to call the MobileIron check and verify the response:


Figure 5 – Calling the MobileIron connector from your access policy and verifying the return

In this example, we have a macro that executes the “mi_device_details” event in the iRule. This takes the “session.client.mac_address” value that Edge Client provides and queries MobileIron VSP for the information related to the device that’s registered with that MAC address. If the device is found, MobileIron will send back a list of all the device-level information that it has.

In Figure 5, you’ll also see an example of how we use the variables that return to us from MobileIron. We can easily check device compliance status by creating an “Empty” VPE action and using advanced TCL to see if the “session.mobileiron.device.compliance” score is equal to zero – that means the device is compliant. Any device fitting that description will then follow the “Compliant” macro branch. But that is, by no means, the only thing we can do.


Figure 6 – Data imported into APM directly from MobileIron appears as a session variable tree

What sort of data is available to us? Well, pretty much anything that MobileIron has collected. Here’s a small sampling:

  • session.mobileiron.device.compliance: The device’s current compliance level (a fully compliant device will show zero (0))
  • session.mobileiron.device.battery_life: The device’s last known battery level
  • session.mobileiron.device.principal: The username of the user to whom the device is registered within MobileIron
  • session.mobileiron.device.details.passcodepresent: A flag to indicate whether the user has set a passcode on the device

Cellular data type? Yes! Carrier? Yes! Remaining storage space? Yes! GPS Location? YES! And many more! You can see a few more in Figure 6, and the full list (and the values they can represent to you) are available to you directly from MobileIron.

That’s the end of Part 1.

In Part 2, we’ll look at some individual use cases and the policy you can construct with your new MobileIron VSP connector. Just to whet your appetite:

  1. Blocking attempts to log into the VPN if the username doesn’t match the user who initially registered the device with MobileIron.
  2. Warning users whose “home” carriers are different than the carrier we currently see them on that they may be subject to roaming charges while connected via VPN.
Historic F5 Account
Any ETA when part 2 will be released?



Thank you!
I tried this setup but APM does not get the client.session.mac_address variable from IOS device and therefore cannot get the compliance status from mobileiron. Only the UDID variable is transmitted from BIG-IP Edge Client (unique_id). Can somebody please tell me why APM does not get the mac ? Could it be that BIG-IP Edge Client 2.0.0 does not transmit it anymore ? I think it was removed in 1.0.5. Is this also the case for version 2.0.0 ?



Many Thanks.


I found that I needed to make some minor modifications to get this working with iOS 7 devices. I am using BIG-IP 11.3.0 and MobileIron VSP 5.9.



Whilst the MAC address is no longer accessible in iOS 7, the UDID still is.



To get this working you will need to first update the iRule, replacing references to the old session variable "session.client.ios.udid" with "session.client.unique_id".



You can then call the "mi_user_lookup_ios" iRule Agent event from within the VPE, rather than the events listed above.



Hoping that this is still actively being updated. I see a note about a change for iOS 7.



My question. Can this be used for an iOS client that is not using the F5 Edge client? I'm hoping I could use this without the Edge to validate that the device is registered with MobileIron and that it is in compliance.



Any additional information would be _Greatly_ appreciated!
What's the benefit of this? Doesn't Mobile Iron already have tools capable of finding compliant/non-compliant devices, etc.?
Regarding the question on the MobileIron complience.. That is exactly it. I have a virtual server and an application on the [mobile] device connects. I want to check with mobile iron to make sure that this device is known and in compliance. Of course I may also like to obtain from mobileiron some of the attributes that it maintains.



Now for an iOS device-- is it possible to obtain enough information to be able to make the query to the MobileIron -- for devices that aren't connected with the Edge VPN?



Maybe there is another/better method.. So I'm open to a good solution.. Thanks for the comment and for any help!
Any chance that a similar iApp is created for AirWatch MDM ? They also have API that can provide same info, so I assume it is a matter of make some adjustments to this iApp template ??
Part 2 would be goo.

This is a good explanation. Part 2 would be welcome.


But regardless of whether Part 2 arrives, it's important to note that the truly latest version of this iRule seems to have moved to github and is being developed by F5 employee Matthieu Dierick. See this DevCentral thread for more information.


Luckily this older Part 1 article still serves as a fairly good overview of how to use his much more up to date iApp.



do i need to install f5 edge client on th mobile device to get this to work



Yes Andrea, you do need to install and run the Edge client. The Edge client, because it is running as a native app, has the ability read and submit the device's UUID to APM. Mobile devices do not submit UUIDs when just browsing websites, so you will only get the UUID in the VPN scenario.



none of pass through it have error:


01070151:3: Rule [/Common/] error: /Common/ error: [parse error: PARSE syntax 706 {syntax error in expression " [HTTP::host] equals $static::abc-mobileiron_mi_host && [IP:...": variable references require preceding $}][{ [HTTP::host] equals $static::abc-mobileiron_mi_host && [IP::remote_addr] starts_with "127." }]


its does not support v13, neither ios 10 nor android 7



Is there a similar solution but for Google (Cloud) MDM (Chrome OS)?

Version history
Last update:
‎06-Feb-2013 07:00
Updated by: