Wireless Access

Hello all,

I'm working on a project to implement a remediation VLAN for clients connecting to our RAP-3's wired ports. A client connected to to a RAP-3 should land in our production network VLAN unless it fails to pass or respond via EAP-TLS 802.1x security used in conjuction with a ClearPass server.

I talked with Aruba support, and they claimed there was no VSA or configuration for changing VLANs for a wired port on an AP. Without getting to deep into the configuration, here's a chunk below.

user-role authenticated
 vlan *prod vlan*
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session ra-guard
 access-list session allowall
 access-list session v6-allowall

user-role remediation                             
 vlan *remediation vlan*                     
 access-list session global-sacl                  
 access-list session apprf-remediation-sacl       
 access-list session dhcp-acl                     
 access-list session dns-acl

ap wired-port-profile "remediation-dot1x"
   wired-ap-profile "vlanprod"
   aaa-profile "remediation"

ap wired-ap-profile "vlanprod"
   wired-ap-enable
   switchport access vlan *prod VLAN id*

The initial role is remediation, and the dot1x post auth role is authenticated. Clients that fail 802.1x remain in the remediation role and are placed in the remediation VLAN. Client that pass are then placed into the prod network. This is actually working pretty well despite one hiccup!

Our PCs that should pass authentication will land usually land in the remediation role/vlan for a few seconds and pull an IP in that network, then flip to the authenticated role and shortly after grab a production IP. This works consistently when unplugging/plugging in the cable, and shutting down and booting the PC back up.

The issue occurs when doing a reboot. About 50% of the time the PC will follow the same process as above and end up in the production VLAN with a production IP - no issues. The other 50% of the time, the PC will land in the remediation role, pull a remediation IP and keep it even after getting pushed to the authenticated role. The prod IP won't ping, the remediation IP won't ping, and an ip release/renew doesn't make the client pull a new IP in the production VLAN even though it shows that it's in the authenticated role. It's like it hangs out in some odd "limbo" state until the PC is either rebooted again, or the ethernet cable is unplugged/plugged in again. Aruba TAC hasn't been able to assist on why this is happening.

I think it has something to do with the ammount of time it takes for the client to drop out of the user-table (user idle-timeout)? If I reboot a client, then do an aaa user delete mac *macaddress* before it boots back up, it seems to consistently come up and land in the production role and pull a production IP without any issues.

I'm wondering if anyone else has run into this issue and has a solution. I'm also wondering if anyone else has implemented a remediation VLAN or similar configuration with RAP-3s and found success.

Thanks!

- Make the initial role a Captive Portal role that forces a user to a https://page with a message or optionally a login

- Make the 802.1x role "authenticated"

- Use the same VLAN for both.. on the wired port profile (not the role)

If a link comes up a user will get an ip address and be forced to the captive portal page.  If the user's device subsequently passes 802.1x authentication, their role will change to the default 802.1x role and the user will be able to pass traffic.

I am not sure how it can be done with multiple VLANs, unfortunately.

Hi cjoseph,

As much as I'd like to do that, there needs to be VLAN separation. This will apply to all sorts of different clients - thin clients, phones, Windows PC, Macbooks, etc. Our new remediation network has been created with the resources required to remediation company clients whose certs have expired, etc. Due to some of our more strict security requirements, hosts that are failing can't share the same IP range as our production network. Right now they're being dropped into the "denyall" role that blocks everything so clients that fail authentication don't get an IP at all.

I was able to implement a solution for this and thought I would share.

I removed the wired port configuration for E1 on the RAP-3, and this now works perfectly. Despite having NO VLAN assigned to E1, the correct VLAN seems to be pushed to the RAP by whatever role the client ends in. My configuration now looks more like this.

user-role authenticated
 vlan *prod vlan*
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session ra-guard
 access-list session allowall
 access-list session v6-allowall

user-role remediation                             
 vlan *remediation vlan*                     
 access-list session global-sacl                  
 access-list session apprf-remediation-sacl       
 access-list session dhcp-acl                     
 access-list session dns-acl

 access-list session remediation

ap wired-port-profile "remediation-dot1x"
   wired-ap-profile "vlanprod"
   aaa-profile "remediation"

ap wired-ap-profile "vlanprod"
   wired-ap-enable

Thanks all!