Home______________________________________________________________________
NAT stands for Network Address Translation. To those familiar with Linux, this concept is called IP Masquerading; NAT and IP Masquerading are the same thing. One of the many things the IPF NAT function enables is the ability to have a private local area network (LAN) behind the firewall sharing a single ISP assigned IP address to the public Internet.
You ask why would someone want to do this. ISP’s normally assign a dynamic IP address to their non-commercial users. Dynamic means the IP address can be different each time you dial in and logon to your ISP, or for cable and DSL modem users when you power off and then power on your modems you can get assigned a different IP address. This IP address is how you are known to the public Internet.
Now lets say you have 5 PC’s at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have 5 phone lines.
With NAT you only need a single account with your ISP, then cable your other 4 PC’s to a switch and the switch to the NIC in your FBSD system which is going to service your LAN as a gateway. NAT will automatically translate the private LAN IP address for each separate PC on the LAN to the single public IP address as it exits the firewall bound for the public Internet. It also does the reverse translation for returning packets.
NAT is most often accomplished without the approval, or knowledge, of your ISP, and in most cases is grounds for your ISP terminating your account if found out. Commercial users pay a lot more for their Internet connection and usually get assigned a block of static IP addresses which never change. The ISP also expects and consents to their commercial customers using NAT for their internal private LANs.
There is a special range of IP addresses reserved for NATed private LAN IP addresses.
According to RFC 1918, you can use the following IP ranges for private nets which will never be routed directly to the public Internet.
Start IP 10.0.0.0 - Ending IP 10.255.255.255
Start IP 172.16.0.0 - Ending IP 172.31.255.255
Start IP 192.168.0.0 - Ending IP 192.168.255.255
NAT rules are loaded by using the ipnat command. Typically the NAT rules are stored in /etc/ipnat.rules. See man ipnat(1) for details.
When changing the NAT rules after NAT has been started, make your changes to the file containing the NAT rules, then run the ipnat command with the –CF flags to delete the internal in use NAT rules and flush the contents of the translation table of all active entries.
ipnat –CF –f /etc/ipnat.rules # reload the NAT rules
ipnat -s # Retrieve and display NAT statistics
ipnat -l # List the internal NAT table entry mappings.
ipnat -v # Turn verbose mode on to display information relating to rule processing and active rules/table entries.
NAT rules are very flexible and can accomplish many different things to fit the needs of non-commercial users with a single dynamic IP address or commercial users who have blocks of static IP address ranges assigned to them.
The rule syntax presented here has been simplified to what is most commonly used in a non-commercial environment. For a complete rule syntax description see the man ipnat page at ipnat(5) or ipnat(8).
# is used to mark the start of a comment and may appear at the end of a rule line or on its own line. Blank lines are ignored.
Rules contain keywords. These keywords have to be coded in a specific order from left to right on the line.
These special aliases |0.32|, |0/0| and |0/32|, only work in IPNAT's
map and bimap rules. They do NOT work in IPF rules, or in IPNAT rdr
rules. Beware how and where you use these special aliases as incorrect usage
generates no errors.
For standard NAT functionality, you only need a single NAT rule.
Create a file called /etc/ipnat.rules with the following line:
A packet leaves a LAN PC for the public internet carring it's private LAN source IP address and public destination IP address. It passes through the outbound firewall rules and NAT gets it's turn at the packet and applies its rules top down; the first matching rule wins. NAT tests each of its rules against the packet's interface name and source IP address. When a packet's interface name matches a NAT rule then the source IP address (IE: private LAN IP address) of the packet is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the NAT rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the 0.32 keyword. NAT posts an entry in its internal NAT table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for processing.
The main thing to remember is the firewall rules only sees the non-public routable private LAN IP address. The NAT function happens after the outbound packet has been processed by the firewall and before the inbound packet gets to the firewall.
To enable the IPNAT function add these statements to /etc/rc.conf
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # ipnat rules definition file
For networks that have large numbers of PC's on the LAN or networks with more that a single LAN, the process of funneling all those private IP addresses into a single public IP address becomes a resource problem that may cause problems with same port numbers being used many times across many NATd LAN PC's causing collisions. There are 2 ways to relieve this resource problem.
1. Mapping many LAN addresses into a single public address.
map dc0 10.0.10.1/29 -> 0.32
In the above rule the packet's source port is unchanged from the original source port. IPNAT has the special keyword "portmap" that changes the above rule into
map dc0 10.0.10.1/29 -> 0.32 portmap tcp/udp 20000:6000
This rule now shoehorns all the translated connections (which can be
tcp, udp, or tcp/udp) into the port range of 20000 to 60000.
Additionally, we can make things even easier by using the "auto"
keyword to tell ipnat to determine for itself which ports are available for use
and allocate a proportional amount of them per address in your pool versus
addresses being NATed:
map dc0 10.0.10.1/29 -> 0.32 portmap tcp/udp auto
2. Mapping many LAN addresses into a pool of static public addresses.
In large LANs there comes a point where there are just too many LAN addresses to fit into a single public IP address. Change the map rule to specify a range of public IP addresses as follows:
map dc0 10.0.10.1/29 -> 20.20.20.0/24 portmap tcp/udp 20000:60000
map dc0 10.0.10.1/29 -> 20.20.20.0/24 portmap tcp/udp auto
Here 20.20.20.0/24 is the pool of static public IP addresses assigned to you by your ISP.
An very common practice is to have a web server, email server, database server or domain name server each segregated to a different PC on the LAN. Any traffic originating from those servers destine for the public internet would pass out the firewall on keep state rules automatically controlling the bidirectional exchange of packets for the duration of the session conversation. Due to the nature of these servers they also need to receive unsolicited inbound traffic from the public internet. The problem is how to direct this unsolicited inbound traffic to the correct target PC on the LAN?
For this purpose we use the NAT 'rdr' directive in the /etc/ipnat.rules file to instruct where to redirect (or route) a particular packet to on the NAT'ed LAN.
For example, lets say your web server resides on the LAN and you want it to
be accessible from the public internet. The NAT rules file would need a
additional rule added after the MAP rules to handle this. You would code the rule like this:
rdr xl0 0.0.0.0/0 port 80 -> 10.0.10.5
port 80
"rdr" = the command which
provides the selection information and target redirect information.
"xl0" = is the network interface
that is connected to the public internet.
"0.0.0.0/0" = is a special
aliases which means any source IP address contained in the inbound packet
traveling the interface is to be selected for testing. The other special aliases |0.32|, |0/0|
and |0/32|, only work in IPNAT's map and bimap rules. They do NOT work in
IPF rules, or in IPNAT rdr rules and 0.0.0.0/0 only works in rdr rules. Beware
how and where you use these special aliases as incorrect usage generates no
errors.
"port 80" = is the destination
port number that has to be matched in the inbound packet to select the candidate
packet to be redirected. The number
"80" don't have to be used. You can use "port www" 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.
"->" = Mandatory arrow symbol used to distinguish between the rule selection information side and the redirect information side of the rule.
"10.0.10.5" = the IP address of
the LAN PC which the matched packets are to be targeted to. The netmask defaults
to "/32" and therefore should not be coded.
"port 80" - this is the port number value to substitute in the destination port number of the redirected packet. You could make it 8088 and tell the web server on 10.0.10.5 to listen on that port number. If omitted the destination port number goes unchanged.
The above IPNAT redirect rule says that any inbound packet that has not already had it's destination IP address translated by earlier MAP rules will then have it's destination port tested for match to the port number on the left of the mandatory arrow symbol, if matched, the packet's destination IP address and port number are over written with the values on the right of the mandatory arrow symbol and then released for processing against the firewall rules. NAT then posts an entry in its internal NAT table so when the packet returns after first being processed by the firewall rules on it's outbound journey it can have it's private LAN IP address mapped back to your gateway's public routable IP address. After reloading the NAT rules, the redirection will start immediately.
Depending on how tightly or loosely you control the services by firewall rules the redirected packet may require a firewall rule to let it pass.The main thing to remember is the firewall rules only sees the non-public
routable private LAN IP address. The NAT function happens after the outbound
packet has been processed by the firewall and before the inbound packet gets to
the firewall.
FTP is a dinosaur left over from the time before the Internet, when research universities were connected with leased lines and FTP was used to share files among research scientists. This was a time when data security was not even an idea yet. Over the years the FTP protocol became buried into the backbone of the emerging Internet and its login ID & PW being sent in clear text was never changed to address new security concerns. FTP has two flavors: it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired be the ordinal FTP session requester. For a real good explanation of FTP and its different modes read http://www.slacksite.com/other/ftp.html
NAT has a special built in FTP proxy option which can be specified on the NAT map rule. It can monitor all outbound packet traffic for active or passive FTP start session requests and dynamically create temporary filter rules containing only the port number really in use for the data channel. This eliminates the security risk FTP normally exposes the firewall to from having large ranges of high order port numbers open. You specify the map rule like this:
map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp
map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp
map dc0 10.0.10.0/29 -> 0/32
The first rule handles all FTP traffic for the private LAN.
The second rule handles all FTP traffic from the gateway.
The third rule handles all non-FTP traffic for the private LAN.
All the non-FTP gateway traffic is using the public IP address by default so
there is no ipnat rule needed.
The FTP map rule goes before our regular map rule. All packets are tested against the first rule from the top. First, it matches on interface name, then private LAN source IP address, and then if it's an FTP packet. If all that matches then the special FTP proxy creates temporary filter rules to let the FTP session packets pass in and out in addition to also NATing the FTP packets. ALL LAN packets that are not FTP do not match the first rule and fall through to the third rule and are tested, matching on interface and source IP, then get NATed.
Only one filter rule is needed for FTP if NAT FTP proxy is used
# Allow out LAN PC client FTP to public Internet
# Active and passive modes.
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
Three Filter rules are needed for FTP if no NAT FTP proxy is used
# Allow out LAN PC client FTP to public Internet
# Active and passive modes.
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
# Allow out passive mode data channel high order port numbers
pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state
# Active mode let data channel in from FTP server
pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state
This FreeBSD Install Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.