Firewall Structure

Shorewall views the network in which it is running as a set of zones. Shorewall itself defines exactly one zone called "fw" which refers to the firewall system itself . The /etc/shorewall/zones file is used to define additional zones and the example file provided with Shorewall defines the zones:

net -- the (untrusted) internet.
dmz - systems that must be accessible from the internet and from the local network. These systems cannot be trusted completely since their servers may have been compromised through a security exploit.
loc - systems in your local network(s). These systems must be protected from the internet and from the DMZ and in some cases, from each other.

Note: You can specify the name of the firewall zone. For ease of description in this documentation, it is assumed that the firewall zone is named "fw".

It can't be stressed enough that with the exception of the firewall zone, Shorewall itself attaches no meaning to zone names. Zone names are simply labels used to refer to a collection of network hosts.

While zones are normally disjoint (no two zones have a host in common), there are cases where nested or overlapping zone definitions are appropriate.

Netfilter has the concept of tables and chains. For the purpose of this document, we will consider Netfilter to have three tables:

Filter table -- this is the main table for packet filtering and can be displayed with the command "shorewall show".
Nat table -- used for all forms of Network Address Translation (NAT); SNAT, DNAT and MASQUERADE.
Mangle table -- used to modify fields in the packet header.

Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables as shown in this table.

CHAIN	Filter	Nat	Mangle
PREROUTING		X	X
INPUT	X		X
OUTPUT	X	X	X
FORWARD	X		X
POSTROUTING		X	X

Shorewall doesn't create rules in all of the builtin chains. In the large diagram below are boxes such as shown below. This box represents in INPUT chain and shows that packets first flow through the INPUT chain in the Mangle table followed by the INPUT chain in the Filter table. The parentheses around "Mangle" indicate that while the packets will flow through the INPUT chain in the Mangle table, Shorewall does not create any rules in that chain.

Here is a picture of how packets traverse the various chains and tables in Netfilter. In that diagram, "Local Process" refers to a process running on the Firewall itself (in the 'fw' zone).

In the text that follows, the paragraph numbers correspond to the box number in the diagram above.

Packets entering the firewall first pass through the mangle table's PREROUTING chain (you can see the mangle table by typing "shorewall show mangle"). If the packet entered through an interface that has the norfc1918 option, then the packet is sent down the man1918 chain which will drop the packet if its destination IP address is reserved (as specified in the /etc/shorewall/rfc1918 file). Next the packet passes through the pretos chain to set its TOS field as specified in the /etc/shorewall/tos file. Finally, if traffic control/shaping is being used, the packet is sent through the tcpre chain to be marked for later use in policy routing or traffic control.

Next, if the packet isn't part of an established connection, it passes through the nat table's PREROUTING chain (you can see the nat table by typing "shorewall show nat"). If you are doing both static nat and port forwarding, the order in which chains are traversed is dependent on the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on then packets will ender a chain called interface_in where interface is the name of the interface on which the packet entered. Here it's destination IP is compared to each of the EXTERNAL IP addresses from /etc/shorewall/nat that correspond to this interface; if there is a match, DNAT is applied and the packet header is modified to the IP in the INTERNAL column of the nat file record. If the destination address doesn't match any of the rules in the interface_in chain then the packet enters a chain called sourcezone_dnat where sourcezone is the source zone of the packet. There it is compared for a match against each of the DNAT records in the rules file that specify sourcezone as the source zone. If a match is found, the destination IP address (and possibly the destination port) is modified based on the rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of the interface_in and sourcezone_dnat is reversed.
Depending on whether the packet is destined for the firewall itself or for another system, it follows either the left or the right path. Traffic going to the firewall goes through chains called INPUT in the mangle table. Shorewall doesn't add any rules to that chain. Traffic next passes the the INPUT chain in the filter table where it is broken out based on the interface on which the packet arrived; packets from interface interface are routed to chain interface_in. For example, packets arriving through eth0 are passed to the chain eth0_in.

The first rule in interface_in jumps to the chain named dynamic which matches the source IP in the packet against all of the addresses that have been blacklisted using dynamic blacklisting.
If the the interface has the norfc1918 option then the packet is sent down the rfc1918 which checks the source address against those listed in /etc/shorewall/rfc1918 and treats the packet according to the first match in that file (if any).
If the interface has the dhcp option, UDP packets to ports 67 and 68 are accepted.

Traffic is next sent to an input chain in the mail Netfilter table (called 'filter'). If the traffic is destined for the firewall itself, the name of the input chain is formed by appending "_in" to the interface name. So traffic on eth0 destined for the firewall will enter a chain called eth0_in. The input chain for traffic that will be routed to another system is formed by appending "_fwd" to the interface name. So traffic from eth1 that is going to be forwarded enters a chain called eth1_fwd. Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces, share input chains. if ppp+ appears in /etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will share the input chains ppp_in and ppp_fwd. In other words, "+" is deleted from the name before forming the input chain names.

While the use of input chains may seem wasteful in simple environments, in complex setups it substantially reduces the number of rules that each packet must traverse.

Traffic directed from a zone to the firewall itself is sent through a chain named <zone name>2fw. For example, traffic inbound from the internet and addressed to the firewall is sent through a chain named net2fw. Similarly, traffic originating in the firewall and being sent to a host in a given zone is sent through a chain named fw2<zone name>. For example, traffic originating in the firewall and destined for a host in the local network is sent through a chain named fw2loc.

Traffic being forwarded between two zones (or from one interface to a zone to another interface to that zone) is sent through a chain named <source zone>2 <destination zone>. So for example, traffic originating in a local system and destined for a remote web server is sent through chain loc2net. This chain is referred to as the canonical chain from <source zone> to <destination zone>. Any destination NAT will have occurred before the packet traverses one of these chains so rules in /etc/shorewall/rules should be expressed in terms of the destination system's real IP address as opposed to its apparent external address. Similarly, source NAT will occur after the packet has traversed the appropriate forwarding chain so the rules again will be expressed using the source system's real IP address.

For each record in the /etc/shorewall/policy file, a chain is created. Policies in that file are expressed in terms of a source zone and destination zone where these zones may be a zone defined in /etc/shorewall/zones, "fw" or "all". Policies specifying the pseudo-zone "all" matches all defined zones and "fw". These chains are referred to as Policy Chains. Notice that for an ordered pair of zones (za,zb), the canonical chain (za2zb) may also be the policy chain for the pair or the policy chain may be a different chain (za2all, for example). Packets from one zone to another will traverse chains as follows:

If the canonical chain exists, packets first traverse that chain.
If the canonical chain and policy chain are different and the packet does not match a rule in the canonical chain, it then is sent to the policy chain.
If the canonical chain does not exist, packets are sent immediately to the policy chain.

The canonical chain from zone za to zone zb will be created only if there are exception rules defined in /etc/shorewall/rules for packets going from za to zb.

Shorewall is built on top of the Netfilter kernel facility. Netfilter implements connection tracking function that allow what is often referred to as "statefull inspection" of packets. This statefull property allows firewall rules to be defined in terms of "connections" rather than in terms of "packets". With Shorewall, you:

Identify the client's zone.
Identify the server's zone.
If the POLICY from the client's zone to the server's zone is what you want for this client/server pair, you need do nothing further.
If the POLICY is not what you want, then you must add a rule. That rule is expressed in terms of the client's zone and the server's zone.

Just because connections of a particular type are allowed between zone A and the firewall and are also allowed between the firewall and zone B DOES NOT mean that these connections are allowed between zone A and zone B. It rather means that you can have a proxy running on the firewall that accepts a connection from zone A and then establishes its own separate connection from the firewall to zone B.

If you adopt the default policy of ACCEPT from the local zone to the internet zone and you are having problems connecting from a local client to an internet server, adding a rule won't help (see point 3 above).

Last modified 5/22/2003 - Tom Eastep