Connecting the world…


Aruba WPA2 with MAC authentication

Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.

These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.

While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.

The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.

Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP= auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing

To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.

I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.

aaa profile "WA-Test_aaa_prof"
   initial-role "denyall"
   authentication-mac "MAC_auth_prof"
   mac-default-role "WA-Test_role"
   mac-server-group "MAC-auth_srv"
   authentication-dot1x "default-psk"

Wireless controllers – the discussion continues

There is already a lot said and written about wireless controllers and it’s architectures. During my recent holiday my thoughts were wandering about this subject. At the beginning we had the stand-alone access-points, which were all configured as unique identities. Choosing the correct channel and power level could be a challenge in dense environments, so everybody was happy with the centralized wireless controllers.

The centralized wireless controllers were the solution to manage channel and power allocation with their build in ARM functionalities. But also the centralized management of the entire wireless environment was a great improvement for the management burden of IT personnel. Key players, like Cisco Systems and Aruba Networks, adopted this architecture and developed some outstanding wireless controllers. Over time more and more feature were added to the controllers, like spectrum analysis, wireless intrusion prevention systems, L3 roaming and advanced reporting. For some features you have to buy a separate license or you should use dedicated software or hardware, but nonetheless you have a easy to manage and flexible wireless design.

Some people started to discuss this architecture and found some disadvantages, like availability and scalability. The access-points are all managed by a centralized wireless controller, but what happens if the controller goes down? Who much time does it take to failover to a backup wireless controller? What license construction do I need when I would like to implement a redundant wireless controller architecture? Why do I need to tunnel all traffic from the access-points to the wireless controller, before the data of wireless clients accesses the wired infrastructure? Isn’t this a disadvantage for latency, delay and jitter characteristics? What is the impact for the controller when tunneling all traffic and who can I scale the controller to the future? These are all valid questions and some vendors decided to develop another wireless architecture.

Maybe the most well-known is AeroHive with their controller less wireless architecture. The wireless controller functionality is integrated in the access-points, but the management is still centralized. Every access-point is operating as an autonomous entity, but all access-points communicate with each other to form a hive (in AeroHive terminology). All configuration and monitoring is done through a centralized management platform. The impact of access-points loosing their connection with the management platform is minimal. The access-points stay online and stay operational for wireless purposes. This means that the wireless environment doesn’t depend on one or more wireless controllers.

But is this the most ideal situation……. not in my opinion. A few weeks ago a customer couldn’t’ access this manager for a couple of days. No problem, because the wireless infrastructure kept working like a charm. However the customer wasn’t able to do any kind of management and monitoring. He couldn’t see what was happing on his wireless LAN and he couldn’t add additional guest users to the AP user database. The question at that moment was: “Do we keep using the wireless infrastructure without any kind of monitoring and management with all risks associated or do we physically shut down the wireless network by disabling the PoE on the switch ports?”

There are some more “disadvantages” for a controller less architecture. VLAN extension (to a remote location) is difficult. This can be accomplished by configuring GRE tunneling between the remote AP’s and the HQ AP’s. With GRE tunneling you can extend the corporate VLAN to remote locations. The remote AP is the source of the GRE tunnel and the HQ AP is the destination. Another topic is RADIUS authentication. In a controller less architecture every AP acts like a RADIUS client. This can have impact on your RADIUS server. For example a Windows Standard server has a limit of 50 RADIUS clients. This means that you have to use a Microsoft Enterprise or Data Center server. You can also configure RADIUS proxy on the wireless environment. This means that all RADIUS from the AP’s are routed to the a couple of designated AP’s, which act as RADIUS proxy. You should also keep in mind that all traffic is directly routed to the wired network at the access-point. If you are using different VLAN’s, you shouldn’t forget to tag this VLAN’s on the uplink connections to the access-points.

I was talking about disadvantages. The topics aren’t real disadvantages, but more design issues. The point that I am trying to make, is that even a controller less architecture is sometimes working as a controller based wireless architecture. Because building GRE tunnels from remote locations to central AP’s or using AP’s as RADIUS proxy behaves, in my opinion, as a controller based environment.

So the discussion of a controller based architecture, a controller less architecture with a separate manager or a controller less architecture with a virtual controller will continue and every vendor will be saying that his solution is the best. I am very curious about your thoughts on the different wireless architectures.

Please keep in mind, this article is based on my experience and opinion. Also note that I am NOT saying that the solutions of the different vendors aren’t good choices to build your wireless network. I am using and will be using the solutions from the mentioned vendors in this article. Every solution has its advantages and disadvantages. Just look at the requirements for your wireless networks and choose the best suitable solution.

Aruba: Split Tunnel with a RAP-5WN

Split Tunneling is technique, which is used very often in (SSL) VPN scenario’s. The RAP-5WN access points has multiple Ethernet ports to connect different components, like workstations or printers. You can configure the usual user roles and other settings on these Ethernet ports.

You can also configure Split Tunneling per Ethernet port. When using Split Tunneling the connected components received an IP address from the company DHCP server. By using access-control lists you can specify the traffic, which is tunnel through the RAP to the central controller. Traffic, which isn’t tunneled, is NAT’ted to the local network by using the IP address of the RAP on the local network.

The configuration example below shows you how to configure Split Tunneling for an Ethernet port on a RAP-5WN. I don’t show you the provision and creation of a VAP for the remote access points. I assume that the RAP is already provisioned and currently all traffic is tunneled to the central controller.

1. The first step involves the creation of the access-control list to specify the traffic to tunnel and the traffic to bridge locally. The access-list shows that the DHCP services (udp/67 and udp/68) and traffic to the network is tunnel to the central controller and all other traffic is locally bridged. This is the most important step when configuring Split Tunneling.

ip access-list session rap-split-tunnel-policy
any network any  permit
any any svc-dhcp  permit
any any any  route src-nat

2. Next you need to create a user role and associate the previously create access-list to the user role.

user-role rap-split-tunnel-port-role
access-list session rap-split-tunnel-policy

3. The user role needs to be tied to a AAA profile.

aaa profile “rap-split-tunnel-aaa_prof”
initial-role “rap-split-tunnel-port-role”

4. The following step contains the configuration of a wired-ap-profile.. The wired-ap-profile contains the VLAN information for the connected component, the forward-mode and you can enable/disable the Ethernet port. The configured wired-ap-profile puts the client in VLAN 50, enables the port and puts the port in Split Tunnel mode.

ap wired-ap-profile “rap-split-tunnel-wired-ap_prof”
forward-mode split-tunnel
switchport access vlan 50

5. You have all the basics configured and next you need to configure the Ethernet port profile. This profile combines the AAA profile and the wired-ap-profile.

ap wired-port-profile “rap-split-tunnel-wired-port_prof”
wired-ap-profile “rap-split-tunnel-wired-ap_prof”
no rap-backup
aaa-profile “rap-split-tunnel-aaa_prof”

6. The last step is to tie the wired-port-profile to the appropriate AP group. I configured a separate group for remote access points, called remote-o1. The configuration ties the wired-ap-profile to Ethernet 4 on the RAP-5WN.

ap-group “remote-01”
enet4-port-profile “rap-split-tunnel-wired-port_prof”

You are now ready to go!!