Wireless Access

Background

We are currently completing an Aruba deployment in a secure government network. One of the components we're deploying, is VIA. We're using 6.4.x AOS and VIA 2.3.x.

As part of planning/design, we've read the following documentation:

1. Aruba_VIA 2.x_UserGuide
2. ArubaOS 6.4.3.x User Guide
3. VIAAppNote

Having read those documents, it appeared to us as a team that TCP port 443 (HTTPs) was needed when performing checks from the client, to establish whether the client was on a trusted or untrusted network. We noted the following particularly in the VIAAppNote...

TCP 443
 used by the end user to download VIA client software
 used by the VIA client to download the latest VIA configuration
 used by the VIA client for trusted network and captive portal checks
 used for SSL fallback when UDP 4500 is blocked

And this comment in the Aruba_VIA 2.x_UserGuide...

TCP 443 - During the initializing phase, VIA uses HTTPS connections to perform trusted network and captive portal checks against the controller. It is mandatory that you enable port 443 on your network to allow VIA to perform these checks.

Overall, this implied that 443 was needed from the "inside" (for the Head check, which we understand) to establish that the client IS on the inside. But that it wasn't necesserily mandatory from the untrusted network if the following considerations were taken into account;

 The design and customer outright does not want to allow the capability for users to download the VIA software OR configuration from the outside (for a number of security reasons)
 We're not allowing any SSL fallback of any kind by design

It's quite possible this reasoning was wrong, which we've discovered under extended testing.

Initially, we setup allowing UDP 4500 from the outside firewall perspective. We checked connectivity through it using a laptop with a mobile-phone hotspot. This worked, so we assumed we were ok. Testing then continued where an administrator took a laptop home, and attempted to connect over domestic broadband/Wi-Fi. This didn't work. We made a change to the perimeter firewall (Cisco) to allow TCP 443, and it then worked. This seems very odd, and suggests there's something we don't know? Why would it work over a mobile-phone hotspot, when it doesn't work over a home-broadband/Wi-Fi router?

Note: We've tried more than 3 different domestic/home internet connections, and 3 different phone-hotspots. All the phone-hotspots work, and none of the home broadband circuits do (until we allow HTTPS).

This raises a couple of questions in our minds...

1. What specifically is it using HTTPS for on the outside at a detailed step-by-step technical level? Initial IKEv2 phase perhaps? Note that our use-case and need for it (HTTPS) will be VERY heavily scrutinized by the security testers, as any additional ports opened up are seen as a "risk" regardless of whatever other countermeasures are put in place.

2. The answer to the first question might answer this anyway of course. Why would we get success on a mobile-phone hotspot (more than 3 tested), vs. a home-broadband circuit (more than 3 tested)?

Any thoughts would be great!

Thanks.

I forgot to add, we also read the following link, but were still unclear as to the answer to the question I've outlined above.

http://community.arubanetworks.com/t5/Remote-Networking/VIA-what-port-needed-to-allow-on-firewall-for-VIA/td-p/6254

Thanks.

443 is required to check to see if the controller is "inside" or outside of the network.  The VIA client tries to reach the "inside" ip address of the controller on port 443 to check if it needs to launch or not.

I've chased this down recently for another government customer.  Short answer, TCP 443 is required to be open from the untrusted side as well.  The reason is, VIA does an HTTPS connection to that port initially as some sort of reachability test, before it tries to connect using IPsec.  *Why* this happens is kind of a long story and goes back to connection timeout values in Windows, because on its face it doesn't make a lot of sense.  I've asked the VIA team if this can be changed in the future, and they are talking it over.

Note that you don't need the actual controller to answer 443.  I've been told by the developers that no information is actually exchanged during this transaction - it's simply a test to see if a connection can be established.  So at least one of my customers is deploying a firewall that will answer on 443, but not actually allowing the connection through to the controller.

Thanks again with your help on this Jon. Project nearly complete!