netfilter Operation: Part Fourteen (Firewall Builder, conclusion)

Firewall Builder

Adding inbound and outbound NAT rules in Firewall Builder.

As you can probably see, once you have completed the up-front work of defining your objects, adding or modifying rules is simple. Additionally, unlike the other free GUI solutions, Firewall Builder allows you to centrally and securely administer all of your (supported) firewalls from one location.

Notice that the default chains have rules matching the rule you configured in Firewall Builder, with a target of RULE_<RULE_NUMBER>. These additional chains are used to configure the logging. there s also a rule at the beginning of all chains to ACCEPT traffic related to an established session. This is generally desirable but is still configurable. To remote this automatically generated rule, select the firewall in the object tree and click on Firewall Settings in the dialog area. There is a checkbox that is selected by default called “Accept ESTABLISHED and RELATED packets before the first rule.” Although the Firewall Builder policies you’ve configured can handle any basic rules you might need, there are still a few more issues to cover. If you need to NAT with your Linux firewall, configuring it with Firewall Builder is easy. Follow these steps so that your firewall with NAT all the traffic from the internal network to the DHCP address used on the outside interface. This configuration is also known as source.nat because it is the source address that is being changed.

  1. In the Object Tree, select NAT.
  2. Move your mouse to the pane to the right of the Object Tree, right-click and select Insert Rule.
  3. Drag your INTERNAL network object from the object tree to the Original Src column in the new NAT policy.
  4. Drag the external interface on the firewall from the object tree to the “Translated Source” column in the NAT policy.

Now, save, compile and install the new policy. Now traffic originating from the internal network will be NAT-ed to the IP on the external interface. Although this source NAT configuration will allow all your internal users to reach the internet, you will need to use destination NAT if Internet users need to reach an internal server. Because the internal server is using a private IP address (which is not routable on the Internet), you need to translate this destination to an IP address that the external users can reach. To configure packets destined for the firewall’s single public IP address to an inside resource using destination NAT, follow these steps:

  1. In the Object Tree, select NAT.
  2. Right-click on rule number zero of the existing NAT ule and select Add rule at Bottom.
  3. Drag the firewall OUTSIDE interface into the Original Destination column of the new rule.
  4. Drag the appropriate services (HTTP and HTTPS) into the Original Service column of the new rule.
  5. Drag the internal server into the translated destination column of the new rule.

Firewall Builder: Creating a Time Policy

Firewall Builder

Creating a time policy with Firewall Builder.

Another nice feature is being able to create a time policy. In this example, we’ll alter the rules so the internal systems can only surf the web from noon to 1:00 PM:

  1. In the Object Tree, right-click Time, and select New Time Interval.
  2. In the “Name” field, we’ll call this rule LUNCH.
  3. In the two time fields provided, enter a time for the rule to START and a time for the rule to STOP. In this case we will enter 12:00 and 13;00 and leave the date field as zeros. You can check off every day of the week at the below the time fields, so the time interval applies to all days. When done, click Apply.
  4. Drag the LUNCH time interval from the Object Tree to te Time column of rule #1.

Now, rule #1 (which permits outbound web surfing) will only be active from noon to 1:00 PM. The ability to configure the rules to be active based on the time of day is a very powerful feature. If the organization is a strictly 8 AM to 5 PM type of place, you could configure the firewall to disable all access during non-business hours. Alternatively, certain non-business-related protocols could be enabled after the normal business day ends.

External Links:

The official Firewall Builder site

netfilter Operation: Part Thirteen (Firewall Builder, continued)

Firewall Builder

Adding inbound and outbound rules for the web server in Firewall Builder.

