Firewalling Network Traffic

Some techniques
[#blknetrf]: Blocking/denying traffic

The firewall may decline to have the traffic go where it is desired to go. Terms may include blocking, denying, discarding, or using one of the names of the following subcategories.

[#drpnetrf]: Dropping Traffic

Traffic is not passed onto any programs. The firewall software either stops doing anything about the traffic (performing only routine clean-up procedures like erasing the traffic's contents from any of the firewall's memory), or redirects the traffic to a sort of “null” virtual device which will accept the traffic and do nothing with it. A port which receives traffic that gets dropped may be referred to as a “closed” port. (However, some documentation may use the term “closed” port to also refer to a “stealth” port. See the section about declining network traffic for details.)

This could be implemented by redirecting traffic to a “null” device, which may be described as a sink or commonly by the phrase “bit bucket”. (The point in redirecting the traffic to be discarded, instead of just discarding the traffic, is to simplify the logic of traffic handling. Redirecting traffic to a null device allows the traffic to be routed/redirected. Since the traffic being routed/redirected, there may be some similarities to the immediate action taken for passed traffic. This similarity may allow certain rules/code to be simplified and may, coincidentally or perhaps because of that simplification, provide some easier optimization opportunities.

[#dclnetrf]: Declining Traffic

This is similar to dropping traffic, in that the traffic doesn't reach the destination. However, instead of silently dropping traffic, a diagnostic response may be given. The firewall will send a packet to the location that was listed as the “source” of the traffic that failed. Specifically, TCP traffic may send a TCP packet with the “RST” flag set to a value of one, and ICMP traffic may send an IMCP “Unreachable” packet. Other types of packets, including UDP packets, might not have a standard method to decline the traffic, so the common approach (even by polite machines that decline the declinable types of traffic) is to silently drop such blocked traffic.

A network address that drops traffic may be referred to as a “stealth” address. That term may apply for IMCP traffic. A machine that provides any response to any TCP traffic may not be considered to be “stealth” for the whole machine, but an individual TCP port which doesn't respond may be known as a “stealth port”. (When discussing TCP, it is more common to refer to stealth ports, even if every possible TCP port is stealth.) (A stealth address/port may be considered to be a type of a “closed” address/port by some documentation, particularly documentation that doesn't use the term “stealth” to describe addresses and/or ports that may deny traffic. However, to reduce some potential confusion, it may be better to use the adjective “closed” only when describing an address/port that drops network traffic.)

[#pasnetrf]: Passing Allowed Traffic

Passing doesn't necessarily mean forwarding: the term passing mainly refers to handling traffic in a way different than blocking the traffic. (If the traffic is forwarded, then the traffic may end up getting passed onto another NIC. If the traffic is meant for the local machine, then it will get passed onto additional handling by the network stack; frequently that will involve the TCP or UDP support sending traffic to a program listening on an appropriate port.) Traffic that is accepted by a program (on the device receiving the traffic) must be passed traffic, or else the program will not see the traffic.

Accepting allowed traffic

If the traffic is meant for the machine that has received the traffic, then the traffic may be passed onto the “layer three” network stack. The most common “layer three” network stack implementation is to check for IPv6 traffic and/or IPv4 traffic. Such traffic is then processed to look for TCP or UDP traffic or ICMP traffic. ICMP traffic may be responded to by the core/critical software that is serving as a network stack. TCP and UDP traffic is responded to by looking for any open ports (from an “established” TCP connection, or from a port number that has a program “listening” for traffic), and sends allowed traffic to whatever software is set up to receive traffic that is sent to that network port.

ICMP

Supporting “ICMP messages” can be quite useful. Details may be covered within the specific sections of various firewalls. For example, Microsoft's “Windows Firewall” may block some ICMP messages (including all IPv4 ICMP messages) by default, but the section on Microsoft's Windows Firewall discusses how to enable such traffic.

Forwarding traffic
If the network traffic is meant for a network destination other than the machine that received the traffic, then the machine may forward network traffic. This may be implemented using tools outside of the firewall software implementation, so check the section about traffic forwarding for details. However, in many cases, NAT may also be needed. The NAT implementation may commonly be performed by firewall software, so do check this section (about firewalls) for details about implementing NAT.
Modifying traffic
[#nat] Network Address Translation (“NAT”)

Perhaps the abbreviation NAT referred to slightly different wording, as shown in the title of RFC 1631: The IP Network Address Translator (NAT) which shows a date of May 1994. (A newer release, RFC 3022: Traditional IP Network Address Translator (Traditional NAT) has also been released.) However, when actually working with computers, modern documentation (software manuals, networking books) and discussions (if someone actually states the full name instead of just referring to the abbreviation) all tend to use the term “Network Address Translation”.

Some details/commentary of NAT is currently provided by some entries in the glossary. Check out: glossary: network address translation (“NAT”) and similar terms: glossary: network address translation (“PAT”) (a.k.a. glossary: network address port translation (“NAPT”)

NAT support by firewalls

For details about how NAT gets set up with various specific implementations, the details provided about specific firewall implementations may cover the topic of setting up a NAT when using a firewall. So, see the section about firewall implementations.

NAT-providing software

Another piece of software which provides support for NAT is the “Routing and Remote Access (Service)” (“RRAS”). (RRAS does not provide much else as far as firewalling, because such firewalling behaviors are covered by other software such as Windows Firewall.)

More info about RRAS is covered by part of the section on Enabling traffic forwarding in Microsoft Windows. TechNet: “Enable RRAS as a VPN Server and a NAT Router” says “IPv6 does not support NAT. If your server is IPv6 only, then skip the steps in the rest of this procedure.” To clarify: NAT is a technology that certainly could be implemented for IPv6. The TechNet page must have just been referring to RRAS's support for NAT. (The page says it “Applies To: Windows Server 2008 R2”.)

Some other software believed to provide NAT: Microsoft's Internet Connection Sharing (“ICS”), and probably also Toolnet6 (old third party support for IPv6 in WinNT/95/98).

Redirecting traffic

Traffic may be redirected to a proxy (e.g. an FTP proxy) and/or sandbox. In at least some cases, this may happen rather transparently.

Asymmetric routing

Asymmetric routing may occur. Note that this can be done transparently without any real problems. However, things can get interesting when asymmetric routing is not handled properly. Endpoint configuration can also represent substantial opportunity for things to not be handled properly. Here are some examples of how asymmetric communications may have issues:

  • If a device that performs NAT is only seeing some of the traffic, such as traffic in one direction, then the unseen traffic may not be appropriately translated. The untranslated traffic might not be forwarded (because it wasn't appropriately modified by NAT). Even if the traffic does reach the destination, the address seen by the destination device might not match what is expected by the destination device. (The traffic received from the destination may not have a “Source” address that matches what the destination expects.) The destination may not fully accept such traffic. This same effect, and consequences, may occur if the reply traffic uses a different network address when performing NAT, possibly because a differnet network interface is used.
  • As a hypothetical example, if a firewall device that provides “intrusion prevention system” functionality see the second part of a TCP handshake, then the presense of the third part of a TCP might seem odd enough that the firewall considers the unexpected type of packet to be breaking rules, and possibly being an attack. This may result in consequences such as packets being dropped.

Intentionally performing asymmetric routing is probably not a good idea for beginners who want to minimize the amount of time taken to troubleshoot.

Using asymmetric routing may currently be covered a bit more in the section about routing: see Direct (Server) Return/Routing. Surely there may be other ways to make things asymmetric.

Types of traffic

There are many, many different categories that can describe different network traffic. This is not meant to be an exhaustive list.

[#icmpmsgs]: ICMP Messages
ICMP Messages

Internet Control Messaging Protocol is a way for a network device to send a standard message to another device. IANA ICMP Message Parameters lists the Message Type numbers of the common messages used by ICMP for IPv4. IANA ICMPv6 Parameters also has a similar list that covers the message types utilized when using IPv6.

The most well-known ICMP message types may be the “Echo Request” and “Echo Reply” message types. When a computer runs the ping command, it will send out an “Echo” Message. In some operating systems, including Microsoft Windows, the TraceRoute program (traceroute in some operating systems, although tracert in other operating systems including Microsoft Windows) may use these same ICMP Message Types. (In other operating systems, traceroute may actually use UDP by default, although ICMP might be a supported alternative.)

After an “Echo” (ICMPv4 Message Type 8 or ICMPv6 Message Type 128) message is sent out, generally it is then hoped that the system will receive a message which is called an “Echo Reply” (ICMPv4 Type 0 or ICMPv6 Type 129). However, sometimes other responses may be found, such as “Destination Unreachable” (ICMPv4 Message Type 3, ICMPv6 Message Type 1). For instance, if the remote system is unable to be looked up via a standard ARP request, the local TCP/IP stack may generate such a packet. The ping may report “Destination host unreachable.” (The ping command may also say that the computer originating this message is using the IP address of the network interface that sent out the ARP request.)

With IPv6, ICMPv6 has even stronger importance. ICMPv6 is used for Neighbor Discovery Protocol, which gets used with SLAAC to automatically assign IPv6 addresses. Also, ICMPv6 is used by the Multicast Listener Discovery (MLD) protocol which effectively performs the role that IGMP did to support multicast in IPv4.

Firewalls may be prone to block at least some ICMP Messages.

IANA Protocol Numbers, as well as some older RFC's, have reserved protocol number 1 for TCP. This protocol number is used by the “Protocol” field of IPv4 packets, as well as the “Next Header” field of IPv6 packets.

So, ICMP uses IP, but uses a different protocol number than TCP or UDP. Because ICMP does not provide the functionality of the Transport Layer (Layer 4) of the OSI Model, it is not considered to be a Layer 4 protocol (even though it does utilize IP which fits at Layer 3 on the OSI Model). It is, therefore, considered to be a Layer 3 protocol (which has its information encapuslated into another Layer 3 protocol).

Some older text about ICMP Echo Requests

The most likely IPv4 diagnostic traffic that is likely to be blocked, but also likely to be useful, may be the ICMPv4 “Echo Request” traffic. This is called the “echo message” by RFC 782 (page 14), although it is commonly called “Echo Request”. An ICMPv4 “Type” is a number, and the ICMPv4 type for “Echo Request” is the number 8. (Most/all references to the number 8 in guides to allowing ICMP probably refer to the ICMPv4 type.)

In many cases, an option may be to disable firewall software entirely. This might not really be bad to do when the system is on a trusted network, although a generally safer practice would be to just allow the specific traffic which is desired.

IANA Protocol Numbers shows that protocol number 1 is reserved for ICMP, although that is mainly referring to IPv4. The number 58 is the corresponding value of the “Next Header” field of an IPv6 packet which is using IPv6.

Some other traffic handling (commonly implemented by firewalls)
[#portfwdi]: Port forwarding
e.g., a router sending traffic meant for one port on one address to another port on another address. (Sometimes port forwarding is combined with tunneling traffic.)
Port triggering

Allowing firewall rules to be modified, generally to allow specific incoming connections, after a machine on the inside makes a request to allow that sort of incoming connection.

As an example, an FTP proxy will commonly implement the generalized concept of port triggering. If an FTP connection is made from an inside machine to an outside machine on port 21, then that trigger leads to the firewall planning to automatically forward traffic from that remote FTP server's port 20 to the same internal machine that initiated the FTP connection.

Port triggering is sometimes discouraged by network administrators who would prefer to be manually bothered every time a new port needs to be opened. The simple logic there is that it helps the network administrator feel more control over what sort of incoming connections may exist.

Port knocking
Using a secret handshake to open a desired port. This could be implemented by running a port knocking server software that looks for some sort of signal/signature, such as various TCP connections. (The knock could then usually be implemented by anybody who had the right knowledge and who had an available telnet-capable client.) Other signals, such as the presense of an acceptable message that is signed with a certain key. Once the port knocking server was satisfied, it could implement port triggering (meaning that it requests that the firewall allow a certain type of connection). Wikipedia's page on Port Knocking.
Automatic Firewall Rule Adjustments

After a device (like a computer) makes a specific and accepted request to another device (like a firewall), the latter device (like a firewall) redirects certain incoming traffic to go to the device (like a computer) that made the accepted request.

Universal Plug 'n' Play (“UPnP”)
...
Authpf

Some information: OpenBSD PF Guide to Authpf.

Note: Authpf may be used for more than just redirecting incoming traffic to a device that requests such a rule. It may also allow incoming traffic from an outside to access multiple resources, like a VPN, or a more limited set of resources (like only a single desktop). It may also be used to effectively sandbox users.

[#frwliplm]: Firewall Implementations
Firewall software
[#tcpwrapr]: TCP-Wrappers

TCP-wrappers might not commonly be thought of as firewall software, although it does basically serve the purpose of firewall software. It is probably not sufficient, or at least recommended, to be used alone, but can be effectively used in addition to other firewall software. (Since the basic implementation of TCP-Wrappers is to be used in addition to other firewall software, general claims about not using multiple firewalls probably does NOT apply.)

sendmail.org FAQ 2.15 (Currently, at the time of this writing, the FAQ mentioning TCP-wrappers has some info.)

PF

PF's syntax (similar to IPF/IPFilter) is fairly straightforward. The software is also quite powerful: The use of named anchors that allow software to modify the rules allows for an extremely simple “ftp-proxy” implementation and provides enough power and flexibility for Authpf (see also authpf-noip???)

Here are some resources for reading about how to set up this firewall:

require-order has been removed. (At the time of the writing, OpenBSD 4.9 is the latest version. This change will probably take effect in OpenBSD 5.0.)

Quick guide
Enabling

This is probably enabled to start with.

To test a firewall configuration file, run “ pfctl -n -f /etc/pf.conf ”. If that has no problems, enable it with “ pfctl -f /etc/pf.conf ”. If that fails to take effect, try the more aggressive method of “ pfctl -F all -f /etc/pf.conf ” This may flush tmeporary states, which might break any existing connections. (However, things may work better after that is done.)

Disabling
pfctl -d ” may do the trick. This may cause the program to stop interfering in undesirable ways. Naturally, this may also have some effects like disabling protection, or enabling NAT. (So, disabling the software could lead to more things breaking, and possibly not fixing anything.)
Handling the configuration file
Official documentation

Some guides to the configuration file include more about much of the rest of the flexibility, see Guide to PF (The OpenBSD Packet Filter): section on Rule Syntax. This is also documented more by OpenBSD Manual Page for the pf.conf file (in /etc/).

Using quick

This example rule for blocking traffic was intentionally made so that, after defining the allowed systems, the traffic to be blocked could be expressed in just one rule. This is better than blocking all traffic and then allowing exceptions, because it allows the quick keyword to be used (as described by Guide to PDF (The OpenBSD Packet Filter): section on the keyword “quick). This allows for faster parsing whenever such traffic is encountered, and eliminates the ability of a later (perhaps more generalized) rule accidentally overriding this rule.

Using the quick keyword is likely a great idea any time that a rule is definitely going to be the last rule that applies to all traffic that is actually described by the rule. This guideline could potentially result in some pretty heavy usage of the quick keyword. If used appropriately, that is not a bad thing. It could mean that some more generalized rules early in the file will have an impact, despite more specific rules later in the file. That has an unfortunate impact on the easy readability of the rules. However, when doing a sequential manual parsing (much like what the software may do), this style allows certain types of traffic to be completely ignored after a certain early point, and that is a nice impact when trying to understand the rules.

NAT
(This section currently has info about PF that is not very specific to NAT. Such info should be moved and referenced. (That will cause this section about NAT to be smaller.)
Some official documentation on PF's support for NAT
Part of PF User's Guide, OpenBSD PF: Network Address Translation (NAT) has some details. OpenBSD Manual Page for the /etc/pf.conf file: section about “Packet Filtering” has a subsection called “Translation”.
/etc/pf.conf contents

The /etc/pf.conf file may contain references to the network interfaces that are being used on the machine. It may be nicer to use variables that have references to the interface names. This way, the /etc/pf.conf can simply contain rules that involve variable names. If a network interface ever has its name changed (perhaps due to a NIC being added or removed), or if the configuration is ever used on another machine (because the functionality of the firewall is being moved to other hardware, or because a successful firewall rule is being copied to another machine that will also implement firewalling), it may be nicer to not have the rule file contain NIC names. Also, it is less likely that the section that most needs customization, which is the section describing NIC names, will end up being overwritten due to a careless upgrade.

Since PF's syntax allows loading other files for configurations (ever since support was added after OpenBSD 4.2), this can be done easily. For instance, make a new directory called /etc/pf/ (simply because this directory name was used in at least one example from OpenBSD's man page for the pf.conf file), and then make a new /etc/pf/pfnics.cnf file with lines that identify the NICs.

ext_if=if0
intlan_if=if1
intwifi_if=if2

In the above example, be sure to customize the NIC names (shown to the right of the equal signs). (Details about finding the names of the NIC are available in the section about determining available NICS.) If there is no WiFi adapter, it may make sense to define intwifi_if anyway. The simple reason there is so that rules involving WiFi can be easily used without modification. Since WiFi is often treated similar to an internal LAN, changing the last line to say the following may work well:

intwifi_if=$intlan_if

In case IPv6 traffic is going out a different interface than other traffic, some rules in this example documentation may reference the external interface used for IPv6 traffic. In case that is the same as the standard external interface, something like the following may work:

ip6_ext_if=$ext_if

If IPv6 traffic is going out some sort of IPv6/IPv4 tunnel, perhaps the above example would not be as appropriate as the following:

ip6_ext_if=gif0

Now, onto making some rules that reference these NICs...

Implementing NAT

The classic reason why NAT has been used, probably more often than any other reason, was due to a scarcity of easily routable IPv4 addresses. Here are some details about how to implement NAT to handle that.

Current syntax
OpenBSD 4.6 to 4.7's guide about pf NAT syntax change provides one of the simplest summaries. However, the summary is a bit incomplete (because using a match rule is only the first part of the process), and the whole process can be even easier. There are basically two ways to do this:
  • The simpler approach: use a pass rule that uses the nat-to option
  • The way that seems to be recommended more often by the documentation: a two-part process
    • Use a match rule that uses the nat-to option. This will apply the nat-to option to the traffic, and affect what happens to the traffic if the traffic is later affected by a pass rule.
    • Use a pass rule to pass the traffic.

Here is a fairly simple file that implements NAT. (The example contents shown below may be a complete file. Or, with newer versions of OpenBSD, this simple example may be appended to the bottom of the default file, which should be backed up before being changed. That is probably the better way go to with newer OpenBSD versions. OpenBSD 5.0 upgrade guide: section about PF notes that “ruleset ordering” requirements “have not been enforced by default for some time.” The OpenBSD 4.5's Manual page for pf.conf file, and at least some earlier versions, mentioned a recommended/required order.)

include "/etc/pf/pfnics.cnf"

table <ietfbcp5> persist { 10/8 172.16/12 192.168/16 }
table <intaddr> persist { $intlan_if:network $intwifi_if:network }
# It may be worthwhile to add a reference to internal addresses that are given
# out to authorized VPN users.

# We never want to pass out traffic from a private address.
# (This is optional if another device, outside this network, addresses this.)
pass out on $ext_if inet from { <ietfbcp5> } to any nat-to ($ext_if:0)
pass out on $ext_if inet6 from { fd00::/8 } to any nat-to ($ip6_ext_if)
# The following rule does not use aliases, so just uses the first address.
# This is probably not desired since non-link-local IPv6 will
# using aliases (and quite possibly multiple aliases)
#pass out on $ext_if inet6 from { fd00::/8 } to any nat-to ($ip6_ext_if:0)

# Until we get routing configured, NAT may be a cheap and dirty method to help
# traffic from external address ranges to be able to reach devices/NICs on
# internal address ranges.  Due to NAT, external devices that communicate
# with the firewall won't need routing rules for the internal addresses.
# This gruesome hack has drawbacks; some will prefer setting up routing.
# Example: TCP should work.  Maybe some other traffic won't work as well.
pass out on $ext_if inet from { $intlan_if:network } to any nat-to ($ext_if:0)

If the above is problematic (apparently it is not, but these notes are remaining until that is re-tested again), here are some more things to try:

  • If that doesn't work, try changing the pass rules to match rules, and then add a pass rule at the end (e.g. pass any). Debug from there.
  • If that doesn't work, try referencing the subnets by IP address range, instead of trying to reference the interface.
  • If any of this works/doesn't, try changing $ext_if to $ext_if:0 or $ext_if:network
  • Use “ pfctl -F all
  • If “ pfctl -s all ” shows:

    FILTER RULES:
    No queue in use

    then re-load (by using “ pfctl -f /etc/pf.conf ” again).

Make sure items are in the right location. (Or is that less of an issue with OpenBSD 4.7's PF? mailing list archive: OpenBSD-Tech mailing list mail from 2010-May-22 21:02:35 seems to suggest this might not be as big of a deal? Even if it was, was there a command to reduce the strictness?

Things to customize: the interface names. To see what the names are, see the section about available NICs. If this machine does not have a WiFi connection (or a NIC dedicated to the WiFi connection), remove references to intlan_if. (The best way to do this may be to comment out an entire line and, if needed, make a new line with the reference deleted.)

Note: It is believed that if there are any subsequent pass rules, those may overwrite the earlier pass rules. (Make sure that the latest applicable rules also have the needed nat-to infromation.)

Earlier syntax

As mentioned by OpenBSD 4.6 to 4.7 Upgrade Guide: section about pf's “NAT syntax change”, there were some changes going into OpenBSD 4.7. There was a “no nat” command (which mailing list archive: OpenBSD-Tech mailing list mail from 2010-May-22 21:02:35 states as not being needed with the newer syntax).

Using an updated configuration

Test the syntax of the new /etc/pf.conf file by running:

sudo pfctl -n -e -f /etc/pf.conf

If all goes well, attempt to have the new rules take effect, by dropping the -n and running:

sudo pfctl -e -f /etc/pf.conf
[#pfflshst]: Flushing old states (and similar)

In many cases, the above will work for brand new connections/states. However, sometimes some old settings/values may be remembered. For simple cases, these old settings will not be needed, but sometimes they may have an undesired impact. Specifically, a change to the rules may not seem to work as expected. A pre-existing session of ping may have even new packets being treated like an already-existing state, and be subject to some old and remembered rules.

Fixing this situation might not require any change in the rules (or any other sort of change to the configuration file). In fact, trying to change the configuration file again may result in the old states still remaining unchanged, so such a change may have no positive effect.

Instead, there are other ways to deal with the issue. One way to work around this might be to disconnect any sessions, including quitting any programs with already-existing network connections, in hopes that this will cause old states to be replaced. Another method, which is probably better, may be to use one or more lossy commands that resolve things by losing the information about old states created before the ruleset changes. Note that this command may, in some way, be lossy about the rather current state of the firewall. (This is probably okay if it means getting things working again.)

sudo pfctl -F states

If the above doesn't work, the next command will erase even more information about the current state of the firewall, including the rules, and so then the following command is needed to re-load the rules. Note that taking it to this extreme may be even less likely to do any good; it may be more worthwhile to check the rules carefully. However, if everything really does look good, the following might eliminate a temporary (but possibly currently impactful) problem that would be difficult to trace down:

sudo pfctl -F all

However, although this may fix some lingering issues, doing this also clears out ALL of the rules:

# sudo pfctl -s all
FILTER RULES:
No queue in use

[...]

So, after doing a “pfctl -F rules” or “ pfctl -F all ”, re-load the rules again. The following command line will do that nicely.

sudo pfctl -e -f /etc/pf.conf

This may happen more commonly when using some of the more advanced functionality/features (possibly including things like a table, or possibly network address translation (including incoming redirection). It may (with slighly less likelihood) also be true that more limited flushing, using -F nat or -F Tables (or both), may have many/all of the same desirable results. If any of these flushing techniques work, the cause is likely related to remembered information before the latest configuration was reloaded. So, repeating the process (of flushing) will probably not be necessary until more changes are made to the configuration file.

Starting the software automatically
In OpenBSD, see /etc/rc.conf.local and make sure a line says pf=YES (unless any more elaborate line is needed and/or is there).
Handling incoming traffic
Passing traffic to another machine
Historical note

When OpenBSD 4.7 came out, there were some changes to PF, and this mandated changes in some commonly used PF rules. Some changes in logic may be needed for some rules. For further details, read OpenBSD Upgrade Guide 4.7, including the reference to the Mailing list article announcing pf.conf syntax change.

The syntax was very similar to the new syntax, except that instead of the newer rdr-to or nat-to vocabulary, a multi-character string of -> was used, and instead of “match in on” or “match out on” or “match on” the line started with rdr on or nat on or binat on. So, really the newer version seems to have a slightly more challenging syntax, although the new syntax enabled some improvements to the PF code. With the old version of PF, the network translation could happen immediately, before block/pass rules get parsed. With the new version, blocked traffic will not be parsed by a subsequent match rule, so there is a two-part process of passing traffic (if it isn't already somehow already being passed by default) and then performing the process of matching and manipulating (redirecting) the already-passed traffic.

PF from OpenBSD 4.7 (and newer)
pass in on $ext_if proto {tcp, udp} from any to ( $ext_if ) port=53
match in on $ext_if proto {tcp, udp} from any to ( $ext_if ) port=53 rdr-to $systemUsedAsDestination
Older OpenBSD Syntax

The following was used with OpenBSD 4.4. This specifically redirected DNS traffic: a variation that simply did not include the phrase port=53 would redirect traffic without caring what TCP port or UDP port was being used.

rdr on $ext_if proto {tcp, udp} from any to ( $ext_if ) port=53 -> $systemUsedAsDestination

(This assumed that $ext_if and $systemUsedAsDestination were defined previously in the file.)

Blocking traffic

See the section about handling the configuration file.

e.g.:

table <oksmtp> { 192.0.2.25, 2001:db8::25 }
block out quick on { $ext_if $extipv4_if } inet proto tcp from ! <oksmtp> \
to any port=smtp

There is a fair amount that may be customized there. Cheifly, the names of the NICs need to be defined. That part is not shown here (although it is shown more in the guide to implementing NAT).

Leaving off the word inet will cause all supported address families to be referenced. At the time of this writing, there are only two address families: inet (for IPv4) and inet6 for (really... does this need to be clarified? IPv6, of course!)

[#ipfw]: IPFW
...
[#ipfilter]: IPFilter (a.k.a. IPF, IPFILTER)
...
[#netfiltr]: Netfilter

Netfilter is a framework that some other firewall software is built off of. The Netfilter Core Team, also known as coreteam, may oversee some of the firewall software. Such firewall software includes:

[#iptables]: IPTables
...
[#ipchains]: IPChains
...
[#ipfwadm]: ipfwadm
...
Firewall software by Microsoft
[#mswnfirw]: Windows Firewall
Overview: How this has been improved from ICF

Article on Windows XP SP2 notes the updated Windows Firewall introduced with WinXPSP2 “adds outbound scanning capabilities and other features previously found only in the Microsoft Internet Security and Acceleration (ISA) Server 2000 enterprise server product.” Referencing “Springboard”, which was a code name for WinXPSP2, Article on Windows XP SP2 states, “The Springboard technologies also will be available for Windows Server 2003 customers in that OS's first service pack, Microsoft says.”

Allowing traffic through the firwall software bundled with Microsoft Windows

Unfortunately, the precise method(s) available for doing this have been different dependening on what version of Microsoft Windows is used. Although netsh has been the software for using a command line interface, the precise syntax has changed. As for people who prefer using the graphical interface, this interface had the notable change of adding the “Advanced Firewall” section.

Allowing port(s)

One example worth mentioning is supporting RDP. Documented method of implementing that may involve using a syntax that enables a whole group of individual rules. This might be the most efficient way. See: Remote Desktop Enabling.

Using the command line interface
For Windows 8 and newer (including Server 2012)

WinSCP.net: Guide to Windows OpenSSH server provided this PowerShell command, which should be run from a UAC-elevated PowerShell prompt:

New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -Action Allow -DisplayName SSH

Older text:
Allowing diagnostic traffic through the firewall software bundled with Microsoft Windows

Allowing ICMP traffic:

Using the command line

UNTESTED!!

Windows Vista (and Windows Server 2008) and newer

MS KB Q947709 (MS KB 947709 - newer-style URL) gives a couple of warnings: “The netsh firewall command-line context might be deprecated in a future version of the Windows operating system. We recommend that you use the netsh advfirewall firewall context to control firewall behavior.” Also, “The netsh firewall command line is not recommended for use in Windows Vista.” So, if using Vista or newer, be sure to use “ netsh advfirewall firewall ” instead of just using netsh firewall ”.

The following command line example came from MS KB Q947709:

netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
Older versions of Windows

(Note: perhaps this only works with Windows Firewall, and not the older Internet Connection Firewall software from older versions of Windows?

netsh firewall set icmpsetting 8 enable

To disable the feature, simply replace the parameter “ enable” with “ disable”. If neither is listed, “ enable” is the default, as documented by the help text that is shown when running:

netsh firewall set icmpsetting /?

(The help text shown by that command also describes the supported ICMP numbers, and information about other supported parameter(s) when the icmpsetting parameter is being used.)

Using a graphical interface
Directions in the GUI of Windows Vista, Windows Server 2008, and newer operating systems
  • The settings are NOT on the Advanced tab of Control Panel's “Windows Firewall” icon. (There is a “Where can I find ICMP and logging settings?” hyperlink that opens a help menu.) Instead, one must go to the “Windows Firewall with Advanced Security” program. A link to this program, which is the %SystemRoot%\system32\WF.msc file, which may be found in the “Administrative Tools” section (which is accessible via an “Administrative Tools” icon in the control panel, and possibly on the Start Menu's “All Programs” section, and possibly also on the Start Menu itself).
  • Check the “Inbound Rules” section.
  • The name of the rule may vary.
    Possibilities for Windows Vista
    • In Windows Vista, it may be one of the rules named “File and Printer Sharing (Echo Request - ICMPv6-In)” (for IPv6), and the similarly-named “File and Printer Sharing (Echo Request - ICMPv4-In)” (for IPv4). There may be multiple rules with each of those names: the difference between those identically-named rules is seen by the “Profile” column (which might not be visible until scrolling the scroll bar to the right). (That is just for the Echo Requests. Another ICMP setting may be “Core Networking - Destination Unreachable Fragmentation Needed ICMPv4-In)”.)
    • How-To Geek's guide to allowing Pings through a Windows Vista Firewall suggests the name of the rule is “Networking - Echo Request (ICMPv4-In)”.

Microsoft TechNet: Creating an Inbound ICMP Rule on Windows Vista, Windows Server 2008, and (other newer operating systems) describes an approach involving using “Group Policy”.

Directions for Windows XP SP2 GUI

(It is possible that these directions might really only affect IPv4.)

Control Panel, Windows Firewall, “Advanced” tab. In the ICMP section, use the “Settings...” button. Check “Allow incoming echo request”.

[#inetcnfw]: Internet Connection Firewall (“ICF”)
Overview
ICF predates Windows Firewall.
Operating Systems using this
32-bit XP w/ SP1 or no SP

32-bit Windows XP w/ no service packs, or with SP1, may have come with “Internet Connection Firewall” (“ICF”). Microsoft.com web page about path of security log file states, “Internet Connection Sharing, Internet Connection Firewall, Discovery and Control, and Network Bridge are not available on Windows XP 64-Bit Edition.”

Windows Server 2003

Microsoft's TechNet: Internet Connection Firewall Feature Overview states, “ICF ships in Windows XP or Windows XP with SP1, for both Windows XP Home Edition and Windows XP Professional. It is also available in Windows Server™ 2003, Standard Edition and Windows Server 2003, Enterprise Edition.”

So, if ICF is being used, see the section with “Directions for Windows XP with no service packs, or with SP1”

How to enable ICMP

(It is possible that these directions might really only affect IPv4.)

(This section may need to be reviewed/updated.)

Under the properties for the network adapter, choose the “Advanced” tab. There is a checkbox to entirely disable the “Internet Connection Firewall”. (The checkbox is called “Protect my computer and network by limiting or preventing access to this computer from the Internet”.) There is also a statement, “Learn more about Internet Connection Firewall.” (The latter half of those words is a hyperlink.)

There is also a “Settings...” button, and them an “ICMP” tab.

Possibly related information: Microsoft's TechNet: Internet Connection Firewall Feature Overview, Microsoft's TechNet: How to Enable Internet Connection Firewall in WindowsXP

[#msisa]: Microsoft Internet Security and Acceleration (MS ISA)

This was sometimes referred to as ISA, though for years the abbreviation of ISA more frequently referred to “Industry Standard Architecture”.

SUSE
SuSEfirewall2

Ali Aboosaidi's guide shows: “/etc/init.d/SuSEfirewall2_setup” shows help, “/etc/init.d/SuSEfirewall2_setup stop” temporarily disables the firewall, “/sbin/SuSEfirewall2 off” disables (and “/sbin/SuSEfirewall2 on” starts).

Guide to XDMCP shows some examples of adjusting firewall rules in the /etc/sysconfig/SuSEfirewall2 file. Another option might be to use YaST and choosing “Security & Users” and then “Firewall”

Dedicated firewall hardware
Cisco
ASA
...
Pix (e.g. Pix 501)
...
Watchguard

There are various interfaces provided with various WatchGuard firewalls. Some may be able to be configured using a web interface. (Try port 8000 or 8080?) There may also be some software called “WatchGuard System Manager” (abbreviated as “WSM”) which is a graphical interface for altering WatchGuard configurations. These configurations may be stored in some text files (stored on the hard drive of the system running WSM, and/or stored as an active configuration file on the WatchGuard unit itself). WSM may be obtained freely for people who have the right type of account.

SonicWall

DELL's announcement of completing acquisition of SonicWALL, Inc.. Wall Street Journal article on Dell's acquisition of SonicWALL stated, “The companies didn't disclose how much Dell agreed to pay, but people familiar with the matter valued the deal around $1.2 billion.”

Untangle
Untangle Appliances: Hardware by the organization that makes firewall software/distributions, including the GPLv2 Untangle Lite.
2Wire / Pace

Fromthe summary on Wikipedia's article on 2Wire, this company was bought out in July of 2010, by a United Kingdom company called Pace. The same Wikipedia article indicates that the company's products were distributed through communications companies (telephone companies and cable service companies).

Fortinet's FortiGate

Wikipedia's article for Fortinet/FortiGate: “GPL violations” section provides a summary, including a reference to GPL-Violations.org injunction against Fortinet. That latter article states that Fortinet “cryptographic techniques to conceal” violations. Apparently they not only used free software (instead of developing their own), but couldn't play by the rules. Speaking of Fortinet rule breaking, Wikipedia's article on Fortinet/FortiGate: section on “US government sanctions violation” discusses further law-breaking on the part of this company.

Resources/documentation

The topics of a firewall (or “packet filter”) has come up a number of times in IETF's RFC documents. For example: