AirWave & VMware Tools installation

It is recommended to install the VMware Tools before running the AMP setup. After deploying the AMP ova file and starting the VM, you can interrupt the installation process via CTRL+C. This gives you access to the AMP shell. Use the following steps to install VMware Tools on a HPE Aruba AirWave Management Platform appliance:

  1. From the VMware vSphere Client, open the console to the VM and select VM – Guest – Install/Update VMware Tools;
  2. Type mkdir -p /media/cdrom
  3. Mount the CD-ROM via mount /dev/cdrom /media/cdrom
  4. Copy the installation file cp /media/cdrom/VMwareTools-*.tar.gz /tmp
  5. Unmount the CD-ROM umount /media/cdrom
  6. Extract the installation file cd /tmp; tar -zxvf VMwareTools-*.tar.gz
  7. Run the VMware Tools setup and install script by typing /tmp/vmware-tools-distrib/vmware-install.pl –default (2x hyphen)

The installation will take a few minutes. After the installation is finished you can restart the VM via the command init 6 or reboot.

Check the VMware Tools installation after the reboot by interrupting the AMP installation again and type the command vmware-toolbox-cmd -vThis will give you information about the installed version of VMware Tools.

You can now start the AMP installation again via the command /root/amp-install.

ClearPass – concurrent session limit

I tried to configure a restriction to the concurrent number of active sessions a user can have on the wireless network. I found a great article on AirHeads Community “How to deny access for authentication requests based on session limit?

In short the article tells you to:

  1. Edit the Insight Repository
  2. Add more Filiters on the Attributes tab
  3. Enter the following information
    1. Filter Name: sessions
    2. Filter Query: see below
    3. Name: sessions
    4. Alias Name: sessions
    5. Data Type: Integer
    6. Enabled As: Role
  4. Add the Insight Repository as Authorization Source
  5. Create an Enforcement Policy Condition to check the Insight Repository
    1. Type: Authorization:[Insight Repository]
    2. Name: sessions
    3. Operator: GREATER_THAN_OR_EQUALS
    4. Value: <number of allowed simultaneous connections + 1

I configured my ClearPass environment like shown in the article, but I didn’t see any active sessions in the access tracker. The counter remained 0. I connected to the Insight database with the tool pgAdmin to see if the Insight database is updated. The database is updated, so every thing seems to be working.

Be accident I found the solution. The SSID is using EAP-PEAP authentication and users enter there username as <username>@<domain-name>, like rene@booches.nl. This is necessary, because the SSID is configured to work with Govroam. Govroam provides government employees with seamless access to WiFi networks, wherever the service has been made available by participating organisations. To authenticated the users correctly, I configured the CPPM Service with Strip Username Rules.

Strip Username Rules

The SQL query checks the attribute %{Authentication:Username}

select count(*) as sessions from radius_acct where (username = ‘%{Authentication:Username}’) AND end_time is null AND termination_cause is null AND (updated_at BETWEEN (now() – interval ‘1 hour’) AND now());

In the InsightDB the username has the format <username>@<domain-name>, but the attribute %{Authentication:Username} has the format <username>. I saw this “mismatch” while checking the Access Tracker.

ClearPass Access Tracker

I altered the query by changing %{Authentication:Username} into %{Authentication:Full-Username}. After this the session information was correct and I could use the session counter in a Role Mapping or Enforcement Profile to limit the concurrent number of active sessions from a user.

FortiGate – IPSec with dynamic IP

Site-to-site VPN connections are a common way to connect a branch office to the corporate network. In the Netherlands it is still common to have a internet connection at a branch office with a dynamic IP address. The usage of dynamic IP address is not ideal when configuring a site-to-site VPN connection, because the configuration almost always relies on static IP addresses.

I recently configured an IPSec VPN between two FortiGate appliances and the branch appliance is using a dynamic IP address. I used Fortinet’s DDNS feature to configure the VPN.

To configure the branch FortiGate for DDNS, I had to configure the WAN interface to retrieve its IP address via DHCP. Next I configured DDNS.

config system ddns
edit 1
set ddns-server FortiGuardDDNS
set ddns-domain “branche01-booches.fortiddns.com”
set monitor-interface “wan1”
next
end

This can also be done in the GUI.

FortiDDNS

The VPN configuration on the hub firewall for dynamic DNS support is the same as the configuration of a regular VPN connection. The only difference is the configuration of the peer IP address. Instead of a static IP, you configure the DDNS FQDN.

config vpn ipsec phase1-interface
edit “vpn_p1_branche01”
set type ddns
set interface “wan1”
set proposal 3des-sha1
set dhgrp 2
set remotegw-ddns “branche01-booches.fortiddns.com”
set psksecret P$k-VPN!
next
end

And as you can image, this can also be done via the GUI.

FortiDDNS IPSec - HQ

Check the status of the VPN connection via the regular methods like cli (get vpn ike gateway or get vpn ipsec tunnel name <tunnel-name>) or via the GUI.

FortiGate – Outbound OSPF filtering

Just a quick post on filtering outbound OSPF advertisements. I had some struggle with this config today.

config router prefix-list
  edit “filter-outbound”
  config rule
    edit 1
      set prefix 10.10.0.0 255.255.0.0
      unset ge
      unset le
    next
    edit 2
      set prefix 10.20.0.0 255.255.0.0
      unset ge
      unset le
    next
    edit 3
      set action deny
      set prefix any
      unset ge
      unset le
    next
  end
 next
end
!
config router ospf
 set router-id 1.1.1.10
  config area
    edit 1.1.1.1
      config filter-list
        edit 1
          set list “filter-outbound”
          set direction out
        next
end

Like a said: a quick-and-dirty  note

Aruba MAS – Tunneled node

Today I played a bit with an Aruba Mobility Access Switch with Tunneled Node configuration to a Aruba Mobility Controller. More information on Tunneled Node can be found here.

The configuration is straight forward. You need to configured a tunneled-node profile on the MAS and associate the access ports on the MAS to a VLAN, which is also present on the controller. I already have a controller in place and I would like to use some access ports for guest users with captive portal capabilities. I already setup a SSID with captive portal capabilities, so I use the same AAA profile on the controller for the tunneled-node clients.

I created the following configuration on the Aruba MAS.

ip-profile
default-gateway 10.10.75.254
controller-ip vlan 75
!
interface-profile tunneled-node-profile “tunnel-prof”
controller-ip 10.10.50.150
mtu 1300
!
interface-profile switching-profile “vl150-prof”
access-vlan 150
!
interface-group gigabitethernet “vl150-group”
apply-to 0/0/1-0/0/22
tunneled-node-profile “tunnel-prof”
switching-profile “vl150-prof”

The IP-profile defines the controller-ip of the MAS and the default-gateway configuration to access the Aruba controller (10.10.50.150). A switching profile is configured with access vlan 150 and the tunneled-node and switching-profile are bound to switch ports 0/0/1 to 0/0/22.

On the controller you only need to enable wired access and assign the AAA profile, which you also use for the guest SSID.

aaa authentication wired
profile “guest-aaa_prof”

A guest devices gets an IP address assigned from VLAN 150, located behind the corporate Aruba Mobility Controller when I connect a device to switch port 0/0/1. The guest-aaa_prof is assigned to the device/user. This redirects the user to the captive portal to enter login credentials. You can also configure user derivation to assign different VLANs to the connected devices behind the Aruba MAS.