From owner-freebsd-questions Wed Oct 9 0:44: 8 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F6FD37B401 for ; Wed, 9 Oct 2002 00:43:56 -0700 (PDT) Received: from web40512.mail.yahoo.com (web40512.mail.yahoo.com [66.218.78.129]) by mx1.FreeBSD.org (Postfix) with SMTP id 89C3C43E42 for ; Wed, 9 Oct 2002 00:43:55 -0700 (PDT) (envelope-from sonam_singh_s@yahoo.com) Message-ID: <20021009074352.13735.qmail@web40512.mail.yahoo.com> Received: from [202.88.149.172] by web40512.mail.yahoo.com via HTTP; Wed, 09 Oct 2002 00:43:52 PDT Date: Wed, 9 Oct 2002 00:43:52 -0700 (PDT) From: sonam singh Subject: Re: Puzzling Simple NATD and IPFW Problem To: freebsd-questions@freebsd.org In-Reply-To: <200210081603.AA143786622@mail.mccallie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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" 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