cc/td/doc/product/dsl_prod/6400/feat_gd
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Service Selection Gateway

Service Selection Gateway

This chapter describes the Service Selection Gateway (SSG) features supported in Cisco IOS Release 12.1(5)DB/DC and the RADIUS profiles, vendor-specific attributes and accounting records used with the SSG features. This chapter contains the following sections:

Overview

Introduced in Cisco IOS Release 12.0(3)DC, the SSG feature is a switching solution for service providers who offer intranet, extranet, and Internet connections to subscribers using broadband access technology such as xDSL, cable modems, or wireless to allow simultaneous access to network services. The SSG with Web Selection works in conjunction with the Cisco Service Selection Dashboard (SSD). The Cisco SSD is a customizable web-based application that allows users to select from multiple passthrough and proxy services through a standard web browser.

Figure 4-1 shows a diagram of a typical network topology including the SSG. This is an end-to-end, service-oriented DSL deployment consisting of Digital Subscriber Line Access Multiplexers (DSLAMs), ADSL modems, and other internetworking components and servers. The SSG resides in the Cisco 6400 universal access concentrator, which acts as a central control point for Layer 2 and Layer 3 services. This can include services available through Asynchronous Transfer Mode (ATM) virtual circuits (VCs), virtual private dial-up networks (VPDNs), or normal routing methods.


Figure 4-1:
SSG Connection Between ADSL Equipment and Network Services


The SSG communicates with the authentication, authorization, and accounting (AAA) management network where Remote Access Dial-In User Service (RADIUS), Dynamic Host Configuration Protocol (DHCP), and Simple Network Management Protocol (SNMP) servers reside and with the Internet service provider (ISP) network, which may connect to the Internet, corporate networks, and value-added services.

A licensed version of the SSG works with the Cisco SSD to present to subscribers a menu of network services that can be selected from a single graphical user interface (GUI). This improves flexibility and convenience for subscribers, and enables service providers to bill subscribers based on connect time and services used, rather than charging a flat rate.

The user opens an HTML browser and accesses the URL of the Cisco SSD, a web server application. The Cisco SSD forwards user login information to the SSG, which forwards the information to the AAA server.

Based on the contents of the Access-Accept response, the Cisco SSD presents a dashboard menu of services that the user is authorized to use, and the user selects one or more of the services. The SSG then creates an appropriate connection for the user and starts RADIUS accounting for the connection.

Note that when a non-Point-to-Point Protocol (non-PPP) user, such as in a bridged-networking environment, disconnects from a service without logging off, the connection remains open and the user can reaccess the service without going through the log in procedure. This is because no direct connection (PPP) exists between the subscribers and the SSG. To prevent non-PPP users from being logged in to services indefinitely, be sure to configure the Session-Timeout and/or Idle-Timeout RADIUS attributes.


Note   The Cisco SSD functionality described throughout this document is available only with the SSG with Web Selection product.


Note   As of Cisco IOS Release 12.1(5)DC, a service object stays in the system after all users log off. The same service object is reused when a user logs on to the service again. The administrator can remove the service object by using the clear ssg service service name command if the administrator knows that the service is obsolete.

Benefits

Web-Based Dashboard

The SSG with Web Selection works with the Cisco SSD, a specialized web server that allows users to log in to and disconnect from multiple passthrough and proxy services through a standard web browser.

After the user opens a web browser, the SSG allows access to a single IP address or subnet, referred to as the "default network." This is typically the IP address of the Cisco SSD. The Cisco SSD prompts the user for a username and password. After the user is authenticated, the Cisco SSD presents a list of available services.

RADIUS Authentication and Accounting

The SSG is designed to work with RADIUS-based AAA servers that accept vendor-specific attributes (VSAs).

Multiple Traffic-Type Support

The SSG supports the following types of services:

The SSG can forward traffic through any interface through normal routing or a next hop table. Because Network Address Translation (NAT) is not performed for this type of traffic, overhead is reduced. Passthrough service is ideal for standard Internet access.

When a subscriber requests access to a proxy service, the SSG will proxy the Access-Request to the remote AAA server. Upon receiving an Access-Accept from the remote RADIUS server, the SSG logs in the subscriber. To the remote AAA server, the SSG appears as a client.

During remote authentication, if the RADIUS server assigns an IP address to the subscriber, the SSG performs NAT between the assigned IP address and the subscriber's real IP address. If the remote RADIUS server does not assign an IP address, NAT is not performed.

When a user selects a proxy service, there is another username and password prompt. After authentication, the service is accessible until the user logs out from the service, logs out from the Cisco SSD, or is timed out.

When enabled, transparent passthrough allows unauthenticated subscriber traffic to be routed through the SSG in either direction. Filters can be specified to control transparent passthrough traffic. Some of the applications for this feature include:

The SSG supports multicast traffic, which includes normal multicast packets and Internet Group Management Protocol (IGMP) packets.

In order for the SSG to forward multicast packets to the IOS routing engine, it must be configured as follows:

If multicast is not enabled, multicast packets received on the interface will be dropped.

PPP Termination Aggregation (PTA) can only be used by PPP-type users. AAA is performed exactly as in the proxy service type. A subscriber logs in to a service by using a PPP dialer application with a username of the form user@service. The SSG recognizes the @service as a service profile and loads the service profile from the local configuration or a AAA server. The SSG forwards the AAA request to the remote RADIUS server as specified by the service profile's RADIUS-Server Attribute. An address is assigned to the subscriber through RADIUS Attribute 8 or Cisco-AVpair "ip:addr-pool." NAT is not performed, and all user traffic is aggregated to the remote network. With PTA, users can only access one service. Users will not have access to the default network or the Cisco SSD.

While PTA terminates the PPP session into a single routing domain, PTA-MD terminates the PPP sessions into multiple IP routing domains, thus supporting a wholesale VPN model where each domain is isolated from the other by an ATM core and has the capability to support overlapping IP addresses.

Packet Filtering

The SSG uses IOS access control lists (ACLs) to prevent users, services, and passthrough traffic from accessing specific IP addresses and ports.

When an ACL attribute is added to a service profile, all users of that service are prevented from accessing the specified IP address, subnet mask, and port combinations through the service.

When an ACL attribute is added to a user profile, it applies globally to all the user's traffic.

Upstream and downstream attributes, including inacl and outacl attributes, can be added to a special pseudo-service profile that can be downloaded to the SSG from a RADIUS server. Additionally, locally configured ACLs can be used. After the ACLs have been defined, they are applied to all traffic passed by the transparent passthrough feature.

Service Access Order

When users are accessing multiple services, the SSG must determine the services for which the packets are destined. To do this, the SSG uses an algorithm to create a service access order list that is stored in the user's host object and contains services that are currently open and the order in which they are searched.

The algorithm that creates this list orders the open services based on the size of the network, which is determined by the subnet mask of the Service Route RADIUS attribute. A subnet that contains more hosts implies a larger network. In the case of networks that are the same size, the services will be listed in the order in which they were last accessed.

When creating service profiles, be sure to define as small a network as possible. If there is overlapping address space, packets might be forwarded to the wrong service.

Next Hop Gateway

The next hop gateway attribute is used to specify the next hop key for a service. Each SSG uses its own next hop gateway table that associates this key with an actual IP address.

Note that this attribute overrides the IP routing table for packets destined to a service.

DNS Redirection

When the SSG receives a DNS request, it performs domain name matching by using the Domain Name attribute from the service profiles of the currently logged in services.

If a match is found, the request is redirected to the DNS server for the matched service.

If a match is not found and the user is logged in to a service that has Internet connectivity, the request is redirected to the first service in the user's service access order list that has Internet connectivity. Internet connectivity is defined as a service containing a Service Route attribute of 0.0.0.0/0.

If a match is not found and the user is not logged in to a service that has Internet connectivity, the request is forwarded to the DNS server defined in the client's Transmission Control Protocol/Internet Protocol (TCP/IP) stack.

Fault Tolerance for DNS

The SSG can be configured to work with a single DNS server, or two servers in a fault-tolerant configuration. Based on an internal algorithm, DNS requests will be switched to the secondary server if the primary server fails to respond with a DNS reply within a certain time limit.

Session-Timeout and Idle-Timeout RADIUS Attributes

In a dial-up networking or bridged (non-PPP) network environment, a user can disconnect from the NAS and release the IP address without logging out from the SSG. If this happens, the SSG continues to allow traffic to pass from that IP address, and this can be a problem if the IP address is obtained by another user.

The SSG provides two mechanisms to prevent this problem:

The Session-Timeout and Idle-Timeout attributes can be used in either a user or service profile. In a user profile, the attribute applies to the user's session. In a service profile, the attribute individually applies to each service connection.

Concurrent or Sequential Service Access Mode

SSG services can be configured for concurrent or sequential access. Concurrent access allows users to log in to this service while simultaneously connected to other services. Sequential access requires that the user log out of all other services before accessing a service configured for sequential access.

Concurrent access is recommended for most services. Sequential access is ideal for services for which security is important, such as corporate intranet access, or for which there is a possibility of overlapping address space.

Extended High System Availability

The SSG supports extended high system availability (EHSA) redundancy. You can configure this chassis redundancy at the slot level of the Cisco 6400 for adjacent slot or subslot pairs. For example, if you have SSGs installed in slots 1 and 2, you can set a preferred device between the two. To ensure that configuration is consistent between redundant SSGs, you can configure automatic synchronization between the two SSGs. You can also manually force the primary and secondary devices in a redundant pair to switch roles. See the Cisco 6400 Software Setup Guide for more information on EHSA redundancy.

