Answer: Check out the QuickStart Guides.

Answer: When first installing Shorewall 4.4.0 or later, you must install the shorewall package. If you want to configure an IPv6 firewall, you must also install shorewall6. Beginning with Shorewall 4.5, you must first install the shorewall-core package.

Answer:

If you install using the .deb, you will find that your /etc/shorewall directory is almost empty. This is intentional. The released configuration file skeletons may be found on your system in the directory /usr/share/doc/shorewall-common/default-config. Simply copy the files you need from that directory to /etc/shorewall and modify the copies.

Answer:In Shorewall 4.4, the shorewall-shell package was discontinued. The shorewall-common and shorewall-perl packages were combined to form a single shorewall package. In Shorewall 4.5, the shorewall-core package was added and all of the other packages depend on shorewall-core.

Answer: This happens when:

When AUTOMAKE=Yes, the compiler looks for files in each directory in CONFIG_PATH for files that are newer that the last-generated firewall script. If none are found, the old script is used as is. Prior to version 5.1.10.2, that search was recursive so changes in sub-directories of /etc/shorewall[6] were automatically searched. This had performance implications if directories on the CONFIG_PATH were deeply nested. So, beginning with version 5.1.10.2, only the directories themselves are searched. You can restore the pre-5.1.10.2 behavior by setting AUTOMAKE=recursive, or AUTOMAKE=integer, where integer specifies the search depth. If your included files are in a separate directory, then that directory must be added to CONFIG_PATH in order to allow AUTOMAKE to work correctly.

Answer: Please see the upgrade issues.

Answer:In Shorewall 4.4, the shorewall-shell package was discontinued. The shorewall-common and shorewall-perl packages were combined to form a single shorewall package. For further information, please see the upgrade issues..

Answer: Please see the upgrade issues.

Answer: Please see the upgrade issues.

Answer: This happens to people who ignore our advice and allow the installer to replace their working /etc/shorewall/shorewall.conf with one that has default settings. Failure to forward traffic (such as during masqueraded net access from a local network) usually means that /etc/shorewall/shorewall.conf contains the default setting IP_FORWARDING=Keep; it should be IP_FORWARDING=On.

Update: Beginning with Shorewall 4.4.21, there is a shorewall update command that does a smart merge of your existing shorewall.conf and the new one.

Answer: See FAQ 1.5.

Answer: The format of a port-forwarding rule from the net to a local system is as follows:

#ACTION    SOURCE      DEST                                   PROTO        DPORT
DNAT       net         loc:local-IP-address[:local-port]      protocol     port-number

So to forward UDP port 7777 to internal system 192.168.1.5, the rule is:

#ACTION    SOURCE   DEST             PROTO    DPORT
DNAT       net      loc:192.168.1.5  udp      7777

If you want to forward requests directed to a particular address ( external-IP ) on your firewall to an internal system:

#ACTION SOURCE DEST                                   PROTO       DPORT         SPORT   ORIGDEST
DNAT    net    loc:local-IP-address>[:local-port]     protocol    port-number   -       external-IP

If you want to forward requests from a particular Internet address ( address ):

#ACTION SOURCE        DEST                                   PROTO       DPORT         SPORT   ORIGDEST
DNAT    net:address   loc:local-IP-address[:local-port]      protocol    port-number   -

Finally, if you need to forward a range of ports, in the DEST PORT column specify the range as low-port:high-port.

#ACTION    SOURCE   DEST                PROTO    DPORT
DNAT       net      loc:192.168.1.3:22  tcp      1022

#ACTION SOURCE  DEST                    PROTO   DPORT
DNAT    net     fw:192.168.1.1:22       tcp     4104

#INTERFACE              SOURCE             ADDRESS         PROTO   PORT
eth1:192.168.1.4        0.0.0.0/0          192.168.1.1     tcp     21

#ACTION                 SOURCE              DEST              PROTO  PORT
SNAT(192.168.1.1)       0.0.0.0/0           eth1:192.168.1.4  tcp    21

#ACTION    SOURCE        DEST                   PROTO    DPORT   SPORT   ORIGDEST

?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

DNAT       net           net:66.249.93.111:993  tcp      80      -       206.124.146.176

?FORMAT 2
#ZONE		INTERFACE		OPTIONS
net             eth0                    routeback

#INTERFACE              SOURCE          ADDRESS         PROTO   PORT
eth0:66.249.93.111      0.0.0.0/0       206.124.146.176 tcp     993

#ACTION                 SOURCE          DEST                PROTO   PORT
SNAT(206.124.146.176)   0.0.0.0/0       eth0:66.249.93.111  tcp     993

IP_FORWARDING=On

#ACTION         SOURCE          DEST            PROTO   DPORT
REDIRECT        net             22              tcp     9022

RULE:
DNAT           scnet:172.19.41.2       dmz0:10.199.198.145             udp     2055

LOG:
Sep 21 12:55:37 fw001 kernel: [10357687.114928] Shorewall:scnet2fw:DROP:IN=eth2 OUT=
MAC=00:26:33:dd:aa:05:00:24:f7:19:ce:44:08:00 SRC=172.19.41.2 DST=172.19.1.1 LEN=1492
TOS=0x00 PREC=0x00 TTL=63 ID=23035 PROTO=UDP SPT=6376 DPT=2055 LEN=1472

conntrack -D -s 172.19.41.2 -d 172.19.1.1 -p udp -sport 6367 -dport 2055 

Answer: It would be a good idea to review the QuickStart Guide appropriate for your setup; the guides cover this topic in a tutorial fashion. DNAT rules should be used for connections that need to go the opposite direction from SNAT/MASQUERADE. So if you masquerade or use SNAT from your local network to the Internet then you will need to use DNAT rules to allow connections from the Internet to your local network.

You also want to use DNAT rules when you intentionally want to rewrite the destination IP address or port number. In all other cases, you use ACCEPT unless you need to hijack connections as they go through your firewall and handle them on the firewall box itself; in that case, you use a REDIRECT rule.

Answer: Specify the external address that you want to redirect in the ORIGDEST column.

Example:

#ACTION         SOURCE          DEST                    PROTO   DPORT   SPORT   ORIGDEST
DNAT            net             net:192.168.4.22        tcp     80,443  -       206.124.146.178

Answer: Ian Allen has written a Paper about DNAT and Linux.

Answer: See Shorewall_Squid_Usage.html.

Answer: I have two objections to this setup.

So the best and most secure way to solve this problem is to move your Internet-accessible server(s) to a separate LAN segment with it's own interface to your firewall and follow FAQ 2b. That way, your local systems are still safe if your server gets hacked and you don't have to run a split DNS configuration (separate server or Bind 9 views).

If physical limitations make it impractical to segregate your servers on a separate LAN, the next best solution it to use Split DNS. Before you complain "It's too hard to set up split DNS!", check here.

If you really want to route traffic between two internal systems through your firewall, then proceed as described below.

Assuming that your external interface is eth0 and your internal interface is eth1 and that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, then:

Oct 4 10:26:40 netgw kernel:
          Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
          DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
          PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0

?FORMAT 2
#ZONE           INTERFACE               OPTIONS
dmz             eth2                    routeback 

#INTERFACE              SOURCE
eth2:192.168.1.2        192.168.2.0/24

#ACTION        SOURCE          DEST                PROTO   PORT
MASQUERADE     192.168.1.0/24  eth2:192.168.1.2    tcp     www

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT   ORIGDEST

?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

DNAT            loc             dmz:192.168.2.4 tcp     80      -       206.124.146.176

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT   ORIGDEST

?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

DNAT            loc             dmz:192.168.2.4 tcp     80      -       &eth0

Answer: Nothing.

Blacklisting an IP address blocks incoming traffic from that IP address. And if you set BLACKLISTNEWONLY=Yes in shorewall.conf, then only new connections from that address are disallowed; traffic from that address that is part of an established connection (such as ping replies) is allowed.

Answer: You probably forgot to specify the blacklist option for your external interface(s) in /etc/shorewall/interfaces.

Answer: There is an H.323 connection tracking/NAT module that helps with Netmeeting.

Look here for a solution for MSN IM but be aware that there are significant security risks involved with this solution. Also check the Netfilter mailing list archives at http://www.netfilter.org.

Answer: The problem here is that a bare iptables -L command produces totally useless output. Use shorewall show instead.

Answer: No one who has installed Shorewall using one of the Quick Start Guides should have to ask this question.

Regardless of which guide you used, all outbound communication is open by default. So you do not need to 'open ports' for output.

For input:

Also please see the Port Forwarding section of this FAQ.

