Security

I have a problem that I hope someone can help out with... it falls into the "we can't be the only company that wants to do this" category.  It seems, however, that the TAC does not have a solution at this time.


The Environment:
Currently, we have a master/standby pair and a local controller in DC1 and a local controller in DC2.  The master/standby are model 3600/3400 and the locals are model 7210.  AOS is v6.4.2.5.

DC1 has a CPPM publisher and DC2 has a CPPM subscriber.  CPPM is v6.5.1


The Goal:
(Note: Everything that I describe below is working fine with our current environment.  The problem will be described in the next section.)

We have several networks that only exist in our DCs that our branch APs use for various DMZ access.  Guest (SSID: GUEST), Developer access (SSID: DEV), and VIP access (SSID: VIP).

Guest is captive portal while DEV and VIP are Onboard.  Due to the differences in user privileges, the DEV and VIP connections require separate policies in CPPM - for example, different access times, # of allowed onboard devices, etc.  

The branch APs terminate on the 7200s and, thus, CPPM is able to categorize appropriately using the Aruba-Essid-Name attribute.

The Problem:
We are preparing to deploy 7005 and 70x0 controllers to several branches and need to retain the functionality of service categorization for the GUEST, DEV, and VIP connections.  Since the networks are only available on the DMZ network in the DCs, we need to tunnel them to the 7200s and continue to perform CPPM authentication.

When the L2 GRE tunnel is established, we lose the Aruba-Essid-Name attribute functionality since the client request becomes a standard wired Ethernet frame (NAS-Port-Type = Ethernet (15)).  When the request is sent to CPPM, it is not able to properly categorize the request since there is no Essid-Name included in the frame.  The only way to match the request is to modify an existing service profile and add the Ethernet (15) attribute, but then that does not give us the separate categorization that we require for the 3 separate networks!

As per TAC, we are not able to send any other attributes in the Ethernet frame to help us identify the request.  The only thing that we can do is use the NAD IP address as part of the service but that is not sufficient...

How are we able properly categorize the request?

#7210

My question is, are you using an untrusted tunnel to get users on a specific VLAN in the DMZ to authenticate?  If that is the case, why don't you make the tunnel trusted on both sides, assign the tunnel on the far side a VLAN number (but not to a port),  and create an SSID on the remote controller(s) that is just like your internal SSID, but puts users on that VLAN you created.

 

 

 

Colin,

 

Thank you for the response.  I did try that and I do get the desired FINAL result - the user is placed onto the correct VLAN/subnet, but the big problem with that is that there is no authentication via CPPM - this method just drops the user into the DMZ VLAN.

 

Am I reading your response correctly?

 

Thanks,

Rob.

 

Do you mean that the onboard process is not working?  The piece you described is the infrastructure or the transport piece.  Did you replicate a Captive Portal network at the remote site where the client's traffic is forwarded to CPPM for onboarding on top of that transport?

 

Correct, neither the onboard process nor the ClearPass captive portal are working across the tunnels. 

 

Actually, I can get the the captive portal to work if I set the DMZ (7200) controller to use a AAA wired profile and leave the DMZ side of the tunnel untrusted.  I ran into some strange MAC caching issues, but I didn't explore that too much further since it still leaves me with the Onboarding problem for the DEV and VIP users.

 

My original question was how to get CPPM to use the correct service and I know that infrastructure configuration is a large part of it, especially since GRE tunnel changes the framed request that CPPM sees.  That's why I tried to provide as much detail as possible

 

I appreciate your help on this!

 

When you just setup the transport, can your clients browse to the clear pass page? If they cannot, that is what needs to be figured out (routing to the primary?). Having multiple GRE tunnels is complicated and as you can see lack many attributes you would need to differentiate your users...

Colin,

 

Yes, if the GRE tunnel is setup as trusted on both ends, the client is able to reach the CPPM server if they manually browse to it.  Can you think of any other way to identify traffic coming across a specific tunnel that can be sent to CPPM?

 

Am I way out in left field with what I'm trying to accomplish?  Surely, we can't be the only company who's ever wanted to do something like this!

 

Thanks,

Rob.

Rcervantez,

 

Based on how you describe it, I don't think you are out in left field, but HOW you are trying to accomplish it might not work with untrusted GRE tunnels.  If you just wanted to authenticate users and tunnel them, you are already doing that.  You need to setup a AAA profile and Captive Portal profile to redirect them to the onboard page at that remote site.  Is this possible?

It's been a long time since I've updated this post, but I did want to provide some information so that others might gain some use from it in the future:

 

I did find a way to uniquely identify the traffic on a per-GRE Tunnel basis. I do have additional issues with the post-authentication roles, but that is something that I'm working on several possible workarounds with TAC and is out of scope for this post.

 

Although traffic coming through the GRE tunnel loses the Aruba-Essid-Name RADIUS attribute, there is another attribute that is introduced since it is now wired access traffic.  It is the Aruba-Port-Id attribute and consists of the following format: <ipaddr of dmz>:x/x/x 

For example, 10.10.10.123:1759/0/4

 

The numbers in the port seem to be random but are unique on a per-tunnel basis, so if we have multiple tunnels, we will see multiple Aruba-Port-Id values coming into CPPM.

 

You can then use that value to match to a Service profile.  It is not elegant but the value remains consistent through reboots, upgrades, etc.  Scaling this for some companies might be a problem... For example, we have 5 remote controllers, each with 3 GRE tunnels.  Those controllers have primary GRE tunnels to one data center and failover GRE tunnels to another data center DMZ controller.  This requires us to include 5 x 3 x 2 = 30 values in the CPPM Service Rule lookup!

 

Hopefully this helps someone in the future!

 

Rob.