Security

I have a master-local setup with a requirement for users to access a captive on each controller. There is a VRRP address running between the controllers acting as the DG for BYOD clients. My question is - do I configure the ip cp-redirect-address command to use the VRRP address (or the controllers static address) and is this a command that is part of the config that is syncd from the master to the local or do I configure it on each individual controller?

It is individual for each controller.

If you're using the "default" captive portal ACL, you don't need to do that.

 

Captive portal users should get redirected to the "controller" alias (version of code dependant), in the controller that is controlling the AP to which they are attached.

 

I.e. a user associated with an AP, will get redirected to the "controller" alias IP on the relevant controller at the time.

 

Try "show netdestination" in the controllers to see what this looks like if interested.

 

the.racking.money,

 

Sort of:.   By default users of the captive portal are redirected to the management ip address of the controller.  In most networks, the admins do NOT want the users to have access to the management ip address or the management address  is not routable to guest users.  The ip cp-redirect-address commands is used to point  user captive portal traffic to a different ip address on the controller that IS routable (usually the ip address of the guest VLAN on the controller).  The captive portal ACL and the netdestination are independent of this command.

That's interesting...

 

I usually don't worry about the "users to have access to the management ip address" part, because the captiveportal ACL redirects to the "magic" port (8081 as per below). And my understanding is the "magic port" doesn't respond to anything other than CP related requests? Therefore, it's not at risk from that perspective (admin abuse). Am I wrong in thinking this?

 

Also, if the customer queries about DOS attacks etc against the CP, I tighten this up with stateful-fw thresholds. Again, am I wrong about this?

 

ip access-list session captiveportal
  user   alias controller svc-https  dst-nat 8081
  user any svc-http  dst-nat 8080
  user any svc-https  dst-nat 8081
  user any svc-http-proxy1  dst-nat 8088
  user any svc-http-proxy2  dst-nat 8088
  user any svc-http-proxy3  dst-nat 8088
!

 

Obviously, everything else RFC1918 I block if that makes sense?

The.racking.monkey,

 

You might have a guest network with the ip address range 192.168.1.x and the default gateway is a cable modem, 192.168.1.254, and the controller's management ip address is 10.10.10.10.  The controller has an ip address of 192.168.1.1 on the guest subnet.  By default the guest users will be redirected to the 10.10.10.10 address, but the cable modem does not have a route to 10.10.10.10, so the users will never get the captive portal.  The solution is to change the ip cp-redirect-address to 192.168.1.1 so that guest users will be redirected to the routable interface on the controller to bring up the captive portal.

 

In short, this is the specific situation that the ip cp-redirect-address command is designed to solve.

Hi CJ,

 

Sure, I appreciate that consideration (routing to redirect IP).

 

I was probably mis-understanding your point  as follows "the admins do NOT want the users to have access to the management ip address".

 

What I was asking (off topic), is regardless of the specific IP used for this purpose, my understanding is that port 8081 doesn't respond to anything other than CP related requests? Therefore, it's not at risk from an "admin abuse/attack" point of view? Am I wrong in thinking this?

 

Try to hit your controller on a wired subnet on port 8081 and see what happens.

Good shout CJ. You know, I never actually tried that before!

 

Having tried it, I think I'm right (different browsers interpret it differently of course).

 

Thanks.

 

Sorry for hijacking your post MattF!

No problem - I'm always keen on following a thread - wherever it goes.

And if I have two captive portal profiles on the same controller, how I configure the ip cp-redirect-address?

The only rule is that users on both VLANs need to be able to reach the ip-cp-redirect address on the controller.  You only need one.

Thank you Colin,

But if a client is on VLAN x, cp-redirect-address is VLAN y, which captive portal/welcome page will be shown?

Yes, but you need to enable the "Allow Tri-session with DNAT" option if it does not work http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/Firewall_Roles/Global_Firewall_Paramete.htm

Hi Colin

We enabled  the "Allow Tri-session with DNAT" option, but the first Captive Portal presents the Welcome Page and the second CP doesn't appear Welcome Page. The client is trying the address https://captiveportal-login.mydomain.com/.../welcome.html but this server doesn't exist.

 

The command ip cp-redirect-address is point to the VLAN of first Captive Portal.

Can the user get to the page by typing the controller ip address?
Do all vlans have an IP address on the controller?

Can the user get to the page by typing the controller ip address?

Yes.

 

Do all vlans have an IP address on the controller?

Yes.

 

The initial role has this ACL, but the default role hasn't. Do I Need   this ACL after logon?

ip access-list session captiveportal

  user   alias controller svc-https  dst-nat 8081

  user any svc-http  dst-nat 8080

  user any svc-https  dst-nat 8081

  user any svc-http-proxy1  dst-nat 8088

  user any svc-http-proxy2  dst-nat 8088

  user any svc-http-proxy3  dst-nat 8088

Only the initial role needs that ACL.

 

Does the user get redirected to a URL?  Can the user resolve DNS?

 

Does the user get redirected to a URL? Yes  

Can the user resolve DNS? Yes 

 

When I change de "ip cp-redirect-address" to an ip of second VLAN, the second CP works and the first doesn't present the Welcome Page.

If you have not already, please open a TAC case in a parallel.  There could be something blocking your traffic from working in both situations...  Both sets of users should be able to route to the ip cp-redirect address.  The redirect URL should also be reachable by both sets of users.

Thank you Colin, I will open a TAC.