Configuring the Cisco VPN 3000 Concentrator for Blocking with Filters and RADIUS Filter Assignment

Introduction

In this sample configuration, we want to use filters to allow a user to access only one server (10.1.1.2) inside the network and block access to all other resources. The Cisco VPN 3000 Concentrator can be set up to control IPsec, Point-to-Point Tunneling Protocol (PPTP), and L2TP client access to network resources with filters. Filters consist of rules, which are similar to access lists on a router. If a router was configured for:

access-list 101 permit ip any host 10.1.1.2 
access-list 101 deny ip any any

the VPN Concentrator equivalent would be to set up a filter with rules.

Our first VPN Concentrator rule is permit_server_rule, which is equivalent to the router's permit ip any host 10.1.1.2 command. Our second VPN Concentrator rule is deny_server_rule which is equivalent to the router's deny ip any any command.

Our VPN Concentrator filter is filter_with_2_rules, which is equivalent to the router's 101 access list; it uses permit_server_rule and deny_server_rule (in that order). It is assumed that clients can connect properly prior to adding filters; they receive their IP addresses from a pool on the VPN Concentrator.

Refer to PIX/ASA 7.x ASDM: Restrict the Network Access of Remote Access VPN Users in order to learn more about the scenario where the PIX/ASA 7.x block the access from the VPN users.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on Cisco VPN 3000 Concentrator version 2.5.2.D.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Network Diagram

This document uses this network setup:

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

VPN 3000 Configuration

Complete these steps in order to configure the VPN 3000 Concentrator.

1. Choose Configuration >Policy Management > Traffic Management > Rules > Add and define the first VPN Concentrator rule called permit_server_rule with these settings:

   • Direction—Inbound

   • Action—Forward

   • Source Address—255.255.255.255

   • Destination Address—10.1.1.2

   • Wildcard Mask—0.0.0.0

   

   

2. In the same area, define the second VPN Concentrator rule called deny_server_rule with these defaults:

   • Direction—Inbound

   • Action—Drop

   • Source and Destination Addresses of anything (255.255.255.255):

   

3. Choose Configuration > Policy Management > Traffic Management > Filters and add your filter_with_2_rules filter.

   

4. Add the two rules to filter_with_2_rules:

   

5. Choose Configuration > User Management > Groups and apply the filter to the group:

   

Filters for a LAN-to-LAN VPN Tunnel

From VPN Concentrator code 3.6 and later, you can filter traffic for each LAN-to-LAN IPsec VPN tunnel. For example, if you build a LAN-to-LAN tunnel to another VPN Concentrator with the address 172.16.1.1, and want to permit host 10.1.1.2 access to the tunnel while you deny all other traffic, you can apply filter_with_2_rules when you choose Configuration > System > Tunneling Protocols > IPSec > LAN-to-LAN > Modify and select filter_with_2_rules under Filter.

VPN 3000 Configuration - RADIUS Filter Assignment

It is also possible to define a filter in the VPN Concentrator and then pass down the filter number from a RADIUS server (in RADIUS terms, attribute 11 is Filter-id), so that when the user is authenticated on the RADIUS server, the Filter-id is associated with that connection. In this example, the assumption is that RADIUS authentication for VPN Concentrator users is already operational and only the Filter-id is to be added.

Define the filter on the VPN Concentrator as in the previous example:

CSNT Server Configuration - RADIUS Filter Assignment

Configure attribute 11, Filter-id on the Cisco Secure NT server to be 101:

Debug - RADIUS Filter Assignment

If AUTHDECODE (1-13 Severity) is on in the VPN Concentrator, the log shows that the Cisco Secure NT server sends down access-list 101 in attribute 11 (0x0B):

207 01/24/2001 11:27:58.100 SEV=13 AUTHDECODE/0 RPT=228
0000: 020C002B 768825C5 C29E439F 4C8A727A     ...+v.%...C.L.rz
0010: EA7606C5 06060000 00020706 00000001     .v..............
0020: 0B053130 310806FF FFFFFF                   ..101......

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

For troubleshooting purposes only, you can turn on filter debugging when you choose Configuration > System > Events > Classes and add FILTERDBG class with Severity to Log = 13. In the rules, change the Default action from Forward (or Drop) to Forward and Log (or Drop and Log). When the event log is retrieved at Monitoring > Event Log, it should show entries such as:

221 12/21/2000 14:20:17.190 SEV=9 FILTERDBG/1 RPT=62 
Deny In: intf 1038, ICMP, Src 10.99.99.1, Dest 10.1.1.3, Type 8

222 12/21/2000 14:20:18.690 SEV=9 FILTERDBG/1 RPT=63 
Deny In: intf 1038, ICMP, Src 10.99.99.1, Dest 10.1.1.3, Type 8

Related Information

• IPsec Negotiation/IKE Protocols
• VPN 3000 Concentrator Frequently Asked Questions
• RADIUS Support
• Cisco VPN 3000 Concentrator Support
• Cisco VPN 3000 Client Support
• Cisco Secure ACS for Windows Support
• Request for Comments (RFCs)
• Technical Support & Documentation - Cisco Systems