Web Selection of L2TP Service Type

SSG supports L2TP. When a subscriber selects a service through the Cisco Service Selection Dashboard (SSD), the NRP as an L2TP access concentrator (LAC) sends the PPP session through the service specific L2TP tunnel. If the tunnel does not already exist, the NRP-LAC creates the proper tunnel to the L2TP network server (LNS).

Local Forwarding

SSG can be enabled to forward packets locally between directly connected subscribers.

SSG Single Host Logon

Subscribers only perform two login sessions to log in to a service through Cisco SSD:

Restrictions

Open Garden

The software does not support binding two services to the same interface. If a configuration has open garden and proxy service bound to the same interface, the open garden functionality will fail.

CEF

CEF works with Point-to-Point Protocol over Ethernet (PPPoE) only and does not work with Fast Ethernet.

SSG does not support simultaneous use of Cisco Express Forwarding (CEF) and Routed Bridge Encapsulation (RBE).

VPI/VCI Indexing to Service Profile

VPI/VCI indexing to service profile only works for Point-to-Point Protocol over ATM (PPPoA).

Proxy RADIUS Enhancements

For the proxy RADIUS enhancements, the sizes of the user-defined string and full username are limited to the smaller of the following values:

HTTP Redirect

The HTTP Redirect feature requires Service Selection Dashboard, Release 3.0(1) to implement captive portal capability.

Prerequisites

Cisco Service Selection Dashboard

If you want to perform Layer 3 service selection, you must install and configure the Cisco Service Selection Dashboard as described in the following documents:

Single Host Login

In order to use the Single Host Login feature, you must install and configure Cisco SSD version 2.5 or later versions.

Layer 2 Tunnel Protocol

To achieve 2000 L2TP sessions, you need at least 128 MB of DRAM on the NRP.

Configuring Features

This section contains the following tasks:

Enabling SSG

As of Cisco IOS Release 12.0(7) DC, SSG is disabled by default. To enable SSG, enter the following command in global configuration mode:

Command Purpose
Router(config)#ssg enable

Enables SSG functionality.

Verifying that SSG is Enabled

To verify that SSG is enabled, enter the EXEC command show running-config.

Configuring Local Service Profiles

This task is required if you want to use Layer 2 service selection; otherwise, it is optional. You can configure local service profiles in addition to the service profiles on the remote RADIUS server. See "Service Profiles" for information on configuring service profiles on the remote RADIUS server.

Command Purpose
Router(config)# local-profile profilename

Enters profile configuration mode. Configures a local RADIUS service profile.

Router(config-prof)# attr radius-attribute-id [vendor-id]
[cisco-vsa-type] attribute-value

Configures an attribute in a local RADIUS service profile.

Verifying Local Service Profiles

Enter the show running-config command to verify that local service profiles have been configured correctly.

Configuring Security

Command Purpose
Router(config)# aaa new-model

Enables AAA.

Router(config)# aaa authentication ppp default radius

Specifies RADIUS as the default authentication method for users that log in to serial interfaces by using PPP.

Router(config)# aaa authorization network default radius

Specifies that RADIUS is the default authorization used for all network-related requests.

Router(config)# radius-server host {hostname | ip-address}
[auth-port UDP-port-number] [acct-port UDP-port-number]

Specifies the RADIUS server host.

Router(config)# radius-server key AAAPassword

Sets the RADIUS shared secret between the SSG and the local AAA server.

Router(config)# radius-server vsa send

(Optional) Send vendor-specific attributes with authentication and accounting requests to the AAA server.

Router(config)# ssg radius-helper key DashboardPassword

Sets the RADIUS shared secret between the SSG and the Cisco SSD.

Router(config)# ssg radius-helper [auth-port UDP-port-number] [acct-port UDP-port-number]

Specifies the UDP default port numbers for a RADIUS authentication server (1645) and accounting server (1646).

Router(config)# ssg service-password ServicePassword

Sets the password used to authenticate the SSG with the local AAA server service profiles. This value must match the value configured for the AAA server service profiles.

Verifying Security

Enter the show running-config command to verify that security has been configured correctly.

Configuring a Default Network

Configure the first IP address or subnet that users will be able to access without authentication. This is the address where the Cisco SSD resides.

Command Purpose
Router(config)# ssg default-network ip-address mask

Sets the IP address or subnet that users will be able to access without authentication. Typically, this is the address where the Cisco SSD resides. A mask provided with the IP address specifies the range of IP addresses that users will be able to access without authentication.

Verifying the Default Network

Enter the show running-config command to verify that the default network has been configured correctly.

Configuring Interfaces

If you are going to use PPP to connect subscribers to the SSG, you do not have to configure any downlink interfaces. If you are using non-PPP connections, such as bridging or LAN, you must configure at least one downlink interface.

Command Purpose
Router(config)# ssg bind direction downlink {ATM
atm-interface | Async async-interface | BVI bvi-interface |
Dialer dialer-interface | Ethernet ethernet-interface |
FastEthernet fastethernet-interface | Group-Async
group-async-interface | Lex lex-interface | Loopback
loopback-interface | Multilink multilink-interface | Null
null-interface | Port-channel port-channel-interface | Tunnel
tunnel-interface | Virtual-Access virtual-access-interface |
Virtual-Template virtual-template-interface |
Virtual-TokenRing virtual-tokenring-interface}

Specifies a downlink interface, that is, the interface to the subscribers.

Configure all interfaces that will be connected to services as uplink interfaces.

Command Purpose
Router(config)# ssg bind direction uplink {ATM atm-interface
| Async async-interface | BVI bvi-interface | Dialer
dialer-interface | Ethernet ethernet-interface | FastEthernet
fastethernet-interface | Group-Async group-async-interface |
Lex lex-interface | Loopback loopback-interface | Multilink
multilink-interface | Null null-interface | Port-channel
port-channel-interface | Tunnel tunnel-interface |
Virtual-Access virtual-access-interface | Virtual-Template
virtual-template-interface | Virtual-TokenRing
virtual-tokenring-interface}

Specifies an uplink interface, that is, the interface to the services.

Verifying Interfaces

Enter the show ssg direction command to verify that interfaces have been configured correctly.

Configuring Services


Note   Every service must be bound to an uplink interface.

Command Purpose
Router(config)# ssg bind service service {ip-address | ATM
atm-interface | Async async-interface | BVI bvi-interface |
Dialer dialer-interface | Ethernet ethernet-interface |
FastEthernet fastethernet-interface | Group-Async
group-async-interface | Lex lex-interface | Loopback
loopback-interface | Multilink multilink-interface | Null
null-interface | Port-channel port-channel-interface | Tunnel
tunnel-interface | Virtual-Access virtual-access-interface |
Virtual-Template virtual-template-interface |
Virtual-TokenRing virtual-tokenring-interface}

Specifies the interface for a service.

Router(config)# ssg service-search-order local | remote |
local remote | remote local

(Optional) Specifies the order in which SSG searches for a service profile. The default service search order is local remote, that is, the SSG searches for service profiles in Flash memory first, then on the RADIUS server.

Router(config)# ssg next-hop download [profile-name]
[profile-password]

(Optional) Downloads the next-hop table from a RADIUS server.

Router(config)# ssg maxservice number

(Optional) Sets the maximum number of services per user. The default is 10.

Verifying Services

Enter the show ssg service command to verify that services have been bound to interfaces correctly. Enter the show running-config command to verify that the service search order and maximum services have been configured correctly. Enter the show ssg next-hop command to verify all mappings between services and IP addresses.

Configuring Fastswitching


Note   This task is optional. Fastswitching is enabled by default.

Command Purpose
Router(config)# ssg fastswitch

Enables fastswitching.

Router(config)# no ssg fastswitch

Disables fastswitching.

Verifying Fastswitching

Enter the show running-config command to verify that fastswitching has been enabled. Because fastswitching is enabled by default, it will not be displayed in the running configuration. If fastswitching has been disabled, the following line will appear in the output of the show running-config command:

no ssg fastswitch

Configuring Multicast


Note   This task is optional. Multicast is disabled by default.

Command Purpose
Router(config)# ssg multicast

Enables multicast. When multicast is enabled, the SSG will forward multicast packets, which include normal multicast packets and IGMP packets, received on an uplink or downlink interface that has had a service bound to it to the IOS routing engine.

Router(config)# no ssg multicast

Disables multicast. If multicast is disabled, multicast packets received on an uplink or downlink interface or an interface that has had a service bound to it will be dropped.

Verifying Multicast

Enter the show running-config command to verify that multicast has been enabled. If multicast is disabled, which is the default, it will not be displayed in the running configuration. If multicast is enabled, the following line will appear in the output of the show running-config command:

ssg multicast

Configuring RADIUS Interim Accounting

The SSG supports intermittent RADIUS accounting updates. When a user logs in to the SSG, the SSG sends an accounting start record to the local RADIUS server. When a user logs in to a service, the SSG sends a connection start record to the local RADIUS server and to the remote RADIUS proxy server. During the time that the user is logged in to the SSG, the SSG sends accounting update records at specified intervals to the appropriate server. When a user logs off from a service, the SSG sends a connection stop record to the local RADIUS server and to the remote RADIUS proxy server. When a user logs off from the SSG, the SSG sends an accounting stop record to the local RADIUS server. See "RADIUS Accounting Records" for more information.

