MultiNet V5.1 Install & Admin Guide

Chapter 11

This chapter explains how to establish IP connectivity between your computer and other computers on your network. Connectivity depends upon the network interfaces in your system.

Establishing IP connectivity ensures that users can perform the tasks described in the MultiNet for OpenVMS User's Guide, including:

• Obtaining information about remote systems and users with FINGER and WHOIS

• Accessing files on other computers with the FTP, RCP, TFTP, SCP, and SFTP commands

• Logging into other computers with the RLOGIN, TELNET, and SSH commands

• Using remote printers

Note! Establishing IP connectivity only ensures you can reach other systems if you know their IP addresses. It does not ensure you can reach other systems by name. For example, there is no guarantee you can send mail to users on remote systems without first configuring host tables or the Domain Name System (DNS) (see Chapter 10).

At startup, MultiNet obtains global configuration data (such as the default route) and device-specific network interface configuration data (such as the IP address) from the following files:

• The MULTINET:NETWORK_DEVICES.CONFIGURATION network database file describes the current network configuration, including a list of the device interfaces you have specified. This file is used to determine which devices are present when the network is started.

• The MULTINET:START_MULTINET.COM network initialization command procedure starts and configures the network, and initializes individual device interfaces and global parameters. This file is overwritten each time you use NET-CONFIG to update and save the configuration.

This chapter describes how to modify the startup command procedure and configuration file with NET-CONFIG or MENU-CONFIG and related steps required to ensure successful configuration. For details on using these configuration utilities, see Chapter 9.

Note! Network interface configuration changes take effect the next time your system reboots. In contrast, most global parameter changes do not require rebooting.

Some network interfaces require configuration data that is not accessible through either NET-CONFIG or MENU-CONFIG. When configuring such interfaces, additional configuration files are required. For details, see the Creating a Custom Interface Initialization Procedure section.

MultiNet allows you to configure multiple interface devices on your network. Each interface is named according to its type (for example, shared Ethernet interfaces are of the type "se").

In general, MultiNet accommodates a maximum of ten devices of each type. Table 11-1 lists the devices MultiNet supports and the interface names to use when specifying devices to be added or modified.

Table 11-1 Supported Network Interface Devices (Continued)

MultiNet contains a driver for each of these device types. The driver either accesses the device directly or is an interface to an appropriate OpenVMS device driver.

The IF_IP interface for IP-over-IP tunneling generally used with encrypted logins is now part of the standard distribution. The encryption code must be obtained separately and is subject to United States export restrictions. See Chapter 1 for information on contacting Process Software.

There are two ways to view the currently configured network interfaces:

• Using the NET-CONFIG SHOW command

• Using the MENU-CONFIG Show All Network Interfaces command

You can use the NET-CONFIG SHOW command to display the maximum configuration or the current configuration.

Use the following command to display all interface types supported by MultiNet are displayed, including the default settings for the Adapter, CSR, Flags, and Vector parameters:

For example:

Use the following command to display global parameter settings and device interfaces currently in your network configuration (including the actual settings for Adapter, CSR, Flags, and Vector):

NET-CONFIG>SHOW [CURRENT]

For example:

The SHOW command with no parameters defaults to SHOW CURRENT.

To view the current interface configuration with MENU-CONFIG:

1 Start MENU-CONFIG:

$ MULTINET CONFIGURE /MENU

The main MENU-CONFIG menu appears.

2 Choose Configure Network Interfaces. The Network Interface Configuration Menu appears. see graphic

3 To view a specific network interface configuration, choose Show an Existing Network Interface, then the name of the interface you want to view. When you are done, press Ctrl/Z to return to the Network Interface Configuration menu.

4 To view all network interface configuration parameters, Choose Show All Network Interfaces. Use the up and down arrow keys to scroll through the interface configuration parameters. When you are done, press Ctrl/A to return to the Network Interface Configuration menu.

5 Press Ctrl/Z to return to the main MENU-CONFIG menu.

6 Quit MENU-CONFIG.

To add a new network interface to your MultiNet configuration, you can either:

• Use NET-CONFIG (see the Adding Network Interfaces with NET-CONFIG section).

• Use the Configure Network Interfaces command in MENU-CONFIG (see the Adding Network Interfaces with NET-CONFIG section).

For details about these utilities, see Chapter 9.

Table 11-2 lists all network interface parameters used by MultiNet-supported interfaces. Table 11-3 lists the parameters required by each type of interface.

The supported network devices can be classified into three categories that determine the parameters you enter when configuring the device:

• Hardware devices with which MultiNet communicates directly. For each of these devices, NET-CONFIG requires that you specify the CSR and the UNIBUS adapter into which the device is plugged. Most of the devices also require you to specify device-specific parameters.

Some of these devices have programmable interrupt vectors that you specify with NET-CONFIG; MultiNet programs these vectors during startup. Others have interrupt vectors that are determined by the hardware. For each of these devices, set the vector and the CSR on the hardware using the DIP switches or jumpers on the card as described in the device's manual. As described in Table 11-2, each interrupt vector must be unique.

• Hardware devices through which MultiNet communicates using a VMS device driver. For these devices, NET-CONFIG requires that you identify the VMS device through which MultiNet is to communicate; for most of these devices, you must also specify device-specific parameters.

• Software, or pseudo, devices whose interfaces communicate with software and for which no hardware is directly associated. These interfaces are typically used to implement special-purpose transports and deliver packets to other software. For example, the IP-over-DECnet interface encapsulates IP packets in DECnet datagrams for transmission over a DECnet network. All parameters for these devices are device-specific.

Table 11-2 lists the prompts that appear when you run NET-CONFIG. Make sure you respond to at least one network address prompt so the device can be started from the boot process. Table 11-3 lists the prompts displayed for each device type.

Table 11-2 Network Interface Parameters (Continued)

If your network requires a network interface to be initialized with parameters other than those listed in Table 11-2, create a custom initialization command procedure as described in the Creating a Custom Interface Initialization Procedure section.

Table 11-3 Interfaces and Parameters (Continued)

You can display the current interrupt vector used by VMS by invoking the SYSGEN utility, then using the SHOW /CONFIGURATION command, as follows:

$ MCR SYSGEN
SYSGEN>SHOW/CONFIGURATION

You can also display the maximum device configuration and the vectors currently used by MultiNet by invoking NET-CONFIG as shown in the Viewing Interface Configuration with NET-CONFIG section.

To add an interface to the configuration:

1 Start NET-CONFIG:

$ MULTINET CONFIGURE /INTERFACES

2 At the NET-CONFIG prompt, enter:

NET-CONFIG>ADD interface_name

interface_name is a name from Table 11-1.

Do not use an interface name currently in use; to modify an existing interface, see the Modifying Network Interfaces section.

For example, to add a third shared Ethernet (se) interface to your network configuration, enter: NET-CONFIG>ADD SE2

NET-CONFIG prompts you for interface parameter values required by the interface_name interface.

3 Enter interface configuration parameter values at each NET-CONFIG prompt. For descriptions of the required parameters for your network interface, refer to Table 11-3.

4 When the NET-CONFIG prompt returns, verify the validity of the new interface configuration with the CHECK command.

5 If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine the cause of the error. To correct the error, modify the configuration as described in the Modifying Network Interfaces section or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.

6 If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.

Your changes take effect the next time your system reboots.

$ MULTINET CONFIGURE
MultiNet Network Configuration Utility 5.1(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>ADD SL0
[Adding new configuration entry for device "sl0"]
VMS Device [TTA0] TTA2
Baud Rate: [UNSPECIFIED]
Header Compression Mode: [DISABLED]
IP Address: [NONE] 196.22.19.1
Point-To-Point Device IP Destination Address: [NONE] 196.22.19.2
IP SubNet Mask: [NONE]
[sl0 (Serial Line IP): Csr=NONE, Flags=%X0]
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
$

To add an interface to the configuration:

1 Start MENU-CONFIG. The main MENU-CONFIG menu appears.

2 Choose Configure Network Interfaces. The Network Interface Configuration Menu appears.
see graphic

3 Choose Add a Network Interface. The Network Interfaces Types menu appears.

4 Choose the network interface type you want to add.

Note! If your network adapter type does not appear in this menu, switch to Extended mode by pressing PF1 and choosing an item from the extended menu.

MENU-CONFIG prompts you for the unit number of the interface you chose.

5 Enter the desired unit number, or press RETURN to accept the default. The default unit number is the next available number. The Add Interface screen appears.

6 Enter values for the interface configuration parameter. For descriptions of the required parameters for your network interface, refer to Table 11-3.

7 When done, press Ctrl/Z to return to the Network Interface Configuration menu. When MENU-CONFIG prompts you to save the configuration, enter YES or NO as needed.

Responding YES at this prompt only preserves your changes in MENU-CONFIG; it does not save the configuration file.

8 To save your network interface configuration changes and return to the main menu, choose Save Changes and Return to Previous Menu.

To abandon your changes, choose Abandon Changes and Return to Previous Menu.

9 Quit MENU-CONFIG.

Your changes take effect the next time your system reboots.

If your network requires that a device be initialized with parameters not supported by NET-CONFIG, you can create a custom initialization command procedure for the device. At network startup, MultiNet uses this file instead of the commands for the device in the MULTINET:START_MULTINET.COM file.

The device must already be part of the network configuration, and commands to its interface must already exist in the MULTINET:START_MULTINET.COM file. To change the device's initialization, create a command file using a text editor:

1 Create a file named MULTINET:interface_CONFIGURE.COM,

interface is an interface in your configuration.

2 Copy the section of MULTINET:START_MULTINET.COM containing the initialization commands into the new file.

3 Edit the new file to specify the new initialization.

There are two ways to modify network interfaces in your MultiNet configuration:

• Using NET-CONFIG (see the Modifying Network Interfaces with NET-CONFIG section)

• Using the MENU-CONFIG Configure Network Interfaces command (see the Modifying Network Interfaces with MENU-CONFIG section)

For details on using these utilities, refer to Chapter 9.

Table 11-2 lists the network interface parameters used by MultiNet-supported interfaces. For the parameters required by each type of interface, refer to Table 11-3.

To modify the configuration of an existing interface:

1 Start NET-CONFIG:

$ MULTINET CONFIGURE /INTERFACES

2 At the NET-CONFIG prompt, enter:

NET-CONFIG>MODIFY interface_name

interface_name is the name of the network interface you want to modify.

For example, to modify the third shared Ethernet interface in your network configuration, enter:

NET-CONFIG>MODIFY SE2

NET-CONFIG prompts you for interface parameter values required by the specified interface.

3 Enter interface configuration parameter values at each of the NET-CONFIG prompts. For descriptions of the required parameters for your network interface, refer to Table 11-3.

4 When the NET-CONFIG prompt returns, verify the validity of the new interface configuration with the CHECK command.

5 If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine what is causing the error. Correct the error by repeating from Step 2, or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.

6 If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.

Your changes take effect the next time your system reboots.

To modify the configuration of an existing interface:

1 Start MENU-CONFIG. The main MENU-CONFIG menu appears.

2 Choose Configure Network Interfaces. The Network Interface Configuration Menu appears. see graphic

3 Choose Modify an Existing Network Interface. The Interface Selection Menu appears, listing the names of currently configured interfaces.

4 Choose the network interface type you want to modify. The Modify Interface screen appears.

5 Enter values for the interface configuration parameter. For descriptions of the required parameters for your network interface, refer to Table 11-3.

6 When done, press Ctrl/Z to return to the Network Interface Configuration menu. When MENU-CONFIG prompts you to save the configuration, enter YES or NO as needed.

Responding YES at this prompt only preserves your changes in MENU-CONFIG; it does not save the configuration file.

1 To save your network interface configuration changes and return to the main menu, choose Save Changes and Return to Previous Menu.

To abandon your changes and return to the main menu, choose Abandon Changes and Return to Previous Menu.

2 Quit MENU-CONFIG.

Your changes take effect the next time your system reboots.

There are two ways to delete network interfaces from your MultiNet configuration:

• NET-CONFIG (see the Deleting Network Interfaces with NET-CONFIG section)

• MENU-CONFIG Configure Network Interfaces command (see the Deleting Network Interfaces with MENU-CONFIG section)

For details on using these utilities, refer to Chapter 9.

Use NET-CONFIG to delete one or all interfaces from the current configuration:

1 Start NET-CONFIG:

$ MULTINET CONFIGURE /INTERFACES

2 At the NET-CONFIG prompt, enter:

NET-CONFIG>DELETE interface_name

interface_name is the name of the existing network interface you want to delete.

For example, to delete the third shared Ethernet interface in your network configuration, enter:

NET-CONFIG>DELETE SE2

3 When the NET-CONFIG prompt reappears, verify the validity of the new interface configuration with the CHECK command.

4 If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine the cause of the error. Correct the error by repeating from Step 2, or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.

5 If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.

Your changes take effect the next time your system reboots.

To delete a specific interface from your configuration:

1 Start MENU-CONFIG. The main MENU-CONFIG menu appears.

2 Choose Configure Network Interfaces. The Network Interface Configuration Menu appears. see graphic

3 Choose Delete a Network Interface. The Interface Selection Menu appears, listing the names of currently configured interfaces.

4 Choose the network interface type you want to modify. MENU-CONFIG confirms that it has deleted the interface.

5 Press RETURN to return to the Network Interface Configuration menu.

6 To verify that the interface has been deleted, choose Show All Network Interfaces.

7 To save or abandon your network interface configuration changes and return to the main menu, choose Save Changes and Return to Previous Menu or Abandon Changes and Return to Previous Menu (respectively).

8 Quit MENU-CONFIG.

Your changes take effect the next time your system reboots.

You can disable and re-enable interfaces individually. If you disable a device, it is not configured when the network is started.

To disable a device, use the DISABLE command; for example:

NET-CONFIG>DISABLE SE0

To re-enable a device, use the ENABLE command; for example:

NET-CONFIG>ENABLE SE0

Sometimes it is necessary to assign multiple IP addresses to a single physical interface; for example, when multiple subnets or networks are running on a single network segment.

You do this by using a pseudo device interface (pd). Use NET-CONFIG to add the device as you do other devices (such as se devices). This MultiNet release supports up to 500 pseudo device interfaces. Instead of specifying the OpenVMS device name, however, specify the MultiNet name for the interface (for example, se0). You must reboot the system after adding the pseudo device.

CAUTION! Careless assignment of a secondary address can cause network problems. In general, you should assign pseudo devices (pd) addresses on the same network or subnet as the se device to which the pd device is linked.

If the pd interface is not in the same IP network as its associated se interface, some TCP/IP packages (such as early versions of SunOS) retransmit broadcast packets for the other IP network back to the network segment from which they were transmitted. This can cause network storms.

Note! Some services listen to traffic on se interfaces only and ignore traffic on pd interfaces. One such service is the RIP listener in GATED.

The following example shows how to add a pseudo device:

$ MULTINET CONFIG
MultiNet Network Configuration Utility 5.1
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SHOW
Interface Adapter CSR Address Flags/Vector
--------- ------- ----------- ------------
se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-|
[TCP/IP: 161.44.128.20, IP-SubNet: 255.255.255.0]
[NETWARE: A12C8000:0.0.0.0.0.0, Link Level: Ethernet]
[VMS Device: ESA0, Link Level: Ethernet]
|
Official Host Name: lobo.process.com
NETWARE Host Name: LOBO
Domain Nameservers: 127.0.0.1
Timezone: EST
Timezone Rules: US/EASTERN
Load EXOS $QIO driver: TRUE
Load UCX $QIO driver: TRUE
Load PWIP (Pathworks) driver: TRUE
Nameserver Retrans Timeout: 9 (6 Retries)
WHOIS Default Server: rs.internic.net
NET-CONFIG>ADD PD0
[Adding new configuration entry for device "pd0"]
Hardware Device: [NONE] SE0
IP Address: [NONE] 161.44.128.21
IP SubNet Mask: [NONE] <Return>
Non-Standard IP Broadcast Address: [NONE] <Return>
[pd0 (Secondary Ethernet Address): Csr=NONE, Flags=%X0]
NET-CONFIG>SHOW

Interface Adapter CSR Address Flags/Vector
--------- ------- ----------- ------------
se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-
[TCP/IP: 161.44.128.20, IP-SubNet: 255.255.255.0]
[NETWARE: A12C8000:0.0.0.0.0.0, Link Level: Ethernet]
[VMS Device: ESA0, Link Level: Ethernet]
pd0 (Secondary Ethernet Address) -NONE- -NONE- -NONE-
[TCP/IP: 161.44.128.21]
[Hardware-Device: se0]
Official Host Name: lobo.process.com
NETWARE Host Name: LOBO
Domain Nameservers: 127.0.0.1
Timezone: EST
Timezone Rules: US/EASTERN
Load EXOS $QIO driver: TRUE
Load UCX $QIO driver: TRUE
Load PWIP (Pathworks) driver: TRUE
Nameserver Retrans Timeout: 9 (6 Retries)
WHOIS Default Server: rs.internic.net
NET-CONFIG>EXIT

Packet filtering is used today in almost all (from basic to sophisticated) security firewalls. Packet filtering firewalls apply filtering rules to each packet received to determine whether to accept or discard it. These filtering rules specify the protocol, source and destination IP addresses, and destination ports (for TCP and UDP) for accepted or discarded packets.

You use packet filtering on routers between an internal network and one or more external networks (such as a connection to the Internet). Packet filter rules restrict what may come in through the interface connected to the external network.

Packet filtering can also be useful on hosts. For example, you can restrict the hosts that are allowed access to services. In particular, these are UDP-based services and services that the MultiNet master server does not activate, and thus cannot use incoming access restrictions.

MultiNet's packet filtering support is similar to that which many routers provide. Once you create a file containing the packet filter rules and load it for an interface, any IP datagrams received on that interface are filtered before being processed or forwarded.

Note! When you use packet filtering, each and every datagram received on the interface is filtered. This increases processing overhead depending on the size of the filter list.

Packet filtering can be an effective and useful security mechanism. However, it cannot solve all your security problems. To be effective, you must construct the filtering rules carefully.

Observe the following cautions when setting up packet filtering on an interface:

• Packet filtering does not use state information. Each datagram is filtered without any knowledge of packets that preceded it. This means that for UDP-based applications, it is not possible to add a rule that says to accept replies to requests. This also affects connection-oriented protocols, such as FTP, that use two connections: one for commands and the other for data.

• Fragmented datagrams for UDP or TCP are difficult to filter, since only the first fragment has the necessary port information. MultiNet solves this problem by applying the filter rules to only the first fragment of UDP and TCP datagrams. The other fragments are accepted and processed or forwarded, but are eventually discarded because they cannot be reassembled without the first fragment. For all other IP protocols, the filter rules apply to each fragment.

• To set up secure packet filtering lists, you need detailed knowledge of IP, ICMP, TCP, UDP and applications protocols.

Suggested reading includes the protocol RFCs (listed elsewhere in the MultiNet documentation) and books such as Cheswick, William R. & Steven M. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker.

Packet filtering uses a filter list to determine whether you can receive a datagram. Filter lists are in packet filter files having the .DAT extension by default. Create one of these files first and then edit the file using the formats described in the following table.

Table 11-4 Fields in a Packet Filter Entry (Continued)

Each entry specifies a packet filtering condition for a particular protocol type, source or destination address and mask, and destination port and mask specification, with certain additional options. The system looks at each condition in sequence, looks for a match, and takes a permit (accept) or deny (reject) action. The system stops testing conditions after the first match. This means that the order of the entries in the file is important; if the file lists a subsequent condition for an address, the system ignores it.

An implicit deny terminates the list of entries in the packet filter file. This means that if no condition matches, the system rejects the datagram. To use packet filtering:

1 Create address list entries in the packet filter file.

2 Apply the list to interfaces on your system by using packet filtering commands.

To create a packet filter file, edit a file and add address list entries in the format described.

Any number of spaces or tabs can separate each entity. Lines beginning with an exclamation point (!) are comment lines. You can use the dash (-) continuation character at the end of a line that needs to continue onto the next.

To apply the list to a particular network interface or interfaces on your system, use the MULTINET SET/INTERFACE/FILTER command, as described in MultiNet for OpenVMS Administrator's Reference.

Filters may be set to be activated only during a specified time period. These filters may be specified as a one-time filter or as a filter that repeats. For example, a filter may be set up to filter all traffic from a specific address during the hours of 5am to 5pm each day, or a filter may be specified that filters traffic starting from the time the filter is loaded and for the next 3 hours.

Time-based filtering is done by specifying a start time, an end time, or both start and end times for a filter in the filter definition file. For repeating filters, both start and end times must be specified. Note that all time values for start and end times must be specified in VMS absolute or delta time format. For example, the following are all valid:

Note that if an absolute time is specified that contains both a date and time (example 2 above), it MUST be enclosed by double quotes. For example:

deny icmp 0 0 0 0 eq 5 start 17:00:00 end "29-Sep-2003 6:00:00"

Given the following filter file (the dashes at the end of some lines are for readability only, and are not valid):

deny tcp 15.1.94.2 15.1.94.255 2.22.2.5 255.255.255.255 start 15:20 end 18:30 repeat
deny tcp 1.1.94.2 1.1.94.255 207.225.29.51 255.255.255.255 end
"1-JAN-2004 18:30" deny tcp 195.101.94.209 195.101.94.255 207.225.29.51 255.255.255.255 start
18:00 end "1 00:30" repeat
deny tcp 195.101.94.209 195.101.94.255 207.225.29.51 255.255.255.255
deny tcp 195.101.94.209 195.101.94.255 207.225.29.51 255.255.255.255 start 17:00 end 18:30
deny tcp 15.1.94.2 15.1.94.255 2.22.2.5 255.255.255.255 start "2 00:00" end 3 00:00"

Line 1 will filter from 15:20 to 18:30 each day.
Line 2 will filter from the time the filter is loaded through 18:30 on January 1, 2004
with no logging. After that time, if the filters are reloaded, this filter will not be loaded.
Line 3 will filter from 18:00 to 19:30 each day.
Line 4 has no time limits on it.
Line 5 will log from 17:00 through 18:30 today.
Line 6 will filter starting 2 days from the time the filter is loaded, through 3 days after that.

Filter "hits" may be logged, either to OPCOM or to a file defined by the user. Logging is enabled on a filter-by-filter basis, by using the "log" keyword on the end of a filter definition line. For example:

deny tcp 192.10.9.209 192.10.9.255 207.225.29.51 255.255.255.255 log

Logging for the interface is controlled via the MULTINET SET/INTERFACE command. The actual logging is performed by the MULTINET_FLOG process, which is started the first time a MULTINET SET/INTERFACE /LOG command is issued (a single MULTINET_FLOG process handles logging for all interfaces defined on the system).

The MULTINET SET/INTERFACE command switches used to support logging are

When filter logging is enabled, the MULTINET_FLOG process will be started. This process checks each interface at the interval defined by the /INTERVAL qualifier for the MULTINET SET/INTERFACE command. As unlogged filter hits are found, it will log them to OPCOM or to a file, according on the parameters set by the /LOG and /FORMAT qualifiers for the MULTINET SET/INTERFACE command.

When logging to OPCOM, only NORMAL formatting is allowed. An OPCOM message, formatted as the filter output from MULTINET SHOW/INTERFACE /FILTER, will be displayed for each filter with unlogged hits on it.

When logging to a file, the output will be identical to that of the filter displays from MULTINET SHOW/INTERFACE /FILTER command, if /FORMAT=NORMAL is specified. If
/FORMAT=COMMA is specified, the data will be recorded as comma-delimited fields, one line per filter, to the file. The first line of this file will contain the field names (comma-delimited) to aid in interpreting the contents of the file.

Examples:

MULTINET SET /INTERFACE SE0 /LOG=OPCOM/INTERVAL=10

enables logging to OPCOM, with a reporting interval of 10 seconds.

MULTINET SET /INTERFACE SE0 /LOG=FOO.DAT/FORMAT=COMMA

enables logging to the file FOO.DAT in comma-delimited format, and a reporting interval of 5 seconds (the default).

MULTINET SET /INTERFACE SE0 /NOLOG

This disables all logging for the interface, closing all open log files.

Constructing an address filter list requires care in that you want to allow only the packets you need. Here are some recommendations in setting up an address filter list for an interface:

• Add an entry to prevent IP "spoofing"-having an external host send a datagram as if it came from a local machine. For a router, this makes sense because no datagram received from an external network should ever have a local source address. Add the following entry to the filter list for the external interface:

deny ip local-network local-network-mask

• Be careful with services that use "unprotected" port numbers (greater than 1024). Some examples are NFS (port 2049) and X Windows (port 6000 and higher). Explicitly denying these services is a good idea:

• Prevent broadcast and loopback packets from entering your network. It is best to restrict the broadcast (the first two of the following entries) to an external interface; apply the loopback restriction (the last entry) to any interface:

• Guard against datagrams from invalid source addresses when connected to the Internet (provided you are not using these network numbers for internal-only traffic purposes). Add the following to the filter list for the external interface:

• You generally need to allow domain name (DNS) requests using:

permit udp 0 0 eq 53 0 0

Whether to allow TCP DNS traffic (usually used for zone transfers) is also something to consider. To disallow TCP DNS traffic, add:

deny tcp 0 0 eq 53 0 0

• You should not be concerned with what services local users use in the external world. You would want to add:

permit tcp 0 0 0 0 gt 1023 established

This allows all TCP datagrams in to ports greater than 1023 that have either the ACK or RST bits set in the TCP flags. Connection establishment requests have just the SYN bit set, so they are not allowed by this entry.

You might want to drop the established option if you want to allow incoming connections to unprotected ports. This would allow use of the FTP PASV capability.

• You may offer services to the external world such as a World Wide Web or anonymous FTP server. Add the following entries:

If you have several hosts for each service, add an entry for each.

Note! For the FTP Server, the data connections are normally outgoing and thus the earlier permit tcp 0 0 0 0 gt 1023 established configuration works to allow these. However, if users switch to PASV mode, the connections will be incoming (to unprotected port numbers) and therefore the permit tcp 0 0 0 0 gt 1023 configuration (without the established option) might be more effective.

• Allow all ICMPs except ICMP redirects:

This is useful for informing hosts about problems. But it can open up denial of service attacks, especially if hosts are not careful about the ICMP redirects they accept. That is why discarding them is recommended.

• Watch the order of the entries in the table carefully.

This entry would not work since the permit entry allows the datagram and processing stops as soon as a match is found. MultiNet processes the entries in the order in which you specify them.

• Remember that an implicit "deny everything" is added to the end of the filtering list. This means that to permit a datagram, you need to have a permit entry in the list.

• Once you applied your filter list, test it first. Get an account on a host on an outside network that you can use to connect to your local hosts. Check that you are not allowing any access you do not want, and that you are allowing access that you do want. If something is not right, modify the filter list, reload it, and retest.

While packet filtering is very useful, it is by no means the only step you should take to secure your network. You must take special care to secure the system to assure that it cannot be compromised. One way to do this is to greatly limit the services it offers.

When you start MultiNet, the START_MULTINET procedure looks for a MULTINET:FILTER-interface.DAT file for each interface it starts. If the file exists, START_MULTINET issues the following command to set the filter list for the interface:

$ MULTINET SET/INTERFACE interface /FILTER=MULTINET:FILTER-line-id.DAT

You can also add the necessary MULTINET commands to the MULTINET:LOCAL_ROUTES.COM file.

If you want to know if filtering is enabled and what the settings are, use the MULTINET SHOW
/INTERFACE/FILTER SE0 command.

MultiNet also supports the use of a LOCAL_INITIALIZATION command procedure during startup. As with the MULTINET:LOCAL_ROUTES.COM file, you can put the necessary MultiNet commands in the MULTINET:LOCAL_INITIALIZATION.COM file to have them executed as MultiNet starts. For example:

$ MULTINET SET/KERNEL TCP_DONT_TSECHO 1

This section explains how to use MultiNet Secure/IP to solve security problems associated with user authentication systems.

Authentication is the process of proving that individuals or entities, known in computer security terms as principals, are who or what they say they are. Most network and dial-up computer systems require a user name and password for authentication before allowing access to the services they provide. Authentication helps protect computer systems and their users from access by individuals who are not authorized to use those systems.

Authentication systems require you to demonstrate one or more of three properties:

• Something you know

• Something you have

• Who you are

The more properties your authentication system requires, the more difficult it is for unauthorized users to access your system. Each property has both merits and associated problems.

On computer systems, plaintext passwords, which are in the first category (something you know), are the most common form of user authentication.

A common example of a secure user authentication is an Automatic Teller Machine (ATM), which requires both your ATM card (something you have) and your Personal Identification Number (something you know).

Currently, only the most secure computer systems depend on the third property, who you are. Such systems scan finger, palm prints, or retinal patterns to authenticate unique physical aspects.

While plaintext passwords are the most common form of authentication, they introduce serious security concerns in computer networks, particularly when systems are accessible from external networks, such as the Internet, or by modem from nearly any remote system.

One concern is that users often choose passwords that can be easily guessed. Random-password generators force users to choose hard-to-guess passwords. Another concern is that passwords, like their real-world analog, can be overheard. This problem actually poses the most significant security risk in existing networks. For example, in TCP/IP, LAT, and DECnet, plaintext passwords are generally sent "in the clear," which means any intermediate system or any system on the same network can "eavesdrop" and obtain them.

Kerberos user authentication, a standard feature in MultiNet, uses encryption to prevent information sent across the network from being of any use to potential intruders. In many organizations, Kerberos encryption addresses security concerns.

However, as the trend towards mobile computing increases, and users log in from many remote systems or networks, new security concerns arise.

If users log in from a non-secure remote system, there is the possibility of hidden, or disguised, attacks, in which client programs capture what you enter from the computer keyboard (specifically your password before it is encrypted) and save it for later use. This type of poor client security is less of a concern for laptop computer users, who have greater control over the software on their system and access to it.

Even if users have complete control over their Kerberized clients, Kerberos requires substantial centralized administration, which makes it increasingly difficult to manage in large and growing networks.

An increasingly popular solution to the network security problem is the use of non-repeating passwords, making it unimportant if intruders capture them. Users can obtain non-repeating passwords from hand-held devices, such as the CRYPTOCard, HP Pathways SNK card, and Security Dynamics SecurID Card, or with a software-based challenge and response system (Bellcore S/KEY).

Each of these systems uses a variation on the same approach to user authentication. MultiNet Secure/IP lets you take advantage of the similarities by providing a way to authenticate users using any of these systems. MultiNet Secure/IP provides a framework to which you can add support for new systems as they emerge.

MultiNet Secure/IP also supplies the tools that make it easier to program tokens and maintain user profiles.

The need for secure user authentication is greater when users attempt to log in from remote systems than when they log in from local systems. In fact, you may only want MultiNet Secure/IP authentication for users who log in from outside a "trusted local network" (TLN) of systems, for example, from behind an Internet firewall.

Within a TLN, users can use plaintext passwords, because you know that all devices are physically secure and that users will not, or cannot, abuse their network access.

With MultiNet Secure/IP, you can specify the systems and users that comprise your TLN in a list of devices and network addresses that are trusted, and in a list of host addresses that are specifically not trusted. For example, you might exclude a modem server from your TLN to make sure that dial-in logins are authenticated with MultiNet Secure/IP.

When users in a TLN log into other hosts in the same TLN, MultiNet Secure/IP does not intervene. Therefore, users can use plaintext passwords.

If you have configured Kerberos, MultiNet Secure/IP also generates a ticket-granting ticket to local users when they log in within the TLN using their Kerberos password. You can disable this feature to prevent unwanted or unnecessary communications with the KDC (see Chapter 24). For information on configuring Kerberos, see the MultiNet for OpenVMS Installation and Administrator's Guide.

If you do not have a TLN, you can configure the MultiNet Secure/IP Client and Server to authenticate each other with Kerberos V4. To enable this form of authentication, use the ACCESS-CONFIG SET MUTUAL-AUTHENTICATION command. By default, MUTUAL- AUTHENTICATION is disabled.

Note! If you do not have a TLN, do not define one! Defining a TLN prevents MultiNet Secure/IP services from intercepting local logins by users and systems in the TLN.

MultiNet Secure/IP also lets you decide if it will affect DECnet login sessions. For example, if your DECnet network is behind a firewall, it may be safe to allow DECnet logins with plaintext passwords.

Note! The MultiNet Secure/IP Server must have correct name and address mappings for all MultiNet Secure/IP Clients.

Hand-held authentication devices, which use built-in microprocessors, are called tokens or smart cards. Most tokens run a cryptographic algorithm, which is also known to the host computer. An example of such an algorithm is DES (Data Encryption Standard). While running the same method as the host, each token has unique programming. No two tokens produce the same results from identical input. For details on how MultiNet Secure/IP simplifies token programming, see Chapter 12.

Tokens usually have some form of input device, typically a keypad, and most are protected from theft by a PIN (Personal Identification Number). To activate the token, a user must first successfully enter a PIN. The system presents a random challenge to the user, which the user enters into his or her token. The token computes a number or string that the user enters into the computer.

MultiNet Secure/IP supports the following tokens:

• CRYPTOCard (see the CRYPTOCard Token section)

• HP Pathways SecureNet Key card (see the HP Pathways SecureNet Key Card Token section)

• Security Dynamics SecurID Card (see the Security Dynamics SecurID Card section)

• Bellcore S/KEY soft tokens (see the Bellcore S/KEY "Soft Token" section)

The CRYPTOCard is a DES-based authentication token, featuring a ten-key numeric keypad and six dedicated function keys, including ENT (enter), ON/OFF, CLR (clear), and CPIN (change PIN).

A system manager must program each CRYPTOCard with DES keys (more than one is allowed) and user preferences before it can be used. The CRYPTOCard keypad allows users to change their PINs unless the system manager programmed a "fixed" PIN into the CRYPTOCard. For details on other CRYPTOCard features, refer to your CRYPTOCard Operations and System Guide.

System managers can generate programming codes for CRYPTOCards with the MULTINET TOKEN CYPTOCARD commands (see Appendix A).

The HP Pathways SecureNet Key card (SNK) runs the DES algorithm and has a keypad with the numbers 0-9, ON, and ENT (enter).

Each SNK is programmed by the system manager or network administrator with a unique DES key and PIN. Users can change their PINs, if desired.

System managers can generate programming codes for SNK tokens with the MULTINET TOKEN SNK commands (see Appendix A). The SNK may be set to erase its memory if the user incorrectly enters a PIN more than five times in a row.

When a user logs into a system using the HP Pathways method, a Challenge prompt appears containing a value that the user enters into an SNK keypad. The user first enters the PIN into the token, then presses ENT, enters the Challenge value, and presses ENT again. The SNK token generates either eight decimal or hexadecimal digits representing the result. The user enters this value at the Response prompt. If the response is the same as that calculated by the server, the user is authenticated.

The Security Dynamics SecurID Card is a small, simple-to-use, hand-held unit that displays a new, one-time access code every 60 seconds. (Security Dynamics also offers SecurID Cards that display a new number every 30 seconds.) No two tokens ever display the same number at the same time. The token contains proprietary programming that is erased if the token is tampered with. The SecurID Server only accepts a valid passcode once. When logging into a system protected by Security Dynamics, the user first enters a PIN, then the number on the SecurID Card. The Security Dynamics ACE/Server, a UNIX system on the same network, authenticates the information. The ACE/Server is required for MultiNet Secure/IP to work with Security Dynamics SecurID Cards.

The Security Dynamics ACE/Server runs the same proprietary code as the SecurID Card and can determine the number a user's SecurID Card should display. SecurID Cards are available with or without a numeric keypad for entering the PIN. Tokens with a numeric keypad are known as the PINPAD model.

S/KEY is a software-based authentication system developed at Bellcore. S/KEY is often referred to as a soft token because it performs the same function as other authentication tokens but is implemented in software called an S/KEY calculator.

Because S/KEY is in the public domain, S/KEY calculators are available for many operating systems. MultiNet Secure/IP includes S/KEY calculator software for OpenVMS, DOS, Microsoft Windows, and Apple Macintosh computers. A reference implementation for UNIX systems is available via anonymous FTP from thumper.bellcore.com in the /pub/skey directory.

Before leaving the TLN, S/KEY users choose an S/KEY password and generate a list of S/KEY responses (also referred to as response sequences) on the MultiNet Secure/IP Server (see Chapter 12) with the MULTINET TOKEN SKEY commands (see Chapter 2 of the Administrator's Reference Guide). Users can test the new response sequences before leaving the TLN to make sure their S/KEY passwords work. From a user's perspective, S/KEY passwords serve the same purpose as PINs.

Users can also print out the response list if they anticipate not having access to S/KEY calculators when they log in from outside the TLN. Each response appears as a sequence of words in uppercase letters. This representation makes it easier for users to enter responses correctly.

Note! Because S/KEY response lists allow users to gain authentication without PINs, users must guard their S/KEY response lists.

When users log in from outside the TLN, the MultiNet Secure/IP Client displays a challenge prompt. The challenge consists of two numbers:

If the user has access to an S/KEY calculator, the user enters the challenge and the S/KEY password, then enters the calculated response at the computer.

If the user does not have access to an S/KEY calculator, the user looks up the appropriate response on the printed copy of the response list, and enters it in response to the challenge. Once authenticated, the user crosses the response off the list because it will not be required again.

For details on logging in with S/KEY authentication, see Chapter 12.

Note! S/KEY is based on the MD4 secure checksum developed by Ron Rivest, co-inventor of the RSA Public Key Cryptosystem. Newer versions of S/KEY may use MD5 and will not interoperate with older S/KEY implementations. MultiNet Secure/IP currently only supports MD4.

MultiNet Secure/IP lets you add token and S/KEY authentication to your existing MultiNet systems to restrict access from remote sites without inconveniencing local users.

MultiNet Secure/IP consists of the following parts:

• The MultiNet Secure/IP Client, which intercepts all login sessions.

The MultiNet Secure/IP Client must be running on the system you want to secure.

• The MultiNet Secure/IP Server, which maintains the user profile database.

The MultiNet Secure/IP Server can be on the same system as the client or on a different system. One MultiNet Secure/IP Server can support multiple MultiNet Secure/IP Client hosts and may run on a VMScluster for redundancy.

• OpenVMS utilities for configuring the MultiNet Secure/IP Client and Server.

• A central management utility for managing user "profiles".

• Utilities for programming tokens and generating S/KEY response sequences.

• S/KEY calculator software for the OpenVMS, DOS, Microsoft Windows, and Apple Macintosh operating systems.

To accommodate these tokens, administrators must maintain user profile databases from which secure hosts can safely obtain information to help authenticate users when they attempt to log in. The MultiNet Secure/IP user profile database is analogous to SYSUAF for OpenVMS.

Maintaining a user profile database solves the administrative problems associated with mobile computing, because the authentication database focuses on what users have and know rather than on where they are.

Each user profile can include any combination of the following data:

• The user's default authentication method

• CRYPTOCard authentication data

• SNK authentication data

• S/KEY authentication data

• SecurID authentication data

Your MultiNet Secure/IP license determines the number of user profiles you can maintain.

The following caveats and restrictions apply to using MultiNet Secure/IP:

1 Kerberos V4 tickets are not granted for token logins.

2 Kerberos V4 passwords cannot be used to log into the DECwindows session manager, or to regain control of a session manager after using the Pause command from the Session Manager.

3 Kerberos V4 passwords can be mixed case but not longer than 32 characters when used with MultiNet Secure/IP.

4 When logging into the OPA0: device as SYSTEM, the regular OpenVMS password prompt appears regardless of the default method. This allows you to get around an improperly configured MultiNet Secure/IP system. OpenVMS includes a similar facility that allows logins as SYSTEM from OPA0 even if break-in prevention is in effect.

MultiNet Secure/IP requires the following software:

• VAX/VMS V5.5-2 or later, OpenVMS VAX V6.1 or later, or OpenVMS Alpha V6.1 or later

• If you use the Security Dynamics method, a UNIX system running the Security Dynamics
ACE/Server software

This guide uses the following terms:

Note! You do not need a TLN to use MultiNet Secure/IP.

IP-over-DECnet is specified using the NET-CONFIG. Use the ADD, DELETE, or MODIFY command with the DN device name to configure an IP-over-DECnet link.

The dn interface encapsulates IP datagrams inside a DECnet connection, allowing you to make an IP point-to-point connection across an arbitrary DECnet network. Rather than sending the IP packets to a hardware device for transmission, MultiNet forwards them through the DECnet network.

Configure one of these interfaces on each side of the link. The DECnet link is established automatically during the boot process.

The following example adds IP over DECnet:

$ MULTINET CONFIGURE
NET-CONFIG>ADD DN0
[Adding new configuration entry for device "dn0"]
IP Over DECnet Peer Host's DECnet Name [NONE] HOLMES
IP Address: [NONE] 192.0.0.2
Point-To-Point Device IP Destination Address: [NONE] 192.0.0.3
IP SubNet Mask: [NONE] <Return>
[dn0 (IP over DECnet link): Csr=NONE, Flags=%X0]
NET-CONFIG>EXIT
$

The prompts are:

The IP-over-PSI (Packetnet System Interface) configuration permits IP communication over a VAX PSI connection. VAX PSI supports communication over PSDNs (packet-switching data networks) and implements the X.25 protocol. MultiNet's PSI support allows configuration of an IP over-X.25 link that conforms to RFC-1356 [ RFC-1356 is entitled "Multiprotocol Interconnect on X.25 and ISDN in Packet Mode."] .

To configure your system for use with PSI, add the PSI interface to the current configuration using NET-CONFIG, then reboot your system to load the PSI interface.

Note! MultiNet IP-over-PSI works only with DECnet Phase IV (VAX/PSI and PSI Access V5.0 and earlier).

The following examples add an IP-over-PSI interface to the current configuration using NET-CONFIG ADD command:

$ MULTINET CONFIGURE
MultiNet Network Configuration Utility 5.1(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>ADD PSI0
[Adding new configuration entry for device "psi0"]
IP Over PSI peer DTE address: [NONE] 050523343000308
IP Over PSI local DTE address: [NONE] 050523343000309
IP Address: [NONE] 192.0.0.1
Point-To-Point Device IP Destination Address: [NONE] 192.0.0.2
IP SubNet Mask: [NONE] 255.255.255.192
[psi0 (IP over PSI link): Csr=NONE, Flags=%X0]
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
$

The DTE (Data Terminal Equipment) address is a unique number that identifies the location of your computer in an X.25 network. Because the DTE address is unique across all public networks, both local and internetwork connections can be made from the system associated with the DTE address. The long form of the DTE address is:

However, the address is frequently shortened by one or more digits. Contact your X.25 system manager for more information.

Refer to RFC-1236, "IP to X.121 Address Mapping for DDN," for information on translating an IP address to a DTE address. (The format for the DTE address is defined by the CCITT X.121 recommendation.)

The peer DTE address is the remote system to which you want to connect across the PSDN. The local DTE address is the address of your system.

The MULTINET NETCONTROL VIAPSI command allows you to customize the DEBUG and IDLE parameters. The DEBUG value is a number in the range of 0 to 20 that determines how much information is displayed in an error, warning, or informational message. The default is zero. The IDLE value is a number of seconds in the range of 0 to two billion (68 years) that determines how long the line should be held open while transmissions are not being sent; that is, when the line is idle. Zero means keep the line connected continually. The default is 180 seconds (3 minutes). Once changed with NETCONTROL, the new values take effect immediately.

DEBUG and IDLE can be set permanently with the SERVER-CONFIG SET PARAMETER command after selecting VIAPSI with the SELECT command.

In addition, NETCONTROL can be used to invoke the following IP-over-PSI commands:

If a problem occurs when using the connection, make sure that:

• The server is enabled.

• Both sides of the link are ready.

• The configuration is correct.

After configuring the IP-over-PSI server, use the MULTINET NETCONTROL VIAPSI NOOP command to ensure the server is enabled:

$ MULTINET NETCONTROL VIAPSI NOOP
< FOO.BAR.COM Network Control 5.1(nnn) at Fri 8-Aug-03 3:36PM-EST
< OK: ViaPSI Server Noop
$

If the "OK: ..." message appears, the server is ready for use. Then use MULTINET PING to ensure both sides of the link are ready. You can also check the PSI configuration with the DECnet NCP utility.

MultiNet supports remote IP transport over serial lines with SLIP (Serial Line IP) or PPP (Point-to-Point Protocol).

Both SLIP and PPP use a simple framing protocol to transfer datagrams over a terminal line. Both require an RS232-C serial line, or one that looks like an asynchronous line to VMS.

MultiNet SLIP interfaces (identified by the name sl) and PPP interfaces (identified by the name ppp) can send and receive packets over any asynchronous terminal line (OpenVMS device of types TTcn or TXcn) connected to other systems that support the SLIP and PPP protocols, respectively.

As a result, MultiNet systems can communicate asynchronously with other MultiNet systems (or UNIX and other systems) that support SLIP or PPP.

With SLIP or PPP, users on one system can connect with another system using modems over telephone lines or over hardwired connections. To use SLIP or PPP over modems, the modems must be 8-bit transparent so all 256 ASCII codes can be sent and received.

If the remote system is configured as a gateway to a network, local users can also reach other systems on that network. MultiNet supports SLIP and PPP running over any VMS-supported terminal multiplexer. MultiNet does not support SLIP or PPP over LAT.

You must know the IP address of the serial interface on every remote host with which you establish serial communications. If you configure MultiNet with PPP interfaces for multiple remote hosts, the remote hosts can obtain their IP addresses when they connect. Similarly, you can configure a PPP interface on MultiNet without knowing your own IP address, and obtain it when you connect to a remote system.

The two methods of connecting hosts via PPP or SLIP are dynamic and static. The following sections explain these methods.

The usual SLIP or PPP configuration consists of two systems connected by serial line only when needed. For these situations, configure a dynamic SLIP or PPP interface. Dynamic interfaces are not associated with a specific OpenVMS device until the remote host connects to a device.

For a dynamic interface, you do not specify an OpenVMS device name when configuring the interface. When MultiNet starts, new dynamic interfaces are available for serial communication; however, an administrator must attach the interfaces to VMS devices.

Large organizations often use SLIP and PPP to connect separate LANs into a single wide area network (WAN) with dedicated serial lines. The host at each end of the serial connection is always the same, and no other hosts are allowed to connect to either serial device. In these situations, configure a static SLIP or PPP interface. Static interfaces are attached to a specific OpenVMS device, which prevents the serial device from being used for any other purpose.

For a static interface, you specify an OpenVMS device name when configuring the interface.

As soon as you connect two static interfaces via modem or hardwired connection, they can communicate over the chosen serial protocol; no user authentication is required.

Because IP connectivity is established as soon as the two serial interfaces connect, do not configure static interfaces for public dial-in access.

To configure a static SLIP interface:

1 Use NET-CONFIG or MENU-CONFIG to add the SLIP interface as described in the Adding Network Interfaces section.

Table 11-5 describes the interface parameters you must define for basic SLIP operation. Space is provided in the table so you can write down the values appropriate for your configuration.

Be sure to specify an OpenVMS device name.

2 If desired, create a custom startup command procedure for the new interface. For details, see theConfiguring Permanent SLIP and PPP Interfaces section.

3 Reboot your system.

When MultiNet starts, you can connect your serial device to a remote system.

To configure a dynamic SLIP interface:

1 Use NET-CONFIG or MENU-CONFIG to add the SLIP interface as described in the Adding Network Interfaces section.

Table 11-5 describes the interface parameters you must define for basic SLIP operation. Space is provided in the table so you can write down the values appropriate for your configuration.

Do not specify an OpenVMS device name.

2 If desired, create a custom startup command procedure for the new interface as described in the Configuring Permanent SLIP and PPP Interfaces section.

3 Reboot your system.

4 The new dynamic interfaces are created when MultiNet starts, but they are not yet connected to a VMS device. See the Attaching Dynamic SLIP or PPP Interfaces to VMS Devices section for instructions.

Table 11-5 lists the configuration parameters for configuring static and dynamic SLIP interfaces.

Table 11-5 SLIP Configuration Parameters (Continued)

To define a static PPP interface:

1 Use NET-CONFIG or MENU-CONFIG to add a PPP interface to your network configuration as described in the Adding Network Interfaces section.

Table 11-6 describes the interface parameters you must define for basic PPP operation. Space is provided in the table so you can write down the values appropriate for your configuration.

Be sure to define an OpenVMS device for the interface.

2 If desired, create a custom startup command procedure for the new interface. For details, see the Configuring Permanent SLIP and PPP Interfaces section.

3 Reboot your system.

After rebooting, the interfaces are attached to VMS terminal lines.

To define a dynamic PPP interface:

1 Use NET-CONFIG or MENU-CONFIG to add a PPP interface to your network configuration as described in the Adding Network Interfaces section.

Table 11-6 describes the interface parameters you must define for basic PPP operation. Space is provided in the table so you can write down the values appropriate for your configuration.

Do not define an OpenVMS device for the interface.

2 Enable virtual terminal (VTA) devices for your dynamic PPP interfaces. For information on configuring virtual terminals, see your OpenVMS system management documentation.

Note! Dynamic PPP interfaces require CMKRNL, LOG_IO, and SYSPRV privileges. Because these privileges are potentially dangerous, login name and password information should be safeguarded carefully.

3 If desired, create a custom startup command procedure for the new interface. For details, see the Configuring Permanent SLIP and PPP Interfaces section.

4 Reboot your system.

The dynamic interfaces are created when MultiNet starts, but they are not associated with a VMS terminal line. The interfaces must now be attached to terminal lines; see the Attaching Dynamic SLIP or PPP Interfaces to VMS Devices section.

Table 11-6 lists the configuration parameters for static and dynamic PPP interfaces.

Table 11-6 PPP Configuration Parameters (Continued)

When you configure an interface, the following line is added to your START_MULTINET.COM file to initialize the device:

$ SET TERM/PERM/NOTYPE_AHEAD/NOAUTOBAUD/SPEED=config_speed dev_name

• config_speed is the baud rate for transmitting and receiving data.

• dev_name specifies a SLIP or PPP interface such as TTA1:.

This setting is used for permanent interfaces to prevent LOGINOUT from gaining control of the device because of extraneous noise on the line.

If you want to override this behavior, create a custom command procedure, MULTINET:dev_name_CONFIGURE.COM, for that interface. If you have an IP address assigned to the device, you custom command procedure is invoked at startup instead of the command line described previously.

After a remote host connects to a MultiNet system over a serial line, the remote system administrator must log into the MultiNet system and attach the appropriate MultiNet dynamic interface to the VMS terminal line to which the remote host is connected.

For example, if your system provides serial access via two modems, but you need to provide access to three or more hosts, configure a dynamic interface for each host you plan to accommodate. Then make sure the administrator on each remote host knows the name of the serial interface you have configured and the commands to execute to attach SLIP or PPP interfaces to the appropriate terminal lines.

To convert a terminal line into a SLIP or PPP interface:

1 Log into an account with CMKRNL, LOG_IO, and SYSPRV privileges.

2 Determine the name of the serial interface corresponding to the remote host. If the administrator knows the remote IP address or host name, the corresponding serial interface name can be determined from the MULTINET SHOW command output. For example:

$ MULTINET SHOW /STATISTICS

MultiNet Network Interface statistics:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis
---- --- ------- ------- ----- ----- ----- ----- ------
se0 1500 ABC-NET FOO.BAR.COM 120360 0 143384 1 4
sl0 296 ABC-NET FOO.BAR.COM 0 0 1 0 0
lo0 1536 LOOPBACK-NET LOCALHOST 917 0 917 0 0
$ MULTINET SHOW /INTERFACE
_Network Device: SL0
Device sl0: flags=71<UP,POINTOPOINT,NOTRAILERS,RUNNING>
IP Address = 192.41.228.78
IP Sub-Net Mask = 255.255.255.192
IP Point to Point Destination = 192.41.228.80

3 Attach the serial interface to the VMS device with the following DCL command:

$ MULTINET SET /INTERFACE interface_name -
_$ /DYNAMIC/VMS_DEVICE/LINK_LEVEL=protocol

protocol is SLIP or PPP, according to the type of serial interface.

Note! If the remote host is also a MultiNet system, the remote administrator must also attach the remote serial interface to the remote VMS device.

The following example illustrates how to establish connectivity between two MultiNet systems over dynamic SLIP interfaces. The first MULTINET SET /INTERFACE command converts the remote host's dial-in port into a SLIP interface. After the user types the control-backslash
Ctrl/\ escape key sequence to return to a local DCL command line, the second MULTINET SET /INTERFACE command converts the local terminal line into a SLIP interface. The MULTINET PING command confirms IP connectivity.

WHARFIN$ ALLOCATE TTA1:
%DCL-I-ALLOC, _WHARFIN$TTA1: allocated
WHARFIN$ SET TERMINAL/SPEED=2400 TTA1:
WHARFIN$ SET HOST/DTE TTA1:
%REM-I-TOEXIT, connection established, type ^\ to exit
ATDT1415555-1212
RRING
CONNECT 2400
BIGBOOTE SLIP Gateway - VAX/VMS V5.5-2
Username: SYSTEM
Password:
Welcome to the BIGBOOTE SLIP Gateway
Last interactive login on Monday, 28-FEB-2003 14:47
Last non-interactive login on Monday, 28-FEB-2003 13:16
BIGBOOTE$ MULTINET SET/INTERFACE SL1/DYNAMIC/LINK_LEVEL=SLIP/VMS_DEVICE
The line you are logged in over is now a SLIP line.
[You now type the Ctrl/\escape sequence to return to WHARFIN.]
%REM-S-END, control returned to node _WHARFIN::
WHARFIN$ MULTINET SET/INTERFACE SL1/DYNAMIC/LINK_LEVEL=SLIP/VMS_DEVICE=TTA1:
WHARFIN$ MULTINET PING 192.0.0.3
PING 192.0.0.3 (192.0.0.3): 56 data bytes
64 bytes from 192.0.0.3: icmp_seq=0 time=860 ms
64 bytes from 192.0.0.3: icmp_seq=1 time=860 ms
64 bytes from 192.0.0.3: icmp_seq=2 time=860 ms
Ctrl/C
----192.0.0.3 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 860/860/860
WHARFIN$

To bring down an interface, issue the following command:

MultiNet maintains a set of global parameters that affect the behavior of all network interfaces. For example, your system's default route (see Chapter 13) is specified as a global parameter and affects how all network interfaces direct data packets over the network.

There are two ways to configure global parameters:

• NET-CONFIG, using the SET parameter_name command. See the MultiNet for OpenVMS Administrator's Reference for a complete list of SET commands.

• MENU-CONFIG, using the Configure Global Parameters command. For each NET-CONFIG SET command, there is a corresponding field you can edit using MENU-CONFIG.

You can modify all global parameters without rebooting your system with the following exceptions:

• LOAD-EXOS-DRIVER

• LOAD-UCX-DRIVER

• WINS-COMPATIBILITY

Changes to these parameters take effect after you reboot the system.

The following subsections describe how to modify global parameters to perform the following tasks:

• Configuring DECwindows support (see the Using the HP TCP/IP Transport Over UCX section)

• Configuring the cluster alias feature, which permits another VMScluster node to continue to provide some connectionless network services if the primary node that provides those services fails (see the Configuring VMScluster Aliasing section)

• Ensuring PATHWORKS 5.0 support is enabled (see the Ensuring PATHWORKS Support is Enabled section)

You can configure the DECwindows server and X clients to use the HP TCP/IP Transport over MultiNet's UCX driver. MultiNet supports DECwindows over TCP/IP under VMS V5.5-2 and later versions by emulating the HP TCP/IP Services for the VMS $QIO interface.

The MultiNet UCX driver is enabled by default.

1 Edit your system startup command procedure to invoke MultiNet before starting DECwindows.

2 Reboot your system to start MultiNet with the UCX $QIO driver loaded.

3 To create a display, issue the following command:

$ SET DISPLAY/CREATE/NODE=ip-node-name /TRANSPORT=TCPIP

For complete information on the SET DISPLAY command and running remote DECwindows applications, see the VMS DECwindows User's Guide.

Each user must enable TCP/IP access on a host-by-host basis using the DECwindows Session Manager Customize Security menu so they can run applications over the TCP/IP transport.

From that menu, specify:

• TCP/IP as the Transport

• The remote host's Internet host name as the Node

• A question mark (?) for the Username

The DECwindows chapter of the MultiNet for OpenVMS User's Guide contains information about running DECwindows applications over MultiNet.

If you have the cluster alias feature [ The cluster alias feature is also known as "cluster failover."] configured on more than one node in a VMScluster, the nodes negotiate among themselves so that only one node at a time answers requests to the cluster alias.

If the node serving the cluster alias fails and more than one node has the cluster alias configured, the service provided by the failed node is provided by another node in the cluster. Without the cluster alias feature, the services provided by the failed node are not available.

To use cluster aliasing, you provide a list of addresses to which each node will answer. If the node currently serving the cluster alias fails, one of the other nodes takes over the connectionless services for that address.

This feature lets you specify one or more nodes in the cluster as having an additional IP address, so only one of the nodes will use that additional IP address at any one time.

Enable cluster aliases with the NET-CONFIG SET IP-CLUSTER-ALIASES command. Specify the extra IP addresses for which this node should also answer requests. Disable cluster aliases by invoking the command without addresses. You can change the value of IP-CLUSTER-ALIASES without rebooting by also defining or redefining the system-wide logical name MULTINET_IP_ CLUSTER_ALIASES and restarting the MULTINET_SERVER process.

Since this service is disabled by default, you must enable it in this way:

$ MULTINET CONFIGURE /SERVER
SERVER-CONFIG>ENABLE CLUSTERALIAS
SERVER-CONFIG>EXIT

Now you can enable cluster failover as shown in the following example:

$ MULTINET CONFIGURE
MultiNet Network Configuration Utility 5.1(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SET IP-CLUSTER-ALIASES 192.1.1.2
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
$ DEFINE /SYSTEM /EXECUTIVE MULTINET_IP_CLUSTER_ALIASES "192.1.1.2"
$ @MULTINET:START_SERVER

By default, MultiNet is configured to support PATHWORKS 5.0 running concurrently. To ensure this support is enabled:

1 Verify the presence of the PWIP (Pathworks over IP) device:

$ SHOW DEV PWIP

2 Invoke NET-CONFIG and enter the SHOW command. Check the "Load PWIP (Pathworks) driver:" line.

3 If MultiNet is not configured to load the PWIP driver, enter the SET LOAD-PWIP-DRIVER command.

4 Save the configuration to ensure it is loaded the next time your system reboots.

To enable multicast packet reception under OpenVMS V5.5-2, create a custom SE0_CONFIGURE.COM file that adds the /MULTICAST=ALL qualifier to the MULTINET SET /INTERFACE command line in that command procedure.

Multicast reception is enabled automatically in OpenVMS VAX V6.0 or later and in all versions of OpenVMS Alpha. The file MULTINET_ROOT:[MULTINET.EXAMPLES]SE0_CONFIGURE.COM is a template for such command procedures.

Maximum Transmission Unit (MTU) discovery determines the maximum size of a TCP packet that can be sent through the network between two hosts. Performance improves when the largest, most efficient packet size possible with the hardware at each hop is enabled. RFC-1191 describes this feature, which is enabled by default.

When MTU discovery becomes active for a remote host, it places a host route in the routing table with the MTU set to the appropriate size. This feature is potentially useful for tracing unusual routes.

MTU discovery sets the Don't Fragment (DF) bit in IP packets. It is difficult to predict how routers from different vendors will handle the DF bit; some handle it correctly, some do not, some work until they need to fragment a packet, and some simply drop the packet. If you suspect a routing problem is affecting communications, disable MTU discovery by issuing the following command:

$ MULTINET SET/KERNEL TCP_PMTU 0

To enable it again, issue this command:

$ MULTINET SET/KERNEL TCP_PMTU 1

Both of these commands take effect immediately.

Some versions of NCSA Telnet for DOS do not interoperate with MultiNet V3.3 and later because NCSA Telnet does not properly handle MTU discovery negotiations. If you experience problems between this product and MultiNet, upgrade to NCSA Telnet version 2.3.07 r3 or later.

The Address Resolution Protocol (ARP) dynamically maps addresses between Internet and Ethernet. ARP is used by all MultiNet Ethernet interface drivers and HP Computer FDDI drivers.

ARP caches Internet-Ethernet address mappings. When an interface requests a mapping for an address not in the cache, ARP queues the message requiring the mapping and broadcasts an ARP request on the associated network requesting the address mapping.

If a response is provided, the new mapping is cached in the ARP table and any pending messages are transmitted. ARP queues no more than one packet while waiting for a mapping request to be responded to; only the most recently "transmitted" packet is kept.

To enable communications with systems that do not use ARP, the MULTINET SET /ARP utility allows you to add and delete entries in the Internet-to-Ethernet tables.

CAUTION! Adding or modifying entries in the ARP table can seriously affect TCP/IP communications. Do not create or modify ARP table entries unless you are sure of their effects on your network.

The SET/ARP qualifiers are: