AirWave & VMware Tools installation

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

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

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

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

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

VMware: upgrade VMware Tools and Virtual Hardware for Microsoft ISA array

Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.

A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.

Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.

RSA 7.1 with On-Demand

RSA token security provides a way to strengthen the security on public services. Token authentication is most often implemented with hardware tokens. RSA 7.1 has additional methods of token authentication besides the hardware tokens:

  • Token delivery by SMS;
  • Token delivery by e-mail;

To enable the above features you have to install at least RSA 7.1 and obtain a On-Demand license, like shown below:


Next I will show you how to configure token authentication for the delivery of tokens through SMS and e-mail. My test environment contains a RSA Authentication Manager 7.1 with RADIUS server installed on a Windows 2003 R2 server under VMware. The RSA server has a LDAP mapping to Active Directory for authenticating users.


The first method explained is configuring RSA to deliver tokens to an e-mail address. The first step is configuring a SMTP server on the RSA server. In this scenario I create a SMTP connection to a Windows Exchange 2003 server. rsa-od-mailIn the Security Console, navigate to Setup – Instances and edit the instance you would like to use for the SMTP connection.

In the SMTP setup you need to configure the Hostname of the SMTP server and a “from” e-mail address. Some SMTP servers require authentication to use them as relay server. If your SMTP server requires authentication you can configure the appropriate user credentials. In my situation I only need to deliver mail to the domain, so I don’t need to configure authentication or assign relay rights to the RSA server on the Exchange server. If you would like to deliver e-mail to domains outside your mail environment, you have to configure authentication or relay access for the RSA server.

rsa-od-ena-mail After configuring the SMTP server you have to enable the ability to deliver token codes by e-mail. Navigate to Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes in the Security Console. Enable the option “Delivery by E-mail” and choose the User Attribute to Provide E-mail Destination. This User Attribute is obtained by default through LDAP. In my scenario I use the e-mail field within Active Directory to obtain the specific e-mail address from a user.

rsa-od-user-mail From now on you can enable the usage of e-mail token delivery to your users. To accomplish this navigate to Identity – Users – Manage Existing and search for a specific user. Go to Security Tokens for the specific user and enable “On-Demand Tokencodes” and the specific settings, like shown in the picture. I configured an initial PIN for the user. The user should be able to obtain a token code through SMS via the Self-Service console. This portal can be reach via the URL: https://<ip address / FQDN RSA server>:7004/console-selfservice.

On-Demand token codes have a PIN code associated to the delivered token code. This PIN code is different from the PIN code of normal hardware tokens. I normally enable the On-Demand feature for a user and specify the first initial PIN code. After the user logs in with this PIN code, the PIN code needs to be changes. There are two ways of doing this:

  1. The user automatically receives a new PIN code, which is generated by the RSA server;
  2. The user has the option to manually specify a new PIN code;

rsa-od-token-policy Most often system engineers let the customers choose there own PIN code. Toggling between both settings is possible by changing the Token Policy. Changing the Token Policy is possible by navigating to Authentication – Policies – Token Policies.


To configure SMS token delivery you need some kind of method to send SMS messages. RSA and Clickatell have partnered to enable delivery of SecurID tokencodes to mobile devices via SMS/text. RSA Authentication 7.1 has a build-in method for delivering SMS messages through Clickatell. Click here to obtain more info about the partnership between RSA and Clickatell and how to register a (trial) Clickatell account.

The first step is to link a User Attribute from the Active Directory to RSA. This User Attribute contains the phone number for delivering the SMS. To such link navigate to Identity – Identity Attribute Definition – Add New.


Within Active Directory you can configure multiple Telephone numbers for a user. Because the SMS is sent to the users mobile phone, I enter the appropriate phone number under the mobile Telephone number of the users.

The picture shows how to configure the the User Attribute mapping. The Attribute Name is a user friendly name to identify the mapping. I choose Personal as Category and the Entry Type is optional. The users mobile phone number is displayed under Personal when editing the user.

The Identity Source Mapping defines the LDAP attribute to use for obtaining the mobile phone number from the user. This value has to be exactly the same as the LDAP value for the mobile phone number in Active Directory. I use Softerra’s LDAP browser to obtain this value from Active Directory. Softerra LDAP browser is a useful tool for browsing LDAP directories.


The configuration of the SMS service provider can be found under Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes.

You need to enable the option “Delivery by SMS”, choose the previously configured User Attribute, select your country code and provide the credentials for your Service Provider.

You can now switch between token code delivery by e-mail and SMS. A user has the option to choose the preferred delivery method via the Self-Service console. Users need access to the Self-Service console to request a token code. The Self-Service portal needs to be securely published to the internet. This can be achieved by using a reverse proxy or some comparable solution. The following PDF contains a quick howto for publishing the RSA environment securely to the internet.

RSA 7.1 supported under ESX 3.5

More and more people would like to implement OTP (One Time Password) solutions. RSA is one of multiple vendors for OTP solutions. I also notice the wish to implement and support OTP with on-demand tokens, like SMS and e-mail.

RSA supports on-demand tokens, but the minimum RSA Authentication Manager version required is 7.1. Not only on-demand tokens, but also virtualization (like VMware) is very hot. For a long time, RSA 7.1 was only supported on physical servers. Running RSA 7.1 on a physical server doesn’t always perform very well, especially compared to RSA 6.1. This version performs well on a physical server as well on a virtual server.

RSA Authentication Manager 7.1 is now supported under VMware ESX server, hosting 3.5. You can check all supported platforms on the RSA website.

I guess I have to install this version under ESX to see how it performs, but maybe someone can tell me their own experience….

Cisco ASA & ESX: strange ARP behavior

Last week I had a very strange problem with a Cisco ASA firewall. The firewall is configured with multiple interfaces, including a DMZ interface. There are multiple servers in the DMZ. These servers are physical and virtual servers. The virtual servers are VMware servers in a blade environment.

I configured the feature

ip verify reverse-path interface DMZ

to prevent spoofing to occur. I also configured a transparent static NAT rule between the Inside network and the DMZ network and multiple static NAT rules between the DMZ network and the Outside network. I left the proxy ARP feature configured with its default settings.

The customer was complaining about log in problems and connectivity problems on the DMZ servers, especially between different DMZ servers. I have done some research and noticed that all problems were related to DMZ servers in the blade environment.

I started some connectivity test and noticed some strange ICMP behavior on the specific servers. When I started a ping from one DMZ VMware server to an other DMZ server on the same ESX host, the first ping responded with an echo-reply, but consequent pings failed. Looking at the ARP table of the server, I noticed that the firewall responded with its own MAC address for every ARP broadcast.

Looking at different forums on the Internet, everybody is speaking about the proxy ARP feature and that you should disable this feature. By default proxy ARP is enabled and I always leave it enabled. Till now I never had this problem. After disabling the proxy ARP feature for the DMZ interface

sysopt noproxyarp DMZ

the problem was solved, because the firewall doesn’t respond to the ARP queries, except for its own interface. Digging a bit deeper on forums, I never found one thread who explains why the proxy ARP feature should be disabled to solve this particular problem.

In my opinion this problem is related to the VMware environment, because I don’t have these problems with physical DMZ servers. So it is strange why the DMZ servers on the same ESX hosts cannot see each other and why does the firewall respond to the ARP queries?

In the near future the blade environment (ESX hosts, network configuration and SAN configuration) is changed, so I hope to find the exact cause and solution of the problem. Does anybody else have some suggestions??