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


Troubleshooting Tips

First Check!

Quit IPNetRouter before doing any changes to the TCP/IP control panel.

1. You MUST make sure that TCP/IP is NOT set to "Load Only When Needed".

Open the TCP/IP control panel on the machine running IPNetRouter. Beneath the "Edit" menu select "User Mode...". Choose "Advanced". Click "OK". You will then see an "Options" button in the TCP/IP control panel. Click it. Make sure that TCP/IP is "Active" and the "Load only when needed" checkbox is UNCHECKED.

After making the above changes, switch back to Basic mode, close the TCP/IP control panel, and restart your machine. Relaunch IPNetRouter. You just might be surprised to find out that everything works!!

2. IF you are running IPNetRouter with a modem or ISDN terminal adapter (connecting with PPP):

Open the TCP/IP control panel. Your settings MUST display the TCP/IP configuration for your local private network.

Typically these settings will list this machine's address at, have the router address BLANK, and have the correct DNS servers listed for your particular ISP.

If you open your TCP/IP control panel and you see that your PPP TCP/IP settings are displayed, you must change these so that the TCP/IP configuration for your LAN is displayed (made active).


General Information

You may need to launch IPNetRouter from the application once while pressing and holding the Option key down. This tells IPNetRouter to rebuild your link stream with the OTModl$Proxy shared library inserted. Normally this occurs automatically, but may be necessary if you have replaced your TCP/IP Preferences File or determine IP masquerading is not working.

For Mac OS 8.1 or earlier, you may need to restart once after trying to start the Monitor or Router to give Open Transport a chance to build your Link Stack with the OTModl$Proxy STREAMS module.

Do not change the settings in your TCP/IP control panel while IPNetRouter is running. Quit IPNetRouter first, make the necessary changes in the TCP/IP control panel, and then re-launch IPNetRouter.


Understanding the IPNetRouter User Interface

IPNetRouter is mostly a utility for sending commands to the IP Module in Open Transport.

You specify the parameters of the command in the Configure Interface box, and then send the command by pressing the Add or Remove button. The Interfaces table 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 Configure Interface box 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.

There is help available for each window by clicking on the question mark symbol in the lower left corner.


Client IP Addresses Should Not Be Added to the Interfaces Window

One common mistake users make is to add client IP addresses to IPNetRouter's Interfaces window. This won't work. Read the "Troubleshooting Client Addressing in the IPNetRouter Interfaces Window" web page to understand what to do instead.


Config App Not Working

The Config App utility is designed to work with common Internet sharing configurations. In some instances, the Config App may not work due to limitations on your ISP's network, complexity of setup required, etc. If it does not work for you, try manually configuring the "IPNetRouter" application directly. There are examples in the IPNetRouter guide that describe how this is done based on the Internet connection you wish to share.


Identifying Problems and Getting Help

TCP/IP networking has many components which can be intimidating when something doesn't work. The key to troubleshooting network problems is to recognize the sequence of components and look at each one individually to see what isn't working.

You can use the tools in IPNetMonitor to verify whether each leg of your network is functioning correctly. From the gateway machine, you should be able to ping hosts on both your LAN, and the public Internet. From a client machine, you should be able to ping the gateway, and hosts on the public Internet. You can use the Monitor tool in IPNetMonitor to see your ping datagrams leaving one machine and arriving at another. Red bars indicate transmit data while green bars show receive. On the gateway, you can see data being received on one interface (green) and being forwarded out another (red). [IPNetMonitor is distributed as 21-day trialware.]

Check that you have specified the correct Name Servers on each machine and that you can ping to them. If your ISP didn't give you any Name Server addresses (because they want you to use DHCP), you can use IPNetMonitor to find your default Name Server. Once your gateway is connected, launch IPNetMonitor and press Cmd-L to open the NS Lookup window. Then press Cmd-T to begin a ping test to your default Name Server (used by the NS Lookup window). The IP address of your default Name Server will appear at the top of the Ping window.

