Cisco IOS Service Selection Gateway Configuration Guide, Release 12.4
Configuring SSG for Subscriber Services
Downloads: This chapterpdf (PDF - 503.0KB) The complete bookPDF (PDF - 3.64MB) | Feedback

Configuring SSG for Subscriber Services

Table Of Contents

Configuring SSG for Subscriber Services

Finding Feature Information

Contents

Prerequisites for Configuring SSG for Subscriber Services

Information About SSG Support for Subscriber Services

Services and Service Profiles

Authenticated Services

Pass-Through Services

Proxy Services

L2TP Dial-In Services

L2TP Dial-Out Services

DNS Packet Handling

How SSG Routes to Services

Open Garden (Unauthenticated) Services

Overview of SSG Open Garden Services

Open Garden Service Binding

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

DNS Packet Handling

SSG Transparent Pass-Through

Service Profile Caching

How to Configure Services for Subscribers

Configuring a Local Service Profile Using the Cisco IOS CLI

Configuring SSG Support for Services

What to Do Next

Configuring SSG to Support L2TP Dial-In Tunnel Services

Configuring SSG to Serve as a LAC

Configuring a VPDN Group

Configuring RADIUS Profiles for SSG Support of L2TP

Configuring the LNS

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

Overview of 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

Configuring a DNIS Filter

Monitoring SSG L2TP Dial-Out

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

Additional References

Related Documents

Technical Assistance

Feature Information for SSG Subscriber Services


Configuring SSG for Subscriber Services


First Published: May 2, 2005
Last 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

Information About SSG Support for Subscriber Services

How to Configure Services for Subscribers

Configuration Examples for SSG Support for Subscriber Services

Additional References

Feature Information for SSG Subscriber Services

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

Authenticated Services

How SSG Routes to Services

Open Garden (Unauthenticated) Services

SSG Uplink Interface Redundancy and Load Balancing

DNS Packet Handling

SSG Transparent Pass-Through

Service Profile Caching

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:

The AAA server—when SESM is working in RADIUS mode

The Lightweight Directory Access Protocol (LDAP) server—when SESM is working in LDAP mode

Directly on SSG—generally used for open garden services and for testing purposes

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

Proxy Services

L2TP Dial-In Services

L2TP Dial-Out Services

DNS Packet Handling

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. The remote AAA server sends the Framed-IP-address attribute (RADIUS attribute 8) in the Access-Accept packet.

2. The remote AAA server provides the IP address pool name VSA in the Access-Accept packet. In this case, SSG chooses one IP address from the locally configured pool as the service IP address.

3. The IP address pool name VSA may be configured in the service profile. In this case, SSG chooses one IP address from the service pool as the service IP address.

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 Effective with Cisco IOS Release 12.2(16)B, SSG passes the mobile station ID (MSID) of the user, if present, to the LNS in the Calling Number attribute value (AV) pair (22) of the Incoming-Call-Request (ICRQ) control message during L2TP session establishment. If LNS is using RADIUS authentication, the MSID value will also be copied to the Calling-Station-ID attribute (31), of the subsequently generated Access-Request packet.


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 DNS packet processing in an open garden configuration was handled differently by SSG in Cisco IOS Release 12.2(2)B and earlier releases. In those releases, DNS domain lookup was performed first in the domains configured in the open garden services. If a match was not found, DNS domain lookup was performed in the connected services of the user.


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 Cisco recommends binding services to next hops.


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

Access Control Lists in Open Garden Services

Hierarchical Policing in 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 Hierarchical policing for open garden services works slightly differently from the way it works for authenticated connected services. For subscribed or authenticated services, each connection inherits policing parameters from the service. For open garden services, policing parameters apply to the service (all traffic to and from the service) since no connections are present.


SSG Uplink Interface Redundancy and Load Balancing

This section contains the following concepts:

Overview of SSG Interface Redundancy

SSG Uplink Interface Redundancy Topologies

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

Multiple Uplink Interfaces with a Single Next Hop

