This chapter explains how to use a virtual private dialup network (VPDN) with the Oracle Communications Billing and Revenue Management (BRM) RADIUS Manager.
Before using RADIUS Manager to set up a VPDN, you should be familiar with these topics:
A virtual private dialup network (VPDN) enables a customer to transparently access a private network by using a public dialup Internet service provider (ISP). VPDN allows a company, that doesn't want to own POPs (Points of Presence) and network infrastructure to provide dialup access to a company network.
Implementation requirements for VPDN solutions:
Provide a POP (phone lines, modems, and terminal servers).
Provide authentication of users.
Track failed authentication requests for potential security breaches.
If the terminal servers are outside a firewall, you must also provide:
A mechanism for information to flow through a firewall
Secure data transmission using encryption
Typically an organization uses a firewall and provides access from the Internet. A tunnel needs to be created between the user's computer and the organization's network. This tunnel transparently transmits information over the Internet and through the firewall. Since the information being transmitted through the tunnel is generally sensitive information, it is usually encrypted.
There are a number of standard and proprietary tunneling protocols available such as L2TP, L2F, ATMP, and PPTP. Each protocol requires different setup information (attributes) to establish the tunnel.
While RADIUS Manager is basically independent of the protocol used between a NAS and the tunnel gateway, only L2F running on CISCO 3600 series hardware has been validated.
Example of how a VPDN user model can work:
For a non-VPDN service, the user dials the ISP and logs in as joe or joe@isp.com.
If Joe is authenticated successfully against the ISP database, he is allocated an IP address from the ISP's pool of addresses and given access to the Internet. In this situation, Joe is not be able to access systems and services at company.com, because those systems are behind a firewall.
After the appropriate arrangements have been made, Joe is able to dial in to the ISP and get through the firewall.
The RADIUS server determines that joe@isp.com requires a VPDN tunnel to be established. The RADIUS server sends attributes back to the NAS which tell the NAS how to set up the tunnel (destination gateway, authentication information, and so on).
The NAS establishes the tunnel through to the gateway at company.com and provides Joe with transparent access to the systems and services at company.com.
The RADIUS server also accepts accounting information from the NAS. This information is used to bill Joe or company.com for the service.
This solution requires that the employee have only a standard dialup system since tunneling is provided transparently by the ISP between the NAS and the organization's gateway.
Two VPDN models are supported:
User model: Users pay for an manage their accounts
Organization model: The organization controls and pays for accounts
Both models are implemented by configuring the mod_pin module instances in the RADIUS configuration file (BRM_home/apps/radius/config, where BRM_home is the directory in which BRM components are installed). The organization model also requires changes to the default BRM behavior.
With the user model, an organization provides access to users through the organization's network using a VPDN, but requires users to pay for and manage their own ISP accounts.
User Joe dials his local ISP and logs in as joe@isp.com.
The NAS sends an Access-Request request to the RADIUS server.
The RADIUS service makes two calls to BRM: one to authenticate joe@isp.com, and one to find session creation attributes.
The BRM database is searched for the /service/ip storable object containing the login joe@isp.com. This service object defines how to set up the tunnel for the user.
Information from the /service/ip storable object defining how to set up the tunnel is returned to the RADIUS server for the reply to the NAS.
The NAS uses the tunnel setup attributes to create a tunnel through the appropriate gateway.
When this session starts and ends, the NAS sends an Accounting-Request to the RADIUS server. This information is passed to BRM and an /event/session/dialup event is create.
The event is then rated and charged to Joe's account.
If multiple NAS types are used, they must all be set up to support your tunneling method. It is possible to work around this limitation in the PCM_OP_TERM_POL_AUTHORIZE opcode by determining the type of the NAS and manually setting the appropriate attribute-value pairs for the NAS type.
A limitation of using multiple network access servers is that the default PCM_OP_TERM_POL_AUTHORIZE policy opcode does not provide common configuration information across services.
For example, if joe@isp.com and susan@isp.com both have the same tunneling information, there is no default policy provision for storing that information in a common location and referring to it in the individual services.
To handle VPDN requests your RADIUS configuration file (BRM_home/apps/radius/config) must be set up to use one of these storable objects:
/service/vpdn
/service/ip
These storable objects provide the necessary VPDN tunneling information.
This example shows the syntax in the RADIUS configuration file (BRM_home/apps/radius/config) for using the /service/vpdn storable object with the VPDN user model.
# Cannot find the account, see if it is a user_vpdn
user_vpdn_auth {
type = mod_pin
check {
Pseudo-Request-Type = Access-Request
User-Name = "*@*"
}
send (
Class = user_vpdn
}
service-type = /service/vpdn
options = Ignore-No-Entry
}
user_vpdn_acct {
type = mod_pin
check {
Pseudo-Request-Type = Accounting-Request
Class = user_vpdn
}
service-type = /service/vpdn
}
No service-type setting is required to use the /service/ip storable object with the user model VPDN. The default BRM authentication and accounting setup processes the requests.
This example shows the syntax in the RADIUS configuration file (BRM_home/apps/radius/config) for using the /service/ip storable object to implement the VPDN user model:
pin_auth {
type = mod_pin
check {
Pseudo-Request-Type = Access-Request
}
send {
Class = "pin"
}
options=Ignore-No-Entry
}
pin_acct {
type = mod_pin
check {
Pseudo-Request-Type = Accounting-Request
Class = "pin"
}
options=Ignore-No-Entry
}
Both examples require you to configure the PIN_FLD_ARGS array in the appropriate /service/ip or /service/vpdn storable objects.
To establish a VPDN tunneling session for an access request, a variety of attributes must be returned to the NAS. The exact attributes needed for each VPDN configuration differs with each VPDN hardware vendor.
To return these attributes to the NAS, the /service/vpdn or /service/ip storable object must be configured to return the attributes. These attributes are stored in the PIN_FLD_ARGS array in the /service/vpdn and /service/ip storable objects. All of the required tunneling information is stored in this array. There are two ways to set the attributes in the PIN_FLD_ARGS array:
Use testnap or a custom PCM client.
Use PCM_OP_TERM_POL_AUTHRORIZE to set the attributes during account creation
Using testnap or a custom application to set VPDN attributes
The array can be accessed by calling the PCM_OP_WRITE_FLDS opcode from either testnap or a simple custom PCM client.
This example shows how to include the fictitious Custom-Attr-1 attribute in the PIN_FLD_ARGS array:
# Remember to use the PCM_OPFLG_ADD_ENTRY (0x0020) flag when calling the # opcode if you are adding new array entries. # 0 PIN_FLD_POID POID [0] 0.0.0.8 /service/ip 8686 0 PIN_FLD_ARGS ARRAY [0] 1 PIN_FLD_NAME STR [0] "Custom-Attr-1" 1 PIN_FLD_VALUE STR [0] "testing_nas"
This example shows the PCM_OP_TERM_POL_AUTHORIZE output flist when the PIN_FLD_ARGS are set:
D Fri October 22 15:19:52 1999 danube pin_radiusd:20320 pin_login.c:498 GOT FROM AUTHORIZE # number of field entries allocated 13, used 13 0 PIN_FLD_POID POID [0] 0.0.0.8 /service/ip 8686 5 0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.8 /account 8942 0 0 PIN_FLD_PROTOCOL ENUM [0] 1 0 PIN_FLD_COMPRESSION ENUM [0] 0 0 PIN_FLD_ARGS ARRAY [0] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "User-Service" 1 PIN_FLD_VALUE STR [0] "2" 0 PIN_FLD_ARGS ARRAY [1] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Framed-Protocol" 1 PIN_FLD_VALUE STR [0] "1" 0 PIN_FLD_ARGS ARRAY [2] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Ascend-Route-IP" 1 PIN_FLD_VALUE STR [0] "1" 0 PIN_FLD_ARGS ARRAY [3] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Framed-Netmask" 1 PIN_FLD_VALUE STR [0] "255.255.255.0" 0 PIN_FLD_ARGS ARRAY [4] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Ascend-Idle-Limit" 1 PIN_FLD_VALUE STR [0] "120" 0 PIN_FLD_ARGS ARRAY [5] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Ascend-Link-Compression" 1 PIN_FLD_VALUE STR [0] "1" 0 PIN_FLD_ARGS ARRAY [6] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Ascend-Assign-IP-Pool" 1 PIN_FLD_VALUE STR [0] "1" 0 PIN_FLD_ARGS ARRAY [7] allocated 2, used 2 1 PIN_FLD_NAME STR [0] "Custom-Attr-1" 1 PIN_FLD_VALUE STR [0] "testing_nas" 0 PIN_FLD_RESULT ENUM [0] 1 D Fri May 22 15:19:52 1998 danube pin_radiusd:20320 pin_radiusd.c:4143 authPinPwd returning 0 D Fri May 22 15:19:52 1998 danube pin_radiusd:20320 pin_radiusd.c:4143 Sending Ack of id 0 to 127.0.0.1 (localhost)
This example shows the return packet:
Request-Type = Auth-Ack
User-Service = 2
Framed-Protocol = 1
Ascend-Route-IP = 1
Framed-Netmask = 255.255.255.0
Ascend-Idle-Limit = 120
Ascend-Link-Compression = 1
Ascend-Assign-IP-Pool = 1
Custom-Attr-1 = "testing_nas"
You can use the PCM_OP_TERM_POL_AUTHORIZE opcode to pass the required VPDN attributes to PCM_OP_CUST_POL_PRE_COMMIT and PCM_OP_CUST_PREP_CUSTOMER. The attributes become part of the inherited service information in the /service/ip or /service/vpdn storable object. See the corresponding opcode information for details.
Both models log sessions as /event/session/dialup events in the corresponding service object. The organization model VPDN is a superset of the user model VPDN. The instructions for setting up the organization model assume that the user model VPDN has been implemented.
Table 12-1 maps RADIUS attributes to fields in the /event/session/dialup service object:
Table 12-1 Radius Attributes Mapping
| RADIUS Attribute | BRM Field |
|---|---|
|
User-Name |
PIN_FLD_LOGIN |
|
NAS-Identifier/NAS-IP-Address |
PIN_FLD_TERMSERV_ID |
|
NAS-Port |
PIN_FLD_TERMSERV_PORT |
|
Acct-Terminate-Cause |
PIN_FLD_TERMINATE_CAUSE |
|
NAS-Port-Type |
PIN_FLD_TYPE |
|
network |
PIN_FLD_NETWORK |
|
timezone |
PIN_FLD_TIMEZONE |
|
Acct-Session-Id |
PIN_FLD_TRANS_ID |
|
Called-Station-Id |
PIN_FLD_DNIS |
|
Calling-Station-Id |
PIN_FLD_ANI |
|
Ascend-Data-Rate |
PIN_FLD_SPEED |
|
Framed-IP-Address |
PIN_FLD_IPADDR |
|
desc |
PIN_FLD_DESCR |
|
Acct-Input-Octets |
PIN_FLD_BYTES_IN |
|
Acct-Output-Octets |
PIN_FLD_BYTES_OUT |
|
Acct-Input-Packets |
PIN_FLD_PACKETS_IN |
|
Acct-Output-Packets |
PIN_FLD_PACKETS_OUT |
If you are implementing VPDN using the /service/vpdn storable object, you configure the following options for a customer account by using Customer Center:
The protocol the customer will use (PPP or SLIP)
The IP address of the customer's host machine (xxx.xxx.xxx.xxx)
Whether or not header compression should be used
Any protocol extensions (name/value pairs that control the IP connection)
With this model, the organization controls which users have access to their network, and pays an ISP to provide the network infrastructure and employee access. The organization model must be used along with the user model. The user model must be implemented prior to setting up the organization model.
The user dials his local ISP and logs in as user@isp.com.
The NAS sends an Access-Request request to the RADIUS server, which sends an authentication request to BRM.
The authentication request fails because there is no service login of user@isp.com in the BRM database.
The RADIUS server picks up this authentication failure, and passes the request through to the module instance configured to handle VPDN requests.
The authentication request is sent to BRM again, this time with a login name containing company.com. The request in checked against the /service/vpdn service.
The authentication is successful, and PCM_OP_TERM_POL_AUTHORIZE is called to find session creation attributes.
As in the user model, attribute-value pairs are selected from the PIN_FLD_ARGS array in the /service/vpdn storable object, and merged into the attributes returned to the NAS.
The NAS uses the tunnel setup attributes and creates a tunnel through the appropriate gateway.
When a session starts and ends, the NAS also sends Accounting-Request requests to the RADIUS server, which passes these requests to BRM.
The requests cause an /event/session/dialup event to be created, which is then rated and charged to the account for company.com.
Most installations need to support both VPDN models. This section provides information and example solutions for supporting the two VPDN models. Both VPDN models can be implemented using the /service/ip or /service/vpdn storable object. However, using the /service/vpdn storable object is recommended because this allows the /service/ip storable object to support the /account dialup function.
The /service/vpdn storable object is designed to support your VPDN. Perform the following tasks to use the /service/vpdn storable object to support the organization model VPDN:
Verify that the /service/vpdn storable object is in your BRM schema.
If you are running BRM, the /service/vpdn storable object is installed when the system is first initialized.
Create price plans that incorporate the/service/vpdn storable object for creation of VPDN organization account. See Pricing Center Help for more information about creating plans.
Configure the mod_pin module instance in the RADIUS configuration file (BRM_home/apps/radius/config) to use the /service/vpdn storable object.
Configure the PIN_FLD_ARGS array in the /service/vpdn storable object for each organization mode VPDN account.
Combine the user and organization VPDN models in the RADIUS configuration file.
This example shows the syntax in the RADIUS configuration file for setting up the user model VPDN:
# Cannot find the account, see if the domain is
# a registered organization VPDN domain.
vpdn_auth {
type = mod_pin
check {
Pseudo-Request-Type = Access-Request
}
send (
Class = vpdn
}
service-type = /service/vpdn
login = Replace//*@// # authenticate against the domain
# name only
options = Ignore-No-Entry
}
# Rate the session under the organization account.
# Save the actual user name in description for reference.
vpdn_acct {
type = mod_pin
check {
Pseudo-Request-Type = Accounting-Request
Class = vpdn
}
service-type = /service/vpdn
login = Replace//*@// # record session against the
# organization account
desc = "%u"
}
To use the user and organization VPDN models together, put both models in the RADIUS configuration file (BRM_home/apps/radius/config). This example shows the RADIUS configuration file syntax for combining the user and organization model VPDN:
# Cannot find the account, see if it is a user_vpdn
user_vpdn_auth {
type = mod_pin
check {
Pseudo-Request-Type = Access-Request
User-Name = "*@*"
}
send (
Class = user_vpdn
}
service-type = /service/vpdn
options = Ignore-No-Entry
}
user_vpdn_acct {
type = mod_pin
check {
Pseudo-Request-Type = Accounting-Request
Class = user_vpdn
}
service-type = /service/vpdn
}
# ... some other modules ...
# Cannot find the account, see if the domain is
# a registered organization VPDN domain.
vpdn_auth {
type = mod_pin
check {
Pseudo-Request-Type = Access-Request
}
send (
Class = vpdn
}
service-type = /service/vpdn
login = Replace//*@//
# authenticate against the domain
# name only
options = Ignore-No-Entry
}
# Rate the session under the organization account.
# Save the actual user name in description for reference.
vpdn_acct {
type = mod_pin
check {
Pseudo-Request-Type = Accounting-Request
Class = vpdn
}
service-type = /service/vpdn
login = Replace//*@// # record session against the
# organization account
desc = "%u"
}