In the last article, we discussed the process of setting up a firewall object in Firewall Builder and adding a network to it, as well as adding a web server to the network. This seems like a lot of additional effort; however, the real advantage of an object-oriented approach is seen when it comes time to configure the rules. With all of the appropriate objects in place, let’s define the rules to permit the inbound HTTP traffic.

  1. Create a new rule by either navigating to Rules -> Insert New Rule from the menu at the top of the window, or click on the large plus (+) beneath the top menu.
  2. Allow inbound HTTP to WEB1. Click on WEB1 in the object tree and drag it to the destination cell for rule 0.
  3. Now drag the HTTP and HTTPS service from the object pane to the Service cell in rule 0.
  4. Right-click the big red dot in the Action column and select Accept. This allows the inbound Web traffic to access WEB1.
  5. To allow outbound Internet access. create another rule by either navigating to Rules -> Insert New Rule or by clicking on the big plus (+) beneath the menu.
  6. Drag and drop HTTP and HTTPS from the object tree into the Service column of rule one.
  7. Drag the Network object INTERNAL from the object tree to the Source column of the new rule.
  8. Right-click on the Action column for rule 1 and change the action to ACCEPT.
  9. Although our rules seem simple at the moment, let’s apply them to see show things work. First, save your work by navigating to File -> Save or File -> Save As.
  10. Next, right-click the OFFICE01 Firewall and select Compile.
  11. When the “Select Firewalls for compilation” window comes up, OFFICE01 should be checked. When satisfied with your selection, click Next. When the compilation is complete you should see “Success” in the “Progress” column. After verifying that the compilation was successful, click Finish.

Compiling and Uploading the Firewall Rules

Firewall Builder

Compiling the firewall rules.

The next step is to tell Firewall Builder where to find the SSH executables, because this is how Firewall Builder uploads the configuration to the firewalls. You need to have SSH working on both the firewall and the Firewall Builder console, assuming they are on different systems.

  1. Select Edit -> Preferences from the menu.
  2. Select the Installer tab and click the Browse button.
  3. Navigate to the location of your desired SSH utility and click Open. Note that if you are using Windows for the Firewall Builder host, you cannot select PUTTY.EXE; you must use the command-line PuTTY program PLINK.EXE. In Linux, you can leave the default setting (ssh).
  4. After selecting the SSH executable, click OK.
  5. Right-click the OFFICE01 firewall in the object tree, and select Install.
  6. Select the firewalls you wish to install, and click Next.
  7. Enter the username and password for the SSH connection.
  8. All other fields are optional; however, it is recommended that you check “Store a copy of the fwb on the firewall.” When satisfied with your choices, click Ok.

After the upload completes, you will get a status of “Success”. Checking your firewall (iptables -L) shows you the new rules that are listed.

One point that should be made is that you have to be careful when configuring the rules. It is always a good idea to creat the rules to permit administrative access before any others. This is because as soon as you configure the default policies to DROP, your SSH connection will no longer be permitted unless you have it added to the access list. And if you forget to do this, you could find that you no longer have remote access to your firewall after applying the policy. If that happens, you won’t even be able to remotely connect to update the policy and change the ACLs.

External Links:

The official Firewall Builder site

netfilter Operation: Part Twelve (Firewall Builder continued)

Firewall Builder

Firewall Builder on startup.

NOTE: After I posted this article, I found out it’s possible to add objects/networks/hosts/etc. by right-clicking items on the object tree under the Linux version of Firewall Builder. This article has been amended accordingly.

In the previous article, I introduced Firewall Builder, including some notes on installation under Windows and Linux. In this article, I will step through the process of adding a firewall object and configuring it.

Firewall Builder: Creating a Firewall Object

In this example, I installed Firewall Builder under Linux Mint. Initially, there are three main options in the main dialog area: “Create New Firewall“, “Import Existing Configuration“, and “Watch ‘Getting Started’ Tutorial“. click on “Create New Firewall“, which will open the New Firewall dialog box.

Firewall Builder

The New Firewall dialog box.

In the New Firewall dialog box, enter the name for the new firewall (in this case OFFICE01). For the firewall software, select iptables from the dropdown box. For the OS, choose Linux 2.4/2.6 and click Next. The next window allows you to configure the interfaces on the firewall. You can do it manually, or if the firewall is running SNMP, you can discover them via SNMP. Here, we select Configure interfaces manually and click Next. This will bring up the manual configuration window. Enter the relevant information for each network interface. The name must correspond to the actual interface name (which is the same as if you had entered ifconfig on the Linux host), such as eth0. The Label is a human friendly name for easy reference such as OUTSIDE. When you are done entering the information for a given interface click Add. When you have entered the information for all interfaces (typically at least an INSIDE and OUTSIDE), click Finish. You must designate one of the interfaces on the firewall as the management interface, typically the INSIDE interface. Do this by navigating to the firewall in the object tree. As you select each interface in the object tree, there is a “Management interface” checkbox in the dialog area. Check this box for the interface you want to use. This will be the interface that Firewall Builder uses to connect and upload the firewall rules to.

Firewall Builder: Adding a Network

Firewall Builder

The button for adding new networks/hosts/services/etc is in the upper left, adjacent to the back arrow button.

Now that you have the basic firewall defined, you need to define something for it to talk to. In this case, we will assume that is you internal network, and you want to allow outbound Web browsing and access to an internal Web server (WEB1). For starters, you need to create an object to represent the internal network. Follow these steps to create the network object:

  1. Navigate to Objects -> Networks in the object tree ((in order to make the object tree visible, you may have to go to the View menu and unselect Editor Panel).
  2. Right-click Networks and select New Network.
  3. Enter INTERNAL for the name of the network, and use for the Address field. Enter for the Netmask.
  4. Next, we’ll create an internal Web server at  Right-click Objects -> Hosts in the object tree and select New Host.
  5. Enter WEB1 for the name of the object. Click the Use preconfigured template host objects check box and click Next.
  6. Select PC with one interface and click Finish.
  7. Expand the object tree to User -> Objects -> Hosts -> WEB1 -> eth0 -> WEB1. Edit the IP address to be and click Apply.
  8. Next, define the appropriate services to allow Web-browsing. Navigate in the object tree to Services -> TCP, right-click on it, and select New Service.
  9. Enter HTTP for the name. Leave the source port ranges at zero, but change the destination port range to start and end at 80.
  10. Repeat the previous two steps for HTTPS on port 443 for secure Web pages.

Now that we have created the network object, in the next article, we will cover defining the firewall rules to allow inbound web traffic and uploading the rules to the firewall.

External Links:

The official Firewall Builder web site

Using Firewall Builder on Linux to Create Firewalls from Scratch on

Firewall Builder Tutorial: The Basics on YouTube

netfilter Operation: Part Eleven (Easy Firewall Generator and Firewall Builder)

Easy Firewall Generator

Easy Firewall Generator in action.

Easy Firewall Generator

Easy Firewall Generator is not a GUI per se, but it does help simplify your netfilter configuration and avoid the need to be familiar with the iptables syntax. By using the Web page at, you can enter the relevant information and click the Generate Firewall button. As you select options, if additional information is needed click the Generate Firewall button and the page will refresh and provide the additional input fields. When all of the required information has been entered, the page will change to a text page that can be copied and pasted for iptables to read as a saved configuration. In Fedora, the iptables configuration is stored in /etc/sysconfig/iptables. Although this method requires you to replace the default iptables configuration file used by your distribution, it is fairly painless, and supportes all of the same basic functionality as Firestarter.

Firewall Builder

Firewall Builder is the most complete GUI offering for managing netfilter firewalls with features and capabilities comparable to some commercial firewall products. As is almost always the case, this functionality and capability come at a price: as far as netfilter GUIs are concerned, Firewall Builder is not the easiest to configure and use. If you want or need its superior management capabilities, however, the extra effort is well worth it. (Download firewall builder from Firewall Builder manages netfilter firewall as well as ipfilter, OpenBSD PF, and Cisco PIX firewalls. Firewall builder runs on many popular operating systems including Red Hat, Mandrake, Suse, FreeBSD, Mac OS X, and Windows XP/Vista/7/8.

Firewall Builder

Firewall Builder 5.1 on startup under Windows.

Firewall Builder operates differently than all of the GUIs covered so far. It uses an object-based approach. Essentially, you must define an object to represent any entity that you want to use in the firewall rules. In most cases this means a source, a destination, and a service port at a minimum. Both the configuration and the GUI bear a strong resemblance so that of the Checkpoint Firewall GUI. Once the objects are defined, you can drag or drop them into the rules in order to permit or deny communications between the two.

As of this writing, the current version of Firewall Builder is 5.1. Under Windows, navigating to Start -> Programs -> Firewall Builder 5.1 -> FWBuilder, which opens the main Firewall Builder window. Firewall Builder can also easily be installed under Linux. Under Linux Mint, I was able to install Firewall Builder using the apt-get command, like so:

sudo apt-get install fwbuilder

Once fwbuilder is installed, it can be accessed by clicking on the start menu, then navigating to Internet -> Firewall Builder, which will bring up the main Firewall Builder window.

In the next article, we will cover how to configure firewall rules in Firewall Builder.]

External Links:

The official Firewall Builder website

Getting Started With Firewall Builder at

netfilter Operation: Part Ten (Firestarter)


The Firestarter GUI in action.

Firestarter is a GUI front end for netfilter and iptables, and its goal is to make it simple for the average user to configure their firewall and protect themselves. Firestarter runs on many Linux distributions and the installation is supported by many automated package management systems (such as yum, apt-get and portage). Firestarter is an excellent choice if your needs are relatively simple for your firewall configuration. To install it manually, download it from Once it is installed, the first time you start the GUI interface you will need to perform some initial configuration. Follow these steps to configure Firestarter:

  1. Start the Firestarter GUI. In Fedora, this is done by navigating to Applications -> System Tools -> Firestarter. This will start the Firewall wizard. Click Forward on the Welcome to Firestarter screen.
  2. On the next screen, select your Internet-connected network device from the “Detected device(s):” dropdown box, and place a checkbox in the “IP address is assigned via DHCP” box. When you are done, click Forward.
  3. The next screen is the “Internet connection sharing setup” screen, which is basically where you enable NAT. If you want to NAT all of the outbound packets to the external IP address, place a check in the “enable internet connection sharing” checkbox. When this checkbox is enabled, you can select the local area network device. If you only have two interfaces, it should be selected by default. When finished, press Forward.
  4. On the final screen, leave the “Start firewall now” box checked and click Save. This will install a service to start Firestarter each time the system boots up. Firestarter will also change the default action for the chains to DENY; therefore, you must explicitly configure any ports you want to permit through the firewall.

The Firestarter GUI is fairly straightforward. The Status tab gives you high-level information such as sent and received data counters per interface and a list of active connections. By clicking the Stop Firewall button, all of the iptables chains are flushed and the default action is changed to ACCEPT. This can be useful for troubleshooting issues to see if they are related to your firewall configuration.

The “Events” tab lists recent blocked connection attempts. The “Policy” tab is where you configure certain rules to permit desired traffic.

For example, if there was a Web server running on the Linux host, you could use the “Policy” tab to permit inbound connection to TCP port 80. The “Editing” dropdown box allows you to choose between inbound and outbound rules to edit. For the Web server example, we selected “Inbound traffic policy“. The policy group you select when you click “Add Rule” determines where the policy is placed. Here are the functions of the various policy groups:

  1. Allow Connections From Host: This is used to configure a given IP address, hostname, or network. When you enter the IP information and create a rule in this policy group, all traffic from the configured source is permitted.
  2. Allow Service: The allow service policy group is used to permit individual services. You can configure the source to be anyone including a specific IP, or network, or all local area network (LAN) clients. The LAN clients option permits the service through the firewall with a source address that is on the same subnet as the inside network adapter.
  3. Forward Service: This option is used only when you are NATing. This allows the firewall to forward a specific port or range of ports, so that a service hosted on an internal NAT-ed device can receive inbound connections from the external network.

The “Outbound traffic policy” window shows a different set of policy groups. There are also the additional radio buttons to select “Permissive by default“, “blacklist traffic“, or “Restrictive by default“, “whitelist traffic“. If you select the restrictive configuration, the default target for the table is DENY, and any rules you create will be PERMIT rules.

The function of the different policy groups toggle between “allow” and “deny” based on whether you select restrictive or permissive mode. The policy groups are outlined here:

  1. Allow/Deny Connections to Host: This policy group is used to globally permit or deny outbound access to a given host, IP address, or network range. This policy uses the destination to match the rule. You can use this policy group in permissive mode to list certain Web sites you do not want anyone to have access to.
  2. Allow/Deny Connection from LAN Host: This policy group is used to permit or deny all access from a particular host, IP address or network range. This policy uses the source to match the rule.
  3. Allow/Deny Service: This policy group permits or denies traffic based on its destination port and source. When you are using permissive mode, this policy group can be used to block all access to the bittorrent ports. The traffic source can be anyone: the firewall itself, LAN clients, or an arbitrary IP, hostname or network range.

Configuring the policies will satisfy the bulk of what you need to accomplish, but there are some additional configuration options available by navigating to Edit -> Preferences. Selecting Interface -> Events allows you to configure some useful options. The “Skip redundant entries’ checkbox only makes one event entry for sequential event entries. This helps prevent the event windows from being flooded by repetitive alerts. You also have the option of entering certain hosts or ports as being exempt from triggering the vent log. After making your selections, click Accept.

Another preferences setting of note is under Firewall -> Network Settings. This allows you to enable Internet connection sharing (the same as during the initial wizard), and enable the firewall host as a Dynamic Host Configuration Protocol (DHCP) server. This allows you to configure the Linux host similarly to a home firewall, which generally acts as a DHCP server in addition to performing NAT and acting as a firewall. The ICMP filtering window also allows you to filter ICMP packets. By default, the permit and deny rules configured by Firestarter apply to TCP and UDP, but not ICMP. This screen allows you to permit the desired types of ICMP traffic. Generally speaking, it is better not to allow any ICMP from the Internet to your firewall or internal network unless absolutely necessary.

One final setting you want to configure is under Firewall -> Advanced Options. In the broadcast traffic section, check both options under Broadcast traffic. In general, you should not permit broadcast traffic to go through your firewall, as doing so poses a security risk. You also want to check the option to “Block traffic from reserved addresses on public interfaces,” which is a common filtering tactic. Because the “private” addresses outlined in RFC 1918 should not be routed through the Internet, there is never a reason to receive traffic sourced from any of those addresses on your outside interface. If you do, it is almost always a hacker attempting to bypass a poorly configured firewall.

Short of any advanced packet mangling, there isn’t much you cannot accomplish using Firestarter as your configuration tool. If you need to implement a more advanced configuration, you could use an alternate tool, or generate the configuration using Firestarter and use those chains as a starting point to add your own more advanced options.

External Links:

The official Firestarter web site

Configuring firewalls with Firestarter at Tech Republic

Firestarter – A High-Level Graphical Interface Iptables Firewall for Linux Systems at

Install the Firestarter Firewall on Ubuntu Linux at

netfilter Operation: Part Nine (Lokkit)


Lokkit in action under Ubuntu.

Using Lokkit

Lokkit is an ncurses-based menu for configuring your netfilter firewall that is part of the GNOME desktop. Lokkit is available for most major distributions and can be installed by default on some (such as Fedora). It asks a small number of simple questions and writes a firewall rule set for you. To start Lokkit, type lokkit in a terminal window. [If you don’t have lokkit, you can install it from the repos using the apt-get command: sudo apt-get install lokkit]. If you want to review the firewall settings without running the firewall, type:

sudo lokkit -n

To see what services/ports can be managed/opened using lokkit, type:

sudo lokkit –list-services

You can navigate the menus using the Tab key and the space bar to toggle the equivalent of radio buttons, such as the Enable and Disabled options shown here. If you select Enabled on this screen, the default ruleset is applied. To edit any custom settings, press Tab until the Customize button is highlighted and then press Enter.

Lokkit does provide a little more flexibility than the Security Level configuration GUI discussed previously; however, it is still limited. By selecting an interface in Trusted Devices, all traffic from that interface will be permitted. This would typically be used to select the inside interface and designate it as trusted. You do have the option of enabling MASQUERADE. The interface you select is the one that will NAT outbound traffic; therefore, you would generally select your external interface. Some pre-defined services are available, and you can enter your own service information in the “Other ports” section. Once you are satisfied with your choices, press OK and then Enter. This will take you back to the main screen, where you press OK and then Enter to apply the changes.

If you attempt to configure an interface for MASQUERADE, it must also be marked as trusted or Lokkit will generate an error, Bear in mind that although MASQUERADE is limited, it has enough flexibility to configure a firewall similar to a typical home firewall/router device. This makes Lokkit a handy little utility to have in your repertoire should you need to configure a simple firewall quickly. The value of this utility is also increased, because it is available for a wide number of Linux distributions.

External Links:

Lock it down quickly with Lokkit at

Linux Firewall – The Second Line of Defense at Linuxtopia

netfilter Operation: Part Eight

Firewall Options tab in the Red Hat firewall configuration GUI.

Firewall Options tab in the Red Hat firewall configuration GUI.

While the console commands that are used to manipulate and configure netfilter are not very complicated, the can sometimes get rather lengthy. As the length of the command line grows, the chances of an accidental error increase. Alternatively, you may not like working on the command line, in which case there are a wide variety of GUI and menu-driven interfaces available for netfilter. In most cases, these menu-driven interfaces use your input to create the appropriate iptables commands, and alleviate you having to know the various switches and options to use. There are a large number of GUI interfaces available to configure your netfilter firewall. In general simpler also means less full featured, so be aware that if you are trying to create a complex ruleset, some GUIs may not have the needed functionality.

You can start the iptables GUI provided with Red Hat-based Linux distributions by navigating to System -> Administration -> Security Level and Firewall. You can also call the program directly by running system-config-securitylevel from a terminal window. While the interface looks nice, it is limited in what it can configure. Basically, all you can do with this GUI is permit or deny certain ports. Fedora Core 5 and subsequent versions of Fedora configures the INPUT and FORWARD chains to jump a custom chain named RH-Firewall-1-INPUT. There is no ability to differentiate between ports permitted in the INPUT chain or the FORWARD chain, because all rules configured through the GUI are applied to this custom chain.

Some services are pre-defined for you. Placing a check next to SSH and clicking OK and then Yes to commit the changes would create the following rule in the RH-Firewall-1-INPUT chain:

iptables -A RH-Firewall-1 INPUT -p tcp -m state –sate NEW -m tcp –dport 22 -j ACCEPT

By expanding Other ports on the Firewall Options tab, you can enter a custom port number.

Click Add, and enter the desired port number in the dialog box. Use the drop-down menu to select TCP or UDP for the protocol and click OK.

This creates a rule identical to the SSH rule. There are no other configuration options. While this interface is adequate for a home PC that isn’t running any services, it probably will not be adequate for a corporate firewall. If you need to configure access based on the interface in use or need to configure any NAT rules, you will need to use a different GUI. While you probably won’t be needing this particular GUI as a corporate firewall, it is still useful to be familiar with it if you are running any Linux systems as workstations.

External Links:

How to edit iptables rules at – includes a section on using the Red Hat GUI configuration tool

netfilter Operation: Part Seven

netfilter operationBy this point, you should have a relatively solid grasp of how to configure a Linux firewall. So far we have covered all of the core commands to permit and deny the traffic. Another useful command for your Linux firewall deals with logging packets. If you want to log everything passing through the firewall, use the iptables -A FORWARD -j LOG command. While simple, this would likely generate an excessive amount of logging traffic. You also might want some additional control of how the logging occurs. There are some additional options to provide this functionality. Of particular note are the –log-level and –log-prefix options.

The –log-level option allows you to specify what logging level is used for the LOG rule, The effect this log level has depends on how you have your kernel logging configured (via syslog or syslog-ng). When you combine the custom logging level of iptables with the syslog configuration, you can have syslog act in any manner of ways based on the firewall logs, including sending e-mails for certain events. The –log-prefix option allows you to insert up to a 29-letter string in front of the log entry. This can be useful for troubleshooting purposes. Some examples of information you could place in log prefix would be the name of the chain that generated the log entry such as iptables -A FORWARD -j LOG –log “from FORWARD chain.”

Saving and Restoring a Ruleset

Now that you can create a working ruleset for netfilter, you will want to save it. There are two commands of note: one for saving the configurations and one for loading a save configuration. You can use the iptables-save command to generate output that is the current active ruleset. By default, it will only generate the output to the stdout, meaning it will display in the console. To save this output, redirect it to a file. To redirect the current ruleset to a file called /etc/ruleset, you would type iptables-save > /etc/ruleset. If you want to save the current packet counts and rule counts, use the iptables-save -c > /etc/ruleset command. Individual tables can be saved separately by specifying the -t option using the iptables-save -t mangle > /etc/ruleset command.

Restoring a ruleset is accomplished using the iptables-restore command. Like iptables-save, the restore function takes only two optional arguments. The -c option will cause iptables to load the saved packet and byte counts, overwriting the current count values. The default behavior when using iptables-restore is to flush the ruleset before loading the saved ruleset, thus all previous rules are lost. If you wish to override this behavior, you can use the -n option, in which case the fules will be added to the existing ruleset, and will only overwrite if there is a duplicate rule. You can use the iptables-restore < /etc/ruleset command to pipe the saved configuration to iptables-restore.

External Links:

How to Log Linux iptables Firewall Dropped Packets to a Log File at The Geek Stuff

netfilter Operation: Part Six

netfilter operationIn the previous article, we began the process of simulating a home router with netfilter. We will continue that process in this article.

We began with the these iptables commands:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s -i eth0 –dport 80 -j ACCEPT
iptables -A FORWARD -s -i eth0 -o eth1 -j ACCEPT
 iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

The INPUT chain allows port 80 to go to the firewall itself from the internal network. Many of the home routers have a Web interface for configuring them, and while your configuration may not need this port open to the firewall, it is included here to help emphasize how the different chains are used. It is important to specify the input interface (using -i) so that the source IP cannot be spoofed by an external attacker. In this way, you ensure that even if a packet was generated with the proper source IP, if it came in on the outside interface (eth1) it would not match the rule and would thus not be permitted. The FORWARD rule allows any outbound traffic from the internal network to the external network. This configuration is simple to implement; however, the IP range is a private IP range and is not routable on the Internet. Thus, this range would not allow traffic from the internal network to the Internet quite yet. To make this Linux firewall a useful replacement for a home network router, you need to enable NAT, which allows all of the systems on your internal network to appear as a single IP address when communicating on the Internet.

Enabling NAT

In principle NAT is simple, but in a complex environment it can get confusing. Basically, NAT means that the NAT device (in this case the Linux netfilter firewall) will change the IP address in apacket and retransmit that packet. Depending on your needs, you can alter the source IP address (source NAT, or SNAT), the destination IP address (destination NAT, DNAT), or both (double NAT). With a home router, the objective behind the NAT capability is to allow all of the internal hosts to communicate on the Internet using the single public IP provided by your Internet Service Provider (ISP). (In this case, SNAT is being used). As each of the hosts on your private network make a connection to an Internet server, the firewall is altering the source address to look like the public IP from your ISP. By doing this, the return traffic can find its way back to the firewall and be retranslated and sent to the originating host.

In this example, assume that the internal host has a private IP address of The public address of the firewall is, which is provided by the ISP. If a host on the private network wants to make a connection to The firewall alters the source address to its own public IP address of and sends the packet on its way. When the server replies to destination, the firewall again edits the packet, this time inserting a new destination of All of this takes place and is transparent to the host and the server. When multiple hosts are using SNAT, the firewall tracks which connections belong to which private hosts using the port numbers. While the destination port of the Web server remains static (typically port 80 for the Web), the source port is usually a random port above 1024. By tracking the source port, the firewall knows which address belongs to which session. In the event that two hosts attempt to use the same source port, the NAT device edits the source port of one of the connections and replaces it with another random source port. When the return traffic is received, it translates the source port back, just like it did for the IP address. because this method of NAT relies heavily on using the source port number, it is sometimes referred to as port NAT (PNAT).

To add the SNAT functionality to the example firewall, use the following command:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source

The -r option is used to specify the table we want to modify, and -A option specifies that we are going to append this rule to the POSTROUTING chain. By specifying the outbound interface, we are ensuring that the SNAT only occurs as traffic leaves the private network, meaning only in the proper direction.

The jump target SNAT is self explanatory. The –to-source option specifies what IP address we want to use as the new source address. SNAT assumes we have a static IP address to SNAT the outgoing packets to. While this is likely the case in a corporate environment, a more appropriate solution to more closely mimic the configuration of a home router would be to use the MASQUERADE command:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

The masquerade command does not require an IP specification, and will use the IP address of the firewall interface. You might be wondering why you would not use the masquerade target all of the time instead of the SNAT target. Because the source IP is static, the SNAT target will cause the NAT calculations to be performed once for a given session. Subsequent packets belonging to that session are handled the same way as the first. With the masquerade target, each packet is checked for the source IP to use, which requires more overhead than with SNAT. This is why SNAT is preferable if you have a static source IP address, and masquerade is your only option if you do not have a static source IP address to use.

External Links:

Linux 2.4 NAT HOWTO at

© 2013 David Zientara. All rights reserved. Privacy Policy