IPNetRouter (IPNR) is mostly a utility for sending commands to the IP module in Open Transport. When you save an IPNR configuration, IPNR writes a plain text file that lists the commands needed to restore this configuration. Each line generally corresponds to a row in the Interfaces, Routes, Port Mapping, or Filter windows.

Here's an example of an IPNR configuration file for a PPP dialup connection:


Notice you don't need to copy down the window contents or send a screen snapshot to describe your configuration, select File->Save to create a configuration file, and then drag-and-drop your configuration file into your email editor. If you are still having trouble and would like me to help, please include your IPNR configuration as above and the output of the IPNR Log Window. This will allow me to see your entire IPNetRouter setup.

For me to find "a problem", we need to know specifically what didn't work. The IPNR configuration file showing the commands to be executed along with the IPNR Log Window output that shows the result of each command usually provides vital information.

If a saved IPNR configuration isn't working, try recreating your desired configuration (per the instructions on our web site) and Saving it only after you have tested to see that it works. Saving and reusing a configuration that doesn't work may only perpetuate the problem.

You can edit IPNetRouter saved configuration files using any text editor such as SimpleText. BBEdit Lite is particularly convenient because it allows you to edit a file without changing its file type and creator (so it remains an IPNetRouter document). If your editor does change the file type and creator, you can drop the resulting file on the IPNetRouter application to invoke it explicitly and then do a Save As to store this configuration as an IPNetRouter document. The command syntax is described on our web site.


Using PPP with IPNetRouter

You should not have a PPP configuration as the primary interface in the TCP/IP Control Panel.

If IPNetRouter is interrupted during a PPP connection attempt, IPNetRouter may be unable to restore the currently selected configuration in the TCP/IP control panel. In this case, you may need to manually select the desired configuration in the TCP/IP control panel to restore normal operation.


Configuring TCP/IP to use PPP

See other section (e.g. FAQ, Getting Started, etc.) for more info about using PPP with IPNetRouter. (Note: These instructions may not apply to configuration if you are using a PPPoE client such as EnterNet. If you are configuring a DSL connection, see the "PPPoE DSL" topic.)

In the TCP/IP Control Panel, select "Configurations" under the File menu. You must have at least two configurations:

  1. A PPP configuration named "IPNetRouter". This configuration must not be active, but you still need to have it so OT/PPP can find its configuration in the TCP/IP Preferences File. This configuration must be set to allow PPP to connect automatically when launching TCP/IP applications (otherwise the PPP configurator will fail to build a PPP link stack). Notice in Mac OS 8.5 the "PPP" control panel has been renamed "Remote Access."
  2. An Ethernet (or MacIP) configuration with some other name (not "IPNetRouter"). This configuration should be made the primary TCP/IP control panel's interface on your gateway (the TCP/IP configuration you see when you open up the control panel).
  3. In both configurations above, you must uncheck "Load only when needed" in the TCP/IP Control Panel's advanced user options dialog. In the same dialog box, you must make sure that both have been made active by the appropriate radio button.

PPP Gateway's LAN Client(s) Fails to Retrieve DNS Info When or Just After PPP Dials

A clever work around for this problem is to enter the IP address of your Name Server(s) more than once in the TCP/IP control panel. This way when the Local Resolver times out after trying each Name Server the first time, it will proceed down the list and try again giving your router a chance to finish connecting to the internet before giving up.

See other sections (e.g. FAQ, Getting Started, etc.) for more info about using PPP with IPNetRouter.


Cable/DSL Modem and Single Ethernet

Drawbacks to deploying the single ethernet solution include the inability to use the DHCP server properly, potential IP and Appletalk conflicts, etc. that would not be seen on a dual physical interface configuration. In the guide, this is explained in detail towards the end of the Single Ethernet chapter.

