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

Wireless Access with an Existing Router in pfSense

wireless accessIf you have an existing wireless access point or a wireless router that you only want to use as an access point now that you have a pfSense router, there are several ways to incorporate wireless access into your network. We will discuss some of them in this article.

Wireless Access: Turning the Old Router into a WAP

When you replace a simple consumer-grade wireless router, the wireless functionality can be retained by turning the wireless router into a wireless access point (WAP) by following the steps described here. First, you will want to disable the DHCP server if it was previously in use. You will want pfSense to act as the DHCP server, and having two DHCP serviers on your network will cause problems.

Next, you will need to change the LAN IP to an unused IP on the subnet where your access point will reside (commonly the LAN interface). It is probably using the same IP address you will assign to the pfSense LAN interface, so it will require a different address. You will want to retain a functional IP address on the access point for management purposes.

Most wireless routers bridge the wireless onto the internal LAN port(s), which means the wireless will be on the same broadcast domain and IP subnet as the wired ports. For routers with an integrated switch, any of the switch ports will do. You do not, however, want to plug in the WAN or Internet port on your router. This will put your wireless network on a different broadcast domain from the rest of your network, and will result in NATing traffic between your wireless and LAN and double NATing traffic between your wireless and the Internet. This will lead to problems in some circumstances, especially if you need to communicate between your wireless clients and your wired LAN. Where you chose to plug in the LAN interface will depend on your chosen network design.

One means of deploying wireless is to plug the access point directly into the same switch as your LAN hosts, where the AP bridges the wireless clients onto the wired netwrk. This will work, but it offers limited control over the ability of your wireless clients to communicate with your internal systems. But if you want more control over your wireless clients, then adding an OPT interface to pfSense for your access point is the preferred solution. If you want to keep your wireless and wired networks on the same IP subnet and broadcast domain, you can bridge the OPT interface to your LAN interface. This scenario is essentially the same as plugging your access point directly into you LAN switch, except that since pfSense is in the middle, it can filter traffic from your wireless network to provide protection to systems connected to your LAN.

You can also put your wireless network on a dedicated IP subnet if you want, by not bridging the OPT interface on pfSense and assigning it with an IP subnet outside of your LAN subnet; this will enable routing between your internal and wireless networks, as permitted by your firewall rule set. This is done often on larger networks where multiple access points are plugged into a switch than in turn are plugged into the OPT interface on pfSense. It is also preferable when wireless clients must connect to a VPN first.

External Links:

pfSense: Associate with a Wireless Access Point at Addicted to IT

Ad Links:

DNS Tools: Configuring DNS Forwarding in pfSense

DNS Forwarding: A Useful DNS Tool

A DNS forwarder is a DNS tool which enables a network to skip the normal DNS resolution process and instead forward certain DNS requests to specified DNS servers, asking them to do the resolution work for it. Under pfSense, the DNS forwarder allows pfSense to act as a DNS server with a number of different features. It is a useful DNS tool in that it allows pfSense to resolve DNS requests using hostnames obtained by DHCP service, static DHCP mappings, or manually entered information. The DNS forwarder can also forward all DNS requests for a particular domain to a server specified manually.

DNS Tools: Configuring Common DNS Forwarding Options

DNS tools

Configuring DNS forwarding in pfSense 2.1

Like most DNS tools, some configuration is required. To configure the DNS forwarder, first navigate to Services -> DNS Forwarder. Check the “Enable DNS forwarder” check box. If you check “Register DHCP leases in DNS forwarder“, then matches that specify their hostname when requesting a DHCP lease will be registered in the DNS forwarder, so that their name can be resolved (these are the hosts that appear in the list at Status -> DHCP Leases or, if it is an IPv6 address, DHCPv6 Leases). If “Register DHCP static mappings in DNS Forwarder” is checked, then DHCP static mappings will be registered in the DNS forwarder (these hosts are found by navigating to Services -> DHCP Server and scrolling down to “DHCP Static Mappings for this interface“).

At “Host Overrides“, (near the bottom of the page) specify individual hosts to be served as DNS records by clicking the “plus” button to add a record. Devices in this list are checked first, so even if a record exists elsewhere, the record here takes precedence and is immediately returned. Scrolling even further down the page and just below “Host Overrides“, you will see the “Domain Overrides” section. Here you can specify a DNS server for a particular domain by clicking the “plus” button to add a record. These records are checked immediately after the individual records are defined above. Thus, a match here will take precedence over records that may exist elsewhere.

Configuring Additional Options

DNS tools

Additional options of the DNS Forwarder under pfSense 2.1

As with most DNS tools, here are some other options available. If you check “Resolve DHCP mappings first“, then DHCP mappings will be resolved before the list specified in “Host Overrides“. This only affects the name given for a reverse lookup. As of pfSense 2.1, the “DNS Query Forwarding” subsection contains three options. Checking “Query DNS servers sequentially” causes pfSense DNS Forwarder (dnsmasq) to query the DNS servers sequentially in the order specified at System -> General Setup under the DNS Servers tab, rather than all at once in parallel. Checking the “Require domain” checkbox will prevent DNS Forwarder from forwarding A or AAAA queries for plain names (without dots or domain parts) to upstream name servers. If the name is not known from /etc/hosts or DHCP, then a “not found” answer is returned. Finally, checking “Do not forward private reverse lookups” prevents DNS forwarder from forwarding reverse DNS lookups for private addresses (those defined as such in RFC 1918) to upstream name servers. Any entries in the “Domain Overrides” section forwarding “” private names to a specific server are still forwarded. If the IP to name is not known from /etc/hosts, DHCP or a specific domain override, then a “not found” answer is returned.

At “Listen Port“, you can specify a port used for responding to DNS queries (the default is 53), which is useful if another service needs to bind to TCP/UDP port 53. Under “Interfaces“, you can choose the IPs that will be used by the DNS Forwarder for responding to queries from clients. The default behavior is to respond to queries on every available IPv4 and IPv6 address. Each interface is listed twice; e.g. “WAN” and “WAN IPv6 Link-Local“; thus you can limit responses to those clients on a specific interface or clients on a specific interface with an IPv6 address. “Localhost” is also an option. If you check “Strict Interface Binding“, the DNS Forwarder will only bind to the interfaces containing the iP addresses selected in the “Interfaces” list box. This option does not work with IPv6. Finally, under “Advanced” you can enter any additional options you would like to add to the dnsmasq configuration, separated by a space or newline.

When you’re done configuring options in this section, press the “Save” button to save the changes, and on the next screen, press the “Apply changes” button.

External Links:

Undersanding DNS Forwarding at

DNS Forwarder at

Link Ads:

Static DHCP Mapping in pfSense

In the previous posting, I covered how to configure basic settings for the DHCP server. In this part, I cover static DHCP mappings. A static DHCP mapping ensures a client is always given the same IP address.

Static DHCP Mapping: First Method

Static DHCP Mapping

Edit static mapping page in the pfSense web GUI.

In order to add static DHCP mappings, browse to Status -> DHCP Leases to view the list of clients who have been issued DHCP requests. Click the “plus” button to add a new static DHCP mapping. The MAC address field will be pre-filled; enter an IP address, which must be outside of the range of dynamically assigned DHCP addresses. Finally, enter a “Hostname” and “Description” if desired. Now press “Save” to save the changes, and “Apply” to apply changes if necessary.

Static DHCP Mapping: Second Method

If no DHCP leases have been issued yet, you may not be able to add static DHCP mappings from Status -> DHCP Leases. Fortunately, there is a second method for adding static DHCP mappings. Browse to Services -> DHCP Server -> Interface (if you followed along with my previous DHCP setup scenario, the interface will be “LAN“). Scroll to the bottom of the page, and you will find “DHCP Static Mappings for this interface.” Click on the Add button to the right. From the Services ->  DHCP -> Edit static mapping page, you can type in “IP Address“, “Hostname” and “Description“, as described above.

