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 184.108.40.206 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”
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!!
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/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# 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
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:
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 authentication login userauthen local
aaa authorization network groupauthor local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
crypto isakmp policy 1
crypto isakmp client configuration group booches-vpn-client
dns 192.168.1.10 192.168.1.11
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
ip address 220.127.116.11 255.255.255.240
ip nat outside
crypto map client-vpn-map
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip local pool vpnpool 10.10.1.1 10.10.1.254
ip nat inside source list 100 interface FastEthernet0/0 overload
access-list 100 deny ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255
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.
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.
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.
no ip address
ip address 172.16.10.1 255.255.255.0
ip address 172.16.50.10 255.255.255.0
The configuration of interface redundancy has some caveats as listed below:
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:
Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:
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.