Answer: The default Shorewall setup invokes the Drop action prior to enforcing a DROP policy and the default policy to all zones from the Internet is DROP. The Drop action is defined in /usr/share/shorewall/action.Drop which in turn invokes the Auth macro (defined in /usr/share/shorewall/macro.Auth) specifying the REJECT action (i.e., Auth(REJECT)). This is necessary to prevent outgoing connection problems to services that use the “Auth” mechanism for identifying requesting users. That is the only service which the default setup rejects.

If you are seeing closed TCP ports other than 113 (auth) then either you have added rules to REJECT those ports or a router outside of your firewall is responding to connection requests on those ports.

If you would prefer to 'stealth' port 113, then:

Please see FAQ 17.

Answer: For a complete description of Shorewall “ping” management, see this page.

Answer: Every time I read “systems can't see out to the net”, I wonder where the poster bought computers with eyes and what those computers will “see” when things are working properly :-). That aside, the most common causes of this problem are:

Answer: See the Shorewall and FTP page.

Answer: Most likely, you need to set CLAMPMSS=Yes in /etc/shorewall/shorewall.conf.

Answer: Add the routeback option to br0 in /etc/shorewall/interfaces.

For more information on this type of configuration, see the Shorewall Simple Bridge documentation.

Answer: In kernel 2.6.20, the Netfilter physdev match feature was changed such that it is no longer capable of matching the output device of non-bridged traffic. You will see messages such as the following in your log:

Apr 20 15:03:50 wookie kernel: [14736.560947] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for
                                                             non-bridged traffic is not supported anymore.

This kernel change, while necessary, means that Shorewall zones may no longer be defined in terms of bridge ports. See the Shorewall-perl bridging documentation for information about how to configure bridge/firewalls.

I'm seeing this in my log:

Aug 31 16:51:24 fw22 kernel: Shorewall:net2fw:DROP:IN=eth5 OUT= MAC=00:0c:29:74:9c:0c:08:00:20:b2:5f:db:08:00
                                       SRC=10.1.50.14 DST=10.1.50.7 LEN=57 TOS=0x00 PREC=0x00 TTL=255 ID=32302 DF
                                       PROTO=UDP SPT=53289 DPT=53 LEN=37

Answer: This occurs when the external interface and an internal interface are connected to the same switch or hub. See this article for details. The solution is to never connect more than one firewall interface to the same hub or switch (an obvious exception is that when you have a switch that supports VLAN tagging and the interfaces are associated with different VLANs).

Answer: No, that is not correct. The LOGFILE setting tells Shorewall where to find the log; it does not determine where messages are written. See the next FAQ.

Answer: NetFilter uses the kernel's equivalent of syslog (see “man syslog”) to log messages. It always uses the LOG_KERN (kern) facility (see “man openlog”) and you get to choose the log level (again, see “man syslog”) in your policies and rules. The destination for messages logged by syslog is controlled by /etc/syslog.conf (see “man syslog.conf”). When you have changed /etc/syslog.conf, be sure to restart syslogd (on a RedHat system, “service syslog restart”).

It is also possible to set up Shorewall to log all of Netfilter's messages to a separate file.

#ACTION         SOURCE          DEST            PROTO   DPORT

?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

DROP            net             $FW             udp     10619

#ACTION         SOURCE          DEST            PROTO   DPORT

DROP            net             $FW             udp     10619

MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00

Answer:

Just to be clear, it is not Shorewall that is writing all over your console. Shorewall issues a single log message during each start, restart, stop, etc. It is rather your logging daemon that is writing messages to your console. Shorewall itself has no control over where a particular class of messages are written. See the Shorewall logging documentation.

The max log level to be sent to the console is available in /proc/sys/kernel/printk:

teastep@ursa:~$ cat /proc/sys/kernel/printk
6      6       1       7
teastep@ursa:~$ 

The first number determines the maximum log level (syslog priority) sent to the console. Messages with priority less than this number are sent to the console. On the system shown in the example above, priorities 0-5 are sent to the console. Since Shorewall defaults to using 'info' (6), the Shorewall-generated Netfilter rule set will generate log messages that will not appear on the console.

The second number is the default log level for kernel printk() calls that do not specify a log level.

The third number specifies the minimum console log level while the fourth gives the default console log level.

If, on your system, the first number is 7 or greater, then the default Shorewall configurations will cause messages to be written to your console. The simplest solution is to add this to your /etc/sysctl.conf file:

kernel.printk = 4 4 1 7

then

sysctl -p /etc/sysctl.conf

Answer: Logging of dropped/rejected packets occurs out of a number of chains (as indicated in the log message) in Shorewall:

Jun 27 15:37:56 gateway kernel:
        Shorewall:all2all:REJECT:IN=eth2
          OUT=eth1
          SRC=192.168.2.2
          DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
        SPT=1803 DPT=53 LEN=47

ACCEPT dmz loc udp 53

Nov 25 18:58:52 linux kernel:
      Shorewall:net2all:DROP:IN=eth1 OUT=
      MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
      DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
      TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
      TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]

192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal LAN

Answer: First of all, please note that the above is a very specific type of log message dealing with ICMP port unreachable packets (PROTO=ICMP TYPE=3 CODE=3). Do not read this answer and assume that all Shorewall log messages have something to do with ICMP (hint -- see FAQ 17).

While most people associate the Internet Control Message Protocol (ICMP) with “ping”, ICMP is a key piece of IP. ICMP is used to report problems back to the sender of a packet; this is what is happening here. Unfortunately, where NAT is involved (including SNAT, DNAT and Masquerade), there are many broken implementations. That is what you are seeing with these messages. When Netfilter displays these messages, the part before the "[" describes the ICMP packet and the part between the "[" and "]" describes the packet for which the ICMP is a response.

Here is my interpretation of what is happening -- to confirm this analysis, one would have to have packet sniffers placed a both ends of the connection.

Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS query to 192.0.2.3 and your DNS server tried to send a response (the response information is in the brackets -- note source port 53 which marks this as a DNS reply). When the response was returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and forwarded the packet to 172.16.1.10 who no longer had a connection on UDP port 2857. This causes a port unreachable (type 3, code 3) to be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179, that box correctly changes the source address in the packet to 206.124.146.179 but doesn't reset the DST IP in the original DNS response similarly. When the ICMP reaches your firewall (192.0.2.3), your firewall has no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be related to anything that was sent. The final result is that the packet gets logged and dropped in the all2all chain.

I blacklisted the address 130.252.100.59 using shorewall drop 130.252.100.59 but I am still seeing these log messages:

Jan 30 15:38:34 server Shorewall:net_dnat:REDIRECT:IN=eth1 OUT= MAC=00:4f:4e:14:97:8e:00:01:5c:23:24:cc:08:00
                       SRC=130.252.100.59 DST=206.124.146.176 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=42444 DF
                       PROTO=TCP SPT=2215 DPT=139 WINDOW=53760 RES=0x00 SYN URGP=0

Answer: Please refer to the Shorewall Netfilter Documentation. Logging of REDIRECT and DNAT rules occurs in the nat table's PREROUTING chain where the original destination IP address is still available. Blacklisting occurs out of the filter table's INPUT and FORWARD chains which aren't traversed until later.

I love the ability to type 'shorewall logdrop ww.xx.yy.zz' and completely block a particular IP address. However, the log part doesn't happen. When I look in the logdrop chain, there is no LOG prefix.

Answer: You haven't set a value for BLACKLIST_LOGLEVEL in shorewall.conf (5).

Dec 15 16:47:30 heath-desktop kernel: [17182740.184000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00
                                                        SRC=10.119.248.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64
                                                        ID=62081 PROTO=UDP SPT=67 DPT=68 LEN=308
Dec 15 16:47:30 heath-desktop last message repeated 2 times
Dec 15 16:47:30 heath-desktop kernel: [17182740.188000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00
                                                        SRC=10.112.70.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64
                                                        ID=62082 PROTO=UDP SPT=67 DPT=68 LEN=308
Dec 15 16:47:30 heath-desktop last message repeated 2 times

Answer: The Webmin 'bandwidth' module adds commands to /etc/shorewall/start that creates rules to log every packet to/from/through the firewall. DON'T START THE BANDWIDTH SERVICE IN WEBMIN!

To correct this situation once it occurs, edit /etc/shorewall/start and insert 'return 0' prior to the BANDWIDTH rules.

Answer: See this article about Shorewall and Multiple ISPs.

Answer: This is usually the consequence of a one-to-one nat configuration blunder:

This combination causes Shorewall to delete the primary IP address from the network interface specified in the INTERFACE column which usually causes all routes out of that interface to be deleted. The solution is to not specify the primary IP address of an interface in the EXTERNAL column.

Answer: Shorewall is not a daemon. It is a configuration tool that configures your kernel based on the contents of /etc/shorewall/. Once the start command completes, Shorewall has done its job and there are no Shorewall processes remaining in the system.

Answer: The stop command places the firewall in a safe state; connections that are allowed are governed by the setting of ADMINISABSENTMINDED in shorewall.conf (5) and the contents of shorewall-stoppedrules (5). To totally open the firewall, use the clear command.

I just installed Shorewall and when I issue the start command, I see the following:

Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
   Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    Local Zone: eth1:0.0.0.0/0
Deleting user chains...
Creating input Chains...
...

Why can't Shorewall detect my interfaces properly?

Answer: The above output is perfectly normal. The Net zone is defined as all hosts that are connected through eth0 and the local zone is defined as all hosts connected through eth1. You can set the routefilter option on an internal interface if you wish to guard against 'Martians' (a Martian is a packet with a source IP address that is not routed out of the interface on which the packet was received). If you do that, it is a good idea to also set the logmartians option.

Answer:You can place these commands in one of the Shorewall Extension Scripts. Be sure that you look at the contents of the chain(s) that you will be modifying with your commands so that the commands will do what is intended. Many iptables commands published in HOWTOs and other instructional material use the -A command which adds the rules to the end of the chain. Most chains that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT rule and any rules that you add after that will be ignored. Check “man iptables” and look at the -I (--insert) command.

Answer: When you install using the "rpm -U" command, Shorewall doesn't run your distribution's tool for configuring Shorewall startup. You will need to run that tool (insserv, chkconfig, run-level editor, …) to configure Shorewall to start in the the default run-levels of your firewall system.

Answer: Copy /usr/share/shorewall[-lite]/modules to /etc/shorewall/modules and modify the copy to include only the modules that you need. An alternative is to set LOAD_HELPERS_ONLY=Yes in shorewall.conf (5).

ERROR: Command "/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT" failed.

Answer: See the Shorewall OpenVZ article.

It is important to understand that the scripts in /etc/init.d are generally provided by your distribution and not by the Shorewall developers. These scripts must meet the requirements of the distribution's packaging system which may conflict with the requirements of a tight firewall. So when you say "…when I stop Shorewall…" it is necessary to distinguish between the commands /sbin/shorewall stop and /etc/init.d/shorewall stop.

/sbin/shorewall stop places the firewall in a safe state, the details of which depend on your /etc/shorewall/stoppedrules file (shorewall-stoppedrules(5)) and on the setting of ADMINISABSENTMINDED in /etc/shorewall/shorewall.conf (shorewall.conf(5)).

/etc/init.d/shorewall stop may or may not do the same thing. In the case of Debian™ systems for example, that command actually executes /sbin/shorewall clear which opens the firewall completely. In other words, in the init script, stop reverses the effect of start.

Beginning with Shorewall 4.4, when the Shorewall tarballs are installed on a Debian (or derivative) system, the /etc/init.d/shorewall file is the same as would be installed by the .deb. The behavior of /etc/init.d/shorewall stop is controlled by the setting of SAFESTOP in /etc/default/shorewall. When set to 0 (the default), the firewall is cleared; when set to 1, the firewall is placed in a safe state.

Answer: Set IP_FORWARDING=On in /etc/shorewall/shorewall.conf.

Answer: I faced a similar problem which I solved as follows:

Answer: Shorewall uses the presence of a chain named shorewall to indicate whether is started or stopped. That chain is created during execution of a successful start, restart or restore command and is removed during stop and clear. If shorewall status indicates that Shorewall is stopped, then something has deleted that chain. Look at the output of shorewall status; if it looks like this:

then it means that something outside of Shorewall has deleted the chain. This usually means that you were running another firewall package before you installed Shorewall and that other package has replaced Shorewall's Netfilter configuration with its own. You must remove (or at least disable) the other firewall package and restart Shorewall.

then a shorewall stop command has been executed (if the State shown in the output is Cleared, then a shorewall clear command was executed). Most likely, you have installed and configured the shorewall-init package and a required interface has gone down.

Answer: This is caused by your failure to disable your distributions default iptables configuration tool when you installed Shorewall. Look for a service called 'iptables' that is being started after Shorewall and disable it.

Answer: There are several steps that you can take:

Answer: This is usually associated with SELinux. Here is an example.

Example:

> Oct 1 13:04:39 deb kernel: [ 9570.619744] xt_addrtype: ipv6 does not support BROADCAST matching

Answer: These are harmless. Shorewall attempts to execute various commands to determine the capabiities of your system. If you system doesn't support a command, it will generally issue a kernel log message.

Answer: To enable start at boot, run systemctl enable shorewall.service

Answer: The Multi-ISP Documentation strongly recommends that you use the balance option on all providers even if you want to manually specify which ISP to use. If you don't do that so that your main routing table only has one default route, then you must disable route filtering. Do not specify the routefilter option on the other interface(s) in /etc/shorewall/interfaces and disable any IP Address Spoofing protection that your distribution supplies.

Answer: Suppose that you want all traffic to go out through ISP1 (mark 1) unless you specify otherwise. Then simply add these two rules as the first marking rules in your /etc/shorewall/mangle (was tcrules) file:

#ACTION         SOURCE          DEST
MARK(1):P       0.0.0.0/0
MARK(1)         $FW
other MARK rules

Now any traffic that isn't marked by one of your other MARK rules will have mark = 1 and will be sent via ISP1. That will work whether balance is specified or not!

Answer: Yes, but we advise strongly against it.

The error I receive is as follows:

RTNETLINK answers: No such file or directory
We have an error talking to the kernel
    ERROR: Command "tc filter add dev eth2 parent ffff: protocol ip prio 
                    50 u32 match ip src 0.0.0.0/0 police rate 500kbit burst 10k drop flowid 
                    :1" Failed

Answer: This message indicates that your kernel doesn't have 'traffic policing' support. If your kernel is modularized, you may be able to resolve the problem by loading the act_police kernel module. Other kernel modules that you will need include:

Answer: This is likely due to TCP Segmentation Offload (TSO) and/or Generic Segmentation Offload (GSO) being enabled in the network adapter. To verify, install the ethtool package and use the -k command:

root@gateway:~# ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
root@gateway:~#

If that is the case, you can correct the problem by adjusting the minburst setting in /etc/shorewall/tcinterfaces (simple traffic shaping) or /etc/shorewall/tcdevices (complex traffic shaping). We suggest starting at 10-12kb and adjust as necessary. Example (simple traffic shaping):

#INTERFACE      TYPE            IN_BANDWIDTH            OUT_BANDWIDTH
eth0            External        50mbit:200kb            5.0mbit:100kb:200ms:100mbit:10kb

Alternatively, you can turn off TSO and GSO using this command in /etc/shorewall/init:

ethtool -K ethN tso off gso off

Answer: This is likely due to Generic Receive Offload (GRO) being enabled in the network adapter. To verify, install the ethtool package and use the -k command:

root@gateway:/etc/shorewall# ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
root@gateway:/etc/shorewall# 

To work around the issue, use this command:

ethtool -K ethN gro off

Beginning with Shorewall 4.4.25, another option is available in the form of a rate-estimated policing filter.

Example from /etc/shorewall/tcdevices:

#INTERFACE      IN_BANDWITH             OUT_BANDWIDTH   OPTIONS
1:COMB_IF       ~20mbit:250ms:4sec      ${UPLOAD}kbit   hfsc,linklayer=ethernet,overhead=0

To create a rate-estimated filter, precede the bandwidth with a tilde ("~"). The optional interval and decay_interval determine how often the rate is estimated and how many samples are retained for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for details.

Answer: Shorewall works with any GNU/Linux distribution that includes the proper prerequisites.

Answer: See the Shorewall Feature List.

Answer: Yes! Shorewall support is available in Webmin. See http://www.webmin.com. But beware of the issue described in FAQ 36.

Answer: Shorewall is a concatenation of “ Shoreline” (the city where I live) and “Firewall ”. The full name of the product is actually “Shoreline Firewall” but “Shorewall” is much more commonly used.

Answer: The Shorewall web site is almost font neutral (it doesn't explicitly specify fonts except on a few pages) so the fonts you see are largely the default fonts configured in your browser. If you don't like them then reconfigure your browser.

Answer: At the shell prompt, type:

/sbin/shorewall[-lite] version -a     

Answer: This article by Paul Gear should help you get started.

Answer: Yes. See Shorewall and Aliased Interfaces.

Answer: Beginning with Shorewall 4.4.11 Beta 2, you can create vserver zones that are nested within the firewall zone.

Prior to 4.4.11 Beta 2, there is no way to create sub-zones of the firewall zone. But you can use shell variables to make vservers easier to deal with.

/etc/shorewall/params:

VS1=fw:192.168.2.12
VS2=fw:192.168.2.13
VS3=fw:192.168.2.14

/etc/shorewall/rules:

#ACTION         SOURCE          DEST            PROTO   DPORT

?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

ACCEPT          $VS1            net             tcp     25
DNAT            net             $VS1            tcp     25
etc...

Answer: Shorewall Lite is a companion product to Shorewall and is designed to allow you to maintain all Shorewall configuration information on a single system within your network. See the Compiled Firewall script documentation for details.

Answer: No. In fact, we recommend that you do NOT install Shorewall on systems where you wish to use Shorewall Lite. You must have Shorewall installed on at least one system within your network in order to use Shorewall Lite.

Answer: If you plan to have only a single firewall system, then Shorewall is the logical choice. I also think that Shorewall is the appropriate choice for laptop systems that may need to have their firewall configuration changed while on the road. In the remaining cases, Shorewall Lite will work very well. At shorewall.net, the two laptop systems have the full Shorewall product installed as does my personal Linux desktop system. All other Linux systems that run a firewall use Shorewall Lite and have their configuration directories on my desktop system.

Answer: There are no compatibility constraints between Shorewall and Shorewall-lite.

Somehow, my firewall config is causing a one-way audio problem in Asterisk. If a person calls into the PBX, they cannot hear me speaking, but I can hear them. If I plug the Asterisk server directly into the router, bypassing the firewall, the problem goes away.

Answer: There are two things to try when VOIP problems are encountered. Both begin with executing two rmmod commands.

If your kernel version is 2.6.20 or earlier:

rmmod ip_nat_sip
rmmod ip_conntrack_sip

If your kernel version is 2.6.21 or later:

rmmod nf_nat_sip
rmmod nf_conntrack_sip

The first alternative seems to work for those running recent kernels (2.6.26 or later):

The second alternative is to not load the sip helpers:

Answer: Shorewall IPv6 support is currently available in Shorewall 4.2.4 and later.

kernel=$(printf "%2d%02d%02d\n" $(echo $(uname -r) 2> /dev/null | sed 's/-.*//' | tr '.' ' ' ) | head -n1)
if [ $kernel -lt 20624 ]; then
    error_message "ERROR: $PRODUCT requires Linux kernel 2.6.24 or later"
    status=2
else 
 

Answer: You have configured forwarding on the interface which disables autoconfiguration of the interface. To retain autoconfiguration on the interface when Shorewall6 starts, specify forwarding=0 in the OPTIONS column on the interface's entry in shorewall6-interfaces (5).

Answer: This is a two-step process.

You will probably want to soon install Shorewall6 so that you have an IPv6 firewall as well as one for IPv4.

Answer: Yes, with a couple of restrictions:

Answer: Yes. Consult the QuickStart guide that you used during your initial setup for information about how to set up rules for your server.

Answer: In the SOURCE column of the rule, follow “net” by a colon and a list of the host/subnet addresses as a comma-separated list.

net:<ip1>,<ip2>,...

ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22

Answer: Temporarily remove any rejNotSyn, dropNotSyn, dropInvalid, NotSyn(...) and Invalid(...) rules from /etc/shorewall/rules and restart Shorewall.

Answer: First take a look at the Shorewall kernel configuration page. You probably also want to be sure that you have selected the “ NAT of local connections (READ HELP) ” on the Netfilter Configuration menu. Otherwise, DNAT rules with your firewall as the source zone won't work with your new kernel.

Answer: Shorewall Bridging Firewall support is available — check here for details.

I tried this rule to block Google's Adsense that you'll find on everyone's site. Adsense is a Javascript that people add to their Web pages. So I entered the rule:

#ACTION         SOURCE  DEST                                    PROTO
REJECT          fw      net:pagead2.googlesyndication.com       all

However, this also sometimes restricts access to "google.com". Why is that? Using dig, I found these IPs for domain googlesyndication.com:

216.239.37.99
216.239.39.99

And this for google.com:

216.239.37.99
216.239.39.99
216.239.57.99

So my guess is that you are not actually blocking the domain, but rather the IP being called. So how in the world do you block an actual domain name?

Answer: Packet filters like Netfilter base their decisions on the contents of the various protocol headers at the front of each packet. Stateful packet filters (of which Netfilter is an example) use a combination of header contents and state created when the packet filter processed earlier packets. Netfilter (and Shorewall's use of Netfilter) also consider the network interface(s) where each packet entered and/or where the packet will leave the firewall/router.

When you specify a domain name in a Shorewall rule, the iptables program resolves that name to one or more IP addresses and the actual Netfilter rules that are created are expressed in terms of those IP addresses. So the rule that you entered was equivalent to:

#ACTION         SOURCE          DEST                    PROTO
REJECT          $FW             net:216.239.37.99       all
REJECT          $FW             net:216.239.39.99       all

Given that name-based multiple hosting is a common practice (another example: lists.shorewall.net and www1.shorewall.net are both hosted on the same system with a single IP address), it is not possible to filter connections to a particular name by examination of protocol headers alone. While some protocols such as FTP require the firewall to examine and possibly modify packet payload, parsing the payload of individual packets doesn't always work because the application-level data stream can be split across packets in arbitrary ways. This is one of the weaknesses of the 'string match' Netfilter extension available in later Linux kernel releases. The only sure way to filter on packet content is to proxy the connections in question -- in the case of HTTP, this means running something like Squid. Proxying allows the proxy process to assemble complete application-level messages which can then be accurately parsed and decisions can be made based on the result.

Answer: Use the shorewall[-lite] show capabilities command at a root prompt.

gateway:~# shorewall show capabilities
Shorewall has detected the following iptables/netfilter capabilities:
   NAT: Available
   Packet Mangling: Available
   Multi-port Match: Available
   Extended Multi-port Match: Available
   Connection Tracking Match: Available
   Extended Connection Tracking Match Support: Available
   Old Connection Tracking Match Syntax: Not available
   Packet Type Match: Available
   Policy Match: Available
   Physdev Match: Available
   Physdev-is-bridged Support: Available
   Packet length Match: Available
   IP range Match: Available
   Recent Match: Available
   Owner Match: Available
   Ipset Match: Available
   CONNMARK Target: Available
   Extended CONNMARK Target: Available
   Connmark Match: Available
   Extended Connmark Match: Available
   Raw Table: Available
   IPP2P Match: Available
   Old IPP2P Match Syntax: Not available
   CLASSIFY Target: Available
   Extended REJECT: Available
   Repeat match: Available
   MARK Target: Available
   Extended MARK Target: Available
   Mangle FORWARD Chain: Available
   Comments: Available
   Address Type Match: Available
   TCPMSS Match: Available
   Hashlimit Match: Available
   Old Hashlimit Match: Not available
   NFQUEUE Target: Available
   Realm Match: Available
   Helper Match: Available
   Connlimit Match: Available
   Time Match: Available
   Goto Support: Available
   LOGMARK Target: Available
   IPMARK Target: Available
   LOG Target: Available
   Persistent SNAT: Available
gateway:~# 

Answer: Add these two policies:

#SOURCE         DEST            POLICY  LOGLEVEL        LIMIT   CONNLIMIT
$FW             loc             ACCEPT
loc             $FW             ACCEPT

You should also delete any ACCEPT rules from $FW->loc and loc->$FW since those rules are redundant with the above policies.

Answer: Yes. In Network Intrusion Detection System (NIDS) mode, Snort is libpcap based (like tcpdump) so it doesn't interfere with Shorewall. We have had reports that users have also been successful in using Snort in inline more with Shorewall, but no HOWTO exists at this time.

Answer: Here's what I did:

If you can't change the IP address of your modem and its current address isn't in your local network, then you need to change this slightly; assuming that the modem IP address is 192.168.1.1:

Answer: If you want to apply firewall rules to the traffic passing between bridge ports, see https://shorewall.org/bridge-Shorewall-perl.html. If you simply want to allow all traffic between ports, then see https://shorewall.org/SimpleBridge.html.

Answer: FW is a shell variable that expands to the name that you gave to the firewall zone in shorewall-zones(5). The default name for the firewall zone is fw:

#ZONE           TYPE            OPTIONS

fw              firewall

So, using the default or sample configurations, writing $FW is the same as writing fw. If you give the firewall zone a different name, gate for example, then writing $FW would be the same as writing gate.

#ZONE           TYPE            OPTIONS

gate            firewall

Answer: There are two ways:

Answer: 'qt' stands for 'quiet'; qt() is a shell function that accepts a command with arguments as parameters. It redirects both standard out and standard error to /dev/null. It is defined in the Shorewall-core shell library lib.common.