Date: Wed, 9 Oct 2002 00:43:52 -0700 (PDT) From: sonam singh <sonam_singh_s@yahoo.com> To: freebsd-questions@freebsd.org Subject: Re: Puzzling Simple NATD and IPFW Problem Message-ID: <20021009074352.13735.qmail@web40512.mail.yahoo.com> In-Reply-To: <200210081603.AA143786622@mail.mccallie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
assigned, use the command pfctl -sr
6.3 - NAT
Note: Packet Filter is the filtering system in If you
are looking for the IPF/IPNAT FAQ for before, click
here.
6.3.1 NAT Introduction
Based on RFC 1631, NAT provides an easy way to map
internal networks to a single routeable ("real")
internet address. This is very useful if you don't
have officially assigned addresses for every host on
your internal network. When you set up
private/internal networks, you can take advantage of
reserved address blocks (assigned in RFC 1918), such
as:
10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)
The user is assumed to have already set up and
configured an BSD machine with two network cards (one
connected to the Internet and the other to the local
network).
Configuration
For the purpose of example, we will use the system
described below. Your setup will almost certainly vary
from this, so be very careful in typing anything you
see here literally into your system and expecting it
to work as you desire.
NICs:
Intel EtherExpress Pro/100 fxp0
Connected to the EXTERNAL LAN (or WAN)
IP Address: 24.5.0.5
Netmask: 255.255.255.0
Compaq Netelligent 10/100Mb tl0
Connected to the INTERNAL LAN
IP Address: 192.168.1.1
Netmask: 255.255.255.0
External, Internet-routeable IP (provided by ISP, in
this example, a cable modem provider)
IP Address: 24.5.0.5
Netmask: 255.255.255.0
Gateway: 24.5.0.1
Local Area Network
In this example environment, machines on the internal
network use the IP addressing scheme 192.168.1.xxx
(where xxx is a unique number). There could be a
variety of different operating systems on the internal
network, such as Windows 98, Windows NT, FreeBSD and
Linux, but the client OS is not an issue for NAT. For
the examples, the client we will look at on the
internal network will be assumed to have an IP address
of 192.168.1.40.
Diagram of Configuration
+-----+ +---------+ +----------+
| Hub |--------- tl0 | NAT | fxp0 ----| Internet |
+-----+ +---------+ +----------+
| |
| +-- Client A
+---- More clients
+--------------------------+
| LEGEND |
+--------------------------+
| NIC fxp0 - 24.5.0.5 |
| NIC tl0 - 192.168.1.1 |
| Client A - 192.168.1.35 |
+--------------------------+
6.3.2 Network Address Translation
Introduction to NAT
Each node on the Internet requires a unique IP
address. At least with IPv4, there is a very finite
number of distinct IP addresses available, and as a
result, they are not free. Most "low-cost" ISPs will
limit a site to anywhere from 1 to 30 addresses, and
while larger budget organizations may be able to
afford a larger block, in most cases, there are
relatively few benefits and considerable risks to
having each computer individually addressable on the
Internet.
Network Address Translation, or NAT, (also known as
"IP Masquerading" if you are coming from a Linux
background) allows multiple computers to be located
"behind" one (or a small number of) IP address. Each
"internal" computer has a locally assigned,
unregistered IP address (per RFC 1918), and all
utilize the same external IP address, simultaneously.
The way NAT works is rather simple. When a client on
the LAN wants to connect to a machine on the Internet,
it sends out a TCP packet with a request to connect.
Inside the TCP packet header is the client's IP
address (e.g. 192.168.1.40) and the requested host's
IP address (e.g. 123.45.67.89). The machine running
NAT intercepts this TCP packet and changes the
client's IP address from 192.168.1.40 to the IP
address of the Internet-connected machine (e.g.
24.5.0.5). This effectively tricks the host machine
into thinking the actual connection is from the NAT
machine, not the actual client's machine. The host
then sends back responses to the NAT machine like it
was the one connecting. When the NAT machine receives
the responses it quickly translates the destination IP
address back from itself to the client's machine and
sends the packet to the client. The client normally
does not have any idea what happened and the apparent
Internet connectivity is transparent to the user and
user's applications.
The example below shows NAT a little more clearly:
Client ----------------- tl0 [ NAT ] fxp0 ----------
Internet Host
192.168.1.35 --- 192.168.1.1 [ NAT ] 24.5.0.5 ---
123.45.67.89
OUTGOING TCP Packet OUTGOING TCP
Packet
From: 192.168.1.35 >>=== NAT ===>> From: 24.5.0.5
To: 123.45.67.89 To:
123.45.67.89
INCOMING TCP Packet INCOMING TCP
Packet
From: 123.45.67.89 From: 123.45.67.89
To: 192.168.1.40 <<=== NAT ===<< To: 24.5.0.5
Why use NAT?
When presented with a cable modem in my new apartment
I was also presented with another minor problem. How
to get Internet access for my roommates, when the
cable modem resides in my room? There were a few
options I could implement, ranging from obtaining
extra IP addresses, to setting up a proxy server, to
setting up NAT. (Don't let the home cable modem
example fool you. NAT is powerful enough to masquerade
a large network with hundreds or even thousands of
computers!)
There are many reasons why I wanted to set up NAT. The
number one reason is to save money. There are two
roommates in my house, splitting the cost is certainly
attractive. Further, as each roommate has their own PC
and I have three, we had five computers to connect,
but my ISP only allows for three IP addresses per
household. This means that there weren't enough IP
addresses to allow every machine simultaneous direct
Internet access.
By using NAT each machine will have a unique internal
IP address but share the one IP address given to me by
my ISP. The cost goes down.
Setup
In order to enable NAT on your FreeBSD machine you
will need to turn on PF. This is easily accomplished
by editing the files listed below (make the changes to
the file so it looks like the options below):
/etc/rc.conf (this file used to start services at boot
time)
pf=YES
/etc/sysctl.conf
net.inet.ip.forwarding=1
After these changes are made, the machine is now ready
for the configuration of NAT.
Configuration
The first step is to configure the PF configuration
file (/etc/pf.conf). For the purposes of this document
we will allow traffic to pass through this firewall
without any interference. The file should look like
this:
pass in all
pass out all
Again, for more information you can read FAQ 6, Packet
Filter
The NAT configuration file (/etc/nat.conf) has a very
simple syntax. For the configuration set forth above,
the file should contain the following entry:
nat on fxp0 from 192.168.1.0/24 to any -> 24.5.0.5
Here is an explanation for the above lines.
"nat"
This indicates the command you are giving is a NAT
rule.
"fxp0"
This is the network interface that is connected to the
Internet.
"192.168.1.0/24"
the IP address and netmask (the netmask is in CIDR
format). Combined they state "any IP address of value
192.168.1.1 through 192.168.1.254" should be mapped.
"24.5.0.5"
This is the external IP address the internal IP
addresses will be mapped to.
Running
Once the configuration is complete, there are two ways
to enable NAT. The first (and best way if possible) is
to reboot your FreeBSD machine. This is accomplished
with the command "reboot".
If you would like to configure NAT from the command
line, use the following commands:
# pfctl -N /etc/nat.conf
# pfctl -e
The first line is to load a set of NAT rules into PF
(and flushing any old rules), the second line enables
PF. Again, though, rebooting is the best way to ensure
that everything will startup from a reboot as you
expect.
Note: in order to reload the NAT settings (in case you
edit the file but don't want to reboot) just execute
the first command over again. The settings will be
flushed and reloaded.
6.3.3 Nat Knowledge Base
Checking NAT Status
To find out how NAT is doing or make sure the settings
have taken effect, you use the "-ss" option. This
option will list all the current sessions that NAT is
running:
# pfctl -ss
TCP 192.168.1.35:2132 -> 24.5.0.5:53136 ->
65.42.33.245:22 TIME_WAIT:TIME_WAIT
TCP 192.168.1.35:2492 -> 24.5.0.5:55011 ->
65.42.33.245:22 ESTABLISHED:ESTABLISHED
UDP 192.168.1.35:2491 -> 24.5.0.5:60527 ->
24.2.68.33:53 2:1
Explanations (first line, others are similar):
"192.168.1.35:2132"
This tells you the IP address of the machine on the
LAN that is using NAT (192.168.1.35). The port number
used to make the connection (2132) is displayed
afterwards.
"24.5.0.5:53136"
This denotes that the connection is going to the
Internet via IP address 24.5.0.5 and using port 53136.
"65.42.33.245:22"
The IP address and the port being connected to.
"TIME_WAIT:TIME_WAIT"
This indicates what state PF believes the TCP
connection to be in.
Issues with FTP and NAT
There are a few limitations of NAT, the most commonly
encountered is with FTP. You can use FTP in two ways:
passive and active. Of these, passive FTP is generally
considered more secure.
With active FTP, when a user connects to a remote FTP
server and requests information or file, the FTP
client sends the server a random port number that the
FTP server will make a connection to on the client and
transfer the info. This is a problem for users
attempting to gain access to FTP servers from within
the LAN. When the FTP server sends its information it
sends it to the external NIC at a random port. The NAT
machine will receive this, but because it has no
mappings for the unknown packet and doesn't have any
mappings for that port, it will drop the packet and
won't deliver it.
With passive mode FTP (the default with FreeBSD ftp(1)
client), the client requests that the server picks up
a random port that it will listen on for the data
connection. The server informs the client of the port
it has chosen, and the client connects to this port to
transfer the data. Unfortunately, this is not always
possible or desirable. ftp(1) uses this mode by
default; to force active mode FTP, use the -A flag to
ftp, or set the passive mode to off by issuing the
command
passive off
at the ftp> prompt.
Packet Filter provides another solution for this
situation, redirecting FTP traffic through an FTP
proxy server, a process which acts to "guide" your FTP
traffic through the filters. The FTP proxy used by
FreeBSD and PF is ftp-proxy(8). To activate it, put
something like this in your /etc/nat.conf file:
rdr on tl0 from any to any port 21 -> 127.0.0.1 port
8081
Short explanation of this line is, "Traffic on the
internal interface is redirected to the proxy server
running on this machine which is listening at port
8081".
Hopefully, it is apparent the proxy server has to be
started and running on the FreeBSD box, this is done
by inserting the following line in /etc/inetd.conf:
127.0.0.1:8081 stream tcp nowait root
/usr/libexec/ftp-proxy ftp-proxy
and either rebooting the system or sending a 'HUP'
signal to inetd(8). One way to send the 'HUP' signal
is with the command:
kill -HUP `cat /var/run/inetd.pid`
You will note that ftp-proxy is listening on port
8081, the same port the above rdr statement was
sending FTP traffic to. The choice of port 8081 is
arbitrary, though 8081 is a good choice, as it is not
defined for any other application.
Redirecting Traffic
For some applications, you may need to redirect
incoming or outgoing traffic for a certain protocol
and/or port to a particular machine behind the
filtering system. An example of this would be a
computer residing inside the local network running a
web server which was to be accessed by the outside
world, (or of course, the already discussed
ftp-proxy(8)). Incoming connections to your valid
Internet IP will find that unless your NAT box is also
running a web server, no connection can be made. For
this purpose we use the NAT 'rdr' directive in the
rules file to instruct where to redirect a particular
connection to.
For our example, lets say a web server resides on the
LAN with IP address of 192.168.1.80. The NAT rules
file needs a new directive to handle this. Add a line
similar to the following one to your /etc/nat.conf:
rdr on fxp0 from any to any port 80 -> 192.168.1.80
port 80
The explanation for each part of this line:
"rdr"
This is the command you are giving NAT. It is telling
NAT that this entry is an entry to redirect a
connection.
"on fxp0"
This is the network interface that is connected to the
Internet.
"from any to any"
This indicates which IP addresses to redirect (from
any coming in on fxp0, as indicated above, to any
destination IP)
"port 80"
This is the incoming port (80) that should be
redirected. The number "80" didn't have to be used.
You can use "port www" also to specify a redirection
of port 80. If you would like to use a name instead of
a number, the service name and corresponding port,
must exist in the file /etc/services.
"192.168.1.80 port 80"
The IP address of the LAN machine which the packets
are redirected to. Note that the destination port does
NOT need to match the incoming port. For example, the
following is valid, and even potentially useful:
rdr on fxp0 from any to any port 8080 -> 192.168.1.35
port 80
This line would redirect incoming traffic on port 8080
to a webserver running on a machine in the internal
network, at the "standard" port 80.
When the addition is complete reload the NAT rules,
and the redirection will start immediately.
Negation
Sometimes, you need to make exceptions to a NAT or
redirection rule. Here's an example. AOL Instant
Messenger is noted for sneaking out firewalls through
any available port. You may find that the ftp-proxy is
interfering with AIM when it chooses to go out to
remote port 21. In the event you consider this bad
(many people spend considerable time trying to block
AIM!), you might wish to exclude the IP addresses used
by the AIM servers from the traffic redirected by our
above ftp-proxy line. You can do this with the
following line:
rdr on tl0 from any to ! 64.12.163.199 port 21 ->
127.0.0.1 port 8081
Interpretation: Redirect traffic coming in on tl0
going to port 21 but NOT to 64.12.163.199 (the AIM
server users were having trouble with) to localhost
port 8081 (where hopefully ftp-proxy is waiting). Now,
be advised that there are many AIM servers, if this
application interests you, you will probably have to
play with these IP addresses (64.12.0.0/16 might be
more productive, though probably also interferes with
some non-AOL sites)
NAT versus Proxy
The difference between NAT and an application-based
proxy is that the proxy software acts as a middle-man
between the Internet and the machines connected on the
LAN. This is fine, however each application you want
to run on your machine and connect to the Internet
through the proxy server MUST be proxy-aware (be able
to use a proxy server). Not all applications are able
to do this (especially games). Furthermore, there
simply are not proxy server applications for all of
the Internet services out there. NAT transparently
maps your internal network so that it may connect to
the Internet. The only security advantage to using a
proxy software over NAT is that the proxy software may
have been made security aware, and can filter based on
content, to keep your Windows machine from getting a
macro virus, it can protect against buffer overflows
to your client software, and more. To maintain these
filters is often a high-maintenance job.
6.3.4 Links and Cross-References
FreeBSD files:
/etc/nat.conf - NAT rules file
/etc/rc.conf - need to edit to start up NAT and PF at
boot time
/etc/sysctl.conf - need to edit to enable IP
forwarding
regards
Sonam Singh
--- "2005 - Chill, Samuel Thomas"
<stchill@mccallie.org> wrote:
> I have ipfirewall, ipdivert, and dummynet all
> compiled into my kernel. I am able to run run natd
> and to specify rules with ipfw, i can also ping my
> external interface. My internal network card (rl1)
> is 10.0.0.1 and my lan clients are running on
> 10.0.0.x. I can ping everything, the network is
> setup properly. Im using the default rules supplied
> in the man page and apperently natd is not passing
> them on. I cant ping or go to any website at all.
> The lan clients have 10.0.0.1 set as there default
> gateway. rl0 is connected to the cable modem and
> gets it ip via dhcp. The freebsd box can ping any
> thing but apparently nothing is forwarded to the
> external interface. I have double checked and
> reinstalled multiple times and it seems that it is
> bound to never work!
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of
> the message
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021009074352.13735.qmail>