Chapter 11 Tailoring Your PPP Link

This chapter contains information you need to configure PPP links less commonly used than the basic links described in Chapter 9, Configuring PPP. The text includes instructions for configuring two types of PPP links: the dial-in server with dynamic point-to-point links and the virtual network, which uses multipoint links. The chapter concludes with tables listing all available keywords for the asppp.cf configuration file.

• "Addressing Issues for Dynamically Allocated Links"

• "Editing asppp.cf for Dynamic Link"

• "Addressing Issues for Virtual Networks"

• "asppp.cf Configuration File for a Virtual Network"

• "Editing asppp.cf for PAP/CHAP Security"

• "Configuration Keywords"

Configuring Dynamically Allocated PPP Links

A dial-in server with a dynamic point-to-point link gives your site all the advantages of point-to-point communications. Chapter 7, Understanding PPP, introduces this configuration type. It consists of remote hosts communicating with at least one dial-in server that dynamically allocates point-to-point links on an as-needed basis. The sample configuration shown in Figure 11-1 is used throughout this section.

Figure 11-1 Network of Remote Hosts and Dynamic Link Dial-in Servers

Each remote host communicates with the dial-in server using a standard point-to-point link. However, unlike the multipoint dial-in server in Figure 9-1, dial-in server mojave connects to a calling host over a dynamic point-to-point link. The server allocates an available link whenever a remote host attempts to establish a connection.

The idea behind a dynamic link is that the server provides the client with an IP address each time a connection is established. When the connection is established, the server allocates an available IP interface to the client. The remote IP address of the interface then becomes the client's IP address for the duration of the connection. When the connection is terminated, the IP interface is returned to the pool of available interfaces, ready to be used for another connection.

You use the same generic procedures for configuring dynamic links as you do for the remote host-to-multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the dynamic point-to-point link has its own set of issues and requires slightly different modifications to the files involved in configuration.

Addressing Issues for Dynamically Allocated Links

You must add host information to the /etc/inet/hosts file for each machine that use the dynamically allocated PPP link. The IP addresses for the PPP endpoints should follow these conventions:

• For the dial-in server, you must use the IP address of the server's primary network interface (for example le0 or smc0) as the address of the dynamic link.

• For a dynamic link, you don't need to assign an IP address to each remote host (as you would for a static link), but you do need to assign a remote IP address to each point-to-point IP interface on the server. The number of IP interfaces you can use is equal to the number of modems your server is connected to. For example, if you have three modems, you need three point-to-point IP interfaces and three IP addresses

• You must include a dummy IP address for the ifconfig command to work properly on the client. This address acts as a placeholder for the local IP address assigned to the client IP interface when PPP is started.

There are no restrictions on the remote IP addresses that can be assigned to the IP interfaces, but, for clarity, it is probably best to include only IP addresses belonging to the same subnet.

Updating the hosts Database for Dynamic Links

You must update the hosts database on all machines involved in the dynamic-link configuration.

How to Update a Remote Host

When configuring the hosts databases on the remote machines, do the following:

1. Add to the /etc/inet/hosts file the IP address and host name of the primary network interface for each dial-in server on the other end of the link.

   For example, in Figure 11-1, the /etc/inet/hosts file for nomada, nomadb, and nomadc should each include the IP address of the primary network interface of the dial-in server mojave.

2. Add the dummy IP address.

   This IP address is used only when PPP is started.

   The /etc/inet/hosts file on nomadc might look like:

   # Internet host table # 127.0.0.1 localhost loghost 192.41.40.55 mojave 1.2.3.4 dummy

3. Add to the /etc/inet/hosts file the IP addresses of all machines on the dial-in server`s physical network that the remote host can remotely log in to.

4. Update the databases on any name server on the physical network with the host names and IP addresses of the remote hosts.

How to Update the Dial-in Server

You do not have to add any PPP-specific address to the hosts database for the dial-in server. The dynamically allocated link must use the server's primary network interface. Therefore, when configuring the hosts database for the dial-in server, do the following:

1. Add entries to the server's /etc/inet/hosts files for each remote host served.

2. Add to the /etc/inet/hosts files of every machine on the physical network entries for any remote hosts they are permitted to communicate with.

Considerations for Other Files

The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.

Editing asppp.cf for Dynamic Link

The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.

Remote Host with Dynamic Link

The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:

ifconfig ipdptp0 plumb dummy mojave up
path
    interface ipdptp0
    peer_system_name mojave-ppp
    connectivity_timeout 300
    negotiate_address on

The negotiate_address parameter indicates whether or not local IP address assignment is obtained through negotiation and assigned dynamically. If set to on, the IP address supplied by the server is used as the client's local address for the duration of the connection.

Dial-in Server With Dynamic Link

When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 11-1 does not contain an interface keyword. Instead, the link manager uses interface information established in the defaults section.

The asppp.cf configuration file for a dial-in server with dynamically allocated links might resemble Example 11-1:

Example 11-1 Configuration File for Server With Dynamically Allocated Link

ifconfig ipdptp0 plumb mojave clienta down
ifconfig ipdptp1 plumb mojave clientb down
ifconfig ipdptp2 plumb mojave clientc down

# This means grab whatever interface is available (not in use)
defaults
	    interface ipdptp*

# Each path specifies a machine that might dial up / log
# in to this server

path
    peer_system_name tamerlane   # nomada uses the login name
                                 # tamerlane
	   
path
    peer_system_name lawrence    # nomadb uses the name lawrence
                                 # for login
    
path
    peer_system_name nomadc   

ifconfig Section for Server With Dynamic Links

The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:

ifconfig ipdptpn plumb server-name client-address down

Example 11-1 contains three ifconfig lines, each initializing a point-to-point interface.

ifconfig  ipdptp0  plumb  mojave  clienta  down
ifconfig  ipdptp1  plumb  mojave  clientb  down
ifconfig  ipdptp2  plumb  mojave  clientc  down

defaults Section for Server With Dynamic Links

When you configure a dynamically allocated link, you might want to include a defaults section in the asppp.cf file. This section sets the defaults for the value replacing keyword, wherever keyword subsequently appears in the asppp.cf file. The syntax for the defaults section is:

default 
     keyword

Example 11-1 uses the keyword interface to define the interface as ipdptp*, indicating a dynamic link. The asterisk wildcard tells the link manager to use any available ipdptp interface defined in the ifconfig section. Thus the link manager on server mojave uses either ipdptp0, ipdptp1, or ipdptp2--whichever is the first interface configured "down" that it finds.

path Section for Server With Dynamic Links

The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax: .

path
    peer_system_name endpoint-username    

No interface keyword has been defined in the path section because this value is defined in the defaults section.The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".

Configuring a Virtual Network

Virtual networks consist of a group of standalone computers, each in an isolated location, that can connect to each other through PPP multipoint links. "Virtual Networks" introduces virtual network concepts. This section explains how to configure a virtual network.

Figure 11-2 Sample Virtual Network

The network shown in Figure 11-2 consists of three isolated computers. Each member of the network connects to the other members of the network through a multipoint PPP link. Therefore, to create such a network, you (and perhaps other network administrators at the remote location) have to configure a multipoint PPP link on each participating host.

You use the same generic process for configuring multipoint links as you do for configuring a multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the virtual network has its own set of issues and requires you to configure each host in the network accordingly.

Addressing Issues for Virtual Networks

You must add host information to the /etc/hosts file for each machine in the virtual network. When typing the IP addresses used for the PPP endpoints:

• Designate a PPP-specific IP address for its point-to-point link. Note that if the machine was not previously configured in a physical network, you must create an IP address for the PPP link. This address becomes the host's primary network interface.

• Create a network number for the virtual network. See "Assigning a Network Number to the PPP Link" for more information.

Updating hosts and networks Databases

The first step in the configuration process involves updating the hosts and networks databases with information about your virtual network.

/etc/inet/hosts File for the Virtual Network

The /etc/inet/hosts file on each machine must contain the addressing information for every member of the network that this host has permission to access. For example, each host in the network in Figure 11-2 would have this information:

# Internet host table
#
127.0.0.1           localhost	loghost
192.41.47.15        nomada
192.41.47.20        nomadb
192.41.47.12        nomadc

/etc/inet/networks File for the Virtual Network

Since the virtual network requires a unique IP address, you must type this address in the networks database. For example, the network shown in Figure 11-2 has the number 192.41.47. Moreover, if the hosts on the network need to communicate with other networks, you should register the network with the InterNIC addressing authority. See Chapter 4, Configuring TCP/IP on the Network, for information on editing the networks database.

Each host on the virtual network must have an entry with the network's address in the /etc/inet/networks file. For example, each host on network 192.41.47 might have the following in /etc/inet/networks:

# Internet networks
#
# arpanet   10          arpa
# ucb-ether 46          ucbether
#
# local networks
loopback    127
ppp         192.41.47   #remote sales offices

Considerations for Other Files

The next steps in the configuration process involve editing the UUCP databases, the /etc/passwd file, and the /etc/shadow file. You edit these files for the machines in the virtual network just as you would for the multipoint dial-in server configuration. Refer to "Editing UUCP Databases" for UUCP-related information and "Modifying the /etc/passwd File" for information regarding the passwd file.

asppp.cf Configuration File for a Virtual Network

The configuration file for a local machine on a virtual network must contain information about all remote hosts on the network that the local host can access. Moreover, each machine on the virtual network must be configured for both dial-in and dial-out functions. After the local machine boots, its link manager reads the asppp.cf file to establish communications.

Example 11-2 shows a configuration file such as you would set up for nomada on a virtual network 192.41.47.

Example 11-2 Configuration File for nomada

# /etc/asppp.cf for hosta

ifconfig ipd0 plumb nomada netmask + up
defaults
   interface ipd0
path
   peer_ip_address  nomadb
   peer_system_name lawrence	   	# name machine logs in with
path
   peer_ip_address nomadc
   peer_system_name azziz

Example 11-3 shows a configuration file such as you would set up for nomadb on virtual network 192.41.47.

Example 11-3 Configuration File for nomadb

# /etc/asppp.cf for nomadb

ifconfig ipd0 plumb nomadb netmask + up
defaults
   interface ipd0
path
   peer_ip_address   nomada
   peer_system_name  tamerlane  # name the machine logs in with
path
   peer_ip_address   nomadc
   peer_system_name  azziz

Editing asppp.cf for PAP/CHAP Security

You can edit the asppp.cf file to establish security and to specify whether parts of the link will respond to Password Authentication Protocol (PAP), or Challenge-Handshake Authentication Protocol (CHAP),as described in "PPP Security". The asppp.cf file is edited by adding a series of keywords. In this section, authenticator is the system starting the link or challenge, and is frequently the server. Peer is the other end of the link, and is often the client.

The keywords to be added are require_authentication and will_do_authentication. The authenticator or server generally require authentication and the peer or client generally do authentication.

How to Install PAP/CHAP

1. On the server, become superuser and prepare to edit the /etc/asppp.cf file.

2. Add the require_authentication keyword for each machine on the link to use either CHAP or PAP security.

   1. For each pap keyword add an associated pap_peer_id and pap_peer_password string.

   2. For each chap keyword add an associated chap_peer_secret and chap_peer_name string.

      You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found in Example 11-4.

3. On each remote host on the link to use either PAP or CHAP security, add an entry in the remote host's /etc/asppp.cf file with the will_do_authentication keyword.

   1. For each pap keyword entry add an associated pap_id and pap_password string.

   2. For each chap keyword entry add an associated chap_secret and chap_name string.

You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found starting with Example 11-4.

Rules for PAP/CHAP Keywords

• Either server or client can require authentication or offer to do authentication.

• If PAP and CHAP are both present, the authenticator first tries CHAP. If that fails, the link is terminated. The authenticator will not try PAP.

• The default value for PAP and CHAP authentication keywords is off. The syntax for keywords is:

  require_authentication off | pap[chap] | chap[pap] will_do_authentication off | pap[chap] | chap[pap]

• If you fail to specify pap_id and pap_password or pap_peer_id and pap_peer_password keywords and values for the associated path, the corresponding values are set to the NULL string.

• You must specify chap_name,chap_secret, chap_peer_secret and chap_peer_name keywords and values for that path.

PAP/CHAP Examples

Example 11-4 shows the asppp.cf file for the server mojave with PAP and CHAP authentication required. The peers are nomada (PAP) and nomadb (CHAP).

Example 11-4 Code Example for Server mojave

ifconfig ipdptp0 plumb mojave nomada up
ifconfig ipdptp1 plumb mojave nomanb up
path
      peer_system_name tamerlane
      require_authentication pap  #tells nomada that mojave
                                  #requires pap authentication
      pap_peer_id desert
      pap_peer_password oasis
path
      peer_system_name lawrence
      require_authentication chap  #tells nomadb that mojave
                                   #requires chap authentication
      chap_peer_name another\sdesert
      chap_peer_secret secret\soasis\swith\007bell

Example 11-5 sample shows mojave's remote host nomada offering to do both PAP and CHAP authentication.

Example 11-5 Code Example for Remote Host nomada

ifconfig ipdptp0 plumb tamerlane mojave up
path
      interface ipdptp0
      peer_system_name mojave
      will_do_authentication chap pap #nomada tells mojave
                                      #that it will do chap and
                                      #pap authentication
      pap_id desert
      pap_password oasis
      chap_name desert\srain
      chap_secret %$#@7&*(+|`P'12

Example 11-6 shows mojave's remote host nomadb offering to do CHAP authentication.

Example 11-6 Code Example for Remote Host nomadb

ifconfig ipdptp0 plumb nomadb mojave private up
path
     interface ipdptp0
     peer_system_name mojave
     will_do_authentication chap   #nomadb tells mojave that it
                                   #will do chap authentication
     chap_name another\sdesert
     chap_secret secret\soasis\swith\007bell

Ideally, both CHAP and PAP are included in the configuration file, with the server requiring authentication and the remote host willing to do authentication. However this is reversible so that either side can require authentication. CHAP secrets need to be delivered by secure means. This generally involves handing them over in person.

Configuration Keywords

This section describes the configuration keywords available for the asppp.cf configuration file and the values you must define for them. Most of these keywords are optional. The required ones are indicated. For further explanations of the keywords, refer to RFCs 1331, 1332, 1333, and 1334.

Table 11-4 lists required keywords that must appear in all asppp.cf configuration files.

Table 11-5 contains optional keywords for asppp.cf that you can use to further define your PPP configuration.