Flomain Networking https://www.flomain.de Everything Networking Wed, 14 Feb 2018 12:30:59 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.4 https://www.flomain.de/wp-content/uploads/2016/11/favicon-image.png Flomain Networking https://www.flomain.de 32 32 20143597 Unified Aruba Controller Discovery https://www.flomain.de/2018/02/unified-aruba-controller-discovery/ https://www.flomain.de/2018/02/unified-aruba-controller-discovery/#respond Wed, 14 Feb 2018 12:30:59 +0000 https://www.flomain.de/?p=993 This time is about some basic things. I will describe the unified Aruba controller discovery process. With the new unified software, the process is the same for IAP and CAP. Actually, with the new unified software, there is no IAP or CAP anymore. The Aruba discovery process is a simple process. The AP uses this […]

The post Unified Aruba Controller Discovery appeared first on Flomain Networking.

]]>
This time is about some basic things. I will describe the unified Aruba controller discovery process. With the new unified software, the process is the same for IAP and CAP. Actually, with the new unified software, there is no IAP or CAP anymore.

The Aruba discovery process is a simple process. The AP uses this process to find a controller or a way to connect to AirWave or Central. Once, the AP found a controller, AirWave or Central it never uses the process again. Except, you do a factory reset on the AP.

The process has 7 plus 1 options. The first 7 options run automatically. The last option is the manual provisioning.

Unified Aruba Controller Discovery: Static Master Assignment

The first and easiest way to discover a controller is the static master assignment. You can do this by manually setting the environment variable during AP boot:

APBoot 1.5.3.14 (build 45815)
Built: 2014-09-05 at 11:23:04

Model: AP-20x
CPU:   BCM53011/15, revision A0
I2C:   ready
SKU:   2
OTP:   0xeca01028
Clock:
       CPU:  800 MHz
       DDR:  533 MHz
       AXI:  400 MHz
       APB:  200 MHz
       PER:  400 MHz
DRAM:  128 MB
POST1: memory passed
SF:    Detected MX25L25635E with page size  4 kB, total 32 MB
Flash: 32 MB
PCIe0: RC, link up
       dev fn venID devID class  rev    MBAR0    MBAR1    MBAR2    MBAR3
       00  00  14e4  4360 00002   03 08000004 00000000 00000000 00000000
PCIe1: RC, link up
       dev fn venID devID class  rev    MBAR0    MBAR1    MBAR2    MBAR3
       00  00  14e4  4360 00002   03 40000004 00000000 00000000 00000000
Power: POE
Net:   eth0
Radio: bcm43460#0, bcm43460#1

Hit  to stop autoboot:  2  0 
apboot> setenv master 10.100.100.50

apboot> printenv 

bootdelay=2
baudrate=9600
autoload=n
boardname=Springbank
servername=aruba-master
bootcmd=boot ap
autostart=yes
bootfile=armv7ns.ari
ethaddr=94:b4:0f:cb:75:cc
ethact=eth0
os_partition=0
stdin=serial
stdout=serial
stderr=serial
master=10.100.100.50

Environment size: 248/65532 bytes
apboot> saveenv 

Saving Environment to Flash...
Erasing flash...Writing to flash..................done
apboot> boot

After boot, the AP connects to the controller with the IP “10.100.100.50” (in my example). This is not handy in large environments and I’m not aware of any customer doing it that way.

I describe this options as well because after the AP uses one of the other options, the controller IP is saved to the same environment variable as above. So, after the AP completes one of the other options, the static assignment option is used for all other reboots.

Unified Aruba Controller Discovery: DHCP Based Discovery

From my point of view, this one is the most used option in the field. The AP tries this options first if no static assignment is present. For IPv4 the AP expects DHCP option 43. If you use IPv6, the AP requests option 52:

Unified Aruba Controller Discovery - IPv6 Option 52

Unified Aruba Controller Discovery – IPv6 Option 52

I will not show the IPv6 setup. But it is the same as with IPv4.

You find the DHCP configuration for a CAP here:

http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/DHCP_Option_43.php

In my case, the DHCP configuration looks like this:

#Aruba Option 43 for CAP
option master code 43 = ip-address;

#Match Option 60
class "ArubaAP-Class" {
        match option vendor-class-identifier;
}

#AP_Management
subnet 10.102.102.0 netmask 255.255.255.0 {
        option routers                  10.102.102.1;
        option subnet-mask              255.255.255.0;
        option domain-search            "flomain.local";
        option domain-name              "flomain.local";
        option domain-name-servers      192.168.2.26;
        subclass "ArubaAP-Class" "ArubaAP" { -->Matches the AP Requests
                option vendor-class-identifier "ArubaAP"; -->Responds with Option 60 "ArubaAP"
                option master           10.100.100.50; -->Set the Master
        }
        range                           10.102.102.10 10.102.102.200;
}

The config above is for the ISC-DHCP-Server on Debian. I create a new option “master”. This option is an IP address. The IP of the controller.

I also create a new class. This class matches all device with a specific “vendor-class-identifier”. DHCP option 60.

In the subnet declaration, I bring both together. The result is the controller IP in the Offer and ACK response from the DHCP server:

Unified Aruba Controller Discovery - Option 43

Unified Aruba Controller Discovery – Option 43

From the AP console it looks like this:

Getting an IP address...
[   21.388000] ADDRCONF(NETDEV_UP): bond0: link is not ready
[   23.392000] bond0: link up (1000FD)
[   23.394000] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
10.102.102.10 255.255.255.0 10.102.102.1
Running ADP...Done. Master is 10.100.100.50

If you cannot use DHCP option 43, go to the next option, ADP.

Unified Aruba Controller Discovery: ADP Based Discovery

If the AP did not get option 43 in the DHCP Offer and/or Ack response but get an IP the AP tries the Aruba Discovery Protocol (ADP) to find a controller. ADP is very simple. The AP just send a broadcast or multicast. I have never seen the multicast option in environments. But the AP sends ADP packets to the multicast group 239.0.82.11. You need to implement multicast routing in the backbone. The controller joins this group as well. But most of the time multicast routing is the show stopper.

Most of the time, my customers use the broadcast option, with the controller in the same VLAN as the AP. If the customer did not use DHCP option 43. This is a simple UDP broadcast:

Unified Aruba Controller Discovery - ADP Broadcast

Unified Aruba Controller Discovery – ADP Broadcast

Unified Aruba Controller Discovery: DNS Based Discovery

This is the second most used option. If the AP can get an IP and can reach a DNS server, this option fits perfectly. The AP tries the options above first, but if they fail, DNS is used.

The AP simply tries to resolve aruba-master.domain.tld. The “domain.tld” part is from the DHCP packet. Put this name into your DNS. The AP will resolve the name and connect to the controller.

Unified Aruba Controller Discovery - DNS Request aruba-master

Unified Aruba Controller Discovery – DNS Request aruba-master

In the screenshot above, you see the DNS queries and afterward the PAPI requests to the controller.

From the CLI it looks like the options above:

Getting an IP address...
[   24.552000] ADDRCONF(NETDEV_UP): bond0: link is not ready
[   26.556000] bond0: link up (1000FD)
[   26.558000] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
10.102.102.10 255.255.255.0 10.102.102.1
Running ADP...Done. Master is 10.100.100.50

Unified Aruba Controller Discovery: Instant VC Discovery

After all the steps above, the AP tries to find another virtual controller (VC). If the AP is in this step, it is in the Instant part of the discovery options. From this stage, the discovery of a controller is only possible after a reboot.

The Instant VC discovery is done through broadcasts. The VC will send UDP broadcasts in the VLAN:

Unified Aruba Controller Discovery - IAP VC Discovery

Unified Aruba Controller Discovery – IAP VC Discovery

If the AP receives such a message, it will connect to the VC, download the full IAP image and restart as an IAP. If no message is received, the AP has not so many options left.

Unified Aruba Controller Discovery: AirWave Discovery

If all the options above fail, the AP is not able to directly connect to a controller (mobility controller or virtual controller(IAP)).

One of the last options is to check DHCP option 43 for information to reach AirWave. The DHCP configuration for this looks like this:

#LAB_IAP
subnet 10.202.202.0 netmask 255.255.255.0 {
        option routers                  10.202.202.254;
        option subnet-mask              255.255.255.0;
        option domain-search            "lab.flomain.local";
        option domain-name              "lab.flomain.local";
        option domain-name-servers      192.168.2.26;
        subclass "ArubaAP-Class" "ArubaInstantAP" {
                option vendor-class-identifier "ArubaInstantAP";
                option airwave          "iap-test,192.168.2.23,aruba123"; -->send the AirWave connection String
        }
        range                           10.202.202.10 10.202.202.200;
}

The option for the AirWave connection string is defined like this:

#Aruba Option 43 for AirWave
option airwave code 43 = string;

The class to match option 60 is defined the same as above for the DHCP based controller discovery.

If the string above is in the DHCP answer from the DHCP server, you see the following in the AP log:

Getting an IP address...
Jan  1 00:00:42 udhcpc[3231]: udhcpc (v0.9.9-pre) started

Jan  1 00:00:43 udhcpc[3231]: send_discover: pkt num 0, secs 0

Jan  1 00:00:43 udhcpc[3231]: Sending discover...

Jan  1 00:00:44 udhcpc[3231]: send_selecting: pkt num 0, secs 2

Jan  1 00:00:44 udhcpc[3231]: Sending select for 10.202.202.13...

Jan  1 00:00:44 udhcpc[3231]: Lease of 10.202.202.13 obtained, lease time 689311

Jan  1 00:00:44 udhcpc[3231]: DHCP OPT 60 is ArubaInstantAP


Jan  1 00:00:44 udhcpc[3231]: DHCP OPT 43, len: 30, buf: iap-test,192.168.2.23,aruba123


Jan  1 00:00:44 udhcpc[3231]: ams-ip: 192.168.2.23, length of ams-key: 8


[   58.601904] ip_time_handler: Got ip and packets on bond0 Started master election 4-0, rand 26
10.202.202.13 255.255.255.0 10.202.202.254

After some time, ca. 5min, the AP starts talking to AirWave and shows up as a new device. The AP will download the full IAP image from AirWave and reboot as an IAP.

Unified Aruba Controller Discovery: Activate

If even AirWave is not working, the AP tries to connect to Activate. First, the AP checks for a new Instant software image. Afterwards, it looks for provisioning rules in Activate. If a rule is found, the AP follows those instructions.

If nothing is there, the AP broadcasts a default SSID “SetMeUp-xx:xx:xx” to allow a manual provisioning of the AP. If this fails as well, the AP reboots and starts from scratch.

Unified Aruba Controller Discovery: Putting all Together

After you know all the single steps, an AP tries to connect to a controller you can decide which one is best for your environment. Keep in mind, the steps are sequentially and not in parallel. Below is an overview of all options:

Unified Aruba Controller Discovery Process

Unified Aruba Controller Discovery Process

What is your preferred discovery method? Let me know as a comment below.

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.

The post Unified Aruba Controller Discovery appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/02/unified-aruba-controller-discovery/feed/ 0 993
How to Protect from Spanning Tree and Loops in the Access Area https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/ https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/#respond Wed, 17 Jan 2018 12:30:23 +0000 https://www.flomain.de/?p=981 With modern architectures and campus designs, you do not need spanning tree anymore. But how could you protect from spanning tree BPDU’s and loops in the access area, e.g. from external devices? The classical scenario is the cleaner, putting the free cable into the switch because it is in his way. ArubaOS switches have some […]

