Security

Hello, I'm trying to determine if this configuration is possible via a single DMZ controller and single Guest CPPM.  I presently have master/local environment with a functioning L2GRE Guest overlay.  I need to add a second guest network into the environment and treat this second set of guest users differently than the first.  Ideally I'd like to leverage the same L2GRE tunnels/DMZ controllers with a second vlan added for these new guests. 

There are a few issues:

1) Terminating this second vlan on the DMZ controller is not an issue, however I have yet to determine how the DMZ controller can distiguish the incoming tunneled traffic to be sourced from either of the two guest networks.  This is the key piece.  Effectively I need to have the ability to identify this traffic on the controller and force it to two different initial roles which are tied to different captive portal URLs.

2) Present configuration has the DMZ controller with a leg in the same subnet as the guest CPPM, redirects work fine. Guest 1 VLAN in diagram  If 1) can be reconciled, I'm assuming I can use Stateful Firewall config Allow-tri-session with DNAT to redirect the Guest 2 vlan traffic to use the same CPPM interface that is in the Guest 1 vlan.  The firewalls hold the default gateways for the vlans.

One solution to this problem is obviously to build two DMZ controllers, one for Guest 1 and one for Guest 2 and redirect the traffic from the internal network to the appropriate DMZ controller.  I would still need to use the NAT command since the firewalls will still hold the default gateways for the vlans.  Obviously not ideal from a hardware/management perspective.

Thanks in advance for looking.

Some people, when they have a guest network tunneled to another controller make the "far" side untrusted and that is how they bring up the captive portal.  You can make the "far" side trusted, but make the initial role for the guests on the controller(s) that the access points terminate on, whatever you want.

Long story short, use the initial role on the wireless lan controller to put users in the captive portal role that you want them to be in.  Using that initial role in the AAA profile, you can have the "blue" users redirected to URL A and on the other controller the "red" users redirected to URL B.  Again, the DMZ controller will be trusted and its only job would be to terminate the GRE tunnel and forward traffic back and forth.  The WLC controllers will put users in their unauthenticated Captive Portal role, which will forward them to the URL you want them to be in.  A good side effect of this approach, instead of making the DMZ controller tunnel untrusted is that you will have visibility of what access points users are on.

I hope that makes sense.

It does, I've also been discussing with my SE.  He forwarded this article to me as well.  http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-do-I-redirect-guest-access-across-a-GRE-tunnel-to-a-DMZ/ta-p/183468  Based on the information you've both provided I'm looking to do the following:

1. On the internal controller((s) - there is more than one), have both SSIDs redirect to different AAA profiles with different captive portals.  There will be no layer 3 interfaces on the internal controllers.
2. Send all IP traffic (initial DHCP, DNS and captive portal traffic) down the GRE tunnel out to the DMZ for processing.
3. Have the DMZ controller forward all captive portal traffic to the external captive portal.  I'm unclear as to whether I need NAT yet.  I'll look into that once I have components 1) and 2) above configured.

Thanks!

Update - I've made some modifications to the configuration and have realized a few things:

1. Once L2 auth occurs you cannot place a user in role that redirect to a captive portal if that role is on the same controller as where the L2 auth occurred.  It never triggers.  I can understand why this would be the case, but an open SSID auth's as well, its simply a default allow and works in that scenario.
2. Once L2 auth occurs you cannot place a user in role that uses a redirect to a GRE tunnel.  User never redirects.
3. Once L2 auth occurs you CAN place a user in a role/vlan that redirects down the GRE tunnel (via the vlan derivation, not a redirect ACL).  The user shows up on the DMZ controller under the guest initial role, but at this point the guest initial role captive portal assignment does not work.

This is where I am.  I can see the user in an initial role state however I cannot seem to trigger an the initial role to use the captive portal.  I've used our production guest initial role and captive portal config for this testing (included below).

user-role SLF_TEST_Logon
captive-portal "11111_SLF_AAA_Dev"
access-list session global-sacl
access-list session apprf-SLF_TEST_Logon-sacl
access-list session captiveportal

***********never get to this role

user-role SLF_TEST_Authenticated_Guest
access-list session global-sacl
access-list session apprf-SLF_TEST_Authenticated_Guest-sacl

***********

aaa profile "default"
initial-role "SLF_TEST_Logon"
radius-accounting "SLF_Guest_DEV_Clearpass"
radius-interim-accounting
rfc-3576-server "x.x.x.x"
enforce-dhcp
!
aaa authentication captive-portal "11111_SLF_AAA_Dev"
default-role "SLF_TEST_Authenticated_Guest"
server-group "SLF_Guest_DEV_Clearpass"
redirect-pause 3
guest-logon
no logout-popup-window
protocol-http
show-fqdn
login-page "http://x.x.x.x/weblogin.php/4"
no enable-welcome-page
!
aaa authentication captive-portal "default"
!

At the end of the day, I need the initial user role on the DMZ controller to trigger the captive portal initiation. Any suggestions would be very helpful.

Updated diagram included, thanks in advance.

1.  What layer 2 authentication are you talking about?  I thought this was about captive portal authentication.

2.  Same question

- You should not use a role to redirect traffic.  You should instead just bridge the user traffic to an existing, routable tunnel.

Near side:

config t

interface tunnel 20

tunnel vlan 100

Other side:

config t

interface tunnel 20

tunnel vlan 100

VLAN 100 should have a routable address reachable to/from CPPM.

In your Virtual AP on the farside controller you just put VLAN 100, and be done with it.  As long as interface VLAN 100 on both controllers is a routable address that is reachable, you should be able to do this.

You may need consulting to get this done to your satisfaction.

Thanks Colin for the response, I'll try your suggestion.  I have the scenario detailed in the diagram.  For backgroud, the reason I'm trying to make this work is due to a requirement to support shared mobile devices for internal use.  User A may have mobile device 1 in the morning and user B may have it in the afternoon.  We need to auth the device first use EAP-TLS with a second auth for the user so that we can User A to device 1 in the morning, B in the afternoon.  This is an audit/compliance requirement.

Hi MAB,

Have you successfully fulfilled your requirements? 

Colin,

My scenario is similar, but my far end controllers are in a few different locations. The guest traffic are all L2 GRE tunneled back to DMZ controller. Tunnels on DMZ controller are untrusted to trigger the Guest mac authentication and then Captive Portal.

My issue: during the mac authentication, I have no way to tell the difference between guests from different remote sites... so CPPM can't return different roles to DMZ controller to splash guests to different portal catered for different locations.

Any idea?

Regards,

Peiyong

Pydiao,

You should make the DMZ controller trusted so that it is only supplying DHCP to users.  You should also redirect users to the captive portal on the controller that the access point is on, instead.  If you do that, CPPM will have the Aruba-Essid-Name attribute populated when you do mac authentication, and that will tell you what SSID the user is connecting to.  If you do the captive portal at the controller, instead of the untrusted interface of the DMZ, Airwave and other management systems will correctly list users on access points, since the user table will exist on the Wifi controller, instead of the DMZ controller.

I hope that makes sense.