Video: Configuring Dynamic DNS with pfSense

You may want to set up a domain name for your home or SOHO WAN IP. This video demonstrates how to do this. In this video I cover:

  • What DDNS is, why you might want to use it, and different methods of implementing DDNS
  • Configuring Duck DNS on the Duck DNS web site; downloading and installing the Duck DNS client
  • Configuring DDNS in pfSense and setting up NAT so we can access an Apache web server behind the firewall
  • Accessing a web site using the domain name I set up in the previous steps

pfSense Hardware: A Scrounger’s Guide (Part One)

pfSense hardware

The Pentium P-233 that served as my m0n0wall firewall/router

When I started using pfSense as my primary firewall, it replaced my previous firewall solution: a Pentium P-233 running m0n0-wall. I eventually switched to a Neoware thin client running pfSense, which I ultimately upgraded to version 2.1.3. The Neoware thin client meets the pfSense hardware requirements for running pfSense on an embedded system, and offered pretty good value for the money – one would be hard-pressed to put together a system more cheaply than these pfSense appliances which has the same features and functionality. Yet while running pfSense from a thin client may be the best option for some users, if you have an old computer that meets the pfSense hardware requirements, this may be the better option. For that reason, I thought it would be an interesting exercise to see how easy (or how hard) it is to turn an old PC into a pfSense firewall.

Indeed, the system I used to run m0n0wall had been scrounged from spare parts. The case and power supply had come from an old barebones system I had bought in the late 1990s. The motherboard/CPU was one of a lot of three I had bought on eBay a few years later, and the CD-ROM was from a group of spare CD-ROM drives I had, as was the floppy drive. I only had 32 MB of RAM initially. I found that with only 32 MB of RAM installed, m0n0wall’s web-based configurator would eventually crash (although the firewall itself would continue to function). I found another 32 MB of RAM on eBay for a few dollars, and my system was complete. The NICs had also been taken from old computers, although I eventually bought a lot of 10 Intel Pro 100 cards for $35. As underpowered as this system might seem, it served ably as my firewall for several years. Thus, I began to wonder if I had any old hardware that could run pfSense, and decided that for my next mini-project, I would take an old computer and turn it into a serviceable pfSense router.

pfSense Hardware: The Guidelines

For this project, I set out some basic guidelines:

  1. The hardware had to meet the general requirements for pfSense hardware. These requirements are listed on the official pfSense web site. For any installation, a Pentium II or better with at least 256 MB of RAM is recommended. For hard drive installations, a 1 GB hard drive is required (and a CD-ROM drive for installation).
  2. When possible, I would scrounge from existing resources to put together a system that would serve as my new pfSense box. If necessary, I would buy new hardware, but only as a last resort.
  3. I was not completely sure what the final system would have installed on it, but I knew at a minimum I wanted to have the most recent pfSense version (2.1.3 at this writing), and probably Squid, SquidGuard, and probably some other packages.
  4. To the fullest extent possible, I would document the process, so I would have a record of what worked (and what didn’t work).

These guidelines should provide a rough road map for this project. In the next article, I will cover the selection of hardware, putting together my pfSense box, and installing pfSense onto it.

External Links:

Hardware for pfSense at – pfSense hardware requirements guide

VPN Access Strategies

VPN accessA virtual private network (VPN) is exactly what it sounds like: the network connection you create is virtual, because you can use it over an otherwise public network. Basically, you take two endpoints for the VPN tunnel, and all traffic between these two endpoints will be encrypted so that the data being transmitted is private and unreadable to the system in between. Different VPN solutions use different protocols and encryption algorithms to accomplish this level of privacy. VPNs tend to be protocol independent, at least to some degree, in that the VPN configuration is not on a per-port basis. Rather, once you have established the VPN tunnel, all applicable traffic will be routed across the tunnel, effectively extending the boundaries of your internal network to include the remote host. In this article, we will examine some of the issues involved in implementing VPN access.

VPN Access: Network Design

One of your first considerations when planning to provide for VPN access is the network design. Because the VPN tunnel needs two endpoints, one will be the remote workstation. The other will be a specially configured device for that purpose. This is generally called a VPN concentrator, because it acts as a common endpoint for multiple VPN tunnels. [As noted previously in this blog, Soekris makes affordable VPN cards that offload the CPU of the the computing intensive tasks of encryption and compression.] The remote system will effectively be using the concentrator as a gateway into the internal network; as such the placement of the concentrator is important: in a highly secured environment, the concentrator is placed in a DMZ sandwiched between two firewalls, one firewall facing the Internet, and the other facing internally. While this type of arrangement is the most secure, it takes more hardware to implement.

Another way to place the VPN concentrator inside a DMZ is to use an additional interface on the firewall as the DMZ in a “one-legged” configuration. This saves you having to implement an additional firewall, but still provides some isolation between the concentrator and the rest of the internal network. If an attacker compromised a remote host who was VPNed into the concentrator or compromised the concentrator itself, they would still have a firewall between them and the internal network. The least preferable option is to place the concentrator inside the internal network. With this type of design, if the concentrator is compromised, the attacker would have full access to the internal network, with no firewalls to inhibit their activities. With any of these designs, you will have to permit the required ports through the firewall and forward them to your VPN concentrator in order to ensure VPN access.

VPN Access: Protocols

Another consideration in providing VPN access is the type of VPN protocol you want to use. IPsec is still the most widely deployed VPN technology for good reason. One is interoperability. As a widely used and tested standard, IPsec will work with virtually any modern firewall and operating system. The disadvantage of IPsec is that it can sometimes be difficult to configure properly, and there is zero margin for error on the configuration. Both ends have to se the same parameters for encryptions, hashing, and so forth, or the tunnel cannot be established. SSL is an increasingly popular choice for VPNs, largely because of its simplicity to implement.

Once you have chosen a design and VPN technology, you need to consider the administrative ramifications of offering remote access. Some level of training will be required. At the very least, they may require training to use the VPN software. It is a good idea to educate your users on good security habits as well. A determination will also need to be made as to whether remote users are allowed to use their own personal computers and/or laptops, or if they must use a company-provided computer for remote access. The former option carries with it many risks. When a remote user connects their personal computer to the corporate network, they may have spyware, a virus, or any number or potentially damaging conditions present on their system. Due to the fact that you probably do not have any administrative access to their systems, you may have no way to secure the personal systems even if you wanted. This is why most companies require that only corporate resources be allowed to connect to the company network.

VPN Access: Hardware

One last consideration for VPN access is hardware selection. Normal workplace desktop applications place very little strain on even a remotely modern processor. The same is not true when it comes to VPN connections. A single VPN connection requires little overhead and rarely impacts the remote user’s system unless it is especially underpowered. For the VPN concentrator, however, it will handle the encryption and decryption of multiple connections, in addition to managing the volume of network data that will be accessed through it. For this reason, if you anticipate more than just a couple of VPN connections to be used simultaneously, you will want to test and evaluate your hardware needs.

Internal Links:

pfSense VPN: Part One

pfSense VPN: Part Two

pfSense VPN: Part Three (PPTP)

External Links:

An Overview of VPN Concentrators at YouTube (from CompTIA’s Network+ certification training)

How the VPN Concentrator Works at

Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.

Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

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

© 2013 David Zientara. All rights reserved. Privacy Policy