This task is optional. Set the interval at which accounting updates are sent to the accounting server.

Command Purpose
Router(config-if)#ssg accounting interval seconds

Specifies the interval at which accounting updates are sent to the accounting server. The minimum interval is 60 seconds. The default interval is 120 seconds.

Verifying Interim Accounting

Enter the show running-config command to verify that the accounting interval has been set correctly.

Configuring Cisco Express Forwarding


Note   CEF works with Point-to-Point Protocol over Ethernet (PPPoE) only and does not work with Fast Ethernet.

SSG does not support simultaneous use of Cisco Express Forwarding (CEF) and Routed Bridge Encapsulation (RBE).

The SSG works with Cisco Express Forwarding (CEF) switching technology to provide maximum Layer 3 switching performance. Because CEF is topology-driven rather than traffic-driven, its performance is unaffected by network size or dynamics.


Note   This task is optional. CEF is disabled by default. CEF only works with PPPoE.

Command Purpose
Router(config)#ip cef

Enables global IP CEF.

Verifying Cisco Express Forwarding

Enter the show running-config and show ip cef commands to verify that CEF has been enabled.

Configuring IOS Network Address Translation

The SSG uses IOS Network Address Translation (NAT) to map the inside IP addresses of subscribers to the outside IP addresses from the destination service networks. This replaces the SSG NAT used in Cisco IOS Release 12.0(3)DC.

To configure IOS Network Address Translation (NAT), you must specify an inside interface from which clients connect to the SSG and an outside interface from which services are accessed. Enter interface or subinterface configuration mode for the desired inside and outside interfaces and enter the appropriate command below.


Note   This task is optional.

Command Purpose
Router(config-if)#ip nat inside

Specifies the inside interface from which clients access the SSG.

Router(config-subif)#ip nat outside

Specifies the outside interface from which services are accessed.

Verifying IOS Network Address Translation

Enter the show running-config command to verify that inside and outside ports have been specified correctly. Enter the show ip nat translations command to view your NAT addresses.

Configuring VPI/VCI Indexing to Service Profile


Note   VPI/VCI indexing to service profile only works for Point-to-Point Protocol over ATM (PPPoA).

The SSG supports virtual path identifier/virtual channel identifier (VPI/VCI) closed user groups by allowing VPI/VCIs to be bound to a given service. All users accessing the SSG through the VPI/VCI or range of VPI/VCIs will be able to access the service. You can specify whether users are allowed to access only the bound service or other additional services to which they subscribe. A closed user group service can only be selected through the VPI/VCI and not by entering the domain name in the user name of a Point-to-Point Protocol (PPP) session.

To configure VPI/VCI closed user groups, you must bind VPI/VCIs to a given service as described below. Closed user groups allow all users accessing the SSG through the VPI/VCI or range of VPI/VCIs to access the service. You can specify whether users are allowed to access only the bound service or other additional services to which they subscribe. A closed user group service can only be selected through the VPI/VCI and not by entering the domain name in the user name of a PPP session.


Note   This task is optional.

Command Purpose
Router(config)#ssg vc-service-map service-name [interface
slot-module-port] start-vpi | start-vpi/vci [end-vpi |
end-vpi/vci] exclusive | non-exclusive

Map VCs to service names.

Verifying VPI/VCI Indexing to Service Profile

Enter the show running-config and show ssg vc-service-map command to view service name to VC mappings.

Monitoring VPI/VCI Indexing to Service Profile

Command Purpose
Router#show ssg vc-service-map

Displays VC to service name mappings.

Configuring the Proxy RADIUS Enhancements

Before configuring this feature, see the restrictions for Proxy RADIUS Enhancements.

Two new Service-Info vendor-specific attributes (VSAs) are available for proxy RADIUS service profiles:

To configure the proxy RADIUS enhancements, enter one or both of these Service-Info VSAs in the proxy RADIUS service profile:

For general information on configuring RADIUS profiles for SSG, see the "Configuring RADIUS Profiles" section.

The SSG uses vendor-specific RADIUS attributes. You must customize the AAA server's RADIUS dictionary to incorporate the SSG vendor-specific attributes.

Table 4-1 lists vendor-specific attributes used by the SSG to support the proxy RADIUS enhancements. The vendor ID for all of the Cisco-specific attributes is 9.


Table 4-1: VSAs Related to SSG Support of the Proxy RADIUS Server
AttrID Vendor ID SubAttrID SubAttrName SubAttrDataType

26

9

251

Service-Info

String

Example: Proxy RADIUS Enhancements

The following proxy RADIUS service profile contains a Service-Defined Cookie and a Full Username Attribute:

user = serv1-proxy{ profile_id = 98 profile_cycle = 42 member = Single_Logon radius=6510-SSG-v1.1a { check_items= { 2=alex } reply_attributes= { 9,251="Oservice1.com" 9,251="R10.13.0.0;255.255.0.0" 9,251="TX" 9,251="D10.13.1.5" 9,251="S10.13.1.2;1645;1646;my-secret" 9,251="Gmy-key" 9,251="X" 9,251="Vproxy-service_at_X.X.X.X" } } }

Verifying the Proxy RADIUS Enhancements


Step 1   To verify that the new Service-Info attributes exist in the proxy RADIUS service profile, enter the show ssg service service-name command and check for the "Full User Name Used" and "Service Defined Cookie exist" statements in the output.

Router# show ssg service serv1-proxy ------------------------ ServiceInfo Content ----------------------- Uplink IDB: Name:serv1-proxy Type:PROXY Mode:CONCURRENT Service Session Timeout:0 seconds Service Idle Timeout:0 seconds Class Attr:NONE Authentication Type:CHAP Reference Count:1 Next Hop Gateway Key:my-key DNS Server(s):Primary:10.13.1.5 Radius Server:IP=10.13.1.2, authPort=1645, acctPort=1646, secret=my-secret Included Network Segments: 10.13.0.0/255.255.0.0 Excluded Network Segments: Full User Name Used Service Defined Cookie exist Domain List:service1.com; Active Connections: 1 :Virtual=255.255.255.255, Subscriber=10.20.10.2 ------------------------ End of ServiceInfo Content ----------------

Step 2   To check the content of the RADIUS profiles, refer to the user documentation for your RADIUS server.


Configuring L2TP


Note   Before configuring this feature, see the prerequisites for Layer 2 Tunnel Protocol.

Configuring the NRP as a LAC

To configure the Cisco 6400 NRP as a LAC, enter the following command in global configuration mode:

Command Purpose
Router(config)#vpdn enable

Enables L2TP functionality.

Verifying the NRP-LAC Configuration

To verify the NRP-LAC configuration, enter the EXEC command show running-config.

Configuring the RADIUS Profiles for SSG Support of L2TP

For general information on configuring RADIUS profiles for SSG, see the "Configuring RADIUS Profiles" section.

The SSG uses vendor-specific RADIUS attributes. You must customize the AAA server's RADIUS dictionary to incorporate the SSG vendor-specific attributes.

Table 4-2 lists vendor-specific attributes used by the SSG to support L2TP. The vendor ID for all the Cisco-specific attributes is 9.


Table 4-2: Vendor-Specific RADIUS Attributes Related to SSG Support of L2TP
AttrID Vendor ID SubAttrID SubAttrName SubAttrDataType

26

9

1

Cisco-AVpair

String

26

9

250

Account-Info

String

26

9

251

Service-Info

String

Cisco-AVpair VPDN Attributes

Table 4-3 lists the Cisco-AVpair attributes used in the service profile to configure VPDN.


Table 4-3: Cisco AVPair Attributes
Attribute Usage

VPDN IP Address

Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections.

VPDN Tunnel ID

Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.

L2TP Tunnel Password

Specifies the secret (password) used for L2TP tunnel authentication.

Account-Info VPDN Attribute

Table 4-4 lists the Account-Info attribute used in the user profile to subscribe the user to a VPDN service.


Table 4-4: Account-Info Attribute
Attribute Usage

Service Name

Subscribes the user to a service. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service to which the user is subscribed (reply attribute).

Service-Info VPDN Attribute

Table 4-5 lists the Service-Info attribute used in the service profile to define the L2TP service parameter.


Table 4-5: Service-Info Attribute
Attribute Usage

Type of Service

Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough.

Verifying the RADIUS Profile Configurations

To verify the RADIUS profiles, refer to the user documentation for your RADIUS server.

Configuring the LNS

To configure the LNS, typically a Cisco 7200 or another NRP, enter the following commands beginning in global configuration mode.

Command Purpose

Step 1 

Router(config)#username name password secret

Specifies the password to be used for PAP and CHAP. Each subscriber requires a unique username and password.

Step 2 

Router(config)#vpdn-group number

Selects the VPDN group. Each L2TP tunnel requires a unique VPDN group.

Step 3 

Router(config-vpdn)#accept-dialin l2tp
virtual-template
number

Accepts incoming L2TP tunnel connections. Also specifies the virtual template interface to use to clone the new virtual access interface.

Step 4 

Router(config-vpdn)#terminate-from hostname hostname

Specifies the tunnel ID that will be required when accepting a VPDN tunnel. This must match the VPDN tunnel ID configured in the RADIUS service profile.

Step 5 

Router(config-vpdn)#l2tp tunnel password password

Identifies the password that the router will use for tunnel authentication.

Step 6 

Router(config-vpdn)#exit

Returns to global configuration mode.

Step 7 

