IAP VPN Guest Solution With Captive Portal

After my last post about an IAP VPN, I’ve got a lot of questions regarding an IAP VPN guest solution, either with or without a captive portal. This post is all about an IAP VPN guest solution. I use a controller as the VPN concentrator and for the captive portal. You can use ClearPass for the captive portal as well.

This kind of solution is very handy if you need to provide a centralized guest access, e.g. with a controller in the DMZ. If you just need a tunnel for your clients back to a central site, follow this post instead:

Aruba Instant VPN with Central – IAP VPN

IAP VPN Guest: Controller Part

You need an Aruba controller. This controller needs to be reachable by all IAP’s using GRE. For the basic configuration, this controller does not need any licenses. But if you like to be more flexible, you need at least one AP and PEF license. This is just to enable the firewall and role features.

I also assume that the controller is able to transfer the guest traffic to the destination. In my setup, I use an L2 VLAN on the controller. So you need a firewall or at least a router who send the guests to the internet. You also need an external DHCP server. From my point of view, this makes the most sense, as the controller acts only as the VPN concentrator and provides the captive portal.

The first step is to build the GRE tunnel on the controller. Go to “Configuration–>Interfaces–>GRE Tunnels” and create a new GRE tunnel:

Choose a “Tunnel ID” and select “1” as the “Protocol”. Put in all the VLAN’s you need and make sure you check the “Enable” checkmark. Leave the “Trusted” checkmark unchecked. Select an IP for the “Tunnel source” and configure the “Tunnel destination”. This is the IP of the IAP. Make also sure, that the “Enable keepalive” switch is off:

If this is enabled, the tunnel will not come up.

It looks like this in the running config:

interface tunnel 1
    tunnel mode gre 1
    tunnel source 10.201.201.11
    tunnel destination 10.202.202.10
    tunnel vlan 205

The next step is to create a role with a captive portal configuration. I simply reuse the “guest-logon” role:

user-role guest-logon
    captive-portal "default"
    access-list session ra-guard
    access-list session logon-control
    access-list session captiveportal
    access-list session v6-logon-control
    access-list session captiveportal6

Here you can customize whatever you need to make this applicable to your environment. I will create a post later on, on how to create captive portal configurations on different platforms.

I use this role in an authentication profile for VLAN 205. VLAN 205 is in my case the guest VLAN.

aaa profile "CP_IAP_VPN"
    initial-role "guest-logon"

I was here lazy as well. This is just a copy of the default profile. I only changed the “initial-role” to the “guest-logon” role.

The next step is to apply this profile to the VLAN with the guests. In my case, it is VLAN 205. Go to “Configuration–>Interfaces–>VLANs” select an exsiting or create a new VLAN and add unter “More–>Wired LAN” the profile:

Or from the CLI:

vlan 205 wired aaa-profile "CP_IAP_VPN"

The VLAN has no other configuration and is a pure L2 VLAN, from the controller point of view. I assume, that the VLAN is mapped to a port on the controller.

To make a captive portal in this kind of scenario possible you need to allow three-way sessions. This is needed, as the controller is not the default gateway for the clients. Just head over to “Configuration–>Services–>Firewall” and search for the checkmark for “Allow tri-session with DNAT”:

It looks like this in the CLI:

firewall
    prohibit-ip-spoofing
    allow-tri-session
    attack-rate grat-arp 50 drop
    session-idle-timeout  16
    cp-bandwidth-contract untrusted-ucast 9765
    cp-bandwidth-contract untrusted-mcast 1953
    cp-bandwidth-contract trusted-ucast 65535
    cp-bandwidth-contract trusted-mcast 1953
    cp-bandwidth-contract route 976
    cp-bandwidth-contract sessmirr 976
    cp-bandwidth-contract vrrp 512
    cp-bandwidth-contract arp-traffic 976
    cp-bandwidth-contract l2-other 976
    cp-bandwidth-contract auth 976
    cp-bandwidth-contract ike 1953

With that, the controller is ready to handle the guests. Let’s configure the IAP and let the guests come.

IAP VPN Guest: The IAP Part

The IAP part is easy as well. The IAP just need IP connectivity to the controller. And NAT is not allowed between the IAP and the controller, as we use GRE for the tunnel.

