Wednesday, January 1, 2020

Aruba: Connectivity to Mobility Master for DMZ Deployments

I recently had the opportunity to deploy a remote worker solution using Aruba Mobility Controllers and Remote APs (RAPs). One of the first steps I took in preparing to deploy the solution was to download the Aruba Validated Reference Design, or VRD, for remote AP deployments. There was a lot of good information in that VRD, but it was a little dated. The VRD was written for ArubaOS 6.x deployments, and as a result didn't have any information about Mobility Master.

One thing the VRD does make clear is that for RAP deployments, the Mobility Controllers should be located in your DMZ. My deployment was going to use a cluster of three Mobility Controllers in a DMZ, managed by a Mobility Master that wasn't in the DMZ.

One thing that distinguishes Aruba from the "other" guys controllers is that they are configured with a Controller IP, or LMS-IP. This is the one IP interface on the controller that can terminate a connection with an AP. Because my controllers had to go in the DMZ, my Controller IP had to be an DMZ address. I don't know about your DMZ, by mine has only one way in and out, and that choke point didn't allow access to the internal network (which is good security design). The connection between my Mobility Controllers and my Mobility Master would have to be over a different interface than the DMZ one.

I initially setup my controllers with an IP for a management VLAN, and set port G0/0/0 to that VLAN. This was how I setup my connection to Mobility Master. From there, I created my DMZ interface on G0/0/4 and other settings. I made sure I had my static routes setup correctly, with default route going out the DMZ and a static route to my Mobility Master.

Now to change the Controller IP from my management VLAN to the DMZ address. As soon as I did that, my Mobility Master lost connectivity with the controllers! I thought it must have been a routing issue, but that wasn't the problem. The controllers would do an automatic config rollback and re-establish connectivity with Mobility Master, but every time I changed the Controller IP, connectivity to MM would break.

To see why the connection to MM was failing, I first had to understand what that connection looked like. The connection between Mobility Controllers and Mobility Master is an IPSec tunnel. That tunnel is established when performing the controller's initial setup through the serial port. During initial setup, you are asked for the IP address of the Mobility Master, and which method to authenticate with. If you are connecting to a Virtual Mobility Master, which I was, the two methods are PSK with IP, or PSK with MAC (where PSK stands for pre-shared key). If you choose PSK with IP, the initial setup uses the IP address of the Mobility Master entered earlier with the pre-shared key to establish the tunnel. At the Mobility Master side, you also enter the IP address of the controller and the same PSK.

This is where my problem was. Since the secure connection between the MC and MM was defined using the IP of the MC, that connection broke when changing the controller IP. To support my configuration, I had to switch the configuration to use PSK with MAC.

Using PSK with MAC is a little trickier than PSK with IP, because you have to pick the correct MAC addresses. Once you do though, it doesn't matter what you set for the Controller IP.

The moral of this story: If you plan on deploying Mobility Controllers in a DMZ for RAPs and need to use an interface for management that won't be the same as your Controller IP, use PSKwithMAC as your authentication method for setting up the connection to Mobility Master.