DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring the Point-to-Point Protocol (PPP)

Incoming PPP over modems and ISDN

``A typical incoming PPP configuration for remote access'' shows a typical configuration of the bundles and link devices that would be used to configure incoming PPP connections to a system which is acting as a remote access server.

A typical incoming PPP configuration for remote access

One or more of the following methods may be used to authenticate an incoming user:


NOTE: The global bundle defines whether all incoming users are authenticated using CHAP or PAP. If both protocols are specified, CHAP is used in preference to PAP.

CHAP is generally used to authenticate incoming users who are using PPP under Microsoft Windows. PAP can be used instead if they have configured PPP not to use encrypted passwords. Authentication by logging in can be used if they have installed ``SLIP and Scripting for Dial-Up Networking'' and they have configured a suitable chat script. See ``Interoperating with PPP in Microsoft Windows'' and pppauth(7) for more details.


In this example, the global bundle specifies that CHAP is to be used to authenticate incoming users.


NOTE: It is possible to configure the global bundle so that the name in transmitted CHAP challenge and PAP response packets is overridden. If you maintain several remote access servers at a site, this allows you to create a uniform challenge so that incoming users will be unaware that there is more than one server.

Several bundles are shown for incoming users on analog lines to a bank of modems. Each modem is defined as a separate link device. Each bundle defines all of the modems as potential link devices that an incoming user may use and it also specifies the authentication ID of the incoming user as the wildcard ``*''. In effect the incoming user is anonymous to the bundle. Any user dialing into the modem bank can set up a PPP link between their system and the remote access server provided that they can be successfully authenticated against their entry in the authentication database.

If users log in to authenticate themselves, you can also specify the ``*'' wildcard as the permitted login user name for a bundle.


WARNING: As the PPP link that is set up for each incoming user uses up one bundle, you should configure at least as many anonymous bundles as there are link devices available for remote access. Otherwise, the number of incoming users who will be able to set up incoming PPP links will be limited by the number of bundles rather than the number of devices.

If a PPP user sometimes needs to log in on a local terminal using a login shell such as ksh, the Callservices(4bnu) file on the remote access server should contain entries to start the PPP shell, pppsh(1M), for the serial ports or ISDN devices which the user will use for remote access. You can use the Dialin Services Manager to configure entries in the Callservices file. You can use Account Manager to configure a user's login shell.

``An alternative incoming PPP configuration for remote access'' shows another possible bundle and link device configuration for incoming PPP connections.

An alternative incoming PPP configuration for remote access

This example differs from the previous configuration in that every incoming user (tim, june and so on) has been assigned their own bundle. This is the type of configuration that you can create using the PPP Incoming Connection Wizard. Such a configuration is useful if you want to tailor incoming service to each user's requirements. It also allows you to suspend service for a user by disabling their individual bundle.

When an incoming call is received, the bundle to be used is identified by the user's authentication ID, caller ID, and/or login name, and by the link device on which the incoming call was received.

A PPP link will only be set up if a bundle can be found that matches the user and the link device. This allows you to control access to reserved services and devices such as multilink PPP over ISDN as shown in ``An incoming PPP configuration with controlled remote access''.

An incoming PPP configuration with controlled remote access

In this example, the users tom and mary are configured in a special bundle that allows them to use multilink PPP over both B channels when dialing into an ISDN BRI terminal adapter.


NOTE: Each B channel is represented by a separate link device in each of its configured modes of operation (synchronous and/or V.120 asynchronous).

All other users are matched by a single anonymous bundle which restricts them to using at most one channel and also allows access to only one of them at a time. Either tom or mary will also be able to connect using the anonymous bundle if the other has already taken the bundle in which they are named. This makes sense because if one channel is already taken, there is only one left for another user to obtain a connection.

The ability to use multilink PPP is restricted by the availability of the second channel. For example, if tom is already using one channel, he will be unable to use the other channel for multilink PPP if mary or another user has subsequently grabbed it. Conversely, while tom or mary is using both channels for multilink PPP, no other user will be able to obtain a PPP connection.


© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004