Wireless Access

This post is about configuring the Controller for Virtual Intranet Access.

Included information on 'where in GUI' and the equivalent 'CLI command'.

Setup:
Aruba7005 Controller in standalone mode running ArubaOS Version 8.3.0.5.VIA configuration requires that you first configure VPN settings and then configure VIA settings. 

VPN Settings:
Enable VPN Server Module
You must install the PEFV license to configure and assign user roles.

GUI:

Mobility Controller -> Configuration -> System -> Licensing -> Inventory -> Click on + sign and add the license.

 CLI:

license add <key>

Decide IKE Policy

ArubaOS support both IKEv1 and IKEv2 protocol to establish IPsec tunnels.
We will be using predefined default IKE policies "20", which has the following parameters, to establish the VPN tunnel.
Encryption: AES256
HASH: SHA
AUTHENTICATION: pre-shared
Diffie Hellman Group: 2

GUI:

Configuration -> Services -> VPN -> IKEv1 -> IKEv1 Policies

Configuring the shared secrets

GUI:
Configurations -> Services -> VPN -> Shared Secrets -> IKE Shared Secrets

CLI:

crypto isakmp key  ****** address 0.0.0.0 netmask 0.0.0.0

Address Pool

Define the pool from which the clients are assigned addresses.

GUI
Configuration -> Services -> VPN -> General VPN -> Address Pool

CLI:

ip local pool via 2.2.2.2 2.2.2.200

Define the DNS Server

Configure the IP addresses of the DNS servers that is pushed to the VPN client.
GUI
Configurations -> Services -> VPN -> General VPN -> Primary DNS Server

CLI:

vpdn group l2tp client configuration dns 8.8.8.8

Enabling NAT-T
NAT traversal allows systems behind NATs to request and establish secure connections on demand.

GUI:
Configurations -> Services -> VPN -> General VPN -> Enable NAT-T

CLI:

crypto isakmp udpencap-behind-natdevice

VIA Settings:

VIA Authentication

Create an authentication profile to authenticate users against a server group.

GUI:

Configuration -> Authentication -> L3 Authentication -> VIA Authentication -> Add a new profile and set the server group to 'internal'.

CLI:

aaa authentication via auth-profile "kapvia"
server-group "internal"
!

Adding local users:

GUI:

Goto Configuration -> Authentication -> Auth Servers
In 'Server Groups' -> Internal.
Click on 'Internal' and goto 'Users'
Add local user here.

 CLI:

local-userdb add username kapil password ******  role default-via-role

VIA Web Authentication

Create the VIA web authentication which is a list of VIA authentication profiles.
The web authentication list allows the users to login to the VIA download page <https://<controller IP address>/via> to download the VIA client. 

GUI:

Configuration -> Authentication -> L3 Authentication -> VIA Web Authentication -> Add a new web auth profile

CLI:

aaa authentication via web-auth "default"
auth-profile "kapvia" position 1
!

VIA Connection profile

Create the VIA connection profile which is a collection of all the configurations required by a VIA client to establish a secure IPsec connection to the controller.
A VIA connection profile is always associated to a user role, and all users that belong to that role use the configured settings.
When a user authenticates successfully to a server in an authentication profile, the VIA client downloads the VIA connection profile that is attached to the role assigned to that user.

GUI:

Configuration -> Authentication -> L3 Authentication -> VIA Connection -> Add a new connection profile

- Define the Server address
- Link the VIA Auth profile
- Mention the internal address that needs to be accessed by VIA
- Enable split tunneling
- Select the IKE Policy

CLI:

aaa authentication via connection-profile "kap-con-via"
server addr "59.167.xx.xxx" internal-ip 10.10.101.1 desc "Aruba7005-Gateway" position 1
auth-profile "kapvia" position 1
tunnel address 192.168.17.0 netmask 255.255.255.0
tunnel address 192.168.26.0 netmask 255.255.255.0
tunnel address 172.30.30.0 netmask 255.255.255.0
tunnel address 172.30.29.0 netmask 255.255.255.0
tunnel address 172.30.20.0 netmask 255.255.255.0
tunnel address 10.10.100.0 netmask 255.255.255.0
tunnel address 10.10.101.0 netmask 255.255.255.0
split-tunneling
ikev2-policy "10004"
ike-policy "20"
no windows-credentials
no domain-pre-connect
!

Create VIA roles:
Link the Address Pools and Connection Profile

GUI:

Configuration -> Roles & Policies -> Roles -> Modify the 'default-via-role'

CLI:

user-role default-via-role
pool l2tp via
via "kap-con-via"
access-list session global-sacl
access-list session apprf-default-via-role-sacl
access-list session allowall
access-list session v6-allowall
!

Verification Commands:

show crypto isakmp sa
show crypto ipsec sa

 show user

Hope you find this post useful. Please post your feedback.

Regards,

Kapildev Erampu

It's my understanding that the VIA pool must be routable. Is that not the case?

Not at all.  You would have to have a any any any src-nat ACL at the bottom of the client firewall policies, is all for that client to be able to pass traffic.

Hi CJoseph, 

1.Is enabling source national on pool itself is enough to avoid routable pool. 

 2.let me know that enable src nat acl in client firewall policy, you mean in user role.? 

3.Do we need  to do destination nat on firewall to allow client traffic to controller. 

Regards, 

Mallikarjun

---

@Mallikarjun Hiremath wrote:

Hi CJoseph, 

 

1.Is enabling source national on pool itself is enough to avoid routable pool. 

 

 2.let me know that enable src nat acl in client firewall policy, you mean in user role.? 

3.Do we need  to do destination nat on firewall to allow client traffic to controller. 

 

Regards, 

Mallikarjun

 

 

---

1.  Enabling source nat as a checkbox under the pool creates a srcnat acl and applies it to the default-vpn-role.  If your VIA clients are not using the default-vpn-role, source natting will not work for them.  You should create your own acl that source-nats all traffic and put it at the bottom of your VIA user role (you can also make it the only acl in your user role).

2.  Yes.

3.  You do not.  If your pool is non-routable and the acl is source-natting traffic, you don't need to do anything.  If your pool is routable, it should be in a subnet on an ip interface that already exists on the physical controller.  That should just work.

Hi CJoseph, 

Thank you for the response. 

3.I mean when the VIA CLIENT accessing the network when the firewall comes between the controller and the user ( via client) . 

4.How many PEFV Licenses we need to have for 100 users. 

5.What is the number of VIA TUNNEL limitations for the controller. 

Regards, 

Mallikarjun

3.  If traffic is source-natted, the client traffic will appear to come from the uplink ip address of the Aruba Controller

4.  Please take a look at the website here:  https://www.arubanetworks.com/techdocs/VIA/3x/content/via%20config/before_you_begin.htm?Highlight=licensing

5.  Each VIA client consumes an ipsec tunnel.  IPSEC tunnel limits for the 7000 series controllers are here:  https://www.arubanetworks.com/assets/ds/DS_7000Series.pdf

Thank you.

Regards,

Mallikarjun

It depends on your use case...

If the traffic will only be initiated from the VIA clients and you don't need to see the real VIA client IP on your "corporate network" then there is no need to have routable VIA client IPs. Natting the traffic will work.

However, if you need to reach the VIA clients directly from your "corporate network", meaning traffic will be initiated from your network to the VIA clients IPs, then yes the VIA client IPs need to be routable.

I use this for example when I use my VIA client machine as the SFTP/TFTP server. The "switch" in my "network" will initiate the TFTP/SFTP to my VIA client machine so in this case it should be routable. Note the role policy should allow traffic initiated from corporate to reach the VIA clients as well..