Sustainable Sustworks - Tools for Internet Travel
Inspired Tools for the Mac
Search






 




Specifications

IPNetRouter is Macintosh router software which permits you to share your Internet connection. This includes PPP, Cable Modem, DSL, ADSL, and PPPoE Internet connections. Designed from the ground up to take full advantage of Open Transport, IPNetRouter offers superior performance with greatly reduced cost and complexity.

As shown above, before installing IPNetRouter you have one machine directly connected to the Internet and one or more machines networked via a personal LAN (Local Area Network). Unfortunately, the other machines cannot access the Internet with this setup.

After installing IPNetRouter, the PowerBook and any other computers on the LAN have full Internet access. At the same time IPNetRouter becomes an Internet sentry (firewall) and prevents unauthorized access to machines on your LAN. This is because IPNetRouter enables Open Transport to forward packets between the Internet and the Personal LAN through a mechanism called "Network Address Translation" (aka "NAT"). With both NAT and the packet filtering capabilities of IPNetRouter, you can build a very solid firewall which prevents unauthorized access from the Internet to any of your machines on your personal LAN.

Since IPNetRouter understands network addresses that are independent of the LAN hardware, it can connect networks using different physical media. That is, you could have a private LocalTalk network, a private ethernet network, a private wireless network and IPNetRouter would be able to make intelligent decisions about which packets to forward to/from the Internet and how to transfer packets from one network to another. This capability is called "multilink multihoming" and permits your Macintosh to have several different IP addresses on several different physical networks...a feature most often associated with much more complicated UNIX based computers.

System Requirements

  • MacOS 7.5.3 and Open Transport 1.1.1 or later (OT 1.1.2 for 68k)
  • Macintosh PowerPC or 68030 or higher.
  • A Macintosh capable of connecting to the Internet using the TCP/IP protocol suite.

Technical Description and Specification

IPNetRouter consists of the following major components:

  • A utility for sending commands to the IP module in Open Transport
  • A STREAMS module that performs Network Address Translation and IP Filtering
  • Support for PPP dial-on-demand
  • Support for saved configuration files
  • A graphical user interface
  • A DHCP Server

The following sections examine each of these components in detail.

Utility for Sending Commands to IP

This component sends IOCTL commands to configure and bring up additional IP interfaces based on the following parameters:

  • The user port name or physical port name (from the OT Port Registry)
  • The interface name
  • The IP address
  • The network mask
  • A set of boolean values that specify whether to bring the interface up or down; enable IP masquerading on this interface; designate the interface as unnumbered; and prevent a saved IP address from overriding a DHCP assigned address.