The post How to Protect from Spanning Tree and Loops in the Access Area appeared first on Flomain Networking.

]]>
With modern architectures and campus designs, you do not need spanning tree anymore. But how could you protect from spanning tree BPDU’s and loops in the access area, e.g. from external devices?

The classical scenario is the cleaner, putting the free cable into the switch because it is in his way. ArubaOS switches have some good answers to this and other scenarios and protect your network from unwanted loops and spanning tree BPDU’s.

Protect from Spanning Tree and Loops: Loop Protection

The first and easiest one is loop protection. This feature protects from unwanted loops in the access area, e.g. someone connects a cable twice to the same switch. Loop protection use control packets and send these packets out to all ports with loop protection enabled. To do this, the port must have an untagged VLAN. If no untagged VLAN is configured for the port, no control packets are sent. If the switch sees such a packet on another port, the loop is detected. The switch can now shut down the port to avoid network problems.

You configure loop protection on a per-port basis:

switch2(config)# loop-protect 9

This command enables loop protection for port 9. You can check this with this command:

switch2(config)# show loop-protect 

 Status and Counters - Loop Protection Information

  Transmit Interval (sec)     : 1           
  Port Disable Timer (sec)    : 100         
  Loop Detected Trap          : Disabled    
  Loop Protect Mode           : Port        
  Loop Protect Enabled VLANs  :             


       Loop    Loop     Detected  Loop   Time Since  Rx            Port   
  Port Protect Detected on VLAN   Count  Last Loop   Action        Status  
  ---- ------- -------- --------- ------ ----------- ------------- --------
  8    Yes     Yes      NA        1      1d,1h,27... send-disable  Down    
  9    Yes     No       NA        0                  send-disable  Up      

This command also shows the “Time Since Last Loop”. The default behavior is to disable the port which sends the control packet. You can change this to do nothing, or you can disable both ports:

switch2(config)# loop-protect 9 receiver-action 
 send-disable          Disable the sending port when a loop is detected.  This is the default.
 no-disable            Do not disable the sending port when a loop is detected.
 send-recv-dis         Disable the sending and receiving port when a loop is detected.

You might also define how long the port stays in the disable mode:

switch2(config)# loop-protect disable-timer  
 <0-604800>            Enter a number.

0 disables the port forever. Any other value disables the port for the time of the value in seconds.

You can also fine tune the interval, the control packets are sent. The default is a value of 5 seconds. You can narrow it down to 1 second or slow it down to 10 seconds:

switch2(config)# loop-protect transmit-interval 
 <1-10>                Enter a number.

For management purpose, you can send a trap when a loop is detected:

switch2(config)# loop-protect trap loop-detected

From the show command above, you see my default values. Those can be adjusted to your environment.

Below is a control packet:

Protect from Spanning Tree and Loops - Control Packet

Protect from Spanning Tree and Loops – Control Packet

What kind of loops are protected now:

A Loop directly on the Switch:

This is the obvious one. Someone connects the same cable twice, to the same switch.

Protect from Spanning Tree and Loops - Local LoopProtect from Spanning Tree and Loops - Local Loop

Protect from Spanning Tree and Loops – Local Loop

A Loop on a Device connected to the Switch:

This is more tricky. Let’s assume someone connects a switch or even a hub (not sure if you can even buy hubs today) to the access switch and produces a loop there. Loop protection can identify this and blocks the port as well.

Protect from Spanning Tree and Loops - Remote Loop

Protect from Spanning Tree and Loops – Remote Loop

From the packet snipped above, you can see that the destination MAC address is a multicast address. Therefore the unmanaged switch/hub forwards the packet on all ports with the help of the loop, the packet comes back to the access switch.

A loop between two Access Switches:

This scenario assumes, you have at least two access switches and they are connected to each other. A user connects an unmanaged switch/hub to both of the switches.

Protect from Spanning Tree and Loops - Between Two Access Switches

Protect from Spanning Tree and Loops – Between Two Access Switches

Loop protection protects you in this scenario as well. Even if the loop on the unmanaged switch/hub is not present, the ports on the access switches are blocked. But only if both access switches have the same VLAN’s. If the unmanaged switch/hub is in VLAN 1 on “Access Switch1” and VLAN 100 on “Access Switch2” the loop is only detected if “Access Swtich2” knows VLAN 1 or “Access Switch1” knows VLAN 100. One of the VLAN’s, preferably both, are configured on the link between both access switches.

The reason is, that loop protection works with normal multicast L2 frames. As opposed to BPDU’s, those frames are VLAN aware. BPDU’s are always untagged on the port (not true for PVST) and therefore the VLAN does not matter.

In Case of different VLAN’s, you should consider BPDU protection.

Protect from Spanning Tree and Loops: BPDU Filtering

Loop protection helps to protect against loops. But what about misconfigured devices or intruders. Imagine, someone connects a device to the network which is running spanning tree as well. This device is configured to be the root bridge. If you did not have some kind of protection against such devices, they could bring you in trouble by confusing your spanning tree. This could be a denial of service attack to bring you down.

But there is hope. With BPDU filtering you can do something. If you enable BPDU filtering on a port, this port drops all BPDU’s (incoming and outgoing). This means the port is not part of spanning tree at all. And if someone tries to attack you on this port, all BPDU’s are dropped as well. No chance for bad people.

To enable BPDU filtering on a per port basis you enable spanning tree first:

switch2(config)# spanning-tree enable

Afterwards, you enable BPDU filtering:

switch2(config)# spanning-tree 9 bpdu-filter 
The BPDU filter allows the port to go into a continuous
forwarding mode and spanning tree will not interfere, even if
the port would cause a loop to form in the network topology.
If you suddenly experience high traffic load, disable the port
and reconfigure the BPDU filter with the CLI command(s):
"no spanning tree PORT_LIST bpdu-filter"
"no spanning tree PORT_LIST pvst-filter"

Read the warning carefully, because this is important. A port with BPDU filtering enabled will always forward traffic and stays always in forwarding state. When not carefully thinking what you are doing, you can create loops easily.

To check the configuration use this command:

switch2(config)# show spanning-tree 9               

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 10          
  Time Since Last Change : 1 secs      

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports :                                        
  BPDU Filtered Ports  : 9                                        
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  Forwarding   | 009c02-5dd230 2    Yes Yes 

If you do a trace on the port, you will see no BPDU’s. If you send BPDU’s to the port, they are dropped without notice.

Protect from Spanning Tree and Loops: BPDU Protection

As opposed to BPDU filtering, BPDU protection protects against incoming BPDU’s. If a BPDU is received, the port is disabled. This makes it a more secure option to protect against external misconfigured devices or bad people, trying to confuse your spanning tree.

To use BPDU protection, you need to enable spanning tree first, like BPDU filtering above. Afterwards, you enable BPDU protection with this command on a per-port basis:

switch2(config)# spanning-tree 9 bpdu-protection

To check the configuration, use the command below:

switch2(config)# show spanning-tree 9

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 28          
  Time Since Last Change : 12 mins     

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports : 9                                       
  BPDU Filtered Ports  :                                         
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  Forwarding   | 009c02-5dd230 2    Yes Yes

If you trace the port, you see a lot of STP messages. But, if you answer them or send BPDU’s the port gets into the “BPDU Error” state:

switch2(config)# show spanning-tree 9

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 28          
  Time Since Last Change : 19 mins     

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports : 9                                       
  BPDU Filtered Ports  :                                         
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  BpduError    |               2    Yes No  

Any port in this state will be disabled forever. Or until you enable the port manually:

switch2(config)# interface 9 enable

To change this behavior you can set a global timeout period:

switch2(config)# spanning-tree bpdu-protection-timeout 60

The command above set the timeout for the port. If the port receives a BPDU, the port is set to “BpduError” state for the time in the timeout. Afterwards, the port is set into the enable state again.

The last option is for monitoring. With the command below you tell the switch to send a trap upon receiving a BPDU:

switch2(config)# spanning-tree trap errant-bpdu

My recommendation is to use BPDU filter on all ports to other switches. So, on all uplinks. And BPDU protection on all other ports. This protects you from bad BPDU from outside of your environment. I assume that you do not use STP in your environment for loop protection between switches, because of technologies like VSF or IRF. If you do not use such technologies but STP, do not use BPDU filter on uplinks.

Do you use STP in your environment? Why, or why not? Tell me in the comment section below.

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.

The post How to Protect from Spanning Tree and Loops in the Access Area appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/feed/ 0 981
ArubaOS 8 – Controller Deployment https://www.flomain.de/2017/12/arubaos-8-controller-deployment/ https://www.flomain.de/2017/12/arubaos-8-controller-deployment/#respond Wed, 06 Dec 2017 12:30:27 +0000 https://www.flomain.de/?p=713 In this post, I describe the different ways to deploy a controller with ArubaOS 8. Controller Deployment is significantly easier with ArubaOS 8 and it is the first time, that we see Zero Touch Provisioning for controllers. With ArubaOS 6.x it was not possible to have a complete Zero Touch Provisioning process. The fact, that […]

The post ArubaOS 8 – Controller Deployment appeared first on Flomain Networking.

]]>
In this post, I describe the different ways to deploy a controller with ArubaOS 8. Controller Deployment is significantly easier with ArubaOS 8 and it is the first time, that we see Zero Touch Provisioning for controllers.

With ArubaOS 6.x it was not possible to have a complete Zero Touch Provisioning process. The fact, that you have to configure stuff like the IP of the local controller, made this impossible. With ArubaOS 8 you configure everything on the Mobility Master (MM). There is no need to configure something on the controller. You even have no chance to. The configuration mode is blocked.

Nevertheless, you have the option to deploy the controller the old way. This is the first part of this post. Afterwards, I show you how the Zero Touch Provisioning works.

Controller Deployment: The Manual Way with PSK

The first part is about the manual deployment of controllers. This is still possible and much faster than with 6.x.

I assume, that you have the MM up and running and IP connectivity is possible between the Managed Device (MD) and the MM.

The communication between MM and MD is protected with IPSec. In my case, I use IPSec with PSK. You can also use certificates. In this scenario, I use the PSK option. Therefore you need to make the MM aware of the PSK. Connect to the MM and create the PSK:

(MM) *[mynode] #cd /mm
(MM) *[mm] #configure terminal 
Enter Configuration commands, one per line. End with CNTL/Z
(MM) *[mm] (config) #localip 10.201.201.10 ipsec comcomcom

I always create the PSK at the “mm” level. If you have multiple MM controller, this makes the configuration on all of them.

In this setup, the MD has a static IP. If you need to have a dynamic IP for the MD you can use the MAC for authentication, instead of the IP:

(MM) *[mm] (config) #local-peer-mac 00:0c:29:35:c2:cf ipsec test123

The “local-peer-mac” is the MAC of the MD. If the MD is a hardware controller you need to use the MAC from the VLAN interface, which is used to connect to the MM. If the MD is a virtual controller, you need to use the MAC from the management interface.

You need the MAC address to arrange the controller in the configuration hierarchy, as well. My current hierarchy has a folder named “LAB”:

(MM) *[00:0b:86:be:84:00] (config) #show configuration node-hierarchy 

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                      Type    Name
-----------                      ----    ----
/                                System  
/md                              System  
/md/Haan-Live                    Group   
/md/Haan-Live/00:0b:86:be:84:00  Device  wlan-controller
/md/LAB                          Group   
/mm                              System  
/mm/mynode                       System  

I will place the new controller in the folder “LAB”:

(MM) *[mm] (config) #configuration device 00:0C:29:35:C2:CF device-model MC-VA /md/LAB 
(MM) *[mm] (config) #show configuration node-hierarchy 

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                      Type    Name
-----------                      ----    ----
/                                System  
/md                              System  
/md/Haan-Live                    Group   
/md/Haan-Live/00:0b:86:be:84:00  Device  wlan-controller
/md/LAB                          Group   
/md/LAB/00:0c:29:35:c2:cf        Device  
/mm                              System  
/mm/mynode                       System

I create the new device with the first command. The second one is to check. The new device has no “Name”. After the device connects to the MM, this field is populated as well with the hostname of the MD.

Now, it is time to start the MD.

During bootup of the MD you have the chance to configure all options to connect to the MM:

Controller Deployment - Manual Configuration

Controller Deployment – Manual Configuration

The scenario above is for one MM without a VPN concentrator. I will build this in a later post. The scenario is also only for the “PSKwithIP” option. If you choose the MAC for authentication you need to change this to “PSKwithMAC”.

The most important pieces of information are the IP of the MD, the IP of the MM and the shared secret. You can change the rest afterward on the MM anyway. But those are important to initially connect to the MM.

You accept the configuration at the end and the MD starts rebooting. Afterward, the MD connects to the MM using IPSec and gets the configuration from the “Group” “/md/LAB”:

(MM) *[mynode] #show switches 

All Switches
------------
IP Address     IPv6 Address  Name             Location          Type    Model       Version        Status  Configuration State  Config Sync Time (sec)  Config ID
----------     ------------  ----             --------          ----    -----       -------        ------  -------------------  ----------------------  ---------
192.168.2.70   None          MM               Building1.floor1  master  ArubaMM-VA  8.1.0.2_60858  up      UPDATE SUCCESSFUL    0                       363
10.201.201.10  None          LAB_1            Building1.floor1  MD      ArubaMC-VA  8.1.0.2_60858  up      UPDATE SUCCESSFUL    10                      363
192.168.2.50   None          wlan-controller  Building1.floor1  MD      Aruba7005   8.1.0.2_60858  up      UPDATE SUCCESSFUL    20                      363

Total Switches:3

Controller Deployment: The Manual Way with Certificate

To use a PSK for authentication is not the best way. So, to improve the situation, you can use a certificate for the IPSec connection. With the CLI wizard, it is not possible to use a certificate for IPSec during the initial configuration tasks. But, you can change this afterward. Choose either “PSKwithIP” or “PSKwithMAC” from above and wait until the controller is fully connected to the MM.

To make this work, you have to create certificates for the MM and all MD’s. In my lab, I use the CA from ClearPass. You can use whatever you like to create the certificates, but keep one thing in mind. The subject of the certificate has to include the MAC of the controller. The MAC, you use, in the commands to configure the MD<–>MM connection later on.

You need 2 certificates for every controller. The root CA certificate and a client certificate. The root CA certificate is the same for all controllers. The client certificate is unique and has the controller MAC address in the subject.

Upload the certificates to the controller. This is the same for every MM and MD. Just different levels of the hierarchy. To upload the client certificate to an MD or MM select the MD or MM in the hierarchy and go to “Configuration–>System–>Certificates–>Import Certificates”:

Controller Deployment - Import Certificate

Controller Deployment – Import Certificate

Select a unique “Certificate Name” and select the certificate from your computer. The certificate includes a private key. A passphrase protects this key. You specify the passphrase during export or creation of the certificate. Enter the passphrase as well. Without the passphrase, the controller is not able to get the private key and cannot use the certificate. Select the “Certificate format” and the “Certificate type”. The client certificate is always a “ServerCert” and the root CA certificate is always “TrustedCA”. Click the submit button to upload the certificate. Do this for all MD’s and the MM.

Next step is to create an entry for MD with a custom certificate on the MM:

(MM) ^*[mm] (config) # local-custom-cert local-mac 00:0b:86:be:84:00  ca-cert flomain-root server-cert mm-mac

Now, you can change the connection settings for the MD with this command in the MD context:

(MM) *[00:0b:86:be:84:00] (config) #masterip 192.168.2.70 ipsec-custom-cert master-mac-1-c 00:0c:29:c7:29:3b ca-cert flomain-root server-cert wlan-controller-mac interface vlan 1

The controller will reboot and use the custom certificate for the connection.

To check if a certificate is used for the authentication, use this command:

(MM) *[mynode] #show crypto isakmp sa 

ISAKMP SA Active Session Information
------------------------------------
Initiator IP                              Responder IP                              Flags       Start Time      Private IP     
------------                              ------------                              -----     ---------------   ----------     
192.168.2.50                              192.168.2.70                              r-v2-c    Nov 15 21:34:12     -                                       

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

Total ISAKMP SAs: 1

The “c” flag indicates, that you use a certificate. To check which certificate, use this command:

(MM) *[mynode] #show crypto isakmp sa peer 192.168.2.50

 Initiator IP: 192.168.2.50
 Responder IP: 192.168.2.70
 Initiator: No
 Initiator cookie:5081e3cdf4f0f5c9 Responder cookie:be8ad9caa747eef7
 SA Creation Date: Wed Nov 15 21:34:13 2017
 Life secs: 28800
 Initiator Phase1 ID: C=DE S=NRW L=Haan O=Flomain OU=WLAN Controller (7005) CN=00:0b:86:be:84:00 E=flo@flomain.de
 Responder Phase1 ID: C=DE S=NRW L=Haan O=Flomain OU=WLAN Controller (VMM) CN=00:0C:29:C7:29:3B E=flo@flomain.de
 Exchange Type: IKE_SA (IKEV2) 
 Phase1 Transform:EncrAlg:AES128 HashAlg:HMAC_SHA1_96 DHGroup:2 
 Authentication Method: RSA Digital Signature 4096-bits
 IPSEC SA Rekey Number: 0
 Ipsec-map name: default-local-master-ipsecmap-00:0b:86:be:84:00
 
(MM) *[mynode] #

You cannot see the name of the certificate but from the “Initiator Phase1 ID” and the “Responder Phase1 ID” you can get the subjects for both certificates. And those match my certificates.

Controller Deployment: ZTP with Activate

To deploy controllers without touching them, you use Activate. Activate is a cloud-based tool to provision devices.

I assume that you are somehow familiar with Activate. The first step is to add the MD to Activate. This step is an automatic process. Aruba adds any device to your Activate account which is ordered from you.

After the device is in Activate, move it to the “Folder” of choice. All devices in this “Folder” get the same provisioning rule.

Create a new “Provisioning Rule” in Activate for the folder with the MD. Change to the “Setup” view and select the folder with the MD. Now click the “New” link in the “Rules” section:

Controller Deployment - Create Provisioning Rule in Activate

Controller Deployment – Create Provisioning Rule in Activate

Select the “Folder” with the MD as the “Parent Folder”. The “Provisioning Type” is “Managed Device to Master Controller”. I do not have any redundancy. But here you can select the type of your redundancy, with “Redundancy Level”. Put the node path into the “Config Node Path” field. This is the hierarchy level on the MM, where the device will be placed. Now, you select the MM mac address from the list of “Master Controller”. This assumes the MM is in Activate as well. You cannot use the ZTP with Activate if you did not add the MM to Activate as well. Also, specify the IP of the MM in “Master Controller IP”. You can also change the “Rule Name” if you need.

For monitoring purposes I also add a “Rule” to notify me of any new provisioning event:

Controller Deployment - Create Monitoring Rule in Activate

Controller Deployment – Create Monitoring Rule in Activate

You simply select the provisioning rule, which triggers the mail notification.

Now, let’s go to the MM. You need to configure Activate in the MM. This is my Activate configuration:

activate
    whitelist-enable
    username "mail@no-spam.com"
    password 60f72ede33b80f645d6d0dbf00a1edb6353552f8727a3f56

“username” and “password” are your Activate credentials. You check the configuration with the following command:

(MM) *[mynode] #show activate 

activate
--------
Parameter                                        Value
---------                                        -----
Activate AP Whitelist Service                    Enabled
Activate Device Whitelist Service                Enabled
Activate URL                                     https://activate.arubanetworks.com/
Provision Activate URL                           https://device.arubanetworks.com/
Activate Login Username                          mail@no-spam.com
Activate Login Password                          ********
Periodic Interval for AP WhiteList Download      1
Periodic Interval for Device WhiteList Download  24
Add-Only Operation                               Enabled
Custom cert to upload to Activate                N/A
Server cert to be used for IPSEC                 N/A

To trigger a sync use this command:

(MM) *[mynode] #activate sync

Now, let’s start the MD. The MD boots up and offers you the wizard, from the scenario above. This time, do not enter anything and wait for the MD to connect to Activate:

Starting auto provisioning
Registered for NTP Sync
Using port gigabitethernet 0/0/1 for auto provisioning
Initiated DHCP, awaiting DHCP response

Auto-provisioning is in progress. It requires DHCP and Activate servers
Choose one of the following options to override or debug auto-provisioning...
    'enable-debug'  : Enable auto-provisioning debug logs
    'disable-debug' : Disable auto-provisioning debug logs
    'mini-setup'    : Start mini setup dialog. Provides minimal customization and requires DHCP server
    'full-setup'    : Start full setup dialog. Provides full customization

Enter Option (partial string is acceptable): 

Received DHCP response, My IP = 10.201.201.206, Mask = 255.255.255.0, GW = 10.201.201.254, DNS = 192.168.2.26
Master info not received from DHCP, trying activate
Provisioning Parameters not received from Activate, will retry after 30 secondsReceived Activate response, My Role = md, Master  = 10.100.100.70, Master MAC = 00:0C:29:C7:29:31, Hostname = 7205-Test, Country code = DE, Redundant Master MAC = none, VPN IP = none, VPN MAC = none, Redundant VPN MAC = none, Secondary Master = none, Secondary Master Mac = none, Redundant Secondary Master Mac = none, Secondary VPN IP = none, Secondary VPN MAC = none, Secondary Redundant VPN MAC = none 
Master = 10.100.100.70 auto-discovered from Activate

copying ca-cert


[20:23:39]:Starting rebootme

The MD get all the information from Activate. These are the information from the provisioning rule, from above. But also the ca-certificate from the MM. To check the certificate from the MM, the MD needs this ca certificate. The MM uploads the ca certificate during the initial sync with Activate.  After the MD has all the information, it reboots. During this time you can check the MM config and search for the new MD:

(MM) *[mm] #show running-config | include local-custom 
Building Configuration...
local-custom-cert local-mac "00:1a:1e:03:21:28" ca-cert factory-ca-cert server-cert self-signed-field-cert

and

(MM) *[mm] #show local-cert-mac 


Local Switches configured by Local Certificate
-----------------------------------------------
Switch IP of the Local  MAC address of the Local  Cert-Type    CA cert          Server cert
----------------------  ------------------------  ---------    -------          -----------
                        00:1a:1e:03:21:28         SS Internal  Factory-CA-Cert  Self-Signed-Server-Cert
                        00:0b:86:be:84:00         Custom       flomain-root     mm-mac
                        00:0c:29:35:c2:c5         Custom       flomain-root     Factory-Server-Cert

Here you see the difference in using a custom certificate or the self-signed certificates for the MM<–>MD connection. This is the MD part if the config:

masterip 10.100.100.70 ipsec-custom-cert master-mac-1-c 00:0C:29:C7:29:31 ca-cert sc-root-ca server-cert factory-cert interface vlan 4094

That is everything. Without ever touching the MD it is up and running on the MM.

Did you use the ZTP function of ArubaOS 8? Or any other ZTP functions of the other products. Tell me what you love about this feature and what you would change to make it even better.

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.

The post ArubaOS 8 – Controller Deployment appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/12/arubaos-8-controller-deployment/feed/ 0 713
Master Standby with ArubaOS 8 https://www.flomain.de/2017/11/master-standby-arubaos-8/ https://www.flomain.de/2017/11/master-standby-arubaos-8/#comments Wed, 29 Nov 2017 12:32:19 +0000 https://www.flomain.de/?p=951 In the last posts about ArubaOS 8, I talked a lot about Virtual Mobility Master. This time, I will not include the VMM in my scenario. The reason is simple. Many customers deploy two controllers today. They simply do not need more. So the big question is how to build an environment with ArubaOS 8 and […]

The post Master Standby with ArubaOS 8 appeared first on Flomain Networking.

]]>
In the last posts about ArubaOS 8, I talked a lot about Virtual Mobility Master. This time, I will not include the VMM in my scenario. The reason is simple. Many customers deploy two controllers today. They simply do not need more. So the big question is how to build an environment with ArubaOS 8 and two controllers. The answer is Master Standby. Likely the same design as with ArubaOS 6.x.

Just to make it clear, you get the most features, the most benefits and the most outcome from a deployment with VMM. So this is just a plan B if you cannot use the benefits of an implementation with VMM.

Master Standby: Requirements

The Master Standby design requires two controllers, obviously. They run in the standalone mode. Keep this in mind during the setup of the controller. Only the active controller can terminate AP’s in this design. But you can use a variation of the fast failover feature.

The design looks like this, from a logical point of view:

Master Standby - Design

Master Standby – Design

The two controller run in standalone mode. I use the master redundancy configuration to synchronize the configuration, user data and of course the licenses. If the master fails, you can use the licenses on the standby for 30 days. Enough time to recover.

To create minimal downtimes during failover, I also create an HA Group. With the HA Group configuration, the AP’s creates a tunnel to each of the controllers. During failover, the AP fails over to the tunnel to the standby controller. This works without a reboot of the AP. Even the radios stay active.

Sounds interesting to you? Read further.

Master Standby: Master Redundancy

The first step to build the above design is to create the master redundancy. To start with master redundancy, I assume you have the two controllers running in standalone mode. Preferably fresh vom the factory or after a factory reset. You have configured them with the initial setup wizard to standalone controllers and they have rebooted.

Login to the one, which will be the active master. In the future, I name them master and standby. On the master, go to “Configuration–>Services–>Redundancy” and select the “Virtual Routing Table”.  Make sure, you are in the device hierarchy and not in the “Mobility Controller” hierarchy. Add a new “Virtual Router” with the “+” sign:

Master Standby - Create VRRP

Master Standby – Create VRRP

Use a meaningful “Description” to avoid confusion later on. I always use the VLAN ID for the “ID”. This assumes I use VLAN 201. This is my controller management VLAN. So both controllers have IP addresses in that VLAN and the controller IP is in this VLAN as well. Enter an “Authentication password” and specify the VRRP “IP address”.  I set the “Priority” of the master to 110, to make sure he is always the master. I also use pre-emption to make sure the master is master again after he is back. Set the “Admin state” to up and select the VLAN.

“Submit” the configuration and configure the same, except for the priority, on the standby. For priority use the value of 100, which is the default.

After some seconds, VRRP is up and running. You can check on the CLI:

(Master) [mynode] (config) #show vrrp


Virtual Router 201:
    Description Master VRRP
    Admin State UP, VR State MASTER
    IP Address 10.201.201.10, MAC Address 00:00:5e:00:01:c9, vlan 201
    Priority 110, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
(Standby) *[mynode] (config) #show vrrp


Virtual Router 201:
    Description 
    Admin State UP, VR State BACKUP
    IP Address 10.201.201.10, MAC Address 00:00:5e:00:01:c9, vlan 201
    Priority 100, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled

The next step is to enable database synchronization. On the master, go to the “Mobility Controller” configuration hierarchy and go to “Configuration–>Services–>Redundancy” and select “Master Redundancy”:

Master Standby - Database Synchronization

Master Standby – Database Synchronization

“Submit” the changes and go down to the controller hierarchy again, but the same configuration page:

Master Standby - Create Master Redundancy

Master Standby – Create Master Redundancy

Add the “Master VRRP” information, this is the VRRP from above and the “IP address of the peer”. This is the IP of the standby. For this lab, I use an “IPSec Key” for “Authentication”. Certificates are possible as well. “Submit” the changes and redo the configuration on the standby, except for the IP address. Here you use the IP of the master. It could take some minutes to form the master redundancy. To check if it is up and running use the command below:

(Master) [mynode] #show database synchronize 

Last L2 synchronization time: Mon Nov 27 04:41:29 2017
Last L3 synchronization time: Secondary not synchronized since last reboot
To Master Switch at 10.201.201.12:  succeeded
To Secondary Master Switch at unknown IP address:  succeeded
WMS Database backup file size: 31093 bytes
Local User Database backup file size: 38393 bytes
Global AP Database backup file size: 12953 bytes
IAP Database backup file size: 3750 bytes
Airgroup Database backup file size: 3052 bytes
License Database backup file size: 5168 bytes
CPSec Database backup file size: 3224 bytes
L2 Synchronization took 2 second
L3 Synchronization took less than one second

16 L2 synchronization attempted
15 L2 synchronization have failed

0 L3 synchronization attempted
0 L3 synchronization have failed

L2 Periodic synchronization is enabled and runs every 1 minute

L3 Periodic synchronization is disabled

Synchronization doesn't include Captive Portal Custom data
(Standby) *[mynode] #show database synchronize 

Last L2 synchronization time: Mon Nov 27 04:41:22 2017
From Master Switch at 10.201.201.11:  succeeded
WMS Database backup file size: 31093 bytes
Local User Database backup file size: 38393 bytes
Global AP Database backup file size: 12953 bytes
IAP Database backup file size: 3750 bytes
Airgroup Database backup file size: 3052 bytes
License Database backup file size: 5168 bytes
CPSec Database backup file size: 3224 bytes
L2 Synchronization took 1 second

8 L2 synchronization attempted
6 L2 synchronization have failed

L2 Periodic synchronization is enabled and runs every 1 minute

Synchronization doesn't include Captive Portal Custom data

I have set the synchronization time to 1 minute. This is to make the waiting time shorter. In production environments, 10 minutes is ok as well.

You could now connect an AP. You would use the VRRP address for the connection between AP and controller. During a failover, the AP would connect to the standby after VRRP changes. But the AP would reboot. To avoid this, we use “HA Groups”.

Master Standby: HA Groups

The “HA Group” feature enables fast failover. To do this, the AP creates a tunnel to the two controllers. The first tunnel is the active one. If the controller for tunnel one fails, the AP uses tunnel two to the second controller. This makes the failover time very short and the best, the AP did not reboot during the failover.

To create an “HA Group”, login to the master controller. Stay in the “Mobility Controller” hierarchy and go to “Configuration–>Services–>Redundancy” and select “HA Groups”. Create a new “HA Group” with the “+” sign:

Master Standby - Create HA Group

Master Standby – Create HA Group

Add the two controllers to the “HA Group”. You can use the role “dual”. “Active” for the master and “Standby” for the standby works as well. Enable “Pre-emption” and “State synchronization”. Enter a “Pre-shared-key” and “Submit” the changes.

The last step is to join the controllers to the group. Stay on the same page as bevor and select “HA Member”:

Master Standby - HA Member

Master Standby – HA Member

 

Select the “HA Group” from the drop-down list “Member of HA group”. Now, the two controllers form an “HA Group”.

You also have to change the LMS IP in the AP group. You can do this in the AP Systems profile as well. I personally, prefer the group. In the same hierarchy level go to “Configuration–>AP Groups” and select the AP group you would like to change:

Master Standby - LMS IP

Master Standby – LMS IP

Select the “LMS” tab and enter the two IP addresses of the two controllers. The master the first one and the standby is the “Backup IP address”. Save the configuration.

All AP’s establish now two connections. One to each controller. To check this use the command below:

(Master) [mynode] #show ha ap table 

HA AP Table
-----------
AP       IP-Address      MAC-Address        AP-flags  HA-flags
--       ----------      -----------        --------  --------
HA-Test  10.201.201.204  94:b4:0f:cb:75:cc  LU        

Total Num APs::1
Active APs::1
Standby APs::0
AP Flags: R=RAP; S=Standby; s=Bridge Split VAP L=Licensed; M=Mesh, U=Up
HA Flags: S=Standby, C=Standby connected, L=LMS, F=Sent Failover Request to AP, H=AP flaged for Inter Controller Heartbeat
(Standby) *[mynode] (config-submode)#show ha ap table

HA AP Table
-----------
AP       IP-Address      MAC-Address        AP-flags  HA-flags
--       ----------      -----------        --------  --------
HA-Test  10.201.201.204  94:b4:0f:cb:75:cc  SLU       

Total Num APs::1
Active APs::0
Standby APs::1
AP Flags: R=RAP; S=Standby; s=Bridge Split VAP L=Licensed; M=Mesh, U=Up
HA Flags: S=Standby, C=Standby connected, L=LMS, F=Sent Failover Request to AP, H=AP flaged for Inter Controller Heartbeat

You see, that the AP is “Licensed” and “Up” in the master and in addition “Standby” on the standby controller. In case of a failure, the AP uses the standby connection to stay active. Because if the synchronization, all user sessions are available on the standby as well. No need for a complete new authentication.

Once the master is back online. All the master functions change back, including the AP termination.

The user might see a small interruption, I had only 8 pings failing in the worst case. Normally around 3-5.

Do you use this design of master standby or do you prefer a design with virtual mobility master? Tell me and leave a comment below.

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.

The post Master Standby with ArubaOS 8 appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/master-standby-arubaos-8/feed/ 3 951
Captive Portal without PEFNG License on ArubaOS8 https://www.flomain.de/2017/11/captive-portal-without-pefng-license-arubaos-8/ https://www.flomain.de/2017/11/captive-portal-without-pefng-license-arubaos-8/#respond Wed, 22 Nov 2017 12:30:40 +0000 https://www.flomain.de/?p=938 On a regular basis, I get the question on how to configure a wireless captive portal without the PEFNG license on the controller. This post is to address this and to show how you can use a wireless captive portal without PEFNG license. Notice, I always recommend using PEFNG license. Not to use PEFNG should […]

The post Captive Portal without PEFNG License on ArubaOS8 appeared first on Flomain Networking.

]]>
On a regular basis, I get the question on how to configure a wireless captive portal without the PEFNG license on the controller. This post is to address this and to show how you can use a wireless captive portal without PEFNG license. Notice, I always recommend using PEFNG license. Not to use PEFNG should only be an exception.

Captive Portal without PEFNG: What is the PEFNG License

Before we start with the technical part, some words on the PEFNG license. I always recommend getting this license as well. It includes very useful features like the following:

  • Fully Stateful Layer 4-7 Firewall
  • Fully user and application-aware
  • Integration with external RADIUS servers
  • and more…

For a full list of features visit www.arubanetworks.com and search for the PEFNG license. Or just use this link to the datasheet:

http://www.arubanetworks.com/assets/ds/DS_PEF.pdf

The main reason I recommend PEFNG is the firewall feature, together with the ability to create individual roles for the users. Without PEFNG you can only use the default roles. But roles are critical and a very important part of security.

Captive portal on ArubaOS depends on roles as well. You use a role to define the URL of the captive portal. This is the reason because a captive portal without PEFNG is tricky. Read further to get it done, even without PEFNG.

Captive Portal without PEFNG: Configuration of a new SSID

I assume you have a VMM (Virtual Mobility Master) and one or multiple MD’s (Managed Devices). I also use the internal captive portal here. But ClearPass should work as well.

To start, log in to the VMM and create a new WLAN. Select the hierarchy level and go to “Configuration–>WLAN” and click the “+” sign:

Captive Portal without PEFNG - Create WLAN

Captive Portal without PEFNG – Create WLAN

As you see, I’m in the “Managed Network” hierarchy level. All controllers get the configuration of this new WLAN, due to the hierarchy level. This is just my lab environment, so I expect your production environment to look different. You should have more hierarchy levels.

The configuration of the new WLAN is easy. On the first page of the wizard, you specify the “Name (ssid)” and the “Primary usage”. For the name, you use a meaningful name. This is the name of the SSID as well. The “Primary usage” is “Guest”. Click the “Next” button at the bottom.

Captive Portal without PEFNG - Create WLAN VLAN

Captive Portal without PEFNG – Create WLAN VLAN

Choose the VLAN for the guest clients. A good practice is to not use VLAN 1. I use VLAN 1 for simplicity in my LAB environment. Click the “Next” button.

Captive Portal without PEFNG - Create WLAN Security

Captive Portal without PEFNG – Create WLAN Security

Select the captive portal you prefer. I use the one with authentication. All the other options should work as well, including ClearPass. you can also customize the captive portal. But this is out of the scope of this post. Click “Next”.

Captive Portal without PEFNG - Create WLAN Access

Captive Portal without PEFNG – Create WLAN Access

Up to this point, everything is normal. Now, the controller should create a new role. This is the “Default role” on the screen above. remember the name, before clicking “Finish”.

“Submit” the changes and wait for the SSID becoming available.

Captive Portal without PEFNG: Check the Roles

In the meantime, let’s check the role. I use the CLI for this. The CLI give more information. Connect to the MD, not the VMM. The VMM is not aware of the role.

This is the list of all roles on the MD:

(ArubaMC-VA) #show rights

RoleTable
---------
Name                   ACL  Bandwidth                  ACL List                                 Type
----                   ---  ---------                  --------                                 ----
ap-role                9    Up: No Limit,Dn: No Limit                                           System
CP-Guest               34   Up: No Limit,Dn: No Limit  CP-Guest/                                User
cpbase                 26   Up: No Limit,Dn: No Limit  cpbase/                                  User
default-iap-user-role  13   Up: No Limit,Dn: No Limit                                           User
denyall                24   Up: No Limit,Dn: No Limit  denyall/                                 User
Gast                   30   Up: No Limit,Dn: No Limit  Gast/                                    User
gast_cppm_sg           32   Up: No Limit,Dn: No Limit  gast_cppm_sg/                            User
guest                  7    Up: No Limit,Dn: No Limit  global-sacl/,apprf-guest-sacl/           User
guest-logon            12   Up: No Limit,Dn: No Limit                                           User
logon                  2    Up: No Limit,Dn: No Limit                                           User
stateful-dot1x         10   Up: No Limit,Dn: No Limit  global-sacl/,apprf-stateful-dot1x-sacl/  System
switch-logon           16   Up: No Limit,Dn: No Limit  switch-logon-acl/                        System
sys-ap-role            14   Up: No Limit,Dn: No Limit  sys-control/,sys-ap-acl/                 System
sys-switch-role        15   Up: No Limit,Dn: No Limit  sys-control/,sys-switch-acl/             System

Total Roles:14
(ArubaMC-VA) #

The one from the screen above is not there. But, there is a role with the same name as the SSID. In my case, this is the “CP-Guest” role. Let’s check this role in detail:

(ArubaMC-VA) #show rights CP-Guest

Valid = 'Yes'
CleanedUp = 'No'
Derived Role = 'CP-Guest'
 Up BW:No Limit   Down BW:No Limit  
 L2TP Pool = default-l2tp-pool
 PPTP Pool = default-pptp-pool
 Number of users referencing it = 0
 Periodic reauthentication: Disabled
 DPI Classification: Enabled
 Youtube education: Disabled
 Web Content Classification: Enabled
 IP-Classification Enforcement: Enabled
 ACL Number = 34/0
 Openflow: Enabled
 Max Sessions = 65535

 Check CP Profile for Accounting = TRUE
 Captive Portal profile = CP-Guest

Application Exception List
--------------------------
Name  Type
----  ----

Application BW-Contract List
----------------------------
Name  Type  BW Contract  Id  Direction
----  ----  -----------  --  ---------

access-list List
----------------
Position  Name      Type     Location
--------  ----      ----     --------
1         CP-Guest  session  

CP-Guest
--------
Priority  Source  Destination  Service      Application  Action        TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  IPv4/6  Contract
--------  ------  -----------  -------      -----------  ------        ---------  ---  -------  -----  ---  -----  ---------  ------  -------  ------  --------
1         user    controller6  svc-https                 captive                                Low                                            6       
2         user    controller   svc-https                 dst-nat 8081                           Low                                            4        
3         user    any          svc-https                 captive                                Low                                            6        
4         user    any          svc-http                  captive                                Low                                            6        
5         any     any          svc-v6-icmp               permit                                 Low                                            6        
6         any     any          svc-v6-dns                permit                                 Low                                            6        
7         any     any          svc-v6-dhcp               permit                                 Low                                            6        
8         user    any          svc-http                  dst-nat 8080                           Low                                            4        
9         user    any          svc-https                 dst-nat 8081                           Low                                            4        
10        any     any          svc-dns                   permit                                 Low                                            4        
11        any     any          svc-dhcp                  permit                                 Low                                            4        

Expired Policies (due to time constraints) = 0
(ArubaMC-VA) #

Much information. The important stuff is the last table. Here are all the rules to redirect the client to a captive portal. You also see the information about the captive portal profile. In the middle, just before the tables starting you find this:

Captive Portal profile = CP-Guest

Let’s check the captive profile as well:

(ArubaMC-VA) #show aaa profile CP-Guest 

AAA Profile "CP-Guest"
----------------------
Parameter                           Value
---------                           -----
Initial role                        cp-guest-guest-logon
MAC Authentication Profile          N/A
MAC Authentication Server Group     default
802.1X Authentication Profile       N/A
802.1X Authentication Server Group  N/A
Download Role from CPPM             Disabled
Set username from dhcp option 12    Disabled
L2 Authentication Fail Through      Disabled
Multiple Server Accounting          Disabled
User idle timeout                   N/A
Max IPv4 for wireless user          2
RADIUS Accounting Server Group      N/A
RADIUS Roaming Accounting           Disabled
RADIUS Interim Accounting           Disabled
RFC 3576 server                     N/A
User derivation rules               N/A
Wired to Wireless Roaming           Enabled
Device Type Classification          Enabled
Enforce DHCP                        Disabled       
PAN Firewall Integration            Disabled
Open SSID radius accounting         Disabled
(ArubaMC-VA) #

Here you can define all the parameters you need to adjust the captive portal. The only thing, which is not correct, the “Initial role”. Adjust this to reflect the correct role. You have to use the one from above, “CP-Guest” (wait and read further before changing the role).

Captive Portal without PEFNG: Create the Correct Role

But here comes the problem. The VMM is not aware of this role. The VMM use the “cp-guest-guest-login” role. If you look into the Web GUI, you will not find any hint of the “CP-Guest” role. You will always see the “cp-guest-guest-login” role. To change this, we create the “CP-Guest” role on the VMM. So, back to the GUI, stay in the same hierarchy level as before. Go to “Configuration–>Roles & Policies” and click the “+” sign:

Captive Portal without PEFNG - Create Role

Captive Portal without PEFNG – Create Role

Create the role with the same name as from the show command in the CLI. Now, the VMM is aware of the role. The last step is to change the initial role for the SSID to the one above. Go to “Configuration–>System–>Profiles” and select the “Wireless LAN–>Virtual AP” profile and look for your “Virtual AP” profile (SSID). Inside your profile search for “AAA”:

Captive Portal without PEFNG - Change Initial Role

Captive Portal without PEFNG – Change Initial Role

Change the “Initial role” to the one from above. “Submit” the changes. Afterwards, connect to the SSID and check for captive portal.

The last part of the above post sounds weird. But it is the only way, I got it working.

To avoid this, just get the PEFNG license as well. It brings much cool stuff and your security colleagues will love it.

Do you always buy the PEFNG license as well? Or you don’t? Tell me why and leave a comment below. 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.

The post Captive Portal without PEFNG License on ArubaOS8 appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/captive-portal-without-pefng-license-arubaos-8/feed/ 0 938
Firmware Update with AOS8 – Aruba OS 8 https://www.flomain.de/2017/11/firmware-update-aos8/ https://www.flomain.de/2017/11/firmware-update-aos8/#comments Wed, 15 Nov 2017 12:30:35 +0000 https://www.flomain.de/?p=729 With AOS8, the update process changes slightly. It is possible to run different versions of code on controllers and the Mobility Master (VMM). This makes updating a lot easier because you do not have to plan for a long downtime, just for a firmware update. In the following post, I show the different options to […]

The post Firmware Update with AOS8 – Aruba OS 8 appeared first on Flomain Networking.

]]>
With AOS8, the update process changes slightly. It is possible to run different versions of code on controllers and the Mobility Master (VMM). This makes updating a lot easier because you do not have to plan for a long downtime, just for a firmware update.

In the following post, I show the different options to upgrade the controller and what strategy I prefer for the upgrade process.

Firmware Update – The Manual Way

This method is completely manual and works great for small environments. You can start with the VMM and update the controller afterward.

To update the VMM, select the VMM in the configuration hierarchy and go to “Maintenance–>Software Management–>Upgrade”:

Firmware Update - VMM

Firmware Update – VMM

I use a local file on my PC and install the image to partition 1. I use partition 1 because the current version is in partition 0. And if something goes wrong, I can boot to partition 0 and I’m back online. I let the controller reboot immediately, after the upload of the image is ready. But before, the controller saves the configuration. Just hit “Upgrade” and wait for the process to finish.

Is the VMM up and running again, you can start to upgrade the Managed Devices (MD). This is one of the only steps, you can only perform on the MD itself. So you have to log in to the MD and go to “Maintenance–>Software Management–>Upgrade”:

Firmware Update - MD

Firmware Update – MD

Same rules as above. Use the partition with the oldest image. I reboot the controller right after the upload, but before, save the configuration. Hit “Upgrade” to start the process.

Repeat this for every MD. This process allows you to update the VMM first and afterward the MD’s step by step. You can start with non-critical controllers, like LAB controller, and afterward the important ones.