Router(config)#interface Virtual-Template number

Creates a virtual template interface that can clone new virtual access interfaces.

Step 8 

Router(config-if)#ip unnumbered interface-type
interface-number

Configures the interface as unnumbered and provides a local address.

Step 9 

Router(config-if)#peer default ip address
pool
pool-name

Specifies the pool from which to retrieve the IP address to assign to a remote peer dialing in to the interface.

Step 10 

Router(config-if)#ppp authentication
{chap | chap pap | pap chap | pap}

Specifies the order in which the CHAP or PAP protocols are requested on the interface.

L2TP Example

This section provides the following configuration examples:

SSG as a LAC Example

The following example shows a basic SSG configuration for a LAC:

! vpdn enable ssg enable !
RADIUS User Profile Example

The following example shows a basic RADIUS user profile for SSG support of L2TP:

user = l2tp_user{ member = Some-Users radius=CSUNIX_RADIUS_DICTIONARY_for_6400-NRP-SSG-v1.0 { check_items= { 2=cisco } reply_attributes= { 6=2 7=1 9,250="Nl2tp_tunnel.com" } } }
RADIUS Service Profile Example

The following example shows a basic RADIUS service profile for SSG support of L2TP:

reply_attributes= { 9,251="R10.6.6.0;255.255.255.0" 9,251="ODomain.com" 9,251="D10.7.7.7;10.7.7.8" 9,251="ITunnel1" 9,251="TT" 9,251="S10.7.7.7;1645;1646;cisco" 9,1="vpdn:ip-addresses=10.8.8.8" 9,1="vpdn:tunnel-id=My-Tunnel" 9,1="vpdn:l2tp-tunnel-password=cisco"
LNS Configuration Example

The following example shows a basic LNS configuration:

! username l2tp_user password 0 cisco vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname My-Tunnel l2tp tunnel password 7 02050D480809 ! interface Virtual-Template1 ip unnumbered FastEthernet0/0 no ip directed-broadcast peer default ip address pool pool2 ppp authentication pap chap !

Monitoring L2TP

The following privileged EXEC commands will help you monitor and maintain the SSG support of L2TP.

Command Purpose
show ssg l2x {dialer-config | dialer-list | dialer-status |
info | vpdn-group} service-name

Displays SSG L2TP information, including dialer configuration, dialer-list tables, tunnel information, and vpdn-group information.

show vpdn tunnel [all | packets | state | summary | transport]
[id | local-name | remote-name]

Displays VPDN tunnel information including tunnel protocol, ID, packets sent and received, receive window sizes, retransmission times, and transport status.

show vpdn session [all [interface | tunnel | username]|
packets | sequence | state | timers | window]

Displays VPDN session information including interface, tunnel, username, packets, status, and window statistics.

clear vpdn tunnel l2tp remote-name local-name

Shuts down a specific tunnel and all the sessions within the tunnel.

Configuring Local Forwarding

To enable SSG to forward packets locally, enter the following command in global configuration mode:

Command Purpose
Router(config)#ssg local-forwarding

Enables local forwarding.

Example: Local Forwarding

In the following configuration, local forwarding is enabled:

! ssg enable ssg local-forwarding !

Verifying Local Forwarding

To verify that you enabled local forwarding, enter the show running-config EXEC command.

Configuring an Open Garden


Note   The SSG does not support binding two services to the same interface. If a configuration has open garden and proxy service bound to the same interface, the open garden functionality will fail.

An Open Garden is one or more domains that can be accessed without user authentication. This differs from a "Walled Garden." A "Walled Garden" refers to a collection of Web sites, or networks in general, that a user can access after providing minimal authentication information.

The Open Garden enhancement enables a list of as many as 100 domains to be associated with the default network. If a subscriber creates a DNS request for one of those domain names, the DNS request is resolved by the SSG to the default network.This ensures that a subscriber can access the Service Selection Dashboard, which typically resides on the management network with a private address, even when the subscriber is assigned a public DNS server.

To configure an open garden:

    1. Create a local profile for each open garden network desired.

    2. Add this new profile to the open garden list.

Creating a Local Profile for an Open Garden

Enter the local-profile profile-name command to enter profile configuration mode and to create and name a local profile.

Syntax Description

profile-name

User-defined name for the open garden network.

Example

Router# local-profile opengarden_network1

Enter the attr radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value command to define the local profile attributes R,O,D, where networks and domain names can be configured for each open garden network.

Syntax Description

R

Open garden network IP address and subnet mask.

O

Domain names list.

D

DNS IP address.

Table 4-2 lists VSAs (vendor-specific attributes) used by the SSG. The vendor ID for all Cisco-specific attributes is 9.


Table 4-6: VSAs Related to SSG Support of Open Garden
AttrID Vendor ID SubAttrID SubAttrName SubAttrDataType

26

9

251

Service-Info

String

Example

Router(opengarden_network1)# attribute 26 9 251 "R x.x.x.x;m.m.m.m" Router(opengarden_network1)# attribute 26 9 251 "O www.cisco.com " Router(opengarden_network1)# attribute 26 9 251 "D x.x.x.x"

Adding the Local Profile to the Open Garden List

Enter the ssg open-garden profile-name command to add the new profile to the list of open garden networks.

Syntax Description

profile-name

The previously-defined name for the open garden network.

Example

Rouer# ssg open-garden opengarden_network1

Verifying the Open Garden Configuration


Step 1   To verify the open garden configuration, enter the show ssg open-garden profile-name command and check for the open garden network statements in the output:

Router# show ssg open-garden opengarden_network1

Step 2   To verify the open garden configuration, enter the following command:

Router# show ssg service opengarden_network1

Configuring HTTP Redirection


Note   The HTTP Redirect feature requires Service Selection Dashboard, Release 3.0(1) to implement captive portal capability.

The Hypertext Transfer Protocol (HTTP) Redirect feature works with the Cisco Service Selection Dashboard (SSD) to implement captive portals. If a user has not logged in and sends packets upstream to a configurable group of TCP ports, SSG sends those packets to a captive portal group (one or more servers). The SSD handles the incoming packets in a suitable manner, such as returning a login page.

The group of captive portals consists of one or more SSDs. The SSG redirects packets to the captive portal groups on a round-robin basis.

The HTTP Redirect feature provides a means for user authentication without requiring the user to know the dashboard URL. It enables service providers to implement captive portals, own the user experience, advertise value-added services, and build a brand experience.


Note   HTTP Redirect is supported in 12.1(5)DC for bridged or routed users. It supports subscribers coming in on bridged or routed interfaces. This feature does not support subscribers coming in with PPP and RBE. SSG operates by using standard Internet protocols with AAA and other Web servers the user chooses. A customer can currently use any Web server that can handle the HTTP Redirect. Cisco SSD version 3.0 can receive HTTP Redirection from SSG and handles the request. Release 3.0(1) of the SSD, which is scheduled to FCS in June 2001.

To configure HTTP redirection:


Step 1   Define a captive portal group.

Step 2   Add a TCP port to the portal group.

Step 3   Set a default group for redirection of unauthorized users.


Defining a Captive Portal Group

To define a group of one or more servers that make up the captive portal group, enter the
ssg http-redirect group group-name server ip-address port command.

Syntax Description

group

Defines a portal group.

groupname

The user-defined name for the captive portal group.

server

Adds a server to the group

ip-address

Specifies the IP address of the server to add to the group

port

TCP port on the server. Both ip-address and port are required.

Example

Router# ssg http-redirect group RedirectServer server 1.1.1.1 8080

Adding a TCP Port to the Portal Group

To add a TCP port to a list of ports that can be redirected by the captive portal group, enter the ssg http-redirect port incoming destination port number group group-name command.

Syntax Description

port

Adds a TCP port to the list of redirectable ports.

incoming
destination port
number

The specific port number to add to the list.

group

Adds the specified port to the group specified in group-name.

group-name

Name of the portal group to which the port is added.

Example

Router# ssg http-redirect port 8080 group SSDGroup

Setting a Default Redirection Group

To select a captive portal group for redirection of traffic from an unauthorized user, enter the
ssg http-redirect unauthorized-user group group-name command.

Syntax Description

unauthorized-
user

Adds a service to the list of redirectable services.

group

Select a portal group for traffic redirection from an unauthorized user.

group-name

Name of the portal group to which the traffic will be redirected.

Example

Router# ssg http-redirect unauthorized-user group SSDGroup

Verifying the HTTP Redirection

To verify that the HTTP redirection is set or to view any direct mappings, enter the show ssg http-redirect group [name] command or the show ssg http-redirect mappings [ip-address] command and check for the HTTP redirect statements in the output.

If the group keyword is used and the optional name field is omitted, the command displays a list of all defined portal groups. If the name field is included, the command displays information about that group.

If the mappings keyword is used and the optional ip-address is omitted, then a list of IP addresses for all hosts with stored mappings is displayed. If the ip-address field is included, then any mappings for the host with that IP address is displayed.

Router# show ssg http-redirect

Configuring RADIUS Profiles

The SSG uses vendor-specific RADIUS attributes to define RADIUS profiles. You must customize the AAA server's RADIUS dictionary to incorporate the SSG vendor-specific attributes described inSSG Vendor-Specific Attributes.

You must set up user and service RADIUS profiles on the AAA server as described in this section. Service profiles can also be defined locally as described in the "Configuring Local Service Profiles" section. You can optionally set up pseudo-service profiles. The following profiles are described:

These profiles contain RADIUS attributes that define specific AAA elements. The syntax for these attributes is described in this section.

SSG Vendor-Specific Attributes

Table 4-7 lists vendor-specific attributes used by the SSG. By sending an Access-Request packet with the vendor-specific attributes shown in the table, the Cisco Service Selection Dashboard (SSD) can send requests to the SSG to log on and log off an account and disconnect and connect services. The vendor ID for all of the Cisco-specific attributes is 9.


Table 4-7: Vendor-Specific RADIUS Attributes for the SSG
AttrID VendorID SubAttrID SubAttrName SubAttrDataType

26

9

1

Cisco-AVpair

String

26

9

250

Account-Info

String

26

9

251

Service-Info

String

26

9

253

Control-Info

String

The following sections describe the format of each subattribute.


Note   All RADIUS attributes are case sensitive.

Cisco-AVpair Attributes

The Cisco-AVpair attributes are used in user and service profiles to configure ACLs and VPDN.


Table 4-8: Cisco-AVPair Attributes
Attribute Usage

Upstream Access Control List (inacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Downstream Access Control List
(outacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

VPDN IP Address

Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections.

VPDN Tunnel ID

Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.

L2TP Tunnel Password

Specifies the secret (password) used for L2TP tunnel authentication.

Account-Info Attributes

The Account-Info attributes are used in user profiles and service group profiles.

User profiles define the password, services, and groups to which the user is subscribed.

Service group profiles contain a list of services and service groups and can be used to create sophisticated directory structures for locating and logging in to services. When a user is subscribed to a service group, the user is automatically subscribed to all services and groups within that service group. A service group profile includes the name of the service group, the password, the service type (outbound), a list of services and/or a list of other service groups.

Example (RADIUS Freeware Format)

    Account-Info = "Nservice1.com"

Example (CiscoSecure ACS for UNIX Format)

    9,250 = "Nservice1.com"


Table 4-9: Account-Info Attributes
Attribute Usage

Service Name

Subscribes the user to a service. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service to which the user is subscribed (reply attribute).

Service Group

Subscribes the user to a service group. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service group to which the user is subscribed (reply attribute).

Auto Service

Automatically logs a user into a service when the user logs on to the SSG (reply attribute).

Group Description

Provides a description of the service group.

Service-Info Attributes

The Service-Info attributes are used to define a service. The following attributes define the parameters for a service.


Table 4-10: Service-Info Attributes
Attribute Usage

Type of Service

(Optional) Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough.

Service Mode

(Optional) Specifies whether the user is able to log on to this service while simultaneously connected to other services (concurrent) or whether the user cannot access any other services while using this service (sequential). The default is concurrent.

DNS Server Address

(Optional) Specifies the primary and secondary DNS servers for this service.

Service Route

(Required) Specifies networks that exist for the service. There can be multiple instances of this attribute within a single user profile.

RADIUS Server

(Required for proxy services) Specifies the remote RADIUS server that the SSG will use to authenticate and authorize a service log on for a proxy service type.

Service Next Hop Gateway

(Optional) Specifies the next hop key for this service. Each SSG uses its own next hop gateway table that associates this key with an actual IP address. For information on creating a next hop gateway table, see the "Next Hop Gateway Pseudo-Service Profile" section.

Domain Name

(Optional) Specifies domain names that get DNS resolution from the DNS server(s) specified in DNS Server Address.

Service Description

(Optional) Provides a description of the service that is displayed to the user.

Service User

Indicates the username provided by the Cisco SSD user to log on to the service and for authentication with the home gateway.

Service Name

Defines the name of the service.

Service-Defined Cookie

A configurable VSA that allows user-defined information to be included in the RADIUS authentication and accounting requests.

Full Username Attribute

Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests.

Control-Info Attributes

The Control-Info attribute is used to define lists or tables of information.


Table 4-11: Control-Info Attribute
Attribute Usage

Next Hop Gateway Table Entry

Associates next hop gateway keys with IP addresses.

User Profiles

RADIUS user profiles contain a password, a list of subscribed services and groups, and access control lists.

Cisco AVPair Attributes

This section describes Cisco AVPair attributes that appear within user profiles. The Cisco-AVpair attributes are used to configure ACLs.


Table 4-12: Cisco AVPair Attributes
Attribute Usage

Upstream Access Control List (inacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Downstream Access Control Listt
(outacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Upstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Cisco-AVpair = "ip:
inacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:inacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Downstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Cisco-AVpair = "ip:
outacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"

User Profile Attributes

This section specifies standard and vendor-specific RADIUS attributes that can be used in SSG user profiles.


Table 4-13: User Profile Attributes
Attribute Usage

Password

Specifies the user's password (check attribute).

Session-Timeout

Specifies, in seconds, the maximum length of the user's session (reply attribute).

Idle-Timeout

Specifies, in seconds, the maximum time a connection can remain idle (reply attribute).

Service Name

Subscribes the user to a service. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service to which the user is subscribed (reply attribute).

Service Group

Subscribes the user to a service group. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service group to which the user is subscribed (reply attribute).

Auto Service

Automatically logs a user into a service when the user logs on to the SSG (reply attribute).

Service Name

In user profiles, this attribute subscribes the user to the specified service. In service group profiles, this attribute lists services that belong to the service group.

Account-Info = "Nname"

Syntax Description

n

name

Name of the service profile.

Example (RADIUS Freeware Format)

    Account-Info = "Ncisco.com"

Example (CiscoSecure ACS for UNIX)

    9,250="cisco.com"
Service Group

In user profiles, this attribute subscribes a user to a service group. In service group profiles, this attribute lists the service subgroups that belong to this service group.

Account-Info = "Gname"

Syntax Description

name

Name of the group profile.

Example

    Account-Info = "GServiceGroup1"
Auto Service

This attribute subscribes the user to a service and automatically logs the user on to the service when the user accesses the Cisco SSD. Each user profile can have more than one auto service attribute.

Account-Info = "Aservicename [;username;password]"

Syntax Description

servicename

Name of the service.

username

Username used to access the service. Required for proxy services.

password

Password used to access the service. Required for proxy services.

Example

Account-Info = "Agamers.net;jdoe;secret"


Note   The user must be subscribed to this service. See "Service Name".

Example User Profile

The following is an example of a user profile. The profile is formatted for use with a freeware RADIUS server:

bert Password = "ernie" Session-Timeout = 21600, Account-Info = "GServiceGroup1", Account-Info = "Nservice1.com", Account-Info = "Ngamers.net"

The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:

user = bert { radius = SSG { check_items = { 2 = "ernie" } reply_attributes = { 27 = 21600 9,250 = "GServiceGroup1" 9,250 = "Nservice1.com" 9,250 = "Ngamers.net" } } }

Service Profiles

Service profiles include the password, service type (outbound), type of service (passthrough or proxy), the service access mode (sequential or concurrent), the DNS server IP address, networks that exist in the service domain, access control lists, and other optional attributes.

Cisco-AVPair Attributes

This section describes Cisco AVPair attributes that appear within service profiles. Table 4-14 lists the Cisco-AVpair attributes used to configure ACLs.


Table 4-14: Cisco AVPair Attributes Used to Configure ACLs
Attribute Usage

Upstream Access Control List (inacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Downstream Access Control List
(outacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Table 4-15 lists the Cisco-AVpair attributes used in service profiles.


Table 4-15: Cisco AVPair Attributes Used in Service Profiles
Attribute Usage

VPDN IP Address

Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections.

VPDN Tunnel ID

Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.

L2TP Tunnel Password

Specifies the secret (password) used for L2TP tunnel authentication.

Upstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Cisco-AVpair = "ip:
inacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:inacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Downstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Cisco-AVpair = "ip:
outacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
VPDN IP Address

This attribute specifies the IP addresses of the home gateways (LNSs) to receive the L2TP connections.

Cisco-AVpair = "vpdn:ip-addresses=address1[<delimiter>address2][<delimiter>address3]..."

Syntax Description

address

IP address of the home gateway.

<delimiter>

, (comma)

Selects load sharing among IP addresses.

  (space)

Selects load sharing among IP addresses.

/ (slash)

Groups IP addresses on left side of the slash in higher priority than those on the right side of the slash.

In the following example, the LAC will send the first PPP session through a tunnel to 10.1.1.1, the second PPP session to 10.2.2.2, the third to 10.3.3.3. The fourth PPP session will be sent through the tunnel to 10.1.1.1, and so forth. If the LAC fails to establish a tunnel with any of the IP addresses in the first group, then the LAC will attempt to connect to those in the second group (10.4.4.4 and 10.5.5.5).

Example (RADIUS Freeware Format)

Cisco-AVpair="vpdn:ip-addresses=10.1.1.1,10.2.2.2,10.3.3.3/10.4.4.4,10.5.5.5"

Example (CiscoSecure ACS for UNIX)

9,1="vpdn:ip-addresses=10.1.1.1,10.2.2.2,10.3.3.3/10.4.4.4,10.5.5.5"

VPDN Tunnel ID

This attribute specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group, as shown in Step 4 in the "Configuring the LNS" section.

Cisco-AVpair = "vpdn:tunnel-id=name"

Syntax Description

name

Tunnel name.

Example (RADIUS Freeware Format)

Cisco-AVpair="vpdn:tunnel-id=My-Tunnel"

Example (CiscoSecure ACS for UNIX)

9,1="vpdn:tunnel-id=My-Tunnel"

L2TP Tunnel Password

This attribute is the secret (password) used for L2TP tunnel authentication.

Cisco-AVpair = "vpdn:tunnel-password=secret"

Syntax Description

secret

Secret (password) for L2TP tunnel authentication.

Example (RADIUS Freeware Format)

Cisco-AVpair="vpdn:l2tp-tunnel-password=cisco"

Example (CiscoSecure ACS for UNIX)

9,1="vpdn:l2tp-tunnel-password=cisco"

Standard Service Profile Attributes

This section specifies standard RADIUS attributes that can be used in SSG service profiles.


Table 4-16: Standard Service Profile Attributes
Attribute Usage

Password

Specifies the password (check attribute).

Service-Type

Specifies the level of service (check attribute). Must be "outbound."

Session-Timeout

Specifies, in seconds, the maximum length of the session (reply attribute).

Idle-Timeout

Specifies, in seconds, the maximum time a service connection can remain idle (reply attribute).

SSG Specific Service Profile Attributes

This section specifies VSAs that can appear within service profiles.


Table 4-17: SSG Service Profile Attributes
Attribute Usage

Type of Service

(Optional) Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough.

Service Mode

(Optional) Specifies whether the user is able to log on to this service while simultaneously connected to other services (concurrent) or whether the user cannot access any other services while using this service (sequential). The default is concurrent.

DNS Server Address

(Optional) Specifies the primary and/or secondary DNS servers for this service.

Service Route

(Required) Specifies networks that exist for the service. There can be multiple instances of this attribute within a single user profile.

RADIUS Server

(Required for proxy services) Specifies the remote RADIUS server that the SSG will use to authenticate and authorize a service log on for a proxy service type.

Service Next Hop Gateway

(Optional) Specifies the next hop key for this service. Each SSG uses its own next hop gateway table that associates this key with an actual IP address. For information on creating a next hop gateway table, see "Next Hop Gateway Pseudo-Service Profile".

Domain Name

(Optional) Specifies domain names that get DNS resolution from the DNS server(s) specified in DNS Server Address.

Service Description

(Optional) Provides a description of the service that is displayed to the user.

Service-Defined Cookie

A configurable VSA that allows user-defined information to be included in the RADIUS authentication and accounting requests.

Full Username Attribute

Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests.

Type of Service

This attribute indicates whether the service is proxy, tunnel, or passthrough. This attribute is optional.

Service-Info = "Ttype"

Syntax Description

type

P—Passthrough. Indicates the user's packets are forwarded through the
SSG. This is the default.

T—Tunnel. Indicates that this is a tunneled service.

X—Proxy. Indicates the SSG performs proxy service.

Example (RADIUS Freeware Format)

    Service-Info = "TT"

Example (CiscoSecure ACS for UNIX)

    9,251="TT"
Service Mode

This attribute defines whether the user is able to log on to this service while simultaneously connected to other services (concurrent) or whether the user cannot access any other services while using this service (sequential). The default is concurrent. This attribute is optional.

Service-Info = "Mmode"

Syntax Description

mode

S—Sequential mode.

C—Concurrent mode. This is the default.

Example

Service-Info = "MS"

DNS Server Address

This attribute specifies the primary and secondary DNS servers for this service. If two servers are specified, the SSG can send DNS requests to the primary DNS server until performance is diminished or it fails (failover). This attribute is optional.

Service-Info = "Dip_address_1[;ip_address_2]"

Syntax Description

ip_address_1

IP address of the primary DNS server.

ip_address_2

(Optional) IP address of the secondary DNS server used for fault tolerance.

Example

Service-Info = "D192.168.1.2;192.168.1.3"

Service Route

This attribute specifies networks available to the user for this service. This attribute is required.

Service-Info = "Rip_address;mask"

Syntax Description

ip_address

IP address.

mask

Subnet mask.

Usage

Use the Service Route attribute to specify networks that exist for a service. For more information, see "Service Access Order".


Note   An Internet service is typically specified as "R0.0.0.0;0.0.0.0" in the service profile.

Example

Service-Info = "R192.168.1.128;255.255.255.192"


Note   There can be multiple instances of this attribute within a single service profile.

RADIUS Server

This attribute specifies the remote RADIUS server that the SSG will use to authenticate, authorize, and perform accounting for a service log on for a proxy service type. This attribute is only used in proxy service profiles. This attribute is required for proxy service profiles.

Service-Info = "SRadius-server-address;auth-port;acct-port;secret-key"

Syntax Description

Radius-server-address

IP address of the RADIUS server.

auth-port

UDP port number for authentication and authorization requests.

acct-port

UDP port number for accounting requests.

secret-key

Secret key shared with RADIUS clients.

Example

Service-Info = "S192.168.1.1;1645;1646;cisco"

Service Next Hop Gateway

This attribute specifies the next hop key for this service. Each SSG uses its own next hop gateway table that associates this key with an actual IP address. For information on creating a next hop gateway table, see "Next Hop Gateway Table Entry". This attribute is optional.

Service-Info = "Gkey"

Syntax Description

key

Name of the next hop.



Example

Service-Info = "Gnexthop1"

Domain Name

This attribute specifies domain names that get DNS resolution from the DNS server(s) specified in DNS server address. This attribute is optional.

Service-Info = "Oname1[;name2]...[;nameX]"

Syntax Description

name1

Domain name that gets DNS resolution from this server.

name2...X

(Optional) Additional domain name(s) that gets DNS resolution from this server.

Usage

Use the DNS Resolution attribute to specify domain names that get DNS resolution from this DNS server. For more information, see "Service Access Order".

Example

Service-Info = "Ocisco.com;cisco-sales.com"


Note   There can be multiple instances of this attribute within a single service profile.

Service Description

This attribute describes the service. This attribute is optional.

Service-Info = "Idescription"

Syntax Description

description

Description of the service.

Example

Service-Info = "ICompany Intranet Access"

Service-Defined Cookie

This attribute enables you to include user defined information in the RADIUS authentication and accounting requests.

Service-Info = "Vstring"

Syntax Description

string

Information of your choice that you wish to include in the RADIUS authentication and accounting requests.

Example (RADIUS Freeware Format)

Service-Info = "VserviceIDandAAA-ID"

Example (CiscoSecure ACS for UNIX)

9,251="VserviceIDandAAA-ID"


Note   SSG does not parse or interpret the value of the Service-Defined Cookie. You must configure the proxy RADIUS server to interpret this attribute.


Note   SSG supports only one Service-Defined Cookie per RADIUS service profile.

Full Username Attribute

This attribute indicates that the RADIUS authentication and accounting requests use the full username (user@service).

Service-Info = "X"

Example (RADIUS Freeware Format)

Service-Info = "X"

Example (CiscoSecure ACS for UNIX)

9,251="X"

Example Service Profile

The following is an example of a service profile. The profile is formatted for use with a freeware RADIUS server:

service1.com    Password = "cisco", Service-Type = outbound, Idle-Timeout = 1800, Service-Info = "R192.168.1.128;255.255.255.192", Service-Info = "R192.168.2.0;255.255.255.192", Service-Info = "R192.168.3.0;255.255.255.0", Service-Info = "Gservice1", Service-Info = "D192.168.2.81", Service-Info = "MC", Service-Info = "TP", Service-Info = "ICompany Intranet Access", Service-Info = "Oservice1.com"

The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:

user = service1.com { radius = SSG { check_items = { 2 = "cisco" 6 = 5 } reply_attributes = { 28 = 1800 9,251 = "R192.168.1.128;255.255.255.192" 9,251 = "R192.168.2.0;255.255.255.192" 9,251 = "R192.168.3.0;255.255.255.0" 9,251 = "Gservice1" 9,251 = "D192.168.2.81" 9,251 = "MC" 9,251 = "TP" 9,251 = "ICompany Intranet Access" 9,251 = "Oservice1.com" } } }

Service Group Profiles

Service group profiles contain a list of services and service groups and can be used to create directory structures for locating and logging on to services. When a user is subscribed to a service group, the user automatically is subscribed to all services and groups within that service group. A service group profile includes the password and the service type (outbound) as check attributes and a list of services and a list of service groups as reply attributes.

This section specifies vendor-specific attributes that can be used in SSG service group profiles.


Table 4-18: Service Group Profile Attributes
Attribute Usage

Service Name

Lists services that belong to the service group. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service (reply attribute).

Service Group

Lists the service subgroups that belong to this service group. When configured, the service group and service name attributes can define an organized directory structure for accessing services.

There can be multiple instances of this attribute within a service group profile. Use one attribute for each service subgroup that belongs to this service group.

Group Description

Provides a description of the service group.

Password

Specifies the password (check attribute).

Service-Type

Specifies the level of service (check attribute). Must be "outbound."

Service Name

In user profiles, this attribute subscribes the user to the specified service. In service group profiles, this attribute lists services that belong to the service group.

Account-Info = "Nname"

Syntax Description

name

Name of the service profile.

Example

    Account-Info = "Ncisco.com"
Service Group

In user profiles, this attribute subscribes a user to a service group. In service group profiles, this attribute lists the service subgroups that belong to this service group.

Account-Info = "Gname"

Syntax Description

name

Name of the group profile.

Example

    Account-Info = "GServiceGroup1"
Group Description

This attribute provides a description of the service group to the Cisco SSD. If this attribute is omitted, the service group profile name is used.

Account-Info = "Idescription"

Syntax Description

description

Description of the service group.

Example

Account-Info = "ICompany Intranet Access"

Example Service Group Profile

The following is an example of a service group profile. The profile is formatted for use with a freeware RADIUS server:

ServiceGroup1 Password = "cisco", Service-Type = outbound, Account-Info = "Nservice1.com", Account-Info = "Ngamers.net", Account-Info = "GServiceGroup3", Account-Info = "GServiceGroup4", Account-Info = "IStandard User Services"

The following is the same service group profile, formatted for CiscoSecure ACS for UNIX:

user = ServiceGroup1 { radius = SSG { check_items = { 2 = "cisco" 6 = 5 } reply_attributes = { 9,250 = "Nservice1.com" 9,250 = "Ngamers.net" 9,250 = "GServiceGroup3" 9,250 = "GServiceGroup4" 9,250 = "IStandard User Services" } } }

Pseudo-Service Profiles

This section describes pseudo-service profiles that are used to define variable length tables or lists of information in the form of services. There are currently two types of pseudo-service profiles: Transparent Passthrough Filter and Next Hop Gateway. The following sections describe both profiles.

Transparent Passthrough Filter Pseudo-Service Profile

Transparent passthrough is designed to allow unauthenticated traffic (users or network devices that have not logged in to the SSG through the Cisco SSD) to be routed through normal IOS processing. Transparent passthrough is supported only in Cisco IOS Releases 12.0(3)DC and 12.0(5)DC.

Table 4-19 lists the Cisco AVPair attributes that appear within transparent passthrough filter pseudo-service profiles. The Cisco-AVpair attributes are used to configure ACLs.


Table 4-19: Transparent Passthrough Filter Pseudo-Service Profile Attributes
Attribute Usage

Upstream Access Control List (inacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Downstream Access Control List
(outacl)

Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Upstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.

Cisco-AVpair = "ip:
inacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:inacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Downstream Access Control List

This attribute specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.

Cisco-AVpair = "ip:
outacl[#number]={standard-access-control-list | extended-access-control-list}"

Syntax Description

number

Access list identifier.

standard-access-control-list

Standard access control list.

extended-access-control-list

Extended access control list.

Example

    Cisco-AVpair="ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"

The Transparent Passthrough Filter pseudo-service profile allows or denies access to IP addresses and ports accessed through the transparent passthrough feature.

To define what traffic can pass through, the SSG downloads the Transparent Passthrough Filter pseudo-service profile. This profile contains a list of access control list (ACL) attributes. Each item contains an IP address or range of IP addresses, a list of port numbers, and specifies whether traffic is allowed or denied.

To create a filter for transparent passthrough, create a profile that contains ACL attributes that define what can and cannot be accessed.

You can also create ACLs locally. For more information, see the ssg pass-through command in the Cisco 6400 Command Reference.

Example Transparent Passthrough Filter Pseudo-Service Profile

The following is an example of the Transparent Passthrough Filter pseudo-service profile. The profile is formatted for use with a freeware RADIUS server:

ssg-filter Password = "cisco", Service-Type = outbound, Cisco-AVpair="ip:inacl#3=deny tcp 192.168.1.0 0.0.0.255 any eq 21", Cisco-AVpair="ip:inacl#7=permit ip any any"

The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:

user = ssg-filter { radius = SSG { check_items = { 2 = "cisco" 6 = 5 reply_attributes = { 9,1 = "ip:inacl#3=deny tcp 192.168.1.0 0.0.0.255 any eq 21", 9,1 = "ip:inacl#7=permit ip any any" } } }

Next Hop Gateway Pseudo-Service Profile

Because multiple SSGs might access services from different networks, each service profile can specify a next hop key, which is any string identifier, rather than an actual IP address. For each SSG to determine the IP address of the next hop, each SSG downloads its own next hop gateway table that associates keys with IP addresses.


Table 4-20: Next Hop Gateway Pseudo-Service Profile Attributes
Attribute Usage

Next Hop Gateway Table Entry

Associates next hop gateway keys with IP addresses.

Next Hop Gateway Table Entry

Because multiple SSGs might access services from different networks, each service profile specifies a next hop key rather than an actual IP address. For each SSG to determine the IP address of the next hop, each SSG downloads its own next hop gateway table that associates keys with IP addresses. For information on defining next hop keys, see the "Service Next Hop Gateway" section.


Note   This attribute is only used in Next Hop Gateway pseudo-service profiles and should not appear in service profiles or user profiles.

Control-Info = "Gkey;ip_address"

Syntax Description

key

Service name or key specified in the Service Next Hop Gateway service profile.

ip_address

IP address of the next hop for this service.

Usage

Use this attribute to create a next hop gateway table for the selected SSG.

To define the IP address of the next hop for each service, the SSG downloads a special service profile that associates the next hop gateway key for each service with an IP address.

To create a next hop gateway table, create a service profile and give it any name. Use this attribute to associate service keys with their IP addresses. When you have finished, repeat this for each SSG.

For more information, see the ssg next-hop command in the Cisco 6400 Command Reference.

Example

Control-Info = "GNHT_for_SSG_1;192.168.1.128"

To create a next hop gateway table, create a profile and give it any name. Use the Next Hop Gateway Entry attribute to associate service keys with their IP addresses. When you have finished, repeat this for each SSG if the next hop IP addresses are different. For an example next hop gateway pseudo-service profile, see "Example Transparent Passthrough Filter Pseudo-Service Profile".

For more information, see the ssg next-hop command in the Cisco 6400 Command Reference.

Example NextHop Gateway Pseudo-Service Profile

The following is an example of the Next Hop Gateway pseudo-service profile. The profile is formatted for use with a freeware RADIUS server:

nht1           Password = "cisco", Service-Type = outbound, Account-Info = "Gservice3;192.168.103.3", Account-Info = "Gservice2;192.168.103.2", Account-Info = "Gservice1;192.168.103.1", Account-Info = "GLabservices;192.168.4.2", Account-Info = "GWorldwide_Gaming;192.168.4.2"

The following is the same Next Hop Gateway pseudo-service profile, formatted for CiscoSecure ACS for UNIX:

user = nht1{ radius= SSG { check_items= { 2=cisco 6=5 } reply_attributes= { 9,253="Gservice3;192.168.103.3" 9,253="Gservice2;192.168.103.2" 9,253="Gservice1;192.168.103.1" 9,253="GLabservices;192.168.4.2" 9,253="GWorldwide_Gaming;192.168.4.2" } }

RADIUS Accounting Records

This section describes events that generate RADIUS accounting records and the attributes associated with the accounting records sent from the SSG to the accounting server.

Account Logon

When a user logs in, the SSG sends a RADIUS accounting-request on behalf of the user to the accounting server. The attributes associated with this record are:

Acct-Status-Type = Start NAS-IP-Address = ip_address User-Name = "username" Acct-Session-Id = "session_id" Framed-IP-Address = user_ip Proxy-State = "n"

ip_address

IP address of the SSG.

username

Name used to log in to the service provider network.

session_id

Session number.

user_ip

IP address of the user's system.

n

Accounting record queuing information (has no effect on account billing).

Account Logoff

When a user logs off, the SSG sends a RADIUS accounting-request on behalf of the user to the accounting server. The attributes associated with this record are:

Acct-Status-Type = Stop NAS-IP-Address = ip_address User-Name = "username" Acct-Session-Time = time Acct-Terminate-Cause = cause Acct-Session-Id = "session_id" Framed-Address = user_ip Proxy-State = "n"

ip_address

IP address of the SSG.

username

Name used to log on to the service provider network.

time

Length of session in seconds.

cause

Cause of account termination. These can include:

  • User-Request.

  • Session-Timeout.

  • Idle-Timeout.

  • Lost-Carrier.

session_id

Session number.

user_ip

IP address of the user's system.

n

Accounting record queuing information (has no effect on account billing).

Connection Start

When a user accesses a service, the SSG sends a RADIUS accounting-request to the accounting server. The attributes associated with this record are:

NAS-IP-Address = 172.16.6.1 NAS-Port = 0 NAS-Port-Type = Virtual User-Name = "username" Acct-Status-Type = Start Acct-Authentic = RADIUS Service-Type = Framed Acct-Session-Id = "00000010" Framed-Protocol = PPP Service-Info = "Nisp-name.com" Service-Info = "Uusername" Service-Info = "TP" Acct-Delay-Time = 0

ip_address

IP address of the SSG.

username

Name used to log on to the service provider network.

session_id

Session number.

service

Name of the service profile.

hg_username

The username used to authenticate the user with the remote RADIUS server. This attribute is used for proxy services.

type

X—Proxy connection.

P—Passthrough connection (usually the Internet).

n

Accounting record queuing information (has no effect on account billing).

Connection Stop

When a user terminates a service, the SSG sends a RADIUS accounting-request to the accounting server. The attributes associated with this record are:

NAS-IP-Address = 192.168.2.48 NAS-Port = 0 NAS-Port-Type = Virtual User-Name = "zeus" Acct-Status-Type = Stop Service-Type = Framed-User Acct-Session-Id = "00000002" Acct-Terminate-Cause = User-Request Acct-Session-Time = 84 Acct-Input-Octets = 0 Acct-Output-Octets = 649 Acct-Input-Packets = 0 Acct-Output-Packets = 17 Framed-Protocol = PPP Framed-IP-Address = 201.168.101.10 Control-Info = "I0;0" Control-Info = "O0;649" Service-Info = "Ninternet" Service-Info = "Uzeus" Service-Info = "TP" Acct-Delay-Time = 0

ip_address

IP address of the SSG.

username

Name used to log on to the service provider network.

in_bytes

Number of inbound bytes.

out_bytes

Number of outbound bytes.

time

Length of session in seconds.

cause

Cause of service termination. These include:

  • User-Request.

  • Lost-Carrier.

  • Lost-Service.

  • Session-Timeout.

  • Idle-Timeout.

session_id

Session number.

service

Name of the service profile.

hg_username

The username used to authenticate the user with the remote RADIUS server. This attribute is used for proxy services.

type

X—Proxy connection.

P—Passthrough connection (usually the Internet).

n

Accounting record queuing information (has no effect on account billing).

Attributes Used in Accounting Records

Service User

This attribute indicates the username provided by the Cisco SSD user to log on to the service and for authentication with the home gateway.

Service-Info = "Uusername"

Syntax Description

username

The name provided by the user for authentication.

Example
Service-Info = "Ujoe@cisco.com"
Note   This attribute is only used for accounting purposes and does not appear in profiles.

Service Name

This attribute defines the name of the service.

Service-Info = "Nname"

Syntax Description

name

Name of the service profile or service that belongs to a service group.

Example
Service-Info = "Nservice1.com"
Note   This attribute is only used for accounting purposes and does not appear in profiles.

Octets Output

Current RADIUS standards only support the counting of up to 32 bits of information with the ACCT-Output-Octets attribute. Standards such as ADSL have much higher throughput.

In order for the accounting server to keep track of and bill for this usage, the SSG uses the Octets attribute.

The Octets Output attribute keeps track of how many times the 32-bit integer rolled over and the value of the integer when it overflowed for outbound data.

Control-Info = "Orollover;value"

Syntax Description

rollover

Number of times the 32-bit integer rolled over to 0.

value

Value in the 32-bit integer when the stop record was generated and the service or user was logged out.

Usage

Use this attribute to accurately keep track of and bill for usage. To calculate the actual number of bytes, use the following formula:

rollover * 232 + value

Example

In the following example, the rollover is 2 and the value is 153 (2 * 232 + 153 = 8589934745):

Control-Info = "O2;153"
Note   This attribute is only used for accounting purposes and does not appear in profiles.

Octets Input

Current RADIUS standards only support the counting of up to 32 bits of information with the ACCT-Input-Octets attribute. Standards such as ADSL have much higher throughput.

In order for the accounting server to keep track of and bill for this usage, the SSG uses the Octets attribute.

The Octets Input attribute keeps track of how many times the 32-bit integer rolled over and the value of the integer when it overflowed for inbound data.

Control-Info = "Irollover;value"

Syntax Description

rollover

Number of times the 32-bit integer rolled over to 0.

value

Value in the 32-bit integer when the stop record was generated and the service or user was logged out.

Usage

Use this attribute to accurately keep track of and bill for usage. To calculate the actual number of bytes, use the following formula:

rollover * 232 + value

Example

In the following example, the rollover is 3 and the value is 151 (3 * 232 + 151 = 12884902039):

Control-Info = "I3;151"
Note   This attribute is only used for accounting purposes and does not appear in profiles.

Configuration Example

The configuration examples in this section support the network topology shown in Figure 4-2.


Figure 4-2: Example SSG Network Topology


Security

aaa new-model aaa authentication ppp default radius aaa authorization network default radius ssg service-password cisco ssg radius-helper auth-port 1645 acct-port 1646 ssg radius-helper key cisco radius-server host 192.168.100.28 auth-port 1645 acct-port 1646 radius-server key cisco radius-server vsa send accounting radius-server vsa send authentication

Default Network

ssg default-network 192.168.100.24 255.255.255.255

Interfaces

ssg bind direction uplink ATM0/0/0.1 ssg bind direction uplink ATM0/0/0.2 ssg bind direction uplink ATM0/0/0.3 ssg bind direction downlink BVI1

Services

ssg bind service Labservices 192.168.123.1 ssg bind service Worldwide_Gaming 192.168.113.1 ssg bind service ACME_ISP 192.168.103.1 ssg next-hop download nhg1 cisco ssg maxservice 10

The following is an example service profile as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.

user = ACME_ISP{ profile_id = 2026 profile_cycle = 12 member = ServicesGroup radius=6510-SSG-v1.1a { check_items= { 2=cisco 6=5 } reply_attributes= { 9,251="R192.168.250.0;255.255.255.0" 9,251="TX" 9,251="S192.168.250.11;1645;1646;cisco" } } }

Service Search Order

ssg service-search-order local remote

Next-Hop Table

ssg next-hop download nht1 cisco

The following is an example next-hop table as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.

ssg next-hop download nht1 cisco user = nht1{ radius= SSG { check_items= { 2=cisco 6=5 } reply_attributes= { 9,253="GACME_ISP;192.168.103.1" 9,253="GLabservices;192.168.123.1" 9,253="GWorldwide_Gaming;192.168.113.1" } } }

Max Services

ssg maxservice 10

Local Service Profile

local-profile Labservices attr 26 9 251 "R192.168.123.1;255.255.255.0" attr 26 9 251 "S192.168.252.11;1645;1646;cisco" attr 26 9 251 "OAnyProxyService.Com" attr 26 9 251 "TX" attr 2 "cisco" attr 6 5

Transparent Passthrough Filter

ssg pass-through filter download tptfilter1 cisco

The following is an example transparent passthrough filter as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.

user = tptfilter1{ radius= SSG { check_items= { 2=cisco 6=5 } reply_attributes= { 9,1="ip:inacl#2=deny tcp 172.16.4.0 0.0.0.255 192.168.250.0 0.0.0.255 eq 23" 9,1="ip:inacl#5=permit ip any any" 9,1="ip:inacl#1=permit tcp any any established" } } }

Redundancy

redundancy main-cpu auto-sync standard no secondary console enable

Fastswitching

There will be nothing in the running configuration for fastswitching when it is enabled.

Multicast

ssg multicast

RADIUS Interim Accounting

ssg accounting interval 600

The following example RADIUS accounting records will be sent to the appropriate server every 600 seconds while the user is logged on to the SSG:

Account Update

NAS-IP-Address = 172.16.11.1 NAS-Port = 0 NAS-Port-Type = Virtual User-Name = "cisco" Acct-Status-Type = Update Acct-Authentic = RADIUS Service-Type = Framed Acct-Session-Id = "00000000" Acct-Session-Time = 77 Acct-Input-Octets = 0 Acct-Output-Octets = 0 Acct-Input-Packets = 0 Acct-Output-Packets = 0 Framed-Protocol = PPP Framed-IP-Address = 172.16.11.12 Control-Info = "I0;0" Control-Info = "O0;0" Acct-Delay-Time = 0

Connection Update

NAS-IP-Address = 172.16.11.1 NAS-Port = 0 NAS-Port-Type = Virtual User-Name = "cisco" Acct-Status-Type = Update Acct-Authentic = RADIUS Service-Type = Framed Acct-Session-Id = "00000012" Acct-Session-Time = 8 Acct-Input-Octets = 0 Acct-Output-Octets = 0 Acct-Input-Packets = 0 Acct-Output-Packets = 0 Framed-Protocol = PPP Control-Info = "I0;0" Control-Info = "O0;0" Service-Info = "Nservice.com" Service-Info = "Uname" Service-Info = "TX" Acct-Delay-Time = 0

CEF

ip cef

IOS NAT

interface ATM0/0/0.10 multipoint ip address 192.168.103.12 255.255.255.0 no ip directed-broadcast ip nat outside ip pim sparse-dense-mode ip pim multipoint-signalling map-group mapgroup1 atm multipoint-signalling atm esi-address 202020202020.10 interface Virtual-Template1 ip unnumbered FastEthernet0/0/0 no ip directed-broadcast ip nat inside ip mroute-cache keepalive 60 peer default ip address pool pool1 ppp authentication pap

Service Name to VC Mapping

ssg vc-service-map public1 1/37 non-exclusive

Monitoring and Troubleshooting SSG

Table 4-21 describes the commands that help you monitor and maintain the SSG.


Table 4-21: SSG Monitoring and Troubleshooting Commands
Command Purpose
Router# show ssg connection ip-address service-name

Displays the connections of a given host and service name.

Router# clear ssg connection ip-address service-name

Removes the connections of a given host and service name.

Router# show ssg pass-through-filter

Displays the downloaded filter for transparent passthrough.

Router# clear ssg pass-through-filter

Removes the downloaded filter for transparent passthrough. To remove the filter from NVRAM, enter the no form of the ssg pass-through command.

Router# show ssg host [ip-address] [username]

Displays the information about a subscriber and the current connections of the subscriber.

Router# clear ssg host ip-address

Removes a given host or subscriber.

Router# show ssg direction

Displays the direction of all interfaces for which a direction has been specified.

Router# show ssg next-hop

Displays the next-hop table.

Router# clear ssg next-hop

Removes the next-hop table. To remove the next-hop table from NVRAM, enter the no form of the ssg next-hop command. (See the Cisco6400 Command Reference.)

Router# show ssg binding

Displays service names that have been bound to interfaces and the interfaces to which they have been bound.

Router# show ssg service service-name

Displays the information for a service.

Router# clear ssg service service-name

Removes a service.

RADIUS

To troubleshoot communication between the RADIUS server and the NRP, enter the debug radius command.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Tue Feb 26 15:37:01 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.