Connecting the world…


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

Tunneling sessions via Plink

Plink stands for PuTTY Link and is a command-line connection tool similar to Unix ssh. As a networking consultant I often need to support customers from remote locations. Access to their networking equipment is mostly blocked from unknown locations. Sometimes it is allowed to directly access networking equipment, like a company firewall, from a known location. An example of such a known location could be the public IP space of my companies headquarters.

But how can I support somebody if I am not at my companies headquarters? Most Unix boys already know the answer to that questions…. SSH (Secure SHell) tunneling.

To create a SSH tunnel you need a SSH server and a SSH client. Most Unix servers can be configured as SSH servers by installing OpenSSH. There are also a lot of SSH server applications for the Windows platform. I configure and place the SSH server at my  headquarters. Since the SSH server uses my companies “allowed” public IP space, the server could connect directly, if allowed, to the customers equipment.

By using the SSH tunnel I use my companies SSH server as some kind of man-in-the-middle server. I connect to my companies SSH server via a SSH remote connection. I configure the connection to forward certain localhost connections from my laptop through the SSH tunnel and let the SSH server setup a new connection to the final destination by forwarding the traffic.

An example would be accessing a Cisco ASA firewall via ASDM from my laptop. At first I create the SSH tunnel to my companies SSH server. I “tell” the connection to forward traffic to my localhost on port TCP/1234 to the SSH server and the SSH server should forward the connection to the customers firewall on port TCP/443. That means that my laptops ASDM application uses my companies public IP space to access the customers firewall. Since my companies public IP space is allowed to access the customers firewall, I can use ASDM on my laptop. Even if I am at a completely different location.

I use Windows 7 as operating system on my laptop, so for SSH tunneling I have to use a third-party application. I always use Plink, which I copy to the C:\Windows\system32 directory, so I can run it from the command-line. Plink can be configured with different parameters, like shown below:

PuTTY Link: command-line connection utility
Release 0.60
Usage: plink [options] [user@]host [command]
(“host” can also be a PuTTY saved session name)
-V        print version information and exit
-pgpfp    print PGP key fingerprints and exit
-v        show verbose messages
-load sessname  Load settings from saved session
-ssh -telnet -rlogin -raw
force use of a particular protocol
-P port   connect to specified port
-l user   connect with specified username
-batch    disable all interactive prompts
The following options only apply to SSH connections:
-pw passw login with specified password
-D [listen-IP:]listen-port
Dynamic SOCKS-based port forwarding
-L [listen-IP:]listen-port:host:port
Forward local port to remote address
-R [listen-IP:]listen-port:host:port
Forward remote port to local address
-X -x     enable / disable X11 forwarding
-A -a     enable / disable agent forwarding
-t -T     enable / disable pty allocation
-1 -2     force use of particular protocol version
-4 -6     force use of IPv4 or IPv6
-C        enable compression
-i key    private key file for authentication
-noagent  disable use of Pageant
-agent    enable use of Pageant
-m file   read remote command(s) from file
-s        remote command is an SSH subsystem (SSH-2 only)
-N        don’t start a shell/command (SSH-2 only)
-nc host:port
open tunnel in place of session (SSH-2 only)

The best way to use Plink is by creating a batch file, which can be run from the command-line. My batch file looks like this:

@echo off
plink.exe -v -x -a -T -C -noagent -ssh -L <username>@<IP SSH server>

The command configures a SSH connection to <IP SSH server> using username <username>. All connections from my laptop to on TCP/1234 are forwarded by the SSH server to the remote IP address on TCP/443. You can add more statements to the batch file, by just adding another –L command, like shown below.

@echo off
plink.exe -v -x -a -T -C -noagent -ssh -L -L <username>@<IP SSH server>

After executing the batch file, you will receive a login prompt to enter the user credentials for the SSH server. After entering the credentials you are ready to go. Just start ASDM or another application and connect to the localhost on port TCP/443 or TCP/22. The traffic will be forwarded through the SSH tunnel and from the SSH server to the final destination.

Of course you need to make some preparations to use this solution, like installing the SSH server and publishing the SSH server to the internet. You also need to have SSH access on the remote location, because else you cannot create the SSH tunnel.

Since you are publishing a server to the internet, it is important to “strip” that server. Make sure there are no vulnerable or unnecessary services running on the server and always patch the server to the appropriate level. It is also recommended to use some kind of two-way authentication, like one-time passwords. That way you know you have a secure environment to access the assets at the final destination.

In the end you will have a secure environment with which you can support your customers or access other resources on the internet or on your internal network.

Strange VPDN-GROUP behavior

I noticed some strange behavior in a vpdn-group configuration on a Cisco 876 router. I have a router with the following vpdn-group configuration:

vpdn-group pptp-group
! Default PPTP VPDN group
description pptp vpn users
protocol pptp
virtual-template 10

The configuration is working perfectly and users can dialin using a PPTP connection. Backups of the configuration are made by Kiwi CatTools. Lately I noticed that the following command l2tp tunnel receive-window 256 is added to the configuration, like displayed below:


Cisco has the following explanation for the command:

“Use the l2tp tunnel receive-window command to set the size of the advertised control channel receive window. The receive window size controls the number of L2TP control packets that can be queued by the system for processing. Increasing the size of the control channel receive window allows the system to open PPP sessions more quickly; a smaller size is desirable on networks that cannot handle large bursts of traffic… Source

Two days later the command is gone again. I asked the network engineers if they made any changes to the configuration, but they didn’t. I looked at the configuration and tried to add the command, but I am not able to add the command.

cisco-876(config)#vpdn-group pptp-group
cisco-876(config-vpdn)#l2tp tunnel receive-windows 256
% Invalid input detected at ‘^’ marker.


I searched a little further and the command can only be added, when the dial-in protocol is changed from pptp to l2tp. Looking at the configuration above, you can see clearly that the dial-in protocol pptp is configured and the l2tp command is added.

I cannot explain this behavior. I hope some of you can…….

VPN Filtering through Group Policy

When configuring a Remote Access VPN or a Site to Site VPN connection you have the ability to filter traffic entering and leaving the VPN connection. You have the ability to enable inbound IPsec sessions to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic.

The sysopt connection permit-ipsec command allows all the traffic that enters the security appliance through a VPN tunnel to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. In PIX 7.1 and later, the sysopt connection permit-ipsec command is changed to sysopt connection permit-vpn.


Mostly I use this option and configure some extra ACL’s to filter trafifc. Some customers don’t want to use this option and want to specify all traffic with ACL’s. This is more secure, but is a bigger burden on the management of the firewall.

From IOS 7.1 and later you have the ability to configure VPN filtering through Group Policies. In short you configure an extended ACL, link this ACL to a Group Policy and link the Group Policy to the specific Tunnel Group. The syntax (source and destination) needs to be correct for the ACL to work.

For Site to Site VPN’s the remote network is the source and the local network is the destination. For Remote Access VPN’s the VPN IP pool is the source and the local network the destination, as specified below.

An ACL that is used for a vpn-filter must not also be used for an interface access-group. When a vpn-filter is applied to a group-policy/user name mode that governs Remote Access VPN Client connections, the ACL must be configured with the client assigned IP addresses in the src_ip position of the ACL and the local network in the dest_ip position of the ACL. When a vpn-filter is applied to a group-policy that governs an L2L VPN connection, the ACL must be configured with the remote network in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.


Exercise caution when you construct the ACLs for use with the vpn-filter feature. The ACLs are constructed with the post-decrypted traffic (inbound VPN traffic) in mind. However, they are also applied to the traffic originated in the opposite direction.

More about this matter and examples configurations can be found here.