Tom Eastep 2005-10-01 2004 2005 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

This article will try to help you understand how packets pass through a firewall configured by Shorewall. You may find it useful to have a copy of the Netfilter Overview handy to refer to. The discussion that follows assumes that you are running a current kernel (2.4.2n or 2.6.m) with the recommended options included. Otherwise processing may be somewhat different from described below depending on the features supported by your kernel. Where a packet is covered by steps in more than one of the following sections, processing occurs in the order in which the sections appear.

Certain processing occurs on packets entering the firewall from the outside that don't occur for packets that originate on the firewall itself. The TOS field in the packet is conditionally altered based on the contents of your /etc/shorewall/tos file. This occurs in the pretos chain of the mangle table. Packets are marked based on the contents of your /etc/shorewall/tcrules file and the setting of MARK_IN_FORWARD_CHAIN in /etc/shorewall/shorewall.conf. This occurs in the tcpre chain of the mangle table. The destination IP address and/or port number are rewritten according to DNAT[-] and REDIRECT[-] rules in /etc/shorewall/rules. For new connection requests, this occurs in a chain in the nat table called zone_dnat where zone is the zone where the request originated. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a netfilter rule. If the destination was not rewritten in the previous step then it may be rewritten based on entries in /etc/shorewall/nat. For new connection requests, this occurs in a nat table chain called interface_in where interface is the interface on which the packet entered the firewall. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule. The packet passes through the accounting rules defined in /etc/shorewall/accounting. If Netfilter doesn't know what to do with the packet (connection state INVALID) and the protocol is not ICMP then the packet is silently dropped. The packet is processed according to your Blacklisting configuration (dynamic blacklist first). If BLACKLISTNEWONLY=Yes in /etc/shorewall/shorewall.conf then only new connection requests are processed. Processing occurs in the dynamic and blacklst If the interface on which the packet entered the firewall has the nosmurfs option specified in /etc/shorewall/interfaces, then if the packet is a new connection request is checked for being a smurf in the filter table's smurfs chain. If: the packet will be processed by the firewall itself the interface on which the packet arrived has the dhcp option in /etc/shorewall/interfaces. packet's protocol is UDP with destination port 67 or 68. then the packet is ACCEPTed in the filter table's interface_in chain (for example, eth0_in). If the interface on which the packet entered the firewall has the norfc1918 option specified in /etc/shorewall/interfaces, then the packet is processed against your rfc1918 file (normally /usr/share/shorewall/rfc1918 but that file may be copied to /etc/shorewall/rfc1918 and modified). This happens in the filter table's norfc1918 chain. If the interface on which the packet entered the firewall has the nobogons option specified in /etc/shorewall/interfaces, then the packet is processed against your bogons file (normally /usr/share/shorewall/bogons but that file may be copied to /etc/shorewall/bogons and modified). If the interface on which the packet entered the firewall has the tcpflags option specified in /etc/shorewall/interfaces and the packet's protocol is TCP then the TCP flags are checked by the tcpflags chain (filter table).

Regardless of whether the packet originated on the firewall or came from outside, certain processing steps are common. Packets are marked based on the contents of your /etc/shorewall/tcrules file and the setting of MARK_IN_FORWARD_CHAIN in /etc/shorewall/shorewall.conf. This occurs in the tcfor chain of the mangle table. The remaining processing in this list occurs in the filter table. If either the host sending the packet or the host to which the packet is addressed is not in any defined zone then the all->all policy is applied to the packet (including logging). This can occur in the INPUT, FORWARD or OUTPUT chains. If the packet is part of an established connection or is part of a related connection then no further processing takes place in the filter table (zone12zone2 chain where zone1 is the source zone and zone2 is the destination zone). The packet is processed according to your /etc/shorewall/rules file. This happens in chains named zone12zone2 chain where zone1 is the source zone and zone2 is the destination zone. Note that in the presence of nested or overlapping zones and CONTINUE policies, a packet may go through more than one of these chains. Note: If the packet gets to this step, it did not match any rule. If the applicable policy has a common action then that action is applied (chain has the same name as the action). If the applicable policy has logging specified, the packet is logged. The policy is applied (the packet is accepted, dropped or rejected).

Packets that originate on the firewall itself undergo additional processing. The TOS field in the packet is conditionally altered based on the contents of your /etc/shorewall/tos file. This occurs in the outtos chain of the mangle table. Packets are marked based on the contents of your /etc/shorewall/tcrules file. This occurs in the tcout chain of the mangle table.

Packets being sent to another host undergo additional processing. The source IP address only gets rewritten by the first matching rule below. The source IP address may be rewritten according to DNAT rules that specify SNAT. If this is a new connection request, then the rewriting occurs in a nat table chain called zone_snat where zone is the destination zone. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule. The source IP address may be rewritten according to an entry in the /etc/shorewall/nat file. If this is a new connection request, then the rewriting occurs in a nat table chain called interface_snat where interface is the interface on which the packet will be sent. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule. The source IP address may be rewritten according to an entry in the /etc/shorewall/masq file. If this is a new connection request, then the rewriting occurs in a nat table chain called interface_masq where interface is the interface on which the packet will be sent. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.