Security

Hi,

I have my captive portal on an external IP because I want it to be reachable from all VLAN's where I need to use the portal, which could be in Networks behind different NAT routers etc. With IPv6 clients this is no problem, because their is never any NAT involved. But with IPv4 clients it looks like NAT is killing the Captive Portal athentication, which results in people authenticating and then  not having any access afterwards.

Is their any way to fix this? Or do I really have to prevent any NAT from being between the Captive Portal and the wireless clients that authenticate against it?

Jan Hugo Prins

Hi Jan,

Which code are you running on the controller? 

Is controller doing NAT for user VLANs or some other device?

What do you mean by people authenticating and not having access? Does user-role on Aruba controller get change?

I'm sorry, I forgot my default header:

Aruba 3200XM

ArubaOS 6.1.3.1

The corporate firewalls are doing the NAT for all the user networks.

The Aruba has interfaces in several VLAN's.

The major ones are:

Public frontend IP for RAP connectivity and CP

Services VLAN for connectivity to Radius servers and AD controllers.

And then the Aruba is directly attached to the customer vlan's to be able to push clients into their own network. Most of the problems are with clients doing only IPv4 in the guest VLAN, that is why I suspect NAT to be the cause of all the problems.

Normally I don't give the Aruba an IP address on the customer vlan because it simply doesn't need it. But if I don't do that on the guest vlan either, then the redirect to the portal is not working at all.

Jan Hugo Prins

Jan Hugo Prins

For now I have put the captive portal inside the guest vlan and now both IPv4 and IPv6 are working fine.

While I was tracing everything I have seen some really nasty things with respect to packet rewrites etc.

Jan Hugo

Jan,

I am asssuming that this is an external captive portal hosted on a web-server and once user is authenticated,  external CP server sends back the "user_add" command to the controller to change the user-role on the controller.

However, to send back the user_add command, server needs to initiate a session with the controller, which is not possible if controller is located behind NAT device.

Workaround:

On the firewall, which is doing NATing, put an ACL that will forward any HTTP or HTTPS session coming from external server to the controller.

Hi everyone,

I have tried to create a little drawing of the setup as it is intended. Some explanation:

The guest vlan speaks for itself. The default gateway in the guest vlan is 10.22.61.1 and the Aruba is either unnumbered or it has IP 10.22.61.4. If the interface in the guest vlan is unnumbered the client doesn't receive the redirection to the Captive portal. If the interface is numbered the client does receive this redirection but most of the time it is not able to reach the portal. And if it is able to reach the portal, logging in on the portal results in a Access Denied message. This last access denied was caused by a NAT rule on the corporate firewalls, at least if I understand the following log correct. 

May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  RX (sock) message of type 33, len 4672
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received Captive Portal/WISPr config request for 10.22.61.211
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received CP/WISPr cfg request from 10.22.61.211 0.0.0.0
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  cp_dns_ip = 95.130.233.47
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Opened CP customization file /flash/upload/custom/TC3-Guest-cp_prof/cpformat.txt
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  theme=1, logo=/auth/default1/logo.gif, logintext=/flash/upload/custom/TC3-Guest-cp_prof/logintext.html, policytext=/upload/custom/TC3-Guest-cp_prof/acceptableusepolicy.html
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  custom color=, background= login_page=/upload/custom/TC3-Guest-cp_prof/index.html welcome_page=/auth/welcome.html
May 29 17:42:13 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  ip=10.22.61.211, prof=TC3-Guest-cp_prof, essid=TC3GUEST, login=/upload/custom/TC3-Guest-cp_prof/index.html, wispr_enable=0
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  RX (sock) message of type 33, len 4672
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received Captive Portal/WISPr config request for 95.130.233.161
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received CP/WISPr cfg request from 95.130.233.161 95.130.233.47
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Tx message to Sibyte. Opcode = 17, msglen = 188
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  RX (sock) message of type 33, len 4672
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received Captive Portal/WISPr config request for 95.130.233.161
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Received CP/WISPr cfg request from 95.130.233.161 0.0.0.0
May 29 17:42:20 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Tx message to Sibyte. Opcode = 17, msglen = 188
May 29 17:42:41 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  Rx message 0/67108864, length 247 from 127.0.0.1:8345
May 29 17:42:41 aruba01 authmgr[1564]: <124004> <DBUG> <aruba01 172.30.27.1>  stm_message_handler : msg_type 3007

The Aruba is not routing between netwerks.

The default gateway of the aruba is the public interface.

The gateway to RFC1918 networks is the default gateway of the services network.

I'm currently thinking about changing this a little bit to a setup where the captive portal IP is in a seperate vlan which has full routing without any access list to the guest vlans. This routing will then still be done through the central firewalls but I can set this up in such a way that their will never be any access list between those vlans.

This would then be the next setup:

Jan Hugo Prins