About René Jorissen

René Jorissen works as Solution Specialist for 4IP in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like Cisco, Aruba Networks, FortiNet, HP Networking, Juniper Networks, RSA SecurID, AeroHive, Microsoft and many more. René is CCNP , Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

ClearPass & Sophos Mobile Control

A lot of companies are using MDM to control and manage their (mobile) assets. By connecting the MDM solutions to HPE Aruba ClearPass an organization has the possibility for advanced context-aware access for a (mobile) device to the corporate network, wired and wireless. ClearPass supports multiple MDM solutions via built-in “External Context Servers”, like Airwatch and MobileIron.

The MDM solution from Sophos, Sophos Mobile Control, has no built-in integration with ClearPass. I needed to help a customer to link ClearPass with Sophos Mobile Control, because the customer would like to distinguish BYOD from corporate devices. All corporate devices are managed via Sophos Mobile Control. In this setup, Sophos Mobile Control uses an MSSQL database to store all relevant information. One of the tables in the MSSQL database stores the Wi-Fi MAC address from the asset. I use this table to distinguish the BOYD devices from the corporate devices. If the MAC address of the device is present in the database, the device is a corporate device.

I started by adding the MSSQL database as an authentication source to the ClearPass configuration. The customer created a dedicated SQL user with read-only access to the database. The MSSQL database is added in ClearPass under Configuration – Authentication – Sources. I added a source from the type “Generic SQL DB”.

The next step involves the creation of a proper SQL filter statement. I would like to have the Wi-Fi MAC address as output from the SQL filter. The following SQL filter is used for this (with special thanks to the customer, who had some more experience with SQL statements!!!!)

SELECT LOWER(deviceproperty.value) AS mac_address FROM deviceproperty INNER JOIN device ON deviceproperty.deviceid = device.deviceid WHERE deviceproperty.propertykey = ‘Wi-Fi MAC address’ AND device.managed = ‘managed’ AND deviceproperty.value = ‘%{Connection:Client-Mac-Address-NoDelim}’;

I would like to use the MAC address as a string in the authentication/authorization process. In the end I will check if the MAC address in the RADIUS requests matches a MAC address in the Sophos MDM database. The SQL filter is added in the Filter option within the Authentication Source, like in the image below. Just go to the Attributes tab and choose the option Add More Filters.

The Authentication Source is added to the appropriate Service as Authorization Source. I always add the Source first, before I start to configure some Roles and Role Mappings, because I would like to see which output I receive from the MSSQL database. There are two possible outcomes:

  1. The MAC address exists in the MSSQL database
  2. The MAC address doesn’t exist in the MSSQL database

If the MAC address exists in the MSSQL database, you will see the value of the MAC address in the Access Tracker.

As you can see the MAC address is listed without any delimiter. If the MAC address doesn’t exist in the database, the MAC address won’t be listed in the Access Tracker and you will see the following Alert Message.

Now that we know, which information we receive in the Access Tracker during an authentication request, we can configure the correct Roles and Role Mappings. In this example I assign the Role [VDI Trusted] to the device, when the MAC address from the device equals the MAC address in the MSSQL database.

The last step is easy. Just configure the appropriate Enforcement Policy and Profile you match the Role and set the correct attributes on the Wi-Fi or wired network.

Cisco Catalyst 2960X keeps crashing

Yesterday evening I had to troubleshoot a Cisco Catalyst 2960X switch stack, which didn’t return to normal after a reboot. The following error message was visible on the console:

Error: ASIC/PHY POST failed. Cannot continue.

%Software-forced reload

This error message is listed as a bug (CSCut90593) at Cisco.com. Cisco describes a very “good” workaround: the switch can boot up normally after this crash. I tried to reboot the switch several times, but it didn’t boot normally. The stack is running Cisco IOS version 15.2(2)E6 and the bug should be fixed in 15.2(2)E3.

It took me till midnight to recover the stack, so I am done troubleshooting and I will start the RMA procedure. I have to say that I am not really happy with the Cisco Catalyst 2960X. I have several customers running this type of switch and I had a lot more “troubles” with this switch, then I have/had with other Cisco switches. I hope stability will improve!!!!

Cisco WLC – HA SSO upgrade

“Is the upgrade procedure for a high-availability pair of Cisco Wireless LAN Controllers the same as the procedure for a single Cisco WLC?” Several customers asked me this questions and the answer is YES.

First you check the current and backup firmware image.

(Cisco Controller) >show boot
Primary Boot Image…………………………. 8.2.111.0 (default) (active)
Backup Boot Image………………………….. 8.1.102.0

Next you check if your SSO configuration is working as expected.

(Cisco Controller) >show redundancy summary
Redundancy Mode = SSO ENABLED
Local State = ACTIVE
Peer State = STANDBY HOT
Unit = Primary
Unit ID = 00:81:C4:87:3B:C9
Redundancy State = SSO
Mobility MAC = 00:81:C4:87:3B:C9
BulkSync Status = Complete
Average Redundancy Peer Reachability Latency = 177 Micro Seconds
Average Management Gateway Reachability Latency = 935 Micro Seconds

Upload the new firmware to the controller by using an TFTP or FTP server. I am using an TFTP server in this example.

(Cisco Controller) >transfer download datatype code
(Cisco Controller) >transfer download filename AIR-CT5520-K9-8-2-141-0.aes
(Cisco Controller) >transfer download path .
(Cisco Controller) >transfer download serverip 10.200.8.83
(Cisco Controller) >transfer download mode tftp
(Cisco Controller) >transfer download start

After the TFTP session is finished you’ll notice that the the software is automatically transferred from the active to the standby unit.

TFTP Code transfer starting.

TFTP receive complete… extracting components.

Checking Version Built.

Image version check passed.

Informing the standby to start the transfer download process

Waiting for the Transfer & Validation result from Standby.

Standby – Standby receive complete… extracting components.

Standby – Image version check passed.

Transfer & validation on Standby success, proceed to Flash write on Active.

Writing new AP Image Bundle to flash disk.

Executing fini script.

File transfer is successful.
Reboot the controller for update to complete.
Optionally, pre-download the image to APs before rebooting to reduce network downtime.

Transfer Download complete on Active & Standby

The last step is to reload both controllers to activate the firmware. After you reboot the active controller, you are able to access the standby controller and reboot that controller too. You have the option to reboot both controllers with one command.

(Cisco Controller) >reset system both in 00:05:00 image no-swap reset-aps

The controller also has the option to pre download the firmware from the controller to the access-points. This speeds up the upgrade process for the access-points, because the access-point don’t need to download the firmware after the controllers are online again. The access-point only need to reboot when the loose the connection with the controller. I will describe this process in a separate post.

After the controllers are back online, you should check the primary and backup boot firmware to see if the upgrade was successful.

(Cisco Controller) >show boot
Primary Boot Image…………………………. 8.2.141.0 (default)
Backup Boot Image………………………….. 8.2.111.0 (active)

ClearPass – dual interface and routing

When you are using both interfaces on a ClearPass server (MGMT and DATA) than ClearPass uses the DATA interface to connect to services, like LDAPS to Active Directory, SMTP delivery, Active Directory joining and more. ClearPass uses the DATA interface as default gateway if no specific route is available on the MGMT interface.

That being said, you have the option to add routes to the ClearPass routing table. Routes are added via the ClearPass shell. Use the following command to add a route.

Usage:

network ip add <mgmt|data|greN|vlanN> [-i <id>] <[-s <SrcAddr>] [-d <DestAddr>]> [-g <ViaAddr>]

Where:

  • greN — Name of the gre tunnel where N corresponds to the gre
    tunnel number ranging from 1,2,3…N
  • vlanN — Vlan interface where N corresponds to the vlan id ranging from 1,2,3…N. For example if the configured vlan identifier is ’85’ then input ‘vlan85’
  • -i — Optional parameter. Id of the network ip rule. If unspecified the system will auto generate the Id
  • -s <SrcAddr> — Optional parameter. The source interface ip address or netmask from where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -d <DestAddr> — Optional parameter. The destination interface ip address or netmask where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -g <ViaAddr> — Optional parameter. The via or gateway ip address through which the network traffic should flow. The allowed value is valid IP Address

An example:

[appadmin@CPPM01]# network ip add mgmt -d 10.10.10.0/24 -g 20.20.20.1
INFO – Added route for destination=10.10.10.0/24 via=20.20.20.1
INFO – New ip rule created with the id = 12000

You can check the routing table via the command: network ip list.

Cisco FMC – Dashboard Widgets

Some widgets on the dashboard don’t generate graphs after deploying a default configuration of Cisco FireSight Management Center.

The first two widgets, Top Server Applications Seen and Top Operating Systems Seen, are generated after the configuration of a Network Discovery Profile. The configuration of the Network Discover Profile is done via Policies – Network Discovery – Networks. I always configure a Network Discovery Profile to profile all Hosts, Users and Application for the RFC1918 IP address space.

To generate graphs for the URL widgets, you need to make sure that the correct options for the URL filtering service are enable. The URL filtering service configuration is done via System – Integration – Cisco CSI. I use the following settings for URL filtering.

After this you should wait a while (about one hour) to check if the graphs are generated. If you don’t want to wait, you can check the Analysis tab to see if information is gathered and displayed by the Cisco FireSight Management Center appliance.