Connecting the world…

session

ClearPass – concurrent session limit

I tried to configure a restriction to the concurrent number of active sessions a user can have on the wireless network. I found a great article on AirHeads Community “How to deny access for authentication requests based on session limit?

In short the article tells you to:

  1. Edit the Insight Repository
  2. Add more Filiters on the Attributes tab
  3. Enter the following information
    1. Filter Name: sessions
    2. Filter Query: see below
    3. Name: sessions
    4. Alias Name: sessions
    5. Data Type: Integer
    6. Enabled As: Role
  4. Add the Insight Repository as Authorization Source
  5. Create an Enforcement Policy Condition to check the Insight Repository
    1. Type: Authorization:[Insight Repository]
    2. Name: sessions
    3. Operator: GREATER_THAN_OR_EQUALS
    4. Value: <number of allowed simultaneous connections + 1

I configured my ClearPass environment like shown in the article, but I didn’t see any active sessions in the access tracker. The counter remained 0. I connected to the Insight database with the tool pgAdmin to see if the Insight database is updated. The database is updated, so every thing seems to be working.

Be accident I found the solution. The SSID is using EAP-PEAP authentication and users enter there username as <username>@<domain-name>, like rene@booches.nl. This is necessary, because the SSID is configured to work with Govroam. Govroam provides government employees with seamless access to WiFi networks, wherever the service has been made available by participating organisations. To authenticated the users correctly, I configured the CPPM Service with Strip Username Rules.

Strip Username Rules

The SQL query checks the attribute %{Authentication:Username}

select count(*) as sessions from radius_acct where (username = ‘%{Authentication:Username}’) AND end_time is null AND termination_cause is null AND (updated_at BETWEEN (now() – interval ‘1 hour’) AND now());

In the InsightDB the username has the format <username>@<domain-name>, but the attribute %{Authentication:Username} has the format <username>. I saw this “mismatch” while checking the Access Tracker.

ClearPass Access Tracker

I altered the query by changing %{Authentication:Username} into %{Authentication:Full-Username}. After this the session information was correct and I could use the session counter in a Role Mapping or Enforcement Profile to limit the concurrent number of active sessions from a user.

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 224.0.0.251 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!!

Aruba: Split Tunnel with a RAP-5WN

Split Tunneling is technique, which is used very often in (SSL) VPN scenario’s. The RAP-5WN access points has multiple Ethernet ports to connect different components, like workstations or printers. You can configure the usual user roles and other settings on these Ethernet ports.

You can also configure Split Tunneling per Ethernet port. When using Split Tunneling the connected components received an IP address from the company DHCP server. By using access-control lists you can specify the traffic, which is tunnel through the RAP to the central controller. Traffic, which isn’t tunneled, is NAT’ted to the local network by using the IP address of the RAP on the local network.

The configuration example below shows you how to configure Split Tunneling for an Ethernet port on a RAP-5WN. I don’t show you the provision and creation of a VAP for the remote access points. I assume that the RAP is already provisioned and currently all traffic is tunneled to the central controller.

1. The first step involves the creation of the access-control list to specify the traffic to tunnel and the traffic to bridge locally. The access-list shows that the DHCP services (udp/67 and udp/68) and traffic to the network 10.10.10.0/24 is tunnel to the central controller and all other traffic is locally bridged. This is the most important step when configuring Split Tunneling.

ip access-list session rap-split-tunnel-policy
any network 10.10.10.0 255.255.255.0 any  permit
any any svc-dhcp  permit
any any any  route src-nat

2. Next you need to create a user role and associate the previously create access-list to the user role.

user-role rap-split-tunnel-port-role
access-list session rap-split-tunnel-policy

3. The user role needs to be tied to a AAA profile.

aaa profile “rap-split-tunnel-aaa_prof”
initial-role “rap-split-tunnel-port-role”

4. The following step contains the configuration of a wired-ap-profile.. The wired-ap-profile contains the VLAN information for the connected component, the forward-mode and you can enable/disable the Ethernet port. The configured wired-ap-profile puts the client in VLAN 50, enables the port and puts the port in Split Tunnel mode.

ap wired-ap-profile “rap-split-tunnel-wired-ap_prof”
wired-ap-enable
forward-mode split-tunnel
switchport access vlan 50

5. You have all the basics configured and next you need to configure the Ethernet port profile. This profile combines the AAA profile and the wired-ap-profile.

ap wired-port-profile “rap-split-tunnel-wired-port_prof”
wired-ap-profile “rap-split-tunnel-wired-ap_prof”
no rap-backup
aaa-profile “rap-split-tunnel-aaa_prof”

6. The last step is to tie the wired-port-profile to the appropriate AP group. I configured a separate group for remote access points, called remote-o1. The configuration ties the wired-ap-profile to Ethernet 4 on the RAP-5WN.

ap-group “remote-01”
enet4-port-profile “rap-split-tunnel-wired-port_prof”

You are now ready to go!!

PacketShaper Traffic Discovery and Citrix Session Reliability

While troubleshooting some performance issues with Citrix sessions between headquarters and sub locations, I decided to take a closer look at the PacketShaper. The PacketShaper is positioned at the headquarter and does outbound shaping to the sub locations. The PacketShaper is using older software (7.2x), which isn’t necessarily a problem.

I deleted the class for a specific location, created the class again and enabled traffic discovery for that class to check which protocols are used by the sub location.

Traffic Discovery: The PacketWise process of observing and creating traffic classes for all packets as they pass through the unit. This process compiles a list of the protocols and applications in use on a network, creating a traffic tree.

Traffic Discovery is working perfectly, because I see different protocols popping up under the sub locations class under which Citrix. In the past PacketShaper had the opportunity to discover the Published Applications or priority bit tagging used with Citrix. This gave you the opportunity to configure shaping parameters per published application.

Nowadays a lot of Citrix customers use Session Reliability. A major drawback of Session Reliability, in conjunction with a PacketShaper, is the encryption of the data stream. The encryption of the data stream prevents the PacketShaper from discovering the published applications or the priority bit tagging.

I first checked if this problem is solved by the latest software release (8.5 at the time of writing), but it isn’t. BlueCoat acknowledges the problem and describes it in this article. The article contains a link to another article about Manage Citrix Performance, which can be useful when using Citrix without Session Reliability.

Disabling Session Reliability isn’t an option for my troubleshooting, so I guess I have to find another way to troubleshoot the performance issues.

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:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE000

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