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.
14 thoughts on “IAP VPN Guest Solution With Captive Portal”
Nice solution and nicely defined too, i will try it with purevpn after buying it from here at https://www.purevpn.com/order
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.
Hmmm i see, will contact there support on it.
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
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.
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?
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.
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
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.
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 ?
I do not have a guide but I will write something for this type of setup.
Nice to hear, I am looking forward…
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?
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.