Aruba VIA VPN with IKEv2

Reading Time: 12 minutes

This post is to show how Aruba VIA VPN with IKEv2 works. With IKEv2 we switch to a certificate-based authentication which makes it easier for users and more secure for the whole organization.

In an older post here I did a basic setup with IKEv1 and username password. This new post will leverage IKEv2 and certificate-based authentication for the user and for the computer as well. But I will go deeper into this later on.

Aruba VIA VPN – Basic Setup

Let’s start with the basic setup.

First, you need to make sure, that your controller is reachable from the internet. But I’m pretty sure, this is obvious.

Secondly, and I assume this as given as well, all client devices need at least one certificate. For Windows-based machines which are domain joined, a computer certificate will be helpful as well.

Third, the controller also needs a certificate that is trusted by the client devices. If you have a checkmark on all of those requirements go ahead.

If you are still reading and the above requirements are met, go to the controller and login as admin. Let’s start to do the basic stuff. Go to “Configuration–>Services–>VPN” and select the “General VPN” section:

Aruba VIA VPN - General VPN Settings
Aruba VIA VPN – General VPN Settings

First, create the “Address Pool” with a click on the “+” sign in the table. This allows you to give the pool a “Pool name” and to define a “Start address” and “End address”. Also, enable “NAT-T” for NAT Traversal. You need to select a “Server-certificate for VPN clients”. This is the certificate that will be presented to all clients, trying to connect to the controller. So the client devices need to trust this certificate.

Defining the “Primary DNS server” and “Secondary DNS server” should be the easy part.

Afterwards, submit the changes.

The next step is to assign the certificates to root ca’s for all VPN clients. Go to “Configuration–>Services–>VPN” and select the “Certificates for VPN Clients” section:

Aruba VIA VPN - Certificate for VPN Clients
Aruba VIA VPN – Certificate for VPN Clients

You need to fill both tables. First, use the “+” sign to add your root certificate to the “CA Certificate Assigned for VPN Clients” table and select your root ca certificate from the drop-down list. The one you used to sign your client certificates. You can add more than one if needed.

