Hot Downloads

How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists

Written by Administrator. Posted in Cisco Routers - Configuring Cisco Routers

4 1 1 1 1 1 Rating 4.00 (4 Votes)
How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists - 4.0 out of 5 based on 4 votes

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.

VPN Client Accessing Company Resources - SQL / Web Server

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 new-model

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
!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp policy 2
 encr 3des
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp client configuration group CCLIENT-VPN
 key firewall.cx
 pool VPN-Pool
 acl 120
 max-users 5
!
crypto isakmp profile vpn-ike-profile-1
   match identity group CCLIENT-VPN
   client authentication list vpn_xauth_ml_1
   isakmp authorization list vpn_group_ml_1
   client configuration address respond
   virtual-template 2
!
crypto ipsec transform-set encrypt-method-1 esp-3des esp-sha-hmac
!
crypto ipsec profile VPN-Profile-1
 set transform-set encrypt-method-1
!
!
interface Virtual-Template2 type tunnel
 ip unnumbered Vlan1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VPN-Profile-1
!
access-list 120 remark ==[VPN Group CCLIENT-VPN Access Lists]==
access-list 120 permit tcp host  192.168.0.6 eq 80 192.168.0.0 0.0.0.255
access-list 120 permit tcp host  192.168.0.6 eq 1433 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:

!
crypto isakmp client configuration group web-sql-group
 key $firewall.cx$
 pool VPN-Pool
 acl 110
 max-users 3
!
crypto isakmp profile vpn-ike-profile-2
   match identity group web-sql-group
   client authentication list vpn_xauth_ml_5
   isakmp authorization list vpn_group_ml_1
   client configuration address respond
   virtual-template 3
!
!
interface Virtual-Template3 type tunnel
 ip unnumbered Vlan1
 ip access-group 121 in
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VPN-Profile-1
!
access-list 110 remark ==[Cisco VPN- WEB Service ]==
access-list 110 permit ip host 192.168.0.6 any
access-list 110 remark
!
access-list 121 remark ==[Virtual Template3 - Restrict Access to 192.168.0.6 - HTTP & MSSQL]==
access-list 121 permit tcp any host 192.168.0.6 eq www
access-list 121 permit tcp any host 192.168.0.6 eq 1433
access-list 121 deny   ip any any
access-list 121 remark

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.

 Back to Cisco Routers Section

Articles To Read Next:

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup