Quit IPNetRouter before doing any changes to the TCP/IP control
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 192.168.0.1,
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).
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
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
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
In the TCP/IP Control Panel, select "Configurations"
under the File menu. You must have at least two configurations:
- 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."
- 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).
- 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
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
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 (192.168.0.1) 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
192.168.0.1, 192.168.0.2...192.168.0.n for example, you could change
the 3rd octet to create a different set of addresses: 192.168.117.1,
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
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 AP Support
|AirPort AP Configuration
||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
See our AirPort and IPNetRouter
web page for more discussion of AirPort configuration with IPNetRouter.
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
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:
- Apple changed ethernet significantly in MacOS 9, adversely effecting
3rd party ethernet drivers, especially in dual ethernet configurations.
- AirPort Software is included as part of the MacOS.
- Apple Remote Access Server is now included with MacOS 9.0. This
includes the ARA Client that has been present since MacOS 8.5.
- MacIP is no longer supported over LocalTalk.
- The Multiple Users control panel was added.
- Software Updates cannot be update the IPNetRouter Mac while
IPNetRouter is running.
- New File Sharing implementation.
- Various bug fixes and additions, especially for DNS, DHCP, and
PPP dialup handling.
- In 9.1, Apple removed the ASLM extension. This does not effect
IPNetRouter but may make some Remote Access control strip modules,
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
The alternative is to install IPNetRouter for each user. This
is not recommended due to complications of licensing, installation,
- 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
- 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:
- OT/PPP is replaced with Remote Access (the full ARA 3.0 client
that supports AppleTalk over PPP and ARAP).
- A new much faster Ethernet driver for Ethernet built-in.
- Improved Finder copy code.
- 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"
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.
- Find any previous version of OTModl$Proxy in your Extensions
folder and move it to the trash.
- Remove any previous version of the IPNetRouter Application.
- Run the correct IPNetRouter installer for your machine (PPC
or 68K) to install the desired version of IPNetRouter.
- 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
- 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
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
"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"
Approved IP Addresses for Private
The approved address ranges for private LANs are defined in RFC-1918,
an Internet standards document. They are:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Use only subnets within these ranges on a private LAN.
Use "255.255.255.0" as the Subnet Mask
for Your Private LAN
Most examples in the IPNetRouter guide show the use of a subnet
mask of 255.255.255.0 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.
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.