IAP VPN Guest Solution With Captive Portal

Reading Time: 7 minutes

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:

IAP VPN Guest - Create a GRE Tunnel on the Controller
IAP VPN Guest – Create a GRE Tunnel on the Controller

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:

IAP VPN Guest - Create a GRE Tunnel on the Controller Keepalive
IAP VPN Guest – Create a GRE Tunnel on the Controller Keepalive

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
    tunnel destination
    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:

IAP VPN Guest - Add Profile to VLAN
IAP VPN Guest – Add Profile to VLAN

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”:

IAP VPN Guest - Allow-Tri-Session
IAP VPN Guest – Allow-Tri-Session

It looks like this in the CLI:

    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:

IAP VPN Guest - Configure GRE on the IAP
IAP VPN Guest – Configure GRE on the IAP

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”:

IAP VPN Guest - Add Centralized DHCP Scope
IAP VPN Guest – Add 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:

IAP VPN Guest - WLAN Settings
IAP VPN Guest – WLAN Settings

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”:

IAP VPN Guest - Security
IAP VPN Guest – Security

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  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 

    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
----------     ------------       ------    ----         ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------  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:

IAP VPN Guest - Captive Portal
IAP VPN Guest – Captive Portal

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 

    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
----------     ------------       ------    ----      ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------  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.

14 thoughts on “IAP VPN Guest Solution With Captive Portal”

    • Hi Hannan,

      Not sure, if this is really comparable, as I talked about a Site2Site VPN in order to connect clients to specific in-house location. The offering from purevpn looks more like a cloud solution.


  1. Hi Florian,

    Great article to begin with! I have a problem with the guest network when clients are trying to connect to it! The only AP that will leases out IP addresses is the Virtual controller, the others cant do that (the switches between them are these dummy switches which cant be configured)! So how is this solution usable to my case! Can I create a tunnel between these APs and the Virtual Controller AP (OBS. same cluster)? The only thing I need right now is something that can forward DHCP queries from APs to the virtual controller and then receive the replies back to the AP again?

    thanks in advance

    • Hi Nik,

      first of all, thanks for your comment and the feedback. Really appreciated.

      Currently, I do not get what you really have. The article is about a central controller, which can handle the traffic and the IAP’s are creating tunnels to this controller. Do you have a controller?
      If yes, you simply need to enable the “per-ap-tunnel” option. than all AP’s will build a tunnel to the controller and the dummy switches can stay dummy 🙂
      If you do not have a central controller, you have two options. First, replace all switches to be able to create VLAN’s, or secondly, you can use the Magic VLAN. The magic VLAN does not need tagging but will forward DHCP request to the virtual controller. You do not even need to create, it is already there. While creating the SSID, you need to select “Virtual Controller Assigned” and “default” on the “VLAN Assignment” Page.
      Afterward, your clients should get an IP address.


  2. Hi Florian,

    Thank you for the article.

    I don’t think I can license PEFV on Virtual Mobility Controller (VMC). Do you think it’s really required to use VPN just for centralized guest access over VMC?

    Or should we get one LIC-VIA per IAP-Cluster?

    Best Reguards

    • Hi Martin,

      Thanks for the feedback. Really appreciated.

      A PEFV is not needed, this is just for VIA connections. If you want to build the setup as above, you need at least one LIC-AP and on LIC-PEF License. This is required to enable the firewall on the controller and allow you to change and create roles.
      As IAP’s tunnels will not count against any license, you just need one to enable the functionality.

      Hope this helps and answers your question.


  3. Hi Florian,
    thanks for the nice post – very helpful.

    If I don’t have a PEF License – what profile would I choose? Guest Portal is handled by third party, so I just need to get my clients in a specific VLAN.

    For now, I’m unable to get DHCP Working…
    Client –> IAP –> GRE –> VMC –> external DHCP-Server

    Best Regards

    • Hi Andy,

      Ok, if your guest portal is external without the need for the controller to do the redirect (controller only forward L2 frames) you do not need any license.
      If DHCP is not working on a VMC, can you check if the ESXi server is configured correctly? 99% of those issues came from a wrong configured ESXi vswitch (you need to have promiscuous mode enabled for the portgroup).
      If this is the case, and you ESXi server is configured correctly, what happened if you use a static IP for the client. Can he ping the gateway? Does the gateway has a MAC entry for the client?

      Just some ideas to troubleshoot.


  4. Hi Florian,
    I always read your posts with great interest.
    In this post, you are setting up a guest solution based on IAP.
    I am trying to set up a guest solution for wired guests, using a Mobility Controller and Clearpass.
    Do you have a guide, that might point me in the right direction ?

    Best regards

    • Hi Flemming,

      I do not have a guide but I will write something for this type of setup.


  5. Hi Florian,
    i’m going to do this kind of setup but i’m wondering why do you setup the captive as wired captive on controller side not on the IAP side?
    is this related to roaming?


    • Hi Ricky,

      You are correct. This setup was for a specific customer use case and normally, I would create the captive portal in the IAP itself. This would make the whole setup a lot easier.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.