It is possible someone else on the cable modem network will try to use the same IP addresses suggested in the getting started example on our web site--an IP conflict. If this happens, you would see the following message:

Another device on your TCP/IP internet, which has the physical address 00 10 XX XX XX XX, is currently using the same IP address (dd.dd.dd.dd). Your TCP/IP network interface has shut down.

Notice the IP address reported (dd.dd.dd.dd) may be the address specified in your TCP/IP control panel even though it is the LAN IP address ( that is in conflict. The warning dialog doesn't realize your machine can have more than one IP address.

To work around this problem, you can choose a different sequence of IP addresses for your private LAN. If your LAN is currently using, for example, you could change the 3rd octet to create a different set of addresses:,

Alternatively, you can change to a Dual Ethernet configuration to isolate your LAN from the cable modem network. This makes your private IP addresses truly private (no one else will see them).


Common Ethernet Problems

One major source of problems is bad or no wiring. Check all cables and ports to make sure everything is connected properly. Some ethernet cards will not be recognized by the OS unless they are actually connected to another powered ethernet device via an ethernet cable. Check to make sure you do not have a crossover cable in a regular port when that would not be appropriate. Verify that you can get link lights and that ethernet over Appletalk works (Filesharing). Next, verify that TCP/IP can be used without IPNetRouter. If both are true but you cannot get IPNetRouter to route IP please review the rest of this section.

Some ethernet cards and drivers are not compatible with one another. In many cases, two cards from the same manufacturer (e.g. Asanté, MacSense) may conflict with one another. A simple solution in this case is to install drivers and cards from two different manufacturers. IPNetRouter 1.5 fixes an incompatibility with some cards (e.g. Farallon) that have spaces in their driver names. Apple broke most ethernet drivers in OS 9. Some NuBus cards work better without their drivers or with older drivers, depending on the Macintosh OS. Many older SCSI-Ethernet solutions only work on certain 68k machines. A few cards do not work well with particular machines or in certain slots (Asante). Search our nettalk archives for information on a particular manufacturers cards and solutions found by users. Make sure that you have the latest available drivers and that they are compatible with your gateway machine's OS. Verify with the card manufacturer that your machine should work with IPNetRouter in the configuration you are trying to setup.

Some hubs and switches are not compatible with some cards and/or Macintosh built-in ethernet implementations. See the Tech Support Area at Apple's web site for various tech notes and software that can be used to resolve these problems.

Using Two Ethernets on NuBus Macs

If you have a NuBus Ethernet card in addition to "Ethernet built-in", you should use the TCP/IP control panel to configure Ethernet built-in, and IPNetRouter to configure any remaining NuBus cards. This TCP/IP configuration must be active. That is, you must have the port connected to another active Ethernet device (typically a hub). If you try to use the TCP/IP control panel to select a NuBus Card as the primary configuration, multihoming may not work due to a limitation of the Ethernet driver on these machines.

If your machine doesn't have built-in Ethernet, put the cable modem Ethernet interface in the lower NuBus slot (towards the outside of the case first).



IPNetRouter works with PPPoE, typically over DSL connections. However, you may need to setup your IPNR gateway in a very specific order, depending on the connection client your ISP has chosen to use. There are some other limitations, depending on which implementation you have, etc. Note, if you have any Vicomsoft software installed in your system this must be removed first. If your DSL modem and LAN clients are directly connected to the same hub/switch, LAN limitations described for other single ethernet configurations may apply.

MacDSL, T-DSL, Alcatel USB DSL, EnterNet (Remote Access PPPoE)

Internet sharing should be setup using the Remote Access example described in the IPNetRouter guide.

EnterNet, MacPoet, Sympatico (non-Remote Access PPPoE)

Use the setup procedures detailed in the PPPoE chapter of the IPNetRouter guide to share your DSL connection. In some PPPoE configurations, especially dual ethernet configurations, a "dummy" IP interface may need to be created on the physical ethernet interface used by the PPPoE driver. Add a private, "dummy" LAN subnet interface (192.168.x.1) different from the one you plan to use for your own private LAN on the other physical interface. Next, add the "true" subnet to the other (non-PPPoE) physical interface (usually your second ethernet card or AirPort interface). This has been shown to work in instances where the two physical interfaces are known to be compatible with multihoming. To check for compatibility with IPNetRouter IP multihoming, see the "Common Ethernet Problems" topic.


AirPort File Conflicts & Updating AirPort Software

Apple's Software Base Station (SBS) uses a licensed version of IPNetRouter supplied as a Faceless Background Application (FBA). Because this is mainly where potential conflicts arise, it is important to be aware of this. We currently try to support IPNetRouter 1.4.7 or later with AirPort 1.2 software. We strongly recommend that you install/update to AirPort 1.2 or later to minimize conflicts between AirPort and IPNetRouter. Older versions of the AirPort software have additional conflicts not covered here. Installing AirPort software may remove our "OTModl$Proxy" extension and replace it with a possibly older version named "AirPort AP Support".

To minimize the potential for compatibility problems between AirPort and IPNetRouter, remember to reinstall IPNetRouter, and any other third party networking software (like PPPoE client software), after installing or updating any Apple AirPort software.

The complete list of files that are functionally equivalent to one another are:

AirPort File IPNetRouter File Location Purpose
AirPort AP IPNetRouter.FBA Extensions folder FBA
AirPort AP Support OTModl$Proxy Extensions folder Shared library
AirPort AP Configuration Router Config Preferences folder default IPNetRouter configuration

Using Apple's Software Base Station mode can enable and/or create some of the potential conflicts so familiarizing yourself with our notes here may be important in resolving conflicts that may arise when using IPNetRouter.

In AirPort 1.2, enabling Base Station mode will create the "AirPort AP Configuration" file if the "AirPort AP" extension is present in the Extensions folder. These two files may override IPNetRouter's own saved configuration file when you reboot the Mac. (In earlier versions of AirPort, there are even more potential conflicts so update to 1.2 if you've got an earlier version!) Since these files are not required to use IPNetRouter with AirPort, you can disable them using the Extension Manager control panel if you wish. (We do not recommend that you delete them since you might want to reenable them should you want to use Apple's gateway software instead of ours.)

See our AirPort and IPNetRouter web page for more discussion of AirPort configuration with IPNetRouter.


"VICOM" Conflicts

Vicomsoft's Surfdoubler, Softrouter, and Internet Gateway are not compatible with IPNetRouter. This incompatibility severely increases the likelihood you will see network interface bringup problems when trying to configure IPNR.

A Vicomsoft system extension file named "-Gateway-" is chiefly the cause of this incompatibility. Vicomsoft apparently does not provide a way to automatically uninstall this file from your system. Before removing this file, make sure that IPNetRouter and your TCP/IP control panel are not open and that you have no network applications running. Drag Vicomsoft's "-Gateway-" file to the desktop or use Extension Manager to disable it. Reboot immediately following this removal. The "VICOM TCP/IP" choice in your TCP/IP control panel should now no longer be available and you may now configure IPNR without worrying about this incompatibility. You should also no longer see the term "VICOM" anywhere in your IPNetRouter log window following this removal.


Network Time Server Issues

Apple's Network Time Server, included in the Date & Time control panel starting in OS 8.5, may not work correctly unless you use large time intervals (10+ hours) between synchs.

Also, this feature may cause your gateway to continuously try to reconnect if it is set anywhere on the LAN to synch frequently. There are several solutions for related issues if you require more precise time or are experience trouble with a particular network time server.

We encourage you to search our Nettalk archives on the terms "time troubles" as an exact phrase (don't include the quotes and set the date field to "any") to see a host of interesting information about times servers, alternatives to Date & Time control panel, etc.


Problems With MacPPP

MacPPP was installed in the very early releases of Open Transport. Various versions of MacPPP were also available as shareware. None of these versions is supported by IPNetRouter. Apple replaced MacPPP with OT/PPP. IPNetRouter is designed to work with OT/PPP. See the FAQ page for info about FreePPP and ARA.


"Thread Manager Required"

Message appears on 68k OT 1.1.1 or earlier system, even after Thread Manager is present. Install OT 1.1.2 and the installer will work correctly! This is probably a bug in ASLM.


MacOS 9.x Compatibility

MacOS 9.0.x introduces Open Transport 2.5 & 2.6 and other significant changes that effect IPNetRouter. MacOS 9.1 uses OT 2.7.4. The main changes from MacOS 8 are:

  1. Apple changed ethernet significantly in MacOS 9, adversely effecting 3rd party ethernet drivers, especially in dual ethernet configurations.
  2. AirPort Software is included as part of the MacOS.
  3. Apple Remote Access Server is now included with MacOS 9.0. This includes the ARA Client that has been present since MacOS 8.5.
  4. MacIP is no longer supported over LocalTalk.
  5. The Multiple Users control panel was added.
  6. Software Updates cannot be update the IPNetRouter Mac while IPNetRouter is running.
  7. New File Sharing implementation.
  8. Various bug fixes and additions, especially for DNS, DHCP, and PPP dialup handling.
  9. In 9.1, Apple removed the ASLM extension. This does not effect IPNetRouter but may make some Remote Access control strip modules, etc. fail.

How does this affect IPNetRouter?

  • We recommended that you use IPNetRouter 1.5 or later with OS 9. IPNR 1.4.7 or later is supported. As always, be sure to read the accompanying Read Me and release notes documents carefully before running IPNR.
  • If you have ANY 3rd party ethernet cards installed, verify with the manufacture that you have the latest MacOS 9.x compatible drivers installed if you encounter any problems with IPNetRouter. Apple broke the ethernet drivers of most 3rd party vendors in OS 9; you MUST have Mac OS 9 compatible drivers for the card(s) to function properly. These drivers are only available from the card manufactures. If there is no MacOS 9 updates available for your particular card, you may not be able to get it to function properly with IPNR on OS 9. The best solution if there are no compatible drivers available is to revert to an earlier version of the Mac OS that does support a non-Mac OS 9 compatible driver or to buy a Mac OS 9 compatible card. NOTE: This is a very good reason not to upgrade nubus Power Macs to OS 9 unless you are certain the card is supported in OS 9. ALSO NOTE: Madge PCI Token Ring cards have been shown to work on OS 9.0 with IPNR and built-in Ethernet. See also the "Ethernet" topic for more info on general ethernet troubleshooting.
  • The following Mac OS 9 System software updates are required for IPNR to function correctly with versions of MacOS 9 prior to the release of 9.0.4:
    1. You SHOULD update your version of Open Transport to OT 2.6.1. This update is available from Apple's web site and is installed with MacOS 9.0.4.
    2. You MUST update any installed AirPort software to version 1.2. Earlier versions are not as compatible with the IPNR software. This problem occurs even if you do not have any AirPort hardware installed--you MUST update installed AirPort software for IPNR to function correctly in ALL cases. This update is available from Apple's web site.
  • Treat AirPort cards as if they are Ethernet ports for purposes of configuration with IPNetRouter. See the AirPort section of our web site for more info on using AirPort with IPNetRouter. There is also an AirPort troubleshooting topic that discusses upgrades and potential file conflicts.
  • Mac OS 9 comes with Apple Remote Access (ARA) Server installed by default. See the IPNetRouter FAQ page for more info regarding ARA and IPNR.
  • Don't upgrade to OS 9 if your router depends on MacIP over Localtalk to support your LAN. Sadly, Apple neglected to support MacIP over Localtalk in OS 9. See Apple's Technote for the poop.
  • OS 9 comes with a new Multiple Users control panel. If your machine is configured for more than one user you may have a problem running IPNetRouter. This problem occurs because each user has a separate system preference folder. There are two workarounds to getting IPNetRouter to work on machines with multiple users.
    If you are using Multiple Users on your IPNetRouter gateway, install the latest version of our Faceless Background App of IPNetRouter. It runs independently of the Multiple User API interfaces. You can download the FBA from the IPNetRouter download page elsewhere on this site. Note: You still have to configure the Faceless Background App using a regular copy of IPNetRouter first.
    The alternative is to install IPNetRouter for each user. This is not recommended due to complications of licensing, installation, etc.
  • Starting in OS 9.0, Apple began providing periodic Open Transport updates through the new Software Updates feature. If you have a DSL connection that use an EnterNet PPPoE driver to connect to the Internet you may need to reinstall this driver after updating OT.
  • See the FAQ page for additional information regarding Software Updates and related installer compatibility issues with IPNetRouter.
  • File Sharing in OS 9 is a an implementation of Open Door Network's ShareWay IP software. It now supports file transfer via TCP/IP. If you wish to Filesharing over IP on both the local LAN and the internet, map the AFP port to the appropriate interface on your gateway using IPNetRouter's port mapping feature. Which interface this is may differ depending on your gateways configuration.


MacOS 8.5 Compatibility

MacOS 8.5 introduces Open Transport 2.0 with a number of changes. The main changes are:

  1. OT/PPP is replaced with Remote Access (the full ARA 3.0 client that supports AppleTalk over PPP and ARAP).
  2. A new much faster Ethernet driver for Ethernet built-in.
  3. Improved Finder copy code.
  4. Various bug fixes and additions for developers.

How does this affect IPNetRouter?

  • Previous versions of IPNetRouter may not complete PPP connections successfully with Remote Access. You should download IPNetRouter 1.3 or later to work around this problem.
  • Some 3rd party Ethernet drivers are not compatible with Mac OS 8.5. The Farallon driver for the PN593-C/PN893 (Etherwave/EtherMac) will fail under System 8.5 due to a problem with Apple's ENet driver. The solution is to remove the Apple Enet extension.


DHCP Related Problems

If your IPNetRouter gateway has a DHCP connection as its primary TCP/IP control panel setting (the IP Masqueraded interface), make sure that the TCP/IP control panel is in Basic user mode. There is a bug in Open Transport that prevents proper forwarding of DHCP generated name server IP information to client computers if the gateway Mac is not in Basic mode.

See the "DHCP and MacOS" section for information about how DHCP behaves with different versions of the MacOS (Open Transport). There are more links to other resources dealing with DHCP on that page.

How to use the DHCP Server feature of IPNetRouter is explained in the "Using The DHCP Server" section.

You should not use IPNetRouter's DHCP server with a single ethernet configuration in conjunction with a cable or DSL modem. The DHCP server can be used, when properly configured, with a regular modem or in a dual ethernet or AirPort configuration.

IPNetRouter's DHCP server is still being improved. If you have an older version of IPNetRouter, check the latest release notes on our web site to see if there have been any improvements to the server that you might benefit from.


Installing Over Another Version of IPNetRouter

The standard installer is designed to install a newer version over a previous one. If you have any trouble, the following steps will insure the application is installed correctly.

  1. Find any previous version of OTModl$Proxy in your Extensions folder and move it to the trash.
  2. Remove any previous version of the IPNetRouter Application.
  3. Run the correct IPNetRouter installer for your machine (PPC or 68K) to install the desired version of IPNetRouter.
  4. Restart your computer (this step is very important). The installer only "suggests" you restart because it isn't always necessary, but you should do this if you are not sure.

    I recommend against using the "uninstaller" if you are just going to re-install the application. The uninstaller is for removing IPNetRouter completely and makes it harder to re-install. If you do use the uninstaller, here's how to complete the re-install process.
  5. Hold down the Option key when you launch the IPNetRouter application the first time after re-installing. Continue pressing the option key until the application comes up. This forces Open Transport to rebuild your link stream.
    - or -
    Alternatively, configure IP masquerading, and then Restart your Mac yet again.

The purpose of step (5) is to give Open Transport a chance to rebuild your link stream with the Proxy module inserted. You can verify this was successful if you are able to use the Monitor tool in IPNetMonitor to monitor IP traffic on the interface you will be using to masquerade.


Unix or OS X LAN Clients DNS Problem

OS X and other OSes using BSD socket based networking are not compatible with IPNetRouter's DNS Forwarding feature. Setup your OS X or other Unix based LAN client's using your ISP's domain name server's IP address. Macs running 9.x or earlier and other PCs are not effected by this incompatibility.


Troubleshooting OS X Clients

See our temporary OS X troubleshooting page for now.


Email on LAN Clients

Email and Browser applications running on the client machines should have their servers (such as mail and news servers) set to the standard values specified by your ISP. You may, however, have to use fully specified domain names for Mail servers when accessed from your client machines. For example, instead of just using "mail" for the SMTP mail server, you might have to fully specify the name like "".

Remote email servers may have security requirements that may effect emailer behavior. Usually, this is so to prevent spamming (junk emailings) through the server. Some email servers require that you login and download mail before you can send mail--sometimes you have to wait about 10 seconds after the login completes before attempting the upload. Other email servers will not let you upload mail if you do not have an "approved" IP address (typically one on the public ISP network). Since some email servers will not block email transfers if your emailer application does not forward this information, you may be able to workaround the security feature by using an emailer that does not send the IP address of your client machine.


"Enable Local NAT" Does Not Turn On NAT For Internet Sharing

That's right, it does not. Network Address Translation between the public IP address and your LAN is activated when the public IP interface has the IP Masquerading option added to it in IPNetRouter's Interfaces window. When the "Enable Local NAT" option is checked, datagrams from the non-IP Masqueraded interface(s) addressed to the public IP (Masqueraded) address of the gateway are port mapped to machines behind the gateway prior to routing. If experiencing problems accessing or using the gateway machine for an IP service, try disabling this option until the problem is resolved.

For more information on how "Local NAT" works in IPNetRouter review the "Inbound Port Mapping" chapter in the manual. To setup your gateway for Internet sharing using NAT, refer to the "Getting Started" examples.


Approved IP Addresses for Private Networks

The approved address ranges for private LANs are defined in RFC-1918, an Internet standards document. They are: - (10/8 prefix) - (172.16/12 prefix) - (192.168/16 prefix)

Use only subnets within these ranges on a private LAN.


Use "" as the Subnet Mask for Your Private LAN

Most examples in the IPNetRouter guide show the use of a subnet mask of for a private subnet. Use this subnet mask for your private network unless you have good reason to use a different mask. For more about subnet masks, see the "Net Masks and the Subnet Calculator" web page.


IPNetSentry Compatibility

Refer to IPNetSentry's installed documentation if experiencing problems with an IPNetRouter gateway Mac with IPNetSentry installed. See also the IPNetSentry FAQ page on our web site.

One way to determine whether IPNetSentry is working correctly with IPNetRouter is to turn off IPNetSentry using its Companion Application. Unless you disable the "IPNetSentry.PPC" in your system's Extensions folder IPNetSentry will run when you restart your Mac. IPNetSentry continues to run while this file is in the Extensions folder, even if IPNetSentry's evaluation period has expired. (IPNetSentry continues to alert you to hits after its evaluation period has expired; registering the application permits you to use the automatic blocking and other significant features of IPNetSentry.)

Older versions of IPNetRouter and IPNetSentry may not install a compatible version of the OTModl$Proxy file. Upgrade to the latest versions of both applications to improve OTModl$Proxy compatibility. Refer to the installed documentation and our web site for more information on the OTModl$Proxy file.