Firmware Update – AP Preload Image

With the process above, the controller installs the new firmware first and afterward pushes the firmware to the AP’s. This adds additional downtime. To avoid this, you can configure the controller to preload the image to AP’s and reboot afterward. This reduces the downtime because the AP has the image already. In large environments, the download of the image can take a lot of time. During this time, all AP’s, which are not updated, are down. AP Preload Image avoid this and the AP is up and running right after the controller and the AP has rebooted.

To use this feature, upload the new firmware image to the controller without the reboot option:

Firmware Update - MD without Reboot

Firmware Update – MD without Reboot

Hit the “Upgrade” button and wait for the process to finish.

Afterward, go to “Maintenance–>Access Point–>Preload Image”:

Firmware Update - AP Preload Image

Firmware Update – AP Preload Image

If you see a page with an “Activate” link, use this link to get to the page above. Enable “AP Image Preload” and select the partition with the new firmware. In my setup, I load the image to all AP’s. but you can specify specific AP’s as well. Hit the “Apply” button to start the process.

You get a process summary and an entry per AP:

Firmware Update - AP Preload Image Process

Firmware Update – AP Preload Image Process

After the status for all AP’s is “Preloaded” you can reboot the controller to the new image. The AP’s reboot as well, after they can restore the connection to the controller. But this time, they can just reboot. They do not have to download the image first. This makes the process faster.

You have to configure this for every new upgrade, as the preload feature is disabled after controller reboot.

Firmware Update – Centralized Update

To update all controllers manually work great for small environments. But for larger deployments or deployments with many branch offices, this is not that handy. To make the process for those environments easy as well, you can have something like a centralized update. You only need a central file storage. From this file storage, all the controllers download the image. You do not have to touch every controller. Much better, is it?

I use FTP for the file transfer. You can also use SCP or TFTP. The first step is to configure the file storage location and the protocol in the controller. Log in to the VMM and select a hierarchy level under “/md” where you like to configure the centralized upgrade location. Now go to “Configuration–>System–>Profiles” and search for the “Upgrade” profile under “Controller Profile”:

Firmware Update - Upgrade Profile

Firmware Update – Upgrade Profile

Enter the “Server IP address” and the “File Path”. The “File  Path” is the folder, where the firmware images are stored. If you choose FTP or SCP you need to specify a “Username” and a “Password”. Submit the changes and apply them. This process is only for MD’s. So you need to upgrade the MM with the process above. Do this before updating the MD’s.

To start the update for the MD you need to login to the CLI of the VMM. Here you can start the update process.

Change to the “/md” hierarchy level. From here you can issue the command to start the upgrade:

(MM) *[md] #upgrade managed-devices copy configured-fileserver version 8.2.0.0_61883 path /md/Haan-Live partition 0


upgrade managed-devices
-----------------------
Affected  Ignored
--------  -------
1         1

This command starts the download of the firmware file for version 8.2.0.0_61883. This assumes you have not changed the file name after downloading the file from the Aruba support page. If you use this command with the version parameter, the device selects the correct image from the server, even if you have different controller types in the node. In my case, all controllers under “/md/Haan-Live” are upgraded.

You can see a list of all supported commands here:

http://www.arubanetworks.com/techdocs/ArubaOS_81_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/upgrade_managed-devices.htm%3FTocPath%3DArubaOS%2520Command-Line%2520Interface%2520Reference%2520Guide%7CList%2520Of%2520Commands%7C_____1188

You can see the status of the process with this command:

(MM) *[md] #show upgrade managed-devices status copy all

upgrade managed-node copy command status
----------------------------------------
MAC                Last Cmd   Last Cmd Time             Copy Status     Status Description
---                --------   -------------             -----------     ------------------
00:0b:86:be:84:00  copy-prof  Sat Oct 21 16:18:33 2017  Update success  Successfully updated flash with ArubaOS_70xx_8.2.0.0_61883

From the output above you see that the image upgrade was successful. I did not reboot the device by intent. So I have the chance to preload the AP image to all my AP’s before rebooting the device.

Assume the AP image preload is ready, you can finish the upgrade and reboot the device with this command:

(MM) *[md] #upgrade managed-devices reboot path /md/Haan-Live 
Do you really want to restart the selected managed devices? [y/n]: y


upgrade managed-devices
-----------------------
Affected  Ignored
--------  -------
1         1

After the reboot, the controllers are updated.

The upgrade of a controller cluster is slightly different and I will describe this in a post dedicated to the controller cluster.

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.

The post Firmware Update with AOS8 – Aruba OS 8 appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/firmware-update-aos8/feed/ 1 729
Wired Guest Access with IAP – Aruba Instant https://www.flomain.de/2017/11/wired-guest-access-iap-aruba-instant/ https://www.flomain.de/2017/11/wired-guest-access-iap-aruba-instant/#respond Wed, 08 Nov 2017 12:30:53 +0000 https://www.flomain.de/?p=721 Have you ever heard of someone asking for wired guest access? Why should you use wired guest access, when WLAN is available? For those, who need this kind of guest access, the following post is very interesting. I can think of the following scenarios, where you could need wired guest access: You have a WLAN […]

The post Wired Guest Access with IAP – Aruba Instant appeared first on Flomain Networking.

]]>
Have you ever heard of someone asking for wired guest access? Why should you use wired guest access, when WLAN is available? For those, who need this kind of guest access, the following post is very interesting.

I can think of the following scenarios, where you could need wired guest access:

  1. You have a WLAN installation which does not support captive portal, or you would like to use ClearPass for the captive portal, but your infrastructure does not support captive portal with ClearPass.
  2. You have switches which do not support a captive portal or which do not support captive portal with ClearPass.

Bot scenarios assume, that you put your clients into a guest VLAN and you terminate this guest VLAN on an Aruba IAP. You can also use an Aruba Controller. But for this post, I use an Aruba Instant Access Point (IAP). The only requirement is, that the IAP has at least 2 ethernet ports. I use the IAP225 for this setup.

Wired Guest Access – Topology

The topology for the wired guest access setup is very simple. I have a switch with two VLAN’s, 202 and 203. I use VLAN 202 for the management and VLAN 203 for my wired guest users. Below, is a schema of the physical and logical connection between the IAP and the switch. I highlight only the important information:

 _____               _____
|  S  |             |  A  |
|  W  5---VLAN203---2  P  |
|  I  |             |  2  |
|  T  7---VLAN202---1  2  |
|  C  |             |__5__|
|__H__|

I have a DHCP server in VLAN 202, so the IAP can get an IP address. For VLAN 203, I configure the IAP to serve clients with IP addresses. I use NAT to translate the private addresses in VLAN 203 to the IAP address in VLAN 202. With NAT, you do not have to work with routing. If you prefer routing, you should consider a controller, instead of an IAP.

If you enable LLDP on the IAP and the switch, you might get a warning because of different PVID’s. This is because the IAP use the Magic VLAN 3333 internally. To avoid the warning, configure VLAN 3333 for the guest users.

Wired Guest Access – IAP Configuration

You find the wired configuration in the IAP GUI. Go to “More–>Wired”. Here you find 5 ethernet ports. In my case, Port 0/0 is the uplink port. I use this port for management. As of the time, I write this post, it is not possible to have the management port and a guest VLAN with a captive portal on the same port. This means you need at least two ports in your IAP. So, do not touch port 0/0 or the profile for port 0/0, unless you know what you are doing. For wired guest access, you do not need to change port 0/0.

For IAP’s with two ethernet ports, use port 0/1. First, you have to create a new wired port profile. Select the “New” button in the wired configuration from above:

Wired Guest Access - Wired Configuration

Wired Guest Access – Wired Configuration

Now, you see the “New Wired Network” wizard. It is like the “New SSID” wizard.

Wired Guest Access - Wired Settings

Wired Guest Access – Wired Settings

First, you need to enter a unique “Name” and select “Guest” for the type. You can go to “Next”:

Wired Guest Access - VLAN

Wired Guest Access – VLAN

On the “VLAN” page, select “Access” as the “Mode” and “Virtual Controller managed” for “Client IP assignment”. This ensures, that the IAP use an internal VLAN (3333) for the clients.

The last two tabs are totally your choice. For my setup, I use the internal acknowledge page and no restrictions. You should use what suits your needs. You have the same options as with WLAN based guest networks.

The last step is to assign the profile to the port 0/1. Simply use the drop-down menu and select the profile from above:

Wired Guest Access - Assign Wired Profile to a Port

Wired Guest Access – Assign Wired Profile to a Port

Done! 😊

You can now connect clients to the network and put them into your guest VLAN (203 in my case). They get an IP from the IAP. In my case, they need to accept the T&C’s to get access.

Wired Guest Access – Change Guest VLAN

The method above let you use the magic VLAN 3333 and if you are ok with that, you do not need to continue. But if you like to change the VLAN and the IP addresses, the part below is very interesting.

The first step is to create a local DHCP scope on the IAP. Go to “More–>DHCP Server” and create a new local DHCP scope:

Wired Guest Access - Local DHCP Scope

Wired Guest Access – Local DHCP Scope

The important part is the VLAN. Use the VLAN id you choose for your guest VLAN. In my case, it is 203.  Save the configuration and head back to the wired configuration. You can now change the profile from above. The only change is the VLAN configuration:

Wired Guest Access - Customer VLAN Definition

Wired Guest Access – Customer VLAN Definition

Change the “Client IP Assignment” to “Network Assigned” and the “Access VLAN” to the VLAN from the local DHCP scope. Save the configuration. If you connect your client, it will get an IP from the local DHCP scope from above.

To make it even easier, you can also configure it that way:

Wired Guest Access - Customer VLAN Definition

Wired Guest Access – Customer VLAN Definition

Change the “Client VLAN assignment” to “Custom” and then select the VLAN from the local DHCP server in the new drop-down list. The result is the same as above.

And if you use a custom VLAN and enable LLDP on the IAP and the Switch, there is no warning anymore.

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.

The post Wired Guest Access with IAP – Aruba Instant appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/wired-guest-access-iap-aruba-instant/feed/ 0 721
ClearPass Guest Operator Login with AD https://www.flomain.de/2017/11/clearpass-guest-operator-login-ad/ https://www.flomain.de/2017/11/clearpass-guest-operator-login-ad/#respond Wed, 01 Nov 2017 12:30:22 +0000 https://www.flomain.de/?p=745 ClearPass Guest is one of the most used guest systems and makes it very easy to allow specific people or a group of people to create guest accounts. They can also maintain their own accounts. To allow this you need to configure the ClearPass Guest operator login. The last post about operator login for ClearPass covered […]

The post ClearPass Guest Operator Login with AD appeared first on Flomain Networking.

]]>
ClearPass Guest is one of the most used guest systems and makes it very easy to allow specific people or a group of people to create guest accounts. They can also maintain their own accounts. To allow this you need to configure the ClearPass Guest operator login.

The last post about operator login for ClearPass covered the login for the radius server part. This time it’s all about the guest part of ClearPass. And in contrast to the last post, this is more complex. The main reason for this is, that you will allow more people to access the system. They also have different objectives, but I will explain this later on.

ClearPass Guest Operator Login – Define Operator Profiles

The first step to get this done is to create different operator profiles for different user groups. This is the hard thinking part of this setup. In my lab, I have two different profiles.

  1. Super Administrator
  2. BYOD Operator