Now, when a client connects to your DHCP server, the firewall will first check for a mapping in the “DHCP Static Mappings” table. If the client’s MAC address matches a mapping you specified, then the DHCP server uses the IP address specified in the mapping. If no mappings exists for your client’s MAC address, your DHCP server uses an IP address from its available range. Alternatively, you could have selected “Deny Unknown Clients” under Services -> DHCP Server -> Interface, in which case the client will not get a DHCP lease unless the client is defined in the static mappings table.

Static mappings can always be viewed at the bottom of the DHCP Server configuration page for each interface. All static mappings for a given interface can be managed here. Existing mappings can be modified or removed, and new static mappings can be created (but you will have to enter the MAC addresses manually).

External Links:

Configuring DHCP Server and Dynamic DNS Services


DHCP Server Configuration in pfSense


pfSense’s DHCP configuration page in the web GUI.

In the first four parts, I covered installation and setup from the LiveCD, general configurations in the web GUI, WAN and LAN configuration, and setting up a DMZ. In this part, I cover setting up a DHCP server within pfSense. In many scenarios, you will want your pfSense router to also act as a DHCP server. In this case, pfSense’s DHCP service will assign an IP address to any client who requests one.

To configure the DHCP server, go to Services -> DHCP Server. Choose the interface on which the DHCP Server will be active (in this case, I chose LAN). Check “Enable DHCP server on LAN interface“. The next option is “Deny Unknown Clients“. Enabling this option ensures that only clients with static DHCP mappings will receive an IP address. DHCP requests from all other clients will be ignored. If you enable this option, you will have to enter the static DHCP mappings at the bottom of the settings page. Static DHCP mappings will be covered in the next article.

Next, at “Range“, choose a range of IP addresses for DHCP clients to use. THe range must be contiguous and within the available range listed above “Range“.

The next setting is “WINS Servers“. WINS stands for Windows Internet Name Service, which is used to map NetBIOS names to IP addresses on Windows-based systems. Unless you are running a WINS server, you can leave this field blank. Next is “DNS Servers“. Here you can specify any DNS server to be automaticaly assigned to your DHCP clients. If left blank, pfSense will automatically assign DNS servers to your clients on one of the following two ways:

  • If DNS Forwarder is enabled, then the IP address of the interface is used. This is because the DNS Forwarder turns the pfSense machine into a DNS server, so the IP of the pfSense machine is assigned to each client.
  • If DNS Forwarder is not enabled, then the DNS servers entered on the “General Setup” page are used. And if “Allow DNS server list to be overridden by DHCP/PPP on WAN” is enabled in “General Setup”, then the DNS servers obtained through the WAN will be used instead.

The next option is “Gateway“. The interface gateway will be provided to clients by default (the static IP of the interface), but it can be overridden here if necessary.The domain name specified in the General Setup is used by default, but you can specify an alternative under “Domain Name”.

An alternative lease time can be specified under “Default Lease Time” for clients who do not request a specific expiration time. For those who request a specific expiration time, you can set an alternative under “Maximum Lease Time“.

CARP-configured systems can specify a fail-over IP address under “Failover Peer IP“. Enabling “Static ARP” will only allow clients with DHCP mappings to communicate with the firewall on this interface. Unknown clients will still receive an IP address from the DHCP server, but communication to the firewall will be blocked. [This differs from “Deny Unknown Clients“, where unknown clients won’t get an IP address.]

Dynamic DNS” enables clients to automatically register with the Dynamic DNS domain specified. Under “Additional BOOTP/DHCP Options” allows you to enter custom DHCP options.

Press the “Save” button to save the changes, and press the “Apply” button to apply changes, if necessary.

By now, your DHCP server should be up and running and ready to accept clients. In the next article, I will cover static DHCP mappings.

DHCP Configuration External Links:

DHCP server documentation at
BOOTP/DHCP options

pfSense Setup: Part Three (WAN and LAN Settings)

In pfSense Setup: Part Two,  I covered General Settings within the pfSense web GUI. In this part, I cover configuring the WAN and LAN interfaces. There are a number of different options here; fortunately, pfSense makes the job easy on us by creating reasonable defaults. From the pfSense web GUI menu, go to Interfaces -> WAN.

pfSense Setup: WAN Interface Settings


The WAN settings page in the pfSense web GUI.

The WAN interface provides your connection to the Internet. To access the WAN, you will need a properly-configured WAN interface and an Internet connection. Typically your Internet connection will be through a cable modem provided by your Internet service provider (ISP), but pfSense will support other connection methods as well.

To configure the WAN interface, browse to Interfaces | WAN. Under “General Configuration”, check Enable Interface. You can change the description of the interface (Description).

The next item is “Type”. Here you can choose the interface type. “Static” requires you to type in the WAN interface IP address. “DHCP” gets the IP address from the ISP’s DHCP server, and is probably what you want to select. “PPP” stands for Point-to-Point Protocol, a protocol used for dialup modem connects as well as T-carrier, E-carrier connections, SONET and SDH connections and higher bitrate optical connections. “PPPoE” stands for Point-to-Point Protocol over Ethernet and is used by a number of DSL providers. “PPTP” stands for Point-to-Point Tunneling Protocol and is a method for implementing virtual private networks (VPNs); unless your WAN interface is a VPN you won’t want to choose this option. “L2TP” stands for Layer 2 Tunneling Protocol, a tunneling protocol also used with VPNs.

The next option is MAC address. Typing in a MAC address here allows you to “spoof” a MAC address. The DHCP servers of ISPs assign IP addresses based on MAC addresses. But they have no way of verifying a MAC address, so by typing a different MAC address, you can “force” your ISP’s DHCP server to give you another IP address. Unless you want to spoof your MAC address, you can leave this field blank. MTU stands for maximum transmission unit. Larger MTUs bring greater efficiency but also greater latency. This should probably be left unchanged. MSS stands for maximum segment size, and specifies the largest amount of data pfSense can receive in a single TCP segment. This also should likely be left unchanged.

The next section is different depending on what you selected for the interface type. If you selected “DHCP”, the options will be “Hostname” and “Alias IP Address”. Hostname can be left blank unless your ISP requires it for client identification, and Alias IP address can also be left blank unless the ISP’s DHCP client needs an alias IP address.

The next section is “Private Networks”. Checking “Block private networks” ensures that 10.x.x.x, 172.16.x.x, and 192.168.x.x addresses, as well as loopback addresses (127.x.x.x) are non-routable. This should be left checked under most circumstances. “Block bogon networks” blocks traffic from IP addresses either reserved or not yet assigned by IANA. This should be left checked as well, for obvious reasons.

Save the options and move on to Interfaces -> LAN.

pfSense Setup: LAN Interface Settings


The LAN settings page in the pfSense web GUI.

Under “General Configuration”, “Enable Interface” should be checked, since unchecking it will prevent the local network from connecting to the router. “Description” allows you to type in a description of the interface.

“Type” allows you to choose an interface type. See the section on WAN settings for an explanation of each of the options. “MAC address” allows you to type in a different MAC address in order to do MAC address spoofing. Again, see the section on WAN interface settings for a more detailed explanation. “MTU” and “MSS” are also explained under WAN settings. “Speed and duplex” allows you to explicitly set speed and duplex mode for the interface; pfSense should autodetect this, so this option should be left unchanged.

If you selected “Static” for the interface, there should be a “Static IP Configuration” section with two options: “IP address” and “Gateway”. With “IP address”, you can change the IP address of the LAN interface (it defaults to

The next section is “Private networks”. The two options are “Block private networks” and “Block bogon networks”. See the section on configuring the WAN interface for detailed explanations of these options.

That does it for WAN and LAN settings. In pfSense Setup: Part Four, I will take a look at setting up an optional interface.

The Rest of the Guide:

Part One (installation from LiveCD)

Part Two (configuration using the web GUI)

Ad Links:

© 2013 David Zientara. All rights reserved. Privacy Policy