|
|
This chapter describes the Service Selection Gateway (SSG) features supported in Cisco IOS Release 12.2(2)B and the RADIUS profiles, vendor-specific attributes and accounting records used with the SSG features. This chapter contains the following sections:
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) or its successor product, the Cisco Subscriber Edge Services Manager (SESM). Together with the SESM or SSD, SSG provides subscriber authentication, service selection, and service connection capabilities to subscribers of Internet services. Subscribers interact with an SESM or SSD web application using a standard Internet browser.
The SESM operates in two modes:
This chapter provides information on general SSG configuration that applies to SESM in DESS mode and RADIUS mode. It also provides RADIUS-specific configuration information that only applies to SESM in RADIUS mode or SSD.
If your deployment uses SESM in DESS mode, these documents provide additional information on DESS-mode topics:
These documents can be found:
 |
Note The SESM and SSD functionality described in this document is available only with the SSG with
Web Selection product. In the rest of this chapter, all references to SESM also apply to SSD—unless a clear distinction is made. |
Figure 4-1 shows a diagram of a sample 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 carrier-class broadband aggregator, 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.
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 SESM 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 SESM web server application. SESM forwards user login information to the SSG, which forwards the information to the either the AAA server for the SSD or SESM in RADIUS mode, or to the RADIUS/DESS Proxy (RDP) component of SESM for SESM in DESS mode.
Based on the contents of the Access-Accept response, SESM presents a 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 optionally 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 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. |
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 SESM. The SESM prompts the user for a username and password. After the user is authenticated, SESM presents a list of available services.
The SESM provides all the functionality of its predecessor product, the SSD. SESM also introduces the following functionality:
The SSG is designed to work with RADIUS-based AAA servers that accept vendor-specific attributes (VSAs).
The SSG using SESM in DESS mode can use an LDAP directory as the data repository for service, subscriber, and policy information.
The SSG supports the following types of services:
The SSG uses IOS access control lists (ACLs) to prevent users, services, and passthrough traffic from accessing specific IP addresses and ports.
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 are 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.
Note that this attribute overrides the IP routing table for packets destined to a service.
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.
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 are switched to the secondary server if the primary server fails to respond with a DNS reply within a certain time limit.
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.
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.
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.
SSG supports L2TP. When a subscriber selects a service through SESM, 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).
SSG can be enabled to forward packets locally between directly connected subscribers.
To log in to a service through SESM, a subscriber has to log in only twice: once for the PPP session and once for the service.
|
Note All references to SESM also apply to SSD unless a clear distinction is made. |
The SSG Host Key feature enhances communication and functionality between SSG and SESM.
With the SSG Host Key feature, SSG performs port address translation (PAT) and NAT on the HTTP traffic between the subscriber and the SESM server. When a subscriber sends an HTTP packet to the SESM server, SSG creates a port map that changes the source IP address to a configured SSG source IP address and changes the source TCP port to a port allocated by SSG. The SSG assigns a bundle of ports to each subscriber because one subscriber can have several simultaneous TCP sessions when accessing a web page. The assigned host key, or combination of port bundle and SSG source IP address, uniquely identifies each subscriber. The host key is carried in RADIUS packets sent between the SESM server and SSG as a Host-Key vendor-specific attribute. When the SESM server sends a reply to the subscriber, SSG translates the destination IP address and destination TCP port according to the port map.
For each TCP session between a subscriber and the SESM server, SSG uses one port from the port bundle as the port map. Port mappings are flagged as eligible for reuse based on inactivity timers, but are not explicitly removed once assigned. The number of port bundles are limited, but you can assign multiple SSG source IP addresses to accommodate more subscribers.
SSG assigns the base port of the port bundle to a port map only if SSG has no state information for the subscriber, or if the state of the subscriber has changed. When the SESM server sees the base port of a port bundle in the host key, SESM knows that it needs to query SSG for new subscriber state information.
The SSG Host Key feature provides the following benefits:
Support for Overlapped Subscriber IP Addresses Extended to Include SESM Usage
Without the SSG Host Key feature, PPP users are allowed to have overlapped subscriber IP addresses, but they cannot use SSG with Web Selection to conduct service selection through the web-based SESM user interface.
With the SSG Host Key feature, PPP users can have overlapped IP addresses while using SSG with Web Selection. The subscriber IP addresses are also not required to be routable within the service management network where the SESM server resides, because the host key enables support for private addressing schemes.
Cisco SESM Provisioning for Subscriber and SSG IP Addresses Is No Longer Required
Without the SSG Host Key feature, SESM must be provisioned for subscriber and SSG IP addresses before SESM is able to send RADIUS packets to SSG, or send HTTP packets to subscribers.
The SSG Host Key feature eliminates the need to provision SESM in order to allow one SESM server to serve multiple SSGs, and to allow one SSG to be served by multiple SESM servers.
Reliable and Just-in-Time Notification to Cisco SSD of Subscriber State Changes
Without the SSG Host Key feature, SSG uses an asynchronous messaging mechanism to immediately notify the SESM server of subscriber state changes in SSG (such as session time outs or idle time-out events).
The SSG Host Key feature replaces the asynchronous messaging mechanism with an implicit and reliable notification mechanism that uses the base port of a port bundle to alert the SESM server of a state change. The SESM server can then query SSG for the true state of the subscriber and update the cached object or send the information back to the subscriber.
Support for Additional Data in Subscriber Account Queries
The SESM server queries SSG and receives the following information in reply:
The subscriber can query its account status manually or automatically. Each account query results in an update of the SESM user interface. The SSG Host Key feature enables the account query reply to include additional information, such as an account token.
Support for Multiple Accounts for One Subscriber IP Address
To accommodate multiple users sharing a single PC, the SSG Host Key feature supports multiple subaccounts each with a different username under one subscriber. When the SESM server contacts SSG to log in a new user to an already logged in account, SSG logs off the existing account and logs in the new user. In account switching, the port bundle and host object remain the same, but the content of the host object is changed according to the profile of the subaccount user.
Do not bind an open garden service to an interface that is bound to another service. Use the show ssg binding privileged EXEC command to view services and the interfaces to which they have been bound.
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).
If you use SSD as a captive portal, this feature requires Cisco SSD Release 3.0(1). Alternately, you can use any release of Cisco SESM.
Cisco Subscriber Edge Services Manager
If you want to perform Layer 3 service selection, you must install and configure the Cisco SESM as described in the Cisco Subscriber Edge Services Manager and Subscriber Policy Engine Installation and Configuration Guide .
In order to use the Single Host Logon feature, you must install and configure Cisco SESM or Cisco SSD version 2.5 or later versions.
To achieve 2000 L2TP sessions, you need at least 128 MB of DRAM on the NRP.
The SSG Host Key feature requires Cisco SSD Release 3.0(1) or Cisco SESM Release 3.1(1). If you are using an earlier release of SSD, disable the SSG Host Key feature with the no ssg port-map enable global configuration command.
This section contains the following tasks that apply to the SSG when used with SSD or with SESM in RADIUS or DESS mode:
|
Note The following tasks apply to the SSG only when used with SSD or with SESM in RADIUS mode: |
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. |
To verify that SSG is enabled, enter the EXEC command show running-config.
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 the "Configuring RADIUS Profiles" section 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] | Configures an attribute in a local RADIUS service profile. |
Enter the show running-config command to verify that local service profiles have been configured correctly.
| 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} | 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 SSG and SESM. |
Router(config)# ssg radius-helper [auth-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. |
Enter the show running-config command to verify that security has been configured correctly.
Configure the first IP address or subnet that users are able to access without authentication. This is the address where the Cisco SESM resides.
| Command | Purpose |
|---|---|
Router(config)# ssg default-network
ip-address mask
| Sets the IP address or subnet that users are able to access without authentication. Typically, this is the address where the Cisco SESM resides. A mask provided with the IP address specifies the range of IP addresses that users are able to access without authentication. |
Enter the show running-config command to verify that the default network has been configured correctly.
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.
Configure all interfaces that are connected to services as uplink interfaces.
| Command | Purpose |
|---|---|
Router(config)# ssg bind direction uplink {ATM atm-interface | Specifies an uplink interface, that is, the interface to the services. |
Enter the show ssg direction command to verify that interfaces have been configured correctly.
|
Note Every service must be bound to an uplink interface. |
| Command | Purpose |
|---|---|
Router(config)# ssg bind service service
{ip-address | ATM | Specifies the interface for a service. |
Router(config)# ssg service-search-order
local | remote | | (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] | (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. |
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.
|
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. |
Enter the show running-config command to verify that fastswitching has been enabled. Because fastswitching is enabled by default, it is not displayed in the running configuration. If fastswitching has been disabled, the following line appears in the output of the show running-config command:
no ssg fastswitch
|
Note This task is optional. Multicast is disabled by default. |
| Command | Purpose |
|---|---|
Router(config)# ssg multicast
| Enables multicast. When multicast is enabled, the SSG forwards 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. |
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
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 "Configuration Example" 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. |
Enter the show running-config command to verify that the accounting interval has been set correctly.
|
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)# | Enables global IP CEF. |
Enter the show running-config and show ip cef commands to verify that CEF has been enabled.
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)# | Specifies the outside interface from which services are accessed. |
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.
|
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 | Map VCs to service names. |
Enter the show running-config and show ssg vc-service-map command to view service name to VC mappings.
| Command | Purpose |
|---|---|
Router#show ssg vc-service-map
| Displays VC to service name mappings. |
|
Note Before configuring this feature, see the prerequisites for Layer 2 Tunnel Protocol. |
To configure SSG with L2TP Service Type, perform the following tasks:
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. |
To verify the NRP-LAC configuration, enter the EXEC command show running-config.
The following vendor-specific attributes are used by the SSG to support L2TP:
For general information on configuring RADIUS profiles for SSG, see the "Configuring RADIUS Profiles" section.
Table 4-1 lists the Cisco-AVpair attributes used in the service profile to configure VPDN.
| Attribute | Usage |
|---|---|
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections. | |
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group. | |
Specifies the secret (password) used for L2TP tunnel authentication. |
Table 4-2 lists the Account-Info attribute used in the user profile to subscribe the user to a VPDN service.
| Attribute | Usage |
|---|---|
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). |
Table 4-3 lists the Service-Info attribute used in the service profile to define the L2TP service parameter.
| Attribute | Usage |
|---|---|
Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough. | |
Specifies the PPP MTU size of the SSG as an L2TP access concentrator (LAC). By default, the PPP MTU size is 1500 bytes. Note SESM in DESS mode does not support use of this attribute. |
To verify the RADIUS profiles, refer to the user documentation for your RADIUS server.
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)# | Accepts incoming L2TP tunnel connections. Also specifies the virtual template interface to use to clone the new virtual access interface. |
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 | Configures the interface as unnumbered and provides a local address. |
Step 9 | Router(config-if)#peer default ip address | 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 | Specifies the order in which the CHAP or PAP protocols are requested on the interface. |
This section provides the following configuration examples:
The following example shows a basic SSG configuration for a LAC:
!
vpdn enable
ssg enable
!
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"
}
}
}
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="B1500"
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"
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
!
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 | | Displays SSG L2TP information, including dialer configuration, dialer-list tables, tunnel information, and vpdn-group information. |
show vpdn tunnel [all | packets | state | summary | transport] | 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]| | 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. |
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. |
In the following configuration, local forwarding is enabled:
!
ssg enable
ssg local-forwarding
!
To verify that you enabled local forwarding, enter the show running-config EXEC command.
|
Note Before configuring this feature, see the restrictions for Open Garden. |
An "open garden" is a collection of websites or networks that users can access as long as they have physical access to the network. Users do not need to provide authentication information before accessing the websites in the open garden. A "walled garden," on the other hand, refers to a collection of websites or networks that users can access after providing minimal authentication information.
SSG handles the default network and the open garden as services that have associated domain names and DNS addresses. As many as 100 domains can be associated with the open garden. 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 SESM, which typically resides on the management network with a private address, even when the subscriber is assigned a public DNS server.
|
Note RADIUS accounting records are not created for open garden services. |
To configure an open garden, complete the following steps beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# local-profile
profile-name
| Creates a local service profile and enters profile configuration mode. |
Step 2 | Router(config-prof)# attribute 26 9 251(Repeat step as necessary.) | (Service Route attribute) Specifies the network available to the service. You can add multiple networks to an open garden service. |
Router(config-prof)# attribute 26 9 251 | (DNS Server Address attribute) Specifies the DNS server for the service. | |
Step 4 | Router(config-prof)# attribute 26 9 251(Repeat step as necessary.) | (Domain Name attribute) Specifies the domain name that gets DNS resolution from the DNS server specified in Step 3. You can add multiple domain names to an open garden service. |
Step 5 | Router(config-prof)# exit
| Returns to global configuration mode. |
Step 6 | Router(config)# ssg open-garden
profile-name
| Designates the service as an open garden service. |
Example
In the following example, two services, called "nrp1-nrp2_og1" and "nrp1-nrp2_og1," are defined and added to the open garden.
!
ssg open-garden nrp1-nrp2_og1
ssg open-garden nrp1-nrp2_og2
!
local-profile nrp1-nrp2_og1
attribute 26 9 251 "Oopengarden1.com"
attribute 26 9 251 "D10.13.1.5"
attribute 26 9 251 "R10.1.1.0;255.255.255.0"
local-profile nrp1-nrp2_og2
attribute 26 9 251 "Oopengarden2.com"
attribute 26 9 251 "D10.14.1.5"
attribute 26 9 251 "R10.2.1.0;255.255.255.0"
attribute 26 9 251 "R10.3.1.0;255.255.255.0"
!
Use the show ssg open-garden privileged EXEC command to list all configured open garden services:
Router# show ssg open-garden
nrp1-nrp2_og1
nrp1-nrp2_og2
nrp1-nrp2_og3
nrp1-nrp2_og4
Use the following commands to monitor and troubleshoot open garden services:
| Command | Purpose |
|---|---|
Router# clear ssg open-garden
| Removes all instances of the ssg open-garden command from the configuration. |
Router# clear ssg service profile-name
| Removes the service object of the specified open garden service from the SSG service object table. |
Router# show ssg open-garden
| Lists all open garden services. |
Router# show ssg service [service-name]
| Displays detailed information about a service. If no service-name is entered, this command displays information for all services. |
Examples
In the following example, all open garden services are displayed:
Router# show ssg open-garden
nrp1-nrp2_og110
nrp1-nrp2_og111
nrp1-nrp2_og112
nrp1-nrp2_og113
In the following example, detailed information is displayed for one of the open garden services:
Router# show ssg service nrp1-nrp2_og110
------------------------ ServiceInfo Content -----------------------
Uplink IDB: gw:0.0.0.0
Name:nrp1-nrp2_og110
Type:PASS-THROUGH
Mode:CONCURRENT
Service Session Timeout:0 seconds
Service Idle Timeout:0 seconds
Authentication Type:CHAP
DNS Server(s):Primary:10.13.1.5
Included Network Segments:
10.1.1.0/255.255.255.0
Excluded Network Segments:
ConnectionCount 0
Full User Name not used
Domain List:opengarden110.com;
------------------------ End of ServiceInfo Content ----------------
|
Note Before configuring this feature, see the restrictions for TCP Redirect - Logon. |
The TCP Redirect - Logon feature redirects certain packets, which would otherwise be dropped, to captive portals that can handle the packets in a suitable manner. For example, packets sent upstream by unauthorized users are forwarded to a captive portal that can redirect the users to a logon page. Similarly, if users try to access a service to which they have not logged on, the packets are redirected to a captive portal that can provide a service logon screen.
The captive portal can be any server that is programmed to respond to the redirected packets. If the Cisco SESM is used as a captive portal, subscribers are sent automatically to the SESM logon page when they start a browser session. The SESM captive portal application can also capture a URL in a subscriber's request and redirect the browser to the originally requested URL after successful authentication.
Redirected packets are always sent to a captive portal group that consists of one or more servers. SSG selects one server from the group in a round robin fashion to receive the redirected packets.
To configure the TCP Redirect - Logon feature, complete the following steps beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 * | Router(config)# ssg http-redirect group groupname
server ip-address port
(Repeat step as necessary.) | Defines a captive portal group. When the command is entered again with the same groupname, this command adds another server or port to that group. When entered with a unique groupname, this command defines a new captive portal group. |
Step 2 | Router(config)# ssg http-redirect unauthorized-user
group groupname
| Specifies the default captive portal group where packets from unauthorized users are sent. |
Example
In the following example, two captive portal groups are defined: RedirectServer and SESMgroup. RedirectServer contains two servers with IP addresses 10.1.1.1 and 10.2.3.4 for the same TCP port 8080. SESMgroup contains one server at 10.1.1.1 for TCP port 8081. RedirectServer is specified as the default captive portal group where packets from unauthorized users are sent.
!
ssg http-redirect group RedirectServer server 10.1.1.1 8080
ssg http-redirect group RedirectServer server 10.2.3.4 8080
ssg http-redirect group SESMgroup server 10.1.1.1 8081
ssg http-redirect unauthorized-user group RedirectServer
!
Use the show ssg http-redirect group privileged EXEC command to:
Use the following commands to monitor and troubleshoot the TCP Redirect - Logon feature:
| Command | Purpose |
|---|---|
Router# show ssg http-redirect group
[groupname]
| Lists all configured captive portal groups and indicates which group receives redirected packets from unauthorized users. If the groupname is specified, this command displays detailed information about that captive portal group. |
Router# show ssg http-redirect mappings
[ip-address]
| Displays the redirect mappings currently stored in SSG. If the host ip-address is provided, this command displays detailed redirect mapping information for the specified host. |
Router# debug ssg http-redirect
| Displays debug messages for the TCP Redirect - Logon feature. |
Examples
In the following example, all configured captive portal groups are listed, and the unauthorized user redirect group is specified:
Router# show ssg http-redirect group
Current HTTP redirect groups:
RedirectServer
SESMgroup
Unauthorized user redirect group:RedirectServer
In the following example, detailed information is displayed about the RedirectServer and SESMgroup captive portal groups. Note, however, that redirectable destination networks and TCP ports are not supported in this release, so the last two lines of the following output are insignificant.
Router# show ssg http-redirect group RedirectServer
HTTP redirect group RedirectServer;
Showing all HTTP servers (Address, Port):
10.1.1.1, 8080
10.2.3.4, 8080
No redirectable destination networks defined.
No redirectable TCP ports defined.
Router# show ssg http-redirect group SESMgroup
HTTP redirect group SESMgroup;
Showing all HTTP servers (Address, Port):
10.1.1.1, 8081
No redirectable destination networks defined.
No redirectable TCP ports defined.
In the following example, there are no redirect mappings currently stored in SSG:
Router# show ssg http-redirect mappings
No Http redirect mappings
In the following example, there are no redirect mappings currently stored in SSG for the user with IP address 10.8.8.7:
Router# show ssg http-redirect mappings 10.8.8.7
Host Address:10.8.8.7 has no stored redirect mappings
In the following example, all redirect mappings stored in SSG are displayed:
Router# show ssg http-redirect mappings
HTTP remapping Host:10.8.8.7 to server:10.1.1.1 on port:8080
HTTP remapping Host:10.8.8.8 to server:10.1.1.1 on port:8080
In the following example, detailed redirect mapping information is displayed for the user with IP address 10.8.8.7:
Router# show ssg http-redirect mappings 10.8.8.7
HTTP remapping Host:10.8.8.7 to server:10.1.1.1 on port:8080
Connection Mappings (src port <-> dest IP,dest port,timestamp,flags):
1092 <-> 2.5.8.4,8080,1001321447,0x0
1093 <-> 2.5.8.4,8080,1001321456,0x0
Before configuring this feature, see the restrictions for Host Key.
|
Note The SSG Host Key feature requires Cisco SSD Release 3.0(1) or Cisco SESM Release 3.1(1). If you are using an earlier release of SSD, disable the SSG Host Key feature with the no ssg port-map enable global configuration command. |
To configure the SSG Host Key feature, complete the following tasks:
|
Note All references to SESM also apply to SSD unless a clear distinction is made. |
The host key is disabled by default. You can enable the host key by entering the following commands:
| Command | Purpose |
|---|---|
Router(config)# ssg port-map enable | Enables the host key. |
Router# reload | You must reload the router for the previous command to take effect. |
Example
ssg port-map enable
The host key requires that you specify the subscriber traffic to be port mapped. SSG can compare the subscriber traffic against a configured TCP port range or an access list. SSG port maps the packets specified with one or both of the following global configuration commands:
| Command | Purpose |
|---|---|
Router(config)# ssg port-map destination range | Specifies the TCP port range to compare against the subscriber traffic. Optionally specifies the destination IP address in the packets. |
Router(config)# ssg port-map destination access-list access-list-number | Specifies an access list to compare against the subscriber traffic. |
|
Note You can use multiple entries of the ssg port-map destination commands. The port ranges and access lists are checked in the order in which they are defined. |
Example
ssg port-map enable
ssg port-map destination range 8080 to 10100 ip 70.13.6.100
ssg port-map source ip Loopback1
The Host Key feature requires that one or more SSG source IP addresses are specified for host key usage. One source IP address will permit the allocation of 4032 unique host keys, assuming a bundle length of 4 bits. For higher subscriber counts, configure additional addresses.
|
Note All SSG source IP addresses configured with the ssg port-map source ip command must be routable in the management network where the SESM resides. |
To specify SSG source IP addresses, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)# ssg port-map source ip {ip-address | interface} | Specifies an SSG source IP address. If you specify an interface instead of an IP address, SSG uses the main IP address of the specified interface. |
|
Note You can use multiple entries of the ssg port-map source ip commands. |
The port-bundle length is used to determine the number of bundles in one group and the number of ports in one bundle. By default, the port-bundle length is 4 bits. The maximum port-bundle length is 10 bits. See Table 4-4 for available port-bundle length values, and the resulting port per bundle and bundle per group values. Increasing the port-bundle length can be useful when you see frequent error messages of running out of ports in a port bundle, but note that the new value does not take effect until the SSG next reloads, and SESM restarts.
|
Note For each SESM server, all connected SSGs must have the same port-bundle length, which must correspond to the configured value given in the SESM server's BUNDLE_LENGTH argument. If you change the port-bundle length on an SSG, be sure to make the corresponding change in the SESM configuration. |
| Port-Bundle Length (in bits) | Number of Ports per Bundle | Number of Bundles per Group (and per SSG Source IP Address) |
|---|---|---|
1 | 2 | 32256 |
2 | 4 | 16128 |
3 | 8 | 8064 |
4 (default) | 16 | 4032 |
5 | 32 | 2016 |
6 | 64 | 1008 |
7 | 128 | 504 |
8 | 256 | 252 |
9 | 512 | 126 |
10 | 1024 | 63 |
To modify the port-bundle length upon the next SSG reload, enter the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)# ssg port-map length bits | (Takes effect upon next reload.) Modifies the port-bundle length, which is used to determine the number of ports per bundle and the number of bundles per group, as detailed in Table 4-4. |
Router# show running-config
Step 2 To verify successful configuration of the SSG Host Key feature, enter the following command:
Router# show ssg port-map status
Bundle-length = 4
Bundle-groups:-
IP Address Free Bundles Reserved Bundles In-use Bundles
70.13.60.2 4032 0 0
Use the following commands to monitor and troubleshoot the SSG Host Key feature:
| Command | Purpose |
|---|---|
Router# show ssg port-map status | Displays information on port-bundle groups, including:
|
Router# show ssg port-map ip ip-address | Displays the following information about a port bundle:
|
Router# show ssg host ip-address interface
| Displays the information about a subscriber and current connections of the subscriber. |
Router# show ssg connection | Displays the connections of a given host and a service name. |
Router# clear ssg host ip-address interface
| Removes or disables a given host or subscriber. |
Router# clear ssg connection | Removes the connections of a given host and a service name. |
Router# debug ssg port-map events
| Displays port mapping event messages. |
Router# debug ssg port-map packets
| Displays port mapping packet contents. |
Examples
In the following examples, the interface Virtual-Access2 is connected to the subscriber:
Router# show ssg port-map status inuse
Bundle-group 70.13.60.2 has the following in-use port-bundles:-
Port-bundle Subscriber Address Interface
64 10.10.3.1 Virtual-Access2
Router# show ssg port-map ip 70.13.60.2 port 64
State = IN-USE
Subscriber Address = 10.10.3.1
Downlink Interface = Virtual-Access2
Port-mappings:-
Subscriber Port: 3271 Mapped Port: 1024
Subscriber Port: 3272 Mapped Port: 1025
Subscriber Port: 3273 Mapped Port: 1026
Subscriber Port: 3274 Mapped Port: 1027
Subscriber Port: 3275 Mapped Port: 1028
|
Note This section applies if you are using SSG with SSD or SESM in RADIUS mode. |
This feature allows you to configure multiple AAA servers. You can configure each remote RADIUS server with timeout and retransmission parameters. SSG will perform failover among the servers in the predefined group.
To configure this feature, use the RADIUS Server attribute (described in Table 4-5) to enter the remote server information into the proxy service profile. SSG automatically creates a AAA server group that contains the remote RADIUS server for this service profile.
| Attribute | Usage |
|---|---|
(Required for proxy services) Specifies the remote RADIUS servers that the SSG uses to authenticate and authorize a service log on for a proxy service type. |
For detailed information on this Service-Info VSA, see the "Service Profiles" section. For general information on configuring RADIUS profiles for SSG, see the "Configuring RADIUS Profiles" section.
To display the AAA server group information, enter the show ssg service privileged EXEC command.
Router# show ssg service serv1-proxy
|
Note This section applies if you are using SSG with SSD or SESM in RADIUS mode. |
Before configuring this feature, see the restrictions for Proxy RADIUS Enhancements.
This feature introduces the Service-Info VSAs described in Table 4-6.
| Attribute | Usage |
|---|---|
Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests. | |
Allows user-defined information to be included in the RADIUS authentication and accounting requests. |
For detailed information on these Service-Info VSAs, see the "Service Profiles" section. For general information on configuring RADIUS profiles for SSG, see the "Configuring RADIUS Profiles" section.
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"
}
}
}
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.
|
Note This section applies if you are using SSG with SSD or SESM in RADIUS or DESS mode. |
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.
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).
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).
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).
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).
This attribute indicates the username provided by the SESM user to log on to the service and for authentication with the home gateway.
Service-Info = "Uusername"username | The name provided by the user for authentication. |
Service-Info = "Ujoe@cisco.com"
|
Note This attribute is only used for accounting purposes and does not appear in profiles. |
This attribute defines the name of the service.
Service-Info = "Nname"name | Name of the service profile or service that belongs to a service group. |
Service-Info = "Nservice1.com"
|
Note This attribute is only used for accounting purposes and does not appear in profiles. |
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"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. |
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
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. |
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"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. |
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
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. |
|
Note This section applies if you are using SSG with SESM in RADIUS mode or with SSD. If you are using SSG with SESM in DESS mode, see the Cisco Distributed Administration Tool Guide for information on creating and maintaining subscriber, service, and policy information in an LDAP directory, including defining a tunnel service profile. |
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 in SSG 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.
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 SESM can send requests to the SSG to log in and log off an account and disconnect and connect services. The vendor ID for all of the Cisco-specific attributes is 9.
| 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. |
The Cisco-AVpair attributes are used in user and service profiles to configure access control lists (ACLs) and Layer 2 Tunnel Protocol (L2TP).
| Attribute | Usage |
|---|---|
Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. | |
Specifies the secret (password) used for L2TP tunnel authentication. | |
Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. | |
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections. | |
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group. |
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"
| Attribute | Usage |
|---|---|
Automatically logs a user into a service when the user logs on to the SSG (reply attribute). | |
Provides a description of the service group. | |
(Optional) The URL for the user's preferred Internet home page. | |
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). | |
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). |
The Service-Info attributes are used to define a service. The following attributes define the parameters for a service.
| Attribute | Usage |
|---|---|
(Optional) Specifies the primary and secondary DNS servers for this service. | |
(Optional) Specifies domain names that get DNS resolution from the DNS server(s) specified in DNS Server Address. | |
Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests. | |
Specifies the PPP MTU size of the SSG as an L2TP access concentrator (LAC). By default, the PPP MTU size is 1500 bytes. Note SESM in DESS mode does not support use of this attribute. | |
(Required for proxy services) Specifies the remote RADIUS server that the SSG uses to authenticate and authorize a service log on for a proxy service type. | |
Allows user-defined information to be included in the RADIUS authentication and accounting requests. | |
(Optional) Provides a description of the service that is displayed to the user. | |
(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. | |
Defines the name of the service. | |
(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. | |
(Required) Specifies networks that exist for the service. There can be multiple instances of this attribute within a single user profile. | |
(Optional) The URL displayed in the SESM HTTP address field when the service opens. | |
Indicates the username provided by the SESM user to log on to the service and for authentication with the home gateway. | |
(Optional) Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough. |
The Control-Info attribute is used to define lists or tables of information.
| Attribute | Usage |
|---|---|
Associates next hop gateway keys with IP addresses. |
RADIUS user profiles contain a password, a list of subscribed services and groups, and access control lists.
Table 4-12 describes attributes that appear in RADIUS user profiles.
| Attribute | Usage |
|---|---|
| Cisco-AVPair Attributes | |
Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. | |
Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. | |
| Account-Info Attributes | |
Automatically logs a user into a service when the user logs on to the SSG (reply attribute). | |
(Optional) The URL for the user's preferred Internet home page. | |
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). | |
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). | |
| Standard Attributes1 | |
Specifies, in seconds, the maximum time a connection can remain idle (reply attribute). | |
Specifies the user's password (check attribute). | |
Specifies, in seconds, the maximum length of the user's session (reply attribute). | |
| 1Standard attributes are described in detail in RFC2138. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
This attribute subscribes the user to a service and automatically logs the user on to the service when the user accesses SESM. 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 "Auto Service". |
This attribute specifies the URL for the user's preferred Internet home page. This attribute is optional.
Account-Info = "Hurl" Syntax Description
url | A fully qualified URL for the user's preferred Internet home page. |
Usage
If the SESM web application is designed to use HTML frames, then this attribute also specifies whether the home page is displayed in a new browser window or in a frame in the current (SESM) window, as follows:
|
Note In a frameless application, both H andU cause a new browser window to open for the home page. The NWSP application is a frameless application. |
Example
Account-Info = "Uhttp://www.BestVideo.com"
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"
|
Note There can be multiple instances of this attribute within a user or service group profile. Use one attribute for each service subgroup. |
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"
|
Note There can be multiple instances of this attribute within a user or service profile. Use one attribute for each service. |
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 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.
Table 4-13 describes attributes that appear in RADIUS service profiles.
| Attribute | Usage |
|---|---|
| Cisco-AVPair Attributes | |
Specifies either an IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. | |
Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. | |
Specifies the secret (password) used for L2TP tunnel authentication. | |
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections. | |
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group. | |
| Service-Info Attributes | |
(Optional) Specifies the primary and/or secondary DNS servers for this service. | |
(Optional) Specifies domain names that get DNS resolution from the DNS server(s) specified in DNS Server Address. | |
Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests. | |
Specifies the PPP MTU size of the SSG as an L2TP access concentrator (LAC). By default, the PPP MTU size is 1500 bytes. Note SESM in DESS mode does not support use of this attribute. | |
(Required for proxy services) Specifies the remote RADIUS servers that the SSG uses to authenticate and authorize a service log on for a proxy service type. | |
Specifies whether the SSG uses the CHAP or PAP protocol to authenticate users for proxy services. | |
Allows user-defined information to be included in the RADIUS authentication and accounting requests. | |
(Optional) Provides a description of the service that is displayed to the user. | |
(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. | |
(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". | |
(Required) Specifies networks that exist for the service. There can be multiple instances of this attribute within a single user profile. | |
(Optional) The URL displayed in the SESM HTTP address field when the service opens. | |
(Optional) Indicates whether the service is proxy (requiring remote authentication) or passthrough (does not require authentication). The default is passthrough. | |
| Standard Attributes1 | |
Specifies, in seconds, the maximum time a service connection can remain idle (reply attribute). | |
Specifies the password (check attribute). | |
Specifies, in seconds, the maximum length of the session (reply attribute). | |
Specifies the level of service (check attribute). Must be "outbound." | |
| 1Standard attributes are described in detail in RFC2138. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
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"
This attribute specifies the IP addresses of the home gateways (LNSes) 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 sends 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 is 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 attempts 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"
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"
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"
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. |
This attribute indicates that the RADIUS authentication and accounting requests use the full username (user@service).
Service-Info = "X"The size of the full username is limited to the smaller of the following values:
Example (RADIUS Freeware Format)
Service-Info = "X"
Example (CiscoSecure ACS for UNIX)
9,251="X"
|
Note SESM in DESS mode does not support use of this attribute. |
This attribute specifies the PPP MTU size of the SSG as a LAC. By default, the PPP MTU size is 1500 bytes.
Service-Info = "Bsize" Syntax Description
size | MTU size in bytes |
Example (RADIUS Freeware Format)
9,251="B1500"
Example (CiscoSecure ACS for UNIX)
9,1="B1500"
This attribute specifies the remote RADIUS servers that the SSG uses 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 and is required.
You can configure each remote RADIUS server with timeout and retransmission parameters. SSG will perform failover among the servers.
Service-Info = "SRadius-server-address;auth-port;acct-port;secret-key[;retrans;timeout;deadtime]" 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. |
retrans | Number of retransmissions. Default is 3. |
timeout | Time in seconds before retransmission. Default is 5. |
deadtime | Time in minutes during which the SSG will not try to perform authentication or accounting with a AAA server that was detected as down. Default is 10. |
Example
Service-Info = "S192.168.1.1;1645;1646;cisco"
This attribute specifies whether the SSG uses the CHAP or PAP protocol to authenticate users for proxy services.
Service-Info = "Aauthen-type" Syntax Description
authen-type C—CHAP Authentication. P—PAP Authentication.
Example
Service-Info = "AC"
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. The size of the user-defined string is limited to the smaller of the following values:
|
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. |
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"
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"
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"
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. |
This attribute specifies the URL that is displayed in the SESM HTTP address field when the service opens. This attribute is optional.
Service-Info = "Hurl" Syntax Description
url | A fully qualified URL that is displayed in the SESM HTTP address field when the service opens. |
Usage
If the SESM web application is designed to use HTML frames, then this attribute also specifies whether the service is displayed in a new browser window or in a frame in the current (SESM) window, as follows:
|
Note In a frameless application, both H and U cause a new browser window to open for the service. The NWSP application is a frameless application. |
Example
Service-Info = "Uhttp://www.BestVideo.com"
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 |
| 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"
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 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.
Table 4-14 describes attributes that can be used in SSG service group profiles.
| Attribute | Usage |
|---|---|
| Account-Info Attributes | |
Provides a description of the service group. | |
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). | |
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. | |
| Standard Attributes1 | |
Specifies the password (check attribute). | |
Specifies the level of service (check attribute). Must be "outbound." | |
| 1Standard attributes are described in detail in RFC2138. |
This attribute provides a description of the service group to the SESM. 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"
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"
|
Note There can be multiple instances of this attribute within a user or service group profile. Use one attribute for each service subgroup. |
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"
|
Note There can be multiple instances of this attribute within a user or service profile. Use one attribute for each service. |
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"
}
}
}
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.
Table 4-15 lists the Cisco AVPair attributes that appear within transparent passthrough filter pseudo-service profiles. The Cisco-AVpair attributes are used to configure ACLs.
| Attribute | Usage |
|---|---|
Downstream Access Control List | 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 | Specifies either an IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
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"
|
Note There can be multiple instances of this attribute within profiles. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
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.
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"
}
}
}
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.
| Attribute | Usage |
|---|---|
Associates next hop gateway keys with IP addresses. |
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. |
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.
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"
}
}
The configuration examples in this section support the network topology shown in Figure 4-2. These examples apply to the SSG used with SSD or SESM in RADIUS mode.
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
ssg default-network 192.168.100.24 255.255.255.255
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
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"
}
}
}
ssg service-search-order local remote
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"
}
}
}
ssg maxservice 10
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
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
main-cpu
auto-sync standard
no secondary console enable
There is nothing in the running configuration for fastswitching when it is enabled.
ssg multicast
ssg accounting interval 600
The following example RADIUS accounting records are 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
ip cef
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
ssg vc-service-map public1 1/37 non-exclusive
Table 4-17 describes the commands that help you monitor and maintain the SSG.
| 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. |
To troubleshoot communication between the RADIUS server and the NRP, enter the debug radius command.
Posted: Tue Feb 26 14:09:52 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.