Connecting the world…


Aruba RAP in bridge mode with remote access

The Aruba Networks Remote Access Points is a nice feature for branch offices or home workers. I use a RAP5WN at home and I configured different SSID’s on the RAP. The SSID’s are in tunnel mode, split-tunnel mode or bridge mode. The bridge mode connections are for my home devices, like my girls iPad and iPhone.

The RAP5WN has four 10/100 FastEthernet ports. I configured wired ap profiles for these ports and they are also configured in bridge mode. All devices in bridge mode receive an IP address from my local internet router (ADSL) and this works without any problems. Devices in bridge mode can directly communicate with each other.

My local internet router has some port forwarding rules configured so I can access the server from the internet. After using the Aruba RAP and physically moving the server from the local router to the Aruba RAP, I couldn’t access the server anymore. I did some more testing and noticed that I couldn’t connect to any device behind the RAP, when I tried to connect to the devices through the uplink port of the RAP.

I checked the configuration of the RAP and especially the wired AP profiles. I couldn’t find any related configuration parameters to change this behavior. Eventually I found the solution within the AP system profile. The setting Session ACL solved my problem. The explanation for the setting is: Session ACL applied on uplink of a remote AP. By default the session acl parameter is configured as ap-uplink-acl. This acl contains the following entries:

ip access-list session ap-uplink-acl
any any udp 68  permit
any any svc-icmp  permit
any host udp 5353  permit

I changed this setting to the session acl allowall to permit all traffic on the uplink interface.

ap system-profile “custom-ap-system-profile”
session-acl “allowall”
ap-group “home-rap-group”
ap-system-profile “custom-ap-system-profile”

I was able to connect remotely to the server after applying the session acl allowall to the AP system profile, which is connect to the correct AP Group. Problem solved!!

Cisco ASA remote management via VPN

By default, remote access VPN users aren’t able to manage a Cisco ASA firewall on the inside interface using any kind of management protocol (SSH, telnet, HTTPS).

You can enable remote management by specifying the management-access interface. You can specify the interface via the CLI or via the Cisco Adaptive Security Device Manager (ASDM). Both methods are specified below.


fw01/ configure terminal
fw01/ management-access inside



When using the Management Access feature with remote VPN connections (IPSec or SSL VPN) don’t forget to add the VPN pool to the corresponding management access protocols on the interface you specified as management access interface

Configure VPN client on IOS router

One way to remotely access a network is using the Cisco VPN client. Nowadays more and more implementations of SSL VPN are being done and Cisco stopped their development on their VPN client and pushes their Cisco AnyConnect client.

Still the Cisco VPN client is often used to remotely gain access to a network. The Cisco VPN client supports:

  • Windows XP, Vista (x86/32-bit only) and Windows 7 (x86/32-bit only);
  • Linux (Intel);
  • Mac OS X 10.4 & 10.5;
  • Solaris UltraSparc (32 and 64-bit);

The Cisco VPN client is available for download if you have a SMARTnet support contract and encryption entitlements. The client can be used in conjunction with VPN concentrators, PIX and ASA firewall and IOS routers. Below you can find a template configuration for enabling the Cisco VPN client on an IOS router (all used IP addresses and credentials are chosen randomly and don’t represent a real configuration). I used the setup from the picture below:


The configuration uses the local database to authenticate users and split-tunneling is configured to only encrypt traffic destined for the LAN network. With split-tunneling enabled you still can access all local resources and the internet.

aaa new-model
aaa authentication login userauthen local
aaa authorization network groupauthor local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp client configuration group booches-vpn-client
key pr3sh@r3dk3y
domain booches.local
pool vpnpool
acl 110
crypto ipsec transform-set vpn-ts-set esp-3des esp-sha-hmac
crypto dynamic-map dynamicmap 10
set transform-set vpn-ts-set
crypto map client-vpn-map client authentication list userauthen
crypto map client-vpn-map isakmp authorization list groupauthor
crypto map client-vpn-map client configuration address initiate
crypto map client-vpn-map client configuration address respond
crypto map client-vpn-map 10 ipsec-isakmp dynamic dynamicmap
interface FastEthernet0/0
ip address
ip nat outside
crypto map client-vpn-map
interface FastEthernet0/1
ip address
ip nat inside
ip local pool vpnpool
ip nat inside source list 100 interface FastEthernet0/0 overload
access-list 100 deny   ip
access-list 100 permit ip any
access-list 110 permit ip

Citrix Terminal Server License Server problem

One of our customers is using a Citrix NetScaler appliance for SSL VPN capabilities for remote users. I tried to start an application (RDP Client) through this SSL VPN solution, but I couldn’t succeed. I was able to login and I would see all the published applications, but when executing one, I received the following error message:

The remote session was disconnected because there are no Terminal Server License Servers available to provide a license. Please contact the server administrator.

So I did contact customers system engineers, because I thought the problem was related to the customers Terminal Server License Server environment. I thought this, because I was still able to use SSL VPN solutions from other customers. They couldn’t find any solution for my problem and that’s correct.

The solution for the problem is found on my own laptop. I stumbled upon this TechNet article. I opened my registry and deleted the following folder and subkey:


This did the trick. I was able to execute the published applications again without any problem after rebooting my laptop.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

HA redundancy

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address

The configuration of interface redundancy has some caveats as listed below:

  • Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
  • Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
  • Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

  • Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
  • Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
  • Multi-context: one physical firewall is divided in more virtual firewalls;
  • Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

  • No support for VPN services;
  • No support for dynamic routing protocols;
  • No way to configure the sharing of CPU usage between contexts;
  • No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.