-
Cisco IOS Service Selection Gateway Configuration Guide, Release 12.4
-
Service Selection Gateway Features Roadmap
-
Overview of SSG
-
Implementing SSG: Initial Tasks
-
Configuring SSG to Serve as a RADIUS Proxy
-
Configuring SSG to Authenticate Web Logon Subscribers
-
Configuring SSG to Authenticate PPP Subscribers
-
Configuring SSG to Authenticate Subscribers with Transparent Autologon
-
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
-
Configuring SSG for On-Demand IP Address Renewal
-
Configuring SSG Support for Subnet-Based Authentication
-
Configuring SSG for MAC-Address-Based Authentication
-
Configuring SSG for Subscriber Services
-
Configuring SSG Subscriber Experience Features
-
Configuring SSG to Log Off Subscribers
-
Configuring Accounting for SSG
-
RADIUS Profiles and Attributes for SSG
-
Feedback
Table Of Contents
Configuring SSG for Subscriber Services
Prerequisites for Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
Open Garden (Unauthenticated) Services
Overview of SSG Open Garden Services
Access Control Lists in Open Garden Services
Hierarchical Policing in Open Garden Services
SSG Uplink Interface Redundancy and Load Balancing
Overview of SSG Interface Redundancy
SSG Uplink Interface Redundancy Topologies
How to Configure Services for Subscribers
Configuring a Local Service Profile Using the Cisco IOS CLI
Configuring SSG Support for Services
Configuring SSG to Support L2TP Dial-In Tunnel Services
Configuring SSG to Serve as a LAC
Configuring RADIUS Profiles for SSG Support of L2TP
Monitoring and Maintaining SSG Support for L2TP Services
Configuring SSG to Support L2TP Dial-Out Services
Prerequisites for SSG L2TP Dial-Out
Restrictions for SSG L2TP Dial-Out
SSG L2TP Dial-Out Service Logon Through SESM
SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG Auto-Domain
SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain
Configuring a Global Dial-Out Service Profile
Configuring the User Service Profile for L2TP Dial-Out Services
Troubleshooting SSG L2TP Dial-Out User Logon Failures
Troubleshooting SSG L2TP Dial-Out Service Login Failures
Configuring SSG Open Garden Services
Configuring SSG Transparent Pass-Through
Verifying SSG Transparent Pass-Through: Example
Monitoring and Maintaining SSG Support for Services
Troubleshooting SSG Support for Services
Configuration Examples for SSG Support for Subscriber Services
Service Profile Configuration: Examples
SSG Support for L2TP Tunnel Services: Examples
SSG Support for L2TP Dial-Out Services: Examples
Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example
Configuring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example
Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example
Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example
Configuring a Global Dial-Out Service Profile: Example
Configuring the Service Profiles for SSG L2TP Dial-Out: Example
Configuring the Service Profile to Send MSISDN Data: Example
Configuring a DNIS Filter: Example
SSG Interface Redundancy: Examples
SSG Open Garden Services: Example
SSG Transparent Pass-Through: Example
Feature Information for SSG Subscriber Services
Configuring SSG for Subscriber Services
First Published: May 2, 2005Last Updated: October 2, 2009
Note
Effective with Cisco IOS Release 15.0(1)M, this feature is not available in Cisco IOS software.
The Cisco Service Selection Gateway (SSG) is deployed at network aggregation points to control subscriber access to network services. SSG can be configured to support authenticated pass-through, proxy, and Layer 2 Tunnel Protocol (L2TP) services, as well as unauthenticated open garden services. This module provides information about how to configure SSG to create services and allow subscribers to use them.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for SSG Subscriber Services" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
Prerequisites for Configuring SSG for Subscriber Services
Before you can perform the tasks in this process, SSG must be enabled.
Service profiles must be configured in the authentication, authorization, and accounting (AAA) server. See the RADIUS Profiles and Attributes for SSG module for information about RADIUS profiles and vendor-specific attributes (VSAs) for SSG.
SSG, Cisco Subscriber Edge Services Manager (SESM), and AAA must be configured correctly in order for subscribers to be able to access services.
Information About SSG Support for Subscriber Services
Before you configure SSG support for services, you should understand the following concepts:
•
•
•
Services and Service Profiles
A service is a type of network access, either access to paid applications or access to free applications. Services are defined by attributes.
A service profile is a collection of attributes that defines a service. Service profiles include information such as the following: type of service (pass-through, proxy, or L2TP), service access mode (sequential or concurrent), Domain Name System (DNS) server IP address for the service, networks that exist in the service domain, access control lists, and timeouts.
Service providers can use attributes to define a wide range of subscriber services, such as a particular level of quality of service, tunneling, personal firewalls and traffic filters, dynamic bandwidth change, free access or paid access, and service selection.
RADIUS service profiles can be configured on the following devices:
•
•
•
SSG and SESM download service profiles from the AAA server or LDAP server as needed.
Authenticated Services
Authenticated services are services that a subscriber can access after providing valid authentication information. There are five types of authenticated services, which are described in the following sections:
Pass-Through Services
SSG does not authenticate users specifically for pass-through services. One example in which a pass-through service may be used is when a Network Access Provider (NAP) provides Internet service. After authenticating the user, the NAP does not require another authentication to provide the user with Internet service.
If the IP address pool name VSA is configured in the service profile for a pass-through service, SSG will choose one IP address from the pool as the service IP address and perform NAT between the user's actual IP address and the IP address of the service.
Proxy Services
Proxy services involve subscriber authentication for the service, such as when a NAP partners with an Internet Service Provider (ISP) to provide Internet service, or with a content provider to provide content. In these cases, the NAP authenticates the user, but before the user can access the service provided by the partner, the partner also authenticates the user (service-level authentication).
When a subscriber requests access to a proxy service, SESM prompts the user for the username and password. SSG then performs the service authentication by sending an Access-Request packet to the remote AAA server configured in the service profile. Upon receiving an Access-Accept packet from the remote RADIUS server, SSG logs the subscriber in to the service. SSG must be configured as a network access server (NAS) client on the remote RADIUS server.
The service IP address can be chosen by one of the following methods (ordered according to priority, the highest first):
1.
2.
3.
SSG supports both Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) authentication for proxy services.
L2TP Dial-In Services
SSG can be used to provide L2TP dial-in services to access corporate networks. In this case, SSG serves as an L2TP access concentrator (LAC) and initiates an L2TP tunnel to the corporate L2TP network server (LNS).
For every user, SSG creates a PPP session through the tunnel to the remote LNS. For the L2TP or PPP session authentication, SESM prompts the user for a username and password. NAT is always performed between subscriber IP address and the LNS-assigned IP address.
Note
For more information about SSG support for L2TP tunnel services, see the "What to Do Next" section.
L2TP Dial-Out Services
SSG L2TP dial-out services provide mobile users with a way to securely connect to their small office/home office (SOHO) corporate networks through the public switched telephone network (PSTN). In this case, SSG serves as an LNS that creates a dial-out tunnel to the LAC, which in turn dials into the corporate gateway.
To provide L2TP dial-out services, SSG requires a digital number identification service (DNIS) number for the dial-up corporate gateway to which the user wants to connect, the address of the LAC closest to the SOHO, and configured tunnel parameters to establish a tunnel to the LAC.
For more details about SSG support for L2TP dial-out services, see the "Configuring SSG to Support L2TP Dial-Out Services" section.
DNS Packet Handling
When SSG receives DNS requests, the DNS packets are first processed for the user connection. If the domain match is not found, the packets are processed for open gardens.
In the upstream direction, SSG handles DNS packets by first looking up the domain in the connected-service list. If a match is not found in the connected-service list, the open garden service list is checked. If the domain is not found in the open garden service list and the user has a connected Internet service (0.0.0.0/0), the DNS request is forwarded to that domain. If the user is not connected to an Internet service and there is an open garden Internet service, the DNS request is forwarded to the open garden Internet domain.
In the downstream direction, SSG handles DNS response packets in the same order in which they are handled in the upstream direction.
Note
If SSG receives a packet that is not destined for the open garden, SSG checks the source IP address of the packet to see if the subscriber is authenticated. If SSG recognizes the IP address, the subscriber is authenticated and SSG forwards the packet. If the subscriber is not authenticated and the packet is not a DNS packet, SSG drops the packet.
How SSG Routes to Services
By default, packets going from a user to a service are not routed by SSG using the global IP routing table. In order for SSG to route packets destined for services, all services (except L2TP tunnel services) must be bound to either an interface or a next hop.
When a service is bound to a next hop, SSG sends all traffic destined to the service to the next hop. This functionality is similar to setting the next hop using Policy Based Routing (PBR). For example, in an equal access network (EAN) environment in which multiple ISPs are providing Internet connectivity, SSG will send traffic to the gateway (next hop) of the appropriate ISP.
When a service is bound to a point-to-point interface, SSG sends the traffic on that interface. If a service is bound to an interface that is not point-to-point (such as Ethernet), SSG will use the global routing table to send the packets.
Note
For L2TP dial-in or dial-out tunnel services, virtual-access interfaces are created dynamically on the service side for each user. SSG automatically determines the binding when the virtual-access interface is created.
SSG allows next-hop bindings to be configured in a next-hop table on the AAA server. The next-hop table is downloaded by SSG upon startup. The next-hop table uses the Next-Hop Gateway attribute to specify the next-hop key for a service. Each SSG uses its own next-hop gateway table, which associates the next-hop key with an actual IP address.
Open Garden (Unauthenticated) Services
The following sections provide information about SSG open garden services:
•
•
•
Overview of SSG Open Garden Services
An open garden is a collection of Web sites or networks that unauthenticated subscribers can access. Subscribers do not have to provide authentication information before accessing an open garden service. In contrast, walled garden refers to a collection of Web sites or networks that subscribers can access after providing minimal authentication information. Figure 1 shows a network topology that includes open gardens.
Figure 1 Open Garden Network Topology
Open Garden Service Binding
Whereas SSG-authenticated services must be bound to an interface or next hop, it is not necessary to bind open garden services that are reachable via the global-ip routing table. Service binding becomes mandatory for open garden services that are routed via a next hop.
Access Control Lists in Open Garden Services
SSG supports upstream and downstream access control lists (ACLs) in open garden service profiles. Packets that match the open garden service are matched against the access control lists before being forwarded. If a packet is allowed by the access control list, the packet is routed to the open garden service. If the packet is denied by the access control list, the packet is processed by the rest of the configured SSG features (such as TCP redirect or transparent autologon) before being dropped. The ACLs are configured as the Cisco vendor-specific attributes (VSAs).
Hierarchical Policing in Open Garden Services
SSG supports hierarchical policing attributes in open garden service profiles. When an open garden service policy is configured for hierarchical policing, SSG polices all traffic going to and from the open garden service.
Note
SSG Uplink Interface Redundancy and Load Balancing
This section contains the following concepts:
•
•
Overview of SSG Interface Redundancy
In SSG, each service is associated with an uplink interface: either the service is bound to a next hop, which is routable through an interface, or the service is bound directly to the interface.
Before Cisco IOS Release 12.3(8)T, SSG had the limitation of only being able to bind a service to one uplink interface, even if the next hop through which the service was bound was reachable via multiple interfaces. In Cisco IOS Release 12.3(8)T, SSG interface redundancy was introduced. SSG interface redundancy allows services to be associated with more than one next hop or interface to protect against link failures. When a service is bound to multiple interfaces, these interfaces can be grouped into an interface group.
If a service is configured for multiple uplink interfaces, downstream traffic is allowed on all of the interfaces for any service bound to even one of those interfaces.
If a host has a connection that uses NAT to one of the services on a set of redundant uplink interfaces, all traffic from a user to any of the uplink interfaces uses NAT. This is because NAT will be applied for the user on all the uplink interfaces in the uplink-interface group.
This feature is supported on all interfaces that support SSG, including subinterfaces and VLAN interfaces.
Failover
When redundant bindings are configured for a service, the order in which SSG selects these bindings to be used to reach a service depends on the distance metric that is assigned to the service binding. The interface for the service binding with the lowest weight is the primary interface. The interface for the service binding with the second-lowest weight is the secondary interface, and so on.
If a failure occurs on an active interface, SSG recognizes the failure and switches the service connection to the interface associated with the next-lowest weight. When the primary uplink interface or next hop becomes available again, SSG switches back to using the primary interface.
SSG interface redundancy can be configured for services, including open garden and walled garden services, and the default network.
Load Balancing
If the same distance metric is assigned to multiple service bindings, SSG will perform load-balancing across those bindings. If one of the bindings fails, SSG will move the traffic to the rest of the working bindings. If the binding that failed comes back up again, the traffic is automatically shared among all the active bindings.
Load-balancing with the same distance metric to multiple bindings and failover with different distance metrics can be configured together for the same service.
Configuration Information
SSG uplink interface redundancy is configured by binding a service to more than one next hop or interface and grouping the redundant interfaces to ensure that SSG treats them similarly. To bind services to interfaces or next hops, see the "DETAILED STEPS" section. To group redundant uplink interfaces, see the "Establishing Initial SSG Communication" feature.
SSG Uplink Interface Redundancy Topologies
The SSG Interface Redundancy feature supports uplink interface redundancy in the following network topologies:
•
•
•
•
Multiple Next Hops per Service
Figure 2 shows an example of SSG interface redundancy configured to support multiple next-hop IP addresses per service. In this type of topology, each next hop is routable on a different uplink interface. SSG forwards traffic to the appropriate next hop on the basis of the distance metric assigned to it.
Figure 2 Multiple Next Hops per Service: Sample Topology
Multiple Uplink Interfaces with a Single Next Hop
Figure 3 shows an example of SSG interface redundancy configured to support multiple uplink interfaces that share a single next hop. In this type of topology, routing to the service is governed by the active route to the next-hop IP address in the IP routing table.
Figure 3 Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
Multiple Uplink Interfaces with No Next Hop
Figure 4 shows an example of SSG interface redundancy configured to support multiple uplink interfaces that are directly connected to the service. These uplink interfaces could also be tunnel interfaces.
Figure 4 Multiple Uplink Interfaces with No Next Hop: Sample Topology
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops
Figure 5 shows an example of SSG interface redundancy configured to support an uplink interface that is directly connected to the service and an uplink interfaces with a next hop.
Figure 5 Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops: Sample Topology
DNS Packet Handling
When SSG receives DNS requests, the DNS packets are first processed for the user connection. If the domain match is not found, the packets are processed for open gardens.
In the upstream direction, SSG handles DNS packets by first looking up the domain in the connected-service list. If a match is not found in the connected-service list, the open garden service list is checked. If the domain is not found in the open garden service list and the user has a connected Internet service (0.0.0.0/0), the DNS request is forwarded to that domain. If the user is not connected to an Internet service and there is an open garden Internet service, the DNS request is forwarded to the open garden Internet domain.
In the downstream direction, SSG handles DNS response packets in the same order in which they are handled in the upstream direction.
Note
If SSG receives a packet that is not destined for the open garden, SSG checks the source IP address of the packet to see if the subscriber is authenticated. If SSG recognizes the IP address, the subscriber is authenticated and SSG forwards the packet. If the subscriber is not authenticated and the packet is not a DNS packet, SSG drops the packet.
SSG Transparent Pass-Through
When enabled, transparent pass-through allows unauthenticated subscriber traffic to be routed through SSG in either direction. These are some of the benefits of SSG transparent pass-through:
•
•
•
Filters can be configured to control transparent pass-through traffic. These filters can be configured locally on the router or on the AAA server in a transparent pass-through filter pseudo-service profile. For information about transparent pass-through filter pseudo-service profiles, see the RADIUS Profiles and Attributes for SSG feature.
Service Profile Caching
The Service Profile Cache feature enables SSG to use a cached copy of a service profile instead of downloading the profile from a RADIUS server every time a user logs on to the service.
SSG caches the service profile whenever the first user logs on to the service and uses this cached profile when another user attempts to log on to the same service.
The following sequence describes how service profiles are cached:
•
•
•
•
SSG runs a timer for refreshing the service profiles from the RADIUS server. When the profile changes on the RADIUS server, the SSG timer process periodically updates the cached profile to ensure that the service information is current.
If the service profile fails to update, SSG retains the cached service profile. When a new user connects to the SSG, SSG downloads the service profile again. If SSG cannot download the service profile, the user is not allowed to log on to the service.
Service profile caching is enabled by default.
How to Configure Services for Subscribers
This section contains the following tasks:
•
•
•
•
•
•
•
Configuring a Local Service Profile Using the Cisco IOS CLI
Service profiles are most commonly configured on the remote AAA server and downloaded by the router as needed. For information about RADIUS profiles and VSAs for SSG, see the RADIUS Profiles and Attributes for SSG module.
You can also configure service profiles directly on the router by using the Cisco IOS command line interface. Perform this task to configure a local service profile.
Note
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
local-profile service-name
Example:Router(config)# local-profile service1
Configures a local RADIUS service profile and enters profile configuration mode.
Step 2
attribute radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value
Example:Router(config-prof)# attribute 26 9 251 "Owww.opengarden.com"
Configures an attribute in a local RADIUS service profile.
•
•
Step 3
Repeat Step 2 for each attribute that you want to add to the service profile.
Configuring SSG Support for Services
Perform this task to configure SSG support for authenticated services (pass-through, proxy, and L2TP services).
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
What to Do Next
If you are configuring L2TP services, you must also perform the tasks in the "Configuring SSG to Support L2TP Dial-In Tunnel Services".
Configuring SSG to Support L2TP Dial-In Tunnel Services
SSG can be configured to support L2TP dial-in services with configured with L2TP dial-in IOS configurations.
To configure SSG to support L2TP, perform the tasks in the following sections:
•
•
To verify SSG support for L2TP dial-in tunnel services, perform the task in the following section:
•
Configuring SSG to Serve as a LAC
Perform this task to configure SSG to serve as an LAC.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuring a VPDN Group
Perform this task to configure SSG to support virtual private dialup network (VPDN) group names in the SSG tunnel service profile.
SUMMARY STEPS
1.
DETAILED STEPS
Step 1
vpdn-group name
Example:Router(config)# vpdn-group mytunnel
Associates an SSG service profile to the specified VPDN group name.
Configuring RADIUS Profiles for SSG Support of L2TP
To configure support of L2TP, you must add the following vendor-specific attributes to the service profiles:
Cisco AVpair VPDN Attributes
Cisco AVpair VPDN attributes can be configured in either of two ways:
•
•
Table 1 lists the Cisco AVpair attributes used in the service profile to configure VPDN.
Service-Info VPDN Attributes
Table 2 lists the Service-Info attributes used in the service profile to define the L2TP service parameters.
Configuring the LNS
To configure the L2TP network server (LNS) to accept L2TP dial-in tunnels from SSG, perform the steps in this section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
DETAILED STEPS
Monitoring and Maintaining SSG Support for L2TP Services
Perform this task to monitor and maintain SSG support of L2TP tunnel services.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring SSG to Support L2TP Dial-Out Services
SSG dial-out service provides mobile users with a way to connect securely to their SOHOs through the PSTN.
•
•
Before you configure SSG support for L2TP dial-out service, you should understand the following concepts:
•
•
•
•
Perform the following tasks to configure SSG support for L2TP dial-out services:
•
•
•
•
Prerequisites for SSG L2TP Dial-Out
Before configuring SSG for L2TP dial-out service, you must first perform the tasks in the "Configuring SSG to Support L2TP Dial-In Tunnel Services" section.
Restrictions for SSG L2TP Dial-Out
SSG L2TP Dial-Out does not support the following functionality:
•
•
•
Overview of SSG L2TP Dial-Out
The SSG L2TP Dial-Out feature provides mobile users with a way to securely connect to their SOHOs through the PSTN.
To provide SSG L2TP dial-out functionality, SSG requires a digital number identification service (DNIS) number for the SOHO to which the user wants to connect, the address of the L2TP Access Concentrator (LAC) closest to the SOHO, and configured tunnel parameters to establish a tunnel to the LAC.
Users can access SSG L2TP dial-out service by selecting it using Cisco SESM from the list of subscribed services, or by using a structured username during user login (such as for RADIUS-proxy users). The user must provide the DNIS number when using either method of connecting to the dial-out service.
Figure 6 SSG L2TP Dial-Out Network
SSG L2TP Dial-Out Service Logon Through SESM
A user can access SSG L2TP dial-out functionality by selecting the dial-out tunnel service on the SESM.
After a user selects the dial-out service, the SESM displays a page for the entry of the user's name and password. SSG then downloads the service profile for the dial-out service.
When a user attempts to log on to a dial-out service, the username entered into the SESM must have a numerical realm that is a DNIS prefix; for example, abc@091805318090. If the DNIS prefix that the user enters is found on the DNIS exclusion list, the logon is rejected. If the entered DNIS prefix is valid, a tunnel session to the LAC is established, and SSG starts PPP negotiations with the SOHO. The user is then authenticated at the SOHO.
If you configure the X attribute in the service profile, the full username (abc@091805318090) is sent for authentication. Otherwise, only the username (abc) is authenticated.
Upon successful authentication, the SOHO assigns an IP address to the user, and Network Address Translation (NAT) for the assigned IP address is performed in SSG.
Figure 7 SSG L2TP Dial-Out Service Logon Through SESM
SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG Auto-Domain
When a user attempts an account logon with a structured username and the SSG Auto-domain feature is not enabled, the entered username is sent to a local authentication, authorization, and accounting (AAA) server for user authentication. If the username entered is a structured username, SSG does not interpret the full username as user and domain. If the username is entered as user@DNIS, the full username is used for user authentication.
If a user has a dial-out tunnel service configured as an autologon service and does not specify a username and password along with the service name in the user profile, the username and password entered for account logon are used. If the username and password are given with the service name in the user profile, then that username and password are used. The username entered in either case must be user@DNIS. The DNIS portion of the username is used as the dial string to dial from the LAC to the SOHO.
SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain
When the SSG Auto-domain feature is enabled, a full username must be entered by the user at the account logon page if the user wants to perform service selection by using the DNIS number. SSG interprets the full username as username and domain. For user@DNIS, user is the username and DNIS is the domain. This DNIS domain must be a numerical value; for example, user@3962962.
You can select the dial-out global service that is available to a user who performs an account logon with a structured username (user@DNIS) by configuring the dnis-prefix all service command.
SSG Auto-domain can be configured to work in basic or extended mode. In basic mode, the SSG Auto-domain profile downloaded from the AAA server is a service profile. In extended SSG Auto-domain mode, the SSG Auto-domain profile downloaded from the AAA server is a virtual-user profile. In the virtual-user profile, the dial-out service is configured as the primary autologon service.
When SSG Auto-domain is configured, SSG parses the structured username. If the domain part of the username is a DNIS prefix, the SSG Auto-domain profile is downloaded. If the SSG Auto-domain profile has not been configured or the DNIS prefix is included in the DNIS exclusion list, the account logon is rejected.
If the account logon is successful and the configured service is a dial-out service, SSG establishes a tunnel session with the LAC. The IP address of the LAC must be configured in the global service profile. SSG uses the DNIS number that was entered as part of the username as the dial string to dial out to the SOHO from the LAC. When the PPP session begins successfully, the user is authenticated at the SOHO. If the X attribute is configured in the SSG Auto-domain profile, the full username is sent for authentication.
SSG performs Network Address Translation (NAT) for the user's IP address for a tunnel by default. If you enter the no nat user-address command when SSG Auto-domain is configured, SSG does not perform NAT on the user's IP address. Rather, the IP address assigned by the SOHO is assigned to the user. This configuration is valid only for RADIUS-proxy users where the AAA server (in this case, SSG) is assigning the IP address to the user.
Configuring a Global Dial-Out Service Profile
Perform this task to configure a global dial-out service profile.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuring the User Service Profile for L2TP Dial-Out Services
When you configure the service profile for a dial-out tunnel service, configure the same parameters that are used for dial-in tunnel service, along with the additional Cisco attribute value (AV) pair vpdn:dout-type=2 in the user profile. The 2 represents the L2TP protocol. Only the L2TP protocol is supported for dial-out tunnels.
To configure SSG to send the mobile station integrated services digital network (MSISDN) number along with the DNIS number to the LAC and the SOHO, the service profile must contain the Y attribute. By default, only the DNIS number is sent when the dial-out tunnel is being established. When the MSISDN/DNSI VSA (Y-attribute) is present in the service, the dial string that is passed to the LAC takes the following format:
DNIS-number_delimiter MSISDN-number
The delimiter is a configurable character. It can be any regular expression character (A, B, C, D, 0-9, #, *, \ , $, . , ^) that is not in the DNIS or in the MSISDN number. If you do not specify a delimiter, the @ character is the default delimiter.
If there is no MSISDN for the subscriber, only the DNIS number is sent as the dial string.
Configuring a DNIS Filter
DNIS Filters
To block PSTN calls to unwanted DNIS numbers, such as free phone or international numbers, you can configure a DNIS filter. DNIS filters can be locally configured through the command line interface (CLI) or received from a AAA profile.
Perform this task to configure a DNIS filter locally on the router.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Monitoring SSG L2TP Dial-Out
Perform this task to monitor the SSG L2TP Dial-Out feature.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Troubleshooting SSG L2TP Dial-Out User Logon Failures
Perform this task to troubleshoot L2TP dial-out user logon failures.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
Enter the debug ssg ctrl-events command to display event messages for the control modules, including all modules that manage user authentication and service logon and logoff.
Router# debug ssg ctrl-eventsSSG-CTL-EVN: AAA Response is bad...SSG-CTL-EVN: Failed to get user info. user=dt-user90, pwd=*****If either of the two outputs above is displayed, the user profile does not exist, the password is incorrect in AAA, or the AAA is not configured. Enable AAA by entering the aaa new-model command.
Step 2
Enter the debug ssg radius command to display messages about the communication between the AAA server and the router.
Router# debug ssg radiusRADIUS: No radius servers defined!The output above is displayed if the RADIUS server is not configured or is not reachable. Configure the RADIUS server by entering the radius-server host command.
If the debug ssg radius command displays the following output, there is a RADIUS server key mismatch:
RADIUS: Response (159) failed decryptConfigure the correct key by entering the radius-server key ssg command.
Step 3
Enter the debug ssg ctrl-err command to display error messages for the control modules, including all modules that manage user authentication and service logon and logoff.
Router# debug ssg ctrl-errSSG-CTL-ERR: Unable to find SSG sub-block from ATM3/0.1The output above indicates that the ATM3/0.1 interface, where the user is coming from, is not configured as a downlink interface. SSG requires that all the interfaces to the subscribers be bound as downlink interfaces. Enter the ssg direction downlink command in interface configuration mode to configure the interface as downlink.
Troubleshooting SSG L2TP Dial-Out Service Login Failures
Perform this task to troubleshoot L2TP dial-out service login failures.
Step 1
Enter the debug ssg ctrl-events command.
Router# debug ssg ctrl-eventsSSG-CTL-EVN: Invalid DNIS number for dialout tunnel serviceThe output above indicates that an invalid DNIS number has been configured. The DNIS number should be configured according to the E.165 standard. Valid DNIS numbers can contain the following characters: A, B, C, D, 0-9, #, *, and ".", and they can start with + and end with T.
Any issues on the LAC or SOHO side will cause the following outputs in the debug ssg ctrl-events command:
SSG-VPDN-CTL-EVN: VPDN module failed to establish tunnelor
SSG-VPDN-CTL-EVN: Failed to establish call..informing SSGFollow the steps below to troubleshoot this problem:
a.
b.
Common problems are tunnel ID mismatch and destination IP not reachable.
c.
•
•
d.
For Dialer interface configuration problems, cut and paste the configuration given in the "Configuration Examples for SSG Support for Subscriber Services" again and look for any command rejections. Most problems will have to do with ISDN (Layer 2).
Common problems found in the PPP debug messages are authentication failed and IPCP negotiation failed.
Configuring SSG Open Garden Services
Perform this task to configure a service as an open garden service.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
local-profile profile-name
Example:Router(config)# local-profile myprofile
Creates a local service profile and enters profile configuration mode.
Note
Step 2
attribute 26 9 251 "Rip-address;subnet-mask"
Example:Router(config-prof)# attribute 26 9 251 "R10.10.1.1;255.255.0.0"
(Service Route attribute) Specifies the network available to the service.
•
•
Step 3
attribute 26 9 251 "Dip-address"
Example:Router(config-prof)# attribute 26 9 251 "D10.10.2.2"
(DNS Server Address attribute) Specifies the DNS server for the service.
•
Step 4
attribute 26 9 251 "domain-name"
Example:Router(config-prof)# attribute 26 9 251 "SSG1"
(Domain Name attribute) Specifies the domain name that gets DNS resolution from the DNS server specified in Step 3.
•
Step 5
exit
Example:Router(config-prof)# exit
Returns to global configuration mode.
Step 6
ssg open-garden profile-name
Example:Router(config)# ssg open-garden profile-name
Designates the service as an open garden service.
Step 7
ssg bind service service {ip-address | interface-type interface-number}
Example:Router(config)# ssg bind service og2 10.5.5.1
Specifies the bindings for the service.
Note
Configuring SSG Transparent Pass-Through
Transparent pass-through allows unauthenticated traffic to pass through SSG in either direction without SSG processing. Filters can be configured to control transparent pass-through traffic. These filters can be configured locally on the router or on the AAA server in a transparent pass-through filter pseudo-service profile. For information about configuring transparent pass-through filter pseudo-service profiles on the AAA server, see the Configuring SSG to Serve as a RADIUS Proxy module.
Perform this task to configure transparent pass-through.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying SSG Transparent Pass-Through: Example
The following example shows how to verify SSG transparent pass-through by using the show ssg pass-through-filter command.
Router# show ssg pass-through-filterService name: filter01Password: ciscoDirection: UplinkExtended IP access list (SSG ACL)permit tcp 172.16.6.0 0.0.0.255 any eq telnetpermit tcp 172.16.6.0 0.0.0.255 192.168.250.0 0.0.0.255 eq ftpMonitoring and Maintaining SSG Support for Services
Perform this task to monitor and maintain SSG support for services.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Troubleshooting SSG Support for Services
Perform this task to troubleshoot SSG support for services.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuration Examples for SSG Support for Subscriber Services
This section contains the following examples:
•
•
•
•
•
•
Service Profile Configuration: Examples
Service Profile Configured on the AAA Server: Example
The following is an example of a service profile configured on the AAA server. 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"Service Profile Configured Locally on the Router: Example
The following example shows the configuration of a service profile locally on the router. This service profile is configured to support an L2TP service.
ssg enable!local-profile l2tpnet1attribute 26 9 251 "R0.0.0.0;0.0.0.0;I"attribute 26 9 251 "TT"attribute 26 9 1 "vpdn:l2tp-tunnel-password=cisco"attribute 26 9 1 "vpdn:ip-addresses=171.69.255.246"attribute 26 9 1 "vpdn:tunnel-id=LAC18"!SSG Support for L2TP Tunnel Services: Examples
The following examples show how to configure SSG for L2TP services:
•
LAC Configuration: Example
The following example shows how to configure the LAC:
vpdn enable! "ip nat inside" command should be enabled on the downlink interface.!interface eth1/0ip address 10.1.1.1 255.255.255.0ip nat inside}RADIUS Service Profile: Example
The following example shows a basic RADIUS service profile for SSG support of L2TP:
reply_attributes= {9,251="R10.6.6.0;255.255.255.0"9,251="ODomain.com"9,251="D10.7.7.7;10.7.7.8"9,251="ITunnel1"9,251="TT"9,251="B1450"9,1="vpdn:ip-addresses=10.8.8.8"9,1="vpdn:tunnel-id=My-Tunnel"9,1="vpdn:l2tp-tunnel-password=cisco"LNS Configuration: Example
The following example shows a basic LNS configuration:
username l2tp_user password 0 ciscovpdn-group 1accept-dialinprotocol l2tpvirtual-template 1terminate-from hostname My-Tunnell2tp tunnel password 7 02050D480809!ip local pool pool2 10.8.8.1 10.8.8.127interface Virtual-Template1ip unnumbered FastEthernet0/0no ip directed-broadcastpeer default ip address pool pool2ppp authentication pap chapSSG Support for L2TP Dial-Out Services: Examples
This section contains the following examples:
•
•
•
•
•
•
•
•
Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example
The following example shows the minimum configurations needed for an SSG L2TP Dial-Out solution with the auto-domain feature disabled. Figure 8 illustrates a sample SSG L2TP Dial-Out network.
Figure 8 Sample SSG L2TP Dial-Out Network
In this configuration, the SSG user can access the SOHO in two ways, with an account logon and then a service logon or with an account logon with service configured as an autologon service.
User Profile Configurations: Examples
Use the following profile configuration when the SSG user accesses the SOHO with an account logon and then a service logon:
user=abc {radius=6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,250-"Nsoho0"}}}Use the following profile configuration when the SSG user accesses the SOHO with an account logon with service configured as an autologon service:
user=abc {radius-6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,250-"Asoho0;user@DNIS;cisco"}}}Service Profile Configuration: Example
The following example shows how to configure the service profile:
user=soho0 {radius=6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,251= "TT"9,251="R172.0.0.1:255.0.0.0" ! This is the service network.9,1="vpdn:ip-address=66.102.0.1"9,1="vpdn:l2tp-tunnel-password=lab:9,1=-"vpdn:tunnel-type=l2tp"9,1="vpdn:tunnel-id=lns_l2x0"9,1="vpdn:dout-type=2"SSG Configuration: Example
SSG configuration includes enabling VPDN and configuring NAT on the downlink interface. The following example shows how to perform the minimum complete configuration of SSG:
hostname SSGaaa new-modelaaa authentication ppp default group radius!ip cef! enable vpdn for l2tp dialoutvpdn enable!ssg enablessg default-network 10.1.1.1 255.255.255.255ssg service-password ciscossg radius-helper auth-port 1645 acct-port 1646ssg radius-helper key ciscossg bind direction downlink ATM3/0.1!interface ATM1/0.1 point-to-point ! For an IP user.ip address 172.16.0.0 255.0.0.0! enable NAT on the downlink interfaceip nat insidepvc 0/33!interface ATM3/0.10 point-to-point ! For a PPP user.pvc 0/100encapsulation aal5mux ppp Virtual-Template1!interface Virtual-Template1ip unnumbered Ethernet2/2peer default ip address pool ppp_pool_1ppp authentication papip nat inside!ip local pool ppp_pool_1 10.0.0.1 10.0.0.255!radius-server host 10.2.36.253 auth-port 1645 acct-port 1646 timeout 5radius-server retransmit 3radius-server key ssgLAC Configuration: Example
hostname LAC!enable VPDNvpdn enable! enable to accept dialout tunnelvpdn-group 1accept-dialoutprotocol l2tpdialer 0 ! Matches rotary group and the dialer interface.terminate-from hostname lns_l2x0l2tp tunnel password 7 abcdef!idsn switch-type primary-5ess!interface Dialer0 ! All users coming to VPDN-group 0 are handled by this interface.no ip addressencapsulation pppdialer in-banddialer aaappp authentication pap!dialer-list 1 protocol ip permitSOHO Configuration: Example
hostname soho0username john password 0 cisco!controller T1 1/0framing esflinecode b8zspri-group timeslots 1-24!interface Serial1/0:23no ip addressencapsulation pppdialer rotary-group 0 ! This matches the interface Dialer0.isdn switch-type primary-5essno peer default ip addressno cdp enable!interface Dialer0ip unnumbered Loopback2encapsulation pppdialer-group 1peer default ip address pool soho_1no cdp enableppp authentication chap!ip local pool soho_1 10.0.0.20 10.0.0.40dialer-list 1 protocol ip permitConfiguring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example
The following example shows the minimum configurations needed for an SSG L2TP Dial-Out solution for an SSG with auto-domain enabled, one LAC and one SOHO.
In this configuration, the SSG user is assumed to access the SOHO with an account login and then a service login with user@dnis as the username. In this solution, services are selected on the basis of auto-domain configuration (basic or extended mode) and the global service configured for the SSG dial-out.
User Profile Configuration: Example
Use the following profile configuration when the SSG user accesses the SOHO with an account logon with user@dnis as the username:
user=soho1{radius=6510-SSG-v1.1{check_items= {2=cisco}reply_attributes={9,250="Asoho0"9,250-"Npassthru1"}}}SSG Configuration: Example
...!ssg dial-outdnis-prefix all service soho1 ! This indicates SSG Autodomain in extended mode.or
dnis-prefix all service soho0 ! This indicates SSG Autodomain in basic mode....LAC and SOHO Configurations
The LAC and SOHO configurations for SSG with SSG Auto-domain configured are the same as the configuration for SSG without SSG Auto-domain configured. See the "Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example" section for more details.
Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example
The following example shows how to configure user-specific configurations on the SOHO. The user profile, service profile, SSG, and LAC configurations are the same as in the "Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example" section.
hostname soho0username user1 password 0 ciscousername user1@4444007 password 0 ciscousername user7 password cisco!controller t1 1/0framing esflinecode b8zspri-group timeslots 1-24!interface serial1/1:23no ip addressencapsulation pppdialer pool-member 1isdn switch-type primary-5essno peer default ip addressno cdp enableppp authentication chap!interface Dialer1 ! Configures a special service policy and pool for user "user1."ip unnumbered loopback1encapsulation pppdialer pool 1dialer remote-name johndialer idle-timeout 2147483dialer string 3456048dialer-group 1service-policy output SETDSCPpeer default ip address pool soho_1!interface Dialer2 ! Configures a special service policy and pool for user "user7."ip unnumbered loopback1encapsulation pppdialer pool 1dialer remote-name garydialer idle-timeout 2147483dialer-group 1peer default ip address pool soho_OLAPPpulse-time 0ppp authentication chap!ip local pool soho_1 10.0.0.20 10.0.0.40ip local pool soho_OLAP 11.0.0.10Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example
The following example shows how to configure an SSG L2TP Dial-Out solution with multiple LACs and multiple SOHOs. Figure 9 shows a sample large-scale SSG L2TP Dial-Out network.
Figure 9 Sample Large-Scale SSG L2TP Dial-Out Network
User Profile Configuration: Example
The user profile configuration is the same as that shown in the "Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example" section.
Service Profile Configuration: Example
SSG selects the LAC to which it will create a tunnel by looking at the service profile. In the following example, the IP addresses configured in the LAC interfaces to SSG are
•
•
user = soho10{radius=6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,251="TT"9,251="R170.0.0.1;255.0.0.0"9,1="vpdn:ip-addresses=192.0.2.0" ! IP address of LAC10.9,1="vpdn:l2tp-tunnel-password=lab"9,1="vpdn:tunnel-type=l2tp"9,1="vpdn:tunnel-id=lns_l2x0"9,1="vpdn:dout-type=2"}}}user = soho11{radius=6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,251="TT"9,251="R170.0.0.1;255.0.0.0"9,1="vpdn:ip-addresses=192.1.2.0" ! IP address of LAC11.9,1="vpdn:l2tp-tunnel-password=lab"9,1="vpdn:tunnel-type=l2tp"9,1="vpdn:tunnel-id=lns_l2x0"9,1="vpdn:dout-type=2"}}}SSG Configuration: Example
The SSG Configuration for a large-scale SSG L2TP Dial-Out solution is the same as that in the "Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example" section.
LAC Configuration: Example
The following example shows a sample configuration for LAC10:
hostname LAC10vpdn enable!vpdn-group 1accept-dialoutprotocol l2tpdialer 0 ! This configuration matches with rotory-group and dialer interfaces.terminate-from hostname ForSoho10 ! This tunnel ID "ForSoho10" will be terminated.l2tp tunnel password 7 060A0E23!vpdn-group 1accept-dialoutprotocol l2tpdialer 1 ! To match with rotary-group and dialer interfaces.terminate-from hostname ForSoho20 ! This tunnel ID "ForSoho20" will be terminated.l2tp tunnel password 7 060A0E23!isdn switch-type primary-5ess!controller T1 4/0framing esflinecode b8zspri-group timeslots 1-24!interface ATM2/0.1 point-to-pointip address 100.0.0.2 255.0.0.0pvc 0/100!interface Serial4/0:23no ip addressencapsulation pppdialer rotary-group 0dialer-group 1isdn switch-type primary-5ess!interface Dialer0no ip addressencapsulation pppdialer in-banddialer aaappp authentication pap!interface Serial4/1:23no ip addressencapsulation pppdialer rotary-group 1dialer-group 1isdn switch-type primary-5ess!interface Dialer1no ip addressencapsulation pppdialer in-banddialer aaappp authentication pap!dialer-list 1 protocol ip permitSOHO Configuration: Example
The SOHO configuration for a large-scale SSG L2TP dial-out solution is the same that as shown in the "Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example" section.
Configuring a Global Dial-Out Service Profile: Example
The following example shows how to configure a global dial-out service profile called "dialout_1":
ssg dial-outdnis-prefix all service dialout_1Configuring the Service Profiles for SSG L2TP Dial-Out: Example
The following is an example of a service profile when SSG Auto-domain is configured in basic mode:
user = dialout_tunnel1{member = SSG-DEVradius = 6510-SSG-v1.1 {check_items= {2 = cisco}reply_attributes= {9,251 = "TT"9,251 = "R172.16.0.0;255.255.0.0;I"9,1 = "vpdn:ip-addresses=10.0.0.1"9,1 = "vpdn:l2tp-tunnel-password=cisco"9,1 = "vpdn:tunnel-type = l2tp"9,1 = "vpdn:tunnel-id = ssg1"9,1 = "vpdn:dout-type=2"Configuring the Service Profile to Send MSISDN Data: Example
The following example shows how to configure a service profile with the SSG service-info VSA to send the MSISDN number along with the DNIS number while establishing the dial-out tunnel.
The attribute 9,251="Y" sends the MSISDN number with the DNIS number. The character "#" (pound sign) is the delimiter between the DNIS number and the MSISDN number.
user = dialout_tunnel{member=SSG-DEVradius=6510-SSG-v1.1{check_items= {2=cisco}reply_attributes= {9,251="TT"9,251="R172.16.0.0;255.255.0.0;I"9,1="vpdn:ip-addresses=10.0.0.0"9,1="vpdn:l2tp-tunnel-password=cisco"9,1="vpdn:tunnel-type=l2tp"9,1="vpdn:tunnel-id=ssg1"9,1="vpdn:dout-type:2"9,251="Y#" ! MSISDN/DNIS attributeConfiguring a DNIS Filter: Example
The following example shows how to configure a DNIS exclude profile in AAA:
user = exclude_dnis_aaa{member = SSG-DEVradius=6510-SSG-v1.1 {check_items= {2=cisco}reply_attributes= {9,253="XD+444"9,253="XD22222T"}}}The following example shows how to add two DNIS prefixes to the exclude profile and to download a DNIS exclude profile named exclude_dnis_aaa with a password of cisco:
ssg dial-outexclude dnis-prefix 18085288110exclude dnis-prefix 18085288111download exclude-profile exclude_dnis_aaa ciscoSSG Interface Redundancy: Examples
Service Bound to Multiple Uplink Interfaces: Example
In the following example, a service called sample-service is bound to two uplink interfaces: ATM interface 1/0.1 is the primary interface, and ATM interface 1/0.2 is the secondary interface. Both interfaces are configured as members of groupA.
ssg bind service sample-service atm 1/0.1ssg bind service sample-service atm 1/0.2 100!interface ATM 1/0.1 point-to-pointip address 10.1.0.1 255.255.0.0ssg direction uplink member groupA!interface ATM 1/0.2 point-to-pointip address 10.2.0.1 255.255.0.0ssg direction uplink member groupA!Service Bound to Next Hop with Multiple Uplink Interfaces: Example
In the following example, a service called sample-serviceA is bound to next-hop gateway 10.1.1.1. Next-hop gateway 10.1.1.1 is reachable through two uplink interfaces: Ethernet interface 1/0 and Ethernet interface 2/0. The group name service-groupA indicates that both interfaces share the same service (sample-serviceA).
For any services bound to either of the two interfaces, downstream traffic from the service is accepted on either interface.
!ssg bind service sample-serviceA 10.1.1.1!interface ethernet 1/0ip address 10.0.1.1 255.255.255.0ssg direction uplink member service-groupA!interface ethernet 2/0ip address 10.0.2.1 255.255.255.0ssg direction uplink member service-groupA!ip route 10.1.1.1 255.255.255.255 eth 1/0 10ip route 10.1.1.1 255.255.255.255 eth 2/0 20Service Bound to Multiple Next Hops Through Same Uplink Interface: Example
In the following example, a service called sample-serviceA is bound to primary next-hop gateway 10.1.1.1 (with distance-metric = 10) and secondary next-hop gateway 10.2.2.2 (with distance-metric = 20). Both of the next-hop gateways are reachable through the same uplink interface: Ethernet interface 1/0.
!ssg bind service sample-serviceA 10.1.1.1 10ssg bind service sample-serviceA 10.2.2.2 20!interface ethernet 1/0description connected to 10.0.0.2ip address 10.0.0.1 255.255.255.0ssg direction uplink!ip route 10.1.1.1 255.255.255.255 10.0.0.2ip route 10.2.2.2 255.255.255.255 10.0.0.2SSG Open Garden Services: Example
In the following example, two services, called og1 and og2, are defined and added to the open garden.
local-profile og1attribute 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 og2attribute 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"!ssg bind service og2 10.5.5.1!ssg open-garden og1ssg open-garden ot2!SSG Transparent Pass-Through: Example
The following example shows how to enable SSG transparent pass-through and download a pass-through filter from the AAA server called filter01:
ssg pass-throughssg pass-through filter download filter01 ciscoRadius reply received:Created Upstream acl from it.Created Downstream acl from it.Loading default pass-through filter succeeded.The following example shows how to enable SSG transparent pass-through and apply ACLs with it. The ACLs are defined on the router, which allows traffic from 10.0.0.1/32 (an SNMP tool kept on the downlink).
access-list 101 remark for upstream trafficaccess-list 101 permit ip host 10.0.0.1 anyaccess-list 102 remark for downstream trafficaccess-list 102 permit ip any host 10.0.0.1ssg pass-through filter 101 uplinkssg pass-through filter 102 downlinkAdditional References
The following sections provide references related to the Configuring SSG for Subscriber Services features.
Related Documents
SSG commands
SESM
Cisco Subscriber Edge Services Manager documentation.
RADIUS commands
RADIUS configuration tasks
"Configuring RADIUS" chapter in the Cisco IOS Security Configuration Guide
Technical Assistance
Feature Information for SSG Subscriber Services
Table 4 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the Service Selection Gateway Features Roadmap.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 4 Feature Information for SSG Subscriber Services
SSG L2TP Dial-Out
12.2(15)B
12.2T
12.3(4)T
12.4The L2TP Dial-Out feature provides mobile users with a way to securely connect to their SOHOs through the PSTN.
The following sections provide information about this feature:
•
The following commands were introduced by this feature: dnis-prefix all service, ssg dial-out.
SSG Open Garden
12.1(5)DC
12.2(4)B
12.2(8)T
12.2(11)T
12.2(13)T
12.4The SSG Open Garden feature enables you to use Cisco SSG to implement open gardens, which are collections of Web sites or networks that subscribers can access as long as they have physical access to the network. Subscribers do not have to provide authentication information before accessing the Web sites in an open garden.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: clear ssg open-garden, local-profile, show ssg open-garden, ssg open-garden.
SSG Service Logon Enhancements
12.2T
12.3(7)TThe SSG Service Logon Enhancements feature enables SSG to deliver services to a subscriber after receiving valid authentication information.
The following section provides information about this feature:
SSG Service Profile Caching
12.2T
12.3(4)TThe Service Profile Cache feature enables SSG to use a cached copy of a service profile instead of downloading the profile from a RADIUS server every time a user logs on to the service.
The following section provides information about this feature:
Configuring SSG for Subscriber Services
15.0(1)M
This feature was removed in Cisco IOS Release 15.0(1)M.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Fast Step, Follow Me Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0908R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2005-2009 Cisco Systems, Inc. All rights reserved.