To build the tunnel on the IAP go to “More–>VPN” and configure the tunnel:

From the “Protocol” drop down list select “Manual GRE” and enter the IP of the “Host”. The “GRE type” has to match the one on the controller. The “Per-AP tunnel” option can be enabled. This depends on your environment. If you just want one tunnel per IAP Cluster and if you can configure the VLAN for the guests between the IAP on the switches as a tagged VLAN you can disable this option. If the option is enabled, you need to create one tunnel per AP on the controller as well. Which could make it very complex.

Click “Next” to get to the “Enterprise Domains” page. As all the traffic is tunneled, you do not need to change anything here. This is important for split tunnel scenarios.

The next step is to create a DHCP scope for the VLAN. I knew this sounds strange, as I wrote above that we use the DHCP server in the DMZ, but before you judge me, wait for a second and read further.

To create a DHCP scope go to “More–>DHCP Server” and create a new “Centralized DHCP Scope”:

The options are very easy, just give the scope a “Name” and select “Centralized, L2” as the “Type”. This tells the IAP, that there is a DHCP server behind the tunnel and all DHCP requests are sent through the tunnel. You need to define the “VLAN” as well. Click “OK” to save the new scope.

The last step to get this working is to create a new SSID which use the scope from above. In this scenario, I use a very simple SSID configuration. To create a new SSID click “New” in the “Network” section of the IAP dashboard:

Configure the “Name” and select “Employee” for the “Primary Usage”. This sounds strange, but as we restrict access together with the captive portal on the controller, a simple “Employee” type of SSID is enough. Click “Next”:

The VLAN page is the important one. If you select “Virtual Controller managed” you can now select the created DHCP scope from above under “Custom”. This tells the IAP to send the traffic for this SSID through the tunnel. Click “Next”:

For most guest networks, the SSID is open. So is mine. If you need different security settings, you can configure them here. But remember, any kind of authentication is done at the controller. The only setting, which might make sense is a PSK to protect the SSID from unknown guests if needed. Click “Next”.

The last page is “Access”. Leave everything default, as access is restricted at the controller. Click “Finish” to save the new SSID. And thats it.

Let’s see how it looks like.

The client connects to the SSID in the IAP in the branch:

# show clients

Client List
-----------
Name             IP Address     MAC Address        OS    ESSID         Access Point       Channel  Type  Role          IPv6 Address  Signal    Speed (mbps)  
----             ----------     -----------        --    -----         ------------       -------  ----  ----          ------------  ------    ------------  
FlorianBPArbeit  10.205.205.11  78:4f:43:9d:ce:fc  OS X  Guest_Access  94:b4:0f:cb:75:cc  52E      AC    Guest_Access  --            39(good)  866(good)

On the controller it looks like this:

#show user-table 

Users
-----
    IP              MAC            Name     Role         Age(d:h:m)  Auth  VPN link  AP name   Roaming  Essid/Bssid/Phy  Profile     Forward mode  Type  Host Name  User Type
----------     ------------       ------    ----         ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------
10.205.205.11  78:4f:43:9d:ce:fc            guest-logon  00:00:00                    tunnel 9  Wired                     CP_IAP_VPN  tunnel        OS X             WIRED

Here is the important part. The user has the “guest-logon” role, which we configured above on the controller. This role redirects the user to the local captive portal. So on my MacBook, it looks like this:

After the user enters the credentials, the role is changed. But only on the controller. On the IAP is no change at all. But on the Controller:

#show user-table 

Users
-----
    IP              MAC            Name     Role      Age(d:h:m)  Auth  VPN link  AP name   Roaming  Essid/Bssid/Phy  Profile     Forward mode  Type  Host Name  User Type
----------     ------------       ------    ----      ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------
10.205.205.11  78:4f:43:9d:ce:fc  florian   guest     00:00:03    Web             tunnel 9  Wired                     CP_IAP_VPN  tunnel        OS X             WIRED

The user has no full access or at least access in the boundaries of the applied role.

You can extend this and use ClearPass for the captive portal as well. And then you can decide whether to redirect on the controller or on the IAP. If you redirect on the IAP, you can use the automatic Aruba IPSec VPN again, from my previous post, mentioned at the beginning of this post.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.