Volume Number: 15 (1999)
Issue Number: 7
Column Tag: Network Management

Mac Network Management 101

By John O'Fallon, Maxum
Edited by Ilene Hoffman

Private TCP/IP Networks

Introduction

Private TCP/IP networks aren't just for the security-conscious network administrator. In fact, almost any Web Developer, Network Administration, or Site Designer can use private networks to:

• Test the latest version of a Web server or a new plug-in at home or on a laptop.
• Connect a small LAN to the Internet using a single Mac with a modem and a PPP connection.
• Create a small test network that is logically separate from your production LAN.
• Control Internet access by disabling or limiting certain Internet services or capabilities on an entire LAN.
• Simplify network management and assign static addresses to clients instead of using DHCP for testing, intranet applications or tracking.
• Protect a local network from external Internet users.

Private networks allow you to do all of the above, and on the Mac, it is surprisingly easy. Even if none of the capabilities suggested above appeal to you (and I doubt that's possible, given the subject matter of the fine periodical you now hold in your hands) sit back and read on. If nothing else, you'll find out about some of the cooler new features of Mac networking (Open Transport, from here on called simply OT).

Since we're talking about the newest features of OT, be sure you are using OT 1.3 or greater. Any version of OT that shipped with Mac OS 8.1 or greater will be just fine.

The "Bogus" Setup

In the next few pages, we're going to build a private (or what I refer to as a "bogus") TCP/IP network. Clients on our network will have full Internet access, or, if we choose, only partial access. Furthermore, these clients will peacefully coexist with "real" client workstations on the same physical network, if any physical network exists at all.

We begin with a lone workstation, and not an Ethernet cable in sight...

Let's take the case where you would like to run two TCP/IP applications, say a Web server and a Web browser, on the same Macintosh, with no connection to the Internet or LAN. When I'm on the road and I want to test my latest WebStar Plug-In or Rumpus tweak, I do this all the time on my PowerBook,. Configuring Open Transport so that a Mac can use TCP/IP applications locally is so easy, most people don't believe me when I tell them how to do it.

Start by opening the TCP/IP control panel, and then select "AppleTalk (MacIP)" as the "Connect Via" setting. Set the "Configure" field to "Using Mac IP Manually", and then enter an IP address. The IP address range beginning "192.168." is traditionally used, and is reserved. With OT, you can use anything except "0.0.0.0" (which may actually work but is special, so don't use it). For now, enter "192.168.1.3."

Finally, blank all the other fields and close the TCP/IP control panel. Don't worry about the subnet mask, the router address, DNS, or anything else. Just close the window. OT gives you a warning that it is going to pick some defaults for you. It does a good job, so let OT use its defaults and click "Continue."

Figure 1. The TCP/IP Control Panel, Configured and Ready

Now fire up a TCP/IP server and client. You can use a Web server (Web Sharing, WebStar, WebTen, etc.) and any Web browser for testing. Launch the server, then launch the client and attempt to connect using the IP address you specified. Enter "http://192.168.1.3/" in the location field and press return. Depending on how you have your Web server configured, you should get a Web page served up. Even if you get an error, it should be a "file not found" page delivered from the server, this indicates that your "network" is up and running.

For Macs connected to an Ethernet network, you can also select "Ethernet" in the "Connect Via" field. Again, make sure the "Configure" field is set to "Manually" and that the made-up IP address is the only other field entered. This method should be used for any Mac connected to an Ethernet LAN, and will also work on G3-based PowerMacs and some PowerBooks (depending on your Ethernet driver) even when they aren't connected. The benefit of this configuration is that multiple Macs connected to the same Ethernet LAN will be able to communicate, as we will see in the next section.

Extending Bogusness to the Network

Your Mac is now a network of one, and you can use it to test server software at home or on the road. One of the really nice features of OT is that it allows you to maintain multiple configurations, and switch between them easily. For example, my PowerBook has a "Connected" configuration as well as one called "Private LAN." When I'm plugged into my LAN, the "Connected" configuration gives me a real static address and full Internet connectivity. On the road or at home, "Private LAN" provides me with a test environment.

To create new configurations, open the TCP/IP control panel and select the "Configurations..." option from the "File" menu. Use "Duplicate" to create new configurations, and then set them up accordingly. To switch between configurations, just select the configuration you want and click "Make Active."

So far, so good. To create a Mac with a bogus IP address, you enter that IP address into OT and blank all the other fields. It's even easier than configuring a real IP address, and works like a charm. The cool thing is that multiple Macs, configured this same way , (but with different bogus IP addresses), connected on an Ethernet LAN will be a part of the same bogus network, as long as the "Connect Via" field is set to "Ethernet".

The fact that multiple Macs configured this way work together is not all that amazing, when you think about it. OT assigns the same default subnet mask (255.255.255.0) whenever the subnet mask is left blank, so all the bogus machines will be on the same subnet. The network won't have Domain Name Service, so leaving the DNS field blank is ok, too. Finally, the bogus network won't have Internet access yet so no router address is needed either yet.

Go ahead and try it. Configure two or three Macs on an Ethernet LAN with nothing but IP addresses. I would suggest using "192.168.1.3," "192.168.1.4," "192.168.1.5," and so on. The reason to use "192.168." is mentioned above, and I always start at 3 as the last digit and leave 1 and 2 reserved for a router and maybe DNS or a gateway. Once you've set up at least two machines this way, you can use a server application on one Mac and clients on the others. Use IP addresses in URLs (instead of domain names) and the Macs will happily connect to one another.

You will notice a couple of very interesting, very handy aspects of this configuration. First, no one on the Internet will be able to access these machines, making them perfect for testing. Second, your bogus network happily coexists with your real network on the same physical LAN cabling. If you have a LAN of six Macs, and three are configured with bogus addresses and three have real Internet addresses, there will be no disruption of service for your real workstations. Third, you can make up as many as 255 addresses in the "192.168.1." subnet, giving you lots of room for expanding your network no matter how many "real" TCP/IP addresses you might have. Finally, while the Macs on the private network can "talk" between themselves, they don't have Internet access.

Getting Bogus Macs on the Internet

What good is TCP/IP if you can't access the Internet? This last feature might not sound so great at first. The, is that there are a couple of ways to provide Internet service to machines with bogus addresses. Now that we've disabled Internet access, we can begin to re-enable services in a controlled way.

There are two ways to enable Internet connectivity, and both methods involve routing data from the bogus clients to the real Internet and back again. This can be done at the packet level with some form of traditional router, or at the application level with a higher-level gateway. If you only need very specific Internet services, for example e-mail and Web access, then an application level gateway may be fine. For general purpose Internet capabilities, you want to use a packet level router.

Application level routing can be done using specialized applications (gateways) and another OT trick, called multi-noding. Multi-noding allows a single machine to have multiple IP addresses. Before OT 1.3, Webmasters longed for this capability so that they could run multiple domains from a single Web server (without having to rely on the "Host" field sent by most Web browsers in HTTP requests).

For our purpose, multi-noding will allow TCP/IP servers to "listen" on multiple IP addresses (or "interfaces"), while using a primary interface for all server-initiated connections. Let's say we want to provide our bogus network with e-mail services. First, we configure a Mac with two TCP/IP addresses, one that is bogus and one that is real. This Mac acts as our gateway to the Internet, and runs any server or proxy that will provide Internet service for our private LAN. The e-mail server running on the gateway Mac will be able to process mail for local clients because it is on the bogus network, while at the same time it can send and receive mail from other mail servers on the Internet using its real interface.

The first step is to configure the real Internet connection, using the TCP/IP control panel as you have always done. Once the Mac has Internet access (tested by launching a browser and surfing to "www.netprolive.com," of course), we are ready to give the machine its second (and bogus) address. Editing a simple text file, and placing it in the Preferences folder inside the system folder does this. This file must be called "IP Secondary Addresses," and can be edited using SimpleText, BBEdit, or any other text editor you have handy.

Figure 2. The "IP Secondary Addresses" file

Each line of this file allows you to configure an additional IP address for the machine. You can specify the address, subnet mask, and router, but, we will again let OT default everything but the address. So, with the exception of the comments (denoted by lines beginning with a semi-colon), in the only line in our Secondary Addresses file is "ip=192.168.1.7." Remember to assign whatever address is consistent with your private network.

After restart the Mac and it will have access to both the bogus network and the Internet and the gateway is ready. To continue our e-mail example, clients on the private network can send and receive mail from a mail server on the gateway (once they are configured appropriately, of course). Mail clients on the private LAN are simply configured with the "SMTP Server" set to "192.168.1.7," or whatever address you assigned to the gateway. In addition, external mail can initiate connections with the server so that mail can be received from outside mail servers.

Note that all connections initiated by the server will use the primary network configuration, the one that is configured in the TCP/IP control panel. This is important, since it's the only way for mail to get out from our mail server to the Internet.

Other services can be provided bye using Proxy servers. A proxy is a service that processes transaction on behalf of downstream clients. For example, a Web proxy accepts requests from local clients (on the bogus network) and processes the requested transaction (on the real Internet connection), ultimately returning the Web page to the client. If you would like to try this out, grab a copy of WebDoubler, from Maxum Development, for testing.

For e-mail and Web service, as well as other protocols for which proxies are available, this setup works fine. However, what do we do if another protocol is needed? Also, while OT supports multiple IP addresses beautifully, it currently only supports one physical network interface. This means that both the bogus and real IP addresses must share the same physical connection (most likely Ethernet). If you've got a small network with several Macs, one of which has a modem, this just won't do.

A More Robust Solution: Full Routing

A router can be used to support any protocol you might choose, and to support multiple network interfaces. Sustainable Softworks has a Macintosh software router called IPNetRouter that I think is so cool, it's now bundled with every copy of WebDoubler.

IPNetRouter isn't the simplest program in the world to use, but then routing TCP is not trivial. Still, without too much trouble we'll have our private network on the Internet in just a few minutes.

First, we set up our Internet-connected private network with the Mac that will perform the routing. If your connection to the Internet is via Ethernet, then an existing server is a good choice for your router. If you want to provide Internet access to the LAN using a Mac connected to the Internet via modem, then the router must be the Mac with the modem installed.

The router Mac must have Internet connectivity, with the TCP/IP control panel correctly configured. If you have created an "IP Secondary Addresses" file as described above on the router Mac, you need to get rid of it. IPNetRouter controls all of the addresses, so move the file out of the preferences folder, or open the file and remove or comment out any lines that configure an interface. Once the router is connected to the Internet, download a copy of IPNetRouter from http://www.sustworks.com/.

A fully-functional demo version is available, and works perfectly for testing. As of this writing, version 1.3.3 is the latest. The screen shots use IPNetRouter, version 1.3.3.

When you launch IPNetRouter for the first time, the "Interfaces" window opens with two pre-configured interfaces. The first line is an Open Transport internal interface (technically a "loop-back" interface) and can be ignored. The second shows the "Primary Interface" for the Mac, as defined in Open Transport in the TCP/IP control panel.

Figure 3. IPNetRouter Initial Interfaces Setup

Now for the interesting step: You must configure an interface for the private network. In the "Configure Interface" group box, set the pop-up menu to "Ethernet," "Ethernet built-in" or whatever network adapter the router uses to physically connect with the private network. On a modern PowerMac with built-in Ethernet, this is most likely "Ethernet built-in." Next to this pop-up menu, the "Interface Name" is automatically generated, so click the up-arrow button to specify a new interface with the same name but with ":1" appended to it.

Next, enter the bogus IP address assigned to the router into the field underneath the "IP Address" column. I like to use one of my reserved addresses, and in this example, we will enter "192.168.1.1." The next field, "Mask" should be assigned the value "255.255.255.0."

At the bottom of the "Configure Interface" box are a series of checkboxesCheck "Bring Up," and be sure all the other boxes are unchecked. Finally, click "Add" to add this network interface to the table. When you are done, the Interfaces window should look something like this:

Figure 4. The Completed Interfaces Window

The router is now ready to connect our private network the Internet, but before we go any farther, save your work. Choose "File/Save As..." and give the configuration a name like "Private LAN Config." Note that since IPNetRouter is an application, it must be started for routing to work. Double click the configuration file you just saved to start IPNetRouter with the proper configuration. In fact, for long-term use, you will want to put an alias to this file in your Mac's Startup Items folder.

The next step is to make a few changes to the TCP/IP configuration of the machines on the private network. We now have a router, which will need to be specified, and we also want to enable DNS resolution. On the first machine on the private network, set the Address as "192.168.1.3," the subnet mask as "255.255.255.0," the router address to "192.168.1.1" and the domain name server address as you would normally. When you are done, you should have something that looks vaguely like this:

Figure 5. Bogus TCP/IP Config, Ready for Routing

Close the TCP/IP control panel, save your changes, and try it out. Open a Web browser, and surf to your favorite Web site. You should have complete Web access, as well as e-mail and other protocols. Of course, while you now have access to the Internet, the Net does not have access to you. The TCP/IP address "192.168.1.3" is not routable, and machines outside of your network can not establish a connection to your Mac.

While this is an extremely secure setup, there is a drawback to external machines not having access back to your Mac. Some protocols sometimes initiate connections from the server to the client, as well as from client to server. Since external machines can't access addresses inside your network, servers that attempt to establish a connection back to the client will fail. This is most often a problem with FTP, the most popular protocol where this occurs. Fortunately, FTP supports client-only establishment of connections, using "Passive Mode" transfers. To use FTP on a private network, you will always need to configure your FTP client to use "Passive Mode" transfers.

One Step Further: Limiting Access

Our private network now has full Internet access, even if the private LAN is on Ethernet and the Internet connection is provided via a modem or some other interface. The LAN is protected from external access, and can run on the same physical wiring along with fully configured machines. This allows an organization to use a private network for all client workstations while using a few dedicated and directly connected Macs for Web, e-mail, and other services available to the outside world.

Our final step is to limit Internet access for clients on the private LAN. This is done to completely restrict access to a certain protocol, but is more commonly used to force clients on the LAN to use a proxy or other gateway. For example, many schools and organizations use filtering software to block access to inappropriate Web sites. The problem with this solution is that clients can easily reconfigure the browser to circumvent the proxy, and gain access to any Web site. Using IPNetRouter however, we can disable direct Web access by clients on the LAN, forcing them to go through the proxy. This is exactly what we will do in the following example, although other restrictions are easy to add.

To restrict access, IPNetRouter can be configured with filters. Filters are rules that determine what TCP/IP data packets are routed and which are dropped. Configuring filters is done on the "IP Filtering" window, so choose "IP Filtering" from the "Windows" menu to get started.

Filters are be initiated when certain criteria are met. When a filter is triggered, it may tell IPNetRouter to either pass or reject the packet. Exactly what happens when no filter is executed is a bit convoluted, so I always start by creating a filter that defines the "default" behavior. For now, we will make the default behavior pass all traffic that does not match a filter. The other option is to reject all traffic by default, and then create filters to pass the traffic that we need.

To create the "default" pass filter, use the fields in the "Configure Entry" group box. These fields line up under the columns in the table. For private networks on Ethernet, choose "Ethernet" or "Ethernet built-in" for the "Port Name" field. The "Direction" field should be set to "Send" because we need to filter data being sent to the port. The default "Action" is to "Pass" all packets, and the "Protocol" can be left at "Any."

The last three fields determine the condition that must be met for the filter to trigger. So that the filter will trigger on all data packets, choose "Dst" and leave the "Network#" and "Port#" as asterisks ("*"). This tells IPNetRouter to trigger the rule when the data packet's destination is any address on any port, which of course is always the case and so will always trigger the filter. To save the filter, click "Add," which adds a line to the filter list. The next step is to add a filter that rejects traffic that is not permitted. The Port Name should again be set to "Ethernet" and the Direction is "Send." This time, select "Reject" as the Action, but, again leave the Protocol set to "Any."

In this example, we need to block all Web traffic, which is done by denying any data packets being sent to remote servers on port 80, the standard HTTP port. To do this, set the "Src/Dst" field to "Dst," the Network number to an asterisk, and the port to 80. This will cause the filter to reject all data packets destined for any server on port 80. Click "Add" to save the filter. Note that the filter is added to the top of the list, and the default filter has been moved down one spot. The filter list is evaluated in order, from top to bottom. By inserting the reject filter before the default pass filter, IPNetRouter applies the reject filter first, essentially overriding our default pass filter when appropriate.

Once both filters have been added, close the window and return to the client Mac. Web access should now be disabled, although e-mail and other protocols should function normally.

One final problem remains if you want to use the Web through a proxy server. The proxy itself must be given Web access, even if it running on the same machine along with IPNetRouter. To do this, we need to create one more filter. Open the IP Filtering window again, and reset the Port Name to "Ethernet" and the Direction to "Send." This time, the Action is to "Pass" the data, since we need to enable Web access from the proxy server. Leave the Protocol at "Any," as before. In this filter, the decision to trigger the rule is not based on where the packet is going, but from where it is coming. So, choose "Src" and enter the real IP Address of the proxy server (which is probably also the Mac running IPNetRouter). You can set the Port to 80 or leave it as an asterisk. Click "Add" to save the new filter, which will be inserted above the reject filter, enabling Web access when the packet is sent from the allowed IP address.

In the end, the IP Filtering window should look almost exactly like Figure #, except that the first rule will have your proxy's address as the Network number, instead of the address shown.

Figure 6. IPNetRouter Will Now Force Web Access Through Your Proxy

What Have We Got?

We've covered the basics of three distinct types of private networks: stand-alone, application-level routing (gateways), and fully routed. These networks are perfect for test LANs, small workgroups with very light Internet needs, or even large networks with high-speed, dedicated Internet connectivity.

Our local users can send and receive e-mail and surf the Web, or more if we choose, with either gateway-connected or fully-routed networks. In the process, we have created an extremely effective firewall, since there is still no way for users on the public Internet to access those bogus network workstations. At the same time, life becomes easier for you as the network manager, because you've now got full control over Internet usage and IP configuration.

---

John O'Fallon is president of Maxum Development http://www.maxum.com/, a vendor of Web tools for Mac and Windows users.