Multiple Uplink Interfaces with No Next Hop

Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops

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 DNS packet processing in an open garden configuration was handled differently by SSG in Cisco IOS Release 12.2(2)B and earlier releases. In those releases, DNS domain lookup was performed first in the domains configured in the open garden services. If a match was not found, DNS domain lookup was performed in the connected services of the user.


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:

Makes SSG easier to integrate into an existing network by not requiring users who have authenticated with network access servers (NAS) to authenticate with SSG

Allows management traffic (such as TACACS+, RADIUS, and SNMP) from NASs connected to the host network to pass through to the service provider network

Allows visitors or guests to access certain parts of the network

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:

A user selects a service on the service logon page that SESM displays.

SSG receives the service logon request and looks up the service profile using the service name.

If the service profile exists and it is active, SSG uses the service profile to process the logon request.

If the service profile exists, but it is inactive (for example, SSG is currently downloading the profile), SSG queues the logon request and processes the request after the service profile is downloaded.

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

Configuring SSG to Support L2TP Dial-In Tunnel Services

Configuring SSG to Support L2TP Dial-Out Services

Configuring SSG Open Garden Services

Configuring SSG Transparent Pass-Through

Monitoring and Maintaining SSG Support for Services

Troubleshooting SSG Support for Services

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 If you are using SSG with the SESM in LDAP 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.


SUMMARY STEPS

1. local-profile service-name

2. attribute radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value

3. Repeat Step 2 for each attribute that you want to add to the service profile.

DETAILED STEPS

 
Command or Action
Purpose

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.

See the RADIUS Profiles and Attributes for SSG module for information about RADIUS profiles and VSAs for SSG.

Only attributes that can appear in RADIUS Access-Accept packets can be configured using the attribute command.

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. ssg bind service service-name {ip-address | interface-type interface-number} [distance-metric]

2. ssg service-search-order {local | remote | local remote | remote local}

3. ssg next-hop download [profile-name] [profile-password]

4. ssg service-cache [refresh-interval minutes]

5. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

ssg bind service service-name {ip-address | interface-type interface-number} [distance-metric]

Example:

Router(config)# ssg bind service sample-service atm 1/0.1

Specifies the interface for a service.

Every service must be bound to an uplink interface, either by defining the binding in the next-hop table or by using the ssg bind service command. If the service binding is defined in the next-hop table, then it is not necessary to bind the service by using the ssg bind service command.

To bind a service to more than one interface for interface redundancy, you can enter this command more than once.

To control the routing of upstream traffic, use the distance-metric argument. SSG uses the interface that has the lowest metric. The default value for the distance-metric is 0.

Step 2 

ssg service-search-order {local | remote | local remote | remote local}

Example:

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

(Optional) Specifies the order in which SSG searches for a service profile.

The local keyword specifies that service profiles are configured using local profile.

The default value for the service search order is remote; that is, the SSG searches for service profiles on the RADIUS server.

Step 3 

ssg next-hop download [profile-name] [profile-password]

Example:

Router(config)# ssg next-hop download next-hop-tbl next-hop-tbl-passwd

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

Step 4 

ssg service-cache [refresh-interval minutes]

Example:

Router(config)# ssg profile-cache

(Optional) Allows SSG to cache the user profiles of non-PPP users.

Step 5 

exit

Example:

Router(config)# exit

(Optional) Returns to global configuration mode.

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:

Configuring SSG to Serve as a LAC

Configuring a VPDN Group

Configuring RADIUS Profiles for SSG Support of L2TP

Configuring the LNS

To verify SSG support for L2TP dial-in tunnel services, perform the task in the following section:

Monitoring and Maintaining SSG Support for L2TP Services

Configuring SSG to Serve as a LAC

Perform this task to configure SSG to serve as an LAC.

SUMMARY STEPS

1. vpdn enable

2. interface slot/port

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

vpdn enable

Example:

Router(config)# vpdn enable

Enables L2TP functionality.

Step 1 

interface type slot/port

Example:

Router(config)# interface 1/0

Enables NAT on the downlink interface.

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. vpdn-group name

DETAILED STEPS

 
Command or Action
Purpose

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

Service-Info VPDN Attributes

Cisco AVpair VPDN Attributes

Cisco AVpair VPDN attributes can be configured in either of two ways:

By configuring the vdpn-group-name in the service profile and the VDPN group on the router.

By configuring VPDN attributes within the service profile.

Table 1 lists the Cisco AVpair attributes used in the service profile to configure VPDN.

Table 1 Cisco AV Pair Attributes

Attribute
Description

VPDN IP Address

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

VPDN Tunnel ID

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

L2TP Tunnel Password

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

vpdn-group-name

Specifies the vpdn-group-name that will be configured on the router.


Service-Info VPDN Attributes

Table 2 lists the Service-Info attributes used in the service profile to define the L2TP service parameters.

Table 2 Service-Info Attributes

Attribute
Description

Type of Service

Specifies proxy, tunnel, or pass-through service. L2TP always uses tunnel service.

MTU Size

Specifies the PPP maximum transmission unit (MTU) size for SSG as an LAC. By default, the PPP MTU size is 1500 bytes.

Service Route

Specifies the networks available to the user for this service.


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. username name password secret

2. vpdn-group number

3. accept-dialin

4. protocol l2tp

5. virtual-template template-number

6. exit

7. terminate-from hostname hostname

8. l2tp tunnel password password

9. exit

10. interface virtual-template number

11. ip unnumbered interface-type interface-number

12. peer default ip address pool pool-name

13. ppp authentication {chap | chap pap | pap chap | pap}

14. ip local pool pool-name start-address end-address

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

username name password secret

Example:

Router(config)# username myusername password mypassword

(Optional) Specifies the password to be used for PAP and CHAP.

Subscribers can also be defined and authenticated on the AAA server serving the LNS.

Step 2 

vpdn-group number

Example:

Router(config)# vpdn-group 3

Selects the VPDN group.

Each L2TP tunnel requires a unique VPDN group.

Enters VPDN group configuration mode.

Step 3 

accept-dialin

Example:

Router(config-vpdn)# accept-dialin

Creates an accept dial-in VPDN group and enters VPDN Accept-dialin group configuration mode.

Step 4 

protocol l2tp

Example:

Router(config-vpdn-acc-in)# protocol l2tp

Configures the VPDN to use L2TP.

Step 5 

virtual-template template-number

Example:

Router(config-vpdn-acc-in)# virtual-template 1234

Specifies which virtual template will be used to clone virtual access interfaces.

Step 6 

exit

Example:

Router(config-vpdn-acc-in)# exit

Returns to VPDN group configuration mode.

Step 7 

terminate-from hostname hostname

Example:

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

Specifies the tunnel ID that will be required when a VPDN tunnel is accepted.

This must match the VPDN tunnel ID configured in the RADIUS service profile.

Step 8 

l2tp tunnel password password

Example:

Router(config-vpdn)# l2tp tunnel password mypassword

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

Step 9 

exit

Example:

Router(config-vpdn)# exit

Returns to global configuration mode.

Step 10 

interface virtual-template number

Example:

Router(config)# interface Virtual-Template 1234

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

Step 11 

ip unnumbered interface-type interface-number

Example:

Router(config-if)# ip unnumbered FastEthernet 1/0

Configures the interface as unnumbered and provides a local address.

Enters interface configuration mode.

Step 12 

peer default ip address pool pool-name

Example:

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

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

Step 13 

ppp authentication {chap | chap pap | pap chap | pap}

Example:

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

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

Step 14 

ip local pool pool-name start-address end-address

Example:

Router(config-if)# ip local pool mypool 192.0.2.0 192.0.2.255

Creates a local IP address pool named mypool, which contains all local IP addresses from 192.0.2.0 to 192.0.2.255.

Monitoring and Maintaining SSG Support for L2TP Services