Secondly, you need to create a certificate group. Click the “+” sign in the “Certificate Groups for VPN Clients” table and select the “Server certificate” (should be the one from the “General VPN” section” and the corresponding “CA certificate”. Add more groups if needed, e.g. if different client devices have different trusts to different root ca’s.

Submit the changes. The basic settings are done.

Aruba VIA VPN – Authentication Prerequisites

Let’s do the authentication stuff. Before you can start to authenticate something you need to create a role for your VPN clients. At this stage, you will only create the role. Go to “Configuration–>Role & Policies–>Roles” and click the “+” sign to create a new role:

Aruba VIA VPN - Create VPN Role
Aruba VIA VPN – Create VPN Role

Submit the changes. You will modify the role later.

The next step is to configure the radius servers. They will do the authentication of your users and will check the certificate against revocation. You can also check the user in your directory. I use ClearPass as the radius server, but every radius server will do the job. In a later chapter, I will share, my ClearPass config.

If you have already configured your radius servers in the controller, you can skip the next step.

Go to “Configuration–>Authentication–>Auth Server” and add your radius servers:

Aruba VIA VPN - Add Radius Servers
Aruba VIA VPN – Add Radius Servers

First, create a new server group and click on the “+” sign in the “Server Groups” table. Only a “Name” is required.

Afterward, select the new server group and add servers to the group. Click the “+” sign in the “Server Groups>[SERVER GROUP NAME]” table and select the “Add new server” radio button. Select a “Name” and enter the “IP address / hostname”. Afterward, select the created server and change the “Shared key”. This is the radius key, which must match with the key on the radius server, configured for your controller.

Submit the changes.

The last prerequisite is to allow port 8085 to the controller’s control plane. This is only needed if you like to use the certificates for authentication during the initial profile download as well. Go to “Configuration–>Services–>Firewall” and select the “ACL White List” section. There is a list of all allowed traffic types, which are permitted by the firewall to hit the control plane. Port 8085 is not in there by default so you need to add this port. Click the “+” sign below the table to add a new entry:

Aruba VIA VPN - Add CP Whitelist Entry
Aruba VIA VPN – Add CP Whitelist Entry

The “Action” is permit and the “IPversion” is in my case “IPv4”. You can add an entry for IPv6 as well if needed. “Source” can be any, as the traffic will come from the VPN clients. “IP protocol number” is 6 for TCP and “Starting ports” is the same as “End port”, which is 8085. You might also set a rate limit to that connection if needed with the “White list bandwidth contract” to make sure, there is no DoS attack at that port. But from my point of view, this is only needed, if the controller is directly connected to the internet. If there is a firewall in front of the controller, this is firewall business.

Aruba VIA VPN – Profiles

Now, you will configure VIA profiles in order to authenticate and connect to the controller with VIA. The most important but easiest one is the “VIA Authentication Profile”. To create this profile go to “Configuration–>Authentication–>L3 Authentication” and look for “VIA Authentication”. Create a new profile like this:

Aruba VIA VPN - VIA Authentication Profile
Aruba VIA VPN – VIA Authentication Profile

You should set a good “Profile name” and select the role we created before as the “Default Role”. I also checked the “Client-certificate based authentication for VIA Profile download” checkbox to use the client certificate for profile download as well and changed the “Authentication protocol” from “pap” to “mschapv2”. Submit the changes and select the “Server Group” entry:

Aruba VIA VPN - VIA Authentication Profile Server Group
Aruba VIA VPN – VIA Authentication Profile Server Group

Select the created radius server group from above as the “Server Group”. If you need accounting (I recommend to use accounting), do the same for the “RADIUS Accounting Server Group”.

Now, go to the “VIA Web Authentication” section and select “default”. With a click on the “+” sign add the created “VIA Authentication Profile”:

Aruba VIA VPN - VIA Web Authentication
Aruba VIA VPN – VIA Web Authentication

Let’s get to the biggest chunk. Go to “VIA Connection” and create a new profile. This is where all the configuration for the VIA client is configured. I will only highlight the options I changed from default for this setup. There are many more options available, some are useful others are for corner cases. For the basic IKEv2 setup with automatic connection, the following are needed:

Aruba VIA VPN - VIA Connection Profile Part 1
Aruba VIA VPN – VIA Connection Profile Part 1

The first one you need to add is the “VIA Servers” entry. This is a list of controllers the client tries to reach for a connection. You need to enter an “Addr”, which is the external address or hostname of the controller, an “internal_IP”, which is the internal IP and which is used to check if the client is within your network or connected to an external network and a “Description”.

I enabled the “Client Auto-Login” option. This makes the client to connect automatically, if the client device is connected to an external network.

Also add the “VIA Authentication Profiles to provision” and use the one created above.

Aruba VIA VPN - VIA Connection Profile Part 2
Aruba VIA VPN – VIA Connection Profile Part 2

Here you need to check the “Enable IKEv2” checkbox. I also use “eap-tls” for “IKEv2 Authentication method”. In the past, I also enabled “Allow user to save passwords”. If you like your domain-joined Windows devices to connect to VPN even before the user logs into the system (e.g. for password change, expired passwords, or no cached logins) also check the “Enable Domain Pre-Connect” checkbox.

Aruba VIA VPN - VIA Connection Profile Part 3
Aruba VIA VPN – VIA Connection Profile Part 3

The last thing I changed is the “Certificate Criteria” option. The content of the option is this:

organizationalUnitName=VPN Access for User;[email protected]|@flomain.de

This option is to preselect the certificate, used for the connection. In my case, all certificates on the device are filtered for “organizationalUnitName” and “mailAddress”. If there are multiple certificates in the device this is very helpful to strip the list down. If there is only one certificate in the filtered list, the user is not asked for a selection and the connection is using the certificate for the connection. This makes it really easy.

Below is a list of possible filter options:

TextOID
commonName2.5.4.3
organizationalUnitName2.5.4.11
organizationName2.5.4.10
subjectAltName2.5.29.17
certificateIssuer2.5.29.29
userPrincipalName1.3.6.1.4.1.311.20.2.3
emailAddress1.2.840.113549.1.9.1
friendlyName1.2.840.113549.1.9.20
Certificate Criteria Options

Those are all options needed for this simple setup.

Submit the changes.

Now, get back the role we created earlier. Go to “Configuration–>Roles & Policies–>Roles” and select the created role. There is an option to “Show Advanced View” on the right side of the page. Click this option, select “More” and select the “VPN” section:

Aruba VIA VPN - Modify VPN Role
Aruba VIA VPN – Modify VPN Role

Select the created “Address Pool” as the “L2TP pool” and the created “VIA connection profile”. This brings everything together.

One last step, before we start the testing. Go to “Configuration–>Services–>VPN” and select the IKEv2 section. Make sure that “EAP-TLS” passthrough is enabled:

Aruba VIA VPN - IKEv2 Options
Aruba VIA VPN – IKEv2 Options

This allows the radius server to do EAP-TLS with the client for authentication.

Aruba VIA VPN – Radius Server

As the radius server, I use ClearPass. Every other radius server should work as well. My users are in an active directory and the radius server is checking there for role assignment. I keep the radius part quite short as this is just complementary and not the focus of this post.

I use three services for the solution above. First one an authorization only service for the web profile download. This one is used to authenticate the clients who try to download the VIA profile from the controller. The service looks like this:

Aruba VIA VPN - ClearPass Web Profile Download Service
Aruba VIA VPN – ClearPass Web Profile Download Service

The service is simple. It simply looks up the username from the certificate against the active directory and returns the “lab-via-role” role VSA to the controller.

The second service is to authenticate VPN users:

Aruba VIA VPN - ClearPass VIA Authentication Service
Aruba VIA VPN – ClearPass VIA Authentication Service

This one authenticates the user against active directory using EAP-TLS and assigns the “lab-via-role” role via VSA to the user.

The third service is for machine authentication. If you use “Domain Pre-connect” you need something like this as well:

Aruba VIA VPN - ClearPass Machine Authentication Service
Aruba VIA VPN – ClearPass Machine Authentication Service

This one is a little bit tricky. VIA will use a certificate from the machine certificate store to authenticate and connect to the VPN before the user logs into the system. But this is not a machine authentication but a normal user authentication. Therefore the radius server will not find the user in AD if you use the real machine certificate with FQDN as the username. To avoid user authorization I use my “LAB – EAP TLS without Authorization” method. This will only check the certificate without user lookup. To differentiate those requests from the normal user request, I check that there is no “@” in the username, as the machine certificate will have the FQDN as the username.

Based on the OU in the cert I return the “lab-via-role” role VSA.

That is the radius config and now we can start testing.

Aruba VIA VPN – Test the VPN Connection

So let’s start the testing. I will use a domain-joined Windows 10 running the latest version of the VIA client (version 4.0). The device has two certificates, one user certificate in the user certificate store and one machine certificate in the machine certificate store. When starting the client, you need to download the profile before you can connect to the VPN:

Aruba VIA VPN - Click to Download VPN Profile
Aruba VIA VPN – Click to Download VPN Profile

I think the advice is clear, click to download the profile:

Aruba VIA VPN - VPN Profile Download URL
Aruba VIA VPN – VPN Profile Download URL

First, you need to enter the hostname or IP of the controller. Click “Download” to get the certificate section screen:

Aruba VIA VPN - Certificate Selection Screen
Aruba VIA VPN – Certificate Selection Screen

Here I chose the user certificate. This certificate is used to authenticate against the controller and to download the VPN profile. Click “Proceed” to download the profile. It might happen, that you need to acknowledge a certificate warning if the controller’s web server certificate is not trusted.

After downloading the VPN profile the client might connect automatically to the VPN. This happens if you are not connected to your internal network. If the VPN did not connect automatically, you can start the connection by clicking on the big button in the middle of the app, with the text “CLICK TO CONNECT”:

Aruba VIA VPN - Client Connect
Aruba VIA VPN – Client Connect

If you clicked you should get connected to the VPN. Normally, the window will minimize, if you bring it to the desktop again it should look like this:

Aruba VIA VPN - Successful VPN Connection
Aruba VIA VPN – Successful VPN Connection

Here you can see that the connection is established and using IPSec. If IPSec is not available, the client can fall back to SSL.

From the controller it would look like this:

(VMC-MC-1) *[mynode] #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
----------      ------------       ------                  ----          ----------  ----     --------       -------  -------  ---------------  -------  ------------  ----  ---------  ---------
192.168.2.154   00:00:00:00:00:00                          logon         00:00:08                            N/A                                         tunnel                         WIRELESS
10.222.222.100  00:00:00:00:00:00  [email protected]  lab-via-role  00:00:08    VIA-VPN  192.168.2.154  N/A                                         tunnel                         WIRELESS

User Entries: 2/2
 Curr/Cum Alloc:3/3 Free:0/0 Dyn:3 AllocErr:0 FreeErr:0

You will see two entries in the user table. One for the device with the outer IP and the “logon” role and one with the inner IP with the “lab-via-role”. This one will also have the username populated.

You can also check the IPSec and ISAKMP entries:

(VMC-MC-1) *[mynode] #show crypto ipsec sa


IPSEC SA (V2) Active Session Information
-----------------------------------
Initiator IP                              Responder IP                              SPI(IN/OUT)        Flags Start Time        Inner IP
------------                              ------------                              ----------------   ----- ---------------   --------
192.168.2.154                             10.201.201.40                             87bba500/9f4a59ab  UT2   May 27 13:16:29   10.222.222.100
10.201.201.42                             10.201.201.41                             79989f00/d697fe00  T2    May 27 13:01:02     -

Flags: T = Tunnel Mode; E = Transport Mode; U = UDP Encap
       L = L2TP Tunnel; N = Nortel Client; C = Client; 2 = IKEv2
       l = uplink load-balance

Total IPSEC SAs: 2
(VMC-MC-1) *[mynode] #show crypto ipsec sa peer 192.168.2.154

 Initiator IP: 192.168.2.154
 Responder IP: 10.201.201.40
 Initiator: No
 SA Creation Date: Wed May 27 13:16:29 2020
 Life secs: 7200
 Exchange Type: IKE_SA (IKEV2)
 Phase2 Transform:Encryption Alg: AES 256 Authentication Alg: SHA1
 Encapsulation Mode Tunnel
 IP Compression Disabled
 PFS: no
 IN SPI: 87BBA500, OUT SPI: 9F4A59AB
 CFG Inner-IP 10.222.222.100
 Responder IP: 10.201.201.40

(VMC-MC-1) *[mynode] #show crypto isakmp sa

ISAKMP SA Active Session Information
------------------------------------
Initiator IP                            Responder IP                            Flags     Start Time        Private IP                              Peer ID
------------                            ------------                            -----     ----------        ----------                              -------------
10.201.201.42                           10.201.201.41                           r-v2-p    May 27 13:01:03     -                                     IPV4_ADDR:10.201.201.42
192.168.2.154                           10.201.201.40                           r-v2-E-V  May 27 13:16:29   10.222.222.100                          IPV4_ADDR:192.168.0.100

Flags: i = Initiator; r = Responder
       m = Main Mode; a = Agressive Mode; v2 = IKEv2
       p = Pre-shared key; c = Certificate/RSA Signature; e =  ECDSA Signature
       x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled
       3 = 3rd party AP; C = Campus AP; R = RAP;  Ru = Custom Certificate RAP; I = IAP
       V = VIA; S = VIA over TCP; l = uplink load-balance

Total ISAKMP SAs: 2
(VMC-MC-1) *[mynode] #show crypto isakmp sa peer 192.168.2.154

 Initiator IP: 192.168.2.154
 Responder IP: 10.201.201.40
 Initiator: No
 Initiator cookie:dded66ae7e6002e8 Responder cookie:1200b8a83e16d6e6
 SA Creation Date: Wed May 27 13:16:29 2020
 Life secs: 28800
 Initiator Phase1 ID: IPV4_ADDR:192.168.0.100
 Responder Phase1 ID: C=DE S=NRW L=Selm O=Flomain OU=Network VPN Test CN=vmc-mc-vip.lab.flomain.local [email protected]
 Exchange Type: IKE_SA (IKEV2)
 Phase1 Transform:EncrAlg:AES128 HashAlg:HMAC_SHA1_96 DHGroup:2
 Authentication Method: EAP
 CFG Inner-IP 10.222.222.100
 IPSEC SA Rekey Number: 0
 VIA

During this initial connection, the client also creates another profile for the machine authentication, if “Domain Pre-connect” is enabled. This one is used to connect to the VPN if no user is logged into the computer. To check this as well, disconnect the VPN and logoff or restart the computer. After the computer is up again do not log in but let the computer in the login screen. Let’s check the controller for a VPN connection:

(VMC-MC-1) *[mynode] #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
----------      ------------       ------                      ----          ----------  ----     --------       -------  -------  ---------------  -------  ------------  ----  ---------  ---------
192.168.2.154   00:00:00:00:00:00                              logon         00:00:00                            N/A                                         tunnel                         WIRELESS
10.222.222.101  00:00:00:00:00:00  lab-computer.flomain.local  lab-via-role  00:00:00    VIA-VPN  192.168.2.154  N/A                                         tunnel                         WIRELESS

User Entries: 2/2
 Curr/Cum Alloc:3/6 Free:0/3 Dyn:3 AllocErr:0 FreeErr:0

Comparing the output to the one above, you will now see, that the username is now the FQDN of the device and not the username of the user. If we would now log in, the connection would be disconnected and the user connection would be established again. This is useful if you do not allow cached login to windows based domain-joined devices. You cannot define the certificate to use. VIA will use the first available certificate in the machine certificate store.

In addition to my last post on this topic, this should enhance usability and security using the VIA VPN.

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

Leave a Reply

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

%d bloggers like this: