Copyright © 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”.
2007/10/16
Table of Contents
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 FASTACCEPT=Yes in shorewall.conf
and the
packet is part of or related to an existing connection, it is
accepted.
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 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.
If FASTACCEPT=Yes in shorewall.conf
and the
packet is part of or related to an existing connection, it is
accepted.
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.