Perform this task to monitor and maintain SSG support of L2TP tunnel services.

SUMMARY STEPS

1. enable

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

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

4. clear vpdn tunnel l2tp remote-name local-name

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

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

Router# show vpdn tunnel summary

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

Step 3 

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

Router# show vpdn session

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

Step 4 

clear vpdn tunnel l2tp remote-name local-name 
Example:

Router# clear vpdn tunnel l2tp local2 local3

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

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.

Prerequisites for SSG L2TP Dial-Out

Restrictions for SSG L2TP Dial-Out

Before you configure SSG support for L2TP dial-out service, you should understand the following concepts:

Overview of 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

Perform the following tasks to configure SSG support for L2TP dial-out services:

Configuring a Global Dial-Out Service Profile

Configuring the User Service Profile for L2TP Dial-Out Services

Configuring a DNIS Filter

Monitoring SSG L2TP Dial-Out

Troubleshooting SSG L2TP Dial-Out User Logon Failures

Troubleshooting SSG L2TP Dial-Out Service Login Failures

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:

Layer 2 Tunneling Protocol (L2TP) dial-out as a primary service for PPP users

Challenge Handshake Authentication Protocol (CHAP) authentication for dial-out tunnel services

Dial-out tunnel support for protocols other than L2TP protocols, such as Layer 2 Forwarding Protocol (L2F).

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. ssg dial-out

2. dnis-prefix all service service-name

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

ssg dial-out

Example:

Router(config)# ssg dial-out

Enters SSG dial-out configuration mode.

Note There is no command to enable or disable the SSG L2TP Dial-Out feature. An L2TP dial-out tunnel is established if the service profile contains the "vpdn:dout-type=2" attribute.

Step 2 

dnis-prefix all service service-name

Example:

Router(config-dial-out)# dnis-prefix all service service1

Configures the dial-out global service name.

The global service is configured for users who are doing an account logon with a structured username.

service-name—Name of the dial-out global service.

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.

Table 3 MSISDN/DNIS VSA

Attribute ID
Vendor ID
Subattribute ID and Type
Attribute Name
Subattribute Data

26

9

251

MSISDN/DNIS

Y—Service-information code for sending MSISDN with DNIS

G—Delimiter character that separates the DNIS number from the MSISDN number.


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. ssg dial-out

2. exclude dnis-prefix dnis-prefix

3. Repeat Step 2 to add DNIS prefixes to the DNIS exclusion list.

4. download exclude-profile profile-name password

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

ssg dial-out

Example:

Router(config)# ssg dial-out

Enters SSG dial-out configuration mode.

Step 2 

exclude dnis-prefix dnis-prefix

Example:

Router(config-dial-out)# exclude dnis-prefix 18085288110

(Optional) Configures the DNIS filter by adding a DNIS prefix to the DNIS exclusion list.

dnis-prefix—The DNIS prefix to add to the DNIS exclusion list.

Step 3 

(Optional) Repeat Step 2 to add DNIS prefixes to the DNIS exclusion list.

Step 4 

download exclude-profile profile-name password

Example:

Router(config-dial-out)# download exclude-profile dnis_exclude_profile safe123

(Optional) Downloads the DNIS exclusion list locally or from AAA.

profile-name—Name of the DNIS exclusion list.

password—Password of the DNIS exclusion list.

Monitoring SSG L2TP Dial-Out

Perform this task to monitor the SSG L2TP Dial-Out feature.

SUMMARY STEPS

1. show ssg dial-out exclude-list

2. show ssg service [service-name]

3. show ssg connection ip-address service-name [interface]

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

show ssg dial-out exclude-list

Example:

Router# show ssg dial-out exclude-list

Displays information about the DNIS exclusion list.

Step 2 

show ssg service [service-name]

Example:

Router# show ssg service service1

Displays detailed information about a service.

If no service name is entered, this command displays a list of all services.

service-name—(Optional) Name of an active SSG service.

Step 3 

show ssg connection ip-address service-name [interface]

Example:

Router# show ssg connection 10.1.1.19 InstMsg

Displays the connections of a given host and a service name.

ip-address—IP address of an active SSG connection. This is always a subscribed host.

service-name—Name of an active SSG connection.

interface—(Optional) The IP address through which the host is connected.

Troubleshooting SSG L2TP Dial-Out User Logon Failures

Perform this task to troubleshoot L2TP dial-out user logon failures.

SUMMARY STEPS

1. debug ssg ctrl-events

2. debug ssg radius

3. debug ssg ctrl-err

DETAILED STEPS


Step 1 debug ssg ctrl-events

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-events

SSG-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 debug ssg radius

Enter the debug ssg radius command to display messages about the communication between the AAA server and the router.

Router# debug ssg radius

RADIUS: 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 decrypt

Configure the correct key by entering the radius-server key ssg command.

Step 3 debug ssg ctrl-err

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-err

SSG-CTL-ERR: Unable to find SSG sub-block from ATM3/0.1

The 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 debug ssg ctrl-events

Enter the debug ssg ctrl-events command.

Router# debug ssg ctrl-events

SSG-CTL-EVN: Invalid DNIS number for dialout tunnel service

The 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 tunnel

or

SSG-VPDN-CTL-EVN: Failed to establish call..informing SSG

Follow the steps below to troubleshoot this problem:

a. After giving the service logon request, enter the show vpdn tunnel command to view the tunnel status (the tunnel will time out after some time).

b. If the tunnel has come up, skip this step. If the tunnel is not up, enable the debug vpdn l2x-events and debug vpdn l2x-errors commands on the SSG and on the LAC.

Common problems are tunnel ID mismatch and destination IP not reachable.

c. Once the tunnel is up, problems can appear on the dialer interface.

Enable debug ppp negotiation and debug ppp authentication commands.

If no PPP debug messages are seen, it is confirmed that the problem is with the dialer interface.

d. Enable the debug dialer and debug isdn q921, 931 commands on the LAC and on the SOHO. A common problem is ISDN status "not established."

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. local-profile [profile-name]

2. attribute 26 9 251 "Rip-address;subnet-mask"

3. attribute 26 9 251 "Dip-address"

4. attribute 26 9 251 "Odomain-name"

5. exit

6. ssg open-garden profile-name

7. ssg bind service service {ip-address | interface-type interface-number}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

local-profile profile-name

Example:

Router(config)# local-profile myprofile

Creates a local service profile and enters profile configuration mode.

Note It is not necessary to create a local service profile if the service profile is created on the RADIUS server.

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.

You can add multiple networks to an open garden service.

Repeat step as necessary.

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.

Enter this command twice to specify two DNS servers for DNS fault tolerance. SSG will send DNS requests to the first DNS server in its list. If the first server does not respond to the requests, SSG will send the requests to the second DNS server.

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.

Repeat step as necessary. You can add multiple domain names to an open garden service.

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 This step is required only if the open garden is routed through a next-hop gateway.

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. ssg pass-through [domain | filter {ip-access-list | ip-extended-access-list | access-list-name | download [profile-name | profile-name profile-password]} [downlink | uplink]]

2. end

3. show ssg pass-through-filter [begin expression | exclude expression | include expression]

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

ssg pass-through [domain | filter {ip-access-list | ip-extended-access-list | access-list-name | download [profile-name | profile-name profile-password]} [downlink | uplink]]

Example:

Router(config)# ssg pass-through filter download filter01 cisco

Enables transparent pass-through, which allows unauthenticated traffic to bypass SSG processing in either direction without modification.

Use the filter options to specify access control for packets.

Use the download options to download a service profile and use its filters as default filters.

Step 2 

end

Example:

Router(config)# end

Returns to privileged EXEC mode.

Step 3 

show ssg pass-through-filter [begin expression | exclude expression | include expression]

Example:
Router# show ssg pass-through-filter

(Optional) Displays the downloaded filter for transparent pass-through.

