How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists
In our article Cisco VPN Client Configuration - Setup for IOS Router we explained how to setup up a Cisco IOS router to support Cisco IPSec VPN clients, allowing remote users to securely connect to the company network and access the available resources.
It is recommended that users with little or no experience on Cisco router VPN client configuration read our Cisco Router VPN Client Configuration article before proceeding.
Restricting access to your IPSec VPN clients (or Groups) is possible with the use of standard or extended access lists, which are applied to the crypto isakmp client configuration group section.
The problem many administrators and Cisco engineers are faced with is even though usage of extended ACLs, defining layer-4 services such as TCP or UDP, is allowed, the router will only apply up to layer-3 access list information. Layer-4 information in the defined access lists is completely ignored.
Layer-4 VPN Access Lists Ignored? What Does this Mean?
To put it simply, if there is a need to restrict Cisco IPSec VPN clients to layer 4 services e.g. http access (TCP port 80) or MSSQL access (TCP port 1433) to an internal server (e.g 192.168.0.6), you’d be surprised to know that even though the vpn group access lists can be defind to restrict access to these services, vpn clients will have full access to host 192.168.0.6 when connecting to the VPN!
The Cisco IOS Router will completely ignore any layer 4 information (TCP – UDP) available in the extended access lists applied to the VPN group.
Let’s take for example the following configuration, designed to restrict our CCLIENT-VPN VPN group to host 192.168.0.6 and TCP ports 80 & 1433:
aaa authentication login default local
aaa authentication login vpn_xauth_ml_1 local
aaa authorization network vpn_group_ml_1 local
aaa session-id common
access-list 120 permit tcp host 192.168.0.6 eq 80 192.168.0.0 0.0.0.255
When a VPN client belonging to the CCLIENT-VPN group connects, he is expected to have access to host 192.168.0.6 and the defined (by the ACLs) services - TCP ports 80 & 1433 - right? Wrong!
Access lists under the crypto isakmp client configuration group are not filtering access lists. Their purpose is not to control Layer-4 services, but identify the network routes the remote VPN user(s) will have access to. This is also called Split-Tunneling.
It is for this reason the IOS router will allow full access to our host 192.168.0.6. TCP/UDP services, located on Layer-4 of the OSI model, are completely ignored when defined in VPN group access lists.
As a result, this design or limitation (if you like) is a big problem for many network administrators and engineers as it does not provide the flexibility and granularity required in today’s complex and demanding VPN networks.
The Solution to Making Extended ACLs Work For Cisco IOS VPN Clients – Restricting VPN Clients to Layer 4 Services
Despite the setback, it is possible to control access to layer 4 TCP/UDP services for your VPN groups. The solution involves creating different Virtual-Template interfaces to which the ISAKMP profiles, and therefore VPN groups, are bound. We then create a new set of access lists and apply them to the Virtual-Template in the inbound direction as shown below:
Notice how we still use a set of access-lists (110) for our new group web-sql-group, restricting access to host 192.168.0.6. These will ensure the VPN group will be able to access the particular host.
Next, we create a new set of access-lists (121) which are placed under the new Virtual-Template3 in the inbound direction. These are the extended access-lists that do the job.
Keep in mind that these access-lists must always be placed in the inbound direction of the Virtual-Template3 interface, to ensure they work correctly and block other types of VPN user traffic from reaching our network or hosts.
Finally, it is equally important to pay attention to the crypto isakmp profile vpn-ike-profile-2 command, which essentially maps the VPN group with our new Virtual-Template3 interface. If there is a need to create additional vpn groups with restricted access, all that is required is to configure new crypto isakmp profiles and Virtual-Templates along with the necessary access lists as shown by this example.