Inbound Port Mapping
- Port Mapping in IPNetRouter
- IPNetRouter, DNS, and Enabling Local
- Port Mapping and Generic
- Using The Exposed Host Feature
- NAT and DNS Information Resources
Port Mapping in IPNetRouter
IPNetRouter provides a feature called "IP Masquerading"
that allows you to connect multiple hosts to the Internet using
a single user ISP account and single public IP address. This saves
you the cost of setting up multiple accounts or getting a block
of globally unique IP addresses assigned that your ISP must route
(and will charge you for).
IP Masquerading works using a technique called "Network Address
Translation" (NAT) with extensions for "Port Multiplexing"
(NAPT) and "ICMP Translation". The basic idea is to disguise
IP packets to or from your private LAN so they appear to the rest
of the Internet as if they are only originate from your gateway
machine's Internet IP address. The Network Address Translator in
IPNetRouter is implemented as a module that sits between your gateway
machine and the public Internet. When the Translator sees a packet
from your LAN that doesn't originate from the gateway, it changes
the source IP address of that packet to the IP address of the gateway
machine. In order to keep track of which host on your LAN the packet
came from, it also assigns it an unused protocol port number on
the gateway machine. Whenever a response is received at that port
on the gateway, the Translator knows to reverse the process substituting
the original IP address and port number on your private LAN.
The effect is to hide multiple hosts behind a single public IP
address. Notice it is the action of sending a packet from the LAN
to a host on the Internet that creates a return translation entry.
Until a host on the LAN initiates contact, it is invisible to the
public Internet. It has no public IP address and traffic addressed
to the gateway machine is not forwarded to the LAN since there is
no reverse translation entry. It passes through the NAT module unchanged
so remains addressed to the gateway (unless a different Exposed
Host is set). IP Masquerading acts like a firewall allowing you
to access the public Internet from inside your LAN, but not the
other way around.
This arrangement is ideal for surfing the web from your LAN since
each time your web browser requests a page, it creates a reverse
translation entry allowing the requested web page to be returned
through the NAPT gateway. Suppose you want to run a server on your
private LAN and make it visible to the public Internet. You could
run all your servers on the gateway machine which is visible to
the public Internet, but this might not be the most convenient way
to arrange your network. In order to allow servers on your private
LAN to be visible to the public Internet, we need a way to create
a reverse translation entry without initiating the connection from
your private LAN. This is the purpose of "Inbound Port Mapping".
Inbound Port Mapping allows you to manually create a permanent
translation entry that maps a protocol port on your gateway machine
to an IP address and protocol port on your private LAN. TCP/IP uses
the term "Endpoint" to refer to the combination of an
IP address and protocol port. Every TCP/IP connection exists between
two Endpoints. We use the term "Apparent Endpoint" to
refer to the endpoint on your gateway machine that the rest of the
Internet sees--your LAN's external IP address and port--and the
term "Actual Endpoint" to refer to the Endpoint on your
LAN that forms the local end of a connection; the local LAN IP address
and port for the particular service to be mapped.
To specify an inbound mapping, open IPNetRouter's Port Mapping
window when IP masquerading is enabled for your gateway IP address.
If you uncheck "Show Permanent Only" and press Monitor,
you will be able to see the NAT table in real time (for any connections
in progress). The window help describes how to add or remove your
own mapping entries.
Suppose you have three machines and want to set up a web server
on your LAN as follows:
192.168.0.1 (Gateway machine, IPNR)
192.168.0.3 (Web server)
The apparent address (what the Internet sees) is the public IP
address of your gateway (the floating IP number assigned by your
ISP). This number will be filled in automatically for you in the
Port Mapping window. The Private address is the address of your
web server on your private LAN (192.168.0.3). The port number is
whatever port is used for your server. Web servers usually listen
on port 80.
In the Port Mapping window, you would enter the following in the
"specify entry" area:
Apparent Endpoint Address: leave as already filled in
Actual Endpoint Address: 192.168.0.3
Then press the "Add" button to update the actual record
in the NAT table.
If entered correctly, this would appear in your IPNetRouter log
(if 18.104.22.168 happened to be your gateway's Internet IP address).
See the "Port Mapping and Generic IP Services" topic for
some tips on how to determine what ports any given service might
IPNetRouter, DNS, and Enabling
If you set IP Forwarding to Automatic in the Gateway Window, the
NAT configuration is as follows:
In this configuration, only hosts on the public Internet can access
a server on your LAN using its public IP address on the gateway.
If the LAN tried to access your server via its public address, the
packet would be delivered to the gateway without being translated.
If you check "Enable Local NAT" in the Gateway Window,
the configuration becomes:
In this configuration, if a host on your LAN tries to access a
server on your LAN using its public (port mapped) IP address, the
packet is translated before it gets to the gateway so the gateway
will forward it back out the same interface it arrived from. This
allows you to use the same DNS names to access your servers behind
the gateway regardless of where you are. This feature is not available
in single Ethernet configurations
(with cable or dsl modem--dialup PPP works okay though) because
NAT is disabled on the private network used to communicate with
your LAN (so it can share the same physical Ethernet port with your
public IP address).
Port Mapping and Generic
There are different resources you can use to determine whether
a particular IP service is NAT compatible and whether port mapping
will work in a given situation.
The first step is to find out if port mapping will work at all
and which ports might need to be mapped. Consult the problem software's
web site and documentation for "firewall" and/or "NAT"
compatibility information. Our web site FAQ
page, Nettalk archive,
and other web search engines
can be used to search for information on particular software packages
as well. IPNetRouter can be used to see what ports are being mapped
through the gateway for a particular service and to test if port
mapping is a possible solution using the Exposed Host feature. IPNetMonitor
can be used to determine which TCP/IP ports are being opened by
an application as a possible clue to which ports might need to be
IPNetRouter 1.5 or later has an Exposed Host feature in the Gateway
window. To see if a single LAN client's IP service Internet access
problem can be fixed with port mapping, you can use this feature
to redirect all of the gateways unmapped ports to that client. If
exposing the LAN client through the gateway works for the service
in question then it is likely that port mapping will work for that
service. See the "Exposed Host" topic for more info on
IPNetRouter's Port Mapping window also includes a real-time port
monitoring feature. To see all ports opened by clients on your local
network, uncheck "Show Perm" in the Port Mapping window
and press the "Monitor" button. If you use IP software
on a client that is having problems with NAT, you can see what endpoints
are opened when the client service is used. You may have to sit
in front of the gateway machine to see these transactions as they
are sometimes very quick; get someone else to help you if the client
is physically far away from the gateway Mac. (A logging feature
to avoid this limitation may be added in a later version.) If no
ports are opened in the Port Mapping window when the client software
is accessed then things aren't looking good and you may want to
check that all physical network wiring, client TCP/IP configurations,
etc. are intact and functioning. To see if TCP/IP ports are actually
being opened on the client use IPNetMonitor.
IPNetMonitor's connection list window can be used on a client Mac
to see what TCP/IP ports are opened by a particular IP application
or service. You can download IPNetMonitor
from our web site. As an example, launch IPNetMonitor and then your
browser on a Mac. Open the Connection List window in IPNetMonitor
and position it so that you can observe that window unobstructed
by any browser window that may be open. If the "Monitor"
button is visible, click it. Now, in the browser, connect to a web
site somewhere (e.g. www.sustworks.com). Note the ports being opened.
Now, attempt the same thing with the problem application or service
on the same client. The connection list window only lists TCP/IP
ports so if other protocols are required the only way to figure
this out is via the particular software vendors documentation. Use
IPNetRouter features discussed above to see what's happening on
the gateway at the same time; IPNetRouter's port mapping window
does not have the same limitation.
If the exposed host feature works, you can always use that to get
services temporarily to any particular LAN client suffering behind
the NAT router.
Some services can only be mapped to one client behind a NAT firewall
at a time (those that require a fixed port number); this is a limitation
with any standard NAT router, not just IPNetRouter. A few software
packages have some features that will work through NAT and other
features that won't. Others cannot be made to work through NAT at
all. The best source for authoritative information is the software
also has a description of IP ports used by Appleshare IP and other
Apple software. Our web site FAQ
page covers some of the common application we frequently receive
questions about. Search the Nettalk user email list
archives for user generated information about a package or service
if you do not find any useful info elsewhere on the web.
Using The Exposed Host Feature
The Exposed Host feature in IPNetRouter (1.5 or later) can be used
to make a single host on your LAN visible to the public Internet,
or to prevent unauthorized port access to any host including your
gateway machine. If you are not planning on having anyone access
your private network from the public (Internet) interface, you may
wish to take advantage of this security feature. It effectively
prevents external sources from seeing/accessing your gateway except
when you are using it to access the Internet.
The feature behaves similarly to the "DMZ" (De-Militarized
Zone) feature in other routing solutions. When a packet from the
Internet arrives at your gateway, it is checked against the NAT
table to see if there is a host on your LAN expecting a response
on that port (a matching NAT table entry). If there is no such entry
(host expecting a response), the Exposed Host setting determines
how the packet is handled.
If Exposed Host is set to Gateway (default); the packet is allowed
to pass unmodified so remains addressed to the gateway machine
when it is delivered to the TCP/IP software.
If Exposed Host is set to None; the packet is deleted immediately.
Only solicited or permanently mapped ports are allowed through
to your Gateway or any other host on your LAN.
If Exposed Host is set to the IP address of a host on your LAN,
the destination (IP) address is replaced with the corresponding
exposed host address so the packet will be forwarded to that host
(effectively placing it in the De-Militarized Zone as opposed
to behind your firewall).
Ports mapped by you or created by LAN clients through the public
interface can still be reached externally. For example, if you map
port 80 to a LAN client (or the gateway) then port 80 will be exposed,
even if exposed host is set to "none". See the Firewall
and IP Filtering section for more information on security in
NAT and DNS Information Resources
The basic concept of Network Address Translation (NAT) is described
in RFC-1631, a public internet standards document. IPNetRouter extends
this by adding "Port Multiplexing" (sometimes called NAPT
for Network Address and Port Translation). In addition to translating
between private and public IP addresses, IPNR translates multiple
private addresses to a single public address by assigning unique
port numbers to each protocol stream. RFC-1034 and RFC-1035 detail
how domain names are resolved. You can also read more about this
for "Network Address Translation", "Port Multiplexing"
and "Domain Name Service" on the web.