Use this command to verify transparent pass-through configuration.

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-filter

        Service name:  filter01
        Password:      cisco
        Direction:     Uplink

Extended IP access list (SSG ACL)
    permit tcp 172.16.6.0 0.0.0.255 any eq telnet
    permit tcp 172.16.6.0 0.0.0.255 192.168.250.0 0.0.0.255 eq ftp

Monitoring and Maintaining SSG Support for Services

Perform this task to monitor and maintain SSG support for services.

SUMMARY STEPS

1. show ssg service [service-name [begin expression | exclude expression | include expression]]

2. show vpdn tunnel l2tp

3. show ssg open-garden

4. show ssg interface [brief]

5. show ip nat translations

6. clear ssg open-garden

7. clear ssg service profile-name

8. show ssg pass-through-filter [begin expression | exclude expression | include expression]

9. clear ssg pass-through-filter

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

show ssg service [service-name [begin expression | exclude expression | include expression]]

Example:

Router# show ssg service

Displays information for an SSG service.

If no service name is entered, the command displays information for all services.

Step 2 

show vpdn tunnel l2tp

Example:

Router# show vpdn tunnel l2tp

Shows L2TP tunnels established for tunnel services.

Step 3 

show ssg open-garden

Example:

Router# show ssg open-garden

Shows the list of open-garden services created by the ssg open garden command.

Step 4 

show ssg interface [brief]

Example:

Router# Show ssg interface brief

Lists the SSG-enabled interfaces as uplink, downlink, and featurelink.

Lists hosts on downlink interfaces and services bound to the uplink interfaces.

Step 5 

show ip nat translations

Example:

Router# Show ip nat translations

Lists the NAT entries on SSG.

Step 6 

clear ssg open-garden

Example:

Router# clear ssg open-garden

Removes all instances of the ssg open-garden command from the configuration and removes the service object of all the open garden services.

Step 7 

clear ssg service profile-name

Example:

Router# clear ssg service profile-name

Removes the service from SSG.

For authenticated services, this command clears all of the connections (that is, users) logged into that service.

Step 8 

show ssg pass-through-filter [begin expression | exclude expression | include expression]

Example:
Router# show ssg pass-through-filter

(Optional) Displays the downloaded filter for transparent pass-through.

Step 9 

clear ssg pass-through-filter

Example:
Router# clear ssg pass-through-filter

(Optional) Removes the downloaded filter for transparent pass-through.

Troubleshooting SSG Support for Services

Perform this task to troubleshoot SSG support for services.

SUMMARY STEPS

1. debug ssg ctrl-events

2. debug ssg ctrl-errors

3. debug ssg ctrl-packets

4. debug ssg events

5. debug ssg errors

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

debug ssg ctrl-events

Example:

Router# debug ssg ctrl-events

Displays event messages for the control modules, which include all modules that manage the user authentication and service logon and logoff (RADIUS, PPP, Subblock, and Accounting).

An event message is an informational message generated during normal execution.

Step 2 

debug ssg ctrl-errors

Example:

Router# debug ssg ctrl-errors

Shows error messages for the control modules. These modules include all those that manage the user authentication and service logon and logoff (RADIUS, PPP, Subblock, and Accounting).

An error message is the result of an error detected during normal execution.

Step 3 

debug ssg ctrl-packets

Example:

Router# debug ssg ctrl-packets

Shows packet messages for the control modules. These modules include all those that manage the user authentication and service logon and logoff (RADIUS, PPP, Subblock, and Accounting).

A packet message displays the contents of a package.

Step 4 

debug ssg events

Example:

Router# debug ssg events

Displays event messages for the system modules such as Timeout and Initialization.

An event message is an informational message that appears during normal execution.

Step 5 

debug ssg errors

Example:

Router# debug ssg errors

Displays error messages for the system modules such as Timeout and Initialization.

An error message is the result of an error detected during normal execution.

Configuration Examples for SSG Support for Subscriber Services

This section contains the following examples:

Service Profile Configuration: Examples

SSG Support for L2TP Tunnel Services: Examples

SSG Support for L2TP Dial-Out Services: Examples

SSG Interface Redundancy: Examples

SSG Open Garden Services: Example

SSG Transparent Pass-Through: Example

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 l2tpnet1
 attribute 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

RADIUS Service Profile: Example

LNS Configuration: Example

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/0
 ip address 10.1.1.1 255.255.255.0
 ip 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 cisco
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname My-Tunnel
 l2tp tunnel password 7 02050D480809
!
ip local pool pool2 10.8.8.1 10.8.8.127
interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 no ip directed-broadcast
 peer default ip address pool pool2
 ppp authentication pap chap

SSG 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

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

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 SSG
aaa new-model
aaa authentication ppp default group radius
!
ip cef
! enable vpdn for l2tp dialout
vpdn enable
!
ssg enable
ssg default-network 10.1.1.1 255.255.255.255
ssg service-password cisco
ssg radius-helper auth-port 1645 acct-port 1646
ssg radius-helper key cisco
ssg 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 interface
ip nat inside
pvc 0/33
!
interface ATM3/0.10 point-to-point ! For a PPP user.
pvc 0/100
encapsulation aal5mux ppp Virtual-Template1
!
interface Virtual-Template1
ip unnumbered Ethernet2/2
peer default ip address pool ppp_pool_1
ppp authentication pap
ip 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 5
radius-server retransmit 3
radius-server key ssg

LAC Configuration: Example

hostname LAC
!enable VPDN
vpdn enable
! enable to accept dialout tunnel
vpdn-group 1
accept-dialout
 protocol l2tp
 dialer 0 ! Matches rotary group and the dialer interface.
terminate-from hostname lns_l2x0
l2tp 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 address
encapsulation ppp
dialer in-band
dialer aaa
ppp authentication pap
!
dialer-list 1 protocol ip permit

SOHO Configuration: Example

hostname soho0
username john password 0 cisco
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Serial1/0:23
 no ip address
 encapsulation ppp
 dialer rotary-group 0 ! This matches the interface Dialer0.
 isdn switch-type primary-5ess
 no peer default ip address
 no cdp enable
!
interface Dialer0
 ip unnumbered Loopback2
 encapsulation ppp
 dialer-group 1
 peer default ip address pool soho_1
 no cdp enable
 ppp authentication chap
!
ip local pool soho_1 10.0.0.20 10.0.0.40
dialer-list 1 protocol ip permit

Configuring 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-out
 dnis-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 soho0
username user1 password 0 cisco
username user1@4444007 password 0 cisco
username user7 password cisco
!
controller t1 1/0
framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface serial1/1:23
 no ip address
 encapsulation ppp
 dialer pool-member 1
 isdn switch-type primary-5ess
 no peer default ip address
 no cdp enable
 ppp authentication chap
!
interface Dialer1 ! Configures a special service policy and pool for user "user1."
 ip unnumbered loopback1
 encapsulation ppp
 dialer pool 1
 dialer remote-name john
 dialer idle-timeout 2147483
 dialer string 3456048
 dialer-group 1
 service-policy output SETDSCP
 peer default ip address pool soho_1
!
interface Dialer2 ! Configures a special service policy and pool for user "user7."
 ip unnumbered loopback1
 encapsulation ppp
 dialer pool 1
 dialer remote-name gary
 dialer idle-timeout 2147483
 dialer-group 1
 peer default ip address pool soho_OLAPP
 pulse-time 0
 ppp authentication chap
!
ip local pool soho_1 10.0.0.20 10.0.0.40
ip local pool soho_OLAP 11.0.0.10

Configuring 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

LAC10 = 192.0.2.0

LAC11 = 192.1.2.0

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 LAC10
vpdn enable
!
vpdn-group 1
accept-dialout
 protocol l2tp
  dialer 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 1
accept-dialout
 protocol l2tp
 dialer  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/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface ATM2/0.1 point-to-point
 ip address 100.0.0.2 255.0.0.0
 pvc 0/100 
 !
interface Serial4/0:23
 no ip address
 encapsulation ppp
 dialer rotary-group 0             
 dialer-group 1
 isdn switch-type primary-5ess
!
interface Dialer0
 no ip address
 encapsulation ppp
 dialer in-band
 dialer aaa
 ppp authentication pap
!
interface Serial4/1:23
 no ip address
 encapsulation ppp
 dialer rotary-group 1             
 dialer-group 1
 isdn switch-type primary-5ess
!
interface Dialer1
 no ip address
 encapsulation ppp
 dialer in-band
 dialer aaa
 ppp authentication pap
!
dialer-list 1 protocol ip permit

SOHO 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-out
 dnis-prefix all service dialout_1

Configuring 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-DEV
radius = 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-DEV
radius=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 attribute

Configuring a DNIS Filter: Example

The following example shows how to configure a DNIS exclude profile in AAA:

user = exclude_dnis_aaa{
member = SSG-DEV 
radius=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-out
 exclude dnis-prefix 18085288110
 exclude dnis-prefix 18085288111
 download exclude-profile exclude_dnis_aaa cisco

SSG 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.1
ssg bind service sample-service atm 1/0.2 100
!
interface ATM 1/0.1 point-to-point
 ip address 10.1.0.1 255.255.0.0
 ssg direction uplink member groupA
!
interface ATM 1/0.2 point-to-point
 ip address 10.2.0.1 255.255.0.0
 ssg 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/0
  ip address 10.0.1.1 255.255.255.0
  ssg direction uplink member service-groupA
!
interface ethernet 2/0
  ip address 10.0.2.1 255.255.255.0
  ssg direction uplink member service-groupA
!
ip route 10.1.1.1 255.255.255.255 eth 1/0 10 
ip route 10.1.1.1 255.255.255.255 eth 2/0 20 

Service 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 10
ssg bind service sample-serviceA 10.2.2.2 20
!
interface ethernet 1/0
  description connected to 10.0.0.2
  ip address 10.0.0.1 255.255.255.0
  ssg direction uplink 
!
ip route 10.1.1.1 255.255.255.255 10.0.0.2
ip route 10.2.2.2 255.255.255.255 10.0.0.2

SSG Open Garden Services: Example

In the following example, two services, called og1 and og2, are defined and added to the open garden.

local-profile 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 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" 
!
ssg bind service og2 10.5.5.1
!
ssg open-garden og1
ssg 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-through 
ssg pass-through filter download filter01 cisco 

Radius 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 traffic
access-list 101 permit ip host 10.0.0.1 any
access-list 102 remark for downstream traffic
access-list 102 permit ip any host 10.0.0.1

ssg pass-through filter 101 uplink
ssg pass-through filter 102 downlink

Additional References

The following sections provide references related to the Configuring SSG for Subscriber Services features.

Related Documents

Related Topic
Document Title

SSG commands

Cisco IOS Service Selection Gateway Command Reference

SESM

Cisco Subscriber Edge Services Manager documentation.

RADIUS commands

Cisco IOS Security Command Reference

RADIUS configuration tasks

"Configuring RADIUS" chapter in the Cisco IOS Security Configuration Guide


Technical Assistance

Description
Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/techsupport


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 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.


Table 4 Feature Information for SSG Subscriber Services 

Feature Name
Releases
Feature Configuration Information

SSG L2TP Dial-Out

12.2(15)B
12.2T
12.3(4)T
12.4

The 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:

Configuring SSG to Support L2TP Dial-Out Services

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.4

The 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:

Open Garden (Unauthenticated) Services

Configuring SSG Open Garden Services

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)T

The 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:

Authenticated Services

SSG Service Profile Caching

12.2T
12.3(4)T

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.

The following section provides information about this feature:

Service Profile Caching

Configuring SSG for Subscriber Services

15.0(1)M

This feature was removed in Cisco IOS Release 15.0(1)M.