The Super Administrator has all the power to do everything. But not all people in the organization can resist such a big power, so I give them only to the network admins. All other people get the BYOD Operator profile. This profile allows them to manage devices they onboard. This assumes you allow device onboarding for people within your organization.

You can also allow your users to create and manage guest accounts. Simply add another profile or modify an existing one. You can do everything if have the Super Administrator power, what you want. The process stays the same as in the following paragraphs.

To create or modify the operator profiles login to ClearPass Guest and go to “Administration–>Operator Logins–>Profiles”:

ClearPass Guest Operator Login - Operator Profiles

ClearPass Guest Operator Login – Operator Profiles

Have a look at the existing ones and use them as possible. Or create a new one. I use the existing ones, “Super Administrator” and “BYOD Operator”.

ClearPass Guest Operator Login – Add ClearPass Roles

To make the management easy. I create roles in ClearPass, with the same name as the profiles from above. Login to ClearPass Policy Server and go to “Configuration–>Identity–>Roles” and click the “Add” button the right upper corner:

ClearPass Guest Operator Login - ClearPass Roles

ClearPass Guest Operator Login – ClearPass Roles

The name has to be unique. Also, create a meaningful description and do this for all ClearPass Guest operator profiles you use.

Now, create a role mapping to use the roles in the authentication process. Go to “Configuration–>Identity–>Role Mapping”. Either us an existing role mapping or create a new one. I use my existing one:

ClearPass Guest Operator Login - ClearPass Role Mapping

ClearPass Guest Operator Login – ClearPass Role Mapping

Rule 6 and 7 are new. So every user in Active Directory, which is a member of the group “Guest-Super-Admin” get the “Super Administrator” role. I evaluate all rules, so a user can have multiple roles. keep this in mind. This is important for the policy, later on.

ClearPass Guest Operator Login – ClearPass Enforcement

Now we are getting to the good stuff. I will reuse as much as possible and keep the current operator login process a life. First of all, I create the new enforcement profiles. Login to the ClearPass Policy Manager and go to “Configuration–>Enforcement–>Profile” and create a new application enforcement profile:

ClearPass Guest Operator Login - Enforcement Profile

ClearPass Guest Operator Login – Enforcement Profile

The above is a “Generic Application Profile”. The interesting part is the attribute part. The “Attribute Name” should be “admin_privileges” and the “Attribute Value” the name of the ClearPass Guest operator profile name. Do this for all ClearPass Guest operator profiles you have.

Now, head over to the enforcement policies. I will copy the existing policy. Search for the “[Guest Operator Logins]” policy and make a copy. Select the policy and hit the “Copy” button in the lower right corner and modify the policy to your needs:

ClearPass Guest Operator Login - Enforcement Policy

ClearPass Guest Operator Login – Enforcement Policy

Use a meaningful name and add conditions for all the enforcement profiles you have created before. I have also moved them up to the top. I include the existing conditions as well. This makes sure, you can log in with the internal admin account.

You need to add as many conditions as enforcement profiles you have. As the policy use the first match condition, start with the ClearPass Guest operator profile, with the most privileges and go down to the one with the least privileges.

ClearPass Guest Operator Login – Authentication Service

The last step is to create the authentication service. We cannot use the existing one, as it is not possible to modify this one. As before, just create a copy of the service and work with the copy. The service to copy is “[Guest Operator Logins]”. Below is the summary of my modified service:

ClearPass Guest Operator Login - Authentication Service

ClearPass Guest Operator Login – Authentication Service

I use my AD as an additional “Authentication Source”. I also use the “Role Mapping” from before and the “Enforcement Policy”. Altogether makes a new service. Now, you need to move the new service before the old one in the list with the “Reorder” button. I put it in position 2. You can now check if it is working. Logout from ClearPass and login to ClearPass Guest with the AD credentials.

The final step is to disable the old default service. Just click the green sign at the end of the row of the list of services. It turns red. Now the old service is disabled. Test if the build in account still works. Just to be prepared for the moment when the AD guy kills the AD.

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.

The post ClearPass Guest Operator Login with AD appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/clearpass-guest-operator-login-ad/feed/ 0 745
ClearPass Operator Login with Active Directory https://www.flomain.de/2017/10/clearpass-operator-login-active-directory/ https://www.flomain.de/2017/10/clearpass-operator-login-active-directory/#comments Wed, 25 Oct 2017 11:30:09 +0000 https://www.flomain.de/?p=738 When you setup ClearPass, you always need to authenticate your operator. In this post, I will describe an easy way to use Active Directory for ClearPass operator login. I use AD here because most of my customers use AD. So, we can work with it and do not have to set up something new or […]

The post ClearPass Operator Login with Active Directory appeared first on Flomain Networking.

]]>
When you setup ClearPass, you always need to authenticate your operator. In this post, I will describe an easy way to use Active Directory for ClearPass operator login. I use AD here because most of my customers use AD. So, we can work with it and do not have to set up something new or use the admin database in ClearPass. This will only create a shadow database with separate passwords and a separate structure.

ClearPass Operator Login – Copy the Existing Service

ClearPass use itself for authentication as well. This means when you hit the login button on the ClearPass login page, ClearPass create a TACACS request and authenticate the user with a service. This service is the default “[Policy Manager Admin Network Login Service]”:

Clearpass Operator Login - Policy Manager Admin Network Login Service

Clearpass Operator Login – Policy Manager Admin Network Login Service

To remove or to disable this service make it impossible for ClearPass to authenticate the operator. So, the best option is to adjust the service to use AD as well. But, this is a default service and you cannot change it. The only option is to copy the service and modify the copy. To copy the service, select the service (check the checkmark at the beginning of the row) and hit the “Copy” button at the below the table. This creates a new service in the last row. Open this service to modify the service:

Clearpass Operator Login - Copy of Policy Manager Admin Network Login Service

Clearpass Operator Login – Copy of Policy Manager Admin Network Login Service

The service is the same as the original one. But we change this soon.

ClearPass Operator Login – Modify the Copy of the Default Service

Select the second tab, “Service” and change at least the name:

Clearpass Operator Login - Service

Clearpass Operator Login – Service

You can also change the description, but actually, the default description is pretty good.

Go to “Authentication”:

Clearpass Operator Login - Authentication

Clearpass Operator Login – Authentication

Add the AD to the list of “Authentication Sources”. I also set it to top of the list as this is my main repository for users. Leave the existing sources in the list.

My users use “user@domain.tld” as authentication name. To strip the “@domain.tld” from the name enable the “Strip Username Rules” and add “user:@”.

Go to the “Roles” tab:

Clearpass Operator Login - Roles

Clearpass Operator Login – Roles

You do not have to use roles mapping. But it makes life easier if you do. I have a default role mapping profile. Every group in my active directory, which is used for authentication and/or authorization has a role in ClearPass. This role mapping profile maps the group from AD to a role in ClearPass. The benefit of role mapping comes on the next tab:

Clearpass Operator Login - Enforcement

Clearpass Operator Login – Enforcement

This is the default enforcement policy. There are many conditions for default roles. I simply match my AD groups to those roles and so I can use the “[Admin Network Login Policy]”. This saves me a lot of time. But, as always, you can, of course, create your own rules and policies. But remember, to have a fallback plan, include the conditions from above in your policy. This makes sure, you can use the local admin account in the condition of disaster. so, change the default password for the admin account to something safe and complicated and hide it somewhere.

ClearPass Operator Login – Activate the Service

To use the new service, you have to move it in front of the old one. Go back to the “Services” list and click the “Reorder” button:

Clearpass Operator Login - Reorder Services List

Clearpass Operator Login – Reorder Services List

Move it to position one. And now, finger crossed that it works. Logout from ClearPass and use an AD account to log in again. To make it, even more secure, use a different browser to test the login without logging out before.

If you are in again, we did it correctly. You can now disable the old service. Just click the green light at the end of the row. It turns red.

Also, test the login with the built-in account, to make sure that the fall back plan is working.

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.

The post ClearPass Operator Login with Active Directory appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/10/clearpass-operator-login-active-directory/feed/ 1 738
Backup ESXi Server – Lab System https://www.flomain.de/2017/09/backup-esxi-server-lab-system/ https://www.flomain.de/2017/09/backup-esxi-server-lab-system/#respond Wed, 20 Sep 2017 11:30:57 +0000 https://www.flomain.de/?p=705 My lab environment is more and more important for some of my daily tasks. But I do not care about the system itself. The only requirement is that it has to run. but as it get’s more and more important I started thinking about a backup. ESXi has no built-in function for this and external […]

The post Backup ESXi Server – Lab System appeared first on Flomain Networking.

]]>
My lab environment is more and more important for some of my daily tasks. But I do not care about the system itself. The only requirement is that it has to run. but as it get’s more and more important I started thinking about a backup. ESXi has no built-in function for this and external tools are mostly expensive, for a lab system. But I found a small tool to backup ESXi server, which is free of charge and works like a charm. But let’s start with the beginning.

Backup ESXi: Starting Position

Currently, I have two ESXi servers in my lab. They run stuff like AirWave, ClearPass, Active Directory, my Mobility Master and a DNS/DHCP server. All my clients need this infrastructure to get access to the lab and the internet. If the ESXi server fails or one of the VM’s get corrupted, the manual recovery will consume a lot of time. So I start looking for a simple backup solution. I have a Synology Disk Station in the lab. My intention is to use the Disk Station for the backups.

The first search offers many tools, but most of them are either expensive and for real production environments or nasty scripts. But some blog posts recommend ghettoVCB from William Lam. He is with VMWare and his tool looks quite promising. There is already the option to use an external NFS store for the backup. And the backup is an online backup. Just what I was looking for, for my lab.

Backup ESXi: Install ghettoVCB

The first step is to install ghettoVCB on the ESXi host. You can download the latest version from GitHub:

https://github.com/lamw/ghettoVCB

I use the vghetto-ghettoVCB.vib file. I also download the latest version of the ghettoVCB.sh file. This file contains some extra fixes for NFS and ESXi 6.5.

Now, permanently enable SSH on the ESXi host. I use the web GUI to do so. you can also use the VMWare vSphere Client for this task:

Backup ESXi - Enable TSM-SSH

Backup ESXi – Enable TSM-SSH

The “TSM-SSH” service is the ESXi SSH server. The SSH server should start with the host. Afterward, you can start the service. In my case, it is already running.

Now, I upload the two files to the ESXi datastore. I use the web GUI for this task as well:

Backup ESXi - Upload Files to ESXi Datastore

Backup ESXi – Upload Files to ESXi Datastore

Connect to the ESXi server with SSH and install the vghetto-ghettoVCB.vib file:

[root@esxi2:~] esxcli software vib install -v /vmfs/volumes/datastore1/vghetto-ghettoVCB.vib -f
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: virtuallyGhetto_bootbank_ghettoVCB_1.0.0-0.0.0
   VIBs Removed: 
   VIBs Skipped: 
[root@esxi2:~]

The “Message” “Operation finished successfully” show that the *.vib file is installed. Now, I replace the ghettoVCB.sh file the latest one:

[root@esxi2:~] mv /vmfs/volumes/datastore1/ghettoVCB.sh /opt/ghettovcb/bin/ghettoVCB.sh

Afterward, make the script executable:

[root@esxi2:~] chmod +x-w /opt/ghettovcb/bin/ghettoVCB.sh

To finally run the script, create a config file. Here is mine:

[root@esxi2:~] vi /vmfs/volumes/datastore1/backup.conf
VM_BACKUP_VOLUME=/vmfs/volumes/backup/ESXi1
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=2
ENABLE_COMPRESSION=1
ENABLE_NON_PERSISTENT_NFS=1
UNMOUNT_NFS=1
NFS_SERVER=192.168.2.20
NFS_MOUNT=/volume1/Data/ESXi-Backup
NFS_LOCAL_NAME=backup
NFS_VM_BACKUP_DIR=ESXi1

For a full list of options, please refer to the ghettoVCB documentation page:

https://communities.vmware.com/docs/DOC-8760

My configuration is very simple. The important part is the NFS section. This configures the NFS store. The “NFS_LOCAL_NAME” and the NFS_VM_BACKUP_DIR” are two parts of the “VM_BACKUP_VOLUME” option.

Backup ESXi: Run ghettoVCB the First Time

Before getting serious, you can test the script with the “-d dryrun” switch:

[root@esxi2:~] /opt/ghettovcb/bin/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/backup.conf -d dryrun
Logging output to "/tmp/ghettoVCB-2017-09-13_10-02-27-890532.log" ...
2017-09-13 10:02:27 -- info: ============================== ghettoVCB LOG START ==============================

2017-09-13 10:02:27 -- info: CONFIG - USING GLOBAL GHETTOVCB CONFIGURATION FILE = /vmfs/volumes/datastore1/backup.conf
2017-09-13 10:02:27 -- info: CONFIG - VERSION = 2016_11_20_1
2017-09-13 10:02:27 -- info: CONFIG - GHETTOVCB_PID = 890532
2017-09-13 10:02:27 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/backup/ESXi2
2017-09-13 10:02:27 -- info: CONFIG - ENABLE_NON_PERSISTENT_NFS = 1
2017-09-13 10:02:27 -- info: CONFIG - UNMOUNT_NFS = 1
2017-09-13 10:02:27 -- info: CONFIG - NFS_SERVER = 192.168.2.20
2017-09-13 10:02:27 -- info: CONFIG - NFS_VERSION = nfs
2017-09-13 10:02:27 -- info: CONFIG - NFS_MOUNT = /volume1/Data/ESXi-Backup
2017-09-13 10:02:27 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 2
2017-09-13 10:02:27 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2017-09-13_10-02-27
2017-09-13 10:02:27 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2017-09-13 10:02:27 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2017-09-13 10:02:27 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2017-09-13 10:02:27 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2017-09-13 10:02:27 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2017-09-13 10:02:27 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2017-09-13 10:02:27 -- info: CONFIG - LOG_LEVEL = dryrun
2017-09-13 10:02:27 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2017-09-13_10-02-27-890532.log
2017-09-13 10:02:27 -- info: CONFIG - ENABLE_COMPRESSION = 1
2017-09-13 10:02:27 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2017-09-13 10:02:27 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2017-09-13 10:02:27 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2017-09-13 10:02:27 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2017-09-13 10:02:27 -- info: CONFIG - VM_SHUTDOWN_ORDER = 
2017-09-13 10:02:27 -- info: CONFIG - VM_STARTUP_ORDER = 
2017-09-13 10:02:27 -- info: CONFIG - RSYNC_LINK = 0
2017-09-13 10:02:27 -- info: CONFIG - BACKUP_FILES_CHMOD = 
2017-09-13 10:02:27 -- info: CONFIG - EMAIL_LOG = 0
2017-09-13 10:02:28 -- info: 
2017-09-13 10:02:28 -- dryrun: ###############################################
2017-09-13 10:02:28 -- dryrun: Virtual Machine: CPPM
2017-09-13 10:02:28 -- dryrun: VM_ID: 2
2017-09-13 10:02:28 -- dryrun: VMX_PATH: /vmfs/volumes/datastore1/CPPM/CPPM.vmx
2017-09-13 10:02:28 -- dryrun: VMX_DIR: /vmfs/volumes/datastore1/CPPM
2017-09-13 10:02:28 -- dryrun: VMX_CONF: CPPM/CPPM.vmx
2017-09-13 10:02:28 -- dryrun: VMFS_VOLUME: datastore1
2017-09-13 10:02:28 -- dryrun: VMDK(s): 
2017-09-13 10:02:28 -- dryrun: 	CPPM_1.vmdk	100 GB
2017-09-13 10:02:28 -- dryrun: 	CPPM.vmdk	20 GB
2017-09-13 10:02:28 -- dryrun: INDEPENDENT VMDK(s): 
2017-09-13 10:02:28 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 120 GB
2017-09-13 10:02:28 -- dryrun: ###############################################

2017-09-13 10:02:28 -- dryrun: ###############################################
2017-09-13 10:02:28 -- dryrun: Virtual Machine: VMM
2017-09-13 10:02:28 -- dryrun: VM_ID: 3
2017-09-13 10:02:28 -- dryrun: VMX_PATH: /vmfs/volumes/datastore1/VMM/VMM.vmx
2017-09-13 10:02:28 -- dryrun: VMX_DIR: /vmfs/volumes/datastore1/VMM
2017-09-13 10:02:28 -- dryrun: VMX_CONF: VMM/VMM.vmx
2017-09-13 10:02:28 -- dryrun: VMFS_VOLUME: datastore1
2017-09-13 10:02:28 -- dryrun: VMDK(s): 
2017-09-13 10:02:28 -- dryrun: 	VMM_1.vmdk	6 GB
2017-09-13 10:02:28 -- dryrun: 	VMM.vmdk	4 GB
2017-09-13 10:02:28 -- dryrun: INDEPENDENT VMDK(s): 
2017-09-13 10:02:28 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 10 GB
2017-09-13 10:02:28 -- dryrun: ###############################################

2017-09-13 10:02:28 -- info: ###### Final status: OK, only a dryrun. ######

2017-09-13 10:02:28 -- info: ============================== ghettoVCB LOG END ================================

[root@esxi2:~]

Check the upper part. You should find all your configurations here. If one is missing, check the configuration file again, and rerun the script.

Backup ESXi: Add Cronjob

Finally, the script should run automatically. In Linux, there is cron. In ESXi, you can use cron as well. It is just not that easy as with normal Linux distributions.

You could simply add the script to the crontab of root. But this modification is gone after rebooting the ESXi server. To make it more sustainable, I use a script during boot of ESXi. The script simply stops the cron daemon, insert the cronjob to the crontab file and restart the cron daemon again. This works for ESXi version 6.5. For older versions, you should check, how to permanently add a cronjob as the precedure might differ.

Open the local.sh file:

[root@esxi1:~] vi /etc/rc.local.d/local.sh

and insert the following lines before the “exit 0”:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0    5    15  *   *   /opt/ghettovcb/bin/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/backup.conf > /dev/null" >> /var/spool/cron/crontabs/root
/usr/lib/vmware/busybox/bin/busybox crond

Afterward, execute the local.sh file and check the crontab:

[root@esxi2:~] vi /var/spool/cron/crontabs/root 

#min hour day mon dow command
1    1    *   *   *   /sbin/tmpwatch.py
1    *    *   *   *   /sbin/auto-backup.sh
0    *    *   *   *   /usr/lib/vmware/vmksummary/log-heartbeat.py
*/5  *    *   *   *   /bin/hostd-probe.sh ++group=host/vim/vmvisor/hostd-probe/stats/sh
00   1    *   *   *   localcli storage core device purge
0    5    15  *   *   /opt/ghettovcb/bin/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/backup.conf > /dev/null

The script added the last line. My script runs every 15th at 5am in the morning. You can, of course, adjust the timing to your needs.

Backup ESXi: Restore VM

Let’s assume I never need this. But if something goes wrong the recovery is simple. The only pitfall, there are some more manual steps as during the backup.

The first step is to mount the backup store. I use the CLI to perform this task. But you can also do this with the web GUI or the VMWare vSphere Client:

[root@esxi2:~] esxcli storage nfs add -H 192.168.2.20 -s /volume1/Data/ESXi-Backup -v backup
[root@esxi2:~] esxcli storage nfs list
Volume Name  Host          Share                      Accessible  Mounted  Read-Only   isPE  Hardware Acceleration
-----------  ------------  -------------------------  ----------  -------  ---------  -----  ---------------------
backup       192.168.2.20  /volume1/Data/ESXi-Backup        true     true      false  false  Not Supported

The first command adds the NFS store to the ESXi server. The second one is just to confirm it is mounted.

The second step is to create a list of VM’s to restore. You can read the full documentation with all the available options here:

https://communities.vmware.com/docs/DOC-10595

For my test VM, the file looks like this:

[root@esxi2:~] vi restore.conf

"/vmfs/volumes/backup/ESXi2/Test/Test-2017-09-14_06-09-30.gz;/vmfs/volumes/datastore1;1;Test"

As before, I do a dryrun to test my file and the configuration:

[root@esxi2:~] /opt/ghettovcb/bin/ghettoVCB-restore.sh -c restore.conf -d 1
GZ found, extracting ...

################ DEBUG MODE ##############
Virtual Machine: "Test"
VM_ORIG_VMX: "Test.vmx"
VM_ORG_FOLDER: "Test-2017-09-14_06-09-30"
VM_RESTORE_VMX: "Test.vmx"
VM_RESTORE_FOLDER: "Test"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "Test.vmdk"
scsi0:0.fileName  = "Test-1.vmdk"
##########################################


Start time: Thu Sep 14 06:30:46 UTC 2017
End   time: Thu Sep 14 06:30:58 UTC 2017
Duration  : 12 Seconds

---------------------------------------------------------------------------------------------------------------

To actually do the restore remove the “-d” option:

[root@esxi2:~] /opt/ghettovcb/bin/ghettoVCB-restore.sh -c restore.conf 
GZ found, extracting ...
################## Restoring VM: Test  #####################
Start time: Thu Sep 14 06:48:56 UTC 2017
Restoring VM from: "/vmfs/volumes/backup/ESXi2/Test/Test-2017-09-14_06-09-30"
Restoring VM to Datastore: "/vmfs/volumes/datastore1/" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/datastore1//Test" ...
Copying "Test.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "Test.vmx" file ...
Option --adaptertype is deprecated and hence will be ignored
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/backup/ESXi2/Test/Test-2017-09-14_06-09-30/Test.vmdk'...
Clone: 100% done.
Registering Test ...
5
End time: Thu Sep 14 06:49:10 UTC 2017
################## Completed restore for Test! #####################


Start time: Thu Sep 14 06:48:43 UTC 2017
End   time: Thu Sep 14 06:49:10 UTC 2017
Duration  : 27 Seconds

---------------------------------------------------------------------------------------------------------------

The VM is restored and registered to the ESXi server. You just need to start the VM again.

The last step is to unmount the NFS store again:

[root@esxi2:~] esxcli storage nfs list
Volume Name  Host          Share                      Accessible  Mounted  Read-Only   isPE  Hardware Acceleration
-----------  ------------  -------------------------  ----------  -------  ---------  -----  ---------------------
backup       192.168.2.20  /volume1/Data/ESXi-Backup        true     true      false  false  Not Supported        
[root@esxi2:~] esxcli storage nfs remove -v backup
[root@esxi2:~] esxcli storage nfs list
[root@esxi2:~]

That’s the whole magic.

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.

The post Backup ESXi Server – Lab System appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/09/backup-esxi-server-lab-system/feed/ 0 705