This component builds additional Link Stacks (the chain of modules between IP and a Data Link Provider (such as Ethernet) to support multilink multi homing. Any Link Stacks created by IPNetRouter will be dismantled when the program is quit.

In general, IPNetRouter can work with most Open Transport compatible Data Link Providers such as Ethernet, Fast Ethernet, Token Ring, PPP and others. In the case of PPP however, dial on demand support is more limited (see below).

IPNetRouter supports MacIP (IP in AppleTalk) as a client. This means IPNetRouter can build a Link Stack that will add or remove the AppleTalk wrapper for MacIP allowing LocalTalk connected devices to access TCP/IP services via IPNetRouter. IPNetRouter does not assign IP addresses to other MacIP hosts at this time (as a traditional MacIP gateway), it is necessary to configure each MacIP host manually.

This component enables or disables how the host forwards IP datagrams. IP_FORWARD_NEVER (0) to inhibit forwarding (RFC 1122 compliance); IP_FORWARD_ALWAYS (1) to always forward; IP_FORWARD_AUTOMATIC (2) to forward only if the number of IP interfaces on the system is greater than 1 (SunOS 4.1.x compatible).

IPNetRouter supports static routing. It does not participate in RIP exchanges or other routing table update protocols at this time.

STREAMS module that performs Network Address Translation (NAT) and IP Filtering

An Open Transport STREAMS module (shared library) named OTModl$Proxy is stored in the Extensions folder and inserted in any IP Link Stacks immediately below the IP module itself. We will refer to this module as the "Proxy" module through out the rest of this specification.

The Proxy module performs Network Address Translation (RFC-1631) with extensions for Port Multiplexing and ICMP translation. Port Multiplexing allows an entire LAN to hide behind a single public (globally unique) IP address by assigning unique port numbers to each actual endpoint. ICMP translation allows diagnostic tools like Trace Route to work through the translator by keying off the "triggering datagram" returned in ICMP response packets.

The use of a single public address with Port Multiplexing means that protocols that do not include a protocol port number (ICMP and GRE for example) are limited to a single host at a time.

The NAT function translates IP address and port information in the IP header, TCP header, and UDP header. Certain protocols also embed IP address and port information within the datagram body itself. Among the most heavily used protocols, FTP does this when configured to use "PORT" mode as opposed to "passive" (PASV) mode. The Proxy module recognizes PORT commands on the standard FTP control connection (port 21) and translates them as a special case to provide ftp masquerading. Specialized gaming or streaming protocols may not work with NAT without additional support.

GRE packets are passed unmodified to support PPTP for Window-NT VPN.

The NAT function is normally enabled based on the physical port (from the OT Port Registry). To facilitate using cable modems with a single Ethernet (two IP interfaces on the same physical port), IPNetRouter can designate one IP interface as a "Private Network" so it will not translate datagrams to or from this IP interface even though it is translating other datagrams on the same physical port.

The Proxy module currently supports masquerading on up to four Interfaces at a time (one translation table) using a single public address with a maximum of 500 simultaneous connections (the translation table can hold 500 entries).

The NAT table can be edited under user control to support Inbound Port Mapping. See the Port Mapping page at

<http://www.sustworks.com/site/ipr_guide/port_mapping.html>.

The Proxy module also supports IP Filtering on a per port basis. See the Building Your Own Low Cost Firewall page at

<http://www.sustworks.com/site/ipr_guide/firewall.html>

The module includes built-in filtering for Windows-95 and Windows-NT NetBIOS DNS queries to prevent spurious connection attempts (UDP datagrams from source ports 137, 138, and 139).

Support for PPP dial-on-demand

Open Transport 2.0 and earlier as supplied by Apple assumes there can only be one IP data link active at a time. If that data link is temporary in nature such as PPP, Open Transport will initiate a connection when an application on that machine tries to open an IP endpoint. Since IPNetRouter allows multiple data links to be active and might receive IP traffic for a PPP interface from another host, the existing mechanism does not provide the desired capability.

IPNetRouter implements dial-on-demand as follows. The IPNetRouter application monitors the state of the PPP interface and notifies the Proxy module whether that interface is up or down. While the interface is down, IPNetRouter will periodically poll the Proxy module to determine if it has seen any IP traffic for an on demand interface. When an instance of the Proxy module that is pushed above a PPP data link provider detects IP traffic for an interface that is disconnected, it sets a flag to notify the IPNetRouter application the next time it polls. The IPNetRouter application then launches a connection attempt for that interface.

Since IPNetRouter needs to monitor the state of the PPP connection and initiate a connection attempt when there is traffic for the corresponding interface, IPNetRouter requires some PPP specific code to carry out this task. It is for this reason the dial-on-demand feature only works with certain PPP implementations. IPNetRouter supports dial-on-demand with OT/PPP and FCR PPP (a.k.a. LinkUPPP or LeoMLP) at this time.

When IPNetRouter initiates a PPP connection attempt, it is possible the connection attempt will fail (line is busy, modems fail to connect, ISP is offline, etc...). In this event, IPNetRouter will retry the connection attempt five times. The first 3 tries tell PPP to initiate a connection attempt. The next three tries will remove the PPP interface and then add it back. If all 6 tries fail to connect, IPNetRouter will wait 10 minutes and then try again to launch a connection attempt repeating the process above.

It is possible for other PPP implementations to support dial-on-demand directly without oversight from IPNetRouter. In this case, PPP would initiate a connection when it receives IP traffic, and inform IPNetRouer of the negotiated local IP address possibly using the command file interface described below.

Support for saved configuration files

IPNetRouter allows you to save the current networking configuration including any interfaces, routes, port mapping, filters, or other gateway settings you have specified. To save the current configuration you can choose Save under the IPNetRouter File menu. To restore this configuration at a later time, you can open the corresponding configuration file from the Finder by double-clicking or placing it in the Startup Items Folder. IPNetRouter configuration files contain human readable text to simplify debugging or controlling the application directly from stored configuration files.

The format of IPNetRouter configuration files is largely self evident. Consider the following example:

#forwardingAutomatic +interface\ \lo0\127.0.0.1\255.0.0.0\ +interface\Ethernet\mace0\192.168.0.2\255.255.255.0\ +interface\PPP\IPCP0\0.0.0.0\0.0.0.0\masquerading\ +route\Direct\192.168.0.0\192.168.0.2 +route\Direct\224.0.0.0\192.168.0.2 +route\Default-Gateway\0.0.0.0\0.0.0.0 +map\icmp\209.6.64.35:0\209.6.64.35:0\1\ #end

Keywords corresponding to individual settings begin with the pound character "#" in the first column. Commands to the IP module begin with a plus "+" or minus "-" character. Command parameters are delimited by the backslash "\" character. The configuration ends with a line containing "#end". Any line beginning with a character other than "#", "+", or "-" will be treated as a comment and ignored.

IPNetRouter process the commands in order trying to make the current networking configuration match the configuration contained in the file. Any existing interfaces or routes not listed in a saved configuration will be removed. If the keyword "#addOnly" is seen, IPNetRouter will not try to match the entire configuration, but simply execute any commands in the file. If the keyword "#delete" is seen, IPNetRouter will delete the configuration file after processing the commands therein.

"+interface" specifies to bring up an interface. "-interface" specifies to remove an interface. "+route" adds a route, "-route" removes a route. "+map" and "+filter" entries work similarly.

IPNetRouter recognizes the Open File Apple Event which can be used to programmatically change the networking configuration. The application creator signature for IPNetRouter is "IPnl". IPNetRouter can be configured as a faceless background application to hide the default user interface described below.

Keyword commands:

#forwardingNever #forwardingAlways #forwardingAutomatic #configureOnly #configureDisplay #auto #addOnly #remainConnected #remainconnectedOff #disconnectAtQuit #disconnectAtQuitOff #showPPPdialogs #showPPPdialogsOff #dialOnDemand #dialOnDemandOff #enableLocalNAT #enableLocalNATOff #TRCableModem #TRCableModemOff #PPPName=<name-of-TCP/IP-config> #disconnect #connect #delete #quit

Interface parameters

\masquerading \unnumbered \dhcp \nogateway \mtu=

Graphical User Interface

In Macintosh fashion, the IPNetRouter user interface consists of a menu bar with standard commands and a set of windows that allow you to edit application data thereby controlling the application and networking configuration. Individual windows can be invoked from the Window menu. To allow a single IPNetRouter configuration document to represent the entire network configuration, the Routes Window, Gateway Window, Port Map Window, and IP Filtering Window are children of the Interfaces Window and correspond to different views of a single document. Closing the Interfaces Window closes the corresponding document and will automatically close its dependent windows.

Each IPNetRouter window contains a help button in the lower left corner that describes the window controls in more detail.

Many of the windows follow a similar model for sending commands to the IP module in Open Transport. A table along the top of the window shows the current configuration. You specify the parameters of the command in an entry area below the table, and then send the command by pressing the Add or Remove button. The Interfaces table for example shows the actual IP interfaces the IP module knows about. When you click on a line in the table, it copies the current information from that line to the Configure Interface box below to save you the trouble of retyping it, thus making it easier to modify an existing interface. It is the parameters in the entry area that control what happens, not what line of the table is selected. The IP module identifies which interface you are trying to modify by the interface name field in the Configure Interface box.

If you try to send commands that don't make any sense, the IP Module will not accept them and no changes will appear in the table.

A status line along the bottom of the window provides a summary of any unexpected conditions or errors encountered while trying to perform a command. The IPNetRouter Log window records what the program is doing and will often provide additional information that would not fit in the status area. The contents of the log are also written to the file "IPNR.log" in your Preferences Folder. The log file is automatically re-used each time you launch the IPNetRouter application. In the event of a system crash that precludes reviewing the log window, it is important to rename or copy the IPNR.log file before re-launching IPNetRouter.

DHCP Server

The DHCP window allows you to configure the DHCP server built-in to IPNetRouter. In order to access the Internet, each computer on your LAN needs to be configured with four pieces of information (IP Address, Network Mask, Router Address, and Name Server Address). The DHCP server in IPNetRouter allows other computers on your LAN to get this information automatically from IPNetRouter by selecting "Configure via DHCP" in the corresponding TCP/IP control panel.

Using DHCP (Dynamic Host Configuration Protocol) avoids the need to manually configure each computer on your LAN before it can be used, and is especially useful if you have many computers on your LAN or frequently move computers from one network to another.

Before you can use DHCP to configure other hosts on your LAN, the DHCP Server itself needs to be configured. In most cases, you can simply press the "Use Defaults" button and enable the server by selecting "DHCP Server On". These settings assume your LAN will use IP addresses from the range 192.168.0.x and that your gateway running IPNetRouter will use 192.168.0.1 as its local address. [*WARNING* If you are connecting using a cable modem and single Ethernet, you must not enable DHCP on this Ethernet since DHCP requests are broadcast to all interfaces on that physical network.]

If your Local Area Network has additional requirements, you can use the DHCP Window to control what IP addresses to assign, to whom, for how long, and other operational parameters. The information in the DHCP Window is divided into four tables or panels which are briefly described below. For more information on DHCP, refer to RFC-2131, RFC-2132, or a good book on TCP/IP.

Status Table

This table keeps track of Lease Bindings. What addresses are currently leased, to whom (hardware address or clientID), and when the lease expires. It also keeps a state value for each entry so it can track bindings that are not currently active (such as bindings that have been offered, released, or expired). The intent here is to remember previously assigned leases so clients will always get the same lease whenever possible. Finally, this table keeps track of when each entry was last updated so the server can re-use the oldest unused entry first ("Least Recently Used"). This table should normally be viewed as "Read Only", but you can use the button on the right to remove an obsolete lease binding. You can also copy rows to the clipboard as text for use in other panels.

The Status Table is stored in a separate file in the Preferences Folder called "DHCP Server Status". Any time a lease is granted to a client, the corresponding entry is written out to this file (committed to non-volatile storage). If the server is stopped for any reason, it can recover all the current lease information from here. You can also move your DHCP Server to another machine by copying this file and the corresponding IPNetRouter configuration file.

Static Config Table

This table keeps track of any static address assignments the administrator wants to create. The fields are: (1) Network Interface - the IP address of which interface a request must arrive on [If a host moves from one network to another, we need to assign a different IP address depending on which network it is attached to. If a BOOTP relay agent is used, we match this network as well.]; (2) Lease Address - the address to grant; (3) What host or client this address is reserved for as specified by the Ethernet hardware address or ClientID. The ClientID will override the hardware address if specified in the table. The entries in this table can be edited in place by clicking in a cell. Use the buttons on the right to insert or delete entire rows. You can use Tab, Shift Tab, Return, and Shift Return to move the selected cell.

The Static Config Table is stored as part of your IPNetRouter configuration when you save from the file menu.

Dynamic Config Table

This table keeps track of ranges of IP addresses that can be automatically assigned to hosts as needed and later reclaimed. The fields are: (1) Network Interface - the IP address of which interface a request must arrive on [Each network interface that accepts DHCP requests will normally assign IP addresses from a different range.]; (2) Starting Lease Address - start of range used for address pool; (3) Ending Lease Address - end of range used for address pool. The entries in this table can be edited in place by clicking in a cell. Use the buttons on the right to insert or delete entire rows. You can use Tab, Shift Tab, Return, and Shift Return to move the selected cell.

There are no restrictions on how many address ranges can be defined to serve from multiple interfaces or multiple ranges on a single interface. Any IP address in a dynamic address pool that overlaps with an address in the Static Config Table will be reserved for static configuration and not dynamically assigned. The Dynamic Config Table is stored as part of your IPNetRouter configuration when you save from the file menu.

Some clients may use BOOTP, an older subset of DHCP. BOOTP clients are normally not eligable to receive dynamic IP addresses because BOOTP does not provide any mechanism to reclaim an expired address. To avoid requiring the network administrator to create a static assignment for each BOOTP client, IPNetRouter will try to assign BOOTP clients a dynamic address if no static configuration is found and display a warning message in the log window. In order not to lose addresses permanently, the server will try to reclaim "BOOTP dynamic addresses" after 60 days.

Lease Options Table

This table stores the other information that is given out to clients based on what network they are attached to. The fields are: (1) Network Interface - the IP address of which interface a request must arrive on [Each network interface that accepts DHCP requests can potentially give out different information.]; (2) Network Mask - the network mask for this network; (3) Routers - the router addresses for this network; (4) Name Servers - the name server addresses for this network; (5) Default Lease Time - lease time granted if none is explicitly requested; (6) Maximum Lease Time - the maximum lease time to grant regardless of what is requested; (7) Domain Name - A default domain clients can use for DNS lookups; (8) Enable DHCP on this interface - DHCP serving can be selectively enabled on a per interface basis.

The Network Interface popup menu lists the IP interfaces which have a lease options entry currently defined. It selects which row of the table to view in the rest of the panel. If you select a new interface, IPNetRouter will try to fill in appropriate values for the subnet mask, router, name server and default lease times. The Lease Options Table is stored as part of your IPNetRouter configuration when you save from the file menu.

More About DHCP Data and Editing

When you edit data in place, you are only editing a visible copy of that data on the display. You can undo any changes you make by pressing "Restore". To have your changes take effect, you must press "Apply". To save your settings to an IPNetRouter configuration file, you must still select "Save" from the File menu.

DHCP should be seen as a mission critical service since hosts on your LAN may not be able to use the Internet if your server is unavailable. DHCP is designed so that more than one server can be configured to provide the same information for reliability. Clients normally try to renew an existing lease and only the Server with a record of that lease will respond. If the existing lease cannot be renewed, the client may then try to obtain a new lease. The Server pings any new proposed lease address before offering it to a client to check that the address is not already in use. If the Server discovers an address conflict, it will mark the corresponding address in the Status Table as "In Use" or "Declined" and no longer try to assign it. You can see when the conflict was detected from the "Last Update" column in the Status Table. In order not to loose addresses permanently, the server will try to reclaim "In Use" or "Declined" addresses after 60 days.

Since the Status Table is kept as plain text in the file "DHCP Server Status", you can edit this table manually if desired.

Resource Options

IPNetRouter supports a number of resource switches that can be used to further customize the application. These are stored in 'STR#' resource 131 named "Option Settings". The setting names and their defaults are listed here:

SleepTime=6

Parameter passed to WaitNextEvent

LogFileName=IPNR.log

Name of IPNR log file in Preferences folder

ConfigFileName=Router Config

Name of config file in Preferences folder to load automatically at application startup.

PPPName=IPNetRouter

Name of configuration in TCP/IP control panel to temporarily activiate for PPP connection.

IPNetRouterDials=1

Selects whether IPNetRouter will always tell PPP to dial before building a PPP link stream. Setting this to zero (0) allows PPP to decide when to dial on demand.

DynamicBOOTP=1

Allow BootP clients to receive an IP address from the dynamic address pool (like DHCP clients) instead of requiring a static configuration for each client.

AuthorizationName=wireless-authority

Name used to determine whether a wireless base station is permitted on this network.

DHCPPingCheck=1

Allows you to control whether the DHCP Server will ping a new address to verify it is not in use before offering it to a client.

MapBroadcast=1

Allows you to control whether IPNetRouter will automatically create a port mapping entry to forward directed broadcasts to your private LAN. This can be used to help locate services on your LAN using NSL/SLP.

Top