This configuration is used on a corporate network that has a
-Linux (RedHat 8.0) server with three interfaces, running Shorewall 1.4.5
+
This configuration is used on a corporate network that has a
+Linux (RedHat 8.0) server with three interfaces, running Shorewall 1.4.5
release,
-
Make sure you know what public IP addresses are currently being
+
Make sure you know what public IP addresses are currently being
used and verify these before starting.
-
Verify your DNS settings before starting any Shorewall
+
Verify your DNS settings before starting any Shorewall
configuration especially if you have split DNS.
-
System names and Internet IP addresses have been changed to protect
+
System names and Internet IP addresses have been changed to protect
the innocent.
+
-
-
Warning: This
-configuration uses a combination of Static NAT and Proxy ARP. This is
-generally not relevant to a simple configuration with a single public IP
- address. If you have just a single public
-IP address, most of what you see here won't apply to your setup so beware
-of copying parts of this configuration and expecting them to work for
-you. What you copy may or may not work in your configuration.
-
-
-
-
I have a T1 with 64 static IP addresses (192.0.18.65-127/26). The
- internet is connected to eth0. The local network is connected via eth1
- (10.10.0.0/22) and the DMZ is connected to eth2 (192.168.21.0/24). I have
-an IPSec tunnel connecting our offices in Germany to our offices in the
-US. I host two Microsoft Exchange servers for two different companies
-behind the firewall hence, the two Exchange servers in the diagram below.
-
+
+
Warning: This configuration
+uses a combination of Static NAT and Proxy ARP. This is generally not
+relevant to a simple configuration with a single public IP address.
+If you have just a single public IP address, most of what you see here
+won't apply to your setup so beware of copying parts of this configuration
+and expecting them to work for you. What you copy may or may not work
+in your configuration.
+
+
+
+
I have a T1 with 64 static IP addresses (192.0.18.65-127/26). The
+internet is connected to eth0. The local network is connected via eth1
+(10.10.0.0/22) and the DMZ is connected to eth2 (192.168.21.0/24). I have
+an IPSec tunnel connecting our offices in Germany to our offices in the
+US. I host two Microsoft Exchange servers for two different companies behind
+the firewall hence, the two Exchange servers in the diagram below.
+
Summary:
-
-
+
+
-
SNAT for all systems connected to the LAN - Internal addresses 10.10.x.x
- to external address 192.0.18.127.
-
Static NAT for Polaris (Exchange Server #2). Internal address
+
SNAT for all systems connected to the LAN - Internal addresses
+10.10.x.x to external address 192.0.18.127.
+
Static NAT for Polaris (Exchange Server #2). Internal address
10.10.1.8 and external address 192.0.18.70.
-
Static NAT for Sims (Inventory Management server). Internal
+
Static NAT for Sims (Inventory Management server). Internal
address 10.10.1.56 and external address 192.0.18.75.
-
-
Static NAT for Project (Project Web Server). Internal address
+
+
Static NAT for Project (Project Web Server). Internal address
10.10.1.55 and external address 192.0.18.84.
-
Static NAT for Fortress (Exchange Server). Internal address
+
Static NAT for Fortress (Exchange Server). Internal address
10.10.1.252 and external address 192.0.18.93.
-
Static NAT for BBSRV (Blackberry Server). Internal address
+
Static NAT for BBSRV (Blackberry Server). Internal address
10.10.1.230 and external address 192.0.18.97.
-
Static NAT for Intweb (Intranet Web Server). Internal address
+
Static NAT for Intweb (Intranet Web Server). Internal address
10.10.1.60 and external address 192.0.18.115.
+
-
-
The firewall runs on a 2Gb, Dual PIV/2.8GHz, Intel motherboard with
- RH8.0.
-
+
+
The firewall runs on a 2Gb, Dual PIV/2.8GHz, Intel motherboard with
+ RH8.0.
+
The Firewall is also a proxy server running Privoxy 3.0.
-
-
The single system in the DMZ (address 192.0.18.80) runs sendmail, imap,
- pop3, DNS, a Web server (Apache) and an FTP server (vsFTPd 1.1.0). That
+
+
The single system in the DMZ (address 192.0.18.80) runs sendmail, imap,
+ pop3, DNS, a Web server (Apache) and an FTP server (vsFTPd 1.1.0). That
server is managed through Proxy ARP.
-
-
All administration and publishing is done using ssh/scp. I have X installed
- on the firewall and the system in the DMZ. X applications tunnel through
-SSH to Hummingbird Exceed running on a PC located in the LAN. Access to
-the firewall using SSH is restricted to systems in the LAN, DMZ or the
+
+
All administration and publishing is done using ssh/scp. I have X installed
+ on the firewall and the system in the DMZ. X applications tunnel through
+SSH to Hummingbird Exceed running on a PC located in the LAN. Access to
+the firewall using SSH is restricted to systems in the LAN, DMZ or the
system Kaos which is on the Internet and managed by me.
-
+
-
-
+
+
-
-
The Ethernet 0 interface in the Server is configured with IP address
- 192.0.18.68, netmask 255.255.255.192. The server's default gateway is
- 192.0.18.65, the Router connected to my network and the ISP. This is the
- same default gateway used by the firewall itself. On the firewall, Shorewall
- automatically adds a host route to 192.0.18.80 through Ethernet 2 (192.168.21.1)
-because of the entry in /etc/shorewall/proxyarp (see below). I modified
-the start, stop and init scripts to include the fixes suggested when having
+
+
The Ethernet 0 interface in the Server is configured with IP address
+ 192.0.18.68, netmask 255.255.255.192. The server's default gateway is
+ 192.0.18.65, the Router connected to my network and the ISP. This is the
+ same default gateway used by the firewall itself. On the firewall, Shorewall
+ automatically adds a host route to 192.0.18.80 through Ethernet 2 (192.168.21.1)
+because of the entry in /etc/shorewall/proxyarp (see below). I modified
+the start, stop and init scripts to include the fixes suggested when having
an IPSec tunnel.
-
+
Some Mistakes I Made:
-
-
Yes, believe it or not, I made some really basic mistakes when building
- this firewall. Firstly, I had the new firewall setup in parallel with
-the old firewall so that there was no interruption of service to my users.
-During my out-bound testing, I set up systems on the LAN to utilize the
-firewall which worked fine. When testing my NAT connections, from the
-outside, these would fail and I could not understand why. Eventually,
-I changed the default route on the internal system I was trying to access,
-to point to the new firewall and "bingo", everything worked as expected.
-This oversight delayed my deployment by a couple of days not to mention
-level of frustration it produced.
-
-
Another problem that I encountered was in setting up the Proxyarp system
-in the DMZ. Initially I forgot to remove the entry for the eth2 from the
- /etc/shorewall/masq file. Once my file settings were correct, I started
- verifying that the ARP caches on the firewall, as well as the outside
-system "kaos", were showing the correct Ethernet MAC address. However,
-in testing remote access, I could access the system in the DMZ only from
-the firewall and LAN but not from the Internet. The message I received
-was "connection denied" on all protocols. What I did not realize was that
-a "helpful" administrator that had turned on an old system and assigned
-the same address as the one I was using for Proxyarp without notifying
-me. How did I work this out. I shutdown the system in the DMZ, rebooted
-the router and flushed the ARP cache on the firewall and kaos. Then, from
-kaos, I started pinging that IP address and checked the updated ARP cache
-and lo-and-behold a different MAC address showed up. High levels of frustration
-etc., etc. The administrator will not be doing that again! :-)
-
+
+
Yes, believe it or not, I made some really basic mistakes when building
+ this firewall. Firstly, I had the new firewall setup in parallel with the
+old firewall so that there was no interruption of service to my users.
+During my out-bound testing, I set up systems on the LAN to utilize the
+firewall which worked fine. When testing my NAT connections, from the outside,
+these would fail and I could not understand why. Eventually, I changed
+the default route on the internal system I was trying to access, to point
+to the new firewall and "bingo", everything worked as expected. This oversight
+delayed my deployment by a couple of days not to mention level of frustration
+it produced.
+
+
Another problem that I encountered was in setting up the Proxyarp system
+in the DMZ. Initially I forgot to remove the entry for the eth2 from the
+ /etc/shorewall/masq file. Once my file settings were correct, I started
+ verifying that the ARP caches on the firewall, as well as the outside system
+ "kaos", were showing the correct Ethernet MAC address. However, in testing
+ remote access, I could access the system in the DMZ only from the firewall
+and LAN but not from the Internet. The message I received was "connection
+denied" on all protocols. What I did not realize was that a "helpful"
+administrator that had turned on an old system and assigned the same address
+as the one I was using for Proxyarp without notifying me. How did I work
+this out. I shutdown the system in the DMZ, rebooted the router and flushed
+the ARP cache on the firewall and kaos. Then, from kaos, I started pinging
+that IP address and checked the updated ARP cache and lo-and-behold a
+different MAC address showed up. High levels of frustration etc., etc.
+The administrator will not be doing that again! :-)
+
Lessons Learned:
-
+
-
Read the documentation.
-
Draw your network topology before starting.
-
Understand what services you are going to allow in and out of the
- firewall, whether they are TCP or UDP packets and make a note of these
+
Read the documentation.
+
Draw your network topology before starting.
+
Understand what services you are going to allow in and out of the
+ firewall, whether they are TCP or UDP packets and make a note of these
port numbers.
-
Try to get quiet time to build the firewall - you need to focus on
-the job at hand.
-
When asking for assistance, be honest and include as much detail
-as requested. Don't try and hide IP addresses etc., you will probably
+
Try to get quiet time to build the firewall - you need to focus
+on the job at hand.
+
When asking for assistance, be honest and include as much detail
+as requested. Don't try and hide IP addresses etc., you will probably
screw up the logs and make receiving assistance harder.
-
Read the documentation.
+
Read the documentation.
+
-
+
Futures:
-
-
This is by no means the final configuration. In the near future, I will
-be moving more systems from the LAN to the DMZ. I will also be watching
-the logs for port scan programs etc. but, this should be standard security
+
+
This is by no means the final configuration. In the near future, I will
+be moving more systems from the LAN to the DMZ. I will also be watching
+the logs for port scan programs etc. but, this should be standard security
maintenance.
+
+
Here are copies of my files. I have removed most of the internal documentation
+for the purpose of this space however, my system still has the original
+files with all the comments and I highly recommend you do the same.
+
-
Here are copies of my files. I have removed most of the internal
-documentation for the purpose of this space however, my system still has
-the original files with all the comments and I highly recommend you do
-the same.
-
-
Shorewall.conf
-
-
+
+
############################################################################## # /etc/shorewall/shorewall.conf V1.4 - Change the following variables to # match your setup # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # This file should be placed in /etc/shorewall # # (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) ############################################################################## # L O G G I N G ############################################################################## LOGFILE=/var/log/messages LOGFORMAT="Shorewall:%s:%s:" LOGRATE= LOGBURST= LOGUNCLEAN=info BLACKLIST_LOGLEVEL= LOGNEWNOTSYN= MACLIST_LOG_LEVEL=info TCP_FLAGS_LOG_LEVEL=debug RFC1918_LOG_LEVEL=debug PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SUBSYSLOCK=/var/lock/subsys/shorewall STATEDIR=/var/lib/shorewall MODULESDIR= FW=fw NAT_ENABLED=Yes MANGLE_ENABLED=Yes IP_FORWARDING=On ADD_IP_ALIASES=Yes ADD_SNAT_ALIASES=Yes TC_ENABLED=Yes CLEAR_TC=No MARK_IN_FORWARD_CHAIN=No CLAMPMSS=No ROUTE_FILTER=Yes NAT_BEFORE_RULES=No MULTIPORT=Yes DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 NEWNOTSYN=Yes BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT TCP_FLAGS_DISPOSITION=DROP #LAST LINE -- DO NOT REMOVE
-
-
+
+
Zones File
-
-
+
+
# # Shorewall 1.4 -- Sample Zone File For Two Interfaces # /etc/shorewall/zones # # This file determines your network zones. Columns are: # # ZONE Short name of the zone # DISPLAY Display name of the zone # COMMENTS Comments about the zone # #ZONE DISPLAY COMMENTS net Net Internet loc Local Local Networks dmz DMZ Demilitarized Zone vpn1 VPN1 VPN to Germany #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
+
Interfaces File:
-
-
+
+
##############################################################################
-#ZONE INTERFACE BROADCAST OPTIONS
-net eth0 62.123.106.127 routefilter,norfc1918,blacklist,tcpflags
-loc eth1 detect dhcp,routefilter
-dmz eth2 detect
-vpn1 ipsec0
-#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+ #ZONE INTERFACE BROADCAST OPTIONS
+ net eth0 62.123.106.127 routefilter,norfc1918,blacklist,tcpflags
+ loc eth1 detect dhcp,routefilter
+ dmz eth2 detect
+ vpn1 ipsec0
+ #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
Routestopped File:
-
-
+
+
#INTERFACE HOST(S) eth1 - eth2 - #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
Policy File:
-
-
+
+
############################################################################### #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT loc fw ACCEPT loc dmz ACCEPT # If you want open access to the Internet from your Firewall # remove the comment from the following line. fw net ACCEPT fw loc ACCEPT fw dmz ACCEPT dmz fw ACCEPT dmz loc ACCEPT dmz net ACCEPT # # Adding VPN Access loc vpn1 ACCEPT dmz vpn1 ACCEPT fw vpn1 ACCEPT vpn1 loc ACCEPT vpn1 dmz ACCEPT vpn1 fw ACCEPT # net all DROP info all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
+
Masq File:
-
-
+
+
#INTERFACE SUBNET ADDRESS eth0 eth1 1192.0.18.126 # #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
+
NAT File:
-
-
+
+
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL # # Intranet Web Server 192.0.18.115 eth0:0 10.10.1.60 No No # # Project Web Server 192.0.18.84 eth0:1 10.10.1.55 No No # # Blackberry Server 192.0.18.97 eth0:2 10.10.1.55 No No # # Corporate Mail Server 192.0.18.93 eth0:3 10.10.1.252 No No # # Second Corp Mail Server 192.0.18.70 eth0:4 10.10.1.8 No No # # Sims Server 192.0.18.75 eth0:5 10.10.1.56 No No # #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
+
Proxy ARP File:
-
-
+
+
#ADDRESS INTERFACE EXTERNAL HAVEROUTE # # The Corporate email server in the DMZ 192.0.18.80 eth2 eth0 No # #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
Tunnels File:
-
-
+
+
# TYPE ZONE GATEWAY GATEWAY ZONE PORT ipsec net 134.147.129.82 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
Rules File (The shell variables are set in /etc/shorewall/params):
-
-
+
+
############################################################################## #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST # # Accept DNS connections from the firewall to the network # ACCEPT fw net tcp 53 ACCEPT fw net udp 53 # # Accept SSH from internet interface from kaos only # ACCEPT net:192.0.18.98 fw tcp 22 # # Accept connections from the local network for administration # ACCEPT loc fw tcp 20:22 ACCEPT loc net tcp 22 ACCEPT loc fw tcp 53 ACCEPT loc fw udp 53 ACCEPT loc net tcp 53 ACCEPT loc net udp 53 # # Allow Ping To And From Firewall # ACCEPT loc fw icmp 8 ACCEPT loc dmz icmp 8 ACCEPT loc net icmp 8 ACCEPT dmz fw icmp 8 ACCEPT dmz loc icmp 8 ACCEPT dmz net icmp 8 DROP net fw icmp 8 DROP net loc icmp 8 DROP net dmz icmp 8 ACCEPT fw loc icmp 8 ACCEPT fw dmz icmp 8 DROP fw net icmp 8 # # Accept proxy web connections from the inside # ACCEPT loc fw tcp 8118 # # Forward PcAnywhere, Oracle and Web traffic from outside to the Demo systems # From a specific IP Address on the Internet. # # ACCEPT net:207.65.110.10 loc:10.10.3.151 tcp 1521,http # ACCEPT net:207.65.110.10 loc:10.10.2.32 tcp 5631:5632 # # Intranet web server ACCEPT net loc:10.10.1.60 tcp 443 ACCEPT dmz loc:10.10.1.60 tcp 443 # # Projects web server ACCEPT net loc:10.10.1.55 tcp 80 ACCEPT dmz loc:10.10.1.55 tcp 80 # # Blackberry Server ACCEPT net loc:10.10.1.230 tcp 3101 # # Corporate Email Server ACCEPT net loc:10.10.1.252 tcp 25,53,110,143,443 # # Corporate #2 Email Server ACCEPT net loc:10.10.1.8 tcp 25,80,110,443 # # Sims Server ACCEPT net loc:10.10.1.56 tcp 80,443 ACCEPT net loc:10.10.1.56 tcp 7001:7002 ACCEPT net:63.83.198.0/24 loc:10.10.1.56 tcp 5631:5632 # # Access to DMZ ACCEPT loc dmz udp 53,177 ACCEPT loc dmz tcp 80,25,53,22,143,443,993,20,110 - ACCEPT net dmz udp 53 ACCEPT net dmz tcp 25,53,22,21,123 ACCEPT dmz net tcp 25,53,80,123,443,21,22 ACCEPT dmz net udp 53 # #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
Start File:
-
-
+
+
############################################################################ # Shorewall 1.4 -- /etc/shorewall/start # # Add commands below that you want to be executed after shorewall has # been started or restarted. # qt service ipsec start
-
-
+
+
Stop File:
-
-
+
+
############################################################################ # Shorewall 1.4 -- /etc/shorewall/stop # # Add commands below that you want to be executed at the beginning of a # "shorewall stop" command. # qt service ipsec stop
-
-
+
+
Init File:
-
-
+
+
############################################################################ # Shorewall 1.4 -- /etc/shorewall/init # # Add commands below that you want to be executed at the beginning of # a "shorewall start" or "shorewall restart" command. # qt service ipsec stop
This documentation is intended primarily for reference.
- Step-by-step instructions for configuring
- Shorewall in common setups may be found in
-the QuickStart Guides.
-
+
This documentation is intended primarily for
+reference. Step-by-step instructions for configuring Shorewall in
+common setups may be found in the QuickStart Guides.
Components
-
-
Shorewall consists of the following components:
-
+
Shorewall consists of the following components:
-
params -- a parameter file installed
- in /etc/shorewall that can be used to establish the
- values of shell variables for use in other files.
-
shorewall.conf -- a parameter file
- installed in /etc/shorewall that is used to set several
- firewall parameters.
-
zones - a parameter file installed
- in /etc/shorewall that defines a network partitioning
- into "zones"
-
policy -- a parameter file installed
- in /etc/shorewall/ that establishes overall firewall
- policy.
-
rules -- a parameter file installed
- in /etc/shorewall and used to express firewall
- rules that are exceptions to the high-level policies
- established in /etc/shorewall/policy.
-
blacklist -- a parameter file
- installed in /etc/shorewall and used to list blacklisted
- IP/subnet/MAC addresses.
-
ecn -- a parameter
- file installed in /etc/shorewall and used to selectively disable
- Explicit Congestion Notification (ECN - RFC 3168).
-
-
functions
- -- a set of shell functions used by both the firewall
- and shorewall shell programs. Installed in /etc/shorewall
- prior to version 1.3.2, in /var/lib/shorewall in version
- s 1.3.2-1.3.8 and in /usr/lib/shorewall in later versions.
-
modules -- a parameter file installed
- in /etc/shorewall and that specifies kernel modules and
- their parameters. Shorewall will automatically load
- the modules specified in this file.
-
-
tos-- a parameter
- file installed in /etc/shorewall that is used to specify
- how the Type of Service (TOS) field in packets is to be set.
-
-
common.def -- a parameter file
- installed in in /etc/shorewall that defines firewall-wide
- rules that are applied before a DROP or REJECT policy
- is applied.
-
interfaces -- a parameter
- file installed in /etc/shorewall/ and used to describe the
-interfaces on the firewall system.
-
hosts-- a parameter file
- installed in /etc/shorewall/ and used to describe
- individual hosts or subnetworks in zones.
-
maclist-- a parameter file
-installed in /etc/shorewall and used to verify the MAC address
- (and possibly also the IP address(es)) of devices.
-
-
masq - This file also describes
- IP masquerading under Shorewall and is installed in
- /etc/shorewall.
-
firewall -- a shell
- program that reads the configuration files in
- /etc/shorewall and configures your firewall.
-This file is installed in your init.d directory
-(/etc/rc.d/init.d ) where it is renamed shorewall.
- /etc/shorewall/firewall (/var/lib/shorewall/firewall
- in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall
-in 1.3.9 and later) is a symbolic link to this program.
-
nat -- a parameter file in /etc/shorewall
- used to define static NAT .
routestopped -- a parameter
- file in /etc/shorewall used to define those hosts that can
- access the firewall when Shorewall is stopped.
-
tcrules-- a parameter
- file in /etc/shorewall used to define rules for classifying
- packets for Traffic Shaping/Control.
-
tunnels -- a parameter file in
- /etc/shorewall used to define IPSec tunnels.
-
shorewall -- a shell program
- (requiring a Bourne shell or derivative) used
- to control and monitor the firewall. This should be placed
- in /sbin or in /usr/sbin (the install.sh script and
- the rpm install this file in /sbin).
-
version
- -- a file created in /etc/shorewall/
- (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall
- beginning in version 1.3.9) that describes the version
- of Shorewall installed on your system.
-
+
params -- a parameter file
+installed in /etc/shorewall that can be used to establish the values of
+shell variables for use in other files.
+
shorewall.conf -- a parameter file
+installed in /etc/shorewall that is used to set
+several firewall parameters.
+
zones - a parameter file installed
+in /etc/shorewall that defines a network partitioning into "zones"
+
policy -- a parameter file
+installed in /etc/shorewall/ that establishes overall firewall policy.
+
rules -- a parameter file
+installed in /etc/shorewall and used to express firewall rules that are
+exceptions to the high-level policies established in
+/etc/shorewall/policy.
+
blacklist -- a parameter file
+installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC
+addresses.
+
ecn -- a parameter file installed in
+/etc/shorewall and used to selectively disable Explicit Congestion
+Notification (ECN - RFC 3168).
+
+
functions -- a set of shell functions used by both the
+firewall and shorewall shell programs. Installed in /etc/shorewall
+prior to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8
+and in /usr/lib/shorewall in later versions.
+
modules -- a parameter file
+installed in /etc/shorewall and that specifies kernel modules and their
+parameters. Shorewall will automatically load the modules specified in
+this file.
+
tos-- a parameter file installed in
+/etc/shorewall that is used to specify how the Type of Service (TOS)
+field in packets is to be set.
+
+
common.def -- a parameter file
+installed in in /etc/shorewall that defines firewall-wide rules that
+are applied before a DROP or REJECT policy is applied.
+
interfaces -- a parameter
+file installed in /etc/shorewall/ and used to describe the interfaces
+on the firewall system.
+
hosts-- a parameter file installed
+in /etc/shorewall/ and used to describe individual hosts or subnetworks
+in zones.
+
maclist-- a parameter file
+installed in /etc/shorewall and used to verify the MAC address (and
+possibly also the IP address(es)) of devices.
+
+
masq - This file also describes IP
+masquerading under Shorewall and is installed in /etc/shorewall.
+
firewall --
+a shell program that reads the configuration files in /etc/shorewall
+and configures your firewall. This file is installed in your init.d
+directory (/etc/rc.d/init.d ) where it is renamed shorewall.
+/etc/shorewall/firewall (/var/lib/shorewall/firewall in versions
+1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 and later) is a
+symbolic link to this program.
+
nat -- a parameter file in
+/etc/shorewall used to define static NAT .
+
proxyarp -- a parameter file in
+/etc/shorewall used to define Proxy Arp .
routestopped -- a parameter
+file in /etc/shorewall used to define those hosts that can access the
+firewall when Shorewall is stopped.
+
tcrules-- a
+parameter file in /etc/shorewall used to define rules for classifying
+packets for Traffic Shaping/Control.
+
tunnels -- a parameter file in
+/etc/shorewall used to define IPSec tunnels.
+
shorewall -- a shell program
+(requiring a Bourne shell or derivative) used to control and monitor
+the firewall. This should be placed in /sbin or in /usr/sbin (the
+install.sh
+script and the rpm install this file in /sbin).
+
version -- a file created in /etc/shorewall/
+(/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall
+beginning in version 1.3.9) that describes the version of Shorewall
+installed on your system.
-
-
/etc/shorewall/params
-
-
You may use the file /etc/shorewall/params file to set shell variables
- that you can then use in some of the other
-configuration files.
-
+
/etc/shorewall/params
+
You may use the file /etc/shorewall/params file to set shell
+variables that you can then use in some of the other configuration
+files.
It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally
- within the Shorewall programs
-
+ size="1"> to distinguish them from variables used internally
+within the Shorewall programs
The result will be the same as if the record had been written
-
net eth0 130.252.100.255 blacklist,norfc1918
-
-
Variables may be used anywhere in the other configuration
- files.
-
-
/etc/shorewall/zones
-
-
This file is used to define the network zones. There is one entry
- in /etc/shorewall/zones for each zone; Columns
- in an entry are:
-
+
Variables may be used anywhere in the other configuration files.
+
/etc/shorewall/zones
+
This file is used to define the network zones. There is one entry in
+/etc/shorewall/zones for each zone; Columns in an entry are:
-
ZONE
- - short name for the zone. The name should be 5 characters
- or less in length (4 characters or less if you are running Shorewall
- 1.4.4 or later) and consist of lower-case letters or numbers.
- Short names must begin with a letter and the name assigned
- to the firewall is reserved for use by Shorewall itself.
- Note that the output produced by iptables is much easier
- to read if you select short names that are three characters
-or less in length. The name "all" may not be used as
-a zone name nor may the zone name assigned to the firewall itself
- via the FW variable in /etc/shorewall/shorewall.conf.
-
DISPLAY
- - The name of the zone as displayed during Shorewall
- startup.
-
COMMENTS
- - Any comments that you want to make about the zone.
- Shorewall ignores these comments.
-
+
ZONE - short name for the zone. The name should be 5
+characters or less in length (4 characters or less if you are running
+Shorewall 1.4.4 or later) and consist of lower-case letters or numbers.
+Short names must begin with a letter and the name assigned to the
+firewall is reserved for use by Shorewall itself. Note that the output
+produced by iptables is much easier to read if you select short names
+that are three characters or less in length. The name "all" may not be
+used as a zone name nor may the zone name assigned to the firewall
+itself via the FW variable in /etc/shorewall/shorewall.conf.
+
DISPLAY - The name of the zone as displayed during
+Shorewall startup.
+
COMMENTS - Any comments that you want to make about the
+zone. Shorewall ignores these comments.
-
-
The /etc/shorewall/zones file released with Shorewall is as follows:
-
+
The /etc/shorewall/zones file released with Shorewall is as follows:
-
-
-
-
- ZONE
-
- DISPLAY
-
- COMMENTS
-
-
-
-
net
-
Net
-
Internet
-
-
-
loc
-
Local
-
Local
- networks
-
-
-
dmz
-
DMZ
-
Demilitarized
- zone
-
-
-
-
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
net
+
Net
+
Internet
+
+
+
loc
+
Local
+
Local networks
+
+
+
dmz
+
DMZ
+
Demilitarized zone
+
+
-
-
You may add, delete and modify entries in the /etc/shorewall/zones file
- as desired so long as you have at least one
-zone defined.
-
-
Warning 1: If you rename or delete a zone, you should perform "shorewall
- stop; shorewall start" to install the change
- rather than "shorewall restart".
-
+
You may add, delete and modify entries in the /etc/shorewall/zones
+file as desired so long as you have at least one zone defined.
+
Warning 1: If you rename or delete a zone, you should perform
+"shorewall stop; shorewall start" to install the change rather than
+"shorewall restart".
Warning 2: The order of entries in the /etc/shorewall/zones file is
- significant in some cases.
-
-
/etc/shorewall/interfaces
-
-
This file is used to tell the firewall which of your firewall's network
- interfaces are connected to which zone. There
- will be one entry in /etc/shorewall/interfaces for
-each of your interfaces. Columns in an entry are:
-
+ color="#ff0000">The order of entries in the /etc/shorewall/zones file
+is significant in some cases.
+
/etc/shorewall/interfaces
+
This file is used to tell the firewall which of your firewall's
+network interfaces are connected to which zone. There will be one entry
+in /etc/shorewall/interfaces for each of your interfaces. Columns in an
+entry are:
-
ZONE
- - A zone defined in the /etc/shorewall/zones
- file or "-". If you specify "-", you must
- use the /etc/shorewall/hosts
- file to define the zones accessed via this interface.
-
INTERFACE
- - the name of the interface (examples: eth0, ppp0,
- ipsec+). Each interface can be listed on only one record
-in this file. DO NOT INCLUDE
-THE LOOPBACK INTERFACE (lo) IN THIS FILE!!!
-
BROADCAST
- - the broadcast address(es) for the sub-network(s)
- attached to the interface. This should be left empty
-for P-T-P interfaces (ppp*, ippp*); if you need to specify
- options for such an interface, enter "-" in this column. If
- you supply the special value "detect" in this column, the firewall
- will automatically determine the broadcast address.
-In order to use "detect":
-
+
ZONE - A zone defined in the /etc/shorewall/zones
+file or "-". If you specify "-", you must use the
+/etc/shorewall/hosts file to define the zones accessed via this
+interface.
+
INTERFACE - the name of the interface (examples: eth0,
+ppp0, ipsec+). Each interface can be listed on only one record in this
+file. DO NOT INCLUDE THE LOOPBACK
+INTERFACE (lo) IN THIS FILE!!!
+
BROADCAST - the broadcast address(es) for the
+sub-network(s) attached to the interface. This should be left empty for
+P-T-P interfaces (ppp*, ippp*); if you need to specify options for such
+an interface, enter "-" in this column. If you supply the special value
+"detect" in this column, the
+firewall will automatically determine the broadcast address. In order
+to use "detect":
-
-
the interface must be up before you start
- your firewall
-
the interface
- must only be attached to a single sub-network (i.e.,
- there must have a single broadcast address).
-
-
+
the interface must be up before you start your firewall
+
the interface must only be attached to a single sub-network
+(i.e., there must have a single broadcast address).
-
-
OPTIONS
- - a comma-separated list of options. Possible options
- include:
-
- newnotsyn (Added in version 1.4.6) - This
-option overrides NEWNOTSYN=No for packets arriving
-on this interface. In other words, packets coming in on this interface
-are processed as if NEWNOTSYN=Yes had been specified in /etc/shorewall/shorewall.conf.
-
- routeback (Added in version 1.4.2) - This option causes Shorewall
- to set up handling for routing packets that arrive on this interface
- back out the same interface. If this option is specified, the ZONE
-column may not contain "-".
-
-
-
tcpflags (added in version 1.3.11) - This option causes Shorewall
-to make sanity checks on the header flags in TCP packets arriving on this
-interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; these
-flag combinations are typically used for "silent" port scans. Packets failing
-these checks are logged according to the TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf and are disposed of according
- to the TCP_FLAGS_DISPOSITION option.
-
- blacklist - This option
- causes incoming packets on this interface
- to be checked against the blacklist.
-
- dhcp - The interface
- is assigned an IP address via DHCP or is used
-by a DHCP server running on the firewall. The firewall
- will be configured to allow DHCP traffic to and from the
- interface even when the firewall is stopped. You may
-also wish to use this option if you have a static IP but you
-are on a LAN segment that has a lot of Laptops that use DHCP and
-you select the norfc1918 option (see below).
-
-
-
norfc1918 - Packets arriving on this interface and that
- have a source address that is reserved in RFC 1918 or in other
- RFCs will be dropped after being optionally logged.
- If packet mangling is enabled in /etc/shorewall/shorewall.conf
- , then packets arriving on this interface
-that have a destination address that is reserved by
-one of these RFCs will also be logged and dropped.
-
- Addresses blocked
- by the standard rfc1918
- file include those addresses reserved
-by RFC1918 plus other ranges reserved by the IANA or
-by other RFCs.
-
-
-
Beware that as IPv4 addresses become in increasingly short supply,
- ISPs are beginning to use RFC 1918 addresses
- within their own infrastructure. Also, many cable
- and DSL "modems" have an RFC 1918 address that can be used
- through a web browser for management and monitoring functions.
- If you want to specify norfc1918 on your external
- interface but need to allow access to certain addresses
- from the above list, see FAQ 14.
-
-
-
routefilter - Invoke the Kernel's route filtering
- (anti-spoofing) facility on this interface. The
- kernel will reject any packets incoming on this interface
- that have a source address that would be routed
-outbound through another interface on the firewall.
- Warning: If you specify
-this option for an interface then the interface must be up
-prior to starting the firewall.
-
-
-
dropunclean - Packets from this interface that
-are selected by the 'unclean' match target in iptables will
- be optionally logged and then dropped.
- Warning: This feature requires
- that UNCLEAN match support be configured in your
- kernel, either in the kernel itself or as a module. UNCLEAN
- support is broken in some versions of the kernel
-but appears to work ok in 2.4.17-rc1.
-
-
-
- Update 12/17/2001: The unclean match
- patch from 2.4.17-rc1 is available
- for download. I am currently
- running this patch applied to
-kernel 2.4.16.
-
-
-
Update 12/20/2001: I've
- seen a number of tcp connection
- requests with OPT (020405B40000080A...)
- being dropped in the badpkt chain.
-This appears to be a bug in the remote TCP stack whereby
- it is 8-byte aligning a timestamp (TCP option
- 8) but rather than padding with 0x01 it is padding
- with 0x00. It's a tough call whether to deny people
- access to your servers because of this rather minor
- bug in their networking software. If you wish to disable
- the check that causes these connections to
-be dropped,
+
tcpflags (added in version 1.3.11) - This option
+causes
+Shorewall to make sanity checks on the header flags in TCP packets
+arriving
+on this interface. Checks include Null flags, SYN+FIN, SYN+RST and
+FIN+URG+PSH;
+these flag combinations are typically used for "silent" port scans.
+Packets failing these checks are logged according to the
+TCP_FLAGS_LOG_LEVEL option in
+/etc/shorewall/shorewall.conf and are disposed of
+according to the TCP_FLAGS_DISPOSITION option.
+
+blacklist - This option causes incoming packets on this interface
+to be checked against the blacklist.
+
+dhcp - The interface is assigned an IP address via DHCP or is used
+by a DHCP server running on the firewall. The firewall will be
+configured to allow DHCP traffic to and from the interface even when
+the firewall is stopped. You may also wish to use this option if you
+have a static IP
+but you are on a LAN segment that has a lot of Laptops that
+use DHCP and you select the norfc1918 option (see below).
+
norfc1918 - Packets arriving on this interface and that
+have a source address that is reserved in RFC 1918 or in other RFCs
+will be dropped after being optionally logged. If packet
+mangling is enabled in /etc/shorewall/shorewall.conf , then packets
+arriving on this interface that have a destination address that is
+reserved by one of these RFCs will also be logged and dropped.
+
+Addresses blocked by the standard rfc1918 file
+include those addresses reserved by RFC1918 plus other ranges reserved
+by the IANA or by other RFCs.
+
Beware that as IPv4 addresses become in increasingly short
+supply, ISPs are beginning to use RFC 1918 addresses within their own
+infrastructure. Also, many cable and DSL "modems" have an RFC 1918
+address that can be used through a web browser for management and
+monitoring functions. If you want to specify norfc1918 on your
+external interface but need to allow access to certain addresses from
+the above list, see FAQ 14.
+
routefilter - Invoke the Kernel's route filtering
+(anti-spoofing) facility on this interface. The kernel will reject any
+packets incoming on this interface that have a source address that
+would be routed
+outbound through another interface on the firewall. Warning: If you specify
+this option for an interface then the interface must be up
+prior to starting the firewall.
+
dropunclean - Packets from this interface that are
+selected by the 'unclean' match target in iptables will be optionally logged and then dropped. Warning: This feature requires that UNCLEAN match
+support be configured in your kernel, either in the kernel itself or as
+a module. UNCLEAN support is broken in some versions of the kernel but
+appears to work ok in 2.4.17-rc1.
+
+Update 12/17/2001: The unclean match patch from 2.4.17-rc1
+is available
+for download. I am currently running this patch applied to kernel
+2.4.16.
+
Update 12/20/2001: I've
+seen a number of tcp connection requests with OPT (020405B40000080A...)
+being dropped in the badpkt chain. This appears to be a bug in
+the remote TCP stack whereby it is 8-byte aligning a timestamp (TCP
+option 8) but rather than padding with 0x01 it is padding with 0x00.
+It's a tough call whether to deny people access to your servers because
+of this rather minor bug in their networking software. If you wish to
+disable the check that causes these connections to
+be dropped, here's
- a kernel patch against 2.4.17-rc2.
-
-
-
logunclean - This option works like dropunclean
- with the exception that packets
- selected by the 'unclean' match
- target in iptables are logged but not dropped.
- The level at which the packets are logged
- is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN
- has not been set, "info" is assumed.
-
-
-
proxyarp (Added in version 1.3.5) - This option causes
- Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp
- and is used when implementing
- Proxy ARP Sub-netting as described
- at
- http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do
- not set this option if you are implementing
- Proxy ARP through entries in
- /etc/shorewall/proxyarp.
-
- maclist (Added
- in version 1.3.10) - If this option is specified, all
- connection requests from this interface are subject to
- MAC Verification. May only be
- specified for ethernet interfaces.
-
-
+a kernel patch against 2.4.17-rc2.
+
logunclean - This option works like dropunclean
+with the exception that packets selected by the 'unclean' match target
+in iptables are logged but not dropped. The level at which the
+packets are logged is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN has not been set,
+"info" is assumed.
+
proxyarp (Added in version 1.3.5) - This option causes
+Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp
+and is used when implementing Proxy ARP Sub-netting as described at
+http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do not
+set this option if you are implementing Proxy ARP through entries in /etc/shorewall/proxyarp.
+
+ maclist (Added in version 1.3.10) - If this option is
+specified, all connection requests from this interface are subject to MAC Verification. May
+only be specified for ethernet interfaces.
Don't use dropunclean -- It's broken in my opinion
+
Use logunclean only when you are trying to debug a problem
+
Use dhcp and proxyarp when needed.
+
-
-
-
-
Example 1: You have a conventional firewall setup in which eth0 connects
- to a Cable or DSL modem and eth1 connects to
- your local network and eth0 gets its IP address via
- DHCP. You want to check all packets entering from the internet
- against the black list. Your /etc/shorewall/interfaces
- file would be as follows:
-
-
-
+
+
Example 1: You have a conventional firewall setup in which eth0
+connects to a Cable or DSL modem and eth1 connects to your local
+network and eth0 gets its IP address via DHCP. You want to check all
+packets entering from the
+internet against the black list. Your
+/etc/shorewall/interfaces file would be as follows:
+
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
net
-
eth0
-
detect
-
dhcp,norfc1918,blacklist
-
-
-
loc
-
eth1
-
detect
-
-
-
-
-
-
-
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
eth0
+
detect
+
dhcp,norfc1918,blacklist
+
+
+
loc
+
eth1
+
detect
+
+
+
+
-
-
-
Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces
- file would be:
-
-
-
+
+
Example 2: You have a standalone dialup GNU/Linux System. Your
+/etc/shorewall/interfaces file would be:
+
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
net
-
ppp0
-
-
-
-
-
-
-
-
-
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
ppp0
+
+
+
+
+
+
-
-
-
Example 3: You have local interface eth1 with two IP addresses -
- 192.168.1.1/24 and 192.168.12.1/24
-
-
-
+
+
Example 3: You have local interface eth1 with two IP addresses -
+192.168.1.1/24 and 192.168.12.1/24
+
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
loc
-
eth1
-
192.168.1.255,192.168.12.255
-
-
-
-
-
-
-
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
loc
+
eth1
+
192.168.1.255,192.168.12.255
+
+
+
+
-
-
-
/etc/shorewall/hosts
- Configuration
-
-
For most applications, specifying zones entirely in terms of network
- interfaces is sufficient. There may be times though where you need to
-define a zone to be a more general collection of hosts. This is the purpose
-of the /etc/shorewall/hosts file.
-
-
WARNING: The only times that you need
-entries in /etc/shorewall/hosts are:
-
-
+
+
/etc/shorewall/hosts
+Configuration
+
For most applications, specifying zones entirely in terms of network
+interfaces is sufficient. There may be times though where you need to
+define
+a zone to be a more general collection of hosts. This is the purpose of
+the /etc/shorewall/hosts file.
+
WARNING: The only times that you
+need entries
+in /etc/shorewall/hosts are:
+
-
You have more than one zone connecting through
- a single interface; or
-
You have a zone that has multiple subnetworks
- that connect through a single interface and you want the Shorewall
- box to route traffic between those subnetworks.
-
-
+
You have more than one zone connecting
+through a single interface; or
+
You have a zone that has multiple subnetworks that connect
+through a single interface and you want the Shorewall box to route
+traffic between those subnetworks.
+
- IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN
- DON'T TOUCH THIS FILE!!
-
Columns in this file are:
-
+IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS
+THEN DON'T TOUCH THIS FILE!!
+
HOST(S) - The name of a network interface followed by a
+colon (":") followed by a comma-separated list either:
-
-
-
+
-
-
An IP address (example - eth1:192.168.1.3)
-
-
A subnet in CIDR notation
- (example - eth2:192.168.2.0/24)
-
-
+
An IP address (example - eth1:192.168.1.3)
+
A subnet in CIDR notation(example -
+eth2:192.168.2.0/24)
-
-
-
The interface name much match an entry in /etc/shorewall/interfaces.
-
-
-
Warning: If you are running a
-version of Shorewall earlier than 1.4.6, only a single host/subnet address
-may be specified in an entry in /etc/shorewall/hosts.
-
-
-
-
-
OPTIONS
- - A comma-separated list of option
-
-
-
-
-
-
routeback (Added in version 1.4.2) - This option causes Shorewall
- to set up handling for routing packets sent by this host group back
- back to the same group.
-
- maclist - Added in version 1.3.10. If specified,
- connection requests from the hosts specified in this entry
- are subject to MAC Verification.
- This option is only valid for ethernet interfaces.
-
-
-
-
If you don't define any hosts for a zone, the hosts in the zone default
- to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0,
- i1, ... are the interfaces to the zone.
-
-
Note: You probably DON'T
- want to specify any hosts for your internet zone since the
- hosts that you specify will be the only ones that you will be
-able to access without adding additional rules.
-
-
Example 1:
-
-
Your local interface is eth1 and you have two groups of local hosts that
- you want to make into separate zones:
-
-
-
192.168.1.0/25
-
-
192.168.1.128/
-
-
-
-
Your /etc/shorewall/interfaces file might look like:
-
-
-
-
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
net
-
eth0
-
detect
-
dhcp,norfc1918
-
-
-
-
-
eth1
-
192.168.1.127,192.168.1.255
-
-
-
-
-
-
-
-
-
-
-
-
The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces
- to multiple zones.
-
-
Your /etc/shorewall/hosts file might look like:
-
-
-
-
-
-
-
-
-
- ZONE
-
- HOST(S)
-
- OPTIONS
-
-
-
loc1
-
eth1:192.168.1.0/25
-
-
-
-
-
loc2
-
eth1:192.168.1.128/25
-
-
-
-
-
-
-
-
-
-
-
Example 2:
-
-
Your local interface is eth1 and you have two groups of local hosts that
- you want to consider as one zone and you want Shorewall to route
- between them:
-
-
-
192.168.1.0/25
-
192.168.1.128/25
-
-
-
-
Your /etc/shorewall/interfaces file might look like:
-
-
-
-
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
net
-
eth0
-
detect
-
dhcp,norfc1918
-
-
-
loc
-
-
eth1
-
192.168.1.127,192.168.1.255
-
-
-
-
-
-
-
-
-
-
-
-
Your /etc/shorewall/hosts file might look like:
-
-
-
-
-
-
-
-
-
- ZONE
-
- HOST(S)
-
- OPTIONS
-
-
-
loc
-
eth1:192.168.1.0/25
-
-
-
-
-
loc
-
eth1:192.168.1.128/25
-
-
-
-
-
-
-
-
-
- If you are running Shorewall
-1.4.6 or later, your hosts file may look like:
-
-
-
-
-
-
-
- ZONE
-
- HOST(S)
-
- OPTIONS
-
-
-
loc
-
eth1:192.168.1.0/25,192.168.1.128/25
-
-
-
-
-
-
-
-
-
-
-
-
-
Nested and Overlapping
-Zones
-
-
The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow you
- to define nested or overlapping zones. Such overlapping/nested zones
- are allowed and Shorewall processes zones in the order that
- they appear in the /etc/shorewall/zones file. So if you have
- nested zones, you want the sub-zone to appear before the
-super-zone and in the case of overlapping zones, the rules
- that will apply to hosts that belong to both zones is
- determined by which zone appears first in /etc/shorewall/zones.
-
-
Hosts that belong to more than one zone may be managed by the rules
- of all of those zones. This is done through use
- of the special CONTINUE policy described
- below.
-
-
/etc/shorewall/policy
- Configuration.
-
-
This file is used to describe the firewall policy regarding establishment
- of connections. Connection establishment is described
- in terms of clients who initiate connections
- and servers who receive those connection
-requests. Policies defined in /etc/shorewall/policy describe
- which zones are allowed to establish connections with other
- zones.
-
-
Policies established in /etc/shorewall/policy can be viewed as default
- policies. If no rule in /etc/shorewall/rules
-applies to a particular connection request then the
-policy from /etc/shorewall/policy is applied.
-
-
Four policies are defined:
-
-
-
ACCEPT
- - The connection is allowed.
-
DROP
- - The connection request is ignored.
-
REJECT
- - The connection request is rejected with an RST
-(TCP) or an ICMP destination-unreachable packet being
- returned to the client.
-
CONTINUE
- - The connection is neither ACCEPTed, DROPped
- nor REJECTed. CONTINUE may be used when one or both of
- the zones named in the entry are sub-zones of or intersect
- with another zone. For more information, see below.
-
NONE - (Added in version 1.4.1) - Shorewall
- should not set up any infrastructure for handling traffic from
-the SOURCE zone to the DEST zone. When this policy is specified,
-the LOG LEVEL and BURST:LIMIT columns
-must be left blank.
-
-
-
-
-
For each policy specified in /etc/shorewall/policy, you can indicate
- that you want a message sent to your system
-log each time that the policy is applied.
-
-
Entries in /etc/shorewall/policy have four columns as follows:
POLICY - The default policy
- for connection requests from the SOURCE zone to the DESTINATION
- zone.
-
-
LOG LEVEL - Optional. If
-left empty, no log message is generated when the policy
-is applied. Otherwise, this column should contain an integer
- or name indicating a syslog
-level.
-
-
LIMIT:BURST - Optional.
- If left empty, TCP connection requests from the SOURCE
- zone to the DEST zone will not be rate-limited.
- Otherwise, this column specifies the maximum rate at
- which TCP connection requests will be accepted followed by
-a colon (":") followed by the maximum burst size that will be
- tolerated. Example: 10/sec:40 specifies that the
- maximum rate of TCP connection requests allowed will be 10 per
- second and a burst of 40 connections will be tolerated. Connection
- requests in excess of these limits will be dropped.
-
-
-
-
In the SOURCE and DEST columns, you can enter "all" to indicate all
- zones.
-
-
The policy file installed by default is as follows:
-
-
-
-
-
-
-
-
-
SOURCE
-
DEST
-
- POLICY
-
- LOG LEVEL
-
LIMIT:BURST
-
-
-
loc
-
net
-
ACCEPT
-
-
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
-
-
-
-
-
-
-
This table may be interpreted as follows:
-
-
-
All connection
- requests from the local network to hosts on the
- internet are accepted.
-
All connection
- requests originating from the internet are ignored
- and logged at level KERNEL.INFO.
-
All other connection
- requests are rejected and logged.
-
-
-
-
WARNING:
-
-
The firewall script processes the
- /etc/shorewall/policy file from top to bottom
-and uses the first applicable policy that it finds.
- For example, in the following policy file, the policy
- for (loc, loc) connections would be ACCEPT as specified
- in the first entry even though the third entry in the file specifies
- REJECT.
-
-
-
-
-
-
-
SOURCE
-
DEST
-
POLICY
-
LOG
- LEVEL
-
LIMIT:BURST
-
-
-
loc
-
all
-
ACCEPT
-
-
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
-
-
loc
-
loc
-
REJECT
-
info
-
-
-
-
-
-
-
-
-
-
-
IntraZone Traffic
- Shorewall allows a zone to be associated with more
-than one interface or with multiple networks that interface through
-a single interface. Beginning with Shorewall 1.4.1, Shorewall will
-ACCEPT all traffic from a zone to itself provided that there is no
-explicit policy governing traffic from that zone to itself (an explicit
-policy does not specify "all" in either the SOURCE or DEST column) and
-that there are no rules concerning connections from that zone to itself.
-If there is an explicit policy or if there are one or more rules, then
-traffic within the zone is handled just like traffic between zones is.
-
-
Any time that you have multiple interfaces associated with a single zone,
- you should ask yourself if you really want traffic routed between
- those interfaces. Cases where you might not want that behavior are:
-
-
-
-
Multiple 'net' interfaces to different ISPs.
-You don't want to route traffic from one ISP to the other through
-your firewall.
-
Multiple VPN clients. You don't necessarily want
- them to all be able to communicate between themselves using your
-gateway/router.
-
-
-
-
-
The CONTINUE
- policy
-
-
Where zones are nested or overlapping , the
- CONTINUE policy allows hosts that are within multiple
- zones to be managed under the rules of all of these
- zones. Let's look at an example:
-
-
/etc/shorewall/zones:
-
-
-
-
-
-
-
- ZONE
-
- DISPLAY
-
- COMMENTS
-
-
-
sam
-
Sam
-
Sam's
- system at home
-
-
-
net
-
Internet
-
The
-Internet
-
-
-
loc
-
Loc
-
Local
- Network
-
-
-
-
-
-
-
-
-
/etc/shorewall/interfaces:
-
-
-
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
-
-
eth0
-
detect
-
dhcp,norfc1918
-
-
-
loc
-
eth1
-
detect
-
-
-
-
-
-
-
-
-
-
-
/etc/shorewall/hosts:
-
-
-
-
-
-
-
- ZONE
-
- HOST(S)
-
- OPTIONS
-
-
-
net
-
eth0:0.0.0.0/0
-
-
-
-
-
sam
-
eth0:206.191.149.197
-
-
-
-
-
-
-
-
-
-
-
Note that Sam's home system is a member of both the sam zone
- and the
- net zone and as described
-above , that means that sam must be listed before
-net in /etc/shorewall/zones.
-
-
/etc/shorewall/policy:
-
-
-
-
-
-
-
- SOURCE
-
- DEST
-
- POLICY
-
- LOG LEVEL
-
-
-
loc
-
net
-
ACCEPT
-
-
-
-
-
sam
-
all
-
CONTINUE
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
-
-
-
-
-
The second entry above says that when Sam is the client, connection
- requests should first be process under rules
-where the source zone is sam and if there is
-no match then the connection request should be treated under
- rules where the source zone is net. It is important
- that this policy be listed BEFORE the next policy (net
-to all).
-
-
Partial /etc/shorewall/rules:
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
DNAT
-
sam
-
loc:192.168.1.3
-
tcp
-
ssh
-
-
-
-
-
-
-
DNAT
-
net
-
loc:192.168.1.5
-
tcp
-
www
-
-
-
-
-
-
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Given these two rules, Sam can connect to the firewall's internet interface
- with ssh and the connection request will be
-forwarded to 192.168.1.3. Like all hosts in the
-net zone, Sam can connect to the firewall's internet
- interface on TCP port 80 and the connection request will
- be forwarded to 192.168.1.5. The order of the rules is not
-significant.
-
-
Sometimes it is necessary to suppress port forwarding
- for a sub-zone. For example, suppose that all
- hosts can SSH to the firewall and be forwarded to
-192.168.1.5 EXCEPT Sam. When Sam connects to the firewall's
-external IP, he should be connected to the firewall itself.
- Because of the way that Netfilter is constructed, this requires
- two rules as follows:
-
-
-
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
DNAT
-
sam
-
fw
-
tcp
-
ssh
-
-
-
-
-
-
-
DNAT
-
net!sam
-
loc:192.168.1.3
-
tcp
-
ssh
-
-
-
-
-
-
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
The first rule allows Sam SSH access to the firewall. The second
- rule says that any clients from the net zone
- with the exception of those in the
-'sam' zone should have their
-connection port forwarded to
- 192.168.1.3. If you need to exclude
- more than one zone in this way, you
- can list the zones separated
- by commas (e.g., net!sam,joe,fred).
- This technique also may be used when
- the ACTION is REDIRECT.
-
-
/etc/shorewall/rules
-
-
The /etc/shorewall/rules file defines exceptions to the policies established
- in the /etc/shorewall/policy file. There is one
- entry in /etc/shorewall/rules for each of these rules.
-
-
-
-
Shorewall automatically enables firewall->firewall traffic over the
- loopback interface (lo) -- that traffic cannot be
-regulated using rules and any rule that tries to regulate
-such traffic will generate a warning and will be ignored.
-
-
-
Entries in the file have the following columns:
-
-
-
ACTION
-
-
-
-
ACCEPT, DROP,
- REJECT, CONTINUE. These have the same meaning here as
- in the policy file above.
-
DNAT -- Causes
- the connection request to be forwarded to the system
- specified in the DEST column (port forwarding). "DNAT"
- stands for "Destination Network
- Address Translation"
-
DNAT- -- The above ACTION
- (DNAT) generates two iptables rules: 1) and header-rewriting
- rule in the Netfilter 'nat' table and; 2) an ACCEPT rule
-in the Netfilter 'filter' table. DNAT- works like DNAT but only
-generates the header-rewriting rule.
-
-
REDIRECT
--- Causes the connection request to be redirected to
- a port on the local (firewall) system.
-
REDIRECT- -- The above ACTION (REDIRECT) generates
- two iptables rules: 1) and header-rewriting rule in the Netfilter
- 'nat' table and; 2) an ACCEPT rule in the Netfilter 'filter'
- table. REDIRECT- works like REDIRECT but only generates the header-rewriting
- rule.
-
-
LOG - Log the packet -- requires a syslog
- level (see below).
-
-
-
-
-
-
The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info).
-This causes the packet to be logged at the specified level prior
-to being processed according to the specified ACTION. Note: if the
-ACTION is LOG then you MUST specify a syslog level.
-
- The use of DNAT
-or REDIRECT requires that you have NAT enabled.
-
-
-
SOURCE
-- Describes the source hosts to which the rule applies..
- The contents of this field must begin with the name
- of a zone defined in /etc/shorewall/zones, $FW or "all".
- If the ACTION is DNAT or REDIRECT, sub-zones may be excluded
- from the rule by following the initial zone name with "!'
- and a comma-separated list of those sub-zones to be excluded.
- There is an example above.
-
- If the source is
- not 'all' then the source may be further restricted
- by adding a colon (":") followed by a comma-separated
- list of qualifiers. Qualifiers are may include:
-
-
-
-
An interface
- name - refers to any connection requests arriving
-on the specified interface (example loc:eth4). Beginning
- with Shorwall 1.3.9, the interface name may optionally be
-followed by a colon (":") and an IP address or subnet (examples:
-loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
-
An IP address
- - refers to a connection request from the host with
- the specified address (example net:155.186.235.151).
- If the ACTION is DNAT, this must not be a DNS name.
A subnet
-- refers to a connection request from any host in the
- specified subnet (example net:155.186.235.0/24).
-
-
-
-
-
DEST
-- Describes the destination host(s) to which the rule
- applies. May take most of the forms described above for
- SOURCE plus the following two additional forms:
-
-
-
-
An IP address
- followed by a colon and the port number
- that the server is listening on (service names from
-/etc/services are not allowed - example loc:192.168.1.3:80).
-
-
-
A single
-port number (again, service names are not allowed)
- -- this form is only allowed if the ACTION is REDIRECT
-and refers to a server running on the firewall itself and
- listening on the specified port.
-
-
-
- Restrictions:
-
-
-
-
MAC addresses may not be specified.
-
In DNAT rules, only IP addresses may be
-given -- DNS names are not permitted.
-
You may not specify both an IP address
-and an interface name in the DEST column.
-
-
-
- Unlike in the SOURCE column, a range of IP addresses may be specified
- in the DEST column as <first address>-<last address>.
- When the ACTION is DNAT or DNAT-, connections will be assigned to
-the addresses in the range in a round-robin fashion (load-balancing).
-
-
PROTO
- - Protocol. Must be a protocol name from /etc/protocols,
- a number or "all". Specifies the protocol of the connection
- request.
-
DEST
- PORT(S) - Port or port range (<low port>:<high
- port>) being connected to. May only be specified
- if the protocol is tcp, udp or icmp. For icmp, this column's
- contents are interpreted as an icmp type. If you don't want
- to specify DEST PORT(S) but need to include information in
- one of the columns to the right, enter "-" in this column.
- You may give a list of ports and/or port ranges separated by commas.
- Port numbers may be either integers or service names from /etc/services.
-
SOURCE
- PORTS(S) - May be used to restrict the
- rule to a particular client port or port range (a port
-range is specified as <low port number>:<high
-port number>). If you don't want to restrict client ports but
- want to specify something in the next column, enter "-" in this
-column. If you wish to specify a list of port number or ranges,
-separate the list elements with commas (with no embedded
-white space). Port numbers may be either integers or service
-names from /etc/services.
-
ORIGINAL
-DEST - This column may only be non-empty if the
- ACTION is DNAT or REDIRECT.
-
- If DNAT or REDIRECT
- is the ACTION and the ORIGINAL DEST column is left empty,
- any connection request arriving at the firewall from
- the SOURCE that matches the rule will be forwarded or
-redirected. This works fine for connection requests arriving
- from the internet where the firewall has only a single
- external IP address. When the firewall has multiple external
-IP addresses or when the SOURCE is other than the internet,
- there will usually be a desire for the rule to only apply
- to those connection requests directed to particular IP addresses
-(see Example 2 below for another usage). Those IP addresses are specified
-in the ORIGINAL DEST column as a comma-separated list.
-
- The IP address(es)
- may be optionally followed by ":" and a second
-IP address. This latter address, if present, is used as
-the source address for packets forwarded to the server (This
- is called "Source NAT" or SNAT.
-
- If this list begins with "!" then the rule will only apply if the
- original destination address matches none of the addresses listed.
-
- Note:
- When using SNAT, it is a good idea to qualify the source with
- an IP address or subnet. Otherwise, it is likely that SNAT will
- occur on connections other than those described in the rule.
- The reason for this is that SNAT occurs in the Netfilter
-POSTROUTING hook where it is not possible to restrict the scope
- of a rule by incoming interface.
-
- Example:
- DNAT loc:192.168.1.0/24 loc:192.168.1.3
- tcp www - 206.124.146.179:192.168.1.3
-
- If SNAT
- is not used (no ":" and second IP address), the
- original source address is used. If you want any destination
- address to match the rule but want to specify SNAT,
- simply use a colon followed by the SNAT address.
-
-
-
-
Example 1. You wish to forward all
- ssh connection requests from the internet to
- local system 192.168.1.3.
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
DNAT
-
net
-
loc:192.168.1.3
-
tcp
-
ssh
-
-
-
-
-
-
-
-
-
-
-
-
-
Example 2. You want to redirect all local www connection requests
- EXCEPT
- those to your own http server (206.124.146.177)
- to a Squid transparent proxy
- running on the firewall and listening on port 3128. Squid
- will of course require access to remote web servers. This
-example shows yet another use for the ORIGINAL
- DEST column; here, connection
- requests that were NOT
- (notice
-the "!") originally destined to 206.124.146.177
-are redirected to local port 3128.
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
REDIRECT
-
loc
-
3128
-
tcp
-
www
-
-
-
-
!206.124.146.177
-
-
-
ACCEPT
-
fw
-
net
-
tcp
-
www
-
-
-
-
-
-
-
-
-
-
-
-
-
Example 3. You want to run a web server at 155.186.235.222 in
-your DMZ and have it accessible remotely and locally. the DMZ is managed
- by Proxy ARP or by classical sub-netting.
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
ACCEPT
-
net
-
dmz:155.186.235.222
-
tcp
-
www
-
-
-
-
-
-
-
ACCEPT
-
loc
-
dmz:155.186.235.222
-
tcp
-
www
-
-
-
-
-
-
-
-
-
-
-
-
-
Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded
- DMZ. Your internet interface address is 155.186.235.151
- and you want the FTP server to be accessible from
- the internet in addition to the local 192.168.1.0/24
-and dmz 192.168.2.0/24 subnetworks. Note that since the
- server is in the 192.168.2.0/24 subnetwork, we can assume
- that access to the server from that subnet will not involve
- the firewall (but see FAQ 2). Note that
- unless you have more than one external
- IP address, you can leave
- the ORIGINAL DEST column blank
-in the first rule. You
- cannot leave it blank in the
- second rule though because
- then all ftp connections originating in
-the local subnet 192.168.1.0/24 would be
-sent to 192.168.2.2 regardless of
- the site that the user
-was trying to connect
- to. That is clearly
- not what you want
- .
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
DNAT
-
net
-
dmz:192.168.2.2
-
tcp
-
ftp
-
-
-
-
-
-
-
DNAT
-
loc:192.168.1.0/24
-
dmz:192.168.2.2
-
tcp
-
ftp
-
-
-
-
155.186.235.151
-
-
-
-
-
-
-
-
-
If you are running wu-ftpd, you should restrict the range of passive
- in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions
- so I use port range 65500-65535. In /etc/ftpaccess,
- this entry is appropriate:
-
-
-
-
passive ports 0.0.0.0/0 65500 65534
-
-
-
If you are running pure-ftpd, you would include "-p 65500:65534" on
- the pure-ftpd runline.
-
-
The important point here is to ensure that the port range used for FTP
- passive connections is unique and will not overlap
- with any usage on the firewall system.
-
-
Example 5. You wish to allow unlimited
- DMZ access to the host with MAC address
- 02:00:08:E3:FA:55.
-
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
- PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
ACCEPT
-
loc:~02-00-08-E3-FA-55
-
dmz
-
all
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example 6. You wish to allow access
- to the SMTP server in your DMZ from all zones.
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DEST
-
-
PROTO
-
-
DEST
- PORT(S)
-
-
SOURCE
- PORT(S)
-
-
ORIGINAL
- DEST
-
-
-
-
ACCEPT
-
-
all
-
-
dmz
-
-
tcp
-
-
25
-
-
-
-
-
-
-
-
-
-
-
-
- Note: When 'all' is used as
- a source or destination, intra-zone traffic is not affected.
- In this example, if there were two DMZ interfaces then the
- above rule would NOT enable SMTP traffic between hosts on these
- interfaces.
-
- Example 7. Your firewall's
- external interface has several IP addresses but you only want to accept
- SSH connections on address 206.124.146.176.
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DEST
-
-
PROTO
-
-
DEST
- PORT(S)
-
-
SOURCE
- PORT(S)
-
-
ORIGINAL
- DEST
-
-
-
-
ACCEPT
-
-
net
-
-
fw:206.124.146.176
-
-
tcp
-
-
22
-
-
-
-
-
-
-
-
-
-
-
-
- Example 8 (For advanced users running Shorewall version
- 1.3.13 or later). From the internet, you with to forward
- tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host
- 192.0.2.177 in your DMZ. You also want to allow access from
- the internet directly to tcp port 25 on 192.0.2.177.
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DEST
-
-
PROTO
-
-
DEST
- PORT(S)
-
-
SOURCE
- PORT(S)
-
-
ORIGINAL
- DEST
-
-
-
-
DNAT-
-
-
net
-
-
dmz:192.0.2.177
-
-
tcp
-
-
25
-
-
0
-
-
192.0.2.178
-
-
-
-
DNAT-
-
-
net
-
-
dmz:192.0.2.177
-
-
tcp
-
-
25
-
-
0
-
-
192.0.2.179
-
-
-
-
ACCEPT
-
-
net
-
-
dmz:192.0.2.177
-
-
tcp
-
-
25
-
-
-
-
-
-
-
-
-
-
-
-
- Using "DNAT-" rather than "DNAT"
- avoids two extra copies of the third rule from being generated.
-
- Example 9 (Shorewall version 1.4.6 or later). You have 9 http
- servers behind a Shorewall firewall and you want connection requests to
- be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
-
-
-
Shorewall allows definition of rules that apply between
- all zones. By default, these rules
- are defined in the file
- /etc/shorewall/common.def
- but may be modified to
- suit individual
- requirements. Rather than modify /etc/shorewall/common.def,
- you should copy that
- file to
- /etc/shorewall/common
- and modify that file.
-
-
The /etc/shorewall/common
- file is expected to contain
- iptables commands; rather than
- running iptables
- directly, you should run
- it indirectly using the
- Shorewall function
- 'run_iptables'. That way, if iptables
- encounters an error, the
- firewall will be safely
- stopped.
-
-
/etc/shorewall/masq
-
-
The /etc/shorewall/masq file is used to define classical IP Masquerading
- and Source Network Address Translation (SNAT).
- There is one entry in the file for each subnet that
- you want to masquerade. In order to make use of this
-feature, you must have NAT enabled
- .
-
-
Columns are:
-
-
-
INTERFACE
- - The interface that will masquerade the subnet; this
- is normally your internet interface. This interface
- name can be optionally qualified by adding ":" and a subnet or
- host IP. When this qualification is added, only packets addressed
- to that host or subnet will be masqueraded. Beginning with
-Shorewall version 1.3.14, if you have set ADD_SNAT_ALIASES=Yes in
- /etc/shorewall/shorewall.conf, you can cause
-Shorewall to create an alias label of the form interfacename:digit
- (e.g., eth0:0) by placing that label in this column.
-See example 5 below. Alias labels created in this way allow the
-alias to be visible to the ipconfig utility. THAT IS THE ONLY
-THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE
-IN YOUR SHOREWALL CONFIGURATION.
-
SUBNET
- - The subnet that you want to have masqueraded through
- the INTERFACE. This may be expressed as a single IP address,
- a subnet or an interface name. In the latter instance,
- the interface must be configured and started before Shorewall
- is started as Shorewall will determine the subnet based
- on information obtained from the 'ip' utility. When using Shorewall 1.3.13 or earlier, when an interface
- name is specified, Shorewall will only masquerade traffic from
- the first subnetwork on the named interface; if the interface interfaces
- to more that one subnetwork, you will need to add additional entries
- to this file for each of those other subnetworks. Beginning with
-Shorewall 1.3.14, shorewall will masquerade/SNAT traffic from any
-host that is routed through the named interface.
-
- The subnet may
-be optionally followed by "!' and a comma-separated
- list of addresses and/or subnets that are to be
-excluded from masquerading.
-
ADDRESS
- - The source address to be used for outgoing packets.
- This column is optional and if left blank, the current
- primary IP address of the interface in the first column
- is used. If you have a static IP on that interface, listing it
-here makes processing of output packets a little less expensive
- for the firewall. If you specify an address in this column, it
-must be an IP address configured on the INTERFACE or you must have
-ADD_SNAT_ALIASES enabled in /etc/shorewall/shorewall.conf.
-
-
-
-
Example 1: You have eth0 connected to a cable modem and eth1
- connected to your local subnetwork 192.168.9.0/24.
- Your /etc/shorewall/masq file would look like:
-
-
-
-
-
-
-
-
- INTERFACE
-
- SUBNET
-
ADDRESS
-
-
-
eth0
-
192.168.9.0/24
-
-
-
-
-
-
-
-
-
-
-
Example 2: You have a number of IPSEC tunnels through ipsec0
- and you want to masquerade traffic from your
- 192.168.9.0/24 subnet to the remote subnet 10.1.0.0/16
- only.
-
-
-
-
-
-
-
- INTERFACE
-
- SUBNET
-
ADDRESS
-
-
-
ipsec0:10.1.0.0/16
-
192.168.9.0/24
-
-
-
-
-
-
-
-
-
-
-
Example 3: You have a DSL line connected on eth0 and a local
- network (192.168.10.0/24)
- connected to eth1. You want
- all local->net connections
- to use source address
- 206.124.146.176.
-
-
-
-
-
-
-
- INTERFACE
-
- SUBNET
-
ADDRESS
-
-
-
eth0
-
192.168.10.0/24
-
206.124.146.176
-
-
-
-
-
-
-
-
-
Example 4: Same as example 3 except that
- you wish to exclude
- 192.168.10.44 and 192.168.10.45 from
- the SNAT rule.
-
-
-
-
-
-
-
- INTERFACE
-
- SUBNET
-
ADDRESS
-
-
-
eth0
-
192.168.10.0/24!192.168.10.44,192.168.10.45
-
206.124.146.176
-
-
-
-
-
-
-
- Example 5 (Shorewall version >= 1.3.14):
- You have a second IP address (206.124.146.177) assigned
- to you and wish to use it for SNAT of the subnet 192.168.12.0/24.
- You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes
- in /etc/shorewall/shorewall.conf.
-
-
-
-
-
-
-
- INTERFACE
-
- SUBNET
-
ADDRESS
-
-
-
eth0:0
-
192.168.12.0/24
-
206.124.146.177
-
-
-
-
-
-
-
-
-
- /etc/shorewall/proxyarp
-
-
If you want to use proxy ARP on an entire sub-network,
- I suggest that you
- look at
- http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/.
- If you decide to use the
- technique described in that
- HOWTO, you can set
- the proxy_arp flag
- for an interface
- (/proc/sys/net/ipv4/conf/<interface>/proxy_arp)
- by including the proxyarp
- option in the interface's
- record in
-
- /etc/shorewall/interfaces.
- When using Proxy
- ARP sub-netting, you do NOT include
- any entries in
- /etc/shorewall/proxyarp.
-
-
The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is
- typically used for enabling
-Proxy ARP on a small set
-of systems since
-you need one
-entry in this file for each
- system using proxy ARP. Columns
- are:
-
-
-
ADDRESS
- - address of the system.
-
INTERFACE
- - the interface that connects to the system. If the
- interface is obvious from the subnetting, you may
-enter "-" in this column.
-
EXTERNAL
- - the external interface that you want to honor
-ARP requests for the ADDRESS specified in the first
- column.
-
HAVEROUTE
- - If you already
- have a route
- through
- INTERFACE to
- ADDRESS, this column should contain
- "Yes" or "yes". If you want
- Shorewall to add the route, the
- column should
- contain
- "No" or
- "no".
-
-
-
-
Note: After you have made a change to the /etc/shorewall/proxyarp
- file, you may need to flush the ARP cache of all
- routers on the LAN segment connected to the interface
- specified in the EXTERNAL column of the change/added entry(s).
- If you are having problems communicating between an individual
- host (A) on that segment and a system whose entry has
-changed, you may need to flush the ARP cache on host A as well.
-
-
ISPs typically have ARP configured with long
-TTL (hours!) so if your ISPs router has a stale cache entry (as seen using
-"tcpdump -nei <external interface> host <IP addr>"), it may
-take a long while to time out. I personally have had to contact my ISP
-and ask them to delete a stale entry in order to restore a system to working
-order after changing my proxy ARP settings.
-
-
Example: You have public IP addresses 155.182.235.0/28. You
- configure your firewall as follows:
-
-
-
eth0 - 155.186.235.1
- (internet connection)
-
eth1 - 192.168.9.0/24
- (masqueraded local systems)
-
eth2 - 192.168.10.1
- (interface to your DMZ)
-
-
-
-
In your DMZ, you want to install a Web/FTP server with public address
- 155.186.235.4. On the Web server, you subnet
-just like the firewall's eth0 and you configure
-155.186.235.1 as the default gateway. In your /etc/shorewall/proxyarp
- file, you will have:
-
-
-
-
-
-
-
- ADDRESS
-
- INTERFACE
-
- EXTERNAL
-
HAVEROUTE
-
-
-
155.186.235.4
-
eth2
-
eth0
-
No
-
-
-
-
-
-
-
-
-
Note: You may want to configure the servers in your DMZ with a subnet
- that is smaller than the subnet of your internet
- interface. See the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/)
- for details. In this case you will want to place
- "Yes" in the HAVEROUTE column.
-
-
Warning: Do not use Proxy ARP and
-FreeS/Wan on the same system unless you are prepared to suffer the consequences.
- If you start or restart Shorewall with an IPSEC tunnel active,
- the proxied IP addresses are mistakenly assigned
-to the IPSEC tunnel device (ipsecX) rather than to
-the interface that you specify in the INTERFACE column of
- /etc/shorewall/proxyarp. I haven't had the time to debug this
- problem so I can't say if it is a bug in the Kernel or in FreeS/Wan.
+
The interface name much match an entry in
+/etc/shorewall/interfaces.
-
-
You might be able to work around this problem using the following
- (I haven't tried it):
-
-
In /etc/shorewall/init, include:
-
-
qt service ipsec stop
-
-
In /etc/shorewall/start, include:
-
-
qt service ipsec start
-
-
- /etc/shorewall/nat
-
-
The /etc/shorewall/nat file is used to define static NAT. There is one
- entry in the file for each static NAT relationship
- that you wish to define. In order to make use of
- this feature, you must have NAT enabled
- .
-
-
IMPORTANT: If all you want to do
- is forward ports
- to servers behind your firewall,
- you do NOT want to use
- static NAT. Port
- forwarding
- can be
-accomplished with simple entries
-in the
- rules file. Also, in
-most cases
- Proxy ARP
- provides a
- superior solution
- to static NAT
- because the
- internal systems
- are accessed using the same IP
- address internally and externally.
-
-
Columns in an entry are:
-
+
Warning: If you are
+running a version of Shorewall earlier than 1.4.6, only a single
+host/subnet address may be specified in an entry in
+/etc/shorewall/hosts.
+
+
-
EXTERNAL
- - External IP address - This should NOT be
- the primary IP address of the interface named in the next
- column.
-
INTERFACE
- - Interface that you want the EXTERNAL IP address
-to appear on. Beginning with Shorewall version 1.3.14, if
-you have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf,
- you can specify an alias label of the form interfacename:digit
- (e.g., eth0:0) and Shorewall will create the alias with
- that label. Alias labels created in this way allow the alias
-to be visible to the ipconfig utility. THAT IS THE ONLY THING
- THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN
-YOUR SHOREWALL CONFIGURATION.
-
INTERNAL
- - Internal IP address.
-
ALL
- INTERFACES
- - If Yes
- or yes (or
- left
- empty),
- NAT will
- be effective from all
- hosts. If
- No or no
- then NAT will
-be effective
- only
- through
- the interface named in
- the INTERFACE
- column.
-
LOCAL
- - If Yes or yes and the ALL INTERFACES column contains
- Yes or yes, NAT will be effective from the firewall system.
- Note: For this to work, you must be running
- kernel 2.4.19 or later and iptables 1.2.6a or later and
-you must have enabled CONFIG_IP_NF_NAT_LOCAL
- in your kernel.
The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP,
- OpenVPN, PPTP
- and 6to4.tunnels with end-points on your firewall. To use ipsec,
- you must install version 1.9, 1.91 or the current FreeS/WAN development
-snapshot.
-
-
Note: For kernels 2.4.4 and above, you will need to use version 1.91
- or a development snapshot as patching with
-version 1.9 results in kernel compilation errors.
This file is used to set the following firewall parameters:
-
+
+
routeback (Added in version 1.4.2) - This option causes
+Shorewall to set up handling for routing packets sent by this host
+group back back to the same group.
+
+maclist - Added in version 1.3.10. If specified, connection
+requests from the hosts specified in this entry are subject to MAC Verification. This option is only
+valid for ethernet interfaces.
+
+
+
If you don't define any hosts for a zone, the hosts in the zone
+default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the
+interfaces to the zone.
+
Note: You probably
+DON'T want to specify any hosts for your internet zone since the hosts
+that you specify will be the only ones that you will be able to access
+without adding additional rules.
+
Example 1:
+
Your local interface is eth1 and you have two groups of local hosts
+that you want to make into separate zones:
-
SHOREWALL_SHELL
- - Added at version 1.4.6
- This parameter is used to specify the shell program to be used to interpret
- the firewall script (/usr/share/shorewall/firewall). If not specified or
- specified as a null value, /bin/sh is assumed.
-
-
LOGFORMAT - Added at version 1.4.4.
- The value of this variable generate the --log-prefix setting
-for Shorewall logging rules. It contains a 'printf' formatting template
-which accepts three arguments (the chain name, logging rule number (optional)
- and the disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it as:
-
- LOGFORMAT="fp=%s:%d a=%s "
-
- If the LOGFORMAT value contains the substring '%d' then the
-logging rule number is calculated and formatted in that position; if
-that substring is not included then the rule number is not included.
-If not supplied or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:"
- is assumed.
-
- CAUTION: /sbin/shorewall uses the leading part
-of the LOGFORMAT string (up to but not including the first '%') to
-find log messages in the 'show log', 'status' and 'hits' commands. This
-part should not be omitted (the LOGFORMAT should not begin with "%")
-and the leading part should be sufficiently unique for /sbin/shorewall
-to identify Shorewall messages.
-
-
CLEAR_TC - Added at version 1.3.13
- If this option is set to 'No' then Shorewall
- won't clear the current traffic control rules during [re]start.
- This setting is intended for use by people that prefer to configure
- traffic shaping when the network interfaces come up rather
-than when the firewall is started. If that is what you want to do,
-set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart
- file. That way, your traffic shaping rules can still use the 'fwmark'
- classifier based on packet marking defined in /etc/shorewall/tcrules.
- If not specified, CLEAR_TC=Yes is assumed.
-
-
MARK_IN_FORWARD_CHAIN - Added
- at version 1.3.12
- If your kernel has a FORWARD chain
- in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes
- to cause the marking specified in the tcrules file to occur in that
- chain rather than in the PREROUTING chain. This permits you
- to mark inbound traffic based on its destination address when
-SNAT or Masquerading are in use. To determine if your kernel has
- a FORWARD chain in the mangle table, use the "/sbin/shorewall
- show mangle" command; if a FORWARD chain is displayed then your
-kernel will support this option. If this option is not specified
-or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then
- MARK_IN_FORWARD_CHAIN=No is assumed.
-
-
RFC1918_LOG_LEVEL - Added
- at version 1.3.12
- This parameter determines the
-level at which packets logged under the 'norfc1918' mechanism
- are logged. The value must be a valid syslog level and if no level is given,
- then info is assumed. Prior to Shorewall version 1.3.12,
- these packets are always logged at the info level.
-
TCP_FLAGS_DISPOSITION
-- Added in Version 1.3.11
- Determines the disposition of
-TCP packets that fail the checks enabled by the tcpflags interface option and must
- have a value of ACCEPT (accept the packet), REJECT (send an RST
- response) or DROP (ignore the packet). If not set or if set
- to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP
- is assumed.
-
TCP_FLAGS_LOG_LEVEL
- - Added in Version 1.3.11
- Determines the syslog level for logging packets
- that fail the checks enabled by the tcpflags interface option.The value must
- be a valid syslogd log level. If you don't want to log these
- packets, set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
-
-
MACLIST_DISPOSITION
- - Added in Version 1.3.10
- Determines the disposition
- of connections requests that fail MAC Verification and must have
-the value ACCEPT (accept the connection request anyway), REJECT
-(reject the connection request) or DROP (ignore the connection request).
- If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="")
- then MACLIST_DISPOSITION=REJECT is assumed.
-
MACLIST_LOG_LEVEL
- - Added in Version 1.3.10
- Determines the syslog level for logging connection
- requests that fail MAC Verification.
- The value must be a valid syslogd log level. If you
- don't want to log these connection requests, set to the
- empty value (e.g., MACLIST_LOG_LEVEL="").
-
-
NEWNOTSYN -
- Added in Version 1.3.8
- When set to "Yes" or
-"yes", Shorewall will filter TCP packets that are not
- part of an established connention and that are not SYN
-packets (SYN flag on - ACK flag off). If set to "No", Shorewall
- will silently drop such packets. If not set or set to the empty
-value (e.g., "NEWNOTSYN="), NEWNOTSYN=No is assumed.
-
- If you have a HA setup
- with failover to another firewall, you should have
- NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes
- if you have asymmetric routing.
-
-
LOGNEWNOTSYN
- - Added in Version 1.3.6
- Beginning with
-version 1.3.6, Shorewall drops non-SYN TCP packets
- that are not part of an existing connection. If you
- would like to log these packets, set LOGNEWNOTSYN to
- the syslog level at which
- you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
-
- Note: Packets
- logged under this option are usually the result
-of broken remote IP stacks rather than the result of any
-sort of attempt to breach your firewall.
-
-
DETECT_DNAT_ADDRS - Added in Version 1.3.4
- If set to "Yes" or "yes", Shorewall will detect
- the first IP address of the interface to the source zone and
-will include this address in DNAT rules as the original destination
- IP address. If set to "No" or "no", Shorewall will not detect
- this address and any destination IP address will match the
- DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes"
- is assumed.
-
-
MULTIPORT
- - (Removed in version 1.4.6 -- the value of this parameter is now automatically
- detected by Shorewall)
- If set to "Yes"
-or "yes", Shorewall will use the Netfilter multiport
- facility. In order to use this facility, your kernel
- must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT).
- When this support is used, Shorewall will generate
-a single rule from each record in the /etc/shorewall/rules
- file that meets these criteria:
-
-
-
-
No port range(s)
- specified
-
Specifies
-15 or fewer ports
-
-
-
-
-
-
Rules not meeting those criteria will continue to generate an individual
- rule for each listed port or port range.
-
-
-
NAT_BEFORE_RULES
- If set to "No"
-or "no", port forwarding rules can override the contents
- of the /etc/shorewall/nat file.
- If set to "Yes" or "yes", port forwarding rules cannot override
- static NAT. If not set or set to an empty value, "Yes"
-is assumed.
-
FW
- This
- parameter
- specifies the
- name of the
- firewall zone.
- If not set or
- if set to an empty string,
- the value "fw"
- is assumed.
-
SUBSYSLOCK
- This parameter
- should be set to the name of a file that the firewall
- should create if it starts successfully and remove
- when it stops. Creating and removing this file allows Shorewall
- to work with your distribution's initscripts. For RedHat,
- this should be set to /var/lock/subsys/shorewall. For
- Debian, the value is /var/state/shorewall and in LEAF it is /var/run/shorwall.
- Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
-
STATEDIR
- This parameter
- specifies the name of a directory where Shorewall
- stores state information. If the directory doesn't
- exist when Shorewall starts, it will create the directory.
- Example: STATEDIR=/tmp/shorewall.
-
- NOTE: If
-you change the STATEDIR variable while the firewall
- is running, create the new directory if necessary then
-copy the contents of the old directory to the new directory.
-
-
MODULESDIR
- This parameter
- specifies the directory where your kernel netfilter
- modules may be found. If you leave the variable empty,
- Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
-
LOGRATE
- and LOGBURST
- These parameters
- set the match rate and initial burst size for logged
- packets. Please see the iptables man page for a description
- of the behavior of these parameters (the iptables
- option --limit is set by LOGRATE and --limit-burst is set
-by LOGBURST). If both parameters are set empty, no
-rate-limiting will occur.
-
- Example:
- LOGRATE=10/minute
- LOGBURST=5
-
-
LOGFILE
- This parameter
- tells the
- /sbin/shorewall
- program where
- to look for
- Shorewall
- messages when processing the "show
- log", "monitor", "status"
- and "hits"
- commands. If
- not assigned
- or if assigned
- an empty
- value,
- /var/log/messages
- is assumed.
-
NAT_ENABLED
- (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically
- detected by Shorewall)
- This parameter
- determines whether Shorewall supports NAT operations.
- NAT operations include:
-
- Static
- NAT
- Port
-Forwarding
- Port
-Redirection
- Masquerading
-
- If the parameter
- has no value or has a value of "Yes" or "yes"
- then NAT is enabled. If the parameter has a value of
-"no" or "No" then NAT is disabled.
-
-
MANGLE_ENABLED
- (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically
- detected by Shorewall)
- This parameter
- determines if packet mangling is enabled. If the
-parameter has no value or has a value of "Yes" or "yes"
- than packet mangling is enabled. If the parameter
-has a value of "no" or "No" then packet mangling is disabled.
- If packet mangling is disabled, the /etc/shorewall/tos
- file is ignored.
-
-
IP_FORWARDING
- This parameter
- determines whether Shorewall enables or disables
- IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
- Possible values are:
-
- On or
-on - packet forwarding will be enabled.
- Off or
- off - packet forwarding will be disabled.
- Keep
-or keep - Shorewall will neither enable nor disable
- packet forwarding.
-
- If this variable
- is not set or is given an empty value (IP_FORWARD="")
- then IP_FORWARD=On is assumed.
-
-
ADD_IP_ALIASES
- This parameter
- determines whether Shorewall automatically adds the
- external address(es)
- in /etc/shorewall/nat . If the variable
- is set to "Yes" or "yes" then Shorewall automatically adds
- these aliases. If it is set to "No" or "no", you must add
- these aliases yourself using your distribution's network configuration
- tools. RESTRICTION: Shorewall versions before
-1.4.6 can only add addresses to the first subnetwork configured on
-an interface.
-
- If this variable
- is not set or is given an empty value (ADD_IP_ALIASES="")
- then ADD_IP_ALIASES=Yes is assumed.
-
ADD_SNAT_ALIASES
- This parameter
-determines whether Shorewall automatically adds the
- SNAT ADDRESS in /etc/shorewall/masq.
- If the variable is set to "Yes" or "yes" then Shorewall
- automatically adds these addresses. If it is set to
- "No" or "no", you must add these addresses yourself using
-your distribution's network configuration tools. RESTRICTION:
- Shorewall versions before 1.4.6 can only add addresses to
-the first subnetwork configured on an interface.
-
- If this variable
- is not set or is given an empty value (ADD_SNAT_ALIASES="")
- then ADD_SNAT_ALIASES=No is assumed.
-
-
LOGUNCLEAN
- This parameter
- determines the
- logging level
- of mangled/invalid
- packets
- controlled by
- the 'dropunclean and logunclean'
- interface
- options. If
- LOGUNCLEAN is empty
-(LOGUNCLEAN=) then packets selected
- by 'dropclean' are
- dropped
- silently ('logunclean'
- packets are
- logged
- under the 'info' log level). Otherwise,
- these packets are logged at
- the specified
- level (Example:
- LOGUNCLEAN=debug).
-
BLACKLIST_DISPOSITION
- This parameter
- determines the
- disposition of
- packets from
- blacklisted
- hosts. It may have the value DROP
- if the packets are to
- be dropped or
- REJECT if the
- packets are to
- be replied
- with an ICMP
- port
- unreachable
- reply or a TCP RST (tcp
- only). If you do not assign
- a value or if you assign an
- empty value
- then DROP is
- assumed.
-
BLACKLIST_LOGLEVEL
- This paremter
- determines if
- packets from
- blacklisted
- hosts are
-logged and it
- determines the syslog level that they
-are to be logged
- at. Its value is
-a syslog level
- (Example:
- BLACKLIST_LOGLEVEL=debug). If you do not
- assign a value or if you
- assign an empty value
- then packets
-from blacklisted
- hosts are not
- logged.
-
CLAMPMSS
- This parameter
- enables the
- TCP Clamp MSS
- to PMTU feature
-of Netfilter and
- is usually
- required when
- your
-internet connection is through
- PPPoE or PPTP. If
- set to
- "Yes" or
- "yes",
- the feature is
- enabled. If
- left blank or
- set to
- "No"
- or
- "no",
- the feature is
- not enabled. Note: This
- option requires CONFIG_IP_NF_TARGET_TCPMSS
- in your kernel.
-
ROUTE_FILTER
- If this parameter
- is given the value "Yes" or "yes" then route filtering
- (anti-spoofing) is enabled on all network interfaces.
- The default value is "no".
-
+
192.168.1.0/25
+
192.168.1.128/
-
-
/etc/shorewall/modules Configuration
-
-
The file /etc/shorewall/modules contains commands for loading the kernel
- modules required by Shorewall-defined firewall
- rules. Shorewall will source this file during start/restart
- provided that it exists and that the directory specified
- by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf
- above).
-
-
The file that is released with Shorewall calls the Shorewall function
- "loadmodule" for the set of modules that I load.
-
-
The loadmodule function is called as follows:
-
-
-
-
loadmodule <modulename> [
- <module parameters> ]
-
-
-
where
-
-
-
-
<modulename>
-
-
-
-
-
is the name of the modules without the trailing ".o" (example ip_conntrack).
-
-
-
-
<module parameters>
-
-
-
-
-
Optional parameters to the insmod utility.
-
-
-
-
The function determines if the module named by <modulename>
- is already loaded and if not then the
-function determines if the ".o" file corresponding
-to the module exists in the moduledirectory;
- if so, then the following command is executed:
If the file doesn't exist, the function determines of the ".o.gz" file
- corresponding to the module exists in the moduledirectory. If it
- does, the function assumes that the running configuration supports compressed
- modules and execute the following command:
The /etc/shorewall/tos file allows you to set the Type of Service field
- in packet headers based on packet source,
-packet destination, protocol, source port and
-destination port. In order for this file to be processed
- by Shorewall, you must have mangle
-support enabled .
-
-
Entries in the file have the following columns:
-
-
-
SOURCE
- -- The source zone. May be qualified by following
- the zone name with a colon (":") and either an IP
-address, an IP subnet, a MAC address in Shorewall Format or the
- name of an interface. This column may also contain
- the name of
- the firewall
- zone to indicate packets
-originating on the firewall itself or "all" to indicate any
- source.
-
DEST
- -- The destination zone. May be qualified by following
- the zone name with a colon (":") and either an IP
- address or an IP subnet. Because packets are marked prior
-to routing, you may not specify the name of an interface.
- This column may also contain "all" to indicate any destination.
-
PROTOCOL
- -- The name of a protocol in /etc/protocols or the
- protocol's number.
-
SOURCE
- PORT(S) -- The source port or a port range. For
- all ports, place a hyphen ("-") in this column.
-
DEST
-PORT(S) -- The destination port or a port range.
- To indicate all ports, place a hyphen ("-") in this
- column.
-
TOS
- -- The type of service. Must be one of the following:
The /etc/shorewall/tos file that is included with Shorewall contains
- the following entries.
-
-
-
-
-
-
-
SOURCE
-
DEST
-
PROTOCOL
-
SOURCE
- PORT(S)
-
DEST
- PORT(S)
-
TOS
-
-
-
all
-
all
-
tcp
-
-
-
ssh
-
16
-
-
-
all
-
all
-
tcp
-
ssh
-
-
-
16
-
-
-
all
-
all
-
tcp
-
-
-
ftp
-
16
-
-
-
all
-
all
-
tcp
-
ftp
-
-
-
16
-
-
-
all
-
all
-
tcp
-
-
-
ftp-data
-
8
-
-
-
all
-
all
-
tcp
-
ftp-data
-
-
-
8
-
-
-
-
-
+
Your /etc/shorewall/interfaces file might look like:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
eth0
+
detect
+
dhcp,norfc1918
+
+
+
-
+
eth1
+
192.168.1.127,192.168.1.255
+
+
+
+
+
-
-
-
WARNING: Users have reported that odd routing problems result from
- adding the ESP and AH protocols to the /etc/shorewall/tos
- file.
-
-
/etc/shorewall/blacklist
-
-
Each line in
- /etc/shorewall/blacklist
- contains
- an IP
- address, a MAC address in Shorewall Format
- or
- subnet
- address. Example:
-
-
130.252.100.69 206.124.146.0/24
-
-
Packets from
- hosts
- listed
- in the
- blacklist file
- will be
- disposed of
- according
- to
- the value assigned
- to
- the BLACKLIST_DISPOSITION
- and BLACKLIST_LOGLEVEL variables in
- /etc/shorewall/shorewall.conf.
- Only
- packets arriving
- on interfaces
- that
- have the
- 'blacklist'
- option in
- /etc/shorewall/interfaces
- are
- checked against the
- blacklist. The black list is designed to prevent listed
- hosts/subnets from accessing services on your
- network.
-
-
-
Beginning with Shorewall 1.3.8, the blacklist file has three columns:
-
-
+
+
The '-' in the ZONE column for eth1 tells Shorewall that eth1
+interfaces to multiple zones.
+
Your /etc/shorewall/hosts file might look like:
+
+
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
loc1
+
eth1:192.168.1.0/25
+
+
+
+
+
loc2
+
eth1:192.168.1.128/25
+
+
+
+
+
+
+
Example 2:
+
Your local interface is eth1 and you have two groups of local hosts
+that you want to consider as one zone and you want Shorewall to route
+between them:
-
ADDRESS/SUBNET
- - As described above.
-
PROTOCOL
- - Optional. If specified, only packets specifying
- this protocol will be blocked.
-
PORTS - Optional;
- may only be given if PROTOCOL is tcp, udp or icmp.
-Expressed as a comma-separated list of port numbers or service
- names (from /etc/services). If present, only packets destined
- for the specified protocol and one of the listed ports are blocked.
- When the PROTOCOL is icmp, the PORTS column contains a comma-separated
- list of ICMP type numbers or names (see "iptables -h icmp").
-
IMPORTANT: The Shorewall blacklist file is NOT
- designed to police your users' web browsing --
-to do that, I suggest that you install and configure
-Squid (http://www.squid-cache.org).
-
Your /etc/shorewall/interfaces file might look like:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
eth0
+
detect
+
dhcp,norfc1918
+
+
+
loc
+
+
eth1
+
192.168.1.127,192.168.1.255
+
+
+
+
+
+
+
+
Your /etc/shorewall/hosts file might look like:
+
+
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
loc
+
eth1:192.168.1.0/25
+
+
+
+
+
loc
+
eth1:192.168.1.128/25
+
+
+
+
+
+
+If you are running Shorewall 1.4.6 or later, your hosts file may look
+like:
+
+
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
loc
+
eth1:192.168.1.0/25,192.168.1.128/25
+
+
+
+
+
+
+
+
Nested and Overlapping
+Zones
+
The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow
+you to define nested or overlapping zones. Such overlapping/nested
+zones are allowed and Shorewall processes zones in the order
+that they appear in the /etc/shorewall/zones file. So if
+you have nested zones, you want the sub-zone to appear before
+the super-zone and in the case of overlapping zones, the rules that
+will apply to hosts that belong to both zones is determined by which
+zone appears first in /etc/shorewall/zones.
+
Hosts that belong to more than one zone may be managed by the rules
+of all of those zones. This is done through use of the special CONTINUE policy described below.
+
/etc/shorewall/policy
+Configuration.
+
This file is used to describe the firewall policy regarding
+establishment of connections. Connection establishment is described in
+terms of clients who initiate connections and servers who
+receive those connection requests. Policies defined in
+/etc/shorewall/policy describe which zones are allowed to establish
+connections with other zones.
+
Policies established in /etc/shorewall/policy can be viewed as
+default policies. If no rule in /etc/shorewall/rules applies to a
+particular connection request then the policy from
+/etc/shorewall/policy is applied.
+
Four policies are defined:
-
SUBNET
- - The subnet using VLSM notation (e.g., 192.168.0.0/16).
-
TARGET
- - What to do with packets to/from the
-SUBNET:
-
+
ACCEPT - The connection is allowed.
+
DROP - The connection request is ignored.
+
REJECT - The connection request is rejected with an RST
+(TCP) or an ICMP destination-unreachable packet being returned to the
+client.
+
CONTINUE - The connection is neither ACCEPTed, DROPped
+nor REJECTed. CONTINUE may be used when one or both of the zones named
+in the entry are sub-zones of or intersect with another zone. For more
+information, see below.
+
NONE - (Added in version 1.4.1) - Shorewall should not set
+up any infrastructure for handling traffic from the SOURCE zone to the
+DEST zone. When this policy is specified, the LOG LEVEL and BURST:LIMIT
+ columns must be left blank.
+
+
+
For each policy specified in /etc/shorewall/policy, you can
+indicate that you want a message sent to your system log each time that
+the policy is applied.
+
Entries in /etc/shorewall/policy have four columns as follows:
POLICY - The default policy for connection requests
+from the SOURCE zone to the DESTINATION zone.
+
LOG LEVEL - Optional. If left empty, no log message is
+generated when the policy is applied. Otherwise, this column should
+contain an integer or name indicating a syslog level.
+
LIMIT:BURST - Optional. If left empty, TCP connection
+requests from the SOURCE zone to the DEST zone will not
+be rate-limited. Otherwise, this column specifies the maximum rate at
+which TCP connection requests will be accepted followed by a colon
+(":") followed by the maximum burst size that will be tolerated.
+Example: 10/sec:40 specifies that the maximum rate of TCP
+connection requests allowed will be
+10 per second and a burst of 40 connections will be tolerated.
+Connection requests in excess of these limits will be dropped.
+
+
In the SOURCE and DEST columns, you can enter "all" to indicate all
+zones.
+
The policy file installed by default is as follows:
+
+
+
+
+
SOURCE
+
DEST
+
POLICY
+
LOG LEVEL
+
LIMIT:BURST
+
+
+
loc
+
net
+
ACCEPT
+
+
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
+
+
+
+
This table may be interpreted as follows:
+
+
All connection requests from the local network to hosts on the
+internet are accepted.
+
All connection requests originating from the internet are ignored
+and logged at level KERNEL.INFO.
+
All other connection requests are rejected and logged.
+
+
WARNING:
+
The firewall script processes the
+/etc/shorewall/policy file from top to bottom and uses the first
+applicable policy that it finds. For example, in the following
+policy file, the policy for (loc, loc) connections would be ACCEPT as
+specified in the first entry even though the third entry in the file
+specifies REJECT.
+
+
+
+
+
SOURCE
+
DEST
+
POLICY
+
LOG LEVEL
+
LIMIT:BURST
+
+
+
loc
+
all
+
ACCEPT
+
+
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
+
+
loc
+
loc
+
REJECT
+
info
+
+
+
+
+
+
+
IntraZone Traffic
+Shorewall allows a zone to be associated with more than one interface
+or with multiple networks that interface through a single interface.
+Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from
+a zone to itself provided that there is
+no explicit policy governing traffic from that zone to itself (an
+explicit policy does not specify "all" in either the SOURCE or DEST
+column) and that there are no rules concerning connections from that
+zone to itself. If there is an explicit policy or if there are one or
+more rules, then traffic within the zone is handled just like traffic
+between zones is.
+
Any time that you have multiple interfaces associated with a single
+zone, you should ask yourself if you really want traffic routed between
+those interfaces. Cases where you might not want that behavior are:
+
+
+
Multiple 'net' interfaces to different ISPs. You don't want to
+route traffic from one ISP to the other through your firewall.
+
Multiple VPN clients. You don't necessarily want them to all be
+able to communicate between themselves using your gateway/router.
+
+
+
The CONTINUE policy
+
Where zones are nested or overlapping , the
+CONTINUE policy allows hosts that are within multiple zones to be
+managed under the rules of all of these zones. Let's look at an example:
+
/etc/shorewall/zones:
+
+
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
sam
+
Sam
+
Sam's system at home
+
+
+
net
+
Internet
+
The Internet
+
+
+
loc
+
Loc
+
Local Network
+
+
+
+
+
/etc/shorewall/interfaces:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
-
+
eth0
+
detect
+
dhcp,norfc1918
+
+
+
loc
+
eth1
+
detect
+
+
+
+
+
+
+
/etc/shorewall/hosts:
+
+
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
net
+
eth0:0.0.0.0/0
+
+
+
+
+
sam
+
eth0:206.191.149.197
+
+
+
+
+
+
+
Note that Sam's home system is a member of both the sam
+zone and the net zone and as described above
+, that means that sam must be listed before net in
+/etc/shorewall/zones.
+
/etc/shorewall/policy:
+
+
+
+
+
SOURCE
+
DEST
+
POLICY
+
LOG LEVEL
+
+
+
loc
+
net
+
ACCEPT
+
+
+
+
+
sam
+
all
+
CONTINUE
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
+
+
The second entry above says that when Sam is the client, connection
+requests should first be process under rules where the source zone is sam
+and if there is no match then the connection request should be treated
+under rules where the source zone is net. It is important that
+this policy be listed BEFORE the next policy (net to all).
+
Partial /etc/shorewall/rules:
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
DNAT
+
sam
+
loc:192.168.1.3
+
tcp
+
ssh
+
-
+
+
+
+
+
DNAT
+
net
+
loc:192.168.1.5
+
tcp
+
www
+
-
+
+
+
+
+
...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Given these two rules, Sam can connect to the firewall's internet
+interface with ssh and the connection request will be forwarded to
+192.168.1.3. Like all hosts in the net
+zone, Sam can connect to the firewall's internet interface on TCP port
+80 and the connection request will be forwarded to 192.168.1.5. The
+order of the rules is not significant.
+
Sometimes it is necessary to suppress port
+forwarding for a sub-zone. For example, suppose that all hosts can SSH
+to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam
+connects to the firewall's external IP, he should be connected to the
+firewall itself. Because of the way that Netfilter is constructed, this
+requires two rules as follows:
+
+
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
DNAT
+
sam
+
fw
+
tcp
+
ssh
+
-
+
+
+
+
+
DNAT
+
net!sam
+
loc:192.168.1.3
+
tcp
+
ssh
+
-
+
+
+
+
+
...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The first rule allows Sam SSH access to the firewall. The second
+rule says that any clients from the net zone with the exception of
+those in the 'sam' zone should have their connection port forwarded to
+192.168.1.3. If you need to exclude more than one zone in this way, you
+can list the zones separated by commas (e.g., net!sam,joe,fred). This
+technique also may be used when the ACTION is REDIRECT.
+
/etc/shorewall/rules
+
The /etc/shorewall/rules file defines exceptions to the policies
+established in the /etc/shorewall/policy file. There is one entry in
+/etc/shorewall/rules for each of these rules.
+
+
Shorewall automatically enables firewall->firewall traffic over
+the loopback interface (lo) -- that traffic cannot be regulated using
+rules and any rule that tries to regulate such traffic will generate a
+warning and will be ignored.
+
+
Entries in the file have the following columns:
+
+
ACTION
-
RETURN
- - Process the packet normally thru the rules and
-policies.
-
DROP
- - Silently drop the packet.
-
logdrop
- - Log then drop the packet -- see the RFC1918_LOG_LEVEL
- parameter above.
-
-
+
ACCEPT, DROP, REJECT, CONTINUE. These have the same meaning
+here as in the policy file above.
+
DNAT -- Causes the connection request to be forwarded to the
+system specified in the DEST column (port forwarding). "DNAT" stands
+for "Destination Network Address Translation"
+
DNAT- -- The above ACTION (DNAT) generates two iptables
+rules: 1) and header-rewriting rule in the Netfilter 'nat' table and;
+2) an ACCEPT rule in the Netfilter 'filter' table. DNAT- works like
+DNAT but only generates the header-rewriting rule.
+
+
REDIRECT -- Causes the connection request to be redirected to
+a port on the local (firewall) system.
+
REDIRECT- -- The above ACTION (REDIRECT) generates two
+iptables rules: 1) and header-rewriting rule in the
+Netfilter 'nat' table and; 2) an ACCEPT rule in the Netfilter
+'filter' table. REDIRECT- works like REDIRECT but only generates the
+header-rewriting rule.
+
+
LOG - Log the packet -- requires
+a syslog level (see below).
-
-
+
The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info).
+This
+causes the packet to be logged at the specified level prior to being
+processed according to the specified ACTION. Note: if the ACTION
+is LOG then you MUST specify a syslog level.
+
+The use of DNAT or REDIRECT requires that you have NAT enabled.
+
+
+
SOURCE - Describes the source hosts to which the rule
+applies.. The contents of this field must begin with the name of a zone
+defined in /etc/shorewall/zones, $FW or
+"all". If the ACTION is DNAT or REDIRECT, sub-zones may be excluded
+from the rule by following the initial zone name with "!' and a
+comma-separated list of those sub-zones
+to be excluded. There is an example above.
+
+If the source is not 'all' then the source may be further restricted by
+adding a colon (":") followed by a comma-separated list of qualifiers.
+Qualifiers are may include:
+
+
An interface name - refers to any connection requests
+arriving on the specified interface (example loc:eth4). Beginning with
+Shorwall 1.3.9, the interface name may optionally be followed by a
+colon (":") and an IP address or subnet (examples:
+loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
+
An IP
+address - refers to a connection request from the host with the
+specified address (example net:155.186.235.151). If the ACTION is DNAT,
+this must not be a DNS name.
A subnet - refers to a connection request from any host in
+the specified subnet (example net:155.186.235.0/24).
+
+
+
+
+
DEST - Describes the destination host(s) to which the rule
+applies. May take most of the forms described above
+for SOURCE plus the following two additional forms:
+
+
An IP
+address followed by a colon and the port number that the server
+is listening on (service names from /etc/services are not allowed -
+example loc:192.168.1.3:80).
+
+
A single port number (again, service names are not allowed)
+-- this form is only allowed if the ACTION is REDIRECT and refers to a
+server running on the firewall itself and listening on the specified
+port.
+
+Restrictions:
+
+
MAC addresses may not be specified.
+
In DNAT rules, only IP addresses may be given -- DNS names
+are not permitted.
+
You may not specify both an IP address and an interface name
+in the DEST column.
+
+Unlike in the SOURCE column, a range of IP addresses may be specified
+in the DEST column as <first address>-<last address>. When
+the ACTION is DNAT or DNAT-, connections will be assigned to the
+addresses in the range in a round-robin fashion (load-balancing). This
+feature is available with DNAT rules only with Shorewall 1.4.6 and
+later versions; it is available with DNAT- rules in all versions that
+support DNAT-.
+
+
+
PROTO - Protocol. Must be a protocol name from
+/etc/protocols, a number or "all". Specifies the protocol of the
+connection request.
+
+
+
DEST PORT(S) - Port or port range (<low
+port>:<high port>) being connected to. May only be specified
+if the protocol is tcp, udp or icmp. For icmp, this column's contents
+are interpreted as an icmp type. If you don't want to specify DEST
+PORT(S) but need to include information in one of the columns to the
+right, enter "-" in this
+column. You may give a list of ports and/or port ranges separated by
+commas. Port numbers may be either integers or service names from
+/etc/services.
+
+
+
SOURCEPORTS(S) - May be used to restrict the
+rule to a particular client port or port range (a
+port range is specified as <low port number>:<high port
+number>). If you don't want to restrict client ports
+but want to specify something in the next column, enter "-"
+in this column. If you wish to specify a list of port number or ranges,
+separate the list elements with commas (with no embedded white space).
+Port numbers may be either integers or service names from /etc/services.
+
+
+
ORIGINAL DEST - This column may only be non-empty if the
+ACTION is DNAT or REDIRECT.
+
+If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column is left
+empty, any connection request arriving at the firewall from the SOURCE
+that matches the rule will be forwarded or redirected. This works fine
+for connection requests arriving from the internet where the firewall
+has only a
+single external IP address. When the firewall has multiple external IP
+addresses or when the SOURCE is other than the
+internet, there will usually be a desire for the rule to only
+apply to those connection requests directed to particular IP addresses
+(see Example 2 below for another usage). Those IP
+addresses are specified in the ORIGINAL DEST column as a
+comma-separated
+list.
+
+The IP address(es) may be optionally followed by ":" and a second IP
+address. This latter address, if present, is used as the source address
+for packets forwarded to the server (This is called "Source NAT" or
+SNAT.
+
+If this list begins with "!" then the rule will only apply if the
+original destination address matches none of the addresses listed.
+
+ Note: When using SNAT, it is a
+good idea to qualify the source with an IP address or subnet.
+Otherwise, it is likely that SNAT will occur on connections other than
+those described in the rule. The reason for this is that SNAT occurs in
+the Netfilter POSTROUTING hook where it is not possible to restrict the
+scope of a rule by incoming interface.
+
+ Example: DNAT loc:192.168.1.0/24 loc:192.168.1.3 tcp www
+- 206.124.146.179:192.168.1.3
+
+ If SNAT is not used (no ":" and second IP address), the
+original source address is used. If you want any destination address to
+match the rule but want to specify SNAT, simply use a colon followed by
+the SNAT address.
-
-
/etc/shorewall/routestopped (Added in Version
- 1.3.4)
-
-
This file defines the hosts that are accessible from the firewall when
- the firewall is stopped. Columns in the file
-are:
-
+
Example 1. You wish to forward
+all ssh connection requests from the internet to local system
+192.168.1.3.
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
DNAT
+
net
+
loc:192.168.1.3
+
tcp
+
ssh
+
+
+
+
+
+
+
+
+
Example 2. You want to redirect all local www connection
+requests EXCEPT those to your own http server (206.124.146.177) to a
+Squid transparent proxy running on the firewall and listening on port
+3128. Squid will of course require access to remote web servers. This
+example shows yet another use for the ORIGINAL DEST column; here,
+connection requests that were NOT (notice
+the "!") originally destined to 206.124.146.177 are redirected to
+local port 3128.
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
REDIRECT
+
loc
+
3128
+
tcp
+
www
+
-
+
+
!206.124.146.177
+
+
+
ACCEPT
+
fw
+
net
+
tcp
+
www
+
+
+
+
+
+
+
+
+
Example 3. You want to run a web server at 155.186.235.222
+in your DMZ and have it accessible remotely and locally. the DMZ is
+managed by Proxy ARP or by classical sub-netting.
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
ACCEPT
+
net
+
dmz:155.186.235.222
+
tcp
+
www
+
-
+
+
+
+
+
ACCEPT
+
loc
+
dmz:155.186.235.222
+
tcp
+
www
+
+
+
+
+
+
+
+
+
Example 4. You want to run wu-ftpd on 192.168.2.2 in your
+masqueraded DMZ. Your internet interface address is 155.186.235.151 and
+you want the FTP server to be accessible from the internet in addition
+to the local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note
+that since the server is in the 192.168.2.0/24 subnetwork, we can
+assume that access to the server from that subnet will not involve the
+firewall (but see FAQ 2). Note that unless
+you have more than one external IP address, you can leave the ORIGINAL
+DEST column blank in the first rule. You cannot leave it blank in the
+second rule though because then all ftp connections originating
+in the local subnet 192.168.1.0/24 would be sent to 192.168.2.2
+regardless of the site that the user was trying to connect to. That
+is clearly not what you want .
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
DNAT
+
net
+
dmz:192.168.2.2
+
tcp
+
ftp
+
+
+
+
+
+
+
DNAT
+
loc:192.168.1.0/24
+
dmz:192.168.2.2
+
tcp
+
ftp
+
-
+
155.186.235.151
+
+
+
+
+
If you are running wu-ftpd, you should restrict the range of passive
+in your /etc/ftpaccess file. I only need a few simultaneous FTP
+sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry
+is appropriate:
+
+
passive ports 0.0.0.0/0 65500 65534
+
+
If you are running pure-ftpd, you would include "-p 65500:65534" on
+the pure-ftpd runline.
+
The important point here is to ensure that the port range used for
+FTP passive connections is unique and will not overlap with any usage
+on the firewall system.
+
Example 5. You wish to allow unlimited DMZ access to the
+host with MAC address 02:00:08:E3:FA:55.
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
ACCEPT
+
loc:~02-00-08-E3-FA-55
+
dmz
+
all
+
+
+
+
+
+
+
+
+
+
+Example 6. You wish to allow access to the SMTP server in your
+DMZ from all zones.
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DEST
+
+
PROTO
+
+
DEST
+PORT(S)
+
+
SOURCE
+PORT(S)
+
+
ORIGINAL
+DEST
+
+
+
+
ACCEPT
+
+
all
+
+
dmz
+
+
tcp
+
+
25
+
+
+
+
+
+
+
+
+
+Note: When 'all' is used as a source or destination, intra-zone traffic
+is not affected. In this example, if there were two DMZ interfaces then
+the above rule would NOT enable SMTP traffic between
+hosts on these interfaces.
+
+Example 7. Your firewall's external interface has several IP
+addresses but you only want to accept SSH connections on address
+206.124.146.176.
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DEST
+
+
PROTO
+
+
DEST
+PORT(S)
+
+
SOURCE
+PORT(S)
+
+
ORIGINAL
+DEST
+
+
+
+
ACCEPT
+
+
net
+
+
fw:206.124.146.176
+
+
tcp
+
+
22
+
+
+
+
+
+
+
+
+
+Example 8 (For advanced users running Shorewall version 1.3.13 or
+later). From the internet, you with to forward tcp port 25
+directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your
+DMZ. You also want to allow access from the internet directly to tcp
+port 25 on 192.0.2.177.
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DEST
+
+
PROTO
+
+
DEST
+PORT(S)
+
+
SOURCE
+PORT(S)
+
+
ORIGINAL
+DEST
+
+
+
+
DNAT-
+
+
net
+
+
dmz:192.0.2.177
+
+
tcp
+
+
25
+
+
0
+
+
192.0.2.178
+
+
+
+
DNAT-
+
+
net
+
+
dmz:192.0.2.177
+
+
tcp
+
+
25
+
+
0
+
+
192.0.2.179
+
+
+
+
ACCEPT
+
+
net
+
+
dmz:192.0.2.177
+
+
tcp
+
+
25
+
+
+
+
+
+
+
+
+
+Using "DNAT-" rather than "DNAT" avoids two extra copies of the third
+rule from being generated.
+
+Example 9 (Shorewall version 1.4.6 or later). You have 9
+http servers behind a Shorewall firewall and you want connection
+requests to be distributed among your servers. The servers are
+192.168.1.101-192.168.1.109.
+
+
Shorewall allows definition of rules that apply between all zones.
+By default, these rules are defined in the file
+/etc/shorewall/common.def but may be modified to suit individual
+requirements. Rather than modify /etc/shorewall/common.def, you should
+copy that file to /etc/shorewall/common and modify that file.
+
The /etc/shorewall/common file is expected to contain iptables
+commands; rather than running iptables directly, you should run it
+indirectly using the Shorewall function 'run_iptables'. That way, if
+iptables encounters an error, the firewall will be safely stopped.
+
/etc/shorewall/masq
+
The /etc/shorewall/masq file is used to define classical IP
+Masquerading and Source Network Address Translation (SNAT). There is
+one entry in the file for each subnet that you want to masquerade. In
+order to make use of this feature, you must have NAT
+enabled .
+
Columns are:
-
INTERFACE
- - The firewall interface through which the
- host(s) comminicate with the firewall.
-
HOST(S)
- - (Optional) - A comma-separated list of IP/Subnet
- addresses. If not supplied or supplied as "-" then 0.0.0.0/0
- is assumed.
-
+
INTERFACE - The interface that will masquerade the
+subnet; this is normally your internet interface. This interface name
+can be optionally qualified by adding ":" and a subnet or host IP. When
+this qualification is added, only packets addressed to that host or
+subnet will be masqueraded. Beginning with Shorewall version 1.3.14, if
+you have set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf,
+you can cause Shorewall to create an alias label of the form interfacename:digit
+ (e.g., eth0:0) by placing
+that label in this column. See example 5 below. Alias labels
+created in this way allow the alias to be visible to the ipconfig
+utility. THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR
+AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.
+
SUBNET - The subnet that you want to have masqueraded
+through the INTERFACE. This may be expressed as a single IP address, a
+subnet or an interface name. In the latter instance, the interface must
+be configured and started before Shorewall is started as Shorewall will
+determine the subnet based on information obtained from the 'ip'
+utility. When using Shorewall 1.3.13 or
+earlier, when an interface name is specified, Shorewall will only
+masquerade traffic from the first subnetwork on the named interface; if
+the interface interfaces to more that one subnetwork, you will need to
+add additional entries to this file for each of those other
+subnetworks. Beginning with Shorewall 1.3.14, shorewall will
+masquerade/SNAT traffic from any host that is routed through the named
+interface.
+
+The subnet may be optionally followed by "!' and a comma-separated list
+of addresses and/or subnets that are to be excluded from masquerading.
+
ADDRESS - The source address to be used for outgoing
+packets. This column is optional and if left blank, the current primary
+IP address of the interface in the first column is used. If you have a
+static IP on that interface, listing it here makes processing of output
+packets a little less expensive for the firewall. If you specify an
+address in this column, it must be an IP address configured on the
+INTERFACE or you must have
+ADD_SNAT_ALIASES enabled in /etc/shorewall/shorewall.conf.
-
-
Example: When your firewall is stopped, you want firewall accessibility
- from local hosts 192.168.1.0/24 and from your
-DMZ. Your DMZ interfaces through eth1 and your local
-hosts through eth2.
-
-
-
+
Example 1: You have eth0 connected to a cable modem and
+eth1 connected to your local subnetwork 192.168.9.0/24. Your
+/etc/shorewall/masq file would look like:
+
+
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
eth0
+
192.168.9.0/24
+
+
+
+
+
+
+
Example 2: You have a number of IPSEC tunnels through ipsec0
+and you want to masquerade traffic from your 192.168.9.0/24 subnet to
+the remote subnet 10.1.0.0/16 only.
+
+
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
ipsec0:10.1.0.0/16
+
192.168.9.0/24
+
+
+
+
+
+
+
Example 3: You have a DSL line connected on eth0 and a local
+network (192.168.10.0/24) connected to eth1. You want all local->net
+connections to use source address 206.124.146.176.
+
+
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
eth0
+
192.168.10.0/24
+
206.124.146.176
+
+
+
+
+
Example 4: Same as example 3 except that you wish to
+exclude 192.168.10.44 and 192.168.10.45
+from the SNAT rule.
+
+
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
eth0
+
192.168.10.0/24!192.168.10.44,192.168.10.45
+
206.124.146.176
+
+
+
+
+Example 5 (Shorewall version >= 1.3.14): You have a second
+IP address (206.124.146.177) assigned to you and wish to use it for
+SNAT of the subnet 192.168.12.0/24. You want to give that address the
+name eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
+
+
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
eth0:0
+
192.168.12.0/24
+
206.124.146.177
+
+
+
+
+
/etc/shorewall/proxyarp
+
If you want to use proxy ARP on an entire sub-network, I suggest
+that you look at
+http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. If you decide to
+use the technique described in that HOWTO, you can set the proxy_arp
+flag for an interface (/proc/sys/net/ipv4/conf/<interface>/proxy_arp)
+by including the proxyarp option in the interface's record in /etc/shorewall/interfaces. When using Proxy
+ARP sub-netting, you do NOT include any entries in
+/etc/shorewall/proxyarp.
+
The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for
+enabling Proxy ARP on a
+small set of systems
+since you need
+one entry in this file for each system using proxy ARP. Columns are:
+
+
ADDRESS - address of the system.
+
INTERFACE - the interface that connects to the system. If
+the interface is obvious from the subnetting, you
+may enter "-" in this column.
+
EXTERNAL - the external interface that you want to honor
+ARP requests for the ADDRESS specified in the first column.
+
HAVEROUTE - If you already have a route through INTERFACE
+to ADDRESS, this column should contain "Yes" or "yes". If you want
+Shorewall to add the route, the column should contain "No" or "no".
+
+
Note: After you have made a change to the
+/etc/shorewall/proxyarp file, you may need to flush the ARP cache of
+all routers on the LAN segment connected to the interface specified in
+the EXTERNAL column of the change/added entry(s). If you are having
+problems communicating between an individual host (A) on that segment
+and a system whose entry has changed, you may need to flush the ARP
+cache on host A as well.
+
ISPs typically have ARP configured with
+long TTL (hours!) so if your ISPs router has a stale cache entry (as
+seen using "tcpdump -nei <external interface> host <IP
+addr>"), it may take a long
+while to time out. I personally have had to contact my ISP and ask them
+to delete a stale entry in order to restore a system to working order
+after
+changing my proxy ARP settings.
+
Example: You have public IP addresses 155.182.235.0/28. You
+configure your firewall as follows:
+
+
eth0 - 155.186.235.1 (internet connection)
+
eth1 - 192.168.9.0/24 (masqueraded local systems)
+
eth2 - 192.168.10.1 (interface to your DMZ)
+
+
In your DMZ, you want to install a Web/FTP server with public
+address 155.186.235.4. On the Web server, you subnet just like the
+firewall's eth0 and you configure 155.186.235.1 as the default gateway.
+In your /etc/shorewall/proxyarp file, you will have:
+
+
+
+
+
ADDRESS
+
INTERFACE
+
EXTERNAL
+
HAVEROUTE
+
+
+
155.186.235.4
+
eth2
+
eth0
+
No
+
+
+
+
+
Note: You may want to configure the servers in your DMZ with a
+subnet that is smaller than the subnet of your internet interface. See
+the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/)
+for details. In this case you will want to place "Yes" in the HAVEROUTE
+column.
+
Warning: Do not use Proxy ARP
+and FreeS/Wan
+on the same system unless you are prepared to suffer the consequences.
+If you start or restart Shorewall with an IPSEC tunnel active, the
+proxied IP addresses are mistakenly assigned to the IPSEC tunnel device
+(ipsecX) rather than to the interface that you specify in the INTERFACE
+column of /etc/shorewall/proxyarp. I haven't had the time to debug this
+problem so I can't say if it is a bug in the Kernel or in FreeS/Wan.
+
You might be able to work around this problem using the
+following (I haven't tried it):
+
In /etc/shorewall/init, include:
+
qt service ipsec stop
+
In /etc/shorewall/start, include:
+
qt service ipsec start
+
/etc/shorewall/nat
+
The /etc/shorewall/nat file is used to define static NAT. There is
+one entry in the file for each static NAT relationship that you wish to
+define. In order to make use of this feature, you must have NAT enabled .
+
IMPORTANT: If all you want to do is
+forward ports to servers behind your firewall, you do NOT want to use
+static NAT. Port forwarding can be accomplished with simple entries in
+the rules file. Also, in most cases Proxy ARP provides a superior solution to static
+NAT because the internal systems are accessed using the same IP address
+internally and externally.
+
Columns in an entry are:
+
+
EXTERNAL - External IP address - This should NOT be
+the primary IP address of the interface named in the next column.
+
INTERFACE - Interface that you want the EXTERNAL IP
+address to appear on. Beginning with Shorewall version 1.3.14, if you
+have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf,
+ you can specify an alias label of the form interfacename:digit
+ (e.g., eth0:0) and Shorewall will create the alias
+with that label. Alias labels created in this way allow the
+alias to be visible to the ipconfig utility. THAT IS THE ONLY THING
+THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE
+ELSE IN YOUR SHOREWALL CONFIGURATION.
+
INTERNAL - Internal IP address.
+
ALL INTERFACES - If Yes or yes (or left empty), NAT will
+be effective from all hosts. If No or no then NAT will be effective
+only through the interface named in the INTERFACE column.
+
LOCAL - If Yes or yes and the ALL INTERFACES column
+contains Yes or yes, NAT will be effective from the firewall system. Note:
+ For this to work, you must be
+running kernel 2.4.19 or later and iptables 1.2.6a or later and you
+must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel.
The /etc/shorewall/tunnels file allows you to define IPSec, GRE,
+IPIP, OpenVPN, PPTP and
+6to4.tunnels with end-points on your firewall. To use ipsec, you must
+install version 1.9, 1.91 or the current FreeS/WAN development
+snapshot.
+
+
Note: For kernels 2.4.4 and above, you will need to use version
+1.91 or a development snapshot as patching with version 1.9 results in
+kernel compilation errors.
This file is used to set the following firewall parameters:
+
+
ADMINISABSENTMINDED - Added at version 1.4.7
+The value of this variable affects Shorewall's stopped state. When
+ADMINISABSENTMINDES=No,
+only traffic to/from those addresses listed in
+/etc/shorewall/routestopped
+is accepted when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in
+addition
+to traffic to/from addresses in /etc/shorewall/routestopped,
+ connections
+that were active when Shorewall stopped continue to work and all new
+connections
+from the firewall system itself are allowed. If this variable is not
+set
+or is given the empty value then ADMINISABSENTMINDED=No is assumed.
+
+
SHOREWALL_SHELL - Added at version 1.4.6
+This parameter is used to specify the shell program to be used to
+interpret the firewall script (/usr/share/shorewall/firewall). If not
+specified or specified as a null value, /bin/sh is assumed.
+
+
LOGFORMAT - Added at version 1.4.4.
+The value of this variable generate the --log-prefix setting for
+Shorewall logging rules. It contains a 'printf' formatting template
+which accepts three arguments (the chain name, logging rule number
+(optional) and the disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it
+as:
+
+ LOGFORMAT="fp=%s:%d a=%s "
+
+If the LOGFORMAT value contains the substring '%d' then the logging
+rule number is calculated and formatted in that position; if that
+substring is not included then the rule number is not included. If not
+supplied or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:" is
+assumed.
+
+ CAUTION: /sbin/shorewall uses the leading part of the
+LOGFORMAT string (up to but not including the first '%')
+to find log messages in the 'show log', 'status' and 'hits' commands.
+This part should not be omitted (the LOGFORMAT should not begin with
+"%") and the leading part should be sufficiently unique for
+/sbin/shorewall to identify Shorewall messages.
+
+
CLEAR_TC - Added at version 1.3.13
+If this option is set to 'No' then Shorewall won't clear the current
+traffic control rules during [re]start. This setting is intended for
+use by people that prefer to configure traffic shaping when the network
+interfaces come up rather than when the firewall is started. If that is
+what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not
+supply an /etc/shorewall/tcstart file. That way, your traffic shaping
+rules can still use the 'fwmark' classifier based on packet marking
+defined in /etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is
+assumed.
+
+
MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
+If your kernel has a FORWARD chain in the mangle table, you may set
+MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules file to occur in that
+chain rather than in the PREROUTING chain. This permits you to mark
+inbound traffic based on its destination address when SNAT or
+Masquerading are in use. To determine if your kernel has a FORWARD
+chain in the mangle table, use the "/sbin/shorewall show mangle"
+command; if a FORWARD chain is displayed then your kernel will support
+this option. If this option is not specified or if it is given the
+empty value (e.g., MARK_IN_FORWARD_CHAIN="") then
+MARK_IN_FORWARD_CHAIN=No is assumed.
+
+
RFC1918_LOG_LEVEL
+- Added at version 1.3.12
+This parameter determines
+the level at which packets logged under the 'norfc1918' mechanism are
+logged. The value must be a valid syslog
+level and if no level is given, then info is assumed. Prior to
+Shorewall version 1.3.12, these packets are always logged at the info
+level.
+
TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
+Determines the disposition
+of TCP packets that fail the checks enabled by the tcpflags interface option and
+must have a value of ACCEPT (accept the packet), REJECT (send
+an RST response) or DROP (ignore the packet). If not set
+or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then
+TCP_FLAGS_DISPOSITION=DROP is assumed.
+
TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
+Determines the syslog level for
+logging packets that fail the checks enabled by the tcpflags interface option.The value must be a
+valid syslogd log level. If you don't want to log these packets, set to
+the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
+
+
MACLIST_DISPOSITION - Added in Version 1.3.10
+Determines the disposition of connections requests that fail MAC Verification and must have the
+value ACCEPT (accept the connection request anyway), REJECT (reject the
+connection request) or DROP (ignore the connection request). If not set
+or if set to the empty value (e.g., MACLIST_DISPOSITION="") then
+MACLIST_DISPOSITION=REJECT is assumed.
+
MACLIST_LOG_LEVEL - Added in Version 1.3.10
+Determines the syslog level for
+logging connection requests that fail MAC
+Verification. The value must be a valid syslogd log level. If you
+don't want to log these connection requests, set to the empty value
+(e.g., MACLIST_LOG_LEVEL="").
+
+
NEWNOTSYN - Added in Version 1.3.8
+When set to "Yes" or "yes", Shorewall will filter TCP packets that are
+not part of an established connention and that are not SYN packets (SYN
+flag on - ACK flag off). If set to "No", Shorewall will silently drop
+such packets. If not set or set to the empty value (e.g.,
+"NEWNOTSYN="), NEWNOTSYN=No is assumed.
+
+If you have a HA
+setup with failover to another firewall, you should have NEWNOTSYN=Yes
+on both firewalls. You should also select NEWNOTSYN=Yes if you have
+asymmetric routing.
+
+
LOGNEWNOTSYN - Added in Version 1.3.6
+Beginning with version 1.3.6, Shorewall drops non-SYN TCP packets that
+are not part of an existing connection. If you would like to log these
+packets, set LOGNEWNOTSYN to the syslog
+level at which you want the packets logged. Example:
+LOGNEWNOTSYN=ULOG|
+
+ Note: Packets logged under this option are usually the
+result of broken remote IP stacks rather than the result of any
+sort of attempt to breach your firewall.
+
DETECT_DNAT_ADDRS - Added in Version 1.3.4
+If set to "Yes" or "yes", Shorewall will
+detect the first IP address of the interface to the source
+zone and will include this address in DNAT rules as the original
+destination IP address. If set to "No" or "no", Shorewall will
+not detect this address and any destination IP address will
+match the DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes"
+is assumed.
+
+
MULTIPORT - (Removed in version 1.4.6 -- the value of this
+parameter is now automatically detected by Shorewall)
+If set to "Yes" or "yes", Shorewall will use the Netfilter multiport
+facility. In order to use this facility, your kernel must have
+multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is
+used, Shorewall will generate a single rule from each record in the
+/etc/shorewall/rules file that meets these criteria:
+
+
No port range(s) specified
+
Specifies 15 or fewer ports
+
+
Rules not meeting those criteria will continue to generate an
+individual rule for each listed port or port range.
+
+
NAT_BEFORE_RULES
+If set to "No" or "no", port forwarding rules can override the contents
+of the /etc/shorewall/nat file. If set to "Yes" or
+"yes", port forwarding rules cannot override static NAT. If not set or
+set to an empty value,
+"Yes" is assumed.
+
FW
+ This parameter specifies the name of the firewall zone. If not
+set or if set to an empty string, the value "fw" is assumed.
+
SUBSYSLOCK
+This parameter should be set to the name of a file that the firewall
+should create if it starts successfully and remove when it stops.
+Creating and removing this file allows Shorewall to work with your
+distribution's initscripts. For RedHat, this should be set to
+/var/lock/subsys/shorewall. For Debian, the value is
+/var/state/shorewall and in LEAF it is /var/run/shorwall. Example:
+SUBSYSLOCK=/var/lock/subsys/shorewall.
+
STATEDIR
+This parameter specifies the name of a directory where Shorewall stores
+state information. If the directory doesn't exist when Shorewall
+starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.
+
+ NOTE: If you change the STATEDIR variable while the firewall
+is running, create the new directory if necessary then copy the
+contents of the old directory to the new
+directory.
+
MODULESDIR
+This parameter specifies the directory where your kernel netfilter
+modules may be found. If you leave the variable empty, Shorewall will
+supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
+
LOGRATE and LOGBURST
+These
+parameters set the match rate and initial burst size for logged
+packets. Please see the iptables man page for a description of the
+behavior of these parameters (the iptables option --limit is set by
+LOGRATE and --limit-burst is set by LOGBURST). If both parameters are
+set empty,
+no rate-limiting will occur.
+
+Example:
+LOGRATE=10/minute
+LOGBURST=5
+
+
LOGFILE
+This parameter tells the /sbin/shorewall program where to look for
+Shorewall messages when processing the "show log", "monitor", "status"
+and "hits" commands. If not assigned or if assigned an empty value,
+/var/log/messages is assumed.
+
NAT_ENABLED (Removed in Shorewall 1.4.6 -- the value of
+this parameter is now automatically detected by Shorewall)
+This parameter determines whether Shorewall supports NAT operations.
+NAT operations include:
+
+Static NAT
+Port Forwarding
+Port Redirection
+Masquerading
+
+If the parameter has no value or has a value of "Yes" or "yes" then NAT
+is enabled. If the parameter has a value of "no" or "No" then NAT is
+disabled.
+
+
MANGLE_ENABLED (Removed in Shorewall 1.4.6 -- the value
+of this parameter is now automatically detected by Shorewall)
+This parameter determines if packet mangling is enabled. If the
+parameter has no value or has a value of "Yes" or "yes" than packet
+mangling is enabled. If the parameter has a value of "no" or "No" then
+packet mangling is disabled. If packet mangling is disabled, the
+/etc/shorewall/tos file is ignored.
+
+
IP_FORWARDING
+This parameter determines whether Shorewall enables or disables IPV4
+Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are:
+
+On or on - packet forwarding will be enabled.
+Off or off - packet forwarding will be disabled.
+Keep or keep - Shorewall will neither enable nor disable packet
+forwarding.
+
+If this variable is not set or is given an empty value (IP_FORWARD="")
+then IP_FORWARD=On is assumed.
+
+
ADD_IP_ALIASES
+This parameter determines whether Shorewall automatically adds the external
+ address(es) in /etc/shorewall/nat . If the
+variable is set to "Yes" or "yes" then Shorewall automatically adds
+these aliases. If it is set to "No" or "no", you must add these aliases
+yourself using your distribution's network configuration tools. RESTRICTION:
+ Shorewall versions before 1.4.6 can only add addresses to the
+first subnetwork configured on an interface.
+
+If this variable is not set or is given an empty value
+(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
+
ADD_SNAT_ALIASES
+This parameter determines whether Shorewall automatically adds the SNAT
+ ADDRESS in /etc/shorewall/masq. If
+the variable is set to "Yes" or "yes" then Shorewall automatically adds
+these addresses. If it is set
+to "No" or "no", you must add these addresses yourself using your
+distribution's network configuration tools. RESTRICTION: Shorewall
+versions before 1.4.6 can only
+add addresses to the first subnetwork configured on an interface.
+
+If this variable is not set or is given an empty value
+(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
+
+
LOGUNCLEAN
+This parameter determines the logging level of mangled/invalid packets
+controlled by the 'dropunclean and logunclean'
+interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets
+selected by 'dropclean' are dropped silently ('logunclean' packets are
+logged under the 'info' log level). Otherwise, these packets are logged
+at the specified level (Example: LOGUNCLEAN=debug).
+
BLACKLIST_DISPOSITION
+This parameter determines the disposition of packets from blacklisted
+hosts. It may have the value DROP if the packets are to be dropped or
+REJECT if the packets are to be replied with an ICMP port unreachable
+reply or a TCP RST (tcp only). If you do not assign a value or if you
+assign an empty value then DROP is assumed.
+
BLACKLIST_LOGLEVEL
+This paremter determines if packets from blacklisted hosts are logged
+and it determines the syslog level that they are to be logged at. Its
+value is a syslog level (Example:
+BLACKLIST_LOGLEVEL=debug). If you do
+not assign a value or if you assign an empty value then packets from
+blacklisted hosts are not logged.
+
CLAMPMSS
+This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter
+and is usually required
+when your internet connection is through PPPoE or PPTP. If set to "Yes"
+or "yes", the feature is enabled. If left blank or set to "No" or "no",
+the feature is not enabled. Note: This option requires
+CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
+
ROUTE_FILTER
+If this parameter is given the value "Yes" or "yes" then route
+filtering (anti-spoofing) is enabled on all network interfaces. The
+default value is "no".
+
+
/etc/shorewall/modules Configuration
+
The file /etc/shorewall/modules contains commands for loading the
+kernel modules required by Shorewall-defined firewall rules. Shorewall
+will source this file during start/restart provided that it exists and
+that the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).
+
The file that is released with Shorewall calls the Shorewall
+function "loadmodule" for the set of modules that I load.
+
The loadmodule function is called as follows:
+
+
loadmodule <modulename> [ <module
+parameters> ]
+
+
where
+
+
<modulename>
+
+
is the name of the modules without the trailing ".o" (example
+ip_conntrack).
+
+
<module parameters>
+
+
Optional parameters to the insmod utility.
+
+
+
The function determines if the module named by <modulename>
+ is already loaded and if not then the function determines if the
+".o" file corresponding to the module exists in the moduledirectory;
+if so, then the following command is executed:
If the file doesn't exist, the function determines of the ".o.gz"
+file corresponding to the module exists in the moduledirectory.
+If
+it does, the function assumes that the running configuration supports
+compressed modules and execute the following command:
The /etc/shorewall/tos file allows you to set the Type of Service
+field in packet headers based on packet source, packet destination,
+protocol, source port and destination port. In order for this file to
+be processed by Shorewall, you must have mangle
+support enabled .
+
Entries in the file have the following columns:
+
+
SOURCE -- The source zone. May be qualified by following
+the zone name with a colon (":") and either an IP address, an IP
+subnet, a MAC address in Shorewall Format or the
+name of an interface. This column may also contain the name
+of the firewall zone to indicate packets originating on the
+firewall itself or "all" to indicate any source.
+
DEST -- The destination zone. May be qualified by
+following the zone name with a colon (":") and either an IP address or
+an IP subnet. Because packets are marked prior to routing, you may not
+specify the name of an interface. This column may also contain "all" to
+indicate any destination.
+
PROTOCOL -- The name of a protocol in /etc/protocols or
+the protocol's number.
+
SOURCE PORT(S) -- The source port or a port range. For
+all ports, place a hyphen ("-") in this column.
+
DEST PORT(S) -- The destination port or a port range. To
+indicate all ports, place a hyphen ("-") in this column.
+
TOS -- The type of service. Must be one of the following:
The /etc/shorewall/tos file that is included with Shorewall
+contains the following entries.
+
+
+
+
+
SOURCE
+
DEST
+
PROTOCOL
+
SOURCE
+PORT(S)
+
DEST PORT(S)
+
TOS
+
+
+
all
+
all
+
tcp
+
-
+
ssh
+
16
+
+
+
all
+
all
+
tcp
+
ssh
+
-
+
16
+
+
+
all
+
all
+
tcp
+
-
+
ftp
+
16
+
+
+
all
+
all
+
tcp
+
ftp
+
-
+
16
+
+
+
all
+
all
+
tcp
+
-
+
ftp-data
+
8
+
+
+
all
+
all
+
tcp
+
ftp-data
+
-
+
8
+
+
+
+
+
WARNING: Users have reported that odd routing problems
+result from adding the ESP and AH protocols to the /etc/shorewall/tos
+file.
+
/etc/shorewall/blacklist
+
Each line in /etc/shorewall/blacklist contains an IP address, a MAC
+address in Shorewall Format
+or subnet address. Example:
+
130.252.100.69 206.124.146.0/24
+
Packets from hosts listed in the blacklist file will
+be disposed of according to the value assigned to the BLACKLIST_DISPOSITION
+and BLACKLIST_LOGLEVEL variables in
+/etc/shorewall/shorewall.conf. Only packets arriving on interfaces that
+have the 'blacklist' option in
+/etc/shorewall/interfaces are checked against the blacklist. The black
+list is designed to prevent listed hosts/subnets from accessing
+services on your network.
+
+
Beginning with Shorewall 1.3.8, the blacklist file has three columns:
+
+
+
ADDRESS/SUBNET - As described above.
+
PROTOCOL - Optional. If specified, only packets specifying
+this protocol will be blocked.
+
PORTS - Optional; may only be given if PROTOCOL is tcp,
+udp or icmp. Expressed as a comma-separated list of port
+numbers or service names (from /etc/services). If present, only packets
+destined for the specified protocol and one
+of the listed ports are blocked. When the PROTOCOL is icmp, the PORTS
+column contains a comma-separated list of ICMP type numbers or names
+(see "iptables -h icmp").
+
IMPORTANT: The Shorewall blacklist file is NOT
+designed to police your users' web browsing -- to do that, I suggest
+that you install and configure Squid (http://www.squid-cache.org).
SUBNET - The subnet using VLSM notation (e.g.,
+192.168.0.0/16).
+
TARGET- What to do with packets to/from the
+SUBNET:
+
+
RETURN - Process the packet normally thru the rules
+and policies.
+
DROP - Silently drop the packet.
+
logdrop - Log then drop the packet -- see the RFC1918_LOG_LEVEL parameter above.
+
+
+
+
/etc/shorewall/routestopped (Added in
+Version 1.3.4)
+
This file defines the hosts that are accessible from the firewall
+when the firewall is stopped. Columns in the file are:
+
+
INTERFACE - The firewall interface through which the
+host(s) comminicate with the firewall.
+
HOST(S) - (Optional) - A comma-separated list of
+IP/Subnet addresses. If not supplied or supplied as "-" then 0.0.0.0/0
+is assumed.
+
+
Example: When your firewall is stopped, you want firewall
+accessibility from local hosts 192.168.1.0/24 and from your DMZ. Your
+DMZ interfaces through eth1 and your local hosts through eth2.
-
+ to www.mydomain.com (IP 130.151.100.69)
+to system 192.168.1.5 in my local network. External
+ clients can browse http://www.mydomain.com but
+ internal clients can't.
+
-
+ subnet and I use static NAT to
+assign non-RFC1918 addresses to hosts in Z.
+Hosts in Z cannot communicate with each other using their
+ external (non-RFC1918 addresses) so they can't access
+each other using their DNS names.
+
-
+ and it has an internel web server that
+allows me to configure/monitor it but as expected
+if I enable rfc1918 blocking for my eth0 interface,
+ it also blocks the cable modems web server.
+
-
+ IP addresses, my ISP's DHCP server has
+an RFC 1918 address. If I enable RFC 1918 filtering
+ on my external interface, my DHCP client cannot renew
+ its lease.
+
1. I want to forward UDP port 7777 to
- my my personal PC with IP address 192.168.1.5.
- I've looked everywhere and can't find how to
-do it.
-
+ my my personal PC with IP address 192.168.1.5.
+ I've looked everywhere and can't find how to
+ do it.
+
Answer: The first example in the rules file documentation shows how to
- do port forwarding under Shorewall. The format
- of a port-forwarding rule to a local system is as
- follows:
-
-
+ do port forwarding under Shorewall. The
+format of a port-forwarding rule to a local system
+is as follows:
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE
- PORT
-
ORIG.
- DEST.
-
-
-
DNAT
-
net
-
loc:<local
- IP address>[:<local port>]
-
<protocol>
-
<port
- #>
-
-
-
-
-
-
-
-
-
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
SOURCE PORT
+
+
ORIG. DEST.
+
+
+
+
+
+
DNAT
+
+
net
+
+
loc:<local IP address>[:<local
+ port>]
+
+
<protocol>
+
+
<port #>
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
So to forward UDP port 7777 to internal system 192.168.1.5,
- the rule is:
-
-
+ the rule is:
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE
- PORT
-
ORIG.
- DEST.
-
-
-
DNAT
-
net
-
loc:192.168.1.5
-
udp
-
7777
-
-
-
-
-
-
-
-
-
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
SOURCE PORT
+
+
ORIG. DEST.
+
+
+
+
+
+
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:
-
-
+ you want to forward requests directed to a particular
+ address ( <external IP> ) on your firewall
+ to an internal system:
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE
- PORT
-
ORIG.
- DEST.
-
-
-
DNAT
-
net
-
loc:<local
- IP address>[:<local port>]
-
<protocol>
-
<port
- #>
-
-
-
<external
- IP>
-
-
-
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
SOURCE PORT
+
+
ORIG. DEST.
+
+
+
+
+
+
DNAT
+
+
net
+
+
loc:<local IP address>[:<local
+ port>]
+
+
<protocol>
+
+
<port #>
+
+
-
+
+
<external IP>
+
+
+
+
+
-
- Finally, if you need to forward a range of
-ports, in the PORT column specify the range as low-port:high-port.
-
+
+ Finally, if you need to forward a range
+of ports, in the PORT column specify the range as low-port:high-port.
+
1a. Ok -- I followed those instructions
- but it doesn't work
-
+ but it doesn't work
+
Answer: That is usually the result of one of three
- things:
-
+ things:
+
-
You
- are trying to test from inside your firewall (no, that
- won't work -- see FAQ #2).
-
You
- have a more basic problem with your local system such
- as an incorrect default gateway configured (it should
- be set to the IP address of your firewall's internal
-interface).
-
Your ISP is blocking that particular port inbound.
-
-
+
You
+ are trying to test from inside your firewall (no,
+that won't work -- see FAQ #2).
+
You
+ have a more basic problem with your local system
+such as an incorrect default gateway configured (it
+should be set to the IP address of your firewall's internal
+ interface).
+
Your ISP is blocking that particular port inbound.
+
+
-
+
1b. I'm still having problems with port
- forwarding
- Answer: To
-further diagnose this problem:
-
+ forwarding
+ Answer: To
+ further diagnose this problem:
+
-
As root, type
- "iptables -t nat -Z". This clears the NetFilter counters
- in the nat table.
-
Try to connect
- to the redirected port from an external host.
-
As root type
- "shorewall show nat"
-
Locate the
-appropriate DNAT rule. It will be in a chain called
- <source zone>_dnat ('net_dnat' in the above
- examples).
-
Is the packet
- count in the first column non-zero? If so, the connection
- request is reaching the firewall and is being redirected
- to the server. In this case, the problem is usually a missing
- or incorrect default gateway setting on the server (the
- server's default gateway should be the IP address of the
-firewall's interface to the server).
-
If the packet
- count is zero:
-
+
As root,
+ type "iptables -t nat -Z". This clears the NetFilter
+ counters in the nat table.
+
Try to
+connect to the redirected port from an external host.
+
As root
+type "shorewall show nat"
+
Locate
+the appropriate DNAT rule. It will be in a chain called
+ <source zone>_dnat ('net_dnat' in the
+above examples).
+
Is the
+packet count in the first column non-zero? If so,
+the connection request is reaching the firewall and is being
+ redirected to the server. In this case, the problem is
+usually a missing or incorrect default gateway setting
+on the server (the server's default gateway should be the
+IP address of the firewall's interface to the server).
+
If the
+packet count is zero:
+
+
-
the connection
- request is not reaching your server (possibly it
- is being blocked by your ISP); or
-
you are trying
- to connect to a secondary IP address on your firewall
- and your rule is only redirecting the primary IP address
- (You need to specify the secondary IP address in the "ORIG.
- DEST." column in your DNAT rule); or
-
your DNAT
-rule doesn't match the connection request in some other
- way. In that case, you may have to use a packet sniffer such
- as tcpdump or ethereal to further diagnose the problem.
-
-
+
the connection
+ request is not reaching your server (possibly it
+ is being blocked by your ISP); or
+
you are
+ trying to connect to a secondary IP address on your
+ firewall and your rule is only redirecting the primary IP
+address (You need to specify the secondary IP address in the
+"ORIG. DEST." column in your DNAT rule); or
+
your
+DNAT rule doesn't match the connection request in
+some other way. In that case, you may have to use a packet
+sniffer such as tcpdump or ethereal to further diagnose
+the problem.
+
+
+
-
+
-
+
1c. From the internet, I want
- to connect to port 1022 on my firewall and have the firewall forward
- the connection to port 22 on local system 192.168.1.3. How do I do
-that?
-
-
-
+ to connect to port 1022 on my firewall and have the firewall forward
+ the connection to port 22 on local system 192.168.1.3. How do I do
+ that?
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE
- PORT
-
ORIG.
- DEST.
-
-
-
DNAT
-
net
-
-
loc:192.168.1.3:22
-
tcp
-
1022
-
-
-
-
-
-
-
-
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
SOURCE PORT
+
+
ORIG. DEST.
+
+
+
+
+
+
DNAT
+
+
net
+
+
+
loc:192.168.1.3:22
+
+
tcp
+
+
1022
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
2. I port forward www requests to www.mydomain.com
- (IP 130.151.100.69) to system 192.168.1.5
-in my local network. External clients can browse
-http://www.mydomain.com but internal clients can't.
-
+ (IP 130.151.100.69) to system 192.168.1.5
+ in my local network. External clients can browse
+ http://www.mydomain.com but internal clients can't.
+
Answer: I have two objections to this setup.
-
+
-
Having
- an internet-accessible server in your local network
- is like raising foxes in the corner of your hen house.
- If the server is compromised, there's nothing between
- that server and your other internal systems. For the
- cost of another NIC and a cross-over cable, you can put
- your server in a DMZ such that it is isolated from your local
-systems - assuming that the Server can be located near the
-Firewall, of course :-)
The
+ accessibility problem is best solved using Bind Version 9 "views"
(or using a separate DNS server for local clients) such that www.mydomain.com
- resolves to 130.141.100.69 externally and 192.168.1.5
- internally. That's what I do here at shorewall.net for
- my local systems that use static NAT.
-
+ resolves to 130.141.100.69 externally and 192.168.1.5
+ internally. That's what I do here at shorewall.net
+for my local systems that use static NAT.
+
-
+
If you insist on an IP solution to the accessibility problem
- rather than a DNS solution, then 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.
-
-
+ rather than a DNS solution, then 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.
+
+
If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for
those releases.
-
-
+
+
If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
- upgrade to Shorewall 1.4.2 or later.
-
-
+ upgrade to Shorewall 1.4.2 or later.
+
+
Otherwise:
-
-
+
+
-
+
-
+
-
+
-
+
-
In /etc/shorewall/interfaces:
-
+
In /etc/shorewall/interfaces:
+
-
-
+
+
-
-
-
ZONE
-
-
INTERFACE
-
-
BROADCAST
-
-
OPTIONS
-
-
-
-
loc
-
-
eth1
-
-
detect
-
-
routeback
-
-
+
+
+
ZONE
+
+
INTERFACE
+
+
BROADCAST
+
+
OPTIONS
+
+
+
+
loc
+
+
eth1
+
+
detect
+
+
routeback
+
+
-
-
+
+
-
-
+
+
-
+
-
+
-
In /etc/shorewall/rules:
-
+
In /etc/shorewall/rules:
+
-
-
+
+
-
-
-
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
DNAT
-
-
loc
-
web:192.168.1.5
-
-
tcp
-
www
-
-
-
-
130.151.100.69:192.168.1.254
-
-
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+ PORT(S)
+
SOURCE
+ PORT(S)
+
ORIGINAL
+ DEST
+
+
+
DNAT
+
+
loc
+
web:192.168.1.5
+
+
tcp
+
www
+
-
+
+
130.151.100.69:192.168.1.254
+
+
-
-
+
+
+
-
-
-
+
+
+
+
That rule only works of course if you have a static external
- IP address. If you have a dynamic IP address
- and are running Shorewall 1.3.4 or later then
-include this in /etc/shorewall/init:
-
-
-
+ IP address. If you have a dynamic IP
+address and are running Shorewall 1.3.4 or later
+then include this in /etc/shorewall/init:
+
+
+
ETH0_IP=`find_interface_address eth0`
-
-
-
+
+
+
and make your DNAT rule:
-
-
-
-
+
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE
- PORT
-
ORIG.
- DEST.
-
-
-
DNAT
-
loc
-
web:192.168.1.5
-
tcp
-
www
-
-
-
$ETH0_IP:192.168.1.254
-
-
-
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
SOURCE PORT
+
+
ORIG. DEST.
+
+
+
+
+
+
DNAT
+
+
loc
+
+
web:192.168.1.5
+
+
tcp
+
+
www
+
+
-
+
+
$ETH0_IP:192.168.1.254
+
+
+
+
+
-
-
-
-
+
+
+
+
Using this technique, you will want to configure your DHCP/PPPoE
- client to automatically restart Shorewall
- each time that you get a new IP address.
-
-
+ client to automatically restart Shorewall
+ each time that you get a new IP address.
+
+
2a. I have a zone "Z" with an RFC1918
- subnet and I use static NAT to assign non-RFC1918
- addresses to hosts in Z. Hosts in Z cannot communicate
- with each other using their external (non-RFC1918
- addresses) so they can't access each other using their
- DNS names.
-
+ subnet and I use static NAT to assign non-RFC1918
+ addresses to hosts in Z. Hosts in Z cannot communicate
+ with each other using their external (non-RFC1918
+ addresses) so they can't access each other using their
+ DNS names.
+
Answer: This is another problem that is best solved
- using Bind Version 9 "views". It allows both
- external and internal clients to access a NATed
- host using the host's DNS name.
-
+ using Bind Version 9 "views". It allows
+both external and internal clients to access
+a NATed host using the host's DNS name.
+
Another good way to approach this problem is to switch from
- static NAT to Proxy ARP. That way, the hosts
- in Z have non-RFC1918 addresses and can be accessed
- externally and internally using the same address.
-
+ static NAT to Proxy ARP. That way, the
+hosts in Z have non-RFC1918 addresses and can
+be accessed externally and internally using the same
+ address.
+
If you don't like those solutions and prefer routing all Z->Z
traffic through your firewall then:
-
+
a) Set the Z->Z policy to ACCEPT.
- b) Masquerade
- Z to itself.
-
- Example:
3. I want to use Netmeeting or MSN Instant
- Messenger with Shorewall. What do I do?
-
+ Messenger with Shorewall. What do I do?
+
Answer: There is an H.323 connection
- tracking/NAT module that may help with
+ 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.
-
-
+
+
4. I just used an online port scanner
- to check my firewall and it shows some
-ports as 'closed' rather than 'blocked'. Why?
-
+ to check my firewall and it shows some
+ ports as 'closed' rather than 'blocked'. Why?
+
Answer: The common.def included with version 1.3.x
- always rejects connection requests on
-TCP port 113 rather than dropping them. This is
- necessary to prevent outgoing connection problems to
- services that use the 'Auth' mechanism for identifying
- requesting users. Shorewall also rejects TCP ports
+ always rejects connection requests on
+ TCP port 113 rather than dropping them. This
+is necessary to prevent outgoing connection problems
+to services that use the 'Auth' mechanism for identifying
+ requesting users. Shorewall also rejects TCP ports
135, 137 and 139 as well as UDP ports 137-139. These are
ports that are used by Windows (Windows can be configured
to use the DCE cell locator on port 135). Rejecting these connection
- requests rather than dropping them cuts down slightly on the amount
- of Windows chatter on LAN segments connected to the Firewall.
-
-
+ requests rather than dropping them cuts down slightly on the
+amount of Windows chatter on LAN segments connected to the
+Firewall.
+
If you are seeing port 80 being 'closed', that's probably
- your ISP preventing you from running a
-web server in violation of your Service Agreement.
-
+ your ISP preventing you from running
+a web server in violation of your Service Agreement.
+
4a. I just ran an nmap UDP scan of my
- firewall and it showed 100s of ports as
- open!!!!
-
+ firewall and it showed 100s of ports
+as open!!!!
+
Answer: Take a deep breath and read the nmap man page
- section about UDP scans. If nmap gets
-nothing back from your firewall then it
-reports the port as open. If you want to see which
- UDP ports are really open, temporarily change your net->all
- policy to REJECT, restart Shorewall and do the nmap
-UDP scan again.
-
-
+ section about UDP scans. If nmap gets
+ nothing back from your firewall then
+it reports the port as open. If you want to see which
+ UDP ports are really open, temporarily change your net->all
+ policy to REJECT, restart Shorewall and do the nmap
+ UDP scan again.
+
+
4b. I have a port that I can't close no matter how
- I change my rules.
- I had a rule that allowed telnet from my local network to my firewall;
- I removed that rule and restarted Shorewall but my telnet session still
- works!!!
-
- Answer: Rules only govern the establishment of new connections.
- Once a connection is established through the firewall it will be usable
- until disconnected (tcp) or until it times out (other protocols). If you
- stop telnet and try to establish a new session your firerwall will block
- that attempt.
-
+ I change my rules.
+ I had a rule that allowed telnet from my local network to my
+ firewall; I removed that rule and restarted Shorewall but my telnet
+ session still works!!!
+
+ Answer: Rules only govern the establishment of new
+connections. Once a connection is established through the firewall
+it will be usable until disconnected (tcp) or until it times out (other
+protocols). If you stop telnet and try to establish a new session your
+firerwall will block that attempt.
+
4c. How to I use Shorewall with
-PortSentry?
-
+ Here's
-a writeup on a nice integration of Shorewall and PortSentry.
-
+ a writeup on a nice integration of Shorewall and PortSentry.
+
5. I've installed Shorewall and now I
- can't ping through the firewall
-
+ can't ping through the firewall
+
Answer: If you want your firewall to be totally open
- for "ping",
-
+ for "ping",
+
a) Create /etc/shorewall/common if it doesn't already exist.
-
- b) Be sure
- that the first command in the file is ". /etc/shorewall/common.def"
- c) Add
-the following to /etc/shorewall/common
-
-
+
+ b)
+Be sure that the first command in the file is ". /etc/shorewall/common.def"
+ c)
+Add the following to /etc/shorewall/common
+
+
- For a complete description of
-Shorewall 'ping' management, see this
-page.
+ -j ACCEPT
+
+
+ For a complete description
+of Shorewall 'ping' management, see this
+ page.
6. Where are the log messages written
- and how do I change the destination?
-
+ and how do I change the destination?
+
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 messaged
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").
-
+ When you have changed /etc/syslog.conf, be
+ sure to restart syslogd (on a RedHat system, "service
+ syslog restart").
+
By default, older versions of Shorewall ratelimited log messages
- through settings
- in /etc/shorewall/shorewall.conf -- If you
-want to log all messages, set:
-
-
+ through settings in /etc/shorewall/shorewall.conf
+ -- If you want to log all messages, set:
+
+
- I personnaly use Logwatch.
-It emails me a report each day from my various systems
-with each report summarizing the logged activity on the corresponding
- system.
+ http://www.logwatch.org
+ http://gege.org/iptables
+ http://home.regit.org/ulogd-php.html
+
+
+ I personnaly use Logwatch.
+ It emails me a report each day from my various systems
+ with each report summarizing the logged activity on the corresponding
+ system.
6b. DROP messages on port 10619
- are flooding the logs with their connect requests.
- Can i exclude these error messages for this port temporarily
-from logging in Shorewall?
- Temporarily add the following rule:
-
+ are flooding the logs with their connect requests.
+ Can i exclude these error messages for this port temporarily
+ from logging in Shorewall?
+ Temporarily add the following rule:
+
DROP net fw udp 10619
-
+
6c. All day long I get a steady flow
- of these DROP messages from port 53 to some high numbered
- port. They get dropped, but what the heck are they?
-
+ of these DROP messages from port 53 to some high numbered
+ port. They get dropped, but what the heck are they?
+
- Answer: There are two possibilities:
-
+ Answer: There are two possibilities:
+
-
They are late-arriving replies to
-DNS queries.
-
They are corrupted reply packets.
-
+
They are late-arriving replies
+ to DNS queries.
+
They are corrupted reply packets.
+
- You can distinguish the difference by setting
- the logunclean option (logunclean option (/etc/shorewall/interfaces)
on your external interface (eth0 in the above example). If they get
- logged twice, they are corrupted. I solve this problem by using
- an /etc/shorewall/common file like this:
-
-
+ logged twice, they are corrupted. I solve this problem by using
+ an /etc/shorewall/common file like this:
+
+
# # Include the standard common.def file # . /etc/shorewall/common.def # # The following rule is non-standard and compensates for tardy # DNS replies # run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
6d. Why is the MAC address in
- Shorewall log messages so long? I thought MAC addresses were
- only 6 bytes in length.
- What is labeled as the MAC address in a Shorewall log
- message is actually the Ethernet frame header. IT contains:
-
+ Shorewall log messages so long? I thought MAC addresses were
+ only 6 bytes in length.
+ What is labeled as the MAC address in a Shorewall
+ log message is actually the Ethernet frame header. IT contains:
+
7. When I stop Shorewall using 'shorewall
- stop', I can't connect to anything. Why
-doesn't that command work?
-
+ stop', I can't connect to anything. Why
+ doesn't that command work?
+
The 'stop' command is intended to place your firewall into
- a safe state whereby only those hosts listed
- in /etc/shorewall/routestopped' are activated.
- If you want to totally open up your firewall, you must
- use the 'shorewall clear' command.
-
+ a safe state whereby only those hosts listed
+ in /etc/shorewall/routestopped' are activated.
+ If you want to totally open up your firewall, you must
+ use the 'shorewall clear' command.
+
8. When I try to start Shorewall on RedHat,
- I get messages about insmod failing -- what's wrong?
-
+ I get messages about insmod failing -- what's wrong?
+
Answer: The output you will see looks something like
- this:
-
+ this:
+
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.
-
+
This is usually cured by the following sequence of commands:
-
-
-
+
+
+
service ipchains stop chkconfig --delete ipchains rmmod ipchains
-
-
-
+
+
+
Also, be sure to check the errata
- for problems concerning the version of iptables
- (v1.2.3) shipped with RH7.2.
-
-
+ for problems concerning the version of
+iptables (v1.2.3) shipped with RH7.2.
+
+
8a. When I try to start Shorewall on RedHat
- I get a message referring me to FAQ #8
- Answer: This is usually cured by the sequence of
- commands shown above in FAQ #8
-
-
+ I get a message referring me to FAQ #8
+ Answer: This is usually cured by the sequence
+ of commands shown above in FAQ #8
+
+
9. Why can't Shorewall detect my interfaces
- properly at startup?
-
+ properly at startup?
+
I just installed Shorewall and when I issue the start command,
- I see the following:
-
-
+ 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
-
-
+
+
10. What Distributions does it work
with?
-
+
Shorewall works with any GNU/Linux distribution that includes
- the proper prerequisites.
Answer: Yes. Shorewall support is included in Webmin
- 1.060 and later versions. See http://www.webmin.com
-
+
13. Why do you call it "Shorewall"?
-
+
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 must more
-commonly used.
-
+ and "Firewall". The full name of the product
+ is actually "Shoreline Firewall" but "Shorewall" is must more
+ commonly used.
+
14. I'm connected via a cable modem
- and it has an internal web server that allows
- me to configure/monitor it but as expected if
-I enable rfc1918 blocking for my eth0 interface (the
- internet one), it also blocks the cable modems web server.
-
+ and it has an internal web server that
+allows me to configure/monitor it but as expected
+if I enable rfc1918 blocking for my eth0 interface
+ (the internet one), it also blocks the cable modems web server.
+
Is there any way it can add a rule before the rfc1918 blocking
- that will let all traffic to and from the
-192.168.100.1 address of the modem in/out but
-still block all other rfc1918 addresses?
-
+ that will let all traffic to and from the
+ 192.168.100.1 address of the modem in/out but
+ still block all other rfc1918 addresses?
+
Answer: If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:
If you are running version 1.3.1 or later, simply add the
- following to /etc/shorewall/rfc1918:
-
-
-
-
+
+
+
+
-
-
-
SUBNET
+
-
TARGET
-
-
+
-
192.168.100.1
+
SUBNET
-
RETURN
-
+
TARGET
-
-
+
+
+
+
+
192.168.100.1
+
+
RETURN
+
+
+
+
+
-
-
-
-
+
+
+
+
Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-
-
+
+
Note: If you add a second IP address to your external firewall
- interface to correspond to the modem address,
- you must also make an entry in /etc/shorewall/rfc1918
- for that address. For example, if you configure the
-address 192.168.100.2 on your firewall, then you would add
-two entries to /etc/shorewall/rfc1918:
-
-
-
+ interface to correspond to the modem address,
+ you must also make an entry in /etc/shorewall/rfc1918
+ for that address. For example, if you configure the
+ address 192.168.100.2 on your firewall, then you would add
+ two entries to /etc/shorewall/rfc1918:
+
+
+
-
-
-
SUBNET
-
-
TARGET
-
-
-
-
192.168.100.1
-
-
RETURN
-
-
-
-
192.168.100.2
-
-
RETURN
-
-
+
-
-
+
+
+
SUBNET
+
+
+
+
TARGET
+
+
+
+
+
+
+
+
192.168.100.1
+
+
+
+
RETURN
+
+
+
+
+
+
+
+
192.168.100.2
+
+
+
+
RETURN
+
+
+
+
+
+
+
-
-
-
-
+
+
+
+
14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.
-
-
-
+
+
+
The solution is the same as FAQ 14 above. Simply substitute
- the IP address of your ISPs DHCP server.
-
-
+ the IP address of your ISPs DHCP server.
+
+
15. My local systems can't see out to
- the net
-
+ the net
+
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:
-
+ 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:
+
-
+
+
The default gateway on each local system isn't set to
- the IP address of the local firewall interface.
-
-
+ the IP address of the local firewall
+interface.
+
+
+
+
The entry for the local network in the /etc/shorewall/masq
- file is wrong or missing.
-
-
+ file is wrong or missing.
+
+
+
+
The DNS settings on the local systems are wrong or the
- user is running a DNS server on the firewall
- and hasn't enabled UDP and TCP port 53 from
-the firewall to the internet.
-
-
+ user is running a DNS server on the
+firewall and hasn't enabled UDP and TCP port
+53 from the firewall to the internet.
+
+
+
-
+
16. Shorewall is writing log messages
- all over my console making it unusable!
-
+ all over my console making it unusable!
+
Answer: If you are running Shorewall version 1.4.4
- or 1.4.4a then check the errata. Otherwise, see
- the 'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command
- to your startup scripts or place it in /etc/shorewall/start.
- Under RedHat, the max log level that is sent
- to the console is specified in /etc/sysconfig/init
- in the LOGLEVEL variable.
-
-
+ or 1.4.4a then check the errata. Otherwise,
+see the 'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg'
+command to your startup scripts or place
+it in /etc/shorewall/start. Under RedHat, the
+max log level that is sent to the console is specified
+ in /etc/sysconfig/init in the LOGLEVEL variable.
+
+
17. How do I find out why this traffic is getting
- logged?
- Answer: Logging
- occurs out of a number of chains (as indicated in
- the log message) in Shorewall:
-
+ logged?
+ Answer:
+ Logging occurs out of a number of chains (as indicated
+ in the log message) in Shorewall:
+
-
man1918
- or logdrop - The destination address is
- listed in /etc/shorewall/rfc1918 with a logdrop target
- -- see /etc/shorewall/rfc1918.
rfc1918
+ or logdrop - The source address is listed in /etc/shorewall/rfc1918
+ with a logdrop target -- see /etc/shorewall/rfc1918.
-
all2<zone>,
- <zone>2all or all2all
- - You have a policy
- that specifies a log level and this packet is being
- logged under that policy. If you intend to ACCEPT this
- traffic then you need a rule to
-that effect.
-
-
<zone1>2<zone2>
- - Either you have aall2<zone>,
+ <zone>2all or all2all
+ - You have a policy
+ that specifies a log level and this packet is
+being logged under that policy. If you intend to ACCEPT
+this traffic then you need a rule
+ to that effect.
+
+
<zone1>2<zone2>
+ - Either you have a policy for <zone1>
to <zone2> that specifies a log level and
- this packet is being logged under that policy or this
- packet matches a rule
- that includes a log level.
-
<interface>_mac
- - The packet is being logged under the maclist
- interface option.
-
-
logpkt
- - The packet is being logged under the logunclean
- interface option.
-
badpkt
- - The packet is being logged under the
- dropuncleanrule
+ that includes a log level.
+
<interface>_mac
+ - The packet is being logged under the maclist
+ interface option.
+
+
logpkt
+ - The packet is being logged under the logunclean
+ interface option.
INPUT
- or FORWARD - The packet has a source IP
- address that isn't in any of your defined zones ("shorewall
- check" and look at the printed zone definitions) or the
- chain is FORWARD and the destination IP isn't in any of your
- defined zones.
19. I have added entries to /etc/shorewall/tcrules
- but they don't seem to do anything. Why?
- You probably haven't
-set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf
- so the contents of the tcrules file are simply being ignored.
-
+ but they don't seem to do anything. Why?
+ You probably haven't
+ set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf
+ so the contents of the tcrules file are simply being ignored.
+
20. I have just set up a server. Do I have
- to change Shorewall to allow access to my server
- from the internet?
-
- Yes. Consult the QuickStart guide that
+ to change Shorewall to allow access to my server
+ from the internet?
+
+ Yes. Consult the
+QuickStart guide that
you used during your initial setup for information about how to set
up rules for your server.
-
+
21. I see these strange log entries occasionally;
- what are they?
-
- 192.0.2.3 is external on
- my firewall... 172.16.0.0/24 is my internal LAN
-
- Answer: While most
- people associate the Internet Control Message Protocol
- (ICMP) with 'ping', ICMP is a key piece of the internet.
- 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 a lot of broken
- implementations. That is what you are seeing with these messages.
-
- 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 have also seen
-cases where the source IP in the ICMP itself isn't set back to the external
-IP of the remote NAT gateway; that causes your firewall to log and
-drop the packet out of the rfc1918 chain because the source IP is
-reserved by RFC 1918.
-
+
+ 192.0.2.3 is external
+ on my firewall... 172.16.0.0/24 is my internal LAN
+
+ Answer: While
+ most people associate the Internet Control Message
+ Protocol (ICMP) with 'ping', ICMP is a key piece of the
+internet. 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 a lot of broken implementations. That is what you are
+seeing with these messages.
+
+ 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
+ have also seen cases where the source IP in the ICMP itself isn't set
+back to the external IP of the remote NAT gateway; that causes your
+firewall to log and drop the packet out of the rfc1918 chain because
+ the source IP is reserved by RFC 1918.
+
22. I have some iptables commands that
- I want to run when Shorewall starts. Which file
- do I put them in?
- 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 to
- be sure that the commands will do what they are 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.
-
+ I want to run when Shorewall starts. Which
+file do I put them in?
+ 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 to be sure that the commands
+will do what they are 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.
+
23. Why do you use such ugly fonts on your
- web site?
- 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.
-
+ web site?
+ 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.
+
24. How can I allow conections to let's say
- the ssh port only from specific IP Addresses on
-the internet?
- 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.
-
+ the ssh port only from specific IP Addresses on
+ the internet?
+ 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>,...
- Example:
-
+ Example:
+
ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22
-
+
-
+
25. How to I tell which version of Shorewall
- I am running?
-
- At the shell prompt, type:
-
- /sbin/shorewall version
-
+ I am running?
+
+ At the shell prompt, type:
+
+ /sbin/shorewall
+version
+
26. When I try to use any of the SYN options
- in nmap on or behind the firewall, I get "operation not permitted". How
- can I use nmap with Shorewall?"
- Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes"
- then restart Shorewall.
-
+ in nmap on or behind the firewall, I get "operation not permitted".
+How can I use nmap with Shorewall?"
+ Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to
+"NEWNOTSYN=Yes" then restart Shorewall.
+
- 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.
-
+ 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.
+
28. How do I use Shorewall as a Bridging Firewall?
-
- Basically, you don't. While there are kernel patches that allow you to
- route bridge traffic through Netfilter, the environment is so different
-from the Layer 3 firewalling environment that very little of Shorewall works.
-In fact, so much of Shorewall doesn't work that my official position is that
- "Shorewall doesn't work with Layer 2 Bridging".
-
- Last updated 7/9/2003 - Tom Eastep
+
+ Basically, you don't. While there are kernel patches that allow you
+ to route bridge traffic through Netfilter, the environment is so different
+ from the Layer 3 firewalling environment that very little of Shorewall
+works. In fact, so much of Shorewall doesn't work that my official position
+is that "Shorewall doesn't work with Layer 2 Bridging".
+
+
FTP transfers involve two TCP connections. The first control connection
+ goes from the FTP client to port 21 on the FTP server. This connection is
+ used for logon and to send commands and responses between the endpoints.
+Data transfers (including the output of "ls" and "dir" commands) requires
+a second data connection. The data connection is dependent on the mode
+that the client is operating in:
+
+
+
+
Passive Mode (default for web browsers) -- The client issues a PASV
+ command. Upon receipt of this command, the server listens on a dynamically-allocated
+ port then sends a PASV reply to the client. The PASV reply gives the IP address
+and port number that the server is listening on. The client then opens a
+second connection to that IP address and port number.
+
Active Mode (often the default for line-mode clients) -- The client
+ listens on a dynamically-allocated port then sends a PORT command to the
+server. The PORT command gives the IP address and port number that the client
+is listening on. The server then opens a connection to that IP address and
+port number; the source port for this connection is 20 (ftp-data in
+/etc/services).
+
+
+ You can see these commands in action using your linux ftp command-line
+client in debugging mode. Note that my ftp client defaults to passive mode
+and that I can toggle between passive and active mode by issuing a "passive"
+command:
+
+
+
[teastep@wookie Shorewall]$ ftp ftp1.shorewall.net Connected to lists.shorewall.net. 220-=(<*>)=-.:. (( Welcome to PureFTPd 1.0.12 )) .:.-=(<*>)=- 220-You are user number 1 of 50 allowed. 220-Local time is now 10:21 and the load is 0.14. Server port: 21. 220 You will be disconnected after 15 minutes of inactivity. 500 Security extensions not implemented 500 Security extensions not implemented KERBEROS_V4 rejected as an authentication type Name (ftp1.shorewall.net:teastep): ftp 331-Welcome to ftp.shorewall.net 331- 331 Any password will work Password: 230 Any password will work Remote system type is UNIX. Using binary mode to transfer files. ftp> debug Debugging on (debug=1). ftp> ls ---> PASV 227 Entering Passive Mode (192,168,1,193,195,210) ---> LIST 150 Accepted data connection drwxr-xr-x 5 0 0 4096 Nov 9 2002 archives drwxr-xr-x 2 0 0 4096 Feb 12 2002 etc drwxr-sr-x 6 0 50 4096 Feb 19 15:24 pub 226-Options: -l 226 3 matches total ftp> passive Passive mode off. ftp> ls ---> PORT 192,168,1,3,142,58 200 PORT command successful ---> LIST 150 Connecting to port 36410 drwxr-xr-x 5 0 0 4096 Nov 9 2002 archives drwxr-xr-x 2 0 0 4096 Feb 12 2002 etc drwxr-sr-x 6 0 50 4096 Feb 19 15:24 pub 226-Options: -l 226 3 matches total ftp>
+
+ Things to notice:
+
+
+
The commands that I issued are in green.
+
+
Commands sent by the client to the server are preceded by --->
+
Command responses from the server over the control connection are
+ numbered.
+
+
FTP uses a comma as a separator between the bytes of the IP address;
+ and
+
When sending a port number, FTP sends the MSB then the LSB and separates
+ the two bytes by a comma. As shown in the PORT command, port 142,58 translates
+to 142*256+58 = 36410.
+
+
+
+ Given the normal loc->net policy of ACCEPT, passive mode access from
+ local clients to remote servers will always work but active mode requires
+ the firewall to dynamically open a "hole" for the server's connection back
+ to the client. Similarly, if you are running an FTP server in your local
+zone then active mode should always work but passive mode requires the firewall
+ to dynamically open a "hole" for the client's second connection to the server.
+ This is the role of FTP connection-tracking support in the Linux kernel.
+
+
+ Where any form of NAT (SNAT, DNAT, Masquerading) on your firewall is involved,
+the PORT commands and PASV responses may also need to be modified by the
+firewall. This is the job of the FTP nat support kernel function.
+
+
+
Including FTP connection-tracking and NAT support normally means that the
+modules "ip_conntrack_ftp" and "ip_nat_ftp" need to be loaded. Shorewall automatically
+loads these "helper" modules from /lib/modules/<kernel-version>/kernel/net/ipv4/netfilter/
+ and you can determine if they are loaded using the 'lsmod' command:
+
If you want Shorewall to load these modules from an alternate directory,
+ you need to set the MODULESDIR variable in /etc/shorewall/shorewall.conf
+ to point to that directory.
+
For a client, you must open outbound TCP port 21.
+
+
+
The above discussion about commands and responses makes it clear that the
+FTP connection-tracking and NAT helpers must scan the traffic on the control
+connection looking for PASV and PORT commands as well as PASV responses. If
+you run an FTP server on a nonstandard port or you need to access such
+a server, you must therefore let the helpers know by specifying the port
+in /etc/shorewall/modules entries for the helpers. For example, if you
+run an FTP server that listens on port 49 then you would have:
+
IMPORTANT: Once you have made these changes to /etc/shorewall/modules
+ and/or /etc/modules.conf, you must either:
+
+
+
+
Unload the modules and restart shorewall: (rmmod ip_nat_ftp; rmmod ip_conntrack_ftp; shorewall restart);
+ or
+
Reboot
+
+
+ One problem that I see occasionally involves active mode and the FTP server
+in my DMZ. I see the active data connection to certain client IP addresses
+being continuously rejected by my firewall. It is my conjecture that there
+is some broken client out there that is sending a PORT command that is being
+either missed or mis-interpreted by the FTP connection tracking helper yet
+it is being accepted by my FTP server. My solution is to add the following
+rule:
+
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT(S)
+
+
SOURCE
+ PORT(S)
+
+
ORIGINAL
+ DESTINATION
+
+
+
+
ACCEPT:info
+
+
dmz
+
+
net
+
+
tcp
+
+
-
+
+
20
+
+
+
+
+
+
+
+
+
+ The above rule accepts and logs all active mode connections from my DMZ
+to the net.
+
+
+Shorewall includes built-in support for a wide range of VPN solutions.
+If you have need for a tunnel type that does not have explicit support,
+you can generally describe the tunneling software using "generic
+tunnels"
+
Bridging two Masqueraded Networks
+
Suppose that we have the following situation:
+
+
We want systems in the 192.168.1.0/24 subnetwork to be
+able to communicate with the systems in the 10.0.0.0/8 network. This is
+accomplished through use of the /etc/shorewall/tunnels file, the
+/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
+included with Shorewall.
+
+
Suppose that you have tunneling software that uses two
+different protocols:
+
+
a) TCP port 1071
+b) GRE (Protocol 47)
+c) The tunnel interface on system A is "tun0" and the tunnel interface
+on system B is also "tun0".
+
+
On each firewall, you will need to declare a zone to
+represent the remote subnet. We'll assume that this zone is called
+'vpn' and declare it in /etc/shorewall/zones on both systems as follows.
+
+
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
vpn
+
VPN
+
Remote Subnet
+
+
+
+
+
On system A, the 10.0.0.0/8 will comprise the vpn
+zone.
+In /etc/shorewall/interfaces:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
vpn
+
tun0
+
10.255.255.255
+
+
+
+
+
+
In /etc/shorewall/tunnels on system A, we need the
+following:
+
+
+
+
+
TYPE
+
ZONE
+
GATEWAY
+
GATEWAY ZONE
+
+
+
generic:tcp:1071
+
+
net
+
134.28.54.2
+
+
+
+
generic:47
+
+
net
+
+
134.28.54.2
+
+
+
+
+
+
+
+
These entries in /etc/shorewall/tunnels, opens the firewall so that
+TCP port 1071 and the Generalized Routing Encapsulation Protocol (47)
+will be accepted to/from the remote gateway.
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
vpn
+
tun0
+
192.168.1.255
+
+
+
+
+
+
In /etc/shorewall/tunnels on system B, we have:
+
+
+
+
+
TYPE
+
ZONE
+
GATEWAY
+
GATEWAY ZONE
+
+
+
generic:tcp:1071
+
+
net
+
206.191.148.9
+
+
+
+
generic:47
+
+
net
+
+
134.28.54.2
+
+
+
+
+
+
+
+
You will need to allow traffic between the "vpn" zone
+and the "loc" zone on both systems -- if you simply want to admit all
+traffic in both directions, you can use the policy file:
+
+
+
+
+
SOURCE
+
DEST
+
POLICY
+
LOG LEVEL
+
+
+
loc
+
vpn
+
ACCEPT
+
+
+
+
vpn
+
loc
+
ACCEPT
+
+
+
+
+
+
On both systems, restart Shorewall and start your VPN software on
+each system. The systems in the two masqueraded subnetworks
+can now talk to each other
A problem seen on RH7.3 systems where Shorewall encountered start
- errors when started using the "service" mechanism has been worked around.
-
-
-
Where a list of IP addresses appears in the DEST column of a DNAT[-]
- rule, Shorewall incorrectly created multiple DNAT rules in the nat table
-(one for each element in the list). Shorewall now correctly creates a
-single DNAT rule with multiple "--to-destination" clauses.
-
-
-
Corrected a problem in Beta 1 where DNS names containing a "-"
-were mis-handled when they appeared in the DEST column of a rule.
-
-
-
A number of problems with rule parsing have been corrected. Corrections
-involve the handling of "z1!z2" in the SOURCE column as well as lists in
-the ORIGINAL DESTINATION column.
-
-
-
The message "Adding rules for DHCP" is now suppressed if there are
-no DHCP rules to add.
-
+
Corrected problem in 1.4.6 where the MANGLE_ENABLED
+variable was being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of
+the tcrules file. Previously, these addresses resulted in an invalid
+iptables command.
+
The
+"shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled exists. This prevents people from
+shooting themselves in the foot prior to having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being added to a PPP interface; the addresses were successfully added
+in spite of the messages.
+
+The firewall script has been modified to eliminate the error messages
+
+
+Migration Issues:
+
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions,
+current uses of "shorewall drop" and "shorewall reject" should be
+replaced with "shorewall dropall" and "shorewall rejectall"
+
+New Features:
+
+
Shorewall now creates a dynamic blacklisting chain for each
+interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
+commands use the routing table to determine which of these chains is to
+be used for blacklisting the specified IP address(es).
+
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
Thanks to Steve Herber, the 'help' command can now give
+command-specific help (e.g., shorewall help <command>).
+
A new option "ADMINISABSENTMINDED" has been added to
+/etc/shorewall/shorewall.conf. This option has a default value of "No"
+for existing users which causes Shorewall's 'stopped' state to
+continue as it has been; namely, in the stopped state only traffic
+to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+With ADMINISABSENTMINDED=Yes (the default for new installs), in
+addition to traffic to/from the hosts listed in
+/etc/shorewall/routestopped, Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+loc:192.168.1.5 tcp 22
+ ACCEPT loc
+fw tcp 22
+
+From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+connection with local system 192.168.1.5. I then create a second SSH
+connection
+from that computer to the firewall and confidently type "shorewall
+stop".
+As part of its stop processing, Shorewall removes eth0:0 which kills my
+SSH
+connection to 192.168.1.5!!!
+
Given
+the wide range of VPN software, I can never hope to add specific
+support for all of it. I have therefore decided to add "generic" tunnel
+support.
+
+Generic tunnels work pretty much like any of the other tunnel types.
+You usually add a zone to represent the systems at the other end of the
+tunnel and you add the appropriate rules/policies to
+implement your security policy regarding traffic to/from those systems.
+
+In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+generic:<protocol>[:<port>] <zone> <ip
+address> <gateway zones>
+
+where:
+
+ <protocol> is the protocol
+used by the tunnel
+ <port> if the protocol
+is 'udp' or 'tcp' then this is the destination port number used by the
+tunnel.
+ <zone> is the zone of
+the remote tunnel gateway
+ <ip address> is the IP
+address of the remote tunnel gateway.
+ <gateway zone>
+Optional. A comma-separated list of zone
+names. If specified, the remote gateway is to be considered part of
+these zones.
+
An 'arp_filter' option has been added to the
+/etc/shorewall/interfaces file. This option causes
+/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+result that this interface will only answer ARP 'who-has' requests from
+hosts that are routed out through that interface. Setting this option
+facilitates testing of your firewall where multiple firewall interfaces
+are connected to the same HUB/Switch (all interfaces connected to the
+single HUB/Switch should have this option specified). Note that using
+such a configuration in a production environment is strongly
+recommended against.
+
+
+
8/5/2003 - Shorewall-1.4.6b
+
+Problems Corrected since version 1.4.6:
+
+
Previously, if TC_ENABLED is set to yes in shorewall.conf
+then Shorewall would fail to start with the error "ERROR: Traffic
+Control requires Mangle"; that problem has been corrected.
+
Corrected handling of MAC addresses in the SOURCE column of
+the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables
+command.
+
The "shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled
+exists. This prevents people from shooting themselves in the foot prior
+to
+having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages
+during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being
+added to a PPP interface; the addresses were successfully added in
+spite
+of the messages.
+
+The firewall script has been modified to eliminate the error messages.
+
+
8/5/2003 - Shorewall-1.4.6b
+
+Problems Corrected since version 1.4.6:
+
+
Previously, if TC_ENABLED is set to yes in shorewall.conf then
+Shorewall
+would fail to start with the error "ERROR: Traffic Control
+requires Mangle";
+that problem has been corrected.
+
Corrected handling of MAC addresses in the SOURCE column of the
+tcrules
+file. Previously, these addresses resulted in an invalid iptables
+command.
+
The "shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled exists. This prevents people from
+shooting themselves in the foot prior to having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being added to a PPP interface; the addresses were successfully added
+in spite of the messages.
+
+The firewall script has been modified to eliminate the error messages.
+
Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was
+being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables command.
+
-
-
Migration Issues:
-
-
+
-
In earlier versions, an undocumented feature allowed entries in
-the host file as follows:
-
- z eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6
- to allow entries of the following format:
-
- z eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
- removed from /etc/shorewall/shorewall.conf. These capabilities are now
-automatically detected by Shorewall (see below).
-
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions, current
+uses of "shorewall drop" and "shorewall reject" should be replaced with
+"shorewall dropall" and "shorewall rejectall"
-
-
New Features:
-
-
-
+
New Features:
+
-
A 'newnotsyn' interface option has been added. This option may
-be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
- for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in /etc/shorewall/masq
- to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
- address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other than the first
- one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin) over
-a set of servers. Servers may be specified in a range of addresses given
-as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
- have been removed and have been replaced by code that detects whether
- these capabilities are present in the current kernel. The output of the
- start, restart and check commands have been enhanced to report the outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension has been added.
- This extension is available in recent kernel/iptables releases and allows
- for rules which match against elements in netfilter's connection tracking
- table. Shorewall automatically detects the availability of this extension
- and reports its availability in the output of the start, restart and
-check commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
- is changed in the following ways:
+
Shorewall now creates a dynamic blacklisting chain for each
+interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
+commands use the routing table to determine which of these chains is to
+be used for blacklisting the specified IP address(es).
+
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
Thanks to Steve Herber, the 'help' command can now give
+command-specific help (e.g., shorewall help <command>).
+
A new option "ADMINISABSENTMINDED" has been added to
+/etc/shorewall/shorewall.conf. This option has a default value of "No"
+for existing users which causes
+Shorewall's 'stopped' state to continue as it has been; namely,
+in the
+stopped state only traffic to/from hosts listed in
+/etc/shorewall/routestopped
+is accepted.
+
+With ADMINISABSENTMINDED=Yes (the default for new installs), in
+addition to traffic to/from the hosts listed in
+/etc/shorewall/routestopped, Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+loc:192.168.1.5 tcp 22
+ ACCEPT loc
+fw tcp 22
+
+From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+connection with local system 192.168.1.5. I then create a second SSH
+connection from that computer to the firewall and confidently type
+"shorewall stop". As part of its stop processing, Shorewall removes
+eth0:0 which kills my SSH connection to 192.168.1.5!!!
Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was
+being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables command.
+
+
+Migration Issues:
+
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions, current
+uses of "shorewall drop" and "shorewall reject" should be replaced with
+"shorewall dropall" and "shorewall rejectall"
+
+New Features:
+
+
Shorewall now creates a dynamic blacklisting chain for each
+interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
+commands use the routing table to determine which of these chains is to
+be used for blacklisting the specified IP address(es).
+
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
Thanks to Steve Herber, the 'help' command can now give
+command-specific help (e.g., shorewall help <command>).
+
Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was
+being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables
+command.
+
+
+
Migration Issues:
+
+
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions, current
+uses of "shorewall drop" and "shorewall reject" should be replaced with
+"shorewall dropall" and "shorewall rejectall"
+
+
New Features:
+
+Shorewall now creates a dynamic blacklisting chain for each interface
+defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+use the routing table to determine which of these chains is to be used
+for blacklisting the specified IP address(es).
+
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
7/22/2003 - Shorewall-1.4.6a
+
+Problems Corrected:
+
+
Previously, if TC_ENABLED is set to yes in shorewall.conf then
+Shorewall would fail to start with the error "ERROR: Traffic
+Control requires
+Mangle"; that problem has been corrected.
+
+
7/20/2003 - Shorewall-1.4.6
+
+
+
Problems Corrected:
+
+
+
A problem seen on RH7.3 systems where Shorewall encountered start
+errors when started using the "service" mechanism has been worked
+around.
+
+
+
Where a list of IP addresses appears in the DEST column of a
+DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
+nat table (one for each element in the list). Shorewall now correctly
+creates a single DNAT rule with multiple "--to-destination" clauses.
+
+
+
Corrected a problem in Beta 1 where DNS names containing a "-"
+were mis-handled when they appeared in the DEST column of a rule.
+
+
+
A number of problems with rule parsing have been corrected.
+Corrections involve the handling of "z1!z2" in the SOURCE column as
+well as lists in the ORIGINAL DESTINATION column.
+
+
+
The message "Adding rules for DHCP" is now suppressed if there
+are no DHCP rules to add.
+
+
+
Migration Issues:
+
+
+
In earlier versions, an undocumented feature allowed entries in
+the host file as follows:
+
+ z
+eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+This capability was never documented and has been removed
+in 1.4.6 to allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
+removed from /etc/shorewall/shorewall.conf. These capabilities are now
+automatically detected by Shorewall (see below).
+
+
+
New Features:
+
+
+
A 'newnotsyn' interface option has been added. This option may be
+specified in /etc/shorewall/interfaces and overrides the setting
+NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+
The means for specifying a range of IP addresses in
+/etc/shorewall/masq to use for SNAT is now documented.
+ADD_SNAT_ALIASES=Yes is enabled for address ranges.
+
+
+
Shorewall can now add IP addresses to subnets other than the
+first one on an interface.
+
+
+
DNAT[-] rules may now be used to load balance (round-robin) over
+a set of servers. Servers may be specified in a range of addresses
+given as <first address>-<last address>.
+
+Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
+options have been removed and have been replaced by code that detects
+whether these capabilities are present in the current kernel. The
+output of the start, restart and check commands have been enhanced to
+report
+the outcome:
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+Verifying Configuration...
+
+
+
Support for the Connection Tracking Match Extension has been
+added. This extension is available in recent kernel/iptables releases
+and allows for rules which match against elements in netfilter's
+connection tracking table. Shorewall automatically detects the
+availability of this extension and reports its availability in the
+output of the start, restart and check commands.
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+Verifying Configuration...
+
+If this extension is available, the ruleset generated by
+Shorewall is changed in the following ways:
-
To handle 'norfc1918' filtering, Shorewall will not create chains
- in the mangle table but will rather do all 'norfc1918' filtering in the
-filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter rules;
- one in the nat table and one in the filter table. If the Connection
-Tracking Match Extension is available, the rule in the filter table is extended
- to check that the original destination address was the same as specified
- (or defaulted to) in the DNAT rule.
-
-
+
To handle 'norfc1918' filtering, Shorewall will not create
+chains in the mangle table but will rather do all 'norfc1918' filtering
+in the filter table (rfc1918 chain).
+
Recall that Shorewall DNAT rules generate two netfilter rules;
+one in the nat table and one in the filter table. If the Connection
+Tracking Match Extension is available, the rule in the filter table is
+extended to check that the original destination address was the same as
+specified (or defaulted to) in the DNAT rule.
+
+
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
+
The shell used to interpret the firewall script
+(/usr/share/shorewall/firewall) may now be specified using the
+SHOREWALL_SHELL parameter in shorewall.conf.
+
+
An 'ipcalc' command has been added to /sbin/shorewall.
-
- ipcalc [ <address> <netmask> | <address>/<vlsm>
- ]
-
- Examples:
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0/24
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or dash),
- then the ipcalc command produces incorrect information for IP addresses
- 128.0.0.0-1 and for /1 networks. Bash should produce correct information
- for all valid IP addresses.
-
-
-
An 'iprange' command has been added to /sbin/shorewall.
-
-
- iprange <address>-<address>
-
- This command decomposes a range of IP addressses into a list of
-network and host addresses. The command can be useful if you need to construct
- an efficient set of rules that accept connections from a range of network
- addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic (ash
-or dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
-
- Example:
-
- foo eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The "shorewall check" command now includes the chain name when printing
-the applicable policy for each pair of zones.
-
- Example:
-
- Policy for dmz to net is REJECT using chain all2all
-
- This means that the policy for connections from the dmz to the internet
-is REJECT and the applicable entry in the /etc/shorewall/policy was the all->all
-policy.
-
-
+
+ ipcalc [ <address> <netmask>
+| <address>/<vlsm> ]
+
+Examples:
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+Warning:
+
+If your shell only supports 32-bit signed arithmatic (ash
+or dash), then the ipcalc command produces incorrect information for
+IP addresses 128.0.0.0-1 and for /1 networks. Bash should produce
+correct information for all valid IP addresses.
+
+
+
An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+This command decomposes a range of IP addressses into a list of network
+and host addresses. The command can be useful if you need to construct
+an efficient set of rules that accept connections from a range of
+network addresses.
+
+Note: If your shell only supports 32-bit signed arithmetic (ash or
+dash) then the range may not span 128.0.0.0.
+
+Example:
+
+ [root@gateway root]# shorewall iprange
+192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+
A list of host/net addresses is now allowed in an entry in
+/etc/shorewall/hosts.
+
+Example:
+
+ foo
+eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
The "shorewall check" command now includes the chain name when
+printing the applicable policy for each pair of zones.
+
+ Example:
+
+ Policy for dmz to net is
+REJECT using chain all2all
+
+This means that the policy for connections from the dmz to the internet
+is REJECT and the applicable entry in the /etc/shorewall/policy was the
+all->all policy.
+
+
Support for the 2.6 Kernel series has been added.
-
A problem seen on RH7.3 systems where Shorewall encountered start
- errors when started using the "service" mechanism has been worked around.
-
-
-
Where a list of IP addresses appears in the DEST column of a DNAT[-]
- rule, Shorewall incorrectly created multiple DNAT rules in the nat table
- (one for each element in the list). Shorewall now correctly creates a single
- DNAT rule with multiple "--to-destination" clauses.
-
-
-
Corrected a problem in Beta 1 where DNS names containing a "-" were
- mis-handled when they appeared in the DEST column of a rule.
-
-
-
A number of problems with rule parsing have been corrected. Corrections
- involve the handling of "z1!z2" in the SOURCE column as well as lists in
-the ORIGINAL DESTINATION column.
-
-
-
-
-
Migration Issues:
-
-
-
-
In earlier versions, an undocumented feature allowed entries in
-the host file as follows:
-
- z eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6 to
- allow entries of the following format:
-
- z eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
-removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
- detected by Shorewall (see below).
-
-
-
-
-
New Features:
-
-
-
-
A 'newnotsyn' interface option has been added. This option may be
- specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
- for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in /etc/shorewall/masq
- to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
-address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other than the first
- one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin) over
-a set of servers. Servers may be specified in a range of addresses given
- as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
- have been removed and have been replaced by code that detects whether
-these capabilities are present in the current kernel. The output of the
-start, restart and check commands have been enhanced to report the outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension has been added.
- This extension is available in recent kernel/iptables releases and allows
- for rules which match against elements in netfilter's connection tracking
- table. Shorewall automatically detects the availability of this extension
- and reports its availability in the output of the start, restart and check
- commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
-is changed in the following ways:
-
-
-
To handle 'norfc1918' filtering, Shorewall will not create chains
- in the mangle table but will rather do all 'norfc1918' filtering in the
-filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter rules;
-one in the nat table and one in the filter table. If the Connection Tracking
- Match Extension is available, the rule in the filter table is extended
-to check that the original destination address was the same as specified
-(or defaulted to) in the DNAT rule.
-
-
-
-
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
An 'ipcalc' command has been added to /sbin/shorewall.
-
- ipcalc [ <address> <netmask> | <address>/<vlsm>
- ]
-
- Examples:
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0/24
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or dash),
-then the ipcalc command produces incorrect information for IP addresses
-128.0.0.0-1 and for /1 networks. Bash should produce correct information
-for all valid IP addresses.
-
-
-
An 'iprange' command has been added to /sbin/shorewall.
-
- iprange <address>-<address>
-
- This command decomposes a range of IP addressses into a list of network
- and host addresses. The command can be useful if you need to construct
-an efficient set of rules that accept connections from a range of network
-addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
- then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
-
- Example:
-
- foo eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
-
7/7/2003 - Shorewall-1.4.6 Beta 2
-
-
Problems Corrected:
-
-
-
-
A problem seen on RH7.3 systems where Shorewall encountered start
- errors when started using the "service" mechanism has been worked around.
-
-
-
Where a list of IP addresses appears in the DEST column of a DNAT[-]
- rule, Shorewall incorrectly created multiple DNAT rules in the nat table
- (one for each element in the list). Shorewall now correctly creates a single
- DNAT rule with multiple "--to-destination" clauses.
-
-
-
Corrected a problem in Beta 1 where DNS names containing a "-"
-were mis-handled when they appeared in the DEST column of a rule.
-
-
-
-
-
Migration Issues:
-
-
-
-
In earlier versions, an undocumented feature allowed entries in
-the host file as follows:
-
- z eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6 to
-allow entries of the following format:
-
- z eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
-removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
- detected by Shorewall (see below).
-
-
-
-
-
New Features:
-
-
-
-
A 'newnotsyn' interface option has been added. This option may
-be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
- for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in /etc/shorewall/masq
- to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
-address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other than the first
- one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin) over
- a set of servers. Servers may be specified in a range of addresses given
- as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
- have been removed and have been replaced by code that detects whether
-these capabilities are present in the current kernel. The output of the
-start, restart and check commands have been enhanced to report the outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension has been added.
- This extension is available in recent kernel/iptables releases and allows
- for rules which match against elements in netfilter's connection tracking
- table. Shorewall automatically detects the availability of this extension
- and reports its availability in the output of the start, restart and check
- commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
-is changed in the following ways:
-
-
-
To handle 'norfc1918' filtering, Shorewall will not create chains
- in the mangle table but will rather do all 'norfc1918' filtering in the
- filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter rules;
- one in the nat table and one in the filter table. If the Connection Tracking
- Match Extension is available, the rule in the filter table is extended
-to check that the original destination address was the same as specified
-(or defaulted to) in the DNAT rule.
-
-
-
-
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
An 'ipcalc' command has been added to /sbin/shorewall.
-
- ipcalc [ <address> <netmask> | <address>/<vlsm>
- ]
-
- Examples:
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0/24
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or dash), then
- the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1
- and for /1 networks. Bash should produce correct information for all valid
- IP addresses.
-
-
-
An 'iprange' command has been added to /sbin/shorewall.
-
- iprange <address>-<address>
-
- This command decomposes a range of IP addressses into a list of network
- and host addresses. The command can be useful if you need to construct an
- efficient set of rules that accept connections from a range of network addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
- then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
-
- Example:
-
- foo eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
-
-
-
7/4/2003 - Shorewall-1.4.6 Beta 1
-
-
Problems Corrected:
-
-
-
-
A problem seen on RH7.3 systems where Shorewall encountered start
- errors when started using the "service" mechanism has been worked around.
-
-
-
Where a list of IP addresses appears in the DEST column of a
-DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
-nat table (one for each element in the list). Shorewall now correctly creates
-a single DNAT rule with multiple "--to-destination" clauses.
-
-
-
-
-
New Features:
-
-
-
-
A 'newnotsyn' interface option has been added. This option may
- be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
- for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in /etc/shorewall/masq
- to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
-address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other than the
-first one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin) over
- a set of servers. Up to 256 servers may be specified in a range of addresses
- given as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
- Note that this capability has previously been available using a combination
- of a DNAT- rule and one or more ACCEPT rules. That technique is still
-preferable for load-balancing over a large number of servers (> 16)
-since specifying a range in the DNAT rule causes one filter table ACCEPT
-rule to be generated for each IP address in the range.
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
- have been removed and have been replaced by code that detects whether
-these capabilities are present in the current kernel. The output of the
-start, restart and check commands have been enhanced to report the outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension has been
-added. This extension is available in recent kernel/iptables releases
-and allows for rules which match against elements in netfilter's connection
-tracking table. Shorewall automatically detects the availability of this
-extension and reports its availability in the output of the start, restart
-and check commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
-is changed in the following ways:
-
-
-
-
-
-
-
To handle 'norfc1918' filtering, Shorewall will not create
-chains in the mangle table but will rather do all 'norfc1918' filtering
-in the filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter rules;
- one in the nat table and one in the filter table. If the Connection Tracking
- Match Extension is available, the rule in the filter table is extended
-to check that the original destination address was the same as specified
-(or defaulted to) in the DNAT rule.
-
-
-
-
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
-
-
6/17/2003 - Shorewall-1.4.5
-
-
Problems Corrected:
-
-
-
-
The command "shorewall debug try <directory>" now correctly
- traces the attempt.
-
The INCLUDE directive now works properly in the zones file;
-previously, INCLUDE in that file was ignored.
-
/etc/shorewall/routestopped records with an empty second column
- are no longer ignored.
-
-
-
-
-
New Features:
-
-
-
-
The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may
- now contain a list of addresses. If the list begins with "!' then the
-rule will take effect only if the original destination address in the
-connection request does not match any of the addresses listed.
-
-
-
-
6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
-
-
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and
- iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
- have been encountered with this set of software. The Shorewall version
- is 1.4.4b plus the accumulated changes for 1.4.5.
-
-
-
6/8/2003 - Updated Samples
-
-
Thanks to Francesca Smith, the samples have been updated to Shorewall version
-1.4.4.
-
-
5/29/2003 - Shorewall-1.4.4b
-
-
Groan -- This version corrects a problem whereby the --log-level was not
- being set when logging via syslog. The most commonly reported symptom
- was that Shorewall messages were being written to the console even though
- console logging was correctly configured per FAQ 16.
-
-
-
5/27/2003 - Shorewall-1.4.4a
- The Fireparse --log-prefix fiasco continues. Tuomo Soini has
-pointed out that the code in 1.4.4 restricts the length of short zone
-names to 4 characters. I've produced version 1.4.4a that restores the
-previous 5-character limit by conditionally omitting the log rule number
-when the LOGFORMAT doesn't contain '%d'.
-
-
5/23/2003 - Shorewall-1.4.4
- I apologize for the rapid-fire releases but since there is
-a potential configuration change required to go from 1.4.3a to 1.4.4,
- I decided to make it a full release rather than just a bug-fix release.
-
-
- Problems corrected:
-
-
None.
-
- New Features:
-
-
-
A REDIRECT- rule target has been added. This target behaves
- for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
- nat table REDIRECT rule is added but not the companion filter table
-ACCEPT rule.
-
-
-
The LOGMARKER variable has been renamed LOGFORMAT and
-has been changed to a 'printf' formatting template which accepts three
-arguments (the chain name, logging rule number and the disposition).
-To use LOGFORMAT with fireparse (http://www.fireparse.com), set it
- as:
-
- LOGFORMAT="fp=%s:%d a=%s "
-
- CAUTION: /sbin/shorewall uses the leading part of
- the LOGFORMAT string (up to but not including the first '%') to find
- log messages in the 'show log', 'status' and 'hits' commands. This part
- should not be omitted (the LOGFORMAT should not begin with "%") and
-the leading part should be sufficiently unique for /sbin/shorewall to
-identify Shorewall messages.
-
-
-
When logging is specified on a DNAT[-] or REDIRECT[-]
-rule, the logging now takes place in the nat table rather than in the
-filter table. This way, only those connections that actually undergo
-DNAT or redirection will be logged.
-
-
-
-
-
5/20/2003 - Shorewall-1.4.3a
-
- This version primarily corrects the documentation included
- in the .tgz and in the .rpm. In addition:
-
-
-
(This change is in 1.4.3 but is not documented) If
-you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall
-will return reject replies as follows:
- a) tcp - RST
- b) udp - ICMP port unreachable
- c) icmp - ICMP host unreachable
- d) Otherwise - ICMP host prohibited
- If you are running earlier software, Shorewall will follow
- it's traditional convention:
- a) tcp - RST
- b) Otherwise - ICMP port unreachable
-
UDP port 135 is now silently dropped in the common.def
- chain. Remember that this chain is traversed just before a DROP or
- REJECT policy is enforced.
-
-
-
-
-
5/18/2003 - Shorewall 1.4.3
-
- Problems Corrected:
-
-
-
There were several cases where Shorewall would fail
- to remove a temporary directory from /tmp. These cases have been corrected.
-
The rules for allowing all traffic via the loopback
- interface have been moved to before the rule that drops status=INVALID
- packets. This insures that all loopback traffic is allowed even if
-Netfilter connection tracking is confused.
-
-
- New Features:
-
-
-
IPV6-IPV4 (6to4) tunnels are now supported in the
-/etc/shorewall/tunnels file.
-
You may now change the leading portion of
- the --log-prefix used by Shorewall using the LOGMARKER variable in
- shorewall.conf. By default, "Shorewall:" is used.
-
-
-
-
-
5/10/2003 - Shorewall Mirror in Asia
-
-
-
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
-
-
-
5/8/2003 - Shorewall Mirror in Chile
- Thanks to Darcy Ganga, there is now an HTTP mirror
- in Santiago Chile.
-
4/21/2003 - Samples updated for Shorewall version 1.4.2
-
-
Thanks to Francesca Smith, the sample configurations are now upgraded
-to Shorewall version 1.4.2.
-
-
4/9/2003 - Shorewall 1.4.2
-
-
-
Problems Corrected:
-
-
-
-
-
TCP connection requests rejected out of the
- common chain are now properly rejected with TCP RST;
-previously, some of these requests were rejected with an ICMP port-unreachable
-response.
-
'traceroute -I' from behind the firewall previously
- timed out on the first hop (e.g., to the firewall). This has been
- worked around.
-
-
-
-
-
-
New Features:
-
-
-
Where an entry in the/etc/shorewall/hosts file
- specifies a particular host or network, Shorewall now creates
-an intermediate chain for handling input from the related zone.
-This can substantially reduce the number of rules traversed by connections
- requests from such zones.
-
-
-
Any file may include an INCLUDE directive. An
-INCLUDE directive consists of the word INCLUDE followed by a file
-name and causes the contents of the named file to be logically included
-into the file containing the INCLUDE. File names given in an INCLUDE
-directive are assumed to reside in /etc/shorewall or in an alternate
-configuration directory if one has been specified for the command.
+
A problem seen on RH7.3 systems where Shorewall encountered start
+errors when started using the "service" mechanism has been worked
+around.
-
- Examples:
- shorewall/params.mgmt:
- MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
- TIME_SERVERS=4.4.4.4
- BACKUP_SERVERS=5.5.5.5
- ----- end params.mgmt -----
-
-
- shorewall/params:
- # Shorewall 1.3 /etc/shorewall/params
- [..]
- #######################################
-
- INCLUDE params.mgmt
-
- # params unique to this host here
- #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
-DO NOT REMOVE
- ----- end params -----
-
-
- shorewall/rules.mgmt:
- ACCEPT net:$MGMT_SERVERS $FW tcp
- 22
- ACCEPT $FW net:$TIME_SERVERS udp
- 123
- ACCEPT $FW net:$BACKUP_SERVERS tcp
- 22
- ----- end rules.mgmt -----
-
- shorewall/rules:
- # Shorewall version 1.3 - Rules File
- [..]
- #######################################
-
- INCLUDE rules.mgmt
-
- # rules unique to this host here
- #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE
--- DO NOT REMOVE
- ----- end rules -----
-
- INCLUDE's may be nested to a level of 3 -- further
- nested INCLUDE directives are ignored with a warning message.
-
-
-
Routing traffic from an interface back out that
- interface continues to be a problem. While I firmly believe that
- this should never happen, people continue to want to do it. To limit
- the damage that such nonsense produces, I have added a new 'routeback'
- option in /etc/shorewall/interfaces and /etc/shorewall/hosts. When
-used in /etc/shorewall/interfaces, the 'ZONE' column may not contain
- '-'; in other words, 'routeback' can't be used as an option for a multi-zone
- interface. The 'routeback' option CAN be specified however on individual
- group entries in /etc/shorewall/hosts.
-
- The 'routeback' option is similar to the old 'multi'
- option with two exceptions:
-
- a) The option pertains to a particular zone,interface,address
- tuple.
-
- b) The option only created infrastructure to pass
- traffic from (zone,interface,address) tuples back to themselves
- (the 'multi' option affected all (zone,interface,address) tuples
- associated with the given 'interface').
-
- See the 'Upgrade Issues'
- for information about how this new option may affect your configuration.
-
-
+
+
Where a list of IP addresses appears in the DEST column of
+a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in
+the nat table (one for each element in the list). Shorewall now
+correctly
+creates a single DNAT rule with multiple "--to-destination" clauses.
+
+
+
Corrected a problem in Beta 1 where DNS names containing a
+"-" were mis-handled when they appeared in the DEST column of a rule.
+
+
+
A number of problems with rule parsing have been corrected.
+Corrections involve the handling of "z1!z2" in the SOURCE column as
+well as lists in the ORIGINAL DESTINATION column.
+
-
-
3/24/2003 - Shorewall 1.4.1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0
-and removes additional warts.
-
- Problems Corrected:
-
-
+
Migration Issues:
+
-
When Shorewall 1.4.0 is run under the ash shell
- (such as on Bering/LEAF), it can attempt to add ECN disabling
-rules even if the /etc/shorewall/ecn file is empty. That problem
-has been corrected so that ECN disabling rules are only added if
-there are entries in /etc/shorewall/ecn.
-
+
In earlier versions, an undocumented feature allowed entries in
+the host file as follows:
+
+ z
+eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+This capability was never documented and has been removed in 1.4.6 to
+allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have
+been removed from /etc/shorewall/shorewall.conf. These capabilities are
+now automatically detected by Shorewall (see below).
+
- New Features:
-
+
New Features:
+
+
+
A 'newnotsyn' interface option has been added. This option
+may be specified in /etc/shorewall/interfaces and overrides the setting
+NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+
The means for specifying a range of IP addresses in
+/etc/shorewall/masq to use for SNAT is now documented.
+ADD_SNAT_ALIASES=Yes is enabled for address ranges.
+
+
+
Shorewall can now add IP addresses to subnets other than the
+first one on an interface.
+
+
+
DNAT[-] rules may now be used to load balance (round-robin) over
+a set of servers. Servers may be specified in a range of addresses
+given as <first address>-<last address>.
+
+Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
+options have been removed and have been replaced by code that detects
+whether these capabilities are present in the current kernel. The
+output of the start, restart and check commands have been enhanced to
+report the
+outcome:
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+Verifying Configuration...
+
+
+
Support for the Connection Tracking Match Extension has been
+added. This extension is available in recent kernel/iptables releases
+and allows for rules which match against elements in netfilter's
+connection tracking table. Shorewall automatically detects the
+availability of
+this extension and reports its availability in the output of the start,
+restart and check commands.
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+Verifying Configuration...
+
+If this extension is available, the ruleset generated by Shorewall is
+changed in the following ways:
+
+
To handle 'norfc1918' filtering, Shorewall will not create
+chains in the mangle table but will rather do all 'norfc1918' filtering
+in the filter table (rfc1918 chain).
+
Recall that Shorewall DNAT rules generate two netfilter rules;
+one in the nat table and one in the filter table. If the Connection
+Tracking Match Extension is available, the rule in the filter table is
+extended to check that the original destination address was the same as
+specified (or defaulted to) in the DNAT rule.
+
+
+
+
The shell used to interpret the firewall script
+(/usr/share/shorewall/firewall) may now be specified using the
+SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+
An 'ipcalc' command has been added to /sbin/shorewall.
+
+ ipcalc [ <address> <netmask>
+| <address>/<vlsm> ]
+
+Examples:
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+Warning:
+
+If your shell only supports 32-bit signed arithmatic (ash or dash),
+then the ipcalc command produces incorrect information for IP addresses
+128.0.0.0-1 and for /1 networks. Bash should produce correct
+information for all valid IP addresses.
+
+
+
An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+This command decomposes a range of IP addressses into a list of network
+and host addresses. The command can be useful if you need to construct
+an efficient set of rules that accept connections from a range of
+network addresses.
+
+Note: If your shell only supports 32-bit signed arithmetic (ash or
+dash) then the range may not span 128.0.0.0.
+
+Example:
+
+ [root@gateway root]# shorewall iprange
+192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+
A list of host/net addresses is now allowed in an entry in
+/etc/shorewall/hosts.
+
+Example:
+
+ foo
+eth1:192.168.1.0/24,192.168.2.0/24
+
+
7/7/2003 - Shorewall-1.4.6 Beta 2
+
Problems Corrected:
+
+
+
A problem seen on RH7.3 systems where Shorewall encountered start
+errors when started using the "service" mechanism has been worked
+around.
+
+
+
Where a list of IP addresses appears in the DEST column of a
+DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
+nat table (one for each element in the list). Shorewall now correctly
+creates a single DNAT rule with multiple "--to-destination" clauses.
+
+
+
Corrected a problem in Beta 1 where DNS names containing a "-"
+were mis-handled when they appeared in the DEST column of a rule.
+
+
+
Migration Issues:
+
+
+
In earlier versions, an undocumented feature allowed entries in
+the host file as follows:
+
+ z
+eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+This capability was never documented and has been removed in 1.4.6 to
+allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
+removed from /etc/shorewall/shorewall.conf. These capabilities are now
+automatically detected by Shorewall (see below).
+
+
+
New Features:
+
+
+
A 'newnotsyn' interface option has been added. This option may be
+specified in /etc/shorewall/interfaces and overrides the setting
+NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+
The means for specifying a range of IP addresses in
+/etc/shorewall/masq to use for SNAT is now documented.
+ADD_SNAT_ALIASES=Yes is enabled for address ranges.
+
+
+
Shorewall can now add IP addresses to subnets other than the
+first one on an interface.
+
+
+
DNAT[-] rules may now be used to load balance (round-robin) over
+a set of servers. Servers may be specified in a range of addresses
+given as <first address>-<last address>.
+
+Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
+options have been removed and have been replaced by code that detects
+whether these capabilities are present in the current kernel. The
+output of the start, restart and check commands have been enhanced to
+report
+the outcome:
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+Verifying Configuration...
+
+
+
Support for the Connection Tracking Match Extension has been
+added. This extension is available in recent kernel/iptables releases
+and allows for rules which match against elements in netfilter's
+connection tracking table. Shorewall automatically detects the
+availability of this extension and reports its availability in the
+output of the start, restart and check commands.
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+Verifying Configuration...
+
+If this extension is available, the ruleset generated by Shorewall is
+changed in the following ways:
+
+
To handle 'norfc1918' filtering, Shorewall will not create
+chains in the mangle table but will rather do all 'norfc1918' filtering
+in the filter table (rfc1918 chain).
+
Recall that Shorewall DNAT rules generate two netfilter
+rules; one in the nat table and one in the filter table. If the
+Connection Tracking Match Extension is available, the rule in the
+filter table is extended to check that the original destination address
+was the same as specified (or defaulted to) in the DNAT rule.
+
+
+
+
The shell used to interpret the firewall script
+(/usr/share/shorewall/firewall) may now be specified using the
+SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+
An 'ipcalc' command has been added to /sbin/shorewall.
+
+ ipcalc [ <address> <netmask>
+| <address>/<vlsm> ]
+
+Examples:
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+Warning:
+
+If your shell only supports 32-bit signed arithmatic (ash or dash),
+then the ipcalc command produces incorrect information for IP addresses
+128.0.0.0-1 and for /1 networks. Bash should produce correct
+information for all valid IP addresses.
+
+
+
An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+This command decomposes a range of IP addressses into a list of
+network and host addresses. The command can be useful if you need to
+construct an efficient set of rules that accept connections from a
+range
+of network addresses.
+
+Note: If your shell only supports 32-bit signed arithmetic (ash
+or dash) then the range may not span 128.0.0.0.
+
+Example:
+
+ [root@gateway root]# shorewall iprange
+192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+
A list of host/net addresses is now allowed in an entry in
+/etc/shorewall/hosts.
+
+Example:
+
+ foo
+eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
+
7/4/2003 - Shorewall-1.4.6 Beta 1
+
Problems Corrected:
+
+
+
A problem seen on RH7.3 systems where Shorewall encountered start
+errors when started using the "service" mechanism has been worked
+around.
+
+
+
Where a list of IP addresses appears in the DEST column
+of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
+in the nat table (one for each element in the list). Shorewall now
+correctly creates a single DNAT rule with multiple "--to-destination"
+clauses.
+
+
+
New Features:
+
+
+
A 'newnotsyn' interface option has been added. This option may be
+specified in /etc/shorewall/interfaces and overrides the setting
+NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+
The means for specifying a range of IP addresses in
+/etc/shorewall/masq to use for SNAT is now documented.
+ADD_SNAT_ALIASES=Yes is enabled for address ranges.
+
+
+
Shorewall can now add IP addresses to subnets other than the
+first one on an interface.
+
+
+
DNAT[-] rules may now be used to load balance (round-robin) over
+a set of servers. Up to 256 servers may be specified in a range
+of addresses given as <first address>-<last address>.
+
+Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+Note that this capability has previously been available using
+a combination of a DNAT- rule and one or more ACCEPT rules. That
+technique is still preferable for load-balancing over a large number of
+servers
+(> 16) since specifying a range in the DNAT rule causes one filter
+table ACCEPT rule to be generated for each IP address in the range.
+
+
+
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
+options have been removed and have been replaced by code that detects
+whether these capabilities are present in the current kernel. The
+output of the start, restart and check commands have been enhanced to
+report
+the outcome:
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+Verifying Configuration...
+
+
+
Support for the Connection Tracking Match Extension has
+been added. This extension is available in recent kernel/iptables
+releases and allows for rules which match against elements in
+netfilter's connection tracking table. Shorewall automatically detects
+the availability of this extension and reports its availability in the
+output of the start, restart and check commands.
+
+Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+Verifying Configuration...
+
+If this extension is available, the ruleset generated by Shorewall is
+changed in the following ways:
+
+
+
+
To handle 'norfc1918' filtering, Shorewall will not create
+chains in the mangle table but will rather do all 'norfc1918' filtering
+in the filter table (rfc1918 chain).
+
Recall that Shorewall DNAT rules generate two netfilter rules;
+one in the nat table and one in the filter table. If the Connection
+Tracking Match Extension is available, the rule in the filter table is
+extended to check that the original destination address was the same as
+specified (or defaulted to) in the DNAT rule.
+
+
+
+
The shell used to interpret the firewall script
+(/usr/share/shorewall/firewall) may now be specified using the
+SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+
6/17/2003 - Shorewall-1.4.5
+
Problems Corrected:
+
+
+
The command "shorewall debug try <directory>" now correctly
+traces the attempt.
+
The INCLUDE directive now works properly in the zones file;
+previously, INCLUDE in that file was ignored.
+
/etc/shorewall/routestopped records with an empty second column
+are no longer ignored.
+
+
+
New Features:
+
+
+
The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
+contain a list of addresses. If the list begins with "!' then the rule
+will take effect only if the original destination address in the
+connection request does not match any of the addresses listed.
+
+
6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
+
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
+and iptables 1.2.8 (using the "official" RPM from netfilter.org). No
+problems have been encountered with this set of software. The Shorewall
+version is 1.4.4b plus the accumulated changes for 1.4.5.
+
+
6/8/2003 - Updated Samples
+
Thanks to Francesca Smith, the samples have been updated to
+Shorewall
+version 1.4.4.
+
5/29/2003 - Shorewall-1.4.4b
+
Groan -- This version corrects a problem whereby the --log-level was
+not being set when logging via syslog. The most commonly reported
+symptom was that Shorewall messages were being written to the console
+even though console logging was correctly configured per FAQ 16.
+
+
5/27/2003 - Shorewall-1.4.4a
+The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed
+out that the code in 1.4.4 restricts the length of short zone names to
+4 characters. I've produced version 1.4.4a that restores the previous
+5-character limit by conditionally omitting the log
+rule number when the LOGFORMAT doesn't contain '%d'.
+
5/23/2003 - Shorewall-1.4.4
+I apologize for the rapid-fire releases but since there is a potential
+configuration change required to go from 1.4.3a to 1.4.4, I decided to
+make it a full release rather than just a bug-fix release.
+
+ Problems corrected:
+
None.
+
+ New Features:
+
+
+
A REDIRECT- rule target has been added. This target behaves for
+REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
+nat table REDIRECT rule is added but not the companion filter table
+ACCEPT rule.
+
+
+
The LOGMARKER variable has been renamed LOGFORMAT and has been
+changed to a 'printf' formatting template which accepts three arguments
+(the chain name, logging rule number and the disposition). To use
+LOGFORMAT with fireparse (http://www.fireparse.com),
+set it as:
+
+ LOGFORMAT="fp=%s:%d a=%s "
+
+ CAUTION: /sbin/shorewall uses the leading part of the
+LOGFORMAT string (up to but not including the first '%')
+to find log messages in the 'show log', 'status' and 'hits' commands.
+This part should not be omitted (the LOGFORMAT should not begin with
+"%") and the leading part should be sufficiently unique for
+/sbin/shorewall to identify Shorewall messages.
+
+
+
When logging is specified on a DNAT[-] or REDIRECT[-] rule, the
+logging now takes place in the nat table rather than in the filter
+table. This way, only those connections that actually
+undergo DNAT or redirection will be logged.
+
+
+
5/20/2003 - Shorewall-1.4.3a
+
+This version primarily corrects the documentation included in the .tgz
+and in the .rpm. In addition:
+
+
(This change is in 1.4.3 but is not documented) If you are
+running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return
+reject replies as follows:
+ a) tcp - RST
+ b) udp - ICMP port unreachable
+ c) icmp - ICMP host unreachable
+ d) Otherwise - ICMP host prohibited
+If you are running earlier software, Shorewall will follow it's
+traditional convention:
+ a) tcp - RST
+ b) Otherwise - ICMP port unreachable
+
UDP port 135 is now silently dropped in the common.def chain.
+Remember that this chain is traversed just before a DROP or REJECT
+policy is enforced.
+
+
+
5/18/2003 - Shorewall 1.4.3
+
+ Problems Corrected:
+
+
+
There were several cases where Shorewall would fail to remove a
+temporary directory from /tmp. These cases have
+been corrected.
+
The rules for allowing all traffic via the loopback interface
+have been moved to before the rule that drops status=INVALID packets.
+This insures that all loopback traffic is allowed even if Netfilter
+connection tracking is confused.
+
+ New Features:
+
+
+
IPV6-IPV4 (6to4) tunnels are now supported in the
+/etc/shorewall/tunnels file.
+
You may now change the leading portion of the
+--log-prefix used by Shorewall using the LOGMARKER variable in
+shorewall.conf. By default, "Shorewall:" is used.
+
+
+
5/10/2003 - Shorewall Mirror in Asia
+
+
Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
+
+
5/8/2003 - Shorewall Mirror in Chile
+Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
+
4/21/2003 - Samples updated for Shorewall version 1.4.2
+
Thanks to Francesca Smith, the sample configurations are now
+upgraded to
+Shorewall version 1.4.2.
+
4/9/2003 - Shorewall 1.4.2
+
+
Problems Corrected:
+
+
+
TCP connection requests rejected out of the common
+chain are now properly rejected with
+TCP RST; previously, some of these requests were rejected with
+an ICMP port-unreachable response.
+
'traceroute -I' from behind the firewall previously timed out
+on the first hop (e.g., to the firewall). This has been worked around.
+
+
+
New Features:
+
+
Where an entry in the/etc/shorewall/hosts file specifies a
+particular host or network, Shorewall now creates an intermediate chain
+for handling input from the related zone. This can substantially reduce
+the number of rules traversed by connections requests from such zones.
+
+
+
Any file may include an INCLUDE directive. An INCLUDE directive
+consists of the word INCLUDE followed by a file name and causes the
+contents of the named file to be logically included into the file
+containing the INCLUDE. File names given in an INCLUDE directive are
+assumed to reside in /etc/shorewall or
+in an alternate configuration directory if one has been specified for
+the command.
+
+ Examples:
+ shorewall/params.mgmt:
+ MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
+ TIME_SERVERS=4.4.4.4
+ BACKUP_SERVERS=5.5.5.5
+ ----- end params.mgmt -----
+
+
+ shorewall/params:
+ # Shorewall 1.3 /etc/shorewall/params
+ [..]
+ #######################################
+
+ INCLUDE params.mgmt
+
+ # params unique to this host here
+ #LAST LINE - ADD YOUR ENTRIES ABOVE THIS
+ONE - DO NOT REMOVE
+ ----- end params -----
+
+
+ shorewall/rules.mgmt:
+ ACCEPT
+net:$MGMT_SERVERS
+$FW
+tcp 22
+ ACCEPT
+$FW
+net:$TIME_SERVERS
+udp 123
+ ACCEPT
+$FW
+net:$BACKUP_SERVERS
+tcp 22
+ ----- end rules.mgmt -----
+
+ shorewall/rules:
+ # Shorewall version 1.3 - Rules File
+ [..]
+ #######################################
+
+ INCLUDE rules.mgmt
+
+ # rules unique to this host here
+ #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
+REMOVE
+ ----- end rules -----
+
+INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
+directives are ignored with a warning message.
+
+
+
Routing traffic from an interface back out that interface
+continues to be a problem. While I firmly believe that this should
+never happen, people continue to want to do it. To limit the damage
+that such nonsense produces, I have added a new 'routeback' option in
+/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
+/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in
+other words, 'routeback' can't be used as an option for a multi-zone
+interface. The 'routeback' option CAN be specified however on
+individual group entries in /etc/shorewall/hosts.
+
+The 'routeback' option is similar to the old 'multi' option with two
+exceptions:
+
+ a) The option pertains to a particular
+zone,interface,address tuple.
+
+ b) The option only created infrastructure to pass traffic
+from (zone,interface,address) tuples back to themselves (the 'multi'
+option affected all (zone,interface,address) tuples associated with the
+given 'interface').
+
+See the 'Upgrade Issues' for
+information about how this new option may affect your configuration.
+
+
+
3/24/2003 - Shorewall 1.4.1
+
+
This release follows up on 1.4.0. It corrects a problem introduced
+in
+1.4.0 and removes additional warts.
+
+Problems Corrected:
+
+
+
When Shorewall 1.4.0 is run under the ash shell (such as on
+Bering/LEAF), it can attempt to add ECN disabling rules even if the
+/etc/shorewall/ecn file is empty. That problem has been corrected so
+that ECN disabling rules are only added if there are entries in
+/etc/shorewall/ecn.
+
+New Features:
Note: In the list that follows, the term group refers
-to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be
-a host address) accessed through a particular interface. Examples:
-
-
+to
+a particular network or subnetwork (which may be 0.0.0.0/0 or it may be
+a
+host address) accessed through a particular interface. Examples:
- You can use the "shorewall check" command to see
-the groups associated with each of your zones.
-
-
+eth2:192.168.1.0/24
+eth3:192.0.2.123
+
+You can use the "shorewall check" command to see the groups associated
+with each of your zones.
+
-
Beginning with Shorewall 1.4.1, if a zone Z
-comprises more than one groupthen if there is no explicit
-Z to Z policy and there are no rules governing traffic from Z to
-Z then Shorewall will permit all traffic between the groups in the
-zone.
-
Beginning with Shorewall 1.4.1, Shorewall will
- never create rules to handle traffic from a group to itself.
-
A NONE policy is introduced in 1.4.1. When a
-policy of NONE is specified from Z1 to Z2:
-
+
Beginning with Shorewall 1.4.1, if a zone Z comprises more than
+one groupthen if there is no explicit Z to Z policy and there
+are no rules governing traffic from Z to Z then Shorewall will permit
+all traffic between the groups in the zone.
+
Beginning with Shorewall 1.4.1, Shorewall will never create rules
+to handle traffic from a group to itself.
+
A NONE policy is introduced in 1.4.1. When a policy of NONE is
+specified from Z1 to Z2:
-
-
There may be no rules created that govern connections
- from Z1 to Z2.
-
Shorewall will not create any infrastructure
-to handle traffic from Z1 to Z2.
-
+
There may be no rules created that govern connections from Z1 to
+Z2.
+
Shorewall will not create any infrastructure to handle traffic
+from Z1 to Z2.
- See the upgrade issues
- for a discussion of how these changes may affect your configuration.
-
-
3/17/2003 - Shorewall 1.4.0
-
-Shorewall 1.4 represents the next step in the evolution of
-Shorewall. The main thrust of the initial release is simply to
-remove the cruft that has accumulated in Shorewall over time.
-
- IMPORTANT: Shorewall 1.4.0 requiresthe
- iproute package ('ip' utility).
-
- Function from 1.3 that has been omitted
-from this version include:
-
+See the upgrade issues for a
+discussion of how these changes may affect
+your configuration.
+
3/17/2003 - Shorewall 1.4.0
+Shorewall 1.4 represents the next step in the evolution of Shorewall.
+The main thrust of the initial release is simply to remove the cruft
+that has accumulated in Shorewall over time.
+
+IMPORTANT: Shorewall 1.4.0 requiresthe iproute package
+('ip' utility).
+
+Function from 1.3 that has been omitted from this version include:
-
The MERGE_HOSTS variable in shorewall.conf
- is no longer supported. Shorewall 1.4 behavior is the same as
-1.3 with MERGE_HOSTS=Yes.
-
-
-
Interface names of the form <device>:<integer>
- in /etc/shorewall/interfaces now generate an error.
-
-
-
Shorewall 1.4 implements behavior consistent
- with OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate
- an error at startup as will specification of the 'noping'
-or 'filterping' interface options.
-
-
-
The 'routestopped' option in the /etc/shorewall/interfaces
- and /etc/shorewall/hosts files is no longer supported and
-will generate an error at startup if specified.
-
-
-
The Shorewall 1.2 syntax for DNAT and
- REDIRECT rules is no longer accepted.
-
-
-
The ALLOWRELATED variable in shorewall.conf
- is no longer supported. Shorewall 1.4 behavior is the same as
- 1.3 with ALLOWRELATED=Yes.
-
-
-
The icmp.def file has been removed.
-
-
+
The MERGE_HOSTS variable in shorewall.conf is no longer
+supported. Shorewall 1.4 behavior is the same as 1.3 with
+MERGE_HOSTS=Yes.
+
+
+
Interface names of the form <device>:<integer> in
+/etc/shorewall/interfaces now generate an error.
+
+
+
Shorewall 1.4 implements behavior consistent with
+OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error at
+startup as will specification of the 'noping' or 'filterping' interface
+options.
+
+
+
The 'routestopped' option in the /etc/shorewall/interfaces and
+/etc/shorewall/hosts files is no longer supported and will generate an
+error at startup if specified.
+
+
+
The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
+accepted.
+
+
+
The ALLOWRELATED variable in shorewall.conf is no longer
+supported. Shorewall 1.4 behavior is the same as 1.3 with
+ALLOWRELATED=Yes.
+
+
+
The icmp.def file has been removed.
+
- Changes for 1.4 include:
-
+Changes for 1.4 include:
-
The /etc/shorewall/shorewall.conf file
- has been completely reorganized into logical sections.
-
-
-
LOG is now a valid action for a rule
- (/etc/shorewall/rules).
-
-
-
The firewall script and version file
- are now installed in /usr/share/shorewall.
-
-
-
Late arriving DNS replies are now silently
- dropped in the common chain by default.
-
-
-
In addition to behaving like OLD_PING_HANDLING=No,
- Shorewall 1.4 no longer unconditionally accepts outbound
-ICMP packets. So if you want to 'ping' from the firewall, you
-will need the appropriate rule or policy.
-
-
-
CONTINUE is now a valid action for a rule
-(/etc/shorewall/rules).
-
-
-
802.11b devices with names of the form wlan<n>
- now support the 'maclist' option.
-
-
-
Explicit Congestion Notification (ECN - RFC
- 3168) may now be turned off on a host or network basis using the
- new /etc/shorewall/ecn file. To use this facility:
-
- a) You must be running kernel 2.4.20
- b) You must have applied the patch in
- http://www.shorewall/net/pub/shorewall/ecn/patch.
- c) You must have iptables 1.2.7a installed.
-
-
-
The /etc/shorewall/params file is now processed
- first so that variables may be used in the /etc/shorewall/shorewall.conf
- file.
-
-
-
Shorewall now gives a more helpful
- diagnostic when the 'ipchains' compatibility kernel module is
-loaded and a 'shorewall start' command is issued.
-
-
-
The SHARED_DIR variable has been removed from
- shorewall.conf. This variable was for use by package maintainers
- and was not documented for general use.
-
-
-
Shorewall now ignores 'default' routes when
- detecting masq'd networks.
-
+
The /etc/shorewall/shorewall.conf file has been completely
+reorganized into logical sections.
+
+
+
LOG is now a valid action for
+a rule (/etc/shorewall/rules).
+
+
+
The firewall script and version file are now installed in
+/usr/share/shorewall.
+
+
+
Late arriving DNS replies are
+now silently dropped in the common chain by default.
+
+
+
In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4
+no longer unconditionally accepts outbound ICMP packets. So if you want
+to 'ping' from the firewall, you will need the appropriate rule or
+policy.
+
+
+
CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
+
+
+
802.11b devices with names of the form wlan<n> now support
+the 'maclist' option.
+
+
+
Explicit Congestion Notification (ECN - RFC 3168) may now be
+turned off on a host or network basis using the new /etc/shorewall/ecn
+file. To use this facility:
+
+ a) You must be running kernel 2.4.20
+ b) You must have applied the patch in
+ http://www.shorewall/net/pub/shorewall/ecn/patch.
+ c) You must have iptables 1.2.7a installed.
+
+
+
The /etc/shorewall/params file is now processed first so that
+variables may be used in the /etc/shorewall/shorewall.conf file.
+
+
+
Shorewall now gives a more helpful diagnostic when the
+'ipchains' compatibility kernel module is loaded and a 'shorewall
+start' command is issued.
+
+
+
The SHARED_DIR variable has been removed from shorewall.conf.
+This variable was for use by package
+maintainers and was not documented for general use.
+
+
+
Shorewall now ignores 'default' routes when detecting masq'd
+networks.
-
3/10/2003 - Shoreall 1.3.14a
-
A roleup of the following bug fixes and other updates:
-
-
There is an updated rfc1918 file that reflects
- the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
-
+
There is an updated rfc1918 file that
+reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
-
-
The documentation for the routestopped file
-claimed that a comma-separated list could appear in the second
-column while the code only supported a single host or network address.
-
Log messages produced by 'logunclean' and 'dropunclean'
- were not rate-limited.
-
802.11b devices with names of the form wlan<n>
- don't support the 'maclist' interface option.
-
Log messages generated by RFC 1918 filtering
- are not rate limited.
-
The firewall fails to start in the case where
- you have "eth0 eth1" in /etc/shorewall/masq and the default route
- is through eth1
-
+
The documentation for the routestopped file claimed that a
+comma-separated list could appear in the second column while the code
+only supported a single host or network address.
+
Log messages produced by 'logunclean'
+and 'dropunclean' were not rate-limited.
+
802.11b devices with names of the form wlan<n>
+don't support the 'maclist' interface option.
+
Log messages generated by RFC 1918 filtering are not rate limited.
+
The firewall fails to start in the case where you have "eth0
+eth1" in /etc/shorewall/masq and the default route is through eth1
-
2/8/2003 - Shoreawall 1.3.14
-
New features include
-
-
An OLD_PING_HANDLING option has
-been added to shorewall.conf. When set to Yes, Shorewall
-ping handling is as it has always been (see http://www.shorewall.net/ping.html).
-
- When OLD_PING_HANDLING=No, icmp
-echo (ping) is handled via rules and policies just like
-any other connection request. The FORWARDPING=Yes option
-in shorewall.conf and the 'noping' and 'filterping' options in
- /etc/shorewall/interfaces will all generate an error.
-
-
-
It is now possible to direct Shorewall
- to create a "label" such as "eth0:0" for IP addresses
-that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
- This is done by specifying the label instead of just the interface
- name:
-
- a) In the INTERFACE column of
-/etc/shorewall/masq
- b) In the INTERFACE column of
-/etc/shorewall/nat
-
-
Support for OpenVPN Tunnels.
-
-
-
Support for VLAN devices with names
- of the form $DEV.$VID (e.g., eth0.0)
-
-
-
In /etc/shorewall/tcrules, the MARK
- value may be optionally followed by ":" and either 'F' or 'P'
- to designate that the marking will occur in the FORWARD or PREROUTING
- chains respectively. If this additional specification is omitted,
- the chain used to mark packets will be determined by the setting
- of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
-
-
-
When an interface name is entered
- in the SUBNET column of the /etc/shorewall/masq file, Shorewall
- previously masqueraded traffic from only the first subnet
- defined on that interface. It did not masquerade traffic from:
-
- a) The subnets associated with
- other addresses on the interface.
- b) Subnets accessed through local
- routers.
-
- Beginning with Shorewall 1.3.14,
-if you enter an interface name in the SUBNET column, shorewall
- will use the firewall's routing table to construct the masquerading/SNAT
- rules.
-
- Example 1 -- This is how it works
- in 1.3.14.
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254
-
-
-
-
-
[root@gateway test]# shorewall start ... Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176 To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176 Processing /etc/shorewall/tos...
-
- When upgrading to Shorewall 1.3.14,
- if you have multiple local subnets connected to an interface
- that is specified in the SUBNET column of an /etc/shorewall/masq
- entry, your /etc/shorewall/masq file will need changing. In
- most cases, you will simply be able to remove redundant entries.
- In some cases though, you might want to change from using the interface
- name to listing specific subnetworks if the change described above
- will cause masquerading to occur on subnetworks that you don't wish
-to masquerade.
-
- Example 2 -- Suppose that your current
- config is as follows:
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 192.168.10.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
-
- In this case, the second entry
- in /etc/shorewall/masq is no longer required.
-
- Example 3 -- What if your current
- configuration is like this?
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
-
- In this case, you would want
-to change the entry in /etc/shorewall/masq to:
-
-
-
-
-
#INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
An OLD_PING_HANDLING option has been added to shorewall.conf.
+When set to Yes, Shorewall ping handling is as it has always been (see
+http://www.shorewall.net/ping.html).
+
+When OLD_PING_HANDLING=No,
+icmp echo (ping) is handled via rules and policies just
+like any other connection request. The FORWARDPING=Yes option in
+shorewall.conf and the 'noping' and 'filterping' options in
+/etc/shorewall/interfaces will all generate an error.
+
+
+
It is now possible to direct Shorewall to create a "label" such
+as "eth0:0" for IP addresses that it creates under
+ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
+the label instead of just the interface name:
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+
+
Support for OpenVPN Tunnels.
+
+
+
Support for VLAN devices with names of the form $DEV.$VID (e.g.,
+eth0.0)
+
+
+
In /etc/shorewall/tcrules, the MARK value may be optionally
+followed by ":" and either 'F' or 'P' to designate that the marking
+will occur in the FORWARD or PREROUTING chains respectively. If this
+additional specification is omitted, the chain used to mark packets
+will be determined by the setting of the MARK_IN_FORWARD_CHAIN option
+in shorewall.conf.
+
+
+
When an interface name is
+entered in the SUBNET column of the /etc/shorewall/masq file, Shorewall
+previously masqueraded traffic from only
+the first subnet defined on that interface. It did not masquerade
+traffic from:
+
+ a) The subnets associated with other addresses on the
+interface.
+ b) Subnets accessed through local routers.
+
+Beginning with Shorewall 1.3.14, if you enter an interface name in the
+SUBNET column,
+shorewall will use the firewall's routing table to construct the
+masquerading/SNAT rules.
+
+Example 1 -- This is how it works in 1.3.14.
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+
[root@gateway test]# shorewall start ... Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176 To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176 Processing /etc/shorewall/tos...
+
+When upgrading to Shorewall 1.3.14, if you have multiple local subnets
+connected to an interface that is specified in the SUBNET column of an
+/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
+changing. In most cases, you will simply be able to remove redundant
+entries. In some cases though, you might want to change from using the
+interface name to listing specific subnetworks if the change described
+above will cause masquerading to occur on subnetworks that you don't
+wish to masquerade.
+
+Example 2 -- Suppose that your current config is as follows:
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 192.168.10.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
+
+ In this case, the second entry in /etc/shorewall/masq is
+no longer required.
+
+Example 3 -- What if your current configuration is like this?
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
+
+ In this case, you would
+want to change the entry in /etc/shorewall/masq to:
+
#INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
-
- 2/5/2003 - Shorewall Support included
- in Webmin 1.060
-
-
Webmin version 1.060 now has Shorewall support included as standard. See
- http://www.webmin.com.
-
- 2/4/2003 - Shorewall 1.3.14-RC1
-
-
+2/5/2003 - Shorewall Support
+included in Webmin 1.060
+
Webmin version 1.060 now has Shorewall support included as standard.
+See http://www.webmin.com.
+
+2/4/2003 - Shorewall 1.3.14-RC1
Includes the Beta 2 content plus support for OpenVPN tunnels.
-
-
1/28/2003 - Shorewall 1.3.14-Beta2
-
-
-
Includes the Beta 1 content plus restores VLAN device names of the form
- $dev.$vid (e.g., eth0.1)
-
-
+
Includes the Beta 1 content plus restores VLAN device names of the
+form $dev.$vid (e.g., eth0.1)
1/25/2003 - Shorewall 1.3.14-Beta1
-
-
-
+
The Beta includes the following changes:
-
-
-
+
-
An OLD_PING_HANDLING option
- has been added to shorewall.conf. When set to Yes, Shorewall
- ping handling is as it has always been (see http://www.shorewall.net/ping.html).
-
- When OLD_PING_HANDLING=No, icmp
-echo (ping) is handled via rules and policies just like
-any other connection request. The FORWARDPING=Yes option
-in shorewall.conf and the 'noping' and 'filterping' options in
- /etc/shorewall/interfaces will all generate an error.
-
-
-
It is now possible to direct
- Shorewall to create a "label" such as "eth0:0" for IP addresses
- that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
- This is done by specifying the label instead of just the interface
- name:
-
- a) In the INTERFACE column of
-/etc/shorewall/masq
- b) In the INTERFACE column of
-/etc/shorewall/nat
-
-
When an interface name is
-entered in the SUBNET column of the /etc/shorewall/masq
- file, Shorewall previously masqueraded traffic from only
-the first subnet defined on that interface. It did not masquerade
- traffic from:
-
- a) The subnets associated with
- other addresses on the interface.
- b) Subnets accessed through local
- routers.
-
- Beginning with Shorewall 1.3.14,
-if you enter an interface name in the SUBNET column, shorewall
- will use the firewall's routing table to construct the masquerading/SNAT
- rules.
-
- Example 1 -- This is how it works
- in 1.3.14.
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254
-
-
-
-
-
[root@gateway test]# shorewall start ... Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176 To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176 Processing /etc/shorewall/tos...
-
- When upgrading to Shorewall 1.3.14,
- if you have multiple local subnets connected to an interface
- that is specified in the SUBNET column of an /etc/shorewall/masq
- entry, your /etc/shorewall/masq file will need changing. In
- most cases, you will simply be able to remove redundant entries.
- In some cases though, you might want to change from using the interface
- name to listing specific subnetworks if the change described above
- will cause masquerading to occur on subnetworks that you don't wish
-to masquerade.
-
- Example 2 -- Suppose that your current
- config is as follows:
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 192.168.10.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
-
- In this case, the second entry
- in /etc/shorewall/masq is no longer required.
-
- Example 3 -- What if your current
- configuration is like this?
-
-
-
-
-
-
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
-
- In this case, you would want
-to change the entry in /etc/shorewall/masq to:
-
-
-
-
-
#INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
+
An OLD_PING_HANDLING
+option has been added to shorewall.conf. When set to
+Yes, Shorewall ping handling is as it has always been (see
+http://www.shorewall.net/ping.html).
+
+When OLD_PING_HANDLING=No,
+icmp echo (ping) is handled via rules and policies just
+like any other connection request. The FORWARDPING=Yes option in
+shorewall.conf and the 'noping' and 'filterping' options in
+/etc/shorewall/interfaces will all generate an error.
+
+
+
It is now possible to direct Shorewall to create a "label" such
+as "eth0:0" for IP addresses that it creates under
+ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
+the label instead of just the interface name:
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+
+
When an interface name is entered in the SUBNET column of the
+/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
+only the first subnet defined on that interface. It did not masquerade
+traffic from:
+
+ a) The subnets associated with other addresses on the
+interface.
+ b) Subnets accessed through local routers.
+
+Beginning with Shorewall 1.3.14, if you enter an interface name in the
+SUBNET column,
+shorewall will use the firewall's routing table to construct the
+masquerading/SNAT rules.
+
+Example 1 -- This is how it works in 1.3.14.
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+
[root@gateway test]# shorewall start ... Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176 To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176 Processing /etc/shorewall/tos...
+
+When upgrading to Shorewall 1.3.14, if you have multiple local subnets
+connected to an interface that is specified in the SUBNET column of an
+/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
+changing. In most cases, you will simply be able to remove redundant
+entries. In some cases though, you might want to change from using the
+interface name to listing specific subnetworks if the change described
+above will cause masquerading to occur on subnetworks that you don't
+wish to masquerade.
+
+Example 2 -- Suppose that your current config is as follows:
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 192.168.10.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
+
+ In this case, the second entry in /etc/shorewall/masq is
+no longer required.
+
+Example 3 -- What if your current configuration is like this?
+
+
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
[root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]#
+
+ In this case, you would
+want to change the entry in /etc/shorewall/masq to:
+
#INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
-
-
1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format
-
-
-
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation.
- the PDF may be downloaded from
Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and
-ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A
-big thanks to Alex for making this happen.
-
-
-
+ href="http://www.rettc.com">Rett Consulting, www.shorewall.net and
+ftp.shorewall.net
+are now hosted on a system in Bellevue, Washington. A big thanks to
+Alex
+for making this happen.
+
1/13/2003 - Shorewall 1.3.13
-
-
-
+
Just includes a few things that I had on the burner:
-
-
-
+
-
A new 'DNAT-' action has
- been added for entries in the /etc/shorewall/rules file.
- DNAT- is intended for advanced users who wish to minimize the
- number of rules that connection requests must traverse.
-
- A Shorewall DNAT rule actually
- generates two iptables rules: a header rewriting rule
-in the 'nat' table and an ACCEPT rule in the 'filter' table.
- A DNAT- rule only generates the first of these rules. This
-is handy when you have several DNAT rules that would generate the
- same ACCEPT rule.
-
- Here are three rules from
-my previous rules file:
-
- DNAT net dmz:206.124.146.177
- tcp smtp - 206.124.146.178
- DNAT net dmz:206.124.146.177
- tcp smtp - 206.124.146.179
- ACCEPT net dmz:206.124.146.177
- tcp www,smtp,ftp,...
-
- These three rules ended up
- generating _three_ copies of
-
- ACCEPT net dmz:206.124.146.177
- tcp smtp
-
- By writing the rules this
-way, I end up with only one copy of the ACCEPT rule.
-
- DNAT- net dmz:206.124.146.177
- tcp smtp - 206.124.146.178
- DNAT- net dmz:206.124.146.177
- tcp smtp - 206.124.146.179
- ACCEPT net dmz:206.124.146.177
- tcp www,smtp,ftp,....
-
-
-
The 'shorewall check'
-command now prints out the applicable policy between
-each pair of zones.
-
-
-
A new CLEAR_TC option
-has been added to shorewall.conf. If this option is set
-to 'No' then Shorewall won't clear the current traffic control
- rules during [re]start. This setting is intended for use by
-people that prefer to configure traffic shaping when the network
- interfaces come up rather than when the firewall is started. If
-that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No
-and do not supply an /etc/shorewall/tcstart file. That way, your
-traffic shaping rules can still use the 'fwmark' classifier based
-on packet marking defined in /etc/shorewall/tcrules.
-
-
-
A new SHARED_DIR variable
- has been added that allows distribution packagers to
-easily move the shared directory (default /usr/lib/shorewall).
- Users should never have a need to change the value of this
-shorewall.conf setting.
-
-
-
+
A new 'DNAT-' action has been added for entries in the
+/etc/shorewall/rules file. DNAT- is intended for advanced users who
+wish
+to minimize the number of rules that connection requests must traverse.
+
+A Shorewall DNAT rule actually generates two iptables rules: a header
+rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
+table. A DNAT- rule only generates the first of these rules. This is
+handy when you have several DNAT rules that would generate the same
+ACCEPT rule.
+
+ Here are three rules from my previous rules file:
+
+ DNAT net
+dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT net
+dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net
+dmz:206.124.146.177 tcp www,smtp,ftp,...
+
+ These three rules ended up generating _three_ copies of
+
+ ACCEPT net
+dmz:206.124.146.177 tcp smtp
+
+ By writing the rules this way, I end up with only one copy
+of the ACCEPT rule.
+
+ DNAT- net
+dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT- net
+dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net
+dmz:206.124.146.177 tcp www,smtp,ftp,....
+
+
+
The 'shorewall check' command now prints out the applicable
+policy between each pair of zones.
+
+
+
A new CLEAR_TC option has been added to shorewall.conf. If this
+option is set to 'No' then Shorewall won't clear the current traffic
+control rules during [re]start. This setting is intended for use by
+people that prefer to configure traffic shaping when the network
+interfaces come up rather than when the firewall is started. If that is
+what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not
+supply an /etc/shorewall/tcstart file. That way, your traffic shaping
+rules can still use the 'fwmark' classifier based on packet marking
+defined in /etc/shorewall/tcrules.
+
+
+
A new SHARED_DIR
+variable has been added that allows distribution packagers
+to easily move the shared directory (default /usr/lib/shorewall). Users
+should never have a need to change the value of this shorewall.conf
+setting.
+
-
-
-
1/6/2003 - BURNOUT
-
-
-
-
Until further notice, I will not be involved in either Shorewall Development
- or Shorewall Support
-
-
+
1/6/2003 - BURNOUT
+
Until further notice, I will not be involved in either Shorewall
+Development or Shorewall Support
-Tom Eastep
-
-
-
+
12/30/2002 - Shorewall Documentation in PDF Format
-
-
-
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation.
- the PDF may be downloaded from
"shorewall refresh"
-now reloads the traffic shaping rules (tcrules and
-tcstart).
-
"shorewall debug [re]start"
- now turns off debugging after an error occurs. This
- places the point of the failure near the end of the trace
- rather than up in the middle of it.
-
"shorewall [re]start"
- has been speeded up by more than 40% with my configuration.
- Your milage may vary.
-
A "shorewall show classifiers"
- command has been added which shows the current packet
- classification filters. The output from this command
- is also added as a separate page in "shorewall monitor"
-
ULOG (must be all caps)
- is now accepted as a valid syslog level and causes
-the subject packets to be logged using the ULOG target rather
- than the LOG target. This allows you to run ulogd (available
- from http://www.gnumonks.org/projects/ulogd)
- and log all Shorewall messages to a separate log file.
-
If you are running
-a kernel that has a FORWARD chain in the mangle table
- ("shorewall show mangle" will show you the chains in the
- mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in
- shorewall.conf. This allows
-for marking input packets based on their destination even when
- you are using Masquerading or SNAT.
-
I have cluttered up
-the /etc/shorewall directory with empty 'init', 'start',
- 'stop' and 'stopped' files. If you already have a file with
- one of these names, don't worry -- the upgrade process won't
- overwrite your file.
-
I have added a new
-RFC1918_LOG_LEVEL variable to shorewall.conf. This variable
- specifies the syslog level at which packets are logged
-as a result of entries in the /etc/shorewall/rfc1918 file.
- Previously, these packets were always logged at the 'info'
- level.
-
-
-
+
"shorewall refresh" now reloads the traffic shaping rules
+(tcrules and tcstart).
+
"shorewall debug [re]start" now turns off debugging after an
+error occurs. This places the point of the failure near the end of the
+trace rather than up in the middle of it.
+
"shorewall [re]start" has been speeded up by more than 40% with
+my configuration. Your milage may vary.
+
A "shorewall show classifiers" command has been added which shows
+the current packet classification filters. The output from this command
+is also added as a separate page in "shorewall monitor"
+
ULOG (must be
+all caps) is now accepted as a valid syslog level and causes the
+subject packets to be logged using the ULOG
+target rather than the LOG target. This allows you to run ulogd
+(available from http://www.gnumonks.org/projects/ulogd)
+and log all Shorewall messages to a
+separate log file.
+
If you are running a kernel that has a FORWARD chain in the
+mangle table ("shorewall show mangle" will show you the chains in
+the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for
+marking input packets based on their destination even when you are
+using Masquerading or SNAT.
+
I have cluttered up the /etc/shorewall directory with empty
+'init', 'start', 'stop' and 'stopped' files. If you already have a file
+with one of these names, don't worry -- the upgrade process won't
+overwrite your file.
+
I have added a new RFC1918_LOG_LEVEL variable to shorewall.conf. This variable
+specifies the syslog level at which packets are logged as a result of
+entries in the /etc/shorewall/rfc1918 file. Previously, these packets
+were always logged at the 'info' level.
+
-
-
12/20/2002 - Shorewall 1.3.12 Beta 3
-
- This version corrects a
-problem with Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL
- was set to anything but ULOG, the firewall would fail to
- start and "shorewall refresh" would also fail.
-
-
+
+This version corrects a problem with Blacklist logging. In Beta 2, if
+BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would
+fail to start and "shorewall refresh" would also fail.
12/20/2002 - Shorewall 1.3.12 Beta 2
-
-
-
The first public Beta version of Shorewall 1.3.12 is now available (Beta
- 1 was made available only to a limited audience).
-
- Features include:
-
-
+
The first public Beta version of Shorewall 1.3.12 is now available
+(Beta 1 was made available only to a limited audience).
+
+Features include:
-
"shorewall refresh"
- now reloads the traffic shaping rules (tcrules
-and tcstart).
-
"shorewall debug
- [re]start" now turns off debugging after an error
- occurs. This places the point of the failure near the end of
- the trace rather than up in the middle of it.
-
"shorewall [re]start"
- has been speeded up by more than 40% with my configuration.
- Your milage may vary.
-
A "shorewall show
- classifiers" command has been added which shows
-the current packet classification filters. The output from
- this command is also added as a separate page in "shorewall
- monitor"
-
ULOG (must be
-all caps) is now accepted as a valid syslog level
-and causes the subject packets to be logged using the ULOG target
- rather than the LOG target. This allows you to run ulogd (available
- from http://www.gnumonks.org/projects/ulogd)
- and log all Shorewall messages to a separate log file.
-
If you are running
- a kernel that has a FORWARD chain in the mangle table
- ("shorewall show mangle" will show you the chains in the
-mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf.
- This allows for marking input packets based on their destination
- even when you are using Masquerading or SNAT.
-
I have cluttered
- up the /etc/shorewall directory with empty 'init',
- 'start', 'stop' and 'stopped' files. If you already have a file
- with one of these names, don't worry -- the upgrade process
- won't overwrite your file.
-
-
+
"shorewall refresh" now reloads the traffic shaping rules
+(tcrules and tcstart).
+
"shorewall debug [re]start" now turns off debugging after an
+error occurs. This places the point of the failure near the end of the
+trace rather than up in the middle of it.
+
"shorewall [re]start" has been speeded up by more than 40% with
+my configuration. Your milage may vary.
+
A "shorewall show classifiers" command has been added which shows
+the current packet classification filters. The output from this command
+is also added as a separate page in "shorewall monitor"
+
ULOG (must be all caps) is now accepted as a valid syslog level
+and causes the subject packets to be logged using the ULOG target
+rather than the LOG target. This allows you to run ulogd (available
+from http://www.gnumonks.org/projects/ulogd)
+and log all Shorewall messages to a
+separate log file.
+
If you are running a kernel that has a FORWARD chain in the
+mangle table ("shorewall show mangle" will show you the
+chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in
+shorewall.conf. This allows for marking input packets
+based on their destination even when you are using Masquerading or SNAT.
+
I have cluttered up the /etc/shorewall directory with empty
+'init', 'start', 'stop' and 'stopped' files. If you already have a file
+with one of these names, don't worry -- the upgrade process won't
+overwrite your file.
- You may download the
-Beta from:
-
-
+You may download the Beta from:
- Shorewall is at the
- center of MandrakeSoft's recently-announced
+Shorewall is at the center of MandrakeSoft's recently-announced Multi
- Network Firewall (MNF) product. Here is the
- press
- release.
-
-
+Network Firewall (MNF) product. Here is the press
+release.
12/7/2002 - Shorewall Support for Mandrake 9.0
-
-
-
Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered.
- I have installed 9.0 on one of my systems and
-I am now in a position to support Shorewall users who
-run Mandrake 9.0.
-
-
+
Two months and 3 days after I ordered Mandrake 9.0, it was finally
+delivered. I have installed 9.0 on one of my systems
+and I am now in a position to support Shorewall users
+who run Mandrake 9.0.
This is a bug-fix roll up which includes Roger Aich's fix for DNAT with
- excluded subnets (e.g., "DNAT foo!bar ...").
-Current 1.3.11 users who don't need rules of this
-type need not upgrade to 1.3.11.
-
-
+
This is a bug-fix roll up which includes Roger Aich's fix for DNAT
+with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users
+who don't need rules of this type need not upgrade to 1.3.11.
11/24/2002 - Shorewall 1.3.11
-
-
In this version:
-
-
-
A 'tcpflags'
- option has been added to entries in /etc/shorewall/interfaces.
- This option causes Shorewall to make a set of sanity check on TCP
- packet header flags.
-
It is now
- allowed to use 'all' in the SOURCE or DEST column in
- a rule. When used,
- 'all' must appear by itself (in may not be qualified) and it does
-not enable intra-zone traffic. For example, the rule
-
- ACCEPT loc
- all tcp 80
-
- does not enable
- http traffic from 'loc' to 'loc'.
-
Shorewall's
- use of the 'echo' command is now compatible with bash
- clones such as ash and dash.
-
fw->fw
- policies now generate a startup error. fw->fw rules
- generate a warning and are ignored
-
-
+
A
+'tcpflags' option has been added to entries in /etc/shorewall/interfaces.
+This option causes Shorewall to make a set of sanity check on TCP
+packet header flags.
+
It is now allowed to use 'all' in the SOURCE or DEST column in a rule. When used, 'all' must appear
+by itself (in may not be qualified) and it does not enable intra-zone
+traffic. For example, the rule
+
+ ACCEPT loc all tcp 80
+
+does not enable http traffic from 'loc' to 'loc'.
+
Shorewall's use of the 'echo' command is now compatible with bash
+clones such as ash and dash.
+
fw->fw policies now generate a startup error. fw->fw rules
+generate a warning and are ignored
-
-
11/14/2002 - Shorewall Documentation in PDF Format
-
-
-
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation.
- the PDF may be downloaded from
Shorewall
- can now do MAC verification
- on ethernet segments. You can specify the set of allowed MAC
-addresses on the segment and you can optionally tie each MAC
-address to one or more IP addresses.
-
PPTP
-Servers and Clients running on the firewall system
- may now be defined in the /etc/shorewall/tunnels
- file.
Shorewall can now do MAC
+verification on ethernet segments. You can specify the set of
+allowed MAC addresses on the segment and you can optionally tie each
+MAC address to one or more IP addresses.
+
PPTP Servers and Clients running on the firewall system may now
+be defined in the /etc/shorewall/tunnels file.
The
-main firewall script is now /usr/lib/shorewall/firewall.
- The script in /etc/init.d/shorewall is very small and
-uses /sbin/shorewall to do the real work. This change
-makes custom distributions such as for Debian and
-for Gentoo easier to manage since it is /etc/init.d/shorewall
- that tends to have distribution-dependent code
-
-
+
The main firewall script is now /usr/lib/shorewall/firewall. The
+script in /etc/init.d/shorewall is very small and uses /sbin/shorewall
+to do the real work. This change makes custom distributions such as for
+Debian and for Gentoo easier to manage since it is
+/etc/init.d/shorewall that tends to have distribution-dependent code
Shorewall
- can now do MAC verification
- on ethernet segments. You can specify the set of
-allowed MAC addresses on the segment and you can optionally
- tie each MAC address to one or more IP addresses.
-
PPTP
- Servers and Clients running on the firewall system
- may now be defined in the /etc/shorewall/tunnels
- file.
Shorewall can now do MAC
+verification on ethernet segments. You can specify the set of
+allowed MAC addresses on the segment and you can
+optionally tie each MAC address to one or more IP addresses.
+
PPTP Servers and Clients running on the firewall system may now
+be defined in the /etc/shorewall/tunnels file.
The
-main firewall script is now /usr/lib/shorewall/firewall.
- The script in /etc/init.d/shorewall is very small and
-uses /sbin/shorewall to do the real work. This change
-makes custom distributions such as for Debian and for
-Gentoo easier to manage since it is /etc/init.d/shorewall
- that tends to have distribution-dependent code.
-
-
+
The main firewall script is now /usr/lib/shorewall/firewall. The
+script in /etc/init.d/shorewall is very small
+and uses /sbin/shorewall to do the real work. This
+change makes custom distributions such as for Debian and for Gentoo
+easier to manage since it is /etc/init.d/shorewall that tends to have
+distribution-dependent code.
- You may
-download the Beta from:
-
-
+You may download the Beta from:
- This release
- rolls up fixes to the installer and to the firewall
- script.
-
-
+This release rolls up fixes to the installer and to the firewall script.
10/6/2002 - Shorewall.net now running on RH8.0
-
- The firewall
- and server here at shorewall.net are now running
- RedHat release 8.0.
-
-
- 9/30/2002
- - Shorewall 1.3.9a
- Roles
-up the fix for broken tunnels.
-
-
+
+The firewall and server here at shorewall.net are now running RedHat
+release 8.0.
+
+9/30/2002 - Shorewall 1.3.9a
+Roles up the fix for broken tunnels.
DNS Names
- are now allowed in Shorewall config files (although I recommend
-against using them).
-
-
The connection SOURCE may now be qualified
-by both interface and IP address in a Shorewall rule.
-
-
Shorewall startup is now disabled after initial
- installation until the file /etc/shorewall/startup_disabled
- is removed. This avoids nasty surprises during
- reboot for users who install Shorewall but don't configure
- it.
-
The
- 'functions' and 'version' files and the 'firewall'
- symbolic link have been moved from /var/lib/shorewall
- to /usr/lib/shorewall to appease the LFS police at
- Debian.
-
-
-
+
DNS Names
+are now allowed in Shorewall config files (although I recommend against
+using them).
+
The connection SOURCE may now be qualified by both interface and
+IP address in a Shorewall rule.
+
Shorewall startup is now disabled after initial installation
+until the file /etc/shorewall/startup_disabled is removed. This avoids
+nasty surprises during reboot for users who install Shorewall but don't
+configure it.
+
The 'functions' and 'version' files and the 'firewall' symbolic
+link have been moved from /var/lib/shorewall to /usr/lib/shorewall to
+appease the LFS police at Debian.
+
-
-
-
9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored
-
-
-
-
-
- A couple of recent configuration changes at www.shorewall.net
- broke the Search facility:
-
-
-
-
-
-
-
+
9/23/2002 - Full Shorewall Site/Mailing List Archive Search
+Capability Restored
+
+ A couple of recent configuration changes at
+www.shorewall.net broke the Search facility:
+
-
-
Mailing List Archive Search was not available.
-
-
The Site Search index was incomplete
-
-
Only one page of matches was presented.
-
-
-
-
+
Mailing List Archive Search was not available.
+
The Site Search index was incomplete
+
Only one page of matches was presented.
-
-
-
- Hopefully these problems are now corrected.
-
-
9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored
-
-
-
- A couple of recent configuration changes at www.shorewall.net
- had the negative effect of breaking the Search
- facility:
-
-
-
+
+Hopefully these problems are now corrected.
+
9/23/2002 - Full Shorewall Site/Mailing List Archive Search
+Capability Restored
+
+A couple of recent configuration changes at www.shorewall.net had the
+negative effect of breaking the Search facility:
-
-
Mailing List Archive Search was not available.
-
-
The Site Search index was incomplete
-
-
Only one page of matches was presented.
-
-
-
+
Mailing List Archive Search was not available.
+
The Site Search index was incomplete
+
Only one page of matches was presented.
-
- Hopefully these problems are now corrected.
-
-
-
-
9/18/2002 - Debian 1.3.8 Packages Available
-
-
-
-
-
+Hopefully these problems are now corrected.
+
A NEWNOTSYN
- option has been added to shorewall.conf. This option determines
- whether Shorewall accepts TCP packets
- which are not part of an established connection and
- that are not 'SYN' packets (SYN flag on and ACK flag off).
-
-
The need for the 'multi' option to communicate
- between zones za and zb on the same interface
- is removed in the case where the chain 'za2zb' and/or
- 'zb2za' exists. 'za2zb' will exist if:
-
-
-
-
-
+
A NEWNOTSYN option has been
+added to shorewall.conf. This option determines whether Shorewall
+accepts TCP packets which are not part of an established connection and
+that are not 'SYN' packets (SYN flag on and ACK flag off).
+
The need for the 'multi' option to communicate between zones za
+and zb on the same interface is removed in the case where the chain
+'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
-
-
There is a policy for za to zb; or
-
-
-
There is at least one rule for za to
- zb.
-
-
-
-
-
+
There is a policy for za to zb; or
+
There is at least one rule for za to zb.
-
-
-
-
-
-
-
-
The /etc/shorewall/blacklist file now contains
- three columns. In addition to the SUBNET/ADDRESS
- column, there are optional PROTOCOL and PORT columns
-to block only certain applications from the blacklisted
- addresses.
-
-
-
-
-
+
The /etc/shorewall/blacklist file now contains three columns. In
+addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
+PORT columns to block only certain applications from the blacklisted
+addresses.
+
8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
- -- Shorewall 1.3.7a released
-
-
-
-
-
-
1.3.7a corrects problems occurring in rules file processing when starting
- Shorewall 1.3.7.
-
-
-
+
8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its
+Author -- Shorewall 1.3.7a released
+
1.3.7a corrects problems occurring in rules file processing when
+starting Shorewall 1.3.7.
8/22/2002 - Shorewall 1.3.7 Released 8/13/2002
-
-
-
Features in this release include:
-
-
-
-
-
The 'icmp.def' file is now empty! The rules
- in that file were required in ipchains firewalls
- but are not required in Shorewall. Users who have
- ALLOWRELATED=No in shorewall.conf
- should see the Upgrade
- Issues.
-
-
A 'FORWARDPING' option has been added to
- shorewall.conf.
- The effect of setting this variable to Yes
-is the same as the effect of adding an ACCEPT
- rule for ICMP echo-request in /etc/shorewall/icmpdef.
- Users who have such a rule in icmpdef are
- encouraged to switch to FORWARDPING=Yes.
-
-
The loopback CLASS A Network (127.0.0.0/8)
- has been added to the rfc1918 file.
-
-
Shorewall now works with iptables 1.2.7
-
-
The documentation and web site no longer
- uses FrontPage themes.
-
-
-
+
The 'icmp.def' file is now empty! The rules in that file were
+required in ipchains firewalls but are not required in Shorewall. Users
+who have ALLOWRELATED=No in shorewall.conf
+should see the Upgrade Issues.
+
A 'FORWARDPING' option has been added to shorewall.conf. The effect of
+setting this variable to Yes is the same as the effect of adding an
+ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef.
+Users who have such a rule in icmpdef are encouraged to switch to
+FORWARDPING=Yes.
+
The loopback CLASS A Network (127.0.0.0/8) has been added to the
+rfc1918 file.
+
Shorewall now works with iptables 1.2.7
+
The documentation and web site no longer uses FrontPage themes.
-
-
-
-
I would like to thank John Distler for his valuable input regarding TCP
- SYN and ICMP treatment in Shorewall.
- That input has led to marked improvement in
- Shorewall in the last two releases.
-
-
-
+
I would like to thank John Distler for his valuable input regarding
+TCP SYN and ICMP treatment in Shorewall. That input has led to marked
+improvement in Shorewall in the last two releases.
This branch will only be updated after I release a new version of Shorewall
- so you can always update from this
- branch to get the latest stable tree.
Shorewall will now DROP TCP packets that
- are not part of or related to an existing connection
- and that are not SYN packets. These "New not SYN"
- packets may be optionally logged by setting the LOGNEWNOTSYN
- option in /etc/shorewall/shorewall.conf.
-
-
The processing of "New not SYN" packets
- may be extended by commands in the new newnotsyn extension script.
Shorewall will now DROP TCP packets that are not part of or
+related to an existing connection and that are not SYN packets. These
+"New not SYN" packets may be optionally logged by setting the
+LOGNEWNOTSYN option in /etc/shorewall/shorewall.conf.
+
The processing of "New not SYN" packets may be extended by
+commands in the new newnotsyn
+extension script.
-
-
-
7/30/2002 - Shorewall 1.3.5b Released
-
-
-
This interim release:
-
-
-
-
-
Causes the firewall script to remove the
- lock file if it is killed.
-
-
Once again allows lists in the second column
- of the /etc/shorewall/hosts
- file.
The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm.
- The guide is intended for use by people
- who are setting up Shorewall to manage multiple
- public IP addresses and by people who want to learn
- more about Shorewall than is described in the single-address
- guides. Feedback on the new guide is welcome.
-
-
-
+
The first draft of this guide is available at
+http://www.shorewall.net/shorewall_setup_guide.htm. The guide is
+intended for use
+by people who are setting up Shorewall to manage multiple public IP
+addresses and by people who want to learn more about Shorewall than is
+described in the single-address guides. Feedback on the new guide is
+welcome.
7/28/2002 - Shorewall 1.3.5 Debian Package Available
This interim release restores correct handling of REDIRECT rules.
-
-
-
7/26/2002 - Shorewall 1.3.5 Released
-
-
-
-
This will be the last Shorewall release for a while. I'm going to be
- focusing on rewriting a lot of the documentation.
-
-
-
-
In this version:
-
-
-
+
This will be the last Shorewall release for a while. I'm going to be
+focusing on rewriting a lot of the documentation.
+
In this version:
-
-
Empty and invalid source and destination
- qualifiers are now detected in the rules file.
- It is a good idea to use the 'shorewall check' command
- before you issue a 'shorewall restart' command be be
- sure that you don't have any configuration problems
- that will prevent a successful restart.
-
-
Added MERGE_HOSTS variable in
- shorewall.conf
- to provide saner behavior of the /etc/shorewall/hosts
- file.
-
-
The time that the counters were last reset
- is now displayed in the heading of the 'status'
- and 'show' commands.
-
-
A proxyarp option has been
- added for entries in /etc/shorewall/interfaces.
- This option facilitates Proxy ARP sub-netting as described
- in the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
- Specifying the proxyarp option for
- an interface causes Shorewall to set
+
Empty and invalid source and destination qualifiers are now
+detected in the rules file. It is a good idea to use the 'shorewall
+check' command before you issue a 'shorewall restart' command be be
+sure that you don't have any configuration problems that will prevent a
+successful restart.
+
Added MERGE_HOSTS variable in shorewall.conf to provide saner
+behavior of the /etc/shorewall/hosts file.
+
The time that the counters were last reset is now displayed in
+the heading of the 'status' and 'show' commands.
+
A proxyarp option has been added for entries in /etc/shorewall/interfaces.
+This option facilitates Proxy ARP sub-netting as described in the Proxy
+ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
+Specifying the proxyarp option for an interface causes Shorewall to set
/proc/sys/net/ipv4/conf/<interface>/proxy_arp.
-
-
The Samples have been updated to reflect
- the new capabilities in this release.
-
-
-
+
The Samples have been updated to reflect the new capabilities in
+this release.
-
-
-
7/16/2002 - New Mirror in Argentina
-
-
-
-
Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in
- Argentina. Thanks Buanzo!!!
-
-
-
+
Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror
+in Argentina. Thanks Buanzo!!!
7/16/2002 - Shorewall 1.3.4 Released
-
-
-
In this version:
-
-
-
-
-
A new
- /etc/shorewall/routestopped file
-has been added. This file is intended to eventually
-replace the routestopped option in the
- /etc/shorewall/interface and /etc/shorewall/hosts
- files. This new file makes remote firewall administration
- easier by allowing any IP or subnet to be enabled
- while Shorewall is stopped.
-
-
An /etc/shorewall/stopped extension script has been
- added. This script is invoked after Shorewall
- has stopped.
-
-
A DETECT_DNAT_ADDRS option
- has been added to /etc/shoreall/shorewall.conf.
- When this option is selected, DNAT rules
-only apply when the destination address
- is the external interface's primary IP address.
-
-
The QuickStart
- Guide has been broken into three
- guides and has been almost entirely rewritten.
-
-
The Samples have been updated to reflect
- the new capabilities in this release.
-
-
-
+
A new
+/etc/shorewall/routestopped file has been added. This file is
+intended to eventually replace the routestopped option in the
+/etc/shorewall/interface and /etc/shorewall/hosts files. This new file
+makes remote firewall administration easier by allowing any IP or
+subnet to be enabled while Shorewall is stopped.
+
An /etc/shorewall/stopped extension
+script has been added. This script is invoked after Shorewall has
+stopped.
+
A DETECT_DNAT_ADDRS option has been added to /etc/shoreall/shorewall.conf. When
+this option is selected, DNAT rules only apply when the destination
+address is the external interface's primary IP address.
+
The QuickStart Guide
+has been broken into three guides and has been almost entirely
+rewritten.
+
The Samples have been updated to reflect the new capabilities in
+this release.
-
-
-
7/8/2002 - Shorewall 1.3.3 Debian Package Available
Entries in /etc/shorewall/interface that
- use the wildcard character ("+") now have the "multi"
- option assumed.
-
-
The 'rfc1918' chain in the mangle table
- has been renamed 'man1918' to make log messages
- generated from that chain distinguishable from those
- generated by the 'rfc1918' chain in the filter table.
-
-
Interface names appearing in the hosts
- file are now validated against the interfaces
- file.
-
-
The TARGET column in the rfc1918 file is
- now checked for correctness.
-
-
The chain structure in the nat table has
- been changed to reduce the number of rules that
- a packet must traverse and to correct problems with
- NAT_BEFORE_RULES=No
-
-
The "hits" command has been enhanced.
-
-
-
+
Entries in /etc/shorewall/interface that use the wildcard
+character ("+") now have the "multi" option assumed.
+
The 'rfc1918' chain in the mangle table has been renamed
+'man1918' to make log messages generated from that chain
+distinguishable from those generated by the 'rfc1918' chain in the
+filter table.
+
Interface names appearing in the hosts file are now validated
+against the interfaces file.
+
The TARGET column in the rfc1918 file is now checked for
+correctness.
+
The chain structure in the nat table has been changed to reduce
+the number of rules that a packet must traverse and to correct problems
+with NAT_BEFORE_RULES=No
+
The "hits" command has been enhanced.
-
-
-
6/25/2002 - Samples Updated for 1.3.2
-
-
-
-
The comments in the sample configuration files have been updated to reflect
- new features introduced in Shorewall
- 1.3.2.
-
-
-
+
The comments in the sample configuration files have been updated to
+reflect new features introduced in Shorewall 1.3.2.
6/25/2002 - Shorewall 1.3.1 Debian Package Available
The files firewall, functions and version have
+been moved from /etc/shorewall to /var/lib/shorewall.
-
-
-
6/6/2002 - Why CVS Web access is Password Protected
-
-
-
-
Last weekend, I installed the CVS Web package to provide brower-based access
- to the Shorewall CVS repository. Since then, I have had several instances
-where my server was almost unusable due to the high load generated by website
-copying tools like HTTrack and WebStripper. These mindless tools:
-
-
-
+
Last weekend, I installed the CVS Web package to provide
+brower-based
+access to the Shorewall CVS repository. Since then, I have had several
+instances where my server was almost unusable due to the high load
+generated
+by website copying tools like HTTrack and WebStripper. These mindless
+tools:
-
-
Ignore robot.txt files.
-
-
Recursively copy everything that they find.
-
-
Should be classified as weapons rather than
- tools.
-
-
-
+
Ignore robot.txt files.
+
Recursively copy everything that they find.
+
Should be classified as weapons rather than tools.
-
-
-
-
These tools/weapons are particularly damaging when combined with CVS Web
- because they doggedly follow every
- link in the cgi-generated HTML resulting in
- 1000s of executions of the cvsweb.cgi script. Yesterday,
- I spend several hours implementing measures to block
- these tools but unfortunately, these measures resulted
- in my server OOM-ing under even moderate load.
-
-
-
-
Until I have the time to understand the cause of the OOM (or until I buy
- more RAM if that is what is required),
- CVS Web access will remain Password Protected.
-
-
-
-
+
These tools/weapons are particularly damaging when combined with CVS
+Web because they doggedly follow every link in the cgi-generated HTML
+resulting in 1000s of executions of the cvsweb.cgi script. Yesterday, I
+spend several hours implementing measures to block these tools but
+unfortunately, these measures resulted in my server OOM-ing under even
+moderate load.
+
Until I have the time to understand the cause of the OOM (or until I
+buy more RAM if that is what is required), CVS Web access will remain
+Password Protected.
6/5/2002 - Shorewall 1.3.1 Debian Package Available
The 1.3.0 samples configurations had several serious problems that prevented
- DNS and SSH from working properly.
- These problems have been corrected in the
- 1.3.1 samples.
-
-
-
+
The 1.3.0 samples configurations had several serious problems that
+prevented DNS and SSH from working properly. These problems have been
+corrected in the 1.3.1 samples.
6/1/2002 - Shorewall 1.3.1 Released
-
-
-
Hot on the heels of 1.3.0, this release:
-
-
-
-
-
Corrects a serious problem with "all
- <zone> CONTINUE" policies. This
- problem is present in all versions of Shorewall that
- support the CONTINUE policy. These previous versions
- optimized away the "all2<zone>" chain
-and replaced it with the "all2all" chain with the usual result
-that a policy of REJECT was enforced rather than the intended
- CONTINUE policy.
Corrects a serious problem with "all <zone>
+CONTINUE" policies. This problem is present in all versions of
+Shorewall that support the CONTINUE policy. These previous versions
+optimized away the "all2<zone>" chain and replaced it with
+the "all2all" chain with the usual result that a policy of REJECT was
+enforced rather than the intended CONTINUE policy.
In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0
- includes:
-
-
-
+
In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall
+1.3.0 includes:
-
-
A 'filterping' interface option that allows
- ICMP echo-request (ping) requests addressed
- to the firewall to be handled by entries in /etc/shorewall/rules
- and /etc/shorewall/policy.
-
-
-
+
A 'filterping' interface option that allows ICMP echo-request
+(ping) requests addressed to the firewall to be handled by entries in
+/etc/shorewall/rules and /etc/shorewall/policy.
-
-
-
5/23/2002 - Shorewall 1.3 RC1 Available
-
-
-
-
In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92)
- incorporates the following:
-
-
-
+
In addition to the changes in Beta 1 and Beta 2, RC1 (Version
+1.2.92) incorporates the following:
-
-
Support for the /etc/shorewall/whitelist
- file has been withdrawn. If you need whitelisting,
- see these
- instructions.
-
-
-
+
Support for the /etc/shorewall/whitelist file has been withdrawn.
+If you need whitelisting, see these instructions.
-
-
-
5/19/2002 - Shorewall 1.3 Beta 2 Available
-
-
-
-
In addition to the changes in Beta 1, this release which carries the
- designation 1.2.91 adds:
-
-
-
+
In addition to the changes in Beta 1, this release which carries the
+designation 1.2.91 adds:
-
-
The structure of the firewall is changed
- markedly. There is now an INPUT and a FORWARD
- chain for each interface; this reduces the number
- of rules that a packet must traverse, especially in
- complicated setups.
The names of the columns in a number of
- the configuration files have been changed to
- be more consistent and self-explanatory and the documentation
- has been updated accordingly.
-
-
The sample configurations have been updated
- for 1.3.
-
-
-
+
The structure of the firewall is changed markedly. There is now
+an INPUT and a FORWARD chain for each interface; this reduces the
+number of rules that a packet must traverse, especially in complicated
+setups.
The names of the columns in a number of the configuration files
+have been changed to be more consistent and self-explanatory and the
+documentation has been updated accordingly.
+
The sample configurations have been updated for 1.3.
-
-
-
5/17/2002 - Shorewall 1.3 Beta 1 Available
-
-
-
-
Beta 1 carries the version designation 1.2.90 and implements the following
- features:
-
-
-
+
Beta 1 carries the version designation 1.2.90 and implements the
+following features:
-
-
Simplified rule syntax which makes the
-intent of each rule clearer and hopefully makes
- Shorewall easier to learn.
-
-
Upward compatibility with 1.2 configuration
- files has been maintained so that current users
- can migrate to the new syntax at their convenience.
-
-
WARNING: Compatibility
- with the old parameterized sample configurations has NOT
- been maintained. Users still running those configurations
- should migrate to the new sample configurations
- before upgrading to 1.3 Beta 1.
-
-
-
+
Simplified rule syntax which makes the intent of each rule
+clearer and hopefully makes Shorewall easier to learn.
+
Upward compatibility with 1.2 configuration files has been
+maintained so that current users can migrate to the new syntax at their
+convenience.
+
WARNING: Compatibility with the
+old parameterized sample configurations has NOT been maintained. Users
+still running those configurations should migrate to the new sample
+configurations before upgrading to 1.3 Beta 1.
IP addresses added under ADD_IP_ALIASES
+and ADD_SNAT_ALIASES now inherit the VLSM and Broadcast Address of
+the interface's primary IP address.
+
The order in which port forwarding DNAT and Static DNAT can now be reversed so that port
+forwarding rules can override the contents of /etc/shorewall/nat.
The 'try' command now accepts an optional
- timeout. If the timeout is given in the command,
- the standard configuration will automatically be
- restarted after the new configuration has been running
- for that length of time. This prevents a remote admin
- from being locked out of the firewall in the case where
- the new configuration starts but prevents access.
-
-
Kernel route filtering may now be enabled
- globally using the new ROUTE_FILTER parameter
- in /etc/shorewall/shorewall.conf.
-
-
Individual IP source addresses and/or subnets
- may now be excluded from masquerading/SNAT.
-
-
Simple "Yes/No" and "On/Off" values are
- now case-insensitive in /etc/shorewall/shorewall.conf.
-
-
-
+
The 'try' command now accepts an optional timeout. If the timeout
+is given in the command, the standard configuration will automatically
+be restarted after the new configuration has been running for that
+length of time. This prevents a remote admin from being locked out of
+the firewall in the case where the new configuration starts but
+prevents access.
4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available
-
-
-
-
Version 1.1 of the QuickStart
- Guide is now available. Thanks
- to those who have read version 1.0 and offered
- their suggestions. Corrections have also been made
- to the sample scripts.
-
-
-
+
Version 1.1 of the
+QuickStart Guide is now available. Thanks to those who have read
+version 1.0 and offered their suggestions. Corrections have also been
+made to the sample scripts.
4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available
-
-
-
-
Version 1.0 of the QuickStart
- Guide is now available. This Guide
- and its accompanying sample configurations
- are expected to provide a replacement for the recently
- withdrawn parameterized samples.
-
-
-
+
Version 1.0 of the
+QuickStart Guide is now available. This Guide and its accompanying
+sample configurations are expected to provide a replacement for the
+recently withdrawn parameterized samples.
4/8/2002 - Parameterized Samples Withdrawn
-
-
-
Although the parameterized
- samples have allowed people to
- get a firewall up and running quickly, they
- have unfortunately set the wrong level of expectation
- among those who have used them. I am therefore
- withdrawing support for the samples and I am recommending
- that they not be used in new Shorewall installations.
-
-
-
+ href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
+samples have allowed people to get a firewall up and running
+quickly, they have unfortunately set the wrong level of expectation
+among those who have used them. I am therefore withdrawing support for
+the samples and I am recommending that they not be used in new
+Shorewall installations.
The quick search on the home page now excludes the mailing list archives.
- The Extended
- Search allows excluding the archives
- or restricting the search to just the archives. An archive
- search form is also available on the mailing list information
- page.
-
-
-
+
The quick search on the home page now excludes the mailing list
+archives. The Extended Search allows
+excluding the archives or restricting the search to just the archives.
+An archive search form is also available on the mailing list
+information page.
3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)
A "shorewall try" command has been added
- (syntax: shorewall try <configuration
- directory>). This command attempts "shorewall
- -c <configuration directory> start"
- and if that results in the firewall being stopped due
- to an error, a "shorewall start" command is executed.
- The 'try' command allows you to create a new configuration and attempt
- to start it; if there is an error that leaves your
-firewall in the stopped state, it will automatically be restarted
- using the default configuration (in /etc/shorewall).
-
-
A new variable ADD_SNAT_ALIASES has been
- added to /etc/shorewall/shorewall.conf.
- If this variable is set to "Yes", Shorewall
- will automatically add IP addresses listed
- in the third column of the
- /etc/shorewall/masq file.
-
-
Copyright notices have been added to the
- documenation.
-
-
-
-
-
-
-
-
3/11/2002 - Shorewall 1.2.9 Released
-
-
-
-
In this version:
-
-
-
-
-
-
Filtering by MAC
- address has been added. MAC addresses may be used
- as the source address in:
-
-
-
-
-
-
A "shorewall try" command has been added (syntax: shorewall try
+<configuration directory>). This command attempts "shorewall
+-c <configuration directory> start" and if that results
+in the firewall being stopped due to an error, a "shorewall start"
+command is executed. The 'try' command allows you to create a new configuration and attempt to
+start it; if there is an error that leaves your firewall in the stopped
+state, it will automatically be restarted using the default
+configuration (in /etc/shorewall).
+
A new variable ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf. If
+this variable is set to "Yes", Shorewall will automatically add IP
+addresses listed in the third column of the /etc/shorewall/masq file.
+
Copyright notices have been added to the documenation.
+
+
3/11/2002 - Shorewall 1.2.9 Released
+
In this version:
+
+
Filtering by MAC address has
+been added. MAC addresses may be used as the source address in:
+
Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects
- problems associated with the lock file used to prevent multiple state-changing
- operations from occuring simultaneously.
- My apologies for any inconvenience my carelessness
- may have caused.
-
-
-
+
Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
+corrects problems associated with the lock file used to prevent
+multiple state-changing operations from occuring simultaneously. My
+apologies for any inconvenience my carelessness may have caused.
2/22/2002 - Shorewall 1.2.7 Released
-
-
-
In this version:
-
-
-
-
-
UPnP probes (UDP destination port 1900)
- are now silently dropped in the common
- chain
-
-
RFC 1918 checking in the mangle table has
- been streamlined to no longer require packet
- marking. RFC 1918 checking in the filter table has
- been changed to require half as many rules as previously.
-
-
A 'shorewall check' command has been added
- that does a cursory validation of the zones, interfaces,
- hosts, rules and policy files.
-
-
-
+
UPnP probes (UDP destination port 1900) are now silently dropped
+in the common chain
+
RFC 1918 checking in the mangle table has been streamlined to no
+longer require packet marking. RFC 1918 checking in the filter table
+has been changed to require half as many rules as previously.
+
A 'shorewall check' command has been added that does a cursory
+validation of the zones, interfaces, hosts, rules and policy files.
$-variables may now be used anywhere in
- the configuration files except /etc/shorewall/zones.
-
-
The interfaces and hosts files now have
- their contents validated before any changes
-are made to the existing Netfilter configuration. The
-appearance of a zone name that isn't defined in /etc/shorewall/zones
- causes "shorewall start" and "shorewall restart"
- to abort without changing the Shorewall state.
- Unknown options in either file cause a warning to be issued.
-
-
A problem occurring when BLACKLIST_LOGLEVEL
- was not set has been corrected.
-
-
-
+
$-variables may now be used anywhere in the configuration files
+except /etc/shorewall/zones.
+
The interfaces and hosts files now have their contents validated
+before any changes are made to the existing Netfilter configuration.
+The appearance of a zone name that isn't defined in
+/etc/shorewall/zones causes "shorewall start" and "shorewall restart"
+to abort without changing the Shorewall state. Unknown options in
+either file cause a warning to be issued.
+
A problem occurring when BLACKLIST_LOGLEVEL was not set has been
+corrected.
-
-
-
2/4/2002 - Shorewall 1.2.5 Debian Package Available
The default value of the STATEDIR variable
- in /etc/shorewall/shorewall.conf has been changed
- to /var/lib/shorewall in order to conform to the
- GNU/Linux File Hierarchy Standard, Version 2.2.
The default value of the STATEDIR variable in
+/etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall in
+order to conform to the GNU/Linux File Hierarchy Standard, Version 2.2.
You may now place end-of-line comments
-(preceded by '#') in any of the configuration
- files
-
-
There is now protection against against
- two state changing operations occuring concurrently.
- This is implemented using the 'lockfile' utility
- if it is available (lockfile is part of procmail);
- otherwise, a less robust technique is used. The lockfile
- is created in the STATEDIR defined in /etc/shorewall/shorewall.conf
- and has the name "lock".
-
-
"shorewall start" no longer fails if "detect"
- is specified in /etc/shorewall/interfaces
- for an interface with subnet mask 255.255.255.255.
You may now place end-of-line comments (preceded by '#') in any
+of the configuration files
+
There is now protection against against two state changing
+operations occuring concurrently. This is implemented using the
+'lockfile' utility if it is available (lockfile is part of procmail);
+otherwise, a less robust technique is used. The lockfile is created in
+the STATEDIR defined in /etc/shorewall/shorewall.conf and has the name
+"lock".
+
"shorewall start" no longer fails if "detect" is specified in /etc/shorewall/interfaces for
+an interface with subnet mask 255.255.255.255.
Corrects a problem with BLACKLIST_LOGLEVEL. See the
- errata for details.
-
-
-
+errata for details.
1/19/2002 - Shorewall 1.2.3 Released
-
-
-
-
This is a minor feature and bugfix release. The single new feature is:
-
-
-
+
This is a minor feature and bugfix release. The single new feature
+is:
-
-
Support for TCP MSS Clamp to PMTU -- This
- support is usually required when the internet
- connection is via PPPoE or PPTP and may be enabled
- using the CLAMPMSS
- option in /etc/shorewall/shorewall.conf.
-
-
-
+
Support for TCP MSS Clamp to PMTU -- This support is usually
+required when the internet connection is via PPPoE or PPTP and may be
+enabled using the CLAMPMSS
+option in /etc/shorewall/shorewall.conf.
-
-
-
The following problems were corrected:
-
-
-
-
-
The "shorewall status" command no longer
- hangs.
-
-
The "shorewall monitor" command now displays
- the icmpdef chain
-
-
The CLIENT PORT(S) column in tcrules is
-no longer ignored
-
-
-
+
The "shorewall status" command no longer hangs.
+
The "shorewall monitor" command now displays the icmpdef chain
+
The CLIENT PORT(S) column in tcrules is no longer ignored
-
-
-
1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release
-
-
-
-
Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution
- that includes Shorewall 1.2.2. See
-http://leaf.sourceforge.net/devel/jnilo
- for details.
-
-
-
+
Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
+distribution that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo
+for details.
1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2
- Shorewall Debian package is now available.
- There is a link to Lorenzo's site from the
-Shorewall download page.
-
-
-
+ href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni, a
+1.2.2 Shorewall Debian package is now
+available. There is a link to Lorenzo's site from the Shorewall download page.
1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores
- the "shorewall status" command to health.
-
-
-
+ href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version restores
+the "shorewall status" command to health.
1/8/2002 - Shorewall 1.2.2 Released
-
-
-
In version 1.2.2
-
-
-
-
-
Support for IP blacklisting has been added
-
-
-
-
-
-
+
Support for IP blacklisting has been added
-
-
You specify whether you want packets
- from blacklisted hosts dropped or rejected
- using the BLACKLIST_DISPOSITION
- setting in /etc/shorewall/shorewall.conf
-
-
You specify whether you want packets
- from blacklisted hosts logged and at what
- syslog level using the BLACKLIST_LOGLEVEL
- setting in /etc/shorewall/shorewall.conf
You specify the interfaces you want
- checked against the blacklist using the
- new "blacklist"
- option in /etc/shorewall/interfaces.
-
-
The black list is refreshed from /etc/shorewall/blacklist
- by the "shorewall refresh" command.
-
-
-
-
-
-
-
+
You specify whether you want packets from blacklisted hosts
+dropped or rejected using the BLACKLIST_DISPOSITION
+ setting in /etc/shorewall/shorewall.conf
+
You specify whether you want packets from blacklisted hosts
+logged and at what syslog level using the BLACKLIST_LOGLEVEL setting in
+/etc/shorewall/shorewall.conf
You specify the interfaces you want checked against the
+blacklist using the new "blacklist"
+option in /etc/shorewall/interfaces.
+
The black list is refreshed from /etc/shorewall/blacklist by
+the "shorewall refresh" command.
-
-
-
-
Use of TCP RST replies has been expanded
-
-
-
-
-
-
+
+
Use of TCP RST replies has been expanded
-
-
TCP connection requests rejected because
- of a REJECT policy are now replied with a
- TCP RST packet.
-
-
TCP connection requests rejected because
- of a protocol=all rule in /etc/shorewall/rules
- are now replied with a TCP RST packet.
-
-
-
-
-
-
-
+
TCP connection requests rejected because of a REJECT policy
+are now replied with a TCP RST packet.
+
TCP connection requests rejected because of a protocol=all
+rule in /etc/shorewall/rules are now replied with a TCP RST packet.
-
-
-
-
A LOGFILE
- specification has been added to /etc/shorewall/shorewall.conf.
- LOGFILE is used to tell the /sbin/shorewall program
-where to look for Shorewall messages.
-
-
-
+
+
A LOGFILE specification
+has been added to /etc/shorewall/shorewall.conf. LOGFILE is used to
+tell the /sbin/shorewall program where to look for Shorewall messages.
-
-
-
1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates
- to the previously-released samples.
-There are two new rules added:
-
-
-
+ target="_blank">version 1.2.0) released. These are minor
+updates to the previously-released samples. There are two new rules
+added:
-
-
Unless you have explicitly enabled Auth
-connections (tcp port 113) to your firewall, these
- connections will be REJECTED rather than DROPPED.
- This speeds up connection establishment to some servers.
-
-
Orphan DNS replies are now silently dropped.
-
-
-
+
Unless you have explicitly enabled Auth connections (tcp port
+113) to your firewall, these connections will be REJECTED rather than
+DROPPED. This speeds up connection establishment to some servers.
For the next month or so, I will continue to provide corrections to version
- 1.1.18 as necessary so that current
- version 1.1.x users will not be forced into
- a quick upgrade to 1.2.0 just to have access to bug
+
For the next month or so, I will continue to provide corrections to
+version 1.1.18 as necessary so that current version 1.1.x users will
+not be forced into a quick upgrade to 1.2.0 just to have access to bug
fixes.
-
-
-
-
For those of you who have installed one of the Beta RPMS, you will need
- to use the "--oldpackage" option when
- upgrading to 1.2.0:
-
-
-
-
-
-
-
+
For those of you who have installed one of the Beta RPMS, you will
+need to use the "--oldpackage" option when upgrading to 1.2.0:
11/1/2001 - The current version of Shorewall is 1.1.17. I intend
- this to be the last of the
-1.1 Shorewall releases.
-
-
-
+ href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">
+ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 . See the
+README file for instructions.
+
11/1/2001 - The current version of Shorewall is 1.1.17.
+I intend this to be the last of the 1.1 Shorewall releases.
10/22/2001 - The current version of Shorewall is 1.1.16. In this
- version:
-
-
-
+
10/22/2001 - The current version of Shorewall is 1.1.16. In
+this version:
-
-
A new "shorewall show connections" command
- has been added.
-
-
In the "shorewall monitor" output, the currently
- tracked connections are now shown on a separate
- page.
-
-
Prior to this release, Shorewall unconditionally
- added the external IP adddress(es) specified
- in /etc/shorewall/nat. Beginning with version
- 1.1.16, a new parameter (ADD_IP_ALIASES)
- may be set to "no" (or "No") to inhibit
- this behavior. This allows IP aliases created
-using your distribution's network configuration
- tools to be used in static NAT.
-
-
-
+
A new "shorewall show connections" command has been added.
+
In the "shorewall monitor" output, the currently tracked
+connections are now shown on a separate page.
+
Prior to this release, Shorewall unconditionally added the
+external IP adddress(es) specified in /etc/shorewall/nat. Beginning
+with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be set to
+"no" (or "No") to
+inhibit this behavior. This allows IP aliases created using your
+distribution's network configuration tools to be used in static
+NAT.
-
-
-
-
10/15/2001 - The current version of Shorewall is 1.1.15. In this
- version:
-
-
-
+
10/15/2001 - The current version of Shorewall is 1.1.15. In
+this version:
-
-
Support for nested zones has been improved.
- See the documentation
- for details
-
-
Shorewall now correctly checks the alternate
- configuration directory for the 'zones' file.
-
-
-
+
Support for nested zones has been improved. See the documentation for details
+
Shorewall now correctly checks the alternate configuration
+directory for the 'zones' file.
-
-
-
-
10/4/2001 - The current version of Shorewall is 1.1.14. In this
- version
-
-
-
+
10/4/2001 - The current version of Shorewall is 1.1.14. In
+this version
-
-
Shorewall now supports alternate configuration
- directories. When an alternate directory is
- specified when starting or restarting Shorewall
- (e.g., "shorewall -c /etc/testconf restart"), Shorewall
- will first look for configuration files in the alternate
- directory then in /etc/shorewall. To create an
-alternate configuration simply:
-
- 1. Create a New Directory
-
- 2. Copy to that directory any of your configuration
- files that you want to change.
-
- 3. Modify the copied files as needed.
-
- 4. Restart Shorewall specifying the new directory.
-
-
The rules for allowing/disallowing icmp
- echo-requests (pings) are now moved after rules
- created when processing the rules file. This allows
- you to add rules that selectively allow/deny ping based
- on source or destination address.
-
-
Rules that specify multiple client ip addresses
- or subnets no longer cause startup failures.
-
-
Zone names in the policy file are now validated
- against the zones file.
-
-
If you have packet mangling
- support enabled, the "norfc1918" interface
-option now logs and drops any incoming packets on the interface
- that have an RFC 1918 destination address.
-
-
-
+
Shorewall now supports alternate configuration directories. When
+an alternate directory is specified when starting or restarting
+Shorewall (e.g., "shorewall -c /etc/testconf restart"), Shorewall will
+first look for configuration files in the alternate directory then in
+/etc/shorewall. To create an alternate configuration simply:
+1. Create a New Directory
+2. Copy to that directory any of your configuration files that you want
+to change.
+3. Modify the copied files as needed.
+4. Restart Shorewall specifying the new directory.
+
The rules for allowing/disallowing icmp echo-requests (pings) are
+now moved after rules created when processing the rules file. This
+allows you to add rules that selectively allow/deny ping based on
+source or destination address.
+
Rules that specify multiple client ip addresses or subnets no
+longer cause startup failures.
+
Zone names in the policy file are now validated against the zones
+file.
+
If you have packet
+mangling support enabled, the "norfc1918" interface option
+now logs and drops any incoming packets on the interface that have an
+RFC 1918 destination address.
-
-
-
-
9/12/2001 - The current version of Shorewall is 1.1.13. In this
- version
-
-
-
+
9/12/2001 - The current version of Shorewall is 1.1.13. In
+this version
-
-
Shell variables can now be used to parameterize
- Shorewall rules.
-
-
The second column in the hosts file may
-now contain a comma-separated list.
-
-
-
- Example:
-
- sea eth0:130.252.100.0/24,206.191.149.0/24
8/28/2001 - The current version of Shorewall is 1.1.12. In this
- version
-
-
-
+
8/28/2001 - The current version of Shorewall is 1.1.12. In
+this version
-
-
Several columns in the rules file may now
- contain comma-separated lists.
-
-
Shorewall is now more rigorous in parsing
- the options in /etc/shorewall/interfaces.
-
-
Complementation using "!" is now supported
- in rules.
-
-
-
+
Several columns in the rules file may now contain comma-separated
+lists.
+
Shorewall is now more rigorous in parsing the options in
+/etc/shorewall/interfaces.
+
Complementation using "!" is now supported in rules.
-
-
-
-
7/28/2001 - The current version of Shorewall is 1.1.11. In this
- version
-
-
-
+
7/28/2001 - The current version of Shorewall is 1.1.11. In
+this version
-
-
A "shorewall refresh" command has been added
- to allow for refreshing the rules associated
- with the broadcast address on a dynamic interface.
- This command should be used in place of "shorewall
- restart" when the internet interface's IP address changes.
-
-
The /etc/shorewall/start file (if any) is
- now processed after all temporary rules have
- been deleted. This change prevents the accidental
- removal of rules added during the processing of that
- file.
-
-
The "dhcp" interface option is now applicable
- to firewall interfaces used by a DHCP server
- running on the firewall.
-
-
The RPM can now be built from the .tgz file
- using "rpm -tb"
-
-
-
+
A "shorewall refresh" command has been added to allow for
+refreshing the rules associated with the broadcast address on a dynamic
+interface. This command should be used in place of "shorewall restart"
+when the internet interface's IP address changes.
+
The /etc/shorewall/start file (if any) is now processed after all
+temporary rules have been deleted. This change prevents the accidental
+removal of rules added during the processing of that file.
+
The "dhcp" interface option is now applicable to firewall
+interfaces used by a DHCP server running on the firewall.
+
The RPM can now be built from the .tgz file using "rpm -tb"
-
-
-
-
7/6/2001 - The current version of Shorewall is 1.1.10. In this version
-
-
-
+
7/6/2001 - The current version of Shorewall is 1.1.10. In
+this
+version
-
-
Shorewall now enables Ipv4 Packet Forwarding
- by default. Packet forwarding may be disabled
- by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf.
- If you don't want Shorewall to enable or
- disable packet forwarding, add IP_FORWARDING=Keep
-to your /etc/shorewall/shorewall.conf file.
-
-
The "shorewall hits" command no longer lists
- extraneous service names in its last report.
-
-
Erroneous instructions in the comments at
- the head of the firewall script have been corrected.
-
-
-
+
Shorewall now enables Ipv4 Packet Forwarding by default. Packet
+forwarding may be disabled by specifying IP_FORWARD=Off in
+/etc/shorewall/shorewall.conf. If you don't want Shorewall to enable or
+disable packet forwarding, add IP_FORWARDING=Keep to your
+/etc/shorewall/shorewall.conf file.
+
The "shorewall hits" command no longer lists extraneous service
+names in its last report.
+
Erroneous instructions in the comments at the head of the
+firewall script have been corrected.
-
-
-
-
6/23/2001 - The current version of Shorewall is 1.1.9. In this version
-
-
-
+
6/23/2001 - The current version of Shorewall is 1.1.9. In
+this
+version
-
-
The "tunnels" file really is in
- the RPM now.
-
-
SNAT can now be applied to port-forwarded
- connections.
-
-
A bug which would cause firewall start
-failures in some dhcp configurations has been fixed.
-
-
The firewall script now issues a message
- if you have the name of an interface in the second
- column in an entry in /etc/shorewall/masq and that
- interface is not up.
SNAT can now be applied to port-forwarded connections.
+
A bug which would cause firewall start failures in some dhcp
+configurations has been fixed.
+
The firewall script now issues a message if you have the name of
+an interface in the second column in an entry in /etc/shorewall/masq
+and that interface is not up.
Previous versions of Shorewall have
- an implementation of Static NAT which violates the
- principle of least surprise. NAT only occurs for packets
- arriving at (DNAT) or send from (SNAT) the interface
- named in the INTERFACE column of /etc/shorewall/nat.
- Beginning with version 1.1.6, NAT effective regardless
- of which interface packets come from or are destined to.
- To get compatibility with prior versions, I have added
- a new "ALL "ALL INTERFACES"
- column to /etc/shorewall/nat. By placing "no"
-or "No" in the new column, the NAT behavior of prior
- versions may be retained.
-
-
The treatment of IPSEC Tunnels where the remote
- gateway is a standalone system has been improved. Previously,
- it was necessary to include an additional rule allowing
- UDP port 500 traffic to pass through the tunnel. Shorewall
- will now create this rule automatically when you place
-the name of the remote peer's zone in a new GATEWAY ZONE column
-in /etc/shorewall/tunnels.
Previous versions of Shorewall have an implementation of Static
+NAT which violates the principle of least surprise. NAT only
+occurs for packets arriving at (DNAT) or send from (SNAT) the interface
+named in the INTERFACE column of /etc/shorewall/nat. Beginning with
+version 1.1.6, NAT effective regardless of which interface packets come
+from or are destined to. To get compatibility with prior versions, I
+have added a new "ALL "ALL
+INTERFACES" column to /etc/shorewall/nat. By placing "no" or
+"No" in the new column, the NAT behavior of prior versions may be
+retained.
+
The treatment of IPSEC Tunnels
+where the remote gateway is a standalone system has been improved.
+Previously, it was necessary to include an additional rule allowing UDP
+port 500 traffic to pass through the tunnel. Shorewall will now create
+this rule automatically when you place the name of the remote peer's
+zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels.
-
-
-
-
5/20/2001 - The current version of Shorewall is 1.1.5. In this version
-
-
-
+
5/20/2001 - The current version of Shorewall is 1.1.5. In
+this
+version
Corrected problem where if "shorewall start"
- aborted early (due to kernel configuration errors
- for example), superfluous 'sed' error messages
- were reported.
-
-
Corrected rules generated for port redirection.
-
-
The order in which iptables kernel modules
- are loaded has been corrected (Thanks to Mark
- Pavlidis).
Corrected problem where if "shorewall start" aborted early (due
+to kernel configuration errors for example), superfluous 'sed' error
+messages were reported.
+
Corrected rules generated for port redirection.
+
The order in which iptables kernel modules are loaded has been
+corrected (Thanks to
+Mark Pavlidis).
-
-
-
-
4/28/2001 - The current version of Shorewall is 1.1.3. In this version
-
-
-
+
4/28/2001 - The current version of Shorewall is 1.1.3. In
+this
+version
-
-
Correct message issued when Proxy ARP address
- added (Thanks to Jason Kirtland).
-
-
/tmp/shorewallpolicy-$$ is now removed
-if there is an error while starting the firewall.
-
-
/etc/shorewall/icmp.def and /etc/shorewall/common.def
- are now used to define the icmpdef and common
- chains unless overridden by the presence of /etc/shorewall/icmpdef
- or /etc/shorewall/common.
-
-
In the .lrp, the file /var/lib/lrpkg/shorwall.conf
- has been corrected. An extra space after
-"/etc/shorwall/policy" has been removed and "/etc/shorwall/rules"
- has been added.
-
-
When a sub-shell encounters a fatal error
- and has stopped the firewall, it now kills the
- main shell so that the main shell will not continue.
-
-
A problem has been corrected where a sub-shell
- stopped the firewall and main shell continued
- resulting in a perplexing error message referring
- to "common.so" resulted.
-
-
Previously, placing "-" in the PORT(S)
-column in /etc/shorewall/rules resulted in an
-error message during start. This has been corrected.
-
-
The first line of "install.sh" has been
-corrected -- I had inadvertently deleted the initial
- "#".
-
-
-
+
Correct message issued when Proxy ARP address added (Thanks to
+Jason Kirtland).
+
/tmp/shorewallpolicy-$$ is now removed if there is an error while
+starting the firewall.
+
/etc/shorewall/icmp.def and /etc/shorewall/common.def are now
+used to define the icmpdef and common chains unless overridden by the
+presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
+
In the .lrp, the file /var/lib/lrpkg/shorwall.conf has been
+corrected. An extra space after "/etc/shorwall/policy" has been removed
+and
+"/etc/shorwall/rules" has been added.
+
When a sub-shell encounters a fatal error and has stopped the
+firewall, it now kills the main shell so that the main shell will not
+continue.
+
A problem has been corrected where a sub-shell stopped the
+firewall and main shell continued resulting in a perplexing error
+message referring to "common.so" resulted.
+
Previously, placing "-" in the PORT(S) column in
+/etc/shorewall/rules resulted in an error message during start. This
+has been corrected.
+
The first line of "install.sh" has been corrected -- I had
+inadvertently deleted the initial "#".
-
-
-
-
4/12/2001 - The current version of Shorewall is 1.1.2. In this version
-
-
-
+
4/12/2001 - The current version of Shorewall is 1.1.2. In
+this
+version
The firewall no longer fails to start if
- "routefilter" is specified for an interface that
- isn't started. A warning message is now issued
- in this case.
-
-
The LRP Version is renamed "shorwall" for
- 8,3 MSDOS file system compatibility.
The firewall no longer fails to start if "routefilter" is
+specified for an interface that isn't started. A warning message is now
+issued in this case.
+
The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
+compatibility.
4/5/2001 - The current version of Shorewall is 1.1.1. In this
+version:
-
-
The common chain is traversed from INPUT,
- OUTPUT and FORWARD before logging occurs
-
-
The source has been cleaned up dramatically
-
-
DHCP DISCOVER packets with RFC1918 source
- addresses no longer generate log messages. Linux
- DHCP clients generate such packets and it's
- annoying to see them logged.
-
-
-
+
The common chain is traversed from INPUT, OUTPUT and FORWARD
+before logging occurs
+
The source has been cleaned up dramatically
+
DHCP DISCOVER packets with RFC1918 source addresses no longer
+generate log messages. Linux DHCP clients generate such packets and
+it's annoying to see them logged.
-
-
-
-
3/25/2001 - The current version of Shorewall is 1.1.0. In this version:
-
-
-
+
3/25/2001 - The current version of Shorewall is 1.1.0. In this
+version:
-
-
Log messages now indicate the packet disposition.
-
-
Error messages have been improved.
-
-
The ability to define zones consisting of
- an enumerated set of hosts and/or subnetworks has
- been added.
-
-
The zone-to-zone chain matrix is now sparse
- so that only those chains that contain meaningful
- rules are defined.
-
-
240.0.0.0/4 and 169.254.0.0/16 have been
- added to the source subnetworks whose packets
- are dropped under the norfc1918 interface
- option.
-
-
Exits are now provided for executing an
- user-defined script when a chain is defined,
-when the firewall is initialized, when the firewall
- is started, when the firewall is stopped and when
-the firewall is cleared.
-
-
The Linux kernel's route filtering facility
- can now be specified selectively on network
- interfaces.
-
-
-
+
Log messages now indicate the packet disposition.
+
Error messages have been improved.
+
The ability to define zones consisting of an enumerated set of
+hosts and/or subnetworks has been added.
+
The zone-to-zone chain matrix is now sparse so that only those
+chains that contain meaningful rules are defined.
+
240.0.0.0/4 and 169.254.0.0/16 have been added to the source
+subnetworks whose packets are dropped under the norfc1918
+interface option.
+
Exits are now provided for executing an user-defined script when
+a chain is defined, when the firewall is initialized, when the firewall
+is started, when the firewall is stopped and when the firewall is
+cleared.
+
The Linux kernel's route filtering facility can now be specified
+selectively on network interfaces.
-
-
-
-
3/19/2001 - The current version of Shorewall is 1.0.4. This version:
-
-
-
+
3/19/2001 - The current version of Shorewall is 1.0.4. This
+version:
-
-
Allows user-defined zones. Shorewall now
- has only one pre-defined zone (fw) with the remaining
- zones being defined in the new configuration
- file /etc/shorewall/zones. The /etc/shorewall/zones file
- released in this version provides behavior that
- is compatible with Shorewall 1.0.3.
-
-
Adds the ability to specify logging in entries
- in the /etc/shorewall/rules file.
-
-
Correct handling of the icmp-def chain so
- that only ICMP packets are sent through the
- chain.
-
-
Compresses the output of "shorewall monitor"
- if awk is installed. Allows the command to work
- if awk isn't installed (although it's not pretty).
-
-
-
+
Allows user-defined zones. Shorewall now has only one pre-defined
+zone (fw) with the remaining zones being defined in the new
+configuration file /etc/shorewall/zones. The /etc/shorewall/zones file
+released in this version provides behavior
+that is compatible with Shorewall 1.0.3.
+
Adds the ability to specify logging in entries in the
+/etc/shorewall/rules file.
+
Correct handling of the icmp-def chain so that only ICMP packets
+are sent through the chain.
+
Compresses the output of "shorewall monitor" if awk is installed.
+Allows the command to work if awk isn't installed (although it's not
+pretty).
-
-
-
-
3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix
- release with no new features.
-
-
-
+
3/13/2001 - The current version of Shorewall is 1.0.3. This is a
+bug-fix release with no new features.
-
-
The PATH variable in the firewall script
- now includes /usr/local/bin and /usr/local/sbin.
-
-
DMZ-related chains are now correctly deleted
- if the DMZ is deleted.
-
-
The interface OPTIONS for "gw" interfaces
- are no longer ignored.
-
-
-
+
The PATH variable in the firewall script now includes
+/usr/local/bin and /usr/local/sbin.
+
DMZ-related chains are now correctly deleted if the DMZ is
+deleted.
+
The interface OPTIONS for "gw" interfaces are no longer ignored.
-
-
-
-
3/8/2001 - The current version of Shorewall is 1.0.2. It supports an
- additional "gw" (gateway) zone for
- tunnels and it supports IPSEC tunnels with
- end-points on the firewall. There is also a .lrp available
- now.
NOTE: I am no longer attempting to maintain MPPE patches for
+current
+Linux kernel's and pppd. I recommend that you refer to the following
+URLs
+for information about installing MPPE into your kernel and pppd.
+
The Linux PPTP client
+project
+has a nice GUI for configuring and managing VPN connections where
+your
+Linux system is the PPTP client. This is what I currently use. I am no
+longer
+running PoPToP but rather I use the PPTP Server included with XP
+Professional
+(see PPTP Server running behind your Firewall
+below).
I am leaving the instructions for building MPPE-enabled kernels and
+pppd
+in the text below for those who may wish to obtain the relevant current
+patches
+and "roll their own".
+
+
+
Shorewall easily supports PPTP in a number of
+configurations:
I will try to give you an idea of how to set up a PPTP server on
+your
+firewall system. This isn't a detailed HOWTO but rather an example of
+how
+I have set up a working PPTP server on my own firewall.
Un-tar the pppd source and uncompress the patches into one directory
+(the
+patches and the ppp-2.4.1 directory are all in a single parent
+directory):
+
+
cd ppp-2.4.1
+
patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
+
patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
+
(Optional) patch -p1 < ../require-mppe.diff
+
./configure
+
make
+
+
You will need to install the resulting binary on your firewall
+system.
+To do that, I NFS mount my source filesystem and use "make install"
+from
+the ppp-2.4.1 directory.
+
Patching and Building your Kernel
+
You will need one of the following patches depending on your kernel
+version:
Now configure your kernel. Here is my ppp configuration:
+
+
+
+
Configuring Samba
+
You will need a WINS server (Samba configured to run as a WINS
+server
+is fine). Global section from /etc/samba/smb.conf on my WINS server
+(192.168.1.3)
+is:
+
+
[global] workgroup = TDM-NSTOP netbios name = WOOKIE server string = GNU/Linux Box encrypt passwords = Yes log file = /var/log/samba/%m.log max log size = 0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 os level = 65 domain master = True preferred master = True dns proxy = No wins support = Yes printing = lprng
[homes] comment = Home Directories valid users = %S read only = No create mask = 0664 directory mask = 0775
System 192.168.1.3 acts as a WINS server so I have included that
+IP
+as the 'ms-wins' value.
+
I have pointed the remote clients at my DNS server -- it has
+external
+address 206.124.146.177.
+
I am requiring 128-bit stateless compression (my kernel is built
+with
+the 'require-mppe.diff' patch mentioned above.
+
+
Here's my /etc/ppp/chap-secrets:
+
+
Secrets for authentication using
+CHAP
+# client
+server secret IP addresses
+CPQTDM\\TEastep *
+<shhhhhh> 192.168.1.7
+TEastep
+* <shhhhhh>
+192.168.1.7
+
+
I am the only user who connects to the server but I may connect
+either
+with or without a domain being specified. The system I connect from is
+my
+laptop so I give it the same IP address when tunneled in at it has when
+I
+use its wireless LAN card around the house.
+
You will also want the following in /etc/modules.conf:
+
alias ppp-compress-18 ppp_mppe alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate
I specify the /etc/ppp/options.poptop file as my ppp options file
+(I
+have several).
+
The local IP is the same as my internal interface's
+(192.168.1.254).
+
I have assigned a remote IP range that overlaps my local network.
+This,
+together with 'proxyarp' in my /etc/ppp/options.poptop file make the
+remote
+hosts look like they are part of the local subnetwork.
+
+
I use this file to start/stop pptpd -- I have this in
+/etc/init.d/pptpd:
+
+
#!/bin/sh
+#
+# /etc/rc.d/init.d/pptpd
+#
+# chkconfig: 5 12 85
+# description: control pptp server
+#
+
+case "$1" in
+start)
+ echo 1 > /proc/sys/net/ipv4/ip_forward
+ modprobe ppp_async
+ modprobe ppp_generic
+ modprobe ppp_mppe
+ modprobe slhc
+ if /usr/local/sbin/pptpd; then
+ touch /var/lock/subsys/pptpd
+ fi
+ ;;
+stop)
+ killall pptpd
+ rm -f /var/lock/subsys/pptpd
+ ;;
+restart)
+ killall pptpd
+ if /usr/local/sbin/pptpd; then
+ touch /var/lock/subsys/pptpd
+ fi
+ ;;
+status)
+ ifconfig
+ ;;
+*)
+ echo "Usage: $0 {start|stop|restart|status}"
+ ;;
+esac
+
+
Configuring Shorewall
+
I consider hosts connected to my PPTP server to be just like local
+systems.
+My key Shorewall entries are:
+
/etc/shorewall/zones:
+
+
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
net
+
Internet
+
The Internet
+
+
+
loc
+
Local
+
My Local Network including remote PPTP clients
+
+
+
+
+
/etc/shorewall/interfaces:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
eth0
+
206.124.146.255
+
norfc1918
+
+
+
loc
+
eth2
+
192.168.1.255
+
+
+
+
-
+
ppp+
+
+
+
+
+
+
+
/etc/shorewall/hosts:
+
+
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
loc
+
eth2:192.168.1.0/24
+
-
-
-
-
-
NOTE: I am no longer attempting to maintain MPPE patches for current Linux
-kernel's and pppd. I recommend that you refer to the following URLs for information
-about installing MPPE into your kernel and pppd.
-
-
The Linux PPTP client project
-has a nice GUI for configuring and managing VPN connections where your
-Linux system is the PPTP client. This is what I currently use. I am no longer
-running PoPToP but rather I use the PPTP Server included with XP Professional
-(see PPTP Server running behind your Firewall
-below).
I am leaving the instructions for building MPPE-enabled kernels and pppd
-in the text below for those who may wish to obtain the relevant current patches
-and "roll their own".
-
-
-
-
Shorewall easily supports PPTP in a number of configurations:
I will try to give you an idea of how to set up a PPTP server on your firewall
-system. This isn't a detailed HOWTO but rather an example of how I have set
-up a working PPTP server on my own firewall.
Un-tar the pppd source and uncompress the patches into one directory (the
- patches and the ppp-2.4.1 directory are all in a single parent directory):
-
-
-
cd ppp-2.4.1
-
patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
-
patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
-
(Optional) patch -p1 < ../require-mppe.diff
-
./configure
-
make
-
-
-
-
You will need to install the resulting binary on your firewall system.
- To do that, I NFS mount my source filesystem and use "make install" from
-the ppp-2.4.1 directory.
-
-
Patching and Building your Kernel
-
-
You will need one of the following patches depending on your kernel version:
Now configure your kernel. Here is my ppp configuration:
-
-
-
-
-
-
-
Configuring Samba
-
-
You will need a WINS server (Samba configured to run as a WINS server is
- fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3)
- is:
-
-
-
[global] workgroup = TDM-NSTOP netbios name = WOOKIE server string = GNU/Linux Box encrypt passwords = Yes log file = /var/log/samba/%m.log max log size = 0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 os level = 65 domain master = True preferred master = True dns proxy = No wins support = Yes printing = lprng
[homes] comment = Home Directories valid users = %S read only = No create mask = 0664 directory mask = 0775
System 192.168.1.3 acts as a WINS server so I have included that
- IP as the 'ms-wins' value.
-
I have pointed the remote clients at my DNS server -- it has external
- address 206.124.146.177.
-
I am requiring 128-bit stateless compression (my kernel is built
- with the 'require-mppe.diff' patch mentioned above.
-
-
-
-
Here's my /etc/ppp/chap-secrets:
-
-
-
Secrets for authentication using CHAP
- # client server secret IP addresses
- CPQTDM\\TEastep * <shhhhhh> 192.168.1.7
- TEastep * <shhhhhh> 192.168.1.7
-
-
-
I am the only user who connects to the server but I may connect either
- with or without a domain being specified. The system I connect from is my
- laptop so I give it the same IP address when tunneled in at it has when
-I use its wireless LAN card around the house.
-
-
You will also want the following in /etc/modules.conf:
-
-
alias ppp-compress-18 ppp_mppe alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate
I specify the /etc/ppp/options.poptop file as my ppp options file
- (I have several).
-
The local IP is the same as my internal interface's (192.168.1.254).
-
I have assigned a remote IP range that overlaps my local network.
- This, together with 'proxyarp' in my /etc/ppp/options.poptop file make
- the remote hosts look like they are part of the local subnetwork.
-
-
-
-
I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd:
/etc/shoreawll/tunnels (For Shorewall versions
+1.3.10 and
+later)
+
+
-
-
-
TYPE
-
-
ZONE
-
-
GATEWAY
-
-
GATEWAY ZONE
-
-
-
-
pptpserver
-
-
net
-
-
0.0.0.0/0
-
-
-
-
-
-
+
+
+
TYPE
+
+
ZONE
+
+
GATEWAY
+
+
GATEWAY ZONE
+
+
+
+
pptpserver
+
+
net
+
+
0.0.0.0/0
+
+
+
+
+
-
-
+
- Note: I have multiple ppp interfaces on my firewall. If you have a single
- ppp interface, you probably want:
-
+Note: I have multiple ppp interfaces on my firewall. If you have a
+single
+ppp interface, you probably want:
/etc/shorewall/interfaces:
-
-
+
-
-
-
ZONE
-
INTERFACE
-
BROADCAST
-
OPTIONS
-
-
-
net
-
eth0
-
206.124.146.255
-
norfc1918
-
-
-
loc
-
eth2
-
192.168.1.255
-
-
-
-
loc
-
ppp0
-
-
-
-
-
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
net
+
eth0
+
206.124.146.255
+
norfc1918
+
+
+
loc
+
eth2
+
192.168.1.255
+
+
+
+
loc
+
ppp0
+
+
+
+
-
-
+
and no entries in /etc/shorewall/hosts.
-
-
2. PPTP Server Running Behind
- your Firewall
-
-
If you have a single external IP address, add the following to your /etc/shorewall/rules
+
2. PPTP Server Running
+Behind
+your Firewall
+
If you have a single external IP address, add the following to your
+/etc/shorewall/rules file:
+
+
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
DNAT
+
net
+
loc:<server address>
+
tcp
+
1723
+
+
+
+
+
DNAT
+
net
+
loc:<server address>
+
47
+
-
+
+
+
+
+
+
If you have multiple external IP address and you want to forward a
+single
+<external address>, add the following to your
+/etc/shorewall/rules
file:
-
+
-
-
-
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
DNAT
-
net
-
loc:<server address>
-
tcp
-
1723
-
-
-
-
-
DNAT
-
net
-
loc:<server address>
-
47
-
-
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
DNAT
+
net
+
loc:<server address>
+
tcp
+
1723
+
-
+
<external address>
+
+
+
DNAT
+
net
+
loc:<server address>
+
47
+
-
+
-
+
<external address>
+
+
-
-
If you have multiple external IP address and you want to forward a single
- <external address>, add the following to your /etc/shorewall/rules
- file:
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
DNAT
-
net
-
loc:<server address>
-
tcp
-
1723
-
-
-
<external address>
-
-
-
DNAT
-
net
-
loc:<server address>
-
47
-
-
-
-
-
<external address>
-
-
-
-
-
-
-
3. PPTP Clients Running Behind
- your Firewall
-
-
You shouldn't have to take any special action for this case unless you
- wish to connect multiple clients to the same external server. In that case,
- you will need to follow the instructions at
+
3. PPTP Clients Running
+Behind
+your Firewall
+
You shouldn't have to take any special action for this case unless
+you
+wish to connect multiple clients to the same external server. In that
+case,
+you will need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html.
- I recommend that you also add these two lines to your /etc/shorewall/modules
- file:
-
-
+I recommend that you also add these two lines to your
+/etc/shorewall/modules
+file:
The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.
- Rather than use the configuration script that comes with the client, I
-built my own. I also build my own kernel as described
-above rather than using the mppe package that is available with the
-client. My /etc/ppp/options file is mostly unchanged from what came with
-the client (see below).
-
+ href="http://sourceforge.net/projects/pptpclient/">http://sourceforge.net/projects/pptpclient/.
+Rather than use the configuration script that comes with the client, I
+built
+my own. I also build my own kernel as described
+above
+rather than using the mppe package that is available with the client.
+My
+/etc/ppp/options file is mostly unchanged from what came with the
+client
+(see below).
The key elements of this setup are as follows:
-
-
Define a zone for the remote network accessed via PPTP.
-
Associate that zone with a ppp interface.
-
Define rules for PPTP traffic to/from the firewall.
-
Define rules for traffic two and from the remote zone.
-
+
Define a zone for the remote network accessed via PPTP.
+
Associate that zone with a ppp interface.
+
Define rules for PPTP traffic to/from the firewall.
+
Define rules for traffic two and from the remote zone.
-
Here are examples from my setup:
-
/etc/shorewall/zones
-
-
+
-
-
-
ZONE
-
DISPLAY
-
COMMENTS
-
-
-
cpq
-
Compaq
-
Compaq Intranet
-
-
-
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
cpq
+
Compaq
+
Compaq Intranet
+
+
-
-
+
/etc/shorewall/interfaces
-
-
+
-
-
-
ZONE
-
INTERFACE
-
BROADCAST
-
OPTIONS
-
-
-
-
-
ppp+
-
-
-
-
-
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
-
+
ppp+
+
+
+
+
-
-
+
/etc/shorewall/hosts
-
-
+
-
-
-
ZONE
-
HOST(S)
-
OPTIONS
-
-
-
-
-
ppp+:!192.168.1.0/24
-
-
-
-
+
+
+
ZONE
+
HOST(S)
+
OPTIONS
+
+
+
-
+
ppp+:!192.168.1.0/24
+
+
+
-
-
-
/etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b)
-
-
-
+
+
/etc/shorewall/rules (For Shorewall versions up to and including
+1.3.9b)
+
-
-
+
+
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
ACCEPT
-
fw
-
net
-
tcp
-
1723
-
-
-
-
-
ACCEPT
-
fw
-
net
-
47
-
-
-
-
-
-
-
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
ACCEPT
+
fw
+
net
+
tcp
+
1723
+
+
+
+
+
ACCEPT
+
fw
+
net
+
47
+
-
+
+
+
+
-
-
+
/etc/shorewall/tunnels (For Shorewall versions 1.3.10 and later)
-
-
-
+
+
-
-
-
TYPE
-
-
ZONE
-
-
GATEWAY
-
-
GATEWAY ZONE
-
-
-
-
pptpclient
-
-
net
-
-
0.0.0.0/0
-
-
-
-
-
-
+
+
+
TYPE
+
+
ZONE
+
+
GATEWAY
+
+
GATEWAY ZONE
+
+
+
+
pptpclient
+
+
net
+
+
0.0.0.0/0
+
+
+
+
+
-
-
-
-
I use the combination of interface and hosts file to define the 'cpq' zone
-because I also run a PPTP server on my firewall (see above). Using this
-technique allows me to distinguish clients of my own PPTP server from arbitrary
- hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients
+
+
+
I use the combination of interface and hosts file to define the
+'cpq'
+zone because I also run a PPTP server on my firewall (see above). Using
+this technique allows me to distinguish clients of my own PPTP server
+from arbitrary
+hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP
+clients
and Compaq doesn't use that RFC1918 Class C subnet.
-
-
I use this script in /etc/init.d to control the client. The reason that
- I disable ECN when connecting is that the Compaq tunnel servers don't do
-ECN yet and reject the initial TCP connection request if I enable ECN :-(
-
-
-
+
I use this script in /etc/init.d to control the client. The reason
+that
+I disable ECN when connecting is that the Compaq tunnel servers don't
+do
+ECN yet and reject the initial TCP connection request if I enable ECN
+:-(
+
#
- # Identify this connection
- #
- ipparam Compaq
- #
- # Lock the port
- #
- lock
- #
- # We don't need the tunnel server to authenticate itself
- #
- noauth
-
- +chap
- +chapms
- +chapms-v2
-
- multilink
- mrru 1614
- #
- # Turn off transmission protocols we know won't be used
- #
- nobsdcomp
- nodeflate
-
- #
- # We want MPPE
- #
- mppe-128
- mppe-stateless
-
- #
- # We want a sane mtu/mru
- #
- mtu 1000
- mru 1000
-
- #
- # Time this thing out of it goes poof
- #
- lcp-echo-failure 10
- lcp-echo-interval 10
-
-
-
My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq
- traffic through the PPTP tunnel:
-
-
+# Identify this connection
+#
+ipparam Compaq
+#
+# Lock the port
+#
+lock
+#
+# We don't need the tunnel server to authenticate itself
+#
+noauth
+
++chap
++chapms
++chapms-v2
+
+multilink
+mrru 1614
+#
+# Turn off transmission protocols we know won't be used
+#
+nobsdcomp
+nodeflate
+
+#
+# We want MPPE
+#
+mppe-128
+mppe-stateless
+
+#
+# We want a sane mtu/mru
+#
+mtu 1000
+mru 1000
+
+#
+# Time this thing out of it goes poof
+#
+lcp-echo-failure 10
+lcp-echo-interval 10
+
+
My /etc/ppp/ip-up.local file sets up the routes that I need to route
+Compaq
+traffic through the PPTP tunnel:
5. PPTP Client
+running
+on your Firewall with PPTP Server in an ADSL Modem
+Some ADSL systems in Europe (most notably in Austria) feature a PPTP
+server built into an ADSL "Modem".
+In this setup, an ethernet interface is dedicated to supporting the
+PPTP tunnel between the firewall and the "Modem" while the actual
+internet access is through PPTP (interface ppp0). If you have this type
+of setup, you need to modify the sample configuration
+that you downloaded as described in this section. These changes are in addition to those
+described in the QuickStart
+Guides.
+
+Lets assume the following:
+
+
ADSL Modem connected through eth0
+
Modem IP address = 192.168.1.1
+
eth0 IP address = 192.168.1.2
+
+The changes you need to make are as follows:
+
+1. Add this entry to /etc/shorewall/zones:
+
+
+
+
+
+
ZONE
+
DISPLAY
+
COMMENTS
+
+
+
modem
+
+
Modem
+
ADSL Modem
+
+
+
+
+
+
That entry defines a new zone called 'modem' which will contain only your
+ADSL modem.
+
+
+2. Add the following entry to /etc/shorewall/interfaces:
+
+
+
+
+
ZONE
+
INTERFACE
+
BROADCAST
+
OPTIONS
+
+
+
modem
+
+
eth0
+
+
192.168.1.255
+
+
dhcp
+
+
+
+
+
You will of course modify the 'net'
+entry in /etc/shorewall/interfaces to specify 'pppo' as the interface
+as described in the QuickStart Guide corresponding to your setup.
+
+
+3. Add the following to /etc/shorewall/tunnels:
+
+
+
+
+
+
TYPE
+
+
ZONE
+
+
GATEWAY
+
+
GATEWAY ZONE
+
+
+
+
pptpclient
+
modem
+
+
192.168.1.1
+
+
+
+
+
+
+
+
+That entry allows a PPTP tunnel to be established between your
+Shorewall system and the PPTP server in the modem.
+
-
- This page covers Shorewall configuration to use with
+This page covers Shorewall configuration to use with Squid running as a Transparent
- Proxy. If you are running Shorewall 1.3, please see . If you are running Shorewall 1.3, please see this documentation.
-
-
- Please observe the following general requirements:
-
-
- In all cases, Squid should be configured
- to run as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
-
-
- The following instructions mention the
- files /etc/shorewall/start and /etc/shorewall/init -- if you don't have
- those files, siimply create them.
-
-
- When the Squid server is in the DMZ
-zone or in the local zone, that zone must be defined ONLY by its interface
- -- no /etc/shorewall/hosts file entries. That is because the packets
-being routed to the Squid server still have their original destination
-IP addresses.
-
-
- You must have iptables installed on
-your Squid server.
-
-
- If you run a Shorewall version earlier
- than 1.4.6, you must have NAT and MANGLE enabled in your /etc/shorewall/conf
- file
-
-
- NAT_ENABLED=Yes
- MANGLE_ENABLED=Yes
-
- Three different configurations are covered:
-
+
+ Please observe the
+following general requirements:
+
+
+ In all cases, Squid should be configured to run
+as a transparent proxy as described at http://tldp.org/HOWTO/mini/TransparentProxy.html.
+
+
+ The following instructions mention
+the files /etc/shorewall/start and /etc/shorewall/init -- if you don't
+have those files, siimply create them.
+
+
+When the Squid server is in the DMZ zone or in the local zone, that
+zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
+file entries. That is because the packets being routed to the Squid
+server still have their original destination IP addresses.
+
+
+You must have iptables installed on your Squid server.
+
+
+If you run a Shorewall version earlier than 1.4.6, you must have NAT
+and MANGLE enabled in your /etc/shorewall/conf file
+
+
+NAT_ENABLED=Yes
+MANGLE_ENABLED=Yes
+
+Three different configurations are covered:
-
- You want to redirect all local www connection requests EXCEPT
- those to your
-own http server (206.124.146.177)
- to a Squid
- transparent proxy running on the firewall and listening on
-port 3128. Squid will of course require access to remote web servers.
-
- In /etc/shorewall/rules:
-
-
-
+You want to redirect all local www connection requests
+EXCEPT those to your own http server (206.124.146.177) to a Squid
+transparent proxy running on the firewall
+and listening on port 3128. Squid will of course require access
+to remote web servers.
+
+In /etc/shorewall/rules:
+
+
-
-
-
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
REDIRECT
-
loc
-
3128
-
tcp
-
www
-
-
-
-
!206.124.146.177
-
-
-
ACCEPT
-
fw
-
net
-
tcp
-
www
-
-
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+PORT(S)
+
SOURCE
+PORT(S)
+
ORIGINAL
+DEST
+
+
+
REDIRECT
+
loc
+
3128
+
tcp
+
www
+
-
+
+
!206.124.146.177
+
+
+
ACCEPT
+
fw
+
net
+
tcp
+
www
+
+
+
+
+
+
-
-
- There may be a requirement to exclude additional destination hosts
- or networks from being redirected. For example, you might also want requests
- destined for 130.252.100.0/24 to not be routed to Squid. In that case, you
- must add a manual rule in /etc/shorewall/start:
-
-
+
+
+There may be a requirement to exclude additional destination
+hosts or networks from being redirected. For example, you might also
+want
+requests destined for 130.252.100.0/24 to not be routed to Squid. In
+that
+case, you must add a manual rule in /etc/shorewall/start:
+
- To exclude additional hosts or networks, just add additional similar
- rules.
-
+
+ To exclude additional hosts or networks, just add additional
+similar rules.
Squid Running in the local network
- You want to redirect all local www connection requests
-to a Squid transparent
- proxy running in your local zone at 192.168.1.3 and listening on
-port 3128. Your local interface is eth1. There may also be a web server
-running on 192.168.1.3. It is assumed that web access is already enabled
-from the local zone to the internet.
-
-
WARNING: This setup may conflict with
- other aspects of your gateway including but not limited to traffic
- shaping and route redirection. For that reason, I don't recommend
- it.
-
-
+You want to redirect all local www connection requests to a Squid
+transparent proxy running in your local zone at 192.168.1.3 and
+listening
+on port 3128. Your local interface is eth1. There may also be a web
+server running on 192.168.1.3. It is assumed that web access is already
+enabled from the local zone to the internet..
-
On your firewall system, issue the following command
-
-
+
On your firewall system, issue the following command
+
-
-
+
echo 202 www.out >> /etc/iproute2/rt_tables
-
-
+
-
In /etc/shorewall/init, put:
-
-
+
In /etc/shorewall/init, put:
+
-
-
+
if [ -z "`ip rule list | grep www.out`" ] ; then ip rule add fwmark 202 table www.out ip route add default via 192.168.1.3 dev eth1 table www.out ip route flush cache echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects fi
-
-
+
-
If you are running Shorewall 1.4.1 or Shorewall 1.4.1a,
- please upgrade to Shorewall 1.4.2 or later.
-
-
-
If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:
-
-
-
-
-
-
ZONE
-
-
INTERFACE
-
-
BROADCAST
-
-
OPTIONS
-
-
-
-
loc
-
-
eth1
-
-
detect
-
-
routeback
-
-
-
-
-
-
-
-
In /etc/shorewall/rules:
-
-
-
-
-
-
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
-
-
ACCEPT
-
-
loc
-
loc
-
-
tcp
-
www
-
-
-
-
-
-
-
-
-
-
-
Alternativfely, if you are running Shorewall 1.4.0 you can have
- the following policy in place of the above rule:
-
-
-
-
-
SOURCE
-
-
DESTINATION
-
-
POLICY
-
-
LOG LEVEL
-
-
BURST PARAMETERS
-
-
-
-
loc
-
-
loc
-
-
ACCEPT
-
-
-
-
-
-
-
-
-
-
-
-
In /etc/shorewall/start add:
-
-
-
-
-
-
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-
-
-
-
On 192.168.1.3, arrange for the following command to
-be executed after networking has come up
-
-
If you are running RedHat on the server, you can simply execute
- the following commands after you have typed the iptables command
-above:
-
-
-
-
-
-
iptables-save > /etc/sysconfig/iptables chkconfig --level 35 iptables on
-
-
-
-
-
Squid Running in the DMZ (This is what I do)
- You have a single Linux system in your DMZ with IP address
- 192.0.2.177. You want to run both a web server and Squid on that system.
- Your DMZ interface is eth1 and your local interface is eth2.
-
-
-
On your firewall system, issue the following command
-
-
-
-
-
-
echo 202 www.out >> /etc/iproute2/rt_tables
-
-
-
-
In /etc/shorewall/init, put:
-
-
-
-
-
-
if [ -z "`ip rule list | grep www.out`" ] ; then ip rule add fwmark 202 table www.out ip route add default via 192.0.2.177 dev eth1 table www.out ip route flush cache fi
-
-
-
-
Do one of the following:
-
- A) In /etc/shorewall/start add
-
-
-
-
-
-
iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
-
-
-
B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
- and add the following entry in /etc/shorewall/tcrules:
-
-
-
-
-
-
-
-
MARK
-
-
SOURCE
-
-
DESTINATION
-
-
PROTOCOL
-
-
PORT
-
-
CLIENT PORT
-
-
-
-
202
-
-
eth2
-
-
0.0.0.0/0
-
-
tcp
-
-
80
-
-
-
-
-
-
-
-
-
- C) Run Shorewall 1.3.14 or later and add the following entry in
- /etc/shorewall/tcrules:
-
-
-
-
-
-
-
-
MARK
-
-
SOURCE
-
-
DESTINATION
-
-
PROTOCOL
-
-
PORT
-
-
CLIENT PORT
-
-
-
-
202:P
-
-
eth2
-
-
0.0.0.0/0
-
-
tcp
-
-
80
-
-
-
-
-
-
-
-
-
-
-
-
-
In /etc/shorewall/rules, you will need:
-
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DEST
-
-
PROTO
-
-
DEST
- PORT(S)
-
-
CLIENT
- PORT(2)
-
-
ORIGINAL
- DEST
-
-
-
-
ACCEPT
-
-
loc
-
-
dmz
-
-
tcp
-
-
80
-
-
-
-
-
-
-
-
ACCEPT
-
-
dmz
-
-
net
-
-
tcp
-
-
80
-
-
-
-
-
-
-
-
-
-
-
-
-
-
On 192.0.2.177 (your Web/Squid server), arrange for
-the following command to be executed after networking has come up
-
-
If you are running RedHat on the server, you can simply
+execute the following commands after you have typed the iptables
+command above:
+
+
+
+
iptables-save > /etc/sysconfig/iptables chkconfig --level 35 iptables on
+
+
+
Squid Running in the DMZ (This is what I do)
+You have a single Linux system in your DMZ with IP address 192.0.2.177.
+You want to run both a web server and Squid on that system. Your DMZ
+interface is eth1 and your local interface is eth2.
+
+
On your firewall system, issue the following command
+
+
+
+
echo 202 www.out >> /etc/iproute2/rt_tables
+
+
+
In /etc/shorewall/init, put:
+
+
+
+
if [ -z "`ip rule list | grep www.out`" ] ; then ip rule add fwmark 202 table www.out ip route add default via 192.0.2.177 dev eth1 table www.out ip route flush cache fi
+
+
+
Do one of the following:
+
+A) In /etc/shorewall/start add
+
+
+
+
iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
+
+
B) Set MARK_IN_FORWARD_CHAIN=No in
+/etc/shorewall/shorewall.conf and add the following entry in
+/etc/shorewall/tcrules:
+
+
+
+
+
+
+
MARK
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
CLIENT PORT
+
+
+
+
202
+
+
eth2
+
+
0.0.0.0/0
+
+
tcp
+
+
80
+
+
-
+
+
+
+
+
+C) Run Shorewall 1.3.14 or later and add the following entry
+in /etc/shorewall/tcrules:
+
+
+
+
+
+
+
MARK
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT
+
+
CLIENT PORT
+
+
+
+
202:P
+
+
eth2
+
+
0.0.0.0/0
+
+
tcp
+
+
80
+
+
-
+
+
+
+
+
+
+
+
In /etc/shorewall/rules, you will need:
+
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DEST
+
+
PROTO
+
+
DEST
+PORT(S)
+
+
CLIENT
+PORT(2)
+
+
ORIGINAL
+DEST
+
+
+
+
ACCEPT
+
+
loc
+
+
dmz
+
+
tcp
+
+
80
+
+
+
+
+
+
+
+
ACCEPT
+
+
dmz
+
+
net
+
+
tcp
+
+
80
+
+
+
+
+
+
+
+
+
+
+
+
On 192.0.2.177 (your Web/Squid server), arrange for the following
+command to be executed after networking has come up
+
- The traditional net-tools contain a program called ifconfig
- which is used to configure network devices. ifconfig introduced the concept
- of aliased or virtial interfaces. These virtual interfaces
- have names of the form interface:integer (e.g., eth0:0)
-and ifconfig treats them more or less like real interfaces.
-
- Example:
-
+ The traditional net-tools contain a program called ifconfig
+ which is used to configure network devices. ifconfig introduced the
+concept of aliased or virtual interfaces. These virtual
+interfaces have names of the form interface:integer (e.g.,
+eth0:0) and ifconfig treats them more or less like real interfaces.
+
+ Example:
+
[root@gateway root]# ifconfig eth0:0 eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55 inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x2000 [root@gateway root]#
- The ifconfig utility is being gradually phased out in favor of the
-ip utility which is part of the iproute package. The ip utility
-does not use the concept of aliases or virtual interfaces but rather treats
-additional addresses on an interface as objects. The ip utility does provide
-for interaction with ifconfig in that it allows addresses to be labeled
-and labels may take the form of ipconfig virtual interfaces.
-
- Example:
-
-
+ The ifconfig utility is being gradually phased out in favor of the
+ ip utility which is part of the iproute package. The ip
+utility does not use the concept of aliases or virtual interfaces but rather
+treats additional addresses on an interface as objects in their own right.
+The ip utility does provide for interaction with ifconfig in that it allows
+addresses to be labeled where these labels take the form of ipconfig
+virtual interfaces.
+
+ Example:
+
+
[root@gateway root]# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100 link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0 [root@gateway root]#
- Note that one cannot type "ip addr show dev eth0:0" because
- "eth0:0" is a label for a particular address rather than a device name.
-
+ Note that one cannot type "ip addr show dev eth0:0" because
+ "eth0:0" is a label for a particular address rather than a device name.
+
[root@gateway root]# ip addr show dev eth0:0 Device "eth0:0" does not exist. [root@gateway root]#
- The iptables program doesn't support virtual interfaces in either
-it's "-i" or "-o" command options; as a consequence, Shorewall does not
-allow them to be used in the /etc/shorewall/interfaces file.
-
-
+ The iptables program doesn't support virtual interfaces in either
+ it's "-i" or "-o" command options; as a consequence, Shorewall does not
+ allow them to be used in the /etc/shorewall/interfaces file or anywhere
+else except as described in the discussion below.
+
+
+
Adding Addresses to Interfaces
+Shorewall provides facilities for automatically adding addresses to interfaces
+as described in the following section. It is also easy to add them yourself
+using the ip utility. The above alias was added using:
+
+You probably want to arrange to add these addresses when the device is started
+rather than placing commands like the above in one of the Shorewall extension
+scripts. For example, on RedHat systems, you can place the commands in /sbin/ifup-local:
+
+
+
#!/bin/sh
case $1 in eth0) /sbin/ip addr add 206.124.146.177 dev eth0 label eth0:0 ;; esac
+
+RedHat systems also allow adding such aliases from the network administration
+GUI (which works well if you have a graphical environment on your firewall).
So how do I handle more than one address on an interface?
- The answer depends on what you are trying to do with the interfaces.
- In the sub-sections that follow, we'll take a look at common scenarios.
-
+ The answer depends on what you are trying to do with the interfaces.
+ In the sub-sections that follow, we'll take a look at common scenarios.
+
Separate Rules
- If you need to make a rule for traffic to/from the firewall itself
-that only applies to a particular IP address, simply qualify the $FW zone
-with the IP address.
-
- Example (allow SSH from net to eth0:0 above):
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DESTINATION
-
-
PROTOCOL
-
-
PORT(S)
-
-
SOURCE PORT(S)
-
-
ORIGINAL DESTINATION
-
-
-
-
ACCEPT
-
-
net
-
-
fw:206.124.146.178
-
-
tcp
-
-
22
-
-
-
-
-
-
-
-
-
+ If you need to make a rule for traffic to/from the firewall itself
+ that only applies to a particular IP address, simply qualify the $FW zone
+ with the IP address.
-
-
-
DNAT
- Suppose that I had set up eth0:0 as above and I wanted to port forward
- from that virtual interface to a web server running in my local zone
-at 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules
- file:
-
-
-
+ Example (allow SSH from net to eth0:0 above):
+
+
+
-
-
-
ACTION
-
-
SOURCE
-
-
DESTINATION
-
-
PROTOCOL
-
-
PORT(S)
-
-
SOURCE PORT(S)
-
-
ORIGINAL DESTINATION
-
-
-
-
DNAT
-
-
net
-
-
loc:192.168.1.3
-
-
tcp
-
-
80
-
-
-
-
-
206.124.146.178
-
-
-
-
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT(S)
+
+
SOURCE PORT(S)
+
+
ORIGINAL DESTINATION
+
+
+
+
ACCEPT
+
+
net
+
+
$FW:206.124.146.178
+
+
tcp
+
+
22
+
+
+
+
+
+
+
+
+
+
+
+
DNAT
+ Suppose that I had set up eth0:0 as above and I wanted to port
+forward from that virtual interface to a web server running in my local
+zone at 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules
+ file:
-
-
+
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT(S)
+
+
SOURCE PORT(S)
+
+
ORIGINAL DESTINATION
+
+
+
+
DNAT
+
+
net
+
+
loc:192.168.1.3
+
+
tcp
+
+
80
+
+
-
+
+
206.124.146.178
+
+
+
+
+
+
+
+
SNAT
- If you wanted to use eth0:0 as the IP address for outbound connections
- from your local zone (eth1), then in /etc/shorewall/masq:
-
-
-
-
-
-
-
INTERFACE
-
-
SUBNET
-
-
ADDRESS
-
-
-
-
eth0
-
-
eth1
-
-
206.124.146.178
-
-
-
-
-
+ If you wanted to use eth0:0 as the IP address for outbound connections
+ from your local zone (eth1), then in /etc/shorewall/masq:
-
- Shorewall can create the alias (additional address) for you if you
- set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
+
+
+
+
+
+
INTERFACE
+
+
SUBNET
+
+
ADDRESS
+
+
+
+
eth0
+
+
eth1
+
+
206.124.146.178
+
+
+
+
+
+
+
+ Shorewall can create the alias (additional address) for you if
+you set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
with Shorewall 1.3.14, Shorewall can actually create the "label" (virtual
interface) so that you can see the created address using ifconfig. In
addition to setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface
name in the INTERFACE column as follows:
-
-
+
+
-
-
-
INTERFACE
-
-
SUBNET
-
-
ADDRESS
-
-
-
-
eth0:0
-
-
eth1
-
-
206.124.146.178
-
-
-
-
+
+
+
INTERFACE
+
+
SUBNET
+
+
ADDRESS
+
+
+
+
eth0:0
+
+
eth1
+
+
206.124.146.178
+
+
+
+
-
- Shorewall can also set up SNAT to round-robin over a range of IP addresses.
-Do do that, you specify a range of IP addresses in the ADDRESS column. If
-you specify a label in the INTERFACE column, Shorewall will use that label
-for the first address of the range and will increment the label by one for
-each subsequent label.
-
-
-
+
+ Shorewall can also set up SNAT to round-robin over a range of IP addresses.
+ Do do that, you specify a range of IP addresses in the ADDRESS column. If
+ you specify a label in the INTERFACE column, Shorewall will use that label
+ for the first address of the range and will increment the label by one for
+ each subsequent label.
+
+
+
-
-
-
INTERFACE
-
-
SUBNET
-
-
ADDRESS
-
-
-
-
eth0:0
-
-
eth1
-
-
206.124.146.178-206.124.146.180
-
-
-
-
+
+
+
INTERFACE
+
+
SUBNET
+
+
ADDRESS
+
+
+
+
eth0:0
+
+
eth1
+
+
206.124.146.178-206.124.146.180
+
+
+
+
-
- The above would create three IP addresses:
-
- eth0:0 = 206.124.146.178
- eth0:1 = 206.124.146.179
- eth0:2 = 206.124.146.180
-
+
+ The above would create three IP addresses:
+
+ eth0:0 = 206.124.146.178
+ eth0:1 = 206.124.146.179
+ eth0:2 = 206.124.146.180
+
STATIC NAT
- If you wanted to use static NAT to link eth0:0 with local address
-192.168.1.3, you would have the following in /etc/shorewall/nat:
-
-
-
-
-
-
-
EXTERNAL
-
-
INTERFACE
-
-
INTERNAL
-
-
ALL INTERFACES
-
-
LOCAL
-
-
-
-
206.124.146.178
-
-
eth0
-
-
192.168.1.3
-
-
no
-
-
no
-
-
-
-
-
+ If you wanted to use static NAT to link eth0:0 with local address
+ 192.168.1.3, you would have the following in /etc/shorewall/nat:
-
- Shorewall can create the alias (additional address) for you if you
- set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with
- Shorewall 1.3.14, Shorewall can actually create the "label" (virtual
+
+
+
+
+
+
EXTERNAL
+
+
INTERFACE
+
+
INTERNAL
+
+
ALL INTERFACES
+
+
LOCAL
+
+
+
+
206.124.146.178
+
+
eth0
+
+
192.168.1.3
+
+
no
+
+
no
+
+
+
+
+
+
+
+ Shorewall can create the alias (additional address) for you if
+you set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
+with Shorewall 1.3.14, Shorewall can actually create the "label" (virtual
interface) so that you can see the created address using ifconfig. In
addition to setting ADD_IP_ALIASES=Yes, you specify the virtual interface
name in the INTERFACE column as follows:
-
-
-
+
+
+
-
-
-
EXTERNAL
-
-
INTERFACE
-
-
INTERNAL
-
-
ALL INTERFACES
-
-
LOCAL
-
-
-
-
206.124.146.178
+
+
+
EXTERNAL
+
+
INTERFACE
+
+
INTERNAL
+
+
ALL INTERFACES
+
+
LOCAL
+
+
+
+
206.124.146.178
+
+
eth0:0
+
+
192.168.1.3
+
+
no
+
+
no
+
+
+
+
+
+
+
+ In either case, to create rules that pertain only to this NAT pair,
+ you simply qualify the local zone with the internal IP address.
+
+ Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
+ 192.168.1.3.
+
+
+
+
+
+
+
ACTION
+
+
SOURCE
+
+
DESTINATION
+
+
PROTOCOL
+
+
PORT(S)
+
+
SOURCE PORT(S)
+
+
ORIGINAL DESTINATION
+
+
+
+
ACCEPT
+
+
net
+
+
loc:192.168.1.3
+
+
tcp
+
+
22
+
+
-
eth0:0
+
-
192.168.1.3
-
-
no
-
-
no
-
-
-
-
+
+
+
-
- In either case, to create rules that pertain only to this NAT pair,
- you simply qualify the local zone with the internal IP address.
-
- Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
- 192.168.1.3.
-
-
-
-
-
-
-
ACTION
-
-
SOURCE
-
-
DESTINATION
-
-
PROTOCOL
-
-
PORT(S)
-
-
SOURCE PORT(S)
-
-
ORIGINAL DESTINATION
-
-
-
-
ACCEPT
-
-
net
-
-
loc:192.168.1.3
-
-
tcp
-
-
22
-
-
-
-
-
-
-
-
-
-
-
-
+
+
MULTIPLE SUBNETS
- Sometimes multiple IP addresses are used because there are multiple
- subnetworks configured on a LAN segment. This technique does not provide
- for any security between the subnetworks if the users of the systems have
- administrative privileges because in that case, the users can simply manipulate
- their system's routing table to bypass your firewall/router. Nevertheless,
- there are cases where you simply want to consider the LAN segment itself
- as a zone and allow your firewall/router to route between the two subnetworks.
-
- Example 1: Local interface eth1 interfaces to 192.168.1.0/24
- and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254
+ Sometimes multiple IP addresses are used because there are multiple
+ subnetworks configured on a LAN segment. This technique does not provide
+ for any security between the subnetworks if the users of the systems have
+ administrative privileges because in that case, the users can simply manipulate
+ their system's routing table to bypass your firewall/router. Nevertheless,
+ there are cases where you simply want to consider the LAN segment itself
+ as a zone and allow your firewall/router to route between the two subnetworks.
+
+ Example 1: Local interface eth1 interfaces to 192.168.1.0/24
+ and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254
and eth1:0 is 192.168.20.254. You want to simply route all requests between
- the two subnetworks.
-
+ the two subnetworks.
+
If you are running Shorewall 1.4.1 or Later
- In /etc/shorewall/interfaces:
-
-
+ In /etc/shorewall/interfaces:
+
+
-
-
-
ZONE
-
-
INTERFACE
-
-
BROADCAST
-
-
OPTIONS
-
-
-
-
-
-
-
eth1
-
-
192.168.1.255,192.168.20.255
-
-
-
-
-
-
+
+
+
ZONE
+
+
INTERFACE
+
+
BROADCAST
+
+
OPTIONS
+
+
+
+
-
+
+
eth1
+
+
192.168.1.255,192.168.20.255
+
+
+
+
+
+
-
-
- In /etc/shorewall/hosts:
-
-
+
+
+ In /etc/shorewall/hosts:
+
+
-
-
-
ZONE
-
-
HOSTS
-
-
OPTIONS
-
-
-
-
loc
-
-
eth1:192.168.1.0/24
-
-
-
-
-
-
loc
-
-
eth1:192.168.20.0/24
-
-
-
-
-
-
+
+
+
ZONE
+
+
HOSTS
+
+
OPTIONS
+
+
+
+
loc
+
+
eth1:192.168.1.0/24
+
+
+
+
+
+
loc
+
+
eth1:192.168.20.0/24
+
+
+
+
+
+
-
-
- Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall
- 1.4.1 and later releases default to allowing intra-zone traffic.
-
+
+
+ Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall
+ 1.4.1 and later releases default to allowing intra-zone traffic.
+
If you are running Shorewall 1.4.0 or earlier
-
- In /etc/shorewall/interfaces:
-
-
-
-
-
-
-
ZONE
-
-
INTERFACE
-
-
BROADCAST
-
-
OPTIONS
-
-
-
-
loc
-
-
eth1
-
-
192.168.1.255,192.168.20.255
-
-
Note 1:
-
-
-
-
-
+
+ In /etc/shorewall/interfaces:
-
- Note 1: If you are running Shorewall 1.3.10 or earlier then you must
- specify the multi option.
-
- In /etc/shorewall/policy:
-
-
-
+
+
-
-
-
SOURCE
-
-
DESTINATION
-
-
POLICY
-
-
LOG LEVEL
-
-
BURST:LIMIT
-
-
-
-
loc
-
-
loc
-
-
ACCEPT
-
-
-
-
-
-
-
-
+
+
+
ZONE
+
+
INTERFACE
+
+
BROADCAST
+
+
OPTIONS
+
+
+
+
loc
+
+
eth1
+
+
192.168.1.255,192.168.20.255
+
+
Note 1:
+
+
+
+
+
+
+ Note 1: If you are running Shorewall 1.3.10 or earlier then you
+must specify the multi option.
-
- Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and
-192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
+ In /etc/shorewall/policy:
+
+
+
+
+
+
+
SOURCE
+
+
DESTINATION
+
+
POLICY
+
+
LOG LEVEL
+
+
BURST:LIMIT
+
+
+
+
loc
+
+
loc
+
+
ACCEPT
+
+
+
+
+
+
+
+
+
+
+
+ Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and
+ 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
eth1:0 is 192.168.20.254. You want to make these subnetworks into separate
zones and control the access between them (the users of the systems do
not have administrative privileges).
-
- In /etc/shorewall/zones:
-
-
-
-
-
-
-
ZONE
-
-
DISPLAY
-
-
DESCRIPTION
-
-
-
-
loc
-
-
Local
-
-
Local Zone 1
-
-
-
-
loc2
-
-
Local2
-
-
Local Zone 2
-
-
-
-
-
-
- In /etc/shorewall/interfaces:
-
-
-
+ In /etc/shorewall/zones:
+
+
+
-
-
-
ZONE
-
-
INTERFACE
-
-
BROADCAST
-
-
OPTIONS
-
-
-
-
-
-
-
eth1
-
-
192.168.1.255,192.168.20.255
-
-
Note 1:
-
-
-
-
+
+
+
ZONE
+
+
DISPLAY
+
+
DESCRIPTION
+
+
+
+
loc
+
+
Local
+
+
Local Zone 1
+
+
+
+
loc2
+
+
Local2
+
+
Local Zone 2
+
+
+
+
-
-
- Note 1: If you are running Shorewall 1.3.10 or earlier then you must
- specify the multi option.
-
- In /etc/shorewall/hosts:
-
-
+
+
+ In /etc/shorewall/interfaces:
+
+
+
-
-
-
ZONE
-
-
HOSTS
-
-
OPTIONS
-
-
-
-
loc
-
-
eth1:192.168.1.0/24
-
-
-
-
-
-
loc2
-
-
eth1:192.168.20.0/24
-
-
-
-
-
-
+
+
+
ZONE
+
+
INTERFACE
+
+
BROADCAST
+
+
OPTIONS
+
+
+
+
-
+
+
eth1
+
+
192.168.1.255,192.168.20.255
+
+
Note 1:
+
+
+
+
-
-
- In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
- that you want to permit.
-
-
-
Shorewall supports two different forms of blacklisting; static and dynamic.
-
+
Static Blacklisting
-
-
Shorewall static blacklisting support has the following configuration parameters:
-
+
+
Shorewall static blacklisting support has the following configuration
+parameters:
+
-
You specify whether you want packets from blacklisted hosts dropped
- or rejected using the BLACKLIST_DISPOSITION
- setting in /etc/shorewall/shorewall.conf
-
You specify whether you want packets from blacklisted hosts logged
- and at what syslog level using the BLACKLIST_LOGLEVEL setting in
- /etc/shorewall/shorewall.conf
-
You list the IP addresses/subnets that you wish to blacklist in
- /etc/shorewall/blacklist. Beginning
- with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service
- names in the blacklist file.
-
You specify whether you want packets from blacklisted hosts logged
+ and at what syslog level using the BLACKLIST_LOGLEVEL setting in
+ /etc/shorewall/shorewall.conf
+
You list the IP addresses/subnets that you wish to blacklist in
+ /etc/shorewall/blacklist.
+Beginning with Shorewall version 1.3.8, you may also specify PROTOCOL and
+Port numbers/Service names in the blacklist file.
+
+
You specify the interfaces whose incoming packets you want checked
+ against the blacklist using the "blacklist" option in /etc/shorewall/interfaces.
-
The black list is refreshed from /etc/shorewall/blacklist by the
-"shorewall refresh" command.
-
+
The black list is refreshed from /etc/shorewall/blacklist by the
+ "shorewall refresh" command.
+
-
+
Dynamic Blacklisting
-
-
Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting
- doesn't use any configuration parameters but is rather controlled using
- /sbin/shorewall commands:
-
+
+
Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting
+ doesn't use any configuration parameters but is rather controlled using
+ /sbin/shorewall commands:
+
-
drop <ip address list> - causes packets from the listed
- IP addresses to be silently dropped by the firewall.
-
reject <ip address list> - causes packets from the
-listed IP addresses to be rejected by the firewall.
-
allow <ip address list> - re-enables receipt of packets
- from hosts previously blacklisted by a deny or reject command.
-
save - save the dynamic blacklisting configuration so that it will
- be automatically restored the next time that the firewall is restarted.
-
show dynamic - displays the dynamic blacklisting configuration.
-
+
drop <ip address list> - causes packets from the
+listed IP addresses to be silently dropped by the firewall.
+
reject <ip address list> - causes packets from the
+ listed IP addresses to be rejected by the firewall.
+
allow <ip address list> - re-enables receipt of packets
+ from hosts previously blacklisted by a drop or reject
+command.
+
save - save the dynamic blacklisting configuration so that it
+will be automatically restored the next time that the firewall is restarted.
+
show dynamic - displays the dynamic blacklisting configuration.
+
- Dynamic blacklisting is not dependent on the "blacklist" option in
-/etc/shorewall/interfaces.
-
+ Dynamic blacklisting is not dependent on the "blacklist" option
+in /etc/shorewall/interfaces.
+
Example 1:
-
+
shorewall drop 192.0.2.124 192.0.2.125
-
+
Drops packets from hosts 192.0.2.124 and 192.0.2.125
The documentation in HTML format is included in the .rpm and in the
-.tgz packages below.
-
-
Once you've printed the appropriate QuickStart Guide, download
- one of the modules:
-
+
+
The documentation in HTML format is included in the .rpm and in the .tgz
+packages below.
+
+
Once you've printed the appropriate QuickStart Guide, download
+ one of the modules:
+
-
If you run a RedHat, SuSE, Mandrake,
- Linux PPC or TurboLinux distribution
- with a 2.4 kernel, you can use the RPM version (note: the
- RPM should also work with other distributions that store
- init scripts in /etc/init.d and that include chkconfig
-or insserv). If you find that it works in other cases, let me know so that
- I can mention them here. See the Installation
+
The documentation in HTML format is included in the .tgz and .rpm files
- and there is an documentation .deb that also contains the documentation. The
- .rpm will install the documentation in your default document directory
+
+
The documentation in HTML format is included in the .tgz and .rpm files
+ and there is an documentation .deb that also contains the documentation. The
+ .rpm will install the documentation in your default document directory
which can be obtained using the following command:
-
-
-
+
+
+
rpm --eval '%{defaultdocdir}'
-
-
-
Please check the errata
- to see if there are updates that apply to the version
- that you have downloaded.
-
-
WARNING - YOU CAN NOT SIMPLY INSTALL
- THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
- IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed
-configuration of your firewall, you can enable startup by removing
-the file /etc/shorewall/startup_disabled.
-
+
+
+
Please check the errata
+ to see if there are updates that apply to the version
+ that you have downloaded.
+
+
WARNING - YOU CAN NOT SIMPLY INSTALL
+ THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
+ IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
+ of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.
The CVS repository
- at cvs.shorewall.net contains the latest snapshots of the
-each Shorewall component. There's no guarantee that what you
-find there will work at all.
-
-
-
+ href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository
+ at cvs.shorewall.net contains the latest snapshots of the
+each Shorewall component. There's no guarantee that what you find
+there will work at all.
+
+
+
Shapshots:
-
-
-
+
+
+
Periodic snapshots from CVS may be found at http://shorewall.net/pub/shorewall/Snapshots
- (FTP).
- These snapshots have undergone initial testing and will have been installed
- and run at shorewall.net.
-
If you are installing Shorewall for the
-first time and plan to use the .tgz and install.sh script, you can
-untar the archive, replace the 'firewall' script in the untarred directory
- with the one you downloaded below, and then run install.sh.
-
-
-
-
When the instructions say to install a corrected
- firewall script in /usr/share/shorewall/firewall, you
- may rename the existing file before copying in the new file.
-
-
-
-
DO NOT INSTALL CORRECTED COMPONENTS
- ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
- For example, do NOT install the 1.3.9a firewall script if you are
- running 1.3.7c.
-
-
-
+ style="text-decoration: none;"> dos2unix after you have moved
+ it to your Linux system.
+
+
+
+
If you are installing Shorewall for the first
+time and plan to use the .tgz and install.sh script, you can untar
+the archive, replace the 'firewall' script in the untarred directory
+ with the one you downloaded below, and then run install.sh.
+
+
+
+
When the instructions say to install a corrected
+ firewall script in /usr/share/shorewall/firewall,
+you may rename the existing file before copying in the new file.
+
+
+
+
DO NOT INSTALL CORRECTED COMPONENTS
+ ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER
+ BELOW. For example, do NOT install the 1.3.9a firewall script
+if you are running 1.3.7c.
+
This problem occurs in all versions supporting traffic control. If
+a MAC address is used in the SOURCE column, an error occurs as follows:
+
+ iptables v1.2.8: Bad mac adress `00:08:B5:35:52:E7-d`
+
+ For Shorewall 1.4.6 and 1.4.6a users, this problem has been corrected in
+ this
+firewall script which may be installed in /var/share/shorewall/firewall
+as described above. For all other versions, you will have to edit your 'firewall'
+script (in versions 1.4.*, it is located in /usr/share/shorewall/firewall).
+Locate the function add_tcrule_() and in that function, replace this line:
+
+ r=`mac_match $source`
+
+ with
+
+ r="`mac_match $source` "
+
+ Note that there must be a space before the ending quote!
+
+
+
+
+
1.4.4b
+
+
+
Shorewall is ignoring records in /etc/shorewall/routestopped
+that have an empty second column (HOSTS). This problem may be corrected
+by installing this firewall script in /usr/share/shorewall/firewall
-as described above.
-
The INCLUDE directive doesn't work when placed in the /etc/shorewall/zones
-file. This problem may be corrected by installing this firewall script in /usr/share/shorewall/firewall as
+described above.
+
The INCLUDE directive doesn't work when placed in the /etc/shorewall/zones
+ file. This problem may be corrected by installing this functions script in /usr/share/shorewall/functions.
-
-
-
-
-
1.4.4-1.4.4a
-
-
-
Log messages are being displayed on the system console even though
- the log level for the console is set properly according to FAQ 16. This problem may be corrected by installing
- this firewall script in /usr/share/shorewall/firewall
-as described above.
-
+
-
+
+
1.4.4-1.4.4a
+
+
+
Log messages are being displayed on the system console even
+though the log level for the console is set properly according to FAQ 16. This problem may be corrected by installing
+ this firewall script in /usr/share/shorewall/firewall as
+described above.
+
+
+
+
1.4.4
-
-
+
+
-
If you have zone names that are 5 characters long, you may experience
- problems starting Shorewall because the --log-prefix in a logging rule is
- too long. Upgrade to Version 1.4.4a to fix this problem..
-
+
If you have zone names that are 5 characters long, you may
+experience problems starting Shorewall because the --log-prefix in a logging
+rule is too long. Upgrade to Version 1.4.4a to fix this problem..
+
-
+
1.4.3
-
-
-
The LOGMARKER variable introduced in version 1.4.3 was intended
- to allow integration of Shorewall with Fireparse (http://www.firewparse.com).
- Unfortunately, LOGMARKER only solved part of the integration problem.
-I have implimented a new LOGFORMAT variable which will replace LOGMARKER
-which has completely solved this problem and is currently in production
-with fireparse here at shorewall.net. The updated files may be found at
- ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/.
- See the 0README.txt file for details.
-
-
-
-
-
1.4.2
-
-
-
When an 'add' or 'delete' command is executed, a temporary
-directory created in /tmp is not being removed. This problem may be corrected
-by installing this firewall script in /usr/share/shorewall/firewall
-as described above.
-
-
-
-
-
1.4.1a, 1.4.1 and 1.4.0
-
Some TCP requests are rejected in the 'common' chain with
-an ICMP port-unreachable response rather than the more appropriate TCP
-RST response. This problem is corrected in this updated common.def file which may be installed in
- /etc/shorewall/common.def.
+
The LOGMARKER variable introduced in version 1.4.3 was intended
+ to allow integration of Shorewall with Fireparse (http://www.firewparse.com).
+ Unfortunately, LOGMARKER only solved part of the integration problem.
+I have implimented a new LOGFORMAT variable which will replace LOGMARKER
+which has completely solved this problem and is currently in production
+with fireparse here at shorewall.net. The updated files may be found at
+ ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/.
+ See the 0README.txt file for details.
-
1.4.1
-
-
-
When a "shorewall check" command is executed, each "rule"
-produces the harmless additional message:
-
- /usr/share/shorewall/firewall: line 2174: [: =: unary operator
- expected
-
- You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall
- as described above.
-
-
-
-
-
1.4.0
+
1.4.2
-
When running under certain shells Shorewall will attempt
-to create ECN rules even when /etc/shorewall/ecn is empty. You may either
- just remove /etc/shorewall/ecn or you can install this
- correct script in /usr/share/shorewall/firewall as described above.
+
When an 'add' or 'delete' command is executed, a temporary
+ directory created in /tmp is not being removed. This problem may be corrected
+ by installing this firewall script in /usr/share/shorewall/firewall as
+described above.
There are a couple of serious bugs in iptables 1.2.3 that
- prevent it from working with Shorewall. Regrettably,
- RedHat released this buggy iptables in RedHat 7.2.
Update 11/9/2001: RedHat
- has released an iptables-1.2.4 RPM of their own which you
- can download from http://www.redhat.com/support/errata/RHSA-2001-144.html.
- I have installed this RPM on my firewall and it
- works fine.
-
-
If you would like to patch iptables 1.2.3 yourself,
- the patches are available for download. This patch
- which corrects a problem with parsing of the --log-level
- specification while this patch
- corrects a problem in handling the TOS target.
-
-
To install one of the above patches:
-
-
-
cd iptables-1.2.3/extensions
-
patch -p0 < the-patch-file
-
-
-
-
-
Problems with kernels >= 2.4.18
-and RedHat iptables
-
-
-
Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
- may experience the following:
The RedHat iptables RPM is compiled with debugging enabled but the
- user-space debugging code was not updated to reflect recent changes in
- the Netfilter 'mangle' table. You can correct the problem by
- installing
- this iptables RPM. If you are already running a 1.2.5
- version of iptables, you will need to specify the --oldpackage
- option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").
-
-
-
Problems installing/upgrading
- RPM on SuSE
-
-
If you find that rpm complains about a conflict with kernel <=
- 2.2 yet you have a 2.4 kernel installed, simply use the
- "--nodeps" option to rpm.
-
-
Installing: rpm -ivh --nodeps <shorewall rpm>
-
-
Upgrading: rpm -Uvh --nodeps <shorewall rpm>
-
-
Problems with iptables version 1.2.7 and
- MULTIPORT=Yes
-
-
The iptables 1.2.7 release of iptables has made an incompatible
- change to the syntax used to specify multiport match rules;
- as a consequence, if you install iptables 1.2.7 you
-must be running Shorewall 1.3.7a or later or:
+
1.4.1a, 1.4.1 and 1.4.0
-
set
-MULTIPORT=No in /etc/shorewall/shorewall.conf;
-or
-
if you
- are running Shorewall 1.3.6 you may
- install
- this firewall script in /var/lib/shorewall/firewall
- as described above.
-
+
Some TCP requests are rejected in the 'common' chain with
+ an ICMP port-unreachable response rather than the more appropriate TCP
+ RST response. This problem is corrected in this updated common.def file which may be installed in
+ /etc/shorewall/common.def.
+
+
-
+
+
1.4.1
+
+
+
When a "shorewall check" command is executed, each "rule"
+ produces the harmless additional message:
+
+ /usr/share/shorewall/firewall: line 2174: [: =: unary operator
+ expected
+
+ You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall
+ as described above.
+
+
+
+
+
1.4.0
+
+
+
When running under certain shells Shorewall will attempt
+ to create ECN rules even when /etc/shorewall/ecn is empty. You may
+either just remove /etc/shorewall/ecn or you can install this
+ correct script in /usr/share/shorewall/firewall as described above.
+
There are a couple of serious bugs in iptables 1.2.3 that
+ prevent it from working with Shorewall. Regrettably,
+ RedHat released this buggy iptables in RedHat 7.2.
Update 11/9/2001: RedHat
+ has released an iptables-1.2.4 RPM of their own which
+you can download from http://www.redhat.com/support/errata/RHSA-2001-144.html.
+ I have installed this RPM on my firewall and
+it works fine.
+
+
If you would like to patch iptables 1.2.3 yourself,
+ the patches are available for download. This patch
+ which corrects a problem with parsing of the --log-level
+ specification while this patch
+ corrects a problem in handling the TOS target.
+
+
To install one of the above patches:
+
+
+
cd iptables-1.2.3/extensions
+
patch -p0 < the-patch-file
+
+
+
+
+
Problems with kernels >= 2.4.18 and
+RedHat iptables
+
+
+
Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
+ may experience the following:
The RedHat iptables RPM is compiled with debugging enabled but the
+ user-space debugging code was not updated to reflect recent changes in
+ the Netfilter 'mangle' table. You can correct the problem by
+ installing
+ this iptables RPM. If you are already running a
+1.2.5 version of iptables, you will need to specify the
+--oldpackage option to rpm (e.g., "iptables -Uvh --oldpackage
+iptables-1.2.5-1.i386.rpm").
+
+
+
Problems installing/upgrading
+ RPM on SuSE
+
+
If you find that rpm complains about a conflict with kernel <=
+ 2.2 yet you have a 2.4 kernel installed, simply use the
+ "--nodeps" option to rpm.
+
+
Installing: rpm -ivh --nodeps <shorewall rpm>
+
+
Upgrading: rpm -Uvh --nodeps <shorewall rpm>
+
+
Problems with iptables version 1.2.7 and
+ MULTIPORT=Yes
+
+
The iptables 1.2.7 release of iptables has made an incompatible
+ change to the syntax used to specify multiport match rules;
+ as a consequence, if you install iptables 1.2.7 you
+ must be running Shorewall 1.3.7a or later or:
+
+
+
set
+ MULTIPORT=No in /etc/shorewall/shorewall.conf;
+ or
+
if
+ you are running Shorewall 1.3.6 you may
+ install
+ this firewall script in /var/lib/shorewall/firewall
+ as described above.
+
+
+
Problems with RH Kernel 2.4.18-10 and NAT
-
- /etc/shorewall/nat entries of the following form
- will result in Shorewall being unable to start:
-
-
+
+ /etc/shorewall/nat entries of the following
+ form will result in Shorewall being unable to start:
+
+
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.22 eth0 192.168.9.22 yes yes #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
- Error message is:
-
+ Error message is:
+
Setting up NAT... iptables: Invalid argument Terminated
- The solution is to put "no" in the LOCAL column.
- Kernel support for LOCAL=yes has never worked properly and 2.4.18-10
- has disabled it. The 2.4.19 kernel contains corrected support under
- a new kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
-
-
-
Problems with RH Kernels after 2.4.20-9 and
-REJECT (also applies to 2.4.21-RC1)
- Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset"
- is broken. The symptom most commonly seen is that REJECT rules act just
-like DROP rules when dealing with TCP. A kernel patch and precompiled modules
-to fix this problem are available at
+
+
Problems with RH Kernels after 2.4.20-9 and REJECT
+(also applies to 2.4.21-RC1)
+ Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset"
+ is broken. The symptom most commonly seen is that REJECT rules act just
+like DROP rules when dealing with TCP. A kernel patch and precompiled modules
+ to fix this problem are available at ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel.
-
-
-
Here's a screen shot of my Network Options Configuration:
-
-
+
+
-
-
-
-
While not all of the options that I've selected are required, they should
-be sufficient for most applications. Here's an excerpt from the corresponding
-.config file (Note: If you are running a kernel older than 2.4.17, be sure
-to select CONFIG_NETLINK and CONFIG_RTNETLINK):
-
-
-
#
- # Networking options
- #
- CONFIG_PACKET=y
- # CONFIG_PACKET_MMAP is not set
- # CONFIG_NETLINK_DEV is not set
- CONFIG_NETFILTER=y
- CONFIG_NETFILTER_DEBUG=y
- CONFIG_FILTER=y
- CONFIG_UNIX=y
- CONFIG_INET=y
- CONFIG_IP_MULTICAST=y
- CONFIG_IP_ADVANCED_ROUTER=y
- CONFIG_IP_MULTIPLE_TABLES=y
- CONFIG_IP_ROUTE_FWMARK=y
- CONFIG_IP_ROUTE_NAT=y
- CONFIG_IP_ROUTE_MULTIPATH=y
- CONFIG_IP_ROUTE_TOS=y
- CONFIG_IP_ROUTE_VERBOSE=y
- # CONFIG_IP_ROUTE_LARGE_TABLES is not set
- # CONFIG_IP_PNP is not set
- CONFIG_NET_IPIP=m
- CONFIG_NET_IPGRE=m
- # CONFIG_NET_IPGRE_GROADCAST is not set
- # CONFIG_IP_MROUTE is not set
- # CONFIG_ARPD is not set
- CONFIG_INET_ECN=y
- CONFIG_SYN_COOKIES=y
-
-
-
Here's a screen shot of my Netfilter configuration:
-
-
-
-
-
-
-
Here's an excerpt from the corresponding .config file.
-
-
-
#
- # IP: Netfilter Configuration
- #
- CONFIG_IP_NF_CONNTRACK=y
- CONFIG_IP_NF_FTP=m
- # CONFIG_IP_NF_QUEUE is not set
- CONFIG_IP_NF_IPTABLES=y
- CONFIG_IP_NF_MATCH_LIMIT=y
- CONFIG_IP_NF_MATCH_MAC=y
- CONFIG_IP_NF_MATCH_MARK=y
- CONFIG_IP_NF_MATCH_MULTIPORT=y
- CONFIG_IP_NF_MATCH_TOS=y
- # CONFIG_IP_NF_MATCH_TCPMSS is not set
- CONFIG_IP_NF_MATCH_STATE=y
- # CONFIG_IP_NF_MATCH_UNCLEAN is not set
- # CONFIG_IP_NF_MATCH_OWNER is not set
- CONFIG_IP_NF_FILTER=y
- CONFIG_IP_NF_TARGET_REJECT=y
- # CONFIG_IP_NF_TARGET_MIRROR is not set
- CONFIG_IP_NF_NAT=y
- CONFIG_IP_NF_NAT_NEEDED=y
- CONFIG_IP_NF_TARGET_MASQUERADE=y
- CONFIG_IP_NF_TARGET_REDIRECT=y
- CONFIG_IP_NF_NAT_FTP=m
- CONFIG_IP_NF_MANGLE=y
- CONFIG_IP_NF_TARGET_TOS=y
- CONFIG_IP_NF_TARGET_MARK=y
- CONFIG_IP_NF_TARGET_LOG=y
- CONFIG_IP_NF_TARGET_TCPMSS=y
- # CONFIG_IPV6 is not set
-
-
-
-
Note that I have built everything I need into the kernel except for the
-FTP connection tracking and NAT modules. I have also run successfully with
-all of the options selected above built as modules:
-
-
-
-
-
-
#
- # IP: Netfilter Configuration
- #
- CONFIG_IP_NF_CONNTRACK=m
- CONFIG_IP_NF_FTP=m
- # CONFIG_IP_NF_QUEUE is not set
- CONFIG_IP_NF_IPTABLES=m
- CONFIG_IP_NF_MATCH_LIMIT=m
- CONFIG_IP_NF_MATCH_MAC=m
- CONFIG_IP_NF_MATCH_MARK=m
- CONFIG_IP_NF_MATCH_MULTIPORT=m
- CONFIG_IP_NF_MATCH_TOS=m
- # CONFIG_IP_NF_MATCH_TCPMSS is not set
- CONFIG_IP_NF_MATCH_STATE=m
- # CONFIG_IP_NF_MATCH_UNCLEAN is not set
- # CONFIG_IP_NF_MATCH_OWNER is not set
- CONFIG_IP_NF_FILTER=m
- CONFIG_IP_NF_TARGET_REJECT=m
- # CONFIG_IP_NF_TARGET_MIRROR is not set
- CONFIG_IP_NF_NAT=m
- CONFIG_IP_NF_NAT_NEEDED=m
- CONFIG_IP_NF_TARGET_MASQUERADE=m
- CONFIG_IP_NF_TARGET_REDIRECT=m
- CONFIG_IP_NF_NAT_FTP=m
- CONFIG_IP_NF_MANGLE=m
- CONFIG_IP_NF_TARGET_TOS=m
- CONFIG_IP_NF_TARGET_MARK=m
- CONFIG_IP_NF_TARGET_LOG=m
- CONFIG_IP_NF_TARGET_TCPMSS=m
- # CONFIG_IPV6 is not set
-
#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+# CONFIG_NETLINK_DEV is not set
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_DEBUG is not set
+CONFIG_FILTER=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_FWMARK=y
+CONFIG_IP_ROUTE_NAT=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_TOS=y
+CONFIG_IP_ROUTE_VERBOSE=y
+# CONFIG_IP_ROUTE_LARGE_TABLES is not set
+# CONFIG_IP_PNP is not set
+CONFIG_NET_IPIP=y
+CONFIG_NET_IPGRE=y
+# CONFIG_NET_IPGRE_BROADCAST is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+CONFIG_INET_ECN=y
+CONFIG_SYN_COOKIES=y
+
+
+
+
Here's a screen shot of my Netfilter configuration:
+
+
+
+
+
+
+
+
Note that I have built everything I need as modules. You can also build
+everything into your kernel but if you want to be able to deal with FTP running
+on a non-standard port then I recommend that you modularize FTP Protocol
+support.
+
+
Here's the corresponding part of my .config file:
+
+
+
+
# # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_TFTP=m # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m # CONFIG_IP_NF_MATCH_TTL is not set CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_UNCLEAN=m # CONFIG_IP_NF_MATCH_OWNER is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m # CONFIG_IP_NF_TARGET_MIRROR is not set CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_NAT_LOCAL=y # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set
to ensure that the sender address is fully
- qualified.
-
to verify that the sender's domain has
-an A or MX record in DNS.
-
to ensure that the host name in the HELO/EHLO
- command is a valid fully-qualified DNS name that resolves.
-
+
+
to ensure that the sender address is
+fully qualified.
+
to verify that the sender's domain has
+ an A or MX record in DNS.
+
to ensure that the host name in the HELO/EHLO
+ command is a valid fully-qualified DNS name.
+
-
+
Please post in plain text
- A growing number of MTAs serving list subscribers are
- rejecting all HTML traffic. At least one MTA has gone so far as to
- blacklist shorewall.net "for continuous abuse" because it has been
-my policy to allow HTML in list posts!!
-
- I think that blocking all HTML is a Draconian way to
- control spam and that the ultimate losers here are not the spammers
- but the list subscribers whose MTAs are bouncing all shorewall.net
- mail. As one list subscriber wrote to me privately "These e-mail admin's
- need to get a (explitive deleted) life instead of trying to rid
- the planet of HTML based e-mail". Nevertheless, to allow subscribers
-to receive list posts as must as possible, I have now configured the
-list server at shorewall.net to strip all HTML from outgoing posts.
+ A growing number of MTAs serving list subscribers
+are rejecting all HTML traffic. At least one MTA has gone so far
+as to blacklist shorewall.net "for continuous abuse" because it has
+been my policy to allow HTML in list posts!!
+
+ I think that blocking all HTML is a Draconian way
+to control spam and that the ultimate losers here are not the spammers
+ but the list subscribers whose MTAs are bouncing all shorewall.net
+ mail. As one list subscriber wrote to me privately "These e-mail admin's
+ need to get a (explitive deleted) life instead of trying to
+rid the planet of HTML based e-mail". Nevertheless, to allow subscribers
+ to receive list posts as must as possible, I have now configured the
+ list server at shorewall.net to strip all HTML from outgoing posts.
This means that HTML-only posts will be bounced by the list server.
-
+
Note: The list server limits posts to 120kb.
-
-
+
+
Other Mail Delivery Problems
- If you find that you are missing an occasional list post,
- your e-mail admin may be blocking mail whose Received: headers
- contain the names of certain ISPs. Again, I believe that such policies
- hurt more than they help but I'm not prepared to go so far as to start
- stripping Received: headers to circumvent those policies.
-
+ If you find that you are missing an occasional list
+post, your e-mail admin may be blocking mail whose Received:
+headers contain the names of certain ISPs. Again, I believe that such
+policies hurt more than they help but I'm not prepared to go so far
+as to start stripping Received: headers to circumvent those
+policies.
+
Mailing Lists Archive Search
-
+
-
+
+
Please do not try to download the entire
Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you will be blacklisted.
-
-
+
+
Shorewall CA Certificate
- If you want to trust X.509 certificates issued
- by Shoreline Firewall (such as the one used on my web site),
-you may download and install my CA certificate
- in your browser. If you don't wish to trust my certificates
- then you can either use unencrypted access when subscribing to
-Shorewall mailing lists or you can use secure access (SSL) and
+ If you want to trust X.509 certificates issued
+ by Shoreline Firewall (such as the one used on my web site),
+ you may download and install my CA certificate
+ in your browser. If you don't wish to trust my certificates
+ then you can either use unencrypted access when subscribing to
+ Shorewall mailing lists or you can use secure access (SSL) and
accept the server's certificate when prompted by your browser.
-
+
Shorewall Users Mailing List
-
+
The Shorewall Users Mailing list provides a way for users
- to get answers to questions and to report problems. Information
- of general interest to the Shorewall user community is also
-posted to this list.
-
+ to get answers to questions and to report problems. Information
+ of general interest to the Shorewall user community is also
+ posted to this list.
+
+
To post a problem report to this list or to subscribe to
+the list, please see the problem reporting guidelines.
The Shorewall Development Mailing list provides a forum for
- the exchange of ideas about the future of Shorewall and for
- coordinating ongoing Shorewall Development.
-
+ the exchange of ideas about the future of Shorewall and
+for coordinating ongoing Shorewall Development.
+
How to Unsubscribe from one of
- the Mailing Lists
-
+ the Mailing Lists
+
There seems to be near-universal confusion about unsubscribing
- from Mailman-managed lists although Mailman 2.1 has attempted
- to make this less confusing. To unsubscribe:
-
+ from Mailman-managed lists although Mailman 2.1 has attempted
+ to make this less confusing. To unsubscribe:
+
-
-
+
+
Follow the same link above that you used to subscribe
- to the list.
-
-
-
+ to the list.
+
+
+
Down at the bottom of that page is the following text:
- " To unsubscribe from <list name>, get
- a password reminder, or change your subscription options
+ " To unsubscribe from <list name>,
+get a password reminder, or change your subscription options
enter your subscription email address:". Enter your email
address in the box and click on the "Unsubscribe or edit
options" button.
-
-
-
+
+
+
There will now be a box where you can enter your password
- and click on "Unsubscribe"; if you have forgotten your password,
- there is another button that will cause your password to be
- emailed to you.
-
-
+ and click on "Unsubscribe"; if you have forgotten your
+password, there is another button that will cause your password
+to be emailed to you.
+
+
-
-
+
+
Frustrated by having to Rebuild Mailman to use it with Postfix?
Warning 1: I
- use a combination of Static NAT and Proxy ARP, neither of which are
- relevant to a simple configuration with a single public IP address.
- If you have just a single public IP address, most of what you see here
- won't apply to your setup so beware of copying parts of this configuration
- and expecting them to work for you. What you copy may or may not work
- in your configuration.
-
-
+ use a combination of Static NAT and Proxy ARP, neither of which are
+ relevant to a simple configuration with a single public IP address.
+ If you have just a single public IP address, most of what you see
+here won't apply to your setup so beware of copying parts of this configuration
+ and expecting them to work for you. What you copy may or may not work
+ in your configuration.
+
+
Warning 2: The
-configuration shown here corresponds to Snapshot 1.4.5_20030629 plus a couple
-of patches.
-
-
+ configuration shown here corresponds to version 1.4.6.
+
+
I have DSL service and have 5 static IP addresses (206.124.146.176-180).
- My DSL "modem" (Fujitsu
-Speedport) is connected to eth0. I have a local network connected
-to eth2 (subnet 192.168.1.0/24), a DMZ connected to eth1 (192.168.2.0/24)
-and a Wireless network connected to eth3 (192.168.3.0/24).
-
+ My DSL "modem" (Fujitsu
+ Speedport) is connected to eth0. I have a local network connected
+ to eth2 (subnet 192.168.1.0/24), a DMZ connected to eth1 (192.168.2.0/24)
+ and a Wireless network connected to eth3 (192.168.3.0/24).
+
I use:
-
-
+
+
-
Static NAT for Ursa (my XP System) - Internal
- address 192.168.1.5 and external address 206.124.146.178.
-
Static NAT for Wookie (my Linux System). Internal
- address 192.168.1.3 and external address 206.124.146.179.
-
Static NAT for EastepLaptop (My work system). Internal address
- 192.168.1.7 and external address 206.124.146.180.
-
-
SNAT through the primary gateway address (206.124.146.176)
- for my Wife's system (Tarry) and our laptop (Tipper) which connects
- through the Wireless Access Point (wap) via a Wireless Bridge (bridge).
-
-
- Note: While the distance between the WAP and where I usually
-use the laptop isn't very far (25 feet or so), using a WAC11 (CardBus
-wireless card) has proved very unsatisfactory (lots of lost connections).
-By replacing the WAC11 with the WET11 wireless bridge, I have virtually
-eliminated these problems (Being an old radio tinkerer (K7JPV), I was also
-able to eliminate the disconnects by hanging a piece of aluminum foil on
-the family room wall. Needless to say, my wife Tarry rejected that as a
-permanent solution :-).
-
+
Static NAT for Ursa (my XP System) - Internal
+ address 192.168.1.5 and external address 206.124.146.178.
+
Static NAT for Wookie (my Linux System).
+Internal address 192.168.1.3 and external address 206.124.146.179.
+
Static NAT for EastepLaptop (My work system). Internal address
+ 192.168.1.7 and external address 206.124.146.180.
+
+
SNAT through the primary gateway address
+(206.124.146.176) for my Wife's system (Tarry) and our laptop
+(Tipper) which connects through the Wireless Access Point (wap) via
+a Wireless Bridge (bridge).
+
+ Note: While the distance between the WAP and where I usually
+ use the laptop isn't very far (25 feet or so), using a WAC11 (CardBus
+ wireless card) has proved very unsatisfactory (lots of lost connections).
+ By replacing the WAC11 with the WET11 wireless bridge, I have virtually
+ eliminated these problems (Being an old radio tinkerer (K7JPV), I was
+also able to eliminate the disconnects by hanging a piece of aluminum foil
+on the family room wall. Needless to say, my wife Tarry rejected that as
+a permanent solution :-).
+
-
+
The firewall runs on a 256MB PII/233 with RH9.0.
-
+
Wookie and the Firewall both run Samba and the Firewall acts as a WINS
server.
-
-
+
+
Wookie is in its own 'whitelist' zone called 'me' which is embedded
in the local zone.
-
+
The wireless network connects to eth3 via a LinkSys WAP11. In additional
- to using the rather weak WEP 40-bit encryption (64-bit with the 24-bit
-prefix), I use MAC verification. This
-is still a weak combination and if I lived near a wireless "hot spot", I
-would probably add IPSEC or something similar to my WiFi->local connections.
-
-
+ to using the rather weak WEP 40-bit encryption (64-bit with the 24-bit
+ preamble), I use MAC verification. This
+ is still a weak combination and if I lived near a wireless "hot spot", I
+ would probably add IPSEC or something similar to my WiFi->local connections.
+
+
The single system in the DMZ (address 206.124.146.177) runs postfix,
- Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an
- FTP server (Pure-ftpd). The system also runs fetchmail to fetch
-our email from our old and current ISPs. That server is managed through
- Proxy ARP.
-
+ Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and
+an FTP server (Pure-ftpd). The system also runs fetchmail to fetch
+ our email from our old and current ISPs. That server is managed through
+ Proxy ARP.
+
The firewall system itself runs a DHCP server that serves the local
- network. It also runs Postfix which is configured as a Virus and
- Spam filter with all incoming mail then being forwarded to the MTA in
-the DMZ.
-
+ network. It also runs Postfix which is configured as a Virus
+and Spam filter with all incoming mail then being forwarded to the MTA
+in the DMZ.
+
All administration and publishing is done using ssh/scp. I have X installed
- on the firewall but no X server or desktop is installed. X applications
- tunnel through SSH to XWin.exe running on Ursa. The server does have a
+ on the firewall but no X server or desktop is installed. X applications
+ tunnel through SSH to XWin.exe running on Ursa. The server does have a
desktop environment installed and that desktop environment is available
via XDMCP from the local zone. For the most part though, X tunneled through
SSH is used for server administration and the server runs at run level 3
(multi-user console mode on RedHat).
-
+
I run an SNMP server on my firewall to serve MRTG running
- in the DMZ.
-
+ in the DMZ.
+
-
-
+
+
-
+
The ethernet interface in the Server is configured with IP address
- 206.124.146.177, netmask 255.255.255.0. The server's default gateway
- is 206.124.146.254 (Router at my ISP. This is the same
-default gateway used by the firewall itself). On the firewall,
- Shorewall automatically adds a host route to
- 206.124.146.177 through eth1 (192.168.2.1) because
+ 206.124.146.177, netmask 255.255.255.0. The server's default gateway
+ is 206.124.146.254 (Router at my ISP. This is the same
+ default gateway used by the firewall itself). On the firewall,
+ Shorewall automatically adds a host route to
+ 206.124.146.177 through eth1 (192.168.2.1) because
of the entry in /etc/shorewall/proxyarp (see
below).
-
+
Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior
- access.
-
MIRRORS=<list of shorewall mirror ip addresses> NTPSERVERS=<list of the NTP servers I sync with>
TEXAS=<ip address of gateway in Dallas> LOG=info
-
-
+
+
Zones File
-
-
+
+
#ZONE DISPLAY COMMENTS net Internet Internet WiFi Wireless Wireless Network on eth3 me Wookie My Linux Workstation dmz DMZ Demilitarized zone loc Local Local networks tx Texas Peer Network in Dallas #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
-
-
+
+
Interfaces File:
-
-
+
+
This is set up so that I can start the firewall before bringing up
my Ethernet interfaces.
-
-
-
+
+
+
#ZONE INERFACE BROADCAST OPTIONS net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags loc eth2 192.168.1.255 dhcp dmz eth1 192.168.2.255 WiFi eth3 192.168.3.255 dhcp,maclist - texas 192.168.9.255 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
-
-
+
+
Hosts File:
-
-
+
+
#ZONE HOST(S) OPTIONS me eth2:192.168.1.3 tx texas:192.168.8.0/22 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
-
-
+
+
Routestopped File:
-
-
+
+
#INTERFACQ HOST(S) eth1 206.124.146.177 eth2 - eth3 192.168.3.8 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
-
-
+
+
Policy File:
-
-
+
+
#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT me loc NONE me all ACCEPT tx me ACCEPT WiFi loc ACCEPT loc WiFi ACCEPT loc me NONE all me CONTINUE - 2/sec:5 loc net ACCEPT $FW loc ACCEPT $FW tx ACCEPT loc tx ACCEPT loc fw REJECT $LOG WiFi net ACCEPT net all DROP $LOG 10/sec:40 all all REJECT $LOG #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
-
-
+
+
Masq File:
-
-
+
+
Although most of our internal systems use static NAT, my wife's system
- (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors
- with laptops. Also, I masquerade systems connected through the wireless
- network.
-
-
-
+ (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors
+ with laptops. Also, I masquerade systems connected through the wireless
+ network.
+
+
+
#INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 eth3 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
+
+
NAT File:
-
-
+
+
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 206.124.146.178 eth0:0 192.168.1.5 No No 206.124.146.179 eth0:1 192.168.1.3 No No 206.124.146.180 eth0:2 192.168.1.7 No No 192.168.1.193 eth2:0 206.124.146.177 No No #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE\
-
-
+
+
Proxy ARP File:
-
-
+
+
#ADDRESS INTERFACE EXTERNAL HAVEROUTE 206.124.146.177 eth1 eth0 No #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):
-
-
+
+
#TYPE ZONE GATEWAY GATEWAY ZONE PORT gre net $TEXAS #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
-
+
+
-
+
Rules File (The shell variables are set in /etc/shorewall/params):
-
-
+
+
################################################################################################################################################################ #RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT ORIGINAL DEST:SNAT ################################################################################################################################################################ # Local Network to Internet - Reject attempts by Trojans to call home # REJECT:$LOG loc net tcp 6667 # # Stop NETBIOS crap since our policy is ACCEPT # REJECT loc net tcp 137,445 REJECT loc net udp 137:139 ################################################################################################################################################################ # Local Network to Firewall # DROP loc:!192.168.1.0/24 fw ACCEPT loc fw tcp ssh,time,10000,smtp,swat,137,139,445 ACCEPT loc fw udp snmp,ntp,445 ACCEPT loc fw udp 137:139 ACCEPT loc fw udp 1024: 137 ################################################################################################################################################################ # Local Network to DMZ # ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,pop3 - ################################################################################################################################################################ # Internet to DMZ # ACCEPT net dmz tcp www,ftp,imaps,domain,cvspserver,https - ACCEPT net dmz udp domain ACCEPT net:$MIRRORS dmz tcp rsync ACCEPT:$LOG net dmz tcp 32768:61000 20 DROP net dmz tcp 1433 ################################################################################################################################################################ # # Net to Local # # When I'm "on the road", the following two rules allow me VPN access back home. # ACCEPT net loc:192.168.1.5 tcp 1723 ACCEPT net loc:192.168.1.5 gre # # ICQ # ACCEPT net loc:192.168.1.5 tcp 4000:4100 # # Real Audio # ACCEPT net loc:192.168.1.5 udp 6790 ################################################################################################################################################################ # Net to me # ACCEPT net loc:192.168.1.3 tcp 4000:4100 ################################################################################################################################################################ # DMZ to Internet # ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh ACCEPT dmz net udp domain #ACCEPT dmz net:$POPSERVERS tcp pop3 #ACCEPT dmz net:206.191.151.2 tcp pop3 #ACCEPT dmz net:66.216.26.115 tcp pop3 # # Something is wrong with the FTP connection tracking code or there is some client out there # that is sending a PORT command which that code doesn't understand. Either way, # the following works around the problem. # ACCEPT:$LOG dmz net tcp 1024: 20 ################################################################################################################################################################ # DMZ to Firewall -- ntp & snmp, Silently reject Auth # ACCEPT dmz fw udp ntp ntp ACCEPT dmz fw tcp snmp,ssh ACCEPT dmz fw udp snmp REJECT dmz fw tcp auth ################################################################################################################################################################ # # DMZ to Local Network # ACCEPT dmz loc tcp smtp,6001:6010 ################################################################################################################################################################ # # DMZ to Me -- NFS # ACCEPT dmz me tcp 111 ACCEPT dmz me udp 111 ACCEPT dmz me udp 2049 ACCEPT dmz me udp 32700: ################################################################################################################################################################ # Internet to Firewall # REDIRECT- net 25 tcp smtp - 206.124.146.177 ACCEPT net fw tcp smtp REJECT net fw tcp www DROP net fw tcp 1433 ################################################################################################################################################################ # WiFi to Firewall (SMB and NTP) # ACCEPT WiFi fw tcp ssh,137,139,445 ACCEPT WiFi fw udp 137:139,445 ACCEPT WiFi fw udp 1024: 137 ACCEPT WiFi fw udp ntp ntp ################################################################################################################################################################ # Firewall to WiFi (SMB) # ACCEPT fw WiFi tcp 137,139,445 ACCEPT fw WiFi udp 137:139,445 ACCEPT fw WiFi udp 1024: 137 ############################################################################################################################################################### # WiFi to DMZ # DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193 ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh - ACCEPT WiFi dmz udp domain ################################################################################################################################################################ # Firewall to Internet # ACCEPT fw net:$NTPSERVERS udp ntp ntp ACCEPT fw net:$POPSERVERS tcp pop3 ACCEPT fw net udp domain ACCEPT fw net tcp domain,www,https,ssh,1723,whois,1863,smtp,ftp,2702,2703,7 ACCEPT fw net udp 33435:33535 ACCEPT fw net icmp 8 ################################################################################################################################################################ # Firewall to DMZ # ACCEPT fw dmz tcp www,ftp,ssh,smtp ACCEPT fw dmz udp domain ACCEPT fw dmz icmp 8 REJECT fw dmz udp 137:139
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
diff --git a/Shorewall-docs/ports.htm b/Shorewall-docs/ports.htm
index 7af0cba5a..89d4c0b30 100644
--- a/Shorewall-docs/ports.htm
+++ b/Shorewall-docs/ports.htm
@@ -1,242 +1,201 @@
-
+
Shorewall Port Information
-
+
-
+
-
+
-
-
-
-
Ports required for Various
- Services/Applications
-
-
-
-
+
+
+
+
+
Ports required for Various
+ Services/Applications
+
+
+
+
-
+
In addition to those applications described in the /etc/shorewall/rules documentation, here
- are some other services/applications that you may need to configure your
- firewall to accommodate.
-
+ href="Documentation.htm">the /etc/shorewall/rules documentation, here
+ are some other services/applications that you may need to configure
+your firewall to accommodate.
+
NTP (Network Time Protocol)
-
-
+
+
UDP Port 123
-
-
+
+
rdate
-
-
+
+
TCP Port 37
-
-
+
+
UseNet (NNTP)
-
-
+
+
TCP Port 119
-
-
+
+
DNS
-
-
-
UDP Port 53. If you are configuring a DNS client, you will probably want
-to open TCP Port 53 as well.
- If you are configuring a server, only open TCP Port 53 if you
-will return long replies to queries or if you need to enable ZONE transfers. In
- the latter case, be sure that your server is properly configured.
-
-
+
+
+
UDP Port 53. If you are configuring a DNS client, you will probably
+want to open TCP Port 53 as well.
+ If you are configuring a server, only open TCP Port 53 if
+you will return long replies to queries or if you need to enable ZONE
+transfers. In the latter case, be sure that your server is properly
+configured.
+
+
ICQ
-
-
-
UDP Port 4000. You will also need to open a range of TCP ports which
- you can specify to your ICQ client. By default, clients use 4000-4100.
-
-
+
+
+
UDP Port 4000. You will also need to open a range of TCP ports which
+ you can specify to your ICQ client. By default, clients use 4000-4100.
For a client, you must open outbound TCP port 21 and be sure that your
- kernel is compiled to support FTP connection tracking. If you build
-this support as a module, Shorewall will automatically load the module
-from /var/lib/<kernel version>/kernel/net/ipv4/netfilter.
-
-
-
If you run an FTP server on a nonstandard port or you need to access
- such a server, then you must specify that port in /etc/shorewall/modules.
- For example, if you run an FTP server that listens on port 49 then you
-would have:
-
- "I have fought with IPtables for untold hours. First I
-tried the SuSE firewall, which worked for 80% of what I needed. Then gShield,
-which also worked for 80%. Then I set out to write my own IPtables parser
-in shell and awk, which was a lot of fun but never got me past the "hey,
-cool" stage. Then I discovered Shorewall. After about an hour, everything
-just worked. I am stunned, and very grateful" -- ES, Phoenix AZ, USA.
-
-
"The configuration is intuitive and flexible, and much easier than any
- of the other iptables-based firewall programs out there. After sifting through
- many other scripts, it is obvious that yours is the most well thought-out
- and complete one available." -- BC, USA
-
-
"I just installed Shorewall after weeks of messing with ipchains/iptables
- and I had it up and running in under 20 minutes!" -- JL, Ohio
-
- "My case was almost like [the one above]. Well. instead of 'weeks' it
-was 'months' for me, and I think I needed two minutes more:
-
One to see that I had no Internet access from the firewall itself.
-
Other to see that this was the default configuration, and it was
- enough to uncomment a line in /etc/shorewall/policy.
-
-
+
"I have fought with IPtables for untold hours. First
+I tried the SuSE firewall, which worked for 80% of what I needed. Then gShield,
+which also worked for 80%. Then I set out to write my own IPtables parser
+in shell and awk, which was a lot of fun but never got me past the "hey, cool"
+stage. Then I discovered Shorewall. After about an hour, everything just
+worked. I am stunned, and very grateful" -- ES, Phoenix AZ, USA.
+
+
+
"The configuration is intuitive and flexible, and much easier than
+any of the other iptables-based firewall programs out there. After sifting
+through many other scripts, it is obvious that yours is the most well thought-out
+ and complete one available." -- BC, USA
+
+
+
"I just installed Shorewall after weeks of messing with ipchains/iptables
+ and I had it up and running in under 20 minutes!" -- JL, Ohio
+
+
+
"My case was almost like [the one above]. Well. instead of 'weeks'
+it was 'months' for me, and I think I needed two minutes more:
+
- Minutes instead of months! Congratulations and thanks for such a simple
- and well documented thing for something as huge as iptables." -- JV, Spain.
-
-
"I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without
- any problems. Your documentation is great and I really appreciate your
- network configuration info. That really helped me out alot. THANKS!!!"
- -- MM.
-
-
"[Shorewall is a] great, great project. I've used/tested may firewall
- scripts but this one is till now the best." -- B.R, Netherlands
-
-
-
"Never in my +12 year career as a sys admin have I witnessed someone
- so relentless in developing a secure, state of the art, safe and
-useful product as the Shorewall firewall package for no cost or obligation
- involved." -- Mario Kerecki, Toronto
-
-
"one time more to report, that your great shorewall in the latest release
- 1.2.9 is working fine for me with SuSE Linux 7.3! I now have 7 machines
-up and running with shorewall on several versions - starting with 1.2.2
-up to the new 1.2.9 and I never have encountered any problems!" -- SM,
-Germany
-
-
"You have the best support of any other package I've ever used."
- -- SE, US
-
-
"Because our company has information which has been classified by the
- national government as secret, our security doesn't stop by putting a fence
- around our company. Information security is a hot issue. We also make
-use of checkpoint firewalls, but not all of the internet servers are guarded
- by checkpoint, some of them are running....Shorewall." -- Name withheld
- by request, Europe
-
-
"thanx for all your efforts you put into shorewall - this product stands
- out against a lot of commercial stuff i´ve been working with in terms
-of flexibillity, quality & support" -- RM, Austria
-
-
"I have never seen such a complete firewall package that is so easy to
- configure. I searched the Debian package system for firewall scripts and
- Shorewall won hands down." -- RG, Toronto
-
-
"My respects... I've just found and installed Shorewall 1.3.3-1 and it
- is a wonderful piece of software. I've just sent out an email to about
+
+
+
+
+
One to see that I had no Internet access from the firewall itself.
+
+
+
+
Other to see that this was the default configuration, and it was
+enough to uncomment a line in /etc/shorewall/policy.
+
+
+
+
+
+
Minutes instead of months! Congratulations and thanks for such
+a simple and well documented thing for something as huge as iptables." --
+JV, Spain.
+
+
+
"I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1
+ without any problems. Your documentation is great and I really appreciate
+your network configuration info. That really helped me out alot. THANKS!!!"
+ -- MM.
+
+
+
+
"[Shorewall is a] great, great project. I've used/tested may
+firewall scripts but this one is till now the best." -- B.R, Netherlands
+
+
+
+
+
"Never in my +12 year career as a sys admin have I witnessed
+someone so relentless in developing a secure, state of the art, safe and
+ useful product as the Shorewall firewall package for no cost or obligation
+ involved." -- Mario Kerecki, Toronto
+
+
+
+
"one time more to report, that your great shorewall in the latest
+ release 1.2.9 is working fine for me with SuSE Linux 7.3! I now
+have 7 machines up and running with shorewall on several versions
+- starting with 1.2.2 up to the new 1.2.9 and I never have encountered
+any problems!" -- SM, Germany
+
+
+
+
"You have the best support of any other package I've ever used."
+ -- SE, US
+
+
+
+
"Because our company has information which has been classified by the
+ national government as secret, our security doesn't stop by putting a fence
+ around our company. Information security is a hot issue. We also make use
+ of checkpoint firewalls, but not all of the internet servers are guarded
+ by checkpoint, some of them are running....Shorewall." -- Name withheld
+ by request, Europe
+
+
+
+
"thanx for all your efforts you put into shorewall - this product stands
+ out against a lot of commercial stuff i´ve been working with in terms of
+ flexibillity, quality & support" -- RM, Austria
+
+
+
+
"I have never seen such a complete firewall package that is so easy
+to configure. I searched the Debian package system for firewall scripts
+and Shorewall won hands down." -- RG, Toronto
+
+
+
+
+
"My respects... I've just found and installed Shorewall 1.3.3-1 and
+it is a wonderful piece of software. I've just sent out an email to about
30 people recommending it. :-)
- While I had previously taken the time (maybe 40 hours) to really understand
- ipchains, then spent at least an hour per server customizing and carefully
- scrutinizing firewall rules, I've got shorewall running on my home firewall,
- with rulesets and policies that I know make sense, in under 20 minutes."
+
+While I had previously taken the time (maybe 40 hours) to really understand
+ ipchains, then spent at least an hour per server customizing and carefully
+ scrutinizing firewall rules, I've got shorewall running on my home firewall,
+ with rulesets and policies that I know make sense, in under 20 minutes."
-- RP, Guatamala
-
-
-
-
The Shoreline Firewall, more commonly known as "Shorewall", is a
- Netfilter (iptables) based firewall
- that can be used on a dedicated firewall system, a multi-function
- gateway/router/server or on a standalone GNU/Linux system.
-
-
-
-
-
-
-
This program is free software; you can redistribute it and/or modify
-
- it under the terms of Version 2 of the GNU
-General Public License as published by the Free Software
- Foundation.
-
-
-
- This program is distributed
- in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without
- even the implied warranty of MERCHANTABILITY
- or FITNESS FOR A PARTICULAR PURPOSE.
- See the GNU General Public License for more
-details.
-
-
-
- You should have received a
- copy of the GNU General Public License
- along with this program; if not,
- write to the Free Software Foundation,
- Inc., 675 Mass Ave, Cambridge, MA 02139,
- USA
Netfilter - the
+packet filter facility built into the 2.4 and later Linux kernels.
+
ipchains - the packet filter facility built into the 2.2
+Linux kernels. Also the name of the utility program used to configure
+and control that facility. Netfilter can be used in ipchains
+compatibility mode.
+
+
iptables - the utility program used to configure and
+control
+Netfilter. The term 'iptables' is often used to refer to the
+combination of iptables+Netfilter (with Netfilter not in
+ipchains compatibility mode).
+
+
+The Shoreline Firewall, more commonly known as "Shorewall", is
+high-level tool for configuring Netfilter. You describe your
+firewall/gateway requirements using entries in a set of configuration
+files. Shorewall reads those configuration files and with the help of
+the iptables utility, Shorewall configures Netfilter to match your
+requirements. Shorewall can be used on a dedicated firewall system, a
+multi-function gateway/router/server or on a standalone GNU/Linux
+system. Shorewall does not use Netfilter's ipchains compatibility mode
+and can thus take advantage of Netfilter's connection state tracking
+capabilities.
+
+This program is free software; you can redistribute it and/or modify it
+under the terms of Version
+2 of the GNU
+General Public License as published by the Free Software Foundation.
+
This program is distributed in the hope that it will be
+useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc.,
+675 Mass Ave, Cambridge, MA 02139, USA
- New to Shorewall? Start by selecting
- the QuickStart Guide
- that most closely match your environment and follow the
-step by step instructions.
-
-
+New to Shorewall? Start by selecting the QuickStart Guide that most
+closely match your environment
+and follow the step by step instructions.
Looking for Information?
- The Documentation
- Index is a good place to start as is the Quick Search to your right.
-
+The Documentation
+Index is a good place to start as is the Quick Search to your
+right.
Running Shorewall on Mandrake with a two-interface setup?
- If so, the documentationon this site
- will not apply directly to your setup. If you want to use the
- documentation that you find here, you will want to consider uninstalling
- what you have and installing a setup that matches the documentation
- on this site. See the Two-interface
- QuickStart Guide for details.
-
-
+If so, the documentationon
+this site will not apply directly to your setup. If you want
+to use the documentation that you find here, you will want to consider
+uninstalling what you have and installing a setup that matches the
+documentation on this site. See the Two-interface
+QuickStart Guide for details.
Corrected problem in 1.4.6 where the MANGLE_ENABLED
+variable was being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of
+the tcrules file. Previously, these addresses resulted in an invalid
+iptables command.
+
The "shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled exists. This prevents people from
+shooting themselves in the foot prior to having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages
+during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
+were being added to a PPP interface; the addresses were successfully
+added in spite of the messages.
+
+The firewall script has been modified to eliminate the error messages
+
-
-
-
-
7/20/2003 - Shorewall-1.4.6
-
-
-
-
-
-
-
Problems Corrected:
-
-
-
+ Migration Issues:
-
A problem seen on RH7.3 systems where Shorewall encountered
- start errors when started using the "service" mechanism has been worked
- around.
-
-
-
Where a list of IP addresses appears in the DEST column
- of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
-in the nat table (one for each element in the list). Shorewall now correctly
- creates a single DNAT rule with multiple "--to-destination" clauses.
-
-
-
Corrected a problem in Beta 1 where DNS names containing
- a "-" were mis-handled when they appeared in the DEST column of a rule.
-
-
-
A number of problems with rule parsing have been corrected.
- Corrections involve the handling of "z1!z2" in the SOURCE column as well
- as lists in the ORIGINAL DESTINATION column.
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions,
+current uses of "shorewall drop" and "shorewall reject" should be
+replaced with "shorewall dropall" and "shorewall rejectall"
+
+ New Features:
+
+
Shorewall now creates a dynamic blacklisting chain for each
+interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
+commands use the routing table to determine which of these chains is to
+be used for blacklisting the specified IP address(es).
-
-
The message "Adding rules for DHCP" is now suppressed if there
-are no DHCP rules to add.
-
-
-
-
-
-
Migration Issues:
-
-
-
-
In earlier versions, an undocumented feature allowed
-entries in the host file as follows:
-
- z eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6
- to allow entries of the following format:
-
- z eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
- have been removed from /etc/shorewall/shorewall.conf. These capabilities
- are now automatically detected by Shorewall (see below).
-
-
-
-
-
New Features:
-
-
-
-
-
A 'newnotsyn' interface option has been added. This
-option may be specified in /etc/shorewall/interfaces and overrides the
-setting NEWNOTSYN=No for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in
-/etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes
-is enabled for address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other
-than the first one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin)
- over a set of servers. Servers may be specified in a range of addresses
- given as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
- options have been removed and have been replaced by code that detects
- whether these capabilities are present in the current kernel. The output
- of the start, restart and check commands have been enhanced to report the
- outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension
-has been added. This extension is available in recent kernel/iptables
-releases and allows for rules which match against elements in netfilter's
-connection tracking table. Shorewall automatically detects the availability
-of this extension and reports its availability in the output of the start,
-restart and check commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
- is changed in the following ways:
-
-
-
-
To handle 'norfc1918' filtering, Shorewall will not
- create chains in the mangle table but will rather do all 'norfc1918'
-filtering in the filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter
- rules; one in the nat table and one in the filter table. If the Connection
- Tracking Match Extension is available, the rule in the filter table is
- extended to check that the original destination address was the same as
- specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
An 'ipcalc' command has been added to /sbin/shorewall.
-
- ipcalc [ <address> <netmask> | <address>/<vlsm>
- ]
-
- Examples:
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0/24
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or dash),
- then the ipcalc command produces incorrect information for IP addresses
- 128.0.0.0-1 and for /1 networks. Bash should produce correct information
- for all valid IP addresses.
-
-
-
An 'iprange' command has been added to /sbin/shorewall.
-
-
- iprange <address>-<address>
-
- This command decomposes a range of IP addressses into a list of
-network and host addresses. The command can be useful if you need to construct
- an efficient set of rules that accept connections from a range of network
- addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic (ash
-or dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
A list of host/net addresses is now allowed in an entry
- in /etc/shorewall/hosts.
-
- Example:
-
- foo eth1:192.168.1.0/24,192.168.2.0/24
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
Thanks to Steve Herber, the 'help' command can now give
+command-specific help (e.g., shorewall help <command>).
+
A new option "ADMINISABSENTMINDED" has been added to
+/etc/shorewall/shorewall.conf. This option has a default value of "No"
+for existing users which causes Shorewall's 'stopped' state to
+continue as it has been; namely, in the stopped state only traffic
+to/from hosts listed in /etc/shorewall/routestopped is accepted.
-
-
The "shorewall check" command now includes the chain name when
-printing the applicable policy for each pair of zones.
-
- Example:
-
- Policy for dmz to net is REJECT using chain all2all
-
-This means that the policy for connections from the dmz to the internet is
-REJECT and the applicable entry in the /etc/shorewall/policy was the all->all
-policy.
+With ADMINISABSENTMINDED=Yes (the default for new installs), in
+addition to traffic to/from the hosts listed in
+/etc/shorewall/routestopped, Shorewall will allow:
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+loc:192.168.1.5 tcp 22
+ ACCEPT loc
+fw tcp 22
+
+From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+connection with local system 192.168.1.5. I then create a second SSH
+connection
+from that computer to the firewall and confidently type "shorewall
+stop".
+As part of its stop processing, Shorewall removes eth0:0 which kills my
+SSH
+connection to 192.168.1.5!!!
+
Given the wide range of VPN software, I can never hope to
+add specific support for all of it. I have therefore decided to add
+"generic" tunnel support.
+
+Generic tunnels work pretty much like any of the other tunnel types.
+You usually add a zone to represent the systems at the other end of the
+tunnel and you add the appropriate rules/policies to
+implement your security policy regarding traffic to/from those systems.
+
+In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+generic:<protocol>[:<port>] <zone> <ip
+address> <gateway zones>
+
+where:
+
+ <protocol> is the protocol
+used by the tunnel
+ <port> if the protocol
+is 'udp' or 'tcp' then this is the destination port number used by the
+tunnel.
+ <zone> is the zone of
+the remote tunnel gateway
+ <ip address> is the IP
+address of the remote tunnel gateway.
+ <gateway zone>
+Optional. A comma-separated list of zone names. If specified, the
+remote gateway is to be considered part of these zones.
+
An 'arp_filter' option has been added to the
+/etc/shorewall/interfaces file. This option causes
+/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+result that this interface will only answer ARP 'who-has' requests from
+hosts that are routed out through that interface. Setting this option
+facilitates testing of your firewall where multiple firewall interfaces
+are connected to the same HUB/Switch (all interfaces connected to the
+single HUB/Switch should have this option specified). Note that using
+such a configuration in a production environment is strongly
+recommended against.
-
Support for the 2.6 Kernel series has been added.
+
+
8/5/2003 - Shorewall-1.4.6b
+
+ Problems Corrected since version 1.4.6:
+
+
Previously, if TC_ENABLED is set to yes in shorewall.conf
+then Shorewall would fail to start with the error "ERROR: Traffic
+Control requires Mangle"; that problem has been corrected.
+
Corrected handling of MAC addresses in the SOURCE column of
+the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables
+command.
+
The "shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled
+exists. This prevents people from shooting themselves in the foot prior
+to
+having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages
+during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being
+added to a PPP interface; the addresses were successfully added in
+spite
+of the messages.
+
+The firewall script has been modified to eliminate the error messages.
The command "shorewall debug try <directory>"
- now correctly traces the attempt.
-
The INCLUDE directive now works properly in the
- zones file; previously, INCLUDE in that file was ignored.
-
/etc/shorewall/routestopped records with an empty
- second column are no longer ignored.
-
-
-
-
-
-
-
New Features:
-
-
-
-
-
The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-]
- rule may now contain a list of addresses. If the list begins with
-"!' then the rule will take effect only if the original destination
-address in the connection request does not match any of the addresses
-listed.
-
-
-
-
-
-
6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
-
-
-
-
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
- and iptables 1.2.8 (using the "official" RPM from netfilter.org).
-No problems have been encountered with this set of software. The Shorewall
- version is 1.4.4b plus the accumulated changes for 1.4.5.
-
-
-
-
6/8/2003 - Updated Samples
-
-
-
Thanks to Francesca Smith, the samples have been updated to Shorewall
- version 1.4.4.
-
- Jacques Nilo and Eric
- Wolzak have a LEAF (router/firewall/gateway
- on a floppy, CD or compact flash) distribution
- called Bering that
- features Shorewall-1.4.2 and Kernel-2.4.20.
- You can find their work at:
- http://leaf.sourceforge.net/devel/jnilo
-
-
-
-
- Congratulations to Jacques and Eric
-on the recent release of Bering 1.2!!!
-
-
-
-
+ alt="(Leaf Logo)"> Jacques Nilo and Eric Wolzak have a LEAF
+(router/firewall/gateway on a floppy, CD or compact flash) distribution
+called Bering that features Shorewall-1.4.2 and Kernel-2.4.20.
+You can find their work at:
+http://leaf.sourceforge.net/devel/jnilo
+
+ Congratulations to Jacques
+and Eric on the recent release of Bering 1.2!!!
I am currently a member of the design team for the next-generation operating
- system from the NonStop Enterprise Division of HP.
-
+ system from the NonStop Enterprise Division of HP.
+
I became interested in Internet Security when I established a home office
- in 1999 and had DSL service installed in our home. I investigated
- ipchains and developed the scripts which are now collectively
-known as Seattle Firewall.
- Expanding on what I learned from Seattle Firewall, I then
- designed and wrote Shorewall.
-
+ in 1999 and had DSL service installed in our home. I
+investigated ipchains and developed the scripts which are now
+collectively known as Seattle
+ Firewall. Expanding on what I learned from Seattle
+Firewall, I then designed and wrote Shorewall.
+
1.2Gz Athlon, Windows XP Pro, 320MB RAM,
- 40GB & 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal
- Windows system. Serves as a PPTP server for Road Warrior access. Dual
- boots Mandrake 9.0.
-
Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD,
- LNE100TX(Tulip) NIC - My personal Linux System which runs
-Samba. This system also has VMware
- installed and can run both Debian
- Woody and SuSE 8.1 in virtual
- machines.
-
K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD,
-EEPRO100 NIC - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache),
- FTP (Pure_ftpd), DNS server (Bind 9).
-
PII/233, RH8.0, 256MB MB RAM, 2GB SCSI
- HD - 3 LNE100TX (Tulip) and 1 TLAN NICs - Firewall running Shorewall
- 1.4.6Beta1, a DHCP server and Samba configured as a WINS server..
-
Duron 750, Win ME, 192MB RAM, 20GB HD,
-RTL8139 NIC - My wife's personal system.
-
PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB
- HD, built-in EEPRO100, EEPRO100 in expansion base - My work system.
-
XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC
-and LinkSys WET11 - Our Laptop.
-
-
- By default, Shorewall directs NetFilter to log using syslog (8). Syslog
- classifies log messages by a facility and a priority (using
- the notation facility.priority).
-
- The facilities defined by syslog are auth, authpriv, cron, daemon,
- kern, lpr, mail, mark, news, syslog, user, uucp and local0 through
- local7.
-
- Throughout the Shorewall documentation, I will use the term level
- rather than priority since level is the term used by NetFilter.
- The syslog documentation uses the term priority.
-
-
Syslog Levels
-
- Syslog levels are a method of describing to syslog (8) the importance
- of a message and a number of Shorewall parameters have a syslog level
-as their value.
-
- Valid levels are:
-
- 7
- debug
- 6
- info
- 5
- notice
- 4
- warning
- 3
- err
- 2
- crit
- 1
- alert
- 0
- emerg
-
- For most Shorewall logging, a level of 6 (info) is appropriate.
-Shorewall log messages are generated by NetFilter and are logged using
-the kern facility and the level that you specify. If you are unsure
-of the level to choose, 6 (info) is a safe bet. You may specify levels
-by name or by number.
-
- Syslogd writes log messages to files (typically in /var/log/*) based
- on their facility and level. The mapping of these facility/level pairs
-to log files is done in /etc/syslog.conf (5). If you make changes to this
-file, you must restart syslogd before the changes can take effect.
-
-
Configuring a Separate Log for Shorewall Messages
- There are a couple of limitations to syslogd-based logging:
-
-
-
If you give, for example, kern.info it's own log destination then
- that destination will also receive all kernel messages of levels 5 (notice)
- through 0 (emerg).
-
All kernel.info messages will go to that destination and not just
- those from NetFilter.
-
-
-
- Beginning with Shorewall version 1.3.12, if your kernel has ULOG
-target support (and most vendor-supplied kernels do), you may also specify
-a log level of ULOG (must be all caps). When ULOG is used, Shorewall will
-direct netfilter to log the related messages via the ULOG target which
-will send them to a process called 'ulogd'. The ulogd program is available
-from http://www.gnumonks.org/projects/ulogd and can be configured to log
-all Shorewall message to their own log file.
-
- Note: The ULOG logging mechanism is completely separate from
-syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have absolutely
-no effect on your Shorewall logging (except for Shorewall status messages
-which still go to syslog).
-
- You will need to have the kernel source available to compile ulogd.
-
- Download the ulod tar file and:
-
-
-
Be sure that /usr/src/linux is linked to your kernel source tree
-
-
cd /usr/local/src (or wherever you do your builds)
-
tar -zxf source-tarball-that-you-downloaded
-
cd ulogd-version
-
-
./configure
-
make
-
make install
-
-
-
- If you are like me and don't have a development environment on your
-firewall, you can do the first six steps on another system then either
-NFS mount your /usr/local/src directory or tar up the /usr/local/src/ulogd-version
- directory and move it to your firewall system.
-
- Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
-
-
-
syslogfile <file that you wish to log to>
-
syslogsync 1
-
-
- I also copied the file /usr/local/src/ulogd-version/ulogd.init
-to /etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd"
- to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple "chkconfig
- --level 3 ulogd on" starts ulogd during boot up. Your init system may need
- something else done to activate the script.
-
- You will need to change all instances of log levels (usually 'info') in
-your configuration files to 'ULOG' - this includes entries in the policy,
-rules and shorewall.conf files. Here's what I have:
-
-
[root@gateway shorewall]# grep ULOG * policy:loc fw REJECT ULOG policy:net all DROP ULOG 10/sec:40 policy:all all REJECT ULOG rules:REJECT:ULOG loc net tcp 6667 shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG shorewall.conf:RFC1918_LOG_LEVEL=ULOG [root@gateway shorewall]#
- Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file
- that you wish to log to>. This tells the /sbin/shorewall program
-where to look for the log when processing its "show log", "logwatch" and "monitor"
- commands.
-
-
+
+ By default, Shorewall directs NetFilter to log using syslog (8). Syslog
+ classifies log messages by a facility and a priority (using
+ the notation facility.priority).
+
+ The facilities defined by syslog are auth, authpriv, cron, daemon,
+ kern, lpr, mail, mark, news, syslog, user, uucp and local0
+through local7.
+
+ Throughout the Shorewall documentation, I will use the term level
+ rather than priority since level is the term used by NetFilter.
+ The syslog documentation uses the term priority.
-
+ Syslog levels are a method of describing to syslog (8) the importance
+ of a message and a number of Shorewall parameters have a syslog level
+ as their value.
+
+ Valid levels are:
+
+ 7
+ debug
+ 6
+ info
+ 5
+ notice
+ 4
+ warning
+ 3
+ err
+ 2
+ crit
+ 1
+ alert
+ 0
+ emerg
+
+ For most Shorewall logging, a level of 6 (info) is appropriate.
+ Shorewall log messages are generated by NetFilter and are logged using
+ the kern facility and the level that you specify. If you are
+unsure of the level to choose, 6 (info) is a safe bet. You may specify
+levels by name or by number.
+
+ Syslogd writes log messages to files (typically in /var/log/*)
+based on their facility and level. The mapping of these facility/level
+pairs to log files is done in /etc/syslog.conf (5). If you make changes
+to this file, you must restart syslogd before the changes can take effect.
+
+
Configuring a Separate Log for Shorewall Messages
+ There are a couple of limitations to syslogd-based logging:
+
+
+
If you give, for example, kern.info it's own log destination then
+ that destination will also receive all kernel messages of levels 5 (notice)
+ through 0 (emerg).
+
All kernel.info messages will go to that destination and not just
+ those from NetFilter.
+
+
+
+ Beginning with Shorewall version 1.3.12, if your kernel has ULOG
+ target support (and most vendor-supplied kernels do), you may also specify
+ a log level of ULOG (must be all caps). When ULOG is used, Shorewall will
+ direct netfilter to log the related messages via the ULOG target which
+will send them to a process called 'ulogd'. The ulogd program is available
+from http://www.gnumonks.org/projects/ulogd and can be configured to log
+all Shorewall message to their own log file.
+
+ Note: The ULOG logging mechanism is completely separate
+from syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have
+absolutely no effect on your Shorewall logging (except for Shorewall status
+messages which still go to syslog).
+
+ You will need to have the kernel source available to compile ulogd.
+ Download the ulod tar file and:
+
+
+
Be sure that /usr/src/linux is linked to your kernel source tree
+
+
cd /usr/local/src (or wherever you do your builds)
+
tar -zxf source-tarball-that-you-downloaded
+
cd ulogd-version
+
+
./configure
+
make
+
make install
+
+
+
+ If you are like me and don't have a development environment on your
+firewall, you can do the first six steps on another system then either NFS
+mount your /usr/local/src directory or tar up the /usr/local/src/ulogd-version
+ directory and move it to your firewall system.
+
+ Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
+
+
+
syslogfile <file that you wish to log to>
+
syslogsync 1
+
+
+Also on the firewall system:
+
touch <file that you wish to log to>
+
+ I also copied the file /usr/local/src/ulogd-version/ulogd.init
+ to /etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd"
+ to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple
+"chkconfig --level 3 ulogd on" starts ulogd during boot up. Your init system
+may need something else done to activate the script.
+
+ You will need to change all instances of log levels (usually 'info') in
+ your configuration files to 'ULOG' - this includes entries in the policy,
+ rules and shorewall.conf files. Here's what I have:
+
+
[root@gateway shorewall]# grep ULOG * policy:loc fw REJECT ULOG policy:net all DROP ULOG 10/sec:40 policy:all all REJECT ULOG rules:REJECT:ULOG loc net tcp 6667 shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG shorewall.conf:RFC1918_LOG_LEVEL=ULOG [root@gateway shorewall]#
+ Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file
+ that you wish to log to>. This tells the /sbin/shorewall program
+ where to look for the log when processing its "show log", "logwatch" and
+"monitor" commands.
+
+
Remember that updates to the mirrors are often delayed
- for 6-12 hours after an update to the primary rsync site. For HTML content,
- the main web site (http://shorewall.sf.net)
- is updated at the same time as the rsync site.
-
+ for 6-12 hours after an update to the primary rsync site. For HTML content,
+ the main web site (http://shorewall.sf.net)
+ is updated at the same time as the rsync site.
+
The main Shorewall Web Site is http://shorewall.sf.net
- and is located in California, USA. It is mirrored at:
-
+ and is located in California, USA. It is mirrored at:
+
With thanks to Richard who reminded me once again that
-we must all first walk before we can run.
- The French Translations are courtesy of Patrice Vetsel
-
-
+
With thanks to Richard who reminded me once again
+that we
+must all first walk before we can run.
+The French Translations are courtesy of Patrice Vetsel
+
The Guides
-
-
These guides provide step-by-step instructions for configuring Shorewall
- in common firewall setups.
-
-
If you have a single public IP address:
-
+
These guides provide step-by-step instructions for configuring
+Shorewall in common firewall setups.
The above guides are designed to get your first firewall up and running
- quickly in the three most common Shorewall configurations.
-If you want to learn more about Shorewall than is explained in the above
-simple guides, the Shorewall Setup Guide
-(See Index Below) is for you.
+
The above guides are designed to get your first firewall up and
+running quickly in the three most common Shorewall configurations. If
+you want to learn more about Shorewall than is explained in the above
+simple guides, the Shorewall
+Setup Guide (See Index Below) is for you.
-
-
If you have more than one public IP
-address:
+
If you have more than one public
+IP address:
-
The Shorewall Setup Guide
-(See Index Below) outlines the steps necessary to set up
-a firewall where there are multiple
-public IP addresses involved or if you
-want to learn more about Shorewall than is explained in the
+
The Shorewall Setup
+Guide (See Index Below) outlines the steps necessary to set up a
+firewall where there are multiple public IP
+addresses involved or if you
+want to learn more about Shorewall than is explained in the
single-address guides above.
-
-
-
Documentation Index
-
The following documentation covers a variety of topics and supplements
- the QuickStart
-Guides described above. Please review the appropriate
-guide before trying to use this documentation directly.
-
+the QuickStart Guides
+described above. Please review the appropriate guide before trying
+to use this documentation directly.
Extension Scripts
- (How to extend Shorewall without modifying Shorewall code through the
- use of files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped,
- etc.)
Extension
+Scripts (How to extend Shorewall without modifying Shorewall
+code through the use of files in /etc/shorewall --
+/etc/shorewall/start, /etc/shorewall/stopped, etc.)
This guide is intended for users who are setting up Shorewall in an environment
- where a set of public IP addresses must be managed or who want to
- know more about Shorewall than is contained in the single-address guides. Because
- the range of possible applications is so broad, the Guide will give
- you general guidelines and will point you to other resources as necessary.
-
+
This guide is intended for users who are setting up Shorewall in an
+environment where a set of public IP addresses must be managed or who
+want to know more about Shorewall than is contained in the single-address guides.
+Because the range of possible applications is so broad, the Guide will
+give you general guidelines and will point you to other resources as
+necessary.
- If you run LEAF Bering, your Shorewall configuration
-is NOT what I release -- I suggest that you consider installing a stock
- Shorewall lrp from the shorewall.net site before you proceed.
-
-
Shorewall requires that the iproute/iproute2 package be installed (on
- RedHat, the package is called iproute). You can tell
-if this package is installed by the presence of an ip program
-on your firewall system. As root, you can use the 'which' command to
-check for this program:
-
+ If you run LEAF Bering, your Shorewall configuration
+is NOT what I release -- I suggest that you consider installing a stock
+Shorewall lrp from the shorewall.net site before you proceed.
+
Shorewall requires that the iproute/iproute2 package be installed
+(on RedHat, the package is called iproute). You can
+tell if this package is installed by the presence of an ip
+program
+on your firewall system. As root, you can use the 'which' command to
+check for this program:
[root@gateway root]# which ip /sbin/ip [root@gateway root]#
-
-
I recommend that you first read through the guide to familiarize yourself
- with what's involved then go back through it again making your configuration
- changes. Points at which configuration changes are recommended are
- flagged with
- .
-
+
I recommend that you first read through the guide to familiarize
+yourself with what's involved then go back through it again making your
+configuration changes. Points at which configuration changes are
+recommended are flagged with .
- If you edit your configuration files on a Windows system,
- you must save them as Unix files if your editor supports that option
- or you must run them through dos2unix before trying to use them with Shorewall.
- Similarly, if you copy a configuration file from your Windows hard
-drive to a floppy disk, you must run dos2unix against the copy before
-using it with Shorewall.
-
+ If you edit your configuration files on a Windows
+system, you must save them as Unix files if your editor supports that
+option or you must run them through dos2unix before trying to use them
+with Shorewall. Similarly, if you copy a configuration file from your
+Windows hard
+drive to a floppy disk, you must run dos2unix against the copy before
+using it with Shorewall.
The configuration files for Shorewall are contained in the directory /etc/shorewall
- -- for most setups, you will only need to deal with a few of these as described
- in this guide. Skeleton files are created during the Shorewall Installation Process.
-
-
As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration
-instructions and some contain default entries.
-
-
Shorewall views the network where it is running as being composed of a
- set of zones. In the default installation, the following zone
- names are used:
-
+
The configuration files for Shorewall are contained in the directory
+/etc/shorewall -- for most setups, you will only need to deal with a
+few of these as described in this guide. Skeleton files are created
+during the Shorewall Installation Process.
+
As each file is introduced, I suggest that you look through the
+actual file on your system -- each file contains detailed configuration
+instructions and some contain default entries.
+
Shorewall views the network where it is running as being composed of
+a set of zones. In the default installation, the following zone
+names are used:
Shorewall also recognizes the firewall system as its own zone - by default,
- the firewall itself is known as fw but that may be changed
-in the /etc/shorewall/shorewall.conf
- file. In this guide, the default name (fw) will be used.
-
-
With the exception of fw, Shorewall attaches absolutely no meaning
- to zone names. Zones are entirely what YOU make of them. That means
- that you should not expect Shorewall to do something special "because
- this is the internet zone" or "because that is the DMZ".
Shorewall also recognizes the firewall system as its own zone - by
+default, the firewall itself is known as fw but that may be
+changed
+in the /etc/shorewall/shorewall.conf
+file. In this guide, the default name (fw) will be used.
+
With the exception of fw, Shorewall attaches absolutely no
+meaning to zone names. Zones are entirely what YOU make of them. That
+means that you should not expect Shorewall to do something special
+"because this is the internet zone" or "because that is the DMZ".
- Edit the /etc/shorewall/zones file and make any changes
- necessary.
-
-
Rules about what traffic to allow and what traffic to deny are expressed
- in terms of zones.
-
+ Edit the /etc/shorewall/zones file and make any
+changes necessary.
+
Rules about what traffic to allow and what traffic to deny are
+expressed in terms of zones.
-
You express your default policy for connections from
- one zone to another zone in the /etc/shorewall/policy file.
Shorewall is built on top of the Netfilter
- kernel facility. Netfilter implements a Shorewall is built on top of the Netfilter
+kernel facility. Netfilter implements a connection
- tracking function that allows what is often referred to as stateful
- inspection of packets. This stateful property allows firewall
- rules to be defined in terms of connections rather than in
-terms of packets. With Shorewall, you:
-
+tracking function that allows what is often referred to as stateful
+inspection of packets. This stateful property allows firewall rules
+to be defined in terms of connections rather than in
+terms of packets. With Shorewall, you:
-
Identify the source zone.
-
Identify the destination 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.
-
+
Identify the source zone.
+
Identify the destination 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 from zone A
-to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed
- from zone A to 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.
-
-
For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that
-file matches the connection request then the first policy in /etc/shorewall/policy
- that matches the request is applied. If that policy is REJECT or DROP
- the request is first checked against the rules in /etc/shorewall/common.def.
-
-
The default /etc/shorewall/policy file has the following policies:
-
-
+
Just because connections of a particular type are allowed from zone
+A
+to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are
+allowed from zone A to 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.
+
For each connection request entering the firewall, the request is
+first checked against the /etc/shorewall/rules file. If no rule in that
+file matches the connection request then the first policy in
+/etc/shorewall/policy that matches the request is applied. If that
+policy is REJECT or DROP the request is first checked against the
+rules in /etc/shorewall/common.def.
+
The default /etc/shorewall/policy file has the following policies:
+
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
loc
-
net
-
ACCEPT
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
loc
+
net
+
ACCEPT
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
-
-
+
The above policy will:
-
-
allow all connection requests from your local network
- to the internet
-
drop (ignore) all connection requests from the internet
- to your firewall or local network and log a message at the info
- level (here is a description of
-log levels).
-
reject all other connection requests and log a message
- at the info level. When a request is rejected, the firewall
- will return an RST (if the protocol is TCP) or an ICMP port-unreachable
- packet for other protocols.
-
+
allow all connection requests from your local network to the
+internet
+
drop (ignore) all connection requests from the internet to your
+firewall or local network and log a message at the info level (here is a description of
+log levels).
+
reject all other connection requests and log a message at the info
+level. When a request is rejected, the firewall will return an RST (if
+the protocol is TCP) or an ICMP port-unreachable packet for other
+protocols.
-
- At this point, edit your /etc/shorewall/policy and make
- any changes that you wish.
-
+ At this point, edit your /etc/shorewall/policy and
+make any changes that you wish.
3.0 Network Interfaces
-
-
For the remainder of this guide, we'll refer to the following
- diagram. While it may not look like your own network, it can be used
- to illustrate the important aspects of Shorewall configuration.
-
+
For the remainder of this guide, we'll refer to the
+following diagram. While it may not look like your own network, it can
+be used to illustrate the important aspects of Shorewall configuration.
In this diagram:
-
-
The DMZ Zone consists of systems DMZ 1 and DMZ 2. A
-DMZ is used to isolate your internet-accessible servers from your local
- systems so that if one of those servers is compromised, you still have
- the firewall between the compromised system and your local systems.
-
-
The Local Zone consists of systems Local 1, Local 2
-and Local 3.
-
All systems from the ISP outward comprise the Internet
- Zone.
-
+
The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
+to isolate your internet-accessible servers from your local systems so
+that if one of those servers is compromised, you still have the
+firewall between the compromised system and your local systems.
+
The Local Zone consists of systems Local 1, Local 2 and Local 3.
+
All systems from the ISP outward comprise the Internet Zone.
-
-
-
-
The simplest way to define zones is to simply associate the
- zone name (previously defined in /etc/shorewall/zones) with a network
- interface. This is done in the /etc/shorewall/interfaces file.
-
-
The firewall illustrated above has three network interfaces.
- Where Internet connectivity is through a cable or DSL "Modem", the
- External Interface will be the Ethernet adapter that is connected
- to that "Modem" (e.g., eth0) unless you connect via
-Point-to-Point Protocol over Ethernet
-(PPPoE) or Point-to-Point Tunneling Protocol
-(PPTP) in which case the External Interface will be a ppp interface
-(e.g., ppp0). If you connect via a regular modem, your External
- Interface will also be ppp0. If you connect using ISDN, you external
- interface will be ippp0.
-
+ height="635">
+
The simplest way to define zones is to simply associate
+the zone name (previously defined in /etc/shorewall/zones) with a
+network interface. This is done in the /etc/shorewall/interfaces file.
+
The firewall illustrated above has three network
+interfaces. Where Internet connectivity is through a cable or DSL
+"Modem", the External Interface will be the Ethernet adapter
+that is connected to that "Modem" (e.g., eth0) unless
+you connect via
+Point-to-Point Protocol over Ethernet
+(PPPoE) or Point-to-Point Tunneling Protocol
+(PPTP) in which case the External Interface will be a ppp interface
+(e.g., ppp0). If you connect via a regular modem, your External
+Interface will also be ppp0. If you connect using ISDN, you
+external interface will be ippp0.
Your Local Interface will be an Ethernet adapter (eth0,
- eth1 or eth2) and will be connected to a hub or switch. Your local
- computers will be connected to the same switch (note: If you have
-only a single local system, you can connect the firewall directly to
-the computer using a cross-over cable).
-
-
Your DMZ Interface will also be an Ethernet adapter
- (eth0, eth1 or eth2) and will be connected to a hub or switch. Your
- DMZ computers will be connected to the same switch (note: If you have
- only a single DMZ system, you can connect the firewall directly to the
- computer using a cross-over cable).
-
+ height="13"> If your external interface is ppp0
+or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
+
Your Local Interface will be an Ethernet
+adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
+Your local computers will be connected to the same switch (note: If you
+have
+only a single local system, you can connect the firewall directly to
+the computer using a cross-over cable).
+
Your DMZ Interface will also be an Ethernet
+adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
+Your DMZ computers will be connected to the same switch (note: If you
+have only a single DMZ system, you can connect the firewall directly to
+the computer using a cross-over cable).
- Do not connect more than one interface to the same
- hub or switch (even for testing). It won't work the way that you
-expect it to and you will end up confused and believing that Linux networking
- doesn't work at all.
-
+ width="60" height="60"> Do not connect the internal and
+external interface to the same hub or switch except for testing AND you
+are running Shorewall version 1.4.7 or later. When using these
+recent
+versions, you can test using this kind of configuration if you specify
+the arp_filter
+option in /etc/shorewall/interfaces for all interfaces connected to the
+common hub/switch. Using such a setup with a production firewall is
+strongly recommended against.
For the remainder of this Guide, we will assume that:
-
-
+
The external interface is eth0.
-
-
+
+
The Local interface is eth1.
-
-
+
+
The DMZ interface is eth2.
-
-
+
-
-
The Shorewall default configuration does not define the contents
- of any zone. To define the above configuration using the /etc/shorewall/interfaces
- file, that file would might contain:
-
-
+
The Shorewall default configuration does not define the
+contents of any zone. To define the above configuration using the
+/etc/shorewall/interfaces file, that file would might contain:
+
-
-
-
Zone
-
Interface
-
Broadcast
-
Options
-
-
-
net
-
eth0
-
detect
-
norfc1918
-
-
-
loc
-
eth1
-
detect
-
-
-
-
dmz
-
eth2
-
detect
-
-
-
-
+
+
+
Zone
+
Interface
+
Broadcast
+
Options
+
+
+
net
+
eth0
+
detect
+
norfc1918
+
+
+
loc
+
eth1
+
detect
+
+
+
+
dmz
+
eth2
+
detect
+
+
+
-
-
+
- Edit the /etc/shorewall/interfaces file and define the
- network interfaces on your firewall and associate each interface
-with a zone. If you have a zone that is interfaced through more than
-one interface, simply include one entry for each interface and repeat
-the zone name as many times as necessary.
-
+ height="13"> Edit the /etc/shorewall/interfaces
+file and define the network interfaces on your firewall and associate
+each interface
+with a zone. If you have a zone that is interfaced through more than
+one interface, simply include one entry for each interface and repeat
+the zone name as many times as necessary.
Example:
-
-
+
-
-
-
Zone
-
Interface
-
Broadcast
-
Options
-
-
-
net
-
eth0
-
detect
-
norfc1918
-
-
-
loc
-
eth1
-
detect
-
-
-
-
loc
-
eth2
-
detect
-
dhcp
-
-
-
+
+
+
Zone
+
Interface
+
Broadcast
+
Options
+
+
+
net
+
eth0
+
detect
+
norfc1918
+
+
+
loc
+
eth1
+
detect
+
+
+
+
loc
+
eth2
+
detect
+
dhcp
+
+
-
-
-
-
When you have more than one interface to a zone, you will
- usually want a policy that permits intra-zone traffic:
-
-
-
-
+
+
+
When you have more than one interface to a zone, you
+will usually want a policy that permits intra-zone traffic:
+
+
+
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
loc
-
loc
-
ACCEPT
-
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
loc
+
loc
+
ACCEPT
+
+
+
+
-
-
-
+
+
- You may define more complicated zones using the /etc/shorewall/hosts file but in most
- cases, that isn't necessary.
-
-
4.0 Addressing, Subnets and Routing
-
+ height="13"> You may define more complicated zones
+using the /etc/shorewall/hosts
+file but in most cases, that isn't necessary.
+
4.0 Addressing, Subnets and
+Routing
Normally, your ISP will assign you a set of Public
- IP addresses. You will configure your firewall's external interface
- to use one of those addresses permanently and you will then have to
-decide how you are going to use the rest of your addresses. Before we
-tackle that question though, some background is in order.
-
-
If you are thoroughly familiar with IP addressing and routing,
- you may go to the next section.
-
-
The following discussion barely scratches the surface of addressing
-and routing. If you are interested in learning more about this subject,
-I highly recommend "IP Fundamentals: What Everyone Needs to Know about
-Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN
+IP addresses. You will configure your firewall's external interface to
+use one of those addresses permanently and you will then have to
+decide how you are going to use the rest of your addresses. Before we
+tackle that question though, some background is in order.
+
If you are thoroughly familiar with IP addressing and
+routing, you may go to the next section.
+
The following discussion barely scratches the surface
+of addressing
+and routing. If you are interested in learning more about this subject,
+I highly recommend "IP Fundamentals: What Everyone Needs to Know
+about
+Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999,
+ISBN
0-13-975483-0.
-
4.1 IP Addresses
-
-
IP version 4 (IPv4) addresses are 32-bit numbers.
- The notation w.x.y.z refers to an address where the high-order byte
- has value "w", the next byte has value "x", etc. If we take the address
- 192.0.2.14 and express it in hexadecimal, we get:
-
-
+
IP version 4 (IPv4) addresses are 32-bit
+numbers. The notation w.x.y.z refers to an address where the high-order
+byte has value "w", the next byte has value "x", etc. If we take the
+address 192.0.2.14 and express it in hexadecimal, we get:
+
C0.00.02.0E
-
-
+
or looking at it as a 32-bit integer
-
-
+
C000020E
-
-
+
4.2 Subnets
-
-
You will still hear the terms "Class A network", "Class B
- network" and "Class C network". In the early days of IP, networks
- only came in three sizes (there were also Class D networks but they
-were used differently):
-
-
+
You will still hear the terms "Class A network", "Class
+B network" and "Class C network". In the early days of IP, networks
+only came in three sizes (there were also Class D networks but they
+were used differently):
+
Class A - netmask 255.0.0.0, size = 2 ** 24
-
-
Class B - netmask 255.255.0.0, size = 2 ** 16
-
-
Class C - netmask 255.255.255.0, size = 256
-
-
-
The class of a network was uniquely determined by the value
- of the high order byte of its address so you could look at an IP
-address and immediately determine the associated netmask.
-The netmask is a number that when logically ANDed with an address isolates
-the network number; the remainder of the address is the host
-number. For example, in the Class C address 192.0.2.14, the network
-number is hex C00002 and the host number is hex 0E.
-
-
As the internet grew, it became clear that such a gross partitioning
- of the 32-bit address space was going to be very limiting (early on, large
- corporations and universities were assigned their own class A network!).
- After some false starts, the current technique of subnetting these
- networks into smaller subnetworks evolved; that technique is referred
- to as Classless InterDomain Routing (CIDR). Today, any system that
- you are likely to work with will understand CIDR and Class-based networking
- is largely a thing of the past.
-
-
A subnetwork (often referred to as a subnet) is
- a contiguous set of IP addresses such that:
-
+
Class B - netmask 255.255.0.0, size = 2 ** 16
+
Class C - netmask 255.255.255.0, size = 256
+
+
The class of a network was uniquely determined by the
+value of the high order byte of its address so you could look at an IP
+address and immediately determine the associated netmask.
+The netmask is a number that when logically ANDed with an address
+isolates
+the network number; the remainder of the address is the host
+number. For example, in the Class C address 192.0.2.14, the network
+number is hex C00002 and the host number is hex 0E.
+
As the internet grew, it became clear that such a gross
+partitioning of the 32-bit address space was going to be very limiting
+(early on, large corporations and universities were assigned their own
+class A network!). After some false starts, the current technique of subnetting
+these networks into smaller subnetworks evolved; that technique
+is referred to as Classless InterDomain Routing (CIDR).
+Today, any system that you are likely to work with will understand CIDR
+and Class-based networking is largely a thing of the past.
+
A subnetwork (often referred to as a subnet)
+is a contiguous set of IP addresses such that:
-
-
The number of addresses in the set is a power of 2; and
-
-
-
The first address in the set is a multiple of the set
- size.
-
-
-
The first address in the subnet is reserved and is referred
- to as the subnet address.
-
-
+
+
The number of addresses in the set is a power of 2;
+and
+
+
+
The first address in the set is a multiple of the
+set size.
+
+
+
The first address in the subnet is reserved and is
+referred to as the subnet address.
+
+
The last address in the subnet is reserved as the subnet's
- broadcast address.
-
-
+broadcast address.
+
-
-
As you can see by this definition, in each subnet of size
- n there are (n - 2) usable addresses (addresses that
- can be assigned to hosts). The first and last address in the subnet
- are used for the subnet address and subnet broadcast address respectively.
- Consequently, small subnetworks are more wasteful of IP addresses
- than are large ones.
-
-
Since n is a power of two, we can easily calculate
- the Natural Logarithm (log2) of n. For the
-more common subnet sizes, the size and its natural logarithm are given
-in the following table:
-
-
+
As you can see by this definition, in each subnet of
+size n there are (n - 2) usable addresses (addresses
+that can be assigned to hosts). The first and last address in the
+subnet are used for the subnet address and subnet broadcast address
+respectively. Consequently, small subnetworks are more wasteful of IP
+addresses than are large ones.
+
Since n is a power of two, we can easily
+calculate the Natural Logarithm (log2) of n. For
+the
+more common subnet sizes, the size and its natural logarithm are given
+in the following table:
+
-
-
-
n
-
log2 n
-
(32 - log2 n)
-
-
-
8
-
3
-
29
-
-
-
16
-
4
-
28
-
-
-
32
-
5
-
27
-
-
-
64
-
6
-
26
-
-
-
128
-
7
-
25
-
-
-
256
-
8
-
24
-
-
-
512
-
9
-
23
-
-
-
1024
-
10
-
22
-
-
-
2048
-
11
-
21
-
-
-
4096
-
12
-
20
-
-
-
8192
-
13
-
19
-
-
-
16384
-
14
-
18
-
-
-
32768
-
15
-
17
-
-
-
65536
-
16
-
16
-
-
-
+
+
+
n
+
log2 n
+
(32 - log2 n)
+
+
+
8
+
3
+
29
+
+
+
16
+
4
+
28
+
+
+
32
+
5
+
27
+
+
+
64
+
6
+
26
+
+
+
128
+
7
+
25
+
+
+
256
+
8
+
24
+
+
+
512
+
9
+
23
+
+
+
1024
+
10
+
22
+
+
+
2048
+
11
+
21
+
+
+
4096
+
12
+
20
+
+
+
8192
+
13
+
19
+
+
+
16384
+
14
+
18
+
+
+
32768
+
15
+
17
+
+
+
65536
+
16
+
16
+
+
-
-
-
You will notice that the above table also contains a column
- for (32 - log2 n). That number is the Variable Length
-Subnet Mask for a network of size n. From the above table,
-we can derive the following one which is a little easier to use.
-
-
+
+
You will notice that the above table also contains a
+column for (32 - log2 n). That number is the Variable
+Length
+Subnet Mask for a network of size n. From the above table,
+we can derive the following one which is a little easier to use.
+
-
-
-
Size of Subnet
-
VLSM
-
Subnet Mask
-
-
-
8
-
/29
-
255.255.255.248
-
-
-
16
-
/28
-
255.255.255.240
-
-
-
32
-
/27
-
255.255.255.224
-
-
-
64
-
/26
-
255.255.255.192
-
-
-
128
-
/25
-
255.255.255.128
-
-
-
256
-
/24
-
255.255.255.0
-
-
-
512
-
/23
-
255.255.254.0
-
-
-
1024
-
/22
-
255.255.252.0
-
-
-
2048
-
/21
-
255.255.248.0
-
-
-
4096
-
/20
-
255.255.240.0
-
-
-
8192
-
/19
-
255.255.224.0
-
-
-
16384
-
/18
-
255.255.192.0
-
-
-
32768
-
/17
-
255.255.128.0
-
-
-
65536
-
/16
-
255.255.0.0
-
-
-
2 ** 24
-
/8
-
255.0.0.0
-
-
-
+
+
+
Size of Subnet
+
VLSM
+
Subnet Mask
+
+
+
8
+
/29
+
255.255.255.248
+
+
+
16
+
/28
+
255.255.255.240
+
+
+
32
+
/27
+
255.255.255.224
+
+
+
64
+
/26
+
255.255.255.192
+
+
+
128
+
/25
+
255.255.255.128
+
+
+
256
+
/24
+
255.255.255.0
+
+
+
512
+
/23
+
255.255.254.0
+
+
+
1024
+
/22
+
255.255.252.0
+
+
+
2048
+
/21
+
255.255.248.0
+
+
+
4096
+
/20
+
255.255.240.0
+
+
+
8192
+
/19
+
255.255.224.0
+
+
+
16384
+
/18
+
255.255.192.0
+
+
+
32768
+
/17
+
255.255.128.0
+
+
+
65536
+
/16
+
255.255.0.0
+
+
+
2 ** 24
+
/8
+
255.0.0.0
+
+
-
-
-
Notice that the VLSM is written with a slash ("/") -- you
- will often hear a subnet of size 64 referred to as a "slash 26"
-subnet and one of size 8 referred to as a "slash 29".
-
-
The subnet's mask (also referred to as its netmask) is
- simply a 32-bit number with the first "VLSM" bits set to one and
- the remaining bits set to zero. For example, for a subnet of size
-64, the subnet mask has 26 leading one bits:
The subnet mask has the property that if you logically AND
- the subnet mask with an address in the subnet, the result is the
- subnet address. Just as important, if you logically AND the subnet
- mask with an address outside the subnet, the result is NOT the subnet
- address. As we will see below, this property of subnet masks is very
- useful in routing.
-
-
For a subnetwork whose address is a.b.c.d and whose
- Variable Length Subnet Mask is /v, we denote the subnetwork
- as "a.b.c.d/v" using CIDRNotation.
-
+
+
Notice that the VLSM is written with a slash ("/") --
+you will often hear a subnet of size 64 referred to as a "slash 26"
+subnet and one of size 8 referred to as a "slash 29".
+
The subnet's mask (also referred to as its netmask)
+is simply a 32-bit number with the first "VLSM" bits set to one and
+the remaining bits set to zero. For example, for a subnet of size
+64, the subnet mask has 26 leading one bits:
The subnet mask has the property that if you logically
+AND the subnet mask with an address in the subnet, the result is the
+subnet address. Just as important, if you logically AND the subnet mask
+with an address outside the subnet, the result is NOT the subnet
+address. As we will see below, this property of subnet masks is very
+useful in routing.
+
For a subnetwork whose address is a.b.c.d and
+whose Variable Length Subnet Mask is /v, we denote the
+subnetwork as "a.b.c.d/v" using CIDRNotation.
+
Example:
-
-
+
-
-
-
Subnet:
-
10.10.10.0 - 10.10.10.127
-
-
-
Subnet Size:
-
128
-
-
-
Subnet Address:
-
10.10.10.0
-
-
-
Broadcast Address:
-
10.10.10.127
-
-
-
CIDR Notation:
-
10.10.10.0/25
-
-
-
+
+
+
Subnet:
+
10.10.10.0 - 10.10.10.127
+
+
+
Subnet Size:
+
128
+
+
+
Subnet Address:
+
10.10.10.0
+
+
+
Broadcast Address:
+
10.10.10.127
+
+
+
CIDR Notation:
+
10.10.10.0/25
+
+
-
-
-
There are two degenerate subnets that need mentioning; namely,
- the subnet with one member and the subnet with 2 ** 32 members.
-
-
+
+
There are two degenerate subnets that need mentioning;
+namely, the subnet with one member and the subnet with 2 ** 32 members.
+
-
-
-
Size of Subnetwork
-
VLSM Length
-
Subnet Mask
-
CIDR Notation
-
-
-
1
-
32
-
255.255.255.255
-
a.b.c.d/32
-
-
-
2 ** 32
-
0
-
0.0.0.0
-
0.0.0.0/0
-
-
-
+
+
+
Size of Subnetwork
+
VLSM Length
+
Subnet Mask
+
CIDR Notation
+
+
+
1
+
32
+
255.255.255.255
+
a.b.c.d/32
+
+
+
2 ** 32
+
0
+
0.0.0.0
+
0.0.0.0/0
+
+
-
-
-
So any address a.b.c.d may also be written a.b.c.d/32
- and the set of all possible IP addresses is written 0.0.0.0/0.
-
+
+
So any address a.b.c.d may also be written
+a.b.c.d/32 and the set of all possible IP addresses is written 0.0.0.0/0.
Later in this guide, you will see the notation a.b.c.d/v
- used to describe the ip configuration of a network interface (the
-'ip' utility also uses this syntax). This simply means that the interface
- is configured with ip address a.b.c.d and with the netmask that
- corresponds to VLSM /v.
-
+used to describe the ip configuration of a network interface (the
+'ip' utility also uses this syntax). This simply means that the
+interface is configured with ip address a.b.c.d and with the
+netmask that corresponds to VLSM /v.
Example: 192.0.2.65/29
-
-
The interface is configured with IP address 192.0.2.65
- and netmask 255.255.255.248.
-
-
-
Beginning with Shorewall 1.4.6, /sbin/shorewall supports an
-ipcalc command that automatically calculates information about a [sub]network.
-
-
+
The interface is configured with IP
+address 192.0.2.65 and netmask 255.255.255.248.
+
+
Beginning with Shorewall 1.4.6, /sbin/shorewall
+supports an
+ipcalc command that automatically calculates information about a
+[sub]network.
+
The device texas is a GRE tunnel to a peer site in
- the Dallas, Texas area.
-
- The first three routes are host routes since they
-indicate how to get to a single host. In the 'netstat' output this
-can be seen by the "Genmask" (Subnet Mask) of 255.255.255.255 and
-the "H" in the Flags column. The remainder are 'net' routes since they
-tell the kernel how to route packets to a subnetwork. The last route
-is the default route and the gateway mentioned in that route is
-called the default gateway.
-
-
When the kernel is trying to send a packet to IP address A,
- it starts at the top of the routing table and:
-
+
+
+
The device texas is a GRE tunnel to a peer site
+in the Dallas, Texas area.
+
+The first three routes are host routes since they
+indicate how to get to a single host. In the 'netstat' output this
+can be seen by the "Genmask" (Subnet Mask) of 255.255.255.255 and
+the "H" in the Flags column. The remainder are 'net' routes since they
+tell the kernel how to route packets to a subnetwork. The last route
+is the default route and the gateway mentioned in that route is
+called the default gateway.
+
When the kernel is trying to send a packet to IP
+address A, it starts at the top of the routing table and:
-
-
A is logically ANDed with the 'Genmask' value in
-the table entry.
-
-
-
The result is compared with the 'Destination' value in
- the table entry.
-
-
-
If the result and the 'Destination' value are the same,
- then:
-
+
+
A is logically ANDed with the 'Genmask'
+value in
+the table entry.
+
+
+
The result is compared with the 'Destination' value
+in the table entry.
+
+
+
If the result and the 'Destination' value are the
+same, then:
-
-
-
If the 'Gateway' column is non-zero, the packet is
- sent to the gateway over the interface named in the 'Iface' column.
-
-
-
-
Otherwise, the packet is sent directly to A over
- the interface named in the 'iface' column.
-
-
+
+
If the 'Gateway' column is non-zero, the packet
+is sent to the gateway over the interface named in the 'Iface' column.
+
+
+
Otherwise, the packet is sent directly to A
+ over the interface named in the 'iface' column.
+
-
-
-
Otherwise, the above steps are repeated on the next entry
- in the table.
-
-
+
+
+
Otherwise, the above steps are repeated on the next
+entry in the table.
+
-
-
Since the default route matches any IP address (A land
- 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table
- entries are sent to the default gateway which is usually a router
-at your ISP.
-
-
Lets take an example. Suppose that we want to route a packet
- to 192.168.1.5. That address clearly doesn't match any of the host
- routes in the table but if we logically and that address with 255.255.255.0,
- the result is 192.168.1.0 which matches this routing table entry:
-
-
-
+
Since the default route matches any IP address (A
+land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other
+routing table entries are sent to the default gateway which is
+usually a router
+at your ISP.
+
Lets take an example. Suppose that we want to route a
+packet to 192.168.1.5. That address clearly doesn't match any of the
+host routes in the table but if we logically and that address with
+255.255.255.0, the result is 192.168.1.0 which matches this routing
+table entry:
+
+
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
-
-
-
So to route a packet to 192.168.1.5, the packet is sent directly over eth2.
-
-
-
One more thing needs to be emphasized -- all outgoing packet
- are sent using the routing table and reply packets are not a special
- case. There seems to be a common mis-conception whereby people think
- that request packets are like salmon and contain a genetic code that
- is magically transferred to reply packets so that the replies follow
-the reverse route taken by the request. That isn't the case; the replies
-may take a totally different route back to the client than was taken by
-the requests -- they are totally independent.
-
+
+
So to route a packet to 192.168.1.5, the packet is sent directly
+over eth2.
+
+
One more thing needs to be emphasized -- all outgoing
+packet are sent using the routing table and reply packets are not a
+special case. There seems to be a common mis-conception whereby people
+think that request packets are like salmon and contain a genetic code
+that is magically transferred to reply packets so that the replies
+follow the reverse route taken by the request. That isn't the case; the
+replies may take a totally different route back to the client than was
+taken by the requests -- they are totally independent.
4.4 Address Resolution Protocol (ARP)
-
-
When sending packets over Ethernet, IP addresses aren't used.
- Rather Ethernet addressing is based on Media Access Control
- (MAC) addresses. Each Ethernet device has it's own unique MAC address
- which is burned into a PROM on the device during manufacture. You can
- obtain the MAC of an Ethernet device using the 'ip' utility:
-
-
-
+
When sending packets over Ethernet, IP addresses aren't
+used. Rather Ethernet addressing is based on Media Access Control
+(MAC) addresses. Each Ethernet device has it's own unique MAC
+address which is burned into a PROM on the device during manufacture.
+You can obtain the MAC of an Ethernet device using the 'ip' utility:
+
+
[root@gateway root]# ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100 link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0 inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 [root@gateway root]#
-
-
-
-
-
As you can see from the above output, the MAC is 6 bytes (48
- bits) wide. A card's MAC is usually also printed on a label attached to
-the card itself.
-
-
-
-
Because IP uses IP addresses and Ethernet uses MAC addresses,
- a mechanism is required to translate an IP address into a MAC address;
- that is the purpose of the Address Resolution Protocol (ARP).
- Here is ARP in action:
-
-
-
-
-
+
+
+
+
As you can see from the above output, the MAC is 6
+bytes (48 bits) wide. A card's MAC is usually also printed on a label
+attached to
+the card itself.
+
+
+
Because IP uses IP addresses and Ethernet uses MAC
+addresses, a mechanism is required to translate an IP address into a
+MAC address; that is the purpose of the Address Resolution Protocol
+(ARP). Here is ARP in action:
2 packets received by filter 0 packets dropped by kernel [root@gateway root]#
-
-
-
-
-
In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants
- to know the MAC of the device with IP address 192.168.1.19. The system
- having that IP address is responding that the MAC address of the device
- with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.
-
-
In order to avoid having to exchange ARP information each
- time that an IP packet is to be sent, systems maintain an ARP
-cache of IP<->MAC correspondences. You can see the ARP
-cache on your system (including your Windows system) using the 'arp'
+
+
+
+
In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48)
+wants to know the MAC of the device with IP address 192.168.1.19. The
+system having that IP address is responding that the MAC address of the
+device with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.
+
In order to avoid having to exchange ARP information
+each time that an IP packet is to be sent, systems maintain an ARP
+cache of IP<->MAC correspondences. You can see the ARP
+cache on your system (including your Windows system) using the 'arp'
command:
-
-
-
+
+
[root@gateway root]# arp -na ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1 ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2 ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2 ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0 ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
-
-
-
-
The leading question marks are a result of my having specified
- the 'n' option (Windows 'arp' doesn't allow that option) which causes
- the 'arp' program to forego IP->DNS name translation. Had I not
-given that option, the question marks would have been replaced with
-the FQDN corresponding to each IP address. Notice that the last entry
-in the table records the information we saw using tcpdump above.
-
+
+
+
The leading question marks are a result of my having
+specified the 'n' option (Windows 'arp' doesn't allow that option)
+which causes the 'arp' program to forego IP->DNS name translation.
+Had I not
+given that option, the question marks would have been replaced with
+the FQDN corresponding to each IP address. Notice that the last entry
+in the table records the information we saw using tcpdump above.
4.5 RFC 1918
-
IP addresses are allocated by the Internet Assigned Number Authority(IANA)
- who delegates allocations on a geographic basis to Regional Internet
- Registries (RIRs). For example, allocation for the Americas and
- for sub-Sahara Africa is delegated to the American Registry for Internet Numbers
- (ARIN). These RIRs may in turn delegate to national registries.
- Most of us don't deal with these registrars but rather get our IP addresses
- from our ISP.
-
-
It's a fact of life that most of us can't afford as many Public
- IP addresses as we have devices to assign them to so we end up making use
-of Private IP addresses. RFC 1918 reserves several IP address ranges
-for this purpose:
-
-
+who delegates allocations on a geographic basis to Regional
+Internet Registries (RIRs). For example, allocation for the
+Americas and for sub-Sahara Africa is delegated to the American Registry for Internet Numbers(ARIN).
+These RIRs may in turn delegate to national registries. Most of us
+don't deal with these registrars but rather get our IP addresses from
+our ISP.
+
It's a fact of life that most of us can't afford as
+many Public IP addresses as we have devices to assign them to so we end
+up making use
+of Private IP addresses. RFC 1918 reserves several IP address
+ranges
+for this purpose:
The addresses reserved by RFC 1918 are sometimes referred
- to as non-routable because the Internet backbone routers
-don't forward packets which have an RFC-1918 destination address.
-This is understandable given that anyone can select any of these
-addresses for their private use.
-
-
-
-
When selecting addresses from these ranges, there's a couple
- of things to keep in mind:
-
-
-
+
+
+
The addresses reserved by RFC 1918 are sometimes
+referred to as non-routable because the Internet backbone
+routers
+don't forward packets which have an RFC-1918 destination address.
+This is understandable given that anyone can select any of these
+addresses for their private use.
+
+
+
When selecting addresses from these ranges, there's a
+couple of things to keep in mind:
+
+
-
-
As the IPv4 address space becomes depleted, more and more
- organizations (including ISPs) are beginning to use RFC 1918 addresses
- in their infrastructure.
-
-
-
You don't want to use addresses that are being used by
- your ISP or by another organization with whom you want to establish
- a VPN relationship.
-
-
+
+
As the IPv4 address space becomes depleted, more
+and more organizations (including ISPs) are beginning to use RFC 1918
+addresses in their infrastructure.
+
+
+
You don't want to use addresses that are being used
+by your ISP or by another organization with whom you want to establish
+a VPN relationship.
+
-
-
-
-
So it's a good idea to check with your ISP to see if they
- are using (or are planning to use) private addresses before you
-decide the addresses that you are going to use.
-
-
-
+
+
+
So it's a good idea to check with your ISP to see if
+they are using (or are planning to use) private addresses before you
+decide the addresses that you are going to use.
+
+
5.0 Setting up your Network
-
-
-
-
The choice of how to set up your network depends primarily
- on how many Public IP addresses you have vs. how many addressable
- entities you have in your network. Regardless of how many addresses
- you have, your ISP will handle that set of addresses in one of two
- ways:
-
-
-
+
+
+
The choice of how to set up your network depends
+primarily on how many Public IP addresses you have vs. how many
+addressable entities you have in your network. Regardless of how many
+addresses you have, your ISP will handle that set of addresses in one
+of two ways:
+
+
-
-
Routed - Traffic to any of your addresses will
- be routed through a single gateway address. This will generally
- only be done if your ISP has assigned you a complete subnet (/29
- or larger). In this case, you will assign the gateway address as
-the IP address of your firewall/router's external interface.
-
-
-
-
Non-routed - Your ISP will send traffic to each
- of your addresses directly.
-
-
+
+
Routed - Traffic to any of your addresses
+will be routed through a single gateway address. This will
+generally only be done if your ISP has assigned you a complete subnet
+(/29 or larger). In this case, you will assign the gateway address as
+the IP address of your firewall/router's external interface.
+
+
+
Non-routed - Your ISP will send traffic to
+each of your addresses directly.
+
-
-
-
-
In the subsections that follow, we'll look at each of these
- separately.
-
-
+
+
+
In the subsections that follow, we'll look at each of
+these separately.
+
Before we begin, there is one thing for you to check:
-
- If you are using the Debian package, please check your
-shorewall.conf file to ensure that the following are set correctly;
-if they are not, change them appropriately:
-
-
+ height="13" alt=""> If you are using the Debian
+package, please check your
+shorewall.conf file to ensure that the following are set correctly;
+if they are not, change them appropriately:
+
-
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
-
IP_FORWARDING=On
-
-
+
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
+
IP_FORWARDING=On
+
-
-
-
+
+
5.1 Routed
-
-
-
-
Let's assume that your ISP has assigned you the subnet 192.0.2.64/28
- routed through 192.0.2.65. That means that you have IP addresses
-192.0.2.64 - 192.0.2.79 and that your firewall's external IP address is
- 192.0.2.65. Your ISP has also told you that you should use a netmask
- of 255.255.255.0 (so your /28 is part of a larger /24). With this many
- IP addresses, you are able to subnet your /28 into two /29's and set
- up your network as shown in the following diagram.
-
-
-
-
-
-
-
-
-
Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local
- network is 192.0.2.72/29. The default gateway for hosts in the DMZ would
-be configured to 192.0.2.66 and the default gateway for hosts in the local
- network would be 192.0.2.73.
-
-
-
-
Notice that this arrangement is rather wasteful of public
- IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
- addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses
- and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
- Nevertheless, it shows how subnetting can work and if we were dealing
- with a /24 rather than a /28 network, the use of 6 IP addresses
-out of 256 would be justified because of the simplicity of the setup.
-
-
-
-
The astute reader may have noticed that the Firewall/Router's
- external interface is actually part of the DMZ subnet (192.0.2.64/29).
- What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65?
- The routing table on DMZ 1 will look like this:
-
-
-
-
+
+
+
Let's assume that your ISP has assigned you the subnet
+192.0.2.64/28 routed through 192.0.2.65. That means that you have IP
+addresses 192.0.2.64 - 192.0.2.79 and that your firewall's external IP
+address is 192.0.2.65. Your ISP has also told you that you should use a
+netmask of 255.255.255.0 (so your /28 is part of a larger /24). With
+this many IP addresses, you are able to subnet your /28 into two /29's
+and set up your network as shown in the following diagram.
+
+
+
+
+
+
Here, the DMZ comprises the subnet 192.0.2.64/29 and
+the Local network is 192.0.2.72/29. The default gateway for hosts in
+the DMZ would
+be configured to 192.0.2.66 and the default gateway for hosts in the
+local network would be 192.0.2.73.
+
+
+
Notice that this arrangement is rather wasteful of
+public IP addresses since it is using 192.0.2.64 and 192.0.2.72 for
+subnet addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast
+addresses and 192.0.2.66 and 168.0.2.73 for internal addresses on the
+firewall/router. Nevertheless, it shows how subnetting can work and if
+we were dealing with a /24 rather than a /28 network, the use of 6 IP
+addresses
+out of 256 would be justified because of the simplicity of the setup.
+
+
+
The astute reader may have noticed that the
+Firewall/Router's external interface is actually part of the DMZ subnet
+(192.0.2.64/29). What if DMZ 1 (192.0.2.67) tries to communicate with
+192.0.2.65? The routing table on DMZ 1 will look like this:
+
+
+
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0 0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0
-
-
-
-
-
This means that DMZ 1 will send an ARP "who-has 192.0.2.65"
- request and no device on the DMZ Ethernet segment has that IP address.
- Oddly enough, the firewall will respond to the request with the
-MAC address of its DMZ Interface!! DMZ 1 can then send Ethernet
- frames addressed to that MAC address and the frames will be received
- (correctly) by the firewall/router.
-
-
-
-
It is this rather unexpected ARP behavior on the part of the
- Linux Kernel that prompts the warning earlier in this guide regarding the
- connecting of multiple firewall/router interfaces to the same hub or switch.
- When an ARP request for one of the firewall/router's IP addresses is sent
-by another system connected to the hub/switch, all of the firewall's
- interfaces that connect to the hub/switch can respond! It is then
- a race as to which "here-is" response reaches the sender first.
-
-
-
+
+
+
+
This means that DMZ 1 will send an ARP "who-has
+192.0.2.65" request and no device on the DMZ Ethernet segment has that
+IP address. Oddly enough, the firewall will respond to the request with
+the
+MAC address of its DMZ Interface!! DMZ 1 can then send Ethernet
+frames addressed to that MAC address and the frames will be received
+(correctly) by the firewall/router.
+
+
+
It is this rather unexpected ARP behavior on the part
+of the Linux Kernel that prompts the warning earlier in this guide
+regarding the connecting of multiple firewall/router interfaces to the
+same hub or switch. When an ARP request for one of the
+firewall/router's IP addresses is sent
+by another system connected to the hub/switch, all of the firewall's
+interfaces that connect to the hub/switch can respond! It is then a
+race as to which "here-is" response reaches the sender first.
+
+
5.2 Non-routed
-
-
-
-
If you have the above situation but it is non-routed, you
-can configure your network exactly as described above with one additional
- twist; simply specify the "proxyarp" option on all three firewall
- interfaces in the /etc/shorewall/interfaces file.
-
-
-
-
Most of us don't have the luxury of having enough public IP
- addresses to set up our networks as shown in the preceding example (even
-if the setup is routed).
-
-
-
-
For the remainder of this section, assume that your ISP
- has assigned you IP addresses 192.0.2.176-180 and has told you
-to use netmask 255.255.255.0 and default gateway 192.0.2.254.
-
-
-
-
Clearly, that set of addresses doesn't comprise a subnetwork
- and there aren't enough addresses for all of the network interfaces.
- There are four different techniques that can be used to work around
- this problem.
-
-
-
+
+
+
If you have the above situation but it is non-routed,
+you
+can configure your network exactly as described above with one
+additional twist; simply specify the "proxyarp" option on all three
+firewall interfaces in the /etc/shorewall/interfaces file.
+
+
+
Most of us don't have the luxury of having enough
+public IP addresses to set up our networks as shown in the preceding
+example (even
+if the setup is routed).
+
+
+
For the remainder of this section, assume that your
+ISP has assigned you IP addresses 192.0.2.176-180 and has told you
+to use netmask 255.255.255.0 and default gateway 192.0.2.254.
+
+
+
Clearly, that set of addresses doesn't comprise a
+subnetwork and there aren't enough addresses for all of the network
+interfaces. There are four different techniques that can be used to
+work around this problem.
+
+
-
-
Source Network Address Translation (SNAT).
-
-
-
+
+
Source Network Address Translation (SNAT).
+
+
Destination Network Address Translation (DNAT)
- also known as Port Forwarding.
-
-
-
Proxy ARP.
-
-
-
Network Address Translation (NAT) also referred
- to as Static NAT.
-
-
+also known as Port Forwarding.
+
+
+
Proxy ARP.
+
+
+
Network Address Translation (NAT) also
+referred to as Static NAT.
+
-
-
-
-
Often a combination of these techniques is used. Each of these
- will be discussed in the sections that follow.
-
-
-
-
5.2.1 SNAT
-
-
-
-
With SNAT, an internal LAN segment is configured using RFC
- 1918 addresses. When a host A on this internal segment initiates
- a connection to host B on the internet, the firewall/router
- rewrites the IP header in the request to use one of your public
-IP addresses as the source address. When B responds and the
-response is received by the firewall, the firewall changes the destination
-address back to the RFC 1918 address of A and forwards the response
-back to A.
-
-
-
-
Let's suppose that you decide to use SNAT on your local zone
- and use public address 192.0.2.176 as both your firewall's external
- IP address and the source IP address of internet requests sent from
- that zone.
-
-
-
-
-
-
-
-
The local zone has been subnetted as 192.168.201.0/29
- (netmask 255.255.255.248).
-
-
-
-
- The systems in the local zone would be configured with
- a default gateway of 192.168.201.1 (the IP address of the firewall's
- local interface).
Often a combination of these techniques is used. Each
+of these will be discussed in the sections that follow.
+
+
+
5.2.1 SNAT
+
+
+
With SNAT, an internal LAN segment is configured using
+RFC 1918 addresses. When a host A on this internal segment
+initiates a connection to host B on the internet, the
+firewall/router rewrites the IP header in the request to use one of
+your public
+IP addresses as the source address. When B responds and the
+response is received by the firewall, the firewall changes the
+destination address back to the RFC 1918 address of A and
+forwards the response back to A.
+
+
+
Let's suppose that you decide to use SNAT on your local
+zone and use public address 192.0.2.176 as both your firewall's
+external IP address and the source IP address of internet requests sent
+from that zone.
+
+
+
+
+
The local zone has been subnetted as
+192.168.201.0/29 (netmask 255.255.255.248).
+
+
The systems in the local
+zone would be configured with a default gateway of 192.168.201.1 (the
+IP address of the firewall's local interface).
This example used the normal technique of assigning the same
- public IP address for the firewall external interface and for SNAT.
- If you wanted to use a different IP address, you would either have
- to use your distributions network configuration tools to add that
-IP address to the external interface or you could set ADD_SNAT_ALIASES=Yes
- in /etc/shorewall/shorewall.conf and Shorewall will add the address for
- you.
-
-
-
+
+
+
+
This example used the normal technique of assigning the
+same public IP address for the firewall external interface and for
+SNAT. If you wanted to use a different IP address, you would either
+have to use your distributions network configuration tools to add that
+IP address to the external interface or you could set
+ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf and Shorewall
+will add the address for you.
+
+
5.2.2 DNAT
-
-
-
-
When SNAT is used, it is impossible for hosts on the internet
- to initiate a connection to one of the internal systems since those
- systems do not have a public IP address. DNAT provides a way to
-allow selected connections from the internet.
-
-
-
+
+
+
When SNAT is used, it is impossible for hosts on the
+internet to initiate a connection to one of the internal systems since
+those systems do not have a public IP address. DNAT provides a way to
+allow selected connections from the internet.
+
+
- Suppose that your daughter wants to run a web server
- on her system "Local 3". You could allow connections to the internet
- to her server by adding the following entry in /etc/shorewall/rules:
-
-
-
-
+ height="13"> Suppose that your daughter wants
+to run a web server on her system "Local 3". You could allow
+connections to the internet to her server by adding the following entry
+in /etc/shorewall/rules:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL DESTINATION
-
-
-
DNAT
-
net
-
loc:192.168.201.4
-
tcp
-
www
-
-
-
192.0.2.176
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL DESTINATION
+
+
+
DNAT
+
net
+
loc:192.168.201.4
+
tcp
+
www
+
-
+
192.0.2.176
+
+
-
-
-
-
-
If one of your daughter's friends at address A wants
- to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external
- IP address) and the firewall will rewrite the destination IP address
- to 192.168.201.4 (your daughter's system) and forward the request.
- When your daughter's server responds, the firewall will rewrite the
- source address back to 192.0.2.176 and send the response back to A.
-
-
-
-
This example used the firewall's external IP address for DNAT.
- You can use another of your public IP addresses but Shorewall will not
-add that address to the firewall's external interface for you.
-
-
-
+
+
+
+
If one of your daughter's friends at address A
+wants to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's
+external IP address) and the firewall will rewrite the destination IP
+address to 192.168.201.4 (your daughter's system) and forward the
+request. When your daughter's server responds, the firewall will
+rewrite the source address back to 192.0.2.176 and send the response
+back to A.
+
+
+
This example used the firewall's external IP address
+for DNAT. You can use another of your public IP addresses but Shorewall
+will not
+add that address to the firewall's external interface for you.
+
+
5.2.3 Proxy ARP
-
-
-
+
+
The idea behind proxy ARP is that:
-
-
-
+
+
-
-
A host H behind your firewall is assigned one of
-your public IP addresses (A) and is assigned the same netmask
- (M) as the firewall's external interface.
-
-
-
The firewall responds to ARP "who has" requests for A.
-
-
-
-
When H issues an ARP "who has" request for an address
- in the subnetwork defined by A and M, the firewall will
-respond (with the MAC if the firewall interface to H).
-
-
+
+
A host H behind your firewall is assigned
+one of
+your public IP addresses (A) and is assigned the same netmask (M)
+ as the firewall's external interface.
+
+
+
The firewall responds to ARP "who has" requests for
+ A.
+
+
+
When H issues an ARP "who has" request for
+an address in the subnetwork defined by A and M, the
+firewall will
+respond (with the MAC if the firewall interface to H).
+
-
-
-
-
Let suppose that we decide to use Proxy ARP on the DMZ in
- our example network.
-
-
-
-
-
-
-
-
Here, we've assigned the IP addresses 192.0.2.177 to
- system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned
- an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface
- on the firewall. That address and netmask isn't relevant - just
-be sure it doesn't overlap another subnet that you've defined.
-
-
-
-
- The Shorewall configuration of Proxy ARP is done using
- the /etc/shorewall/proxyarp
- file.
-
-
-
+
+
+
Let suppose that we decide to use Proxy ARP on the DMZ
+in our example network.
+
+
+
+
+
Here, we've assigned the IP addresses 192.0.2.177 to
+system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned
+an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface
+on the firewall. That address and netmask isn't relevant - just
+be sure it doesn't overlap another subnet that you've defined.
Because the HAVE ROUTE column contains No, Shorewall will
- add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
-
-
-
The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
- to have the IP addresses shown but should have the same default gateway
- as the firewall itself -- namely 192.0.2.254. In other words, they should
- be configured just like they would be if they were parallel to the firewall
- rather than behind it.
-
-
-
NOTE: Do not add the Proxy ARP'ed address(es)
- (192.0.2.177 and 192.0.2.178 in the above example) to the external interface
- (eth0 in this example) of the firewall.
-
-
-
-
-
-
+
+
+
+
Because the HAVE ROUTE column contains No, Shorewall
+will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
+
+
The ethernet interfaces on DMZ 1 and DMZ 2 should be
+configured to have the IP addresses shown but should have the same
+default gateway as the firewall itself -- namely 192.0.2.254. In other
+words, they should be configured just like they would be if they were
+parallel to the firewall rather than behind it.
+
+
NOTE: Do not add the Proxy ARP'ed
+address(es) (192.0.2.177 and 192.0.2.178 in the above example) to
+the external interface (eth0 in this example) of the firewall.
+
+
+
+
-
-
-
-
-
A word of warning is in order here. ISPs typically configure
- their routers with a long ARP cache timeout. If you move a system
- from parallel to your firewall to behind your firewall with Proxy
-ARP, it will probably be HOURS before that system can communicate with
-the internet. There are a couple of things that you can try:
-
-
+
+
+
+
A word of warning is in order here. ISPs typically
+configure their routers with a long ARP cache timeout. If you move a
+system from parallel to your firewall to behind your firewall with
+Proxy
+ARP, it will probably be HOURS before that system can communicate with
+the internet. There are a couple of things that you can try:
+
-
(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
- Illustrated, Vol 1 reveals that a
-
- "gratuitous" ARP packet should cause the ISP's router to refresh
- their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
- the MAC address for its own IP; in addition to ensuring that the IP
-address isn't a duplicate,...
-
- "if the host sending the gratuitous ARP has just changed its
-hardware address..., this packet causes any other host...that has an
-entry in its cache for the old hardware address to update its ARP cache
-entry accordingly."
-
- Which is, of course, exactly what you want to do when you switch
- a host from being exposed to the Internet to behind Shorewall using proxy
- ARP (or static NAT for that matter). Happily enough, recent versions
-of Redhat's iputils package include "arping", whose "-U" flag does just
+
(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
+Illustrated, Vol 1 reveals that a
+
+"gratuitous" ARP packet should cause the ISP's router to refresh their
+ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
+the MAC address for its own IP; in addition to ensuring that the IP
+address isn't a duplicate,...
+
+"if the host sending the gratuitous ARP has just changed its hardware
+address..., this packet causes any other host...that has an entry in
+its cache for the old hardware address to update its ARP cache entry
+accordingly."
+
+Which is, of course, exactly what you want to do when you switch a host
+from being exposed to the Internet to behind Shorewall using proxy ARP
+(or static NAT for that matter). Happily enough, recent versions
+of Redhat's iputils package include "arping", whose "-U" flag does just
that:
-
- arping -U -I <net if> <newly
- proxied IP>
- arping -U -I eth0 66.58.99.83 #
-for example
-
- Stevens goes on to mention that not all systems respond correctly
- to gratuitous ARPs, but googling for "arping -U" seems to support the
- idea that it works most of the time.
-
-
-
You can call your ISP and ask them to purge the stale
- ARP cache entry but many either can't or won't purge individual
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens goes on to mention that not all systems respond correctly to
+gratuitous ARPs, but googling for "arping -U" seems to support the idea
+that it works most of the time.
+
+
+
You can call your ISP and ask them to purge the stale ARP cache
+entry but many either can't or won't purge individual
entries.
-
- You can determine if your ISP's gateway ARP cache is stale
- using ping and tcpdump. Suppose that we suspect that the gateway
-router has a stale ARP cache entry for 192.0.2.177. On the firewall,
-run tcpdump as follows:
-
-
+You can determine if your ISP's gateway ARP cache is stale using ping
+and tcpdump. Suppose that we suspect that the gateway
+router has a stale ARP cache entry for 192.0.2.177. On the firewall,
+run tcpdump as follows:
+
tcpdump -nei eth0 icmp
-
-
-
-
Now from 192.0.2.177, ping the ISP's gateway (which we
- will assume is 192.0.2.254):
-
-
-
+
+
+
Now from 192.0.2.177, ping the ISP's gateway (which we
+will assume is 192.0.2.254):
Notice that the source MAC address in the echo request is
- different from the destination MAC address in the echo reply!!
-In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0
-NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other
-words, the gateway's ARP cache still associates 192.0.2.177 with
-the NIC in DMZ 1 rather than with the firewall's eth0.
-
-
-
+
+
+
Notice that the source MAC address in the echo request
+is different from the destination MAC address in the echo reply!!
+In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0
+NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other
+words, the gateway's ARP cache still associates 192.0.2.177 with
+the NIC in DMZ 1 rather than with the firewall's eth0.
+
+
5.2.4 Static NAT
-
-
-
-
With static NAT, you assign local systems RFC 1918 addresses
- then establish a one-to-one mapping between those addresses and
-public IP addresses. For outgoing connections SNAT (Source Network
-Address Translation) occurs and on incoming connections DNAT (Destination
- Network Address Translation) occurs. Let's go back to our earlier example
- involving your daughter's web server running on system Local 3.
-
-
-
+
+
+
With static NAT, you assign local systems RFC 1918
+addresses then establish a one-to-one mapping between those addresses
+and
+public IP addresses. For outgoing connections SNAT (Source Network
+Address Translation) occurs and on incoming connections DNAT
+(Destination Network Address Translation) occurs. Let's go back to our
+earlier example involving your daughter's web server running on system
+Local 3.
+
+
-
-
-
-
-
Recall that in this setup, the local network is using SNAT
- and is sharing the firewall external IP (192.0.2.176) for outbound
- connections. This is done with the following entry in /etc/shorewall/masq:
-
-
-
-
+ height="635">
+
+
+
Recall that in this setup, the local network is using
+SNAT and is sharing the firewall external IP (192.0.2.176) for outbound
+connections. This is done with the following entry in
+/etc/shorewall/masq:
With this entry in place, you daughter has her own IP address
- and the other two local systems share the firewall's IP address.
-
-
-
+
+
+
+
With this entry in place, you daughter has her own IP
+address and the other two local systems share the firewall's IP address.
+
+
- Once the relationship between 192.0.2.179 and 192.168.201.4
- is established by the nat file entry above, it is no longer appropriate
- to use a DNAT rule for you daughter's web server -- you would rather
- just use an ACCEPT rule:
-
-
-
-
+ height="13"> Once the relationship between
+192.0.2.179 and 192.168.201.4 is established by the nat file entry
+above, it is no longer appropriate to use a DNAT rule for you
+daughter's web server -- you would rather just use an ACCEPT rule:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL DESTINATION
-
-
-
ACCEPT
-
net
-
loc:192.168.201.4
-
tcp
-
www
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL DESTINATION
+
+
+
ACCEPT
+
net
+
loc:192.168.201.4
+
tcp
+
www
+
+
+
+
-
-
-
-
-
-
-
A word of warning is in order here. ISPs typically configure
- their routers with a long ARP cache timeout. If you move a system
- from parallel to your firewall to behind your firewall with static
- NAT, it will probably be HOURS before that system can communicate
-with the internet. There are a couple of things that you can try:
-
-
+
+
+
+
+
+
A word of warning is in order here. ISPs typically
+configure their routers with a long ARP cache timeout. If you move a
+system from parallel to your firewall to behind your firewall with
+static NAT, it will probably be HOURS before that system can
+communicate
+with the internet. There are a couple of things that you can try:
+
-
(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
- Illustrated, Vol 1 reveals that a
-
- "gratuitous" ARP packet should cause the ISP's router to refresh
- their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
- the MAC address for its own IP; in addition to ensuring that the IP
-address isn't a duplicate,...
-
- "if the host sending the gratuitous ARP has just changed its
-hardware address..., this packet causes any other host...that has an
-entry in its cache for the old hardware address to update its ARP cache
-entry accordingly."
-
- Which is, of course, exactly what you want to do when you switch
- a host from being exposed to the Internet to behind Shorewall using proxy
- ARP (or static NAT for that matter). Happily enough, recent versions
-of Redhat's iputils package include "arping", whose "-U" flag does just
+
(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
+Illustrated, Vol 1 reveals that a
+
+"gratuitous" ARP packet should cause the ISP's router to refresh their
+ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
+the MAC address for its own IP; in addition to ensuring that the IP
+address isn't a duplicate,...
+
+"if the host sending the gratuitous ARP has just changed its hardware
+address..., this packet causes any other host...that has an entry in
+its cache for the old hardware address to update its ARP cache entry
+accordingly."
+
+Which is, of course, exactly what you want to do when you switch a host
+from being exposed to the Internet to behind Shorewall using proxy ARP
+(or static NAT for that matter). Happily enough, recent versions
+of Redhat's iputils package include "arping", whose "-U" flag does just
that:
-
- arping -U -I <net if> <newly
- proxied IP>
- arping -U -I eth0 66.58.99.83 #
-for example
-
- Stevens goes on to mention that not all systems respond correctly
- to gratuitous ARPs, but googling for "arping -U" seems to support the
- idea that it works most of the time.
-
-
-
You can call your ISP and ask them to purge the stale ARP cache
- entry but many either can't or won't purge individual entries.
-
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens goes on to mention that not all systems respond correctly to
+gratuitous ARPs, but googling for "arping -U" seems to support the idea
+that it works most of the time.
+
+
+
You can call your ISP and ask them to purge the stale ARP cache
+entry but many either can't or won't purge individual entries.
- You can determine if your ISP's gateway ARP cache is stale
- using ping and tcpdump. Suppose that we suspect that the gateway
-router has a stale ARP cache entry for 209.0.2.179. On the firewall,
-run tcpdump as follows:
-
-
+You can determine if your ISP's gateway ARP cache is stale using ping
+and tcpdump. Suppose that we suspect that the gateway
+router has a stale ARP cache entry for 209.0.2.179. On the firewall,
+run tcpdump as follows:
+
tcpdump -nei eth0 icmp
-
-
-
-
Now from the 192.168.201.4, ping the ISP's gateway (which
- we will assume is 192.0.2.254):
-
-
-
+
+
+
Now from the 192.168.201.4, ping the ISP's gateway
+(which we will assume is 192.0.2.254):
Notice that the source MAC address in the echo request is
- different from the destination MAC address in the echo reply!!
-In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0
-NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other
-words, the gateway's ARP cache still associates 192.0.2.179 with
-the NIC in the local zone rather than with the firewall's eth0.
-
-
+
+
+
Notice that the source MAC address in the echo request
+is different from the destination MAC address in the echo reply!!
+In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0
+NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other
+words, the gateway's ARP cache still associates 192.0.2.179 with
+the NIC in the local zone rather than with the firewall's eth0.
+
5.3 Rules
-
-
-
+
+
- With the default policies, your local systems (Local
- 1-3) can access any servers on the internet and the DMZ can't access
- any other host (including the firewall). With the exception of
-DNAT rules which cause address translation and allow
- the translated connection request to pass through the firewall,
-the way to allow connection requests through your firewall is to
-use ACCEPT rules.
-
-
-
-
NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't
- used in this section, they won't be shown
-
-
-
+ height="13"> With the default policies, your local
+systems (Local 1-3) can access any servers on the internet and the DMZ
+can't access any other host (including the firewall). With the
+exception of
+DNAT rules which cause address translation and
+allow the translated connection request to pass through the firewall,
+the way to allow connection requests through your firewall is to
+use ACCEPT rules.
+
+
+
NOTE: Since the SOURCE PORT and ORIG. DEST. Columns
+aren't used in this section, they won't be shown
+
+
You probably want to allow ping between your zones:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
-
-
ACCEPT
-
net
-
dmz
-
icmp
-
echo-request
-
-
-
ACCEPT
-
net
-
loc
-
icmp
-
echo-request
-
-
-
ACCEPT
-
dmz
-
loc
-
icmp
-
echo-request
-
-
-
ACCEPT
-
loc
-
dmz
-
icmp
-
echo-request
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
+
+
ACCEPT
+
net
+
dmz
+
icmp
+
echo-request
+
+
+
ACCEPT
+
net
+
loc
+
icmp
+
echo-request
+
+
+
ACCEPT
+
dmz
+
loc
+
icmp
+
echo-request
+
+
+
ACCEPT
+
loc
+
dmz
+
icmp
+
echo-request
+
+
-
-
-
-
-
Let's suppose that you run mail and pop3 servers on DMZ 2
- and a Web Server on DMZ 1. The rules that you would need are:
-
-
-
-
+
+
+
+
Let's suppose that you run mail and pop3 servers on DMZ
+2 and a Web Server on DMZ 1. The rules that you would need are:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
COMMENTS
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
pop3
-
# Pop3 from the Internet
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Local Network
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.178
-
tcp
-
pop3
-
# Pop3 from the Local Network
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Firewall
-
-
-
ACCEPT
-
dmz:192.0.2.178
-
net
-
tcp
-
smtp
-
# Mail to the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
tcp
-
http
-
# WWW from the Net
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
tcp
-
https
-
# Secure HTTP from the Net
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.177
-
tcp
-
https
-
# Secure HTTP from the Local Net
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
COMMENTS
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
pop3
+
# Pop3 from the Internet
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Local Network
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.178
+
tcp
+
pop3
+
# Pop3 from the Local Network
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Firewall
+
+
+
ACCEPT
+
dmz:192.0.2.178
+
net
+
tcp
+
smtp
+
# Mail to the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
tcp
+
http
+
# WWW from the Net
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
tcp
+
https
+
# Secure HTTP from the Net
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.177
+
tcp
+
https
+
# Secure HTTP from the Local Net
+
+
-
-
-
-
-
If you run a public DNS server on 192.0.2.177, you would need
- to add the following rules:
-
-
-
-
+
+
+
+
If you run a public DNS server on 192.0.2.177, you
+would need to add the following rules:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
COMMENTS
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from the internet
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from firewall
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from firewall
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from the local Net
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from the local Net
-
-
-
ACCEPT
-
dmz:192.0.2.177
-
net
-
udp
-
domain
-
# UDP DNS to the Internet
-
-
-
ACCEPT
-
dmz:192.0.2.177
-
net
-
tcp
-
domain
-
# TCP DNS to the Internet
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
COMMENTS
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from the internet
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from firewall
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from firewall
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from the local Net
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from the local Net
+
+
+
ACCEPT
+
dmz:192.0.2.177
+
net
+
udp
+
domain
+
# UDP DNS to the Internet
+
+
+
ACCEPT
+
dmz:192.0.2.177
+
net
+
tcp
+
domain
+
# TCP DNS to the Internet
+
+
-
-
-
-
-
You probably want some way to communicate with your firewall
- and DMZ systems from the local network -- I recommend SSH which
-through its scp utility can also do publishing and software update
+
+
+
+
You probably want some way to communicate with your
+firewall and DMZ systems from the local network -- I recommend SSH
+which
+through its scp utility can also do publishing and software update
distribution.
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
COMMENTS
-
-
-
ACCEPT
-
loc
-
dmz
-
tcp
-
ssh
-
# SSH to the DMZ
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
ssh
-
# SSH to the Firewall
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
COMMENTS
+
+
+
ACCEPT
+
loc
+
dmz
+
tcp
+
ssh
+
# SSH to the DMZ
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
ssh
+
# SSH to the Firewall
+
+
-
-
-
-
+
+
+
5.4 Odds and Ends
-
-
-
-
The above discussion reflects my personal preference for using
- Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I
-prefer to use NAT only in cases where a system that is part of an RFC 1918
-subnet needs to have it's own public IP.
-
-
-
+
+
+
The above discussion reflects my personal preference
+for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local
+systems. I
+prefer to use NAT only in cases where a system that is part of an RFC
+1918
+subnet needs to have it's own public IP.
+
+
- If you haven't already, it would be a good idea to
-browse through /etc/shorewall/shorewall.conf
- just to see if there is anything there that might be of interest.
- You might also want to look at the other configuration files that
- you haven't touched yet just to get a feel for the other things that
- Shorewall can do.
-
-
-
-
In case you haven't been keeping score, here's the final set
- of configuration files for our sample network. Only those that were modified
- from the original installation are shown.
-
-
-
-
/etc/shorewall/interfaces (The "options" will be very site-specific).
-
-
-
-
+ height="13"> If you haven't already, it would be a
+good idea to
+browse through /etc/shorewall/shorewall.conf
+just to see if there is anything there that might be of interest. You
+might also want to look at the other configuration files that you
+haven't touched yet just to get a feel for the other things that
+Shorewall can do.
+
+
+
In case you haven't been keeping score, here's the
+final set of configuration files for our sample network. Only those
+that were modified from the original installation are shown.
+
+
+
/etc/shorewall/interfaces (The "options" will be very
+site-specific).
+
+
+
-
-
-
Zone
-
Interface
-
Broadcast
-
Options
-
-
-
net
-
eth0
-
detect
-
norfc1918,routefilter
-
-
-
loc
-
eth1
-
detect
-
-
-
-
dmz
-
eth2
-
detect
-
-
-
-
+
+
+
Zone
+
Interface
+
Broadcast
+
Options
+
+
+
net
+
eth0
+
detect
+
norfc1918,routefilter
+
+
+
loc
+
eth1
+
detect
+
+
+
+
dmz
+
eth2
+
detect
+
+
+
-
-
-
-
-
The setup described here requires that your network interfaces
- be brought up before Shorewall can start. This opens a short window
- during which you have no firewall protection. If you replace 'detect'
- with the actual broadcast addresses in the entries above, you can
- bring up Shorewall before you bring up your network interfaces.
-
-
-
-
+
+
+
+
The setup described here requires that your network
+interfaces be brought up before Shorewall can start. This opens a short
+window during which you have no firewall protection. If you replace
+'detect' with the actual broadcast addresses in the entries above, you
+can bring up Shorewall before you bring up your network interfaces.
+
+
+
-
-
-
Zone
-
Interface
-
Broadcast
-
Options
-
-
-
net
-
eth0
-
192.0.2.255
-
norfc1918,routefilter
-
-
-
loc
-
eth1
-
192.168.201.7
-
-
-
-
dmz
-
eth2
-
192.168.202.7
-
-
-
-
+
+
+
Zone
+
Interface
+
Broadcast
+
Options
+
+
+
net
+
eth0
+
192.0.2.255
+
norfc1918,routefilter
+
+
+
loc
+
eth1
+
192.168.201.7
+
+
+
+
dmz
+
eth2
+
192.168.202.7
+
+
+
-
-
-
-
+
+
+
/etc/shorewall/masq - Local subnet
-
-
-
-
+
+
+
-
-
-
INTERFACE
-
SUBNET
-
ADDRESS
-
-
-
eth0
-
192.168.201.0/29
-
192.0.2.176
-
-
-
+
+
+
INTERFACE
+
SUBNET
+
ADDRESS
+
+
+
eth0
+
192.168.201.0/29
+
192.0.2.176
+
+
-
-
-
-
+
+
+
/etc/shorewall/proxyarp - DMZ
-
-
-
-
+
+
+
-
-
-
ADDRESS
-
INTERFACE
-
EXTERNAL
-
HAVE ROUTE
-
-
-
192.0.2.177
-
eth2
-
eth0
-
No
-
-
-
192.0.2.178
-
eth2
-
eth0
-
No
-
-
-
+
+
+
ADDRESS
+
INTERFACE
+
EXTERNAL
+
HAVE ROUTE
+
+
+
192.0.2.177
+
eth2
+
eth0
+
No
+
+
+
192.0.2.178
+
eth2
+
eth0
+
No
+
+
-
-
-
-
+
+
+
/etc/shorewall/nat- Daughter's System
-
-
-
-
+
+
+
-
-
-
EXTERNAL
-
INTERFACE
-
INTERNAL
-
ALL INTERFACES
-
LOCAL
-
-
-
192.0.2.179
-
eth0
-
192.168.201.4
-
No
-
No
-
-
-
+
+
+
EXTERNAL
+
INTERFACE
+
INTERNAL
+
ALL INTERFACES
+
LOCAL
+
+
+
192.0.2.179
+
eth0
+
192.168.201.4
+
No
+
No
+
+
-
-
-
-
+
+
+
/etc/shorewall/rules
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
COMMENTS
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
pop3
-
# Pop3 from the Internet
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Local Network
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.178
-
tcp
-
pop3
-
# Pop3 from the Local Network
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.178
-
tcp
-
smtp
-
# Mail from the Firewall
-
-
-
ACCEPT
-
dmz:192.0.2.178
-
net
-
tcp
-
smtp
-
# Mail to the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
http
-
# WWW from the Net
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.178
-
tcp
-
https
-
# Secure HTTP from the Net
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.178
-
tcp
-
https
-
# Secure HTTP from the Local Net
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from the Internet
-
-
-
ACCEPT
-
net
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from the internet
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from firewall
-
-
-
ACCEPT
-
fw
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from firewall
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.177
-
udp
-
domain
-
# UDP DNS from the local Net
-
-
-
ACCEPT
-
loc
-
dmz:192.0.2.177
-
tcp
-
domain
-
# TCP DNS from the local Net
-
-
-
ACCEPT
-
dmz:192.0.2.177
-
net
-
udp
-
domain
-
# UDP DNS to the Internet
-
-
-
ACCEPT
-
dmz:192.0.2.177
-
net
-
tcp
-
domain
-
# TCP DNS to the Internet
-
-
-
ACCEPT
-
net
-
dmz
-
icmp
-
echo-request
-
# Ping
-
-
-
ACCEPT
-
net
-
loc
-
icmp
-
echo-request
-
# "
-
-
-
ACCEPT
-
dmz
-
loc
-
icmp
-
echo-request
-
# "
-
-
-
ACCEPT
-
loc
-
dmz
-
icmp
-
echo-request
-
# "
-
-
-
ACCEPT
-
loc
-
dmz
-
tcp
-
ssh
-
# SSH to the DMZ
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
ssh
-
# SSH to the Firewall
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
COMMENTS
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
pop3
+
# Pop3 from the Internet
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Local Network
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.178
+
tcp
+
pop3
+
# Pop3 from the Local Network
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.178
+
tcp
+
smtp
+
# Mail from the Firewall
+
+
+
ACCEPT
+
dmz:192.0.2.178
+
net
+
tcp
+
smtp
+
# Mail to the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
http
+
# WWW from the Net
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.178
+
tcp
+
https
+
# Secure HTTP from the Net
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.178
+
tcp
+
https
+
# Secure HTTP from the Local Net
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from the Internet
+
+
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from the internet
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from firewall
+
+
+
ACCEPT
+
fw
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from firewall
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.177
+
udp
+
domain
+
# UDP DNS from the local Net
+
+
+
ACCEPT
+
loc
+
dmz:192.0.2.177
+
tcp
+
domain
+
# TCP DNS from the local Net
+
+
+
ACCEPT
+
dmz:192.0.2.177
+
net
+
udp
+
domain
+
# UDP DNS to the Internet
+
+
+
ACCEPT
+
dmz:192.0.2.177
+
net
+
tcp
+
domain
+
# TCP DNS to the Internet
+
+
+
ACCEPT
+
net
+
dmz
+
icmp
+
echo-request
+
# Ping
+
+
+
ACCEPT
+
net
+
loc
+
icmp
+
echo-request
+
# "
+
+
+
ACCEPT
+
dmz
+
loc
+
icmp
+
echo-request
+
# "
+
+
+
ACCEPT
+
loc
+
dmz
+
icmp
+
echo-request
+
# "
+
+
+
ACCEPT
+
loc
+
dmz
+
tcp
+
ssh
+
# SSH to the DMZ
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
ssh
+
# SSH to the Firewall
+
+
-
-
-
-
+
+
+
6.0 DNS
-
-
-
-
Given the collection of RFC 1918 and public addresses in this
- setup, it only makes sense to have separate internal and external DNS
-servers. You can combine the two into a single BIND 9 server using Views.
- If you are not interested in Bind 9 views, you can
+
Suppose that your domain is foobar.net and you want the two
- DMZ systems named www.foobar.net and mail.foobar.net and you want
- the three local systems named "winken.foobar.net, blinken.foobar.net
- and nod.foobar.net. You want your firewall to be known as firewall.foobar.net
- externally and it's interface to the local network to be know as
-gateway.foobar.net and its interface to the dmz as dmz.foobar.net.
-Let's have the DNS server on 192.0.2.177 which will also be known
+
+
+
Suppose that your domain is foobar.net and you want the
+two DMZ systems named www.foobar.net and mail.foobar.net and you want
+the three local systems named "winken.foobar.net, blinken.foobar.net
+and nod.foobar.net. You want your firewall to be known as
+firewall.foobar.net externally and it's interface to the local network
+to be know as
+gateway.foobar.net and its interface to the dmz as dmz.foobar.net.
+Let's have the DNS server on 192.0.2.177 which will also be known
by the name ns1.foobar.net.
# # This is the view presented to our internal systems #
view "internal" { # # These are the clients that see this view # match-clients { 192.168.201.0/29; 192.168.202.0/29; 127.0.0.0/8; 192.0.2.176/32; 192.0.2.178/32; 192.0.2.179/32; 192.0.2.180/32; }; # # If this server can't complete the request, it should use outside # servers to do so # recursion yes;
zone "." in { type hint; file "int/root.cache"; };
zone "foobar.net" in { type master; notify no; allow-update { none; }; file "int/db.foobar"; };
zone "0.0.127.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.127.0.0"; };
zone "201.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.201"; };
zone "202.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.202"; };
zone "176.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.176"; }; (or status NAT for that matter) zone "177.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.177"; };
zone "178.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.178"; };
zone "179.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.206.124.146.179"; };
}; # # This is the view that we present to the outside world # view "external" { match-clients { any; }; # # If we can't answer the query, we tell the client so # recursion no;
zone "foobar.net" in { type master; notify yes; allow-update {none; }; allow-transfer { <secondary NS IP>; }; file "ext/db.foobar"; };
zone "176.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; allow-transfer { <secondary NS IP>; }; file "db.192.0.2.176"; };
zone "177.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; allow-transfer { <secondary NS IP>; }; file "db.192.0.2.177"; };
zone "178.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; allow-transfer { <secondary NS IP>; }; file "db.192.0.2.178"; };
zone "179.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; allow-transfer { <secondary NS IP>; }; file "db.192.0.2.179"; }; };
-
-
-
-
-
-
Here are the files in /var/named (those not shown are usually
- included in your bind disbribution).
-
-
db.192.0.2.176 - This is the reverse zone for the firewall's
- external interface
-
-
+
+
+
+
+
Here are the files in /var/named (those not shown are
+usually included in your bind disbribution).
+
db.192.0.2.176 - This is the reverse zone for the
+firewall's external interface
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 ; Filename: db.192.0.2.176 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
-
-
-
-
-
db.192.0.2.177 - This is the reverse zone for the www/DNS
- server
-
+
+
+
+
db.192.0.2.177 - This is the reverse zone for the
+www/DNS server
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32 ; Filename: db.192.0.2.177 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
-
-
-
-
-
-
db.192.0.2.178 - This is the reverse zone for the mail
- server
-
+
+
+
+
+
db.192.0.2.178 - This is the reverse zone for the
+mail server
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32 ; Filename: db.192.0.2.178 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
-
-
-
-
-
-
db.192.0.2.179 - This is the reverse zone for daughter's
- web server's public IP
-
+
+
+
+
+
db.192.0.2.179 - This is the reverse zone for
+daughter's web server's public IP
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32 ; Filename: db.192.0.2.179 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
-
-
-
-
-
+
+
+
+
int/db.127.0.0 - The reverse zone for localhost
-
-
-
-
+
+
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8 ; Filename: db.127.0.0 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001092901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net.
; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR localhost.foobar.net.
-
-
-
-
-
int/db.192.168.201 - Reverse zone for the local net. This
- is only shown to internal clients
-
-
-
-
+
+
+
+
int/db.192.168.201 - Reverse zone for the local net.
+This is only shown to internal clients
+
+
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29 ; Filename: db.192.168.201 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day)
; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net.
; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR gateway.foobar.net. 2 86400 IN PTR winken.foobar.net. 3 86400 IN PTR blinken.foobar.net. 4 86400 IN PTR nod.foobar.net.
-
-
-
-
-
int/db.192.168.202 - Reverse zone for the firewall's DMZ
- interface
-
-
-
-
-
+
+
+
+
int/db.192.168.202 - Reverse zone for the firewall's
+DMZ interface
+
+
+
+
; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29 ; Filename: db.192.168.202 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day)
; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net.
; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR dmz.foobar.net.
-
-
-
-
-
-
int/db.foobar - Forward zone for use by internal clients.
-
-
-
-
+
+
+
+
+
int/db.foobar - Forward zone for use by internal
+clients.
+
+
+
;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002071501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; foobar.net Nameserver Records (NS) ;############################################################ @ 604800 IN NS ns1.foobar.net.
;############################################################ ; Foobar.net Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1
firewall 86400 IN A 192.0.2.176 www 86400 IN A 192.0.2.177 ns1 86400 IN A 192.0.2.177 www 86400 IN A 192.0.2.177
gateway 86400 IN A 192.168.201.1 winken 86400 IN A 192.168.201.2 blinken 86400 IN A 192.168.201.3 nod 86400 IN A 192.168.201.4
-
-
-
-
+
+
+
ext/db.foobar - Forward zone for external clients
-
-
-
-
-
+
+
+
+
;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002052901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; Foobar.net Nameserver Records (NS) ;############################################################ @ 86400 IN NS ns1.foobar.net. @ 86400 IN NS <secondary NS>. ;############################################################ ; Foobar.net Foobar Wa Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 ; ; The firewall itself ; firewall 86400 IN A 192.0.2.176 ; ; The DMZ ; ns1 86400 IN A 192.0.2.177 www 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 ; ; The Local Network ; nod 86400 IN A 192.0.2.179
;############################################################ ; Current Aliases for foobar.net (CNAME) ;############################################################
;############################################################ ; foobar.net MX Records (MAIL EXCHANGER) ;############################################################ foobar.net. 86400 IN A 192.0.2.177 86400 IN MX 0 mail.foobar.net. 86400 IN MX 1 <backup MX>.
The firewall is started using the "shorewall start" command
- and stopped using "shorewall stop". When the firewall is stopped,
- routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A
- running firewall may be restarted using the "shorewall restart"
-command. If you want to totally remove any trace of Shorewall from
-your Netfilter configuration, use "shorewall clear".
The firewall is started using the "shorewall start"
+command and stopped using "shorewall stop". When the firewall is
+stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped.
+A running firewall may be restarted using the "shorewall restart"
+command. If you want to totally remove any trace of Shorewall from
+your Netfilter configuration, use "shorewall clear".
+
+
- Edit the /etc/shorewall/routestopped file and configure
- those systems that you want to be able to access the firewall when
- it is stopped.
-
-
-
-
WARNING: If you are connected to your firewall from
- the internet, do not issue a "shorewall stop" command unless you
- have added an entry for the IP address that you are connected from
- to /etc/shorewall/routestopped.
- Also, I don't recommend using "shorewall restart"; it is better to create
- an alternate configuration
- and test it using the "shorewall
- try" command.
-
-
+ height="13"> Edit the /etc/shorewall/routestopped
+file and configure those systems that you want to be able to access the
+firewall when it is stopped.
+
+
+
WARNING: If you are connected to your firewall
+from the internet, do not issue a "shorewall stop" command unless you
+have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped.
+Also, I don't recommend using "shorewall restart"; it is better to
+create an alternate
+configuration and test it using the "shorewall try" command.
The Shoreline Firewall, more commonly known as "Shorewall", is
- a Netfilter (iptables)
- based firewall that can be used on a dedicated
- firewall system, a multi-function gateway/router/server
- or on a standalone GNU/Linux system.
-
-
-
-
-
-
-
This program is free software; you can redistribute it and/or modify
-
- it under the terms of Version 2 of the
-GNU General Public License as published by the Free Software
- Foundation.
-
-
-
- This program is distributed
- in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without
- even the implied warranty of MERCHANTABILITY
- or FITNESS FOR A PARTICULAR PURPOSE.
- See the GNU General Public License for more details.
-
-
-
- You should have received a
- copy of the GNU General Public License
- along with this program; if not,
- write to the Free Software Foundation,
- Inc., 675 Mass Ave, Cambridge, MA 02139,
- USA
Netfilter - the
+packet filter facility built into the 2.4 and later Linux kernels.
+
ipchains - the packet filter facility built into the 2.2
+Linux kernels. Also the name of the utility program used to configure
+and control that facility. Netfilter can be used in ipchains
+compatibility mode.
+
+
iptables - the utility program used to configure and
+control
+Netfilter. The term 'iptables' is often used to refer to the
+combination of iptables+Netfilter (with Netfilter not in
+ipchains compatibility mode).
+
+
+The
+Shoreline Firewall, more commonly known as "Shorewall", is
+high-level tool for configuring Netfilter. You describe your
+firewall/gateway requirements using entries in a set of configuration
+files. Shorewall reads those configuration files and with the help of
+the iptables utility, Shorewall configures Netfilter to match your
+requirements. Shorewall can be used on a dedicated firewall system, a
+multi-function gateway/router/server or on a standalone GNU/Linux
+system. Shorewall does not use Netfilter's ipchains compatibility mode
+and can thus take advantage of Netfilter's connection state tracking
+capabilities.
+
This program is free software; you can redistribute it and/or
+modify it under the terms of Version 2 of the
+GNU General Public License as published by the Free Software
+Foundation.
+
+This program is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc.,
+675 Mass Ave, Cambridge, MA 02139, USA
- New to Shorewall? Start by selecting
- the QuickStart
- Guide that most closely match your environment and
-follow the step by step instructions.
-
+New to Shorewall? Start by
+selecting the QuickStart Guide
+that most closely match your environment and
+follow the step by step instructions.
Looking for Information?
- The Documentation
- Index is a good place to start as is the Quick Search to your right.
-
+The Documentation
+Index is a good place to start as is the Quick Search to your
+right.
Running Shorewall on Mandrake with a two-interface setup?
- If so, the documentationon this site
-will not apply directly to your setup. If you want to use the documentation
- that you find here, you will want to consider uninstalling what you
-have and installing a setup that matches the documentation on
-this site. See the Two-interface QuickStart
- Guide for details.
-
+If so, the documentationon this site will not apply directly
+to your setup. If you want to
+use the documentation that you find here, you will want to consider
+uninstalling what you have and installing a setup that matches the
+documentation on this site. See the Two-interface
+QuickStart Guide for
+details.
-
-
-
-
A problem seen on RH7.3 systems where Shorewall encountered
- start errors when started using the "service" mechanism has been worked
- around.
-
+
Corrected problem in 1.4.6 where the MANGLE_ENABLED
+variable was being tested before it was set.
+
Corrected handling of MAC addresses in the SOURCE column of
+the tcrules file. Previously, these addresses resulted in an invalid
+iptables command.
+
The
+"shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled exists. This prevents people from
+shooting themselves in the foot prior to having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages
+during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being added to a PPP interface; the addresses were successfully added
+in spite of the messages.
+
+The firewall script has been modified to eliminate the error messages
-
Where a list of IP addresses appears in the DEST column of
-a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
- nat table (one for each element in the list). Shorewall now correctly creates
- a single DNAT rule with multiple "--to-destination" clauses.
-
-
-
Corrected a problem in Beta 1 where DNS names containing a
-"-" were mis-handled when they appeared in the DEST column of a rule.
-
-
-
A number of problems with rule parsing have been corrected.
- Corrections involve the handling of "z1!z2" in the SOURCE column as well
-as lists in the ORIGINAL DESTINATION column.
-
-
-
The message "Adding rules for DHCP" is now suppressed if there
-are no DHCP rules to add.
-
-
Migration Issues:
-
-
+ Migration Issues:
-
In earlier versions, an undocumented feature allowed entries
- in the host file as follows:
-
- z eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6
- to allow entries of the following format:
-
- z eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
-have been removed from /etc/shorewall/shorewall.conf. These capabilities
-are now automatically detected by Shorewall (see below).
-
-
+
Once you have installed this version of Shorewall, you must
+restart Shorewall before you may use the 'drop', 'reject', 'allow' or
+'save' commands.
+
To maintain strict compatibility with previous versions,
+current uses of "shorewall drop" and "shorewall reject" should be
+replaced with "shorewall dropall" and "shorewall rejectall"
-
-
New Features:
-
-
+ New Features:
-
A 'newnotsyn' interface option has been added. This option
- may be specified in /etc/shorewall/interfaces and overrides the setting
- NEWNOTSYN=No for packets arriving on the associated interface.
-
-
-
The means for specifying a range of IP addresses in /etc/shorewall/masq
- to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
- address ranges.
-
-
-
Shorewall can now add IP addresses to subnets other than
- the first one on an interface.
-
-
-
DNAT[-] rules may now be used to load balance (round-robin)
- over a set of servers. Servers may be specified in a range of addresses
- given as <first address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
-
-
-
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
- options have been removed and have been replaced by code that detects
-whether these capabilities are present in the current kernel. The output
-of the start, restart and check commands have been enhanced to report the
-outcome:
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
Support for the Connection Tracking Match Extension has
- been added. This extension is available in recent kernel/iptables releases
- and allows for rules which match against elements in netfilter's connection
- tracking table. Shorewall automatically detects the availability of this
- extension and reports its availability in the output of the start, restart
- and check commands.
-
- Shorewall has detected the following iptables/netfilter capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by Shorewall
- is changed in the following ways:
-
-
-
To handle 'norfc1918' filtering, Shorewall will not
-create chains in the mangle table but will rather do all 'norfc1918'
-filtering in the filter table (rfc1918 chain).
-
Recall that Shorewall DNAT rules generate two netfilter
- rules; one in the nat table and one in the filter table. If the Connection
- Tracking Match Extension is available, the rule in the filter table is
-extended to check that the original destination address was the same as
-specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
- may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
An 'ipcalc' command has been added to /sbin/shorewall.
-
- ipcalc [ <address> <netmask> | <address>/<vlsm>
- ]
-
- Examples:
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0/24
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
- CIDR=192.168.1.0/24
- NETMASK=255.255.255.0
- NETWORK=192.168.1.0
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or dash),
- then the ipcalc command produces incorrect information for IP addresses
- 128.0.0.0-1 and for /1 networks. Bash should produce correct information
- for all valid IP addresses.
-
-
-
An 'iprange' command has been added to /sbin/shorewall.
-
-
- iprange <address>-<address>
-
- This command decomposes a range of IP addressses into a list of network
- and host addresses. The command can be useful if you need to construct
-an efficient set of rules that accept connections from a range of network
-addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic (ash or
- dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
A list of host/net addresses is now allowed in an entry
- in /etc/shorewall/hosts.
-
- Example:
-
- foo eth1:192.168.1.0/24,192.168.2.0/24
+
Shorewall now creates a dynamic blacklisting chain for each
+interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
+commands use the routing table to determine which of these chains is to
+be used for blacklisting the specified IP address(es).
+Two new commands ('dropall' and 'rejectall') have been introduced that
+do what 'drop' and 'reject' used to do; namely, when an address is
+blacklisted using these new commands, it will be blacklisted on all of
+your firewall's interfaces.
+
Thanks to Steve Herber, the 'help' command can now give
+command-specific help (e.g., shorewall help <command>).
+
A new option "ADMINISABSENTMINDED" has been added to
+/etc/shorewall/shorewall.conf. This option has a default value of "No"
+for existing users which causes Shorewall's 'stopped' state to
+continue as it has been; namely, in the stopped state only traffic
+to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+With ADMINISABSENTMINDED=Yes (the default for new installs), in
+addition to traffic to/from the hosts listed in
+/etc/shorewall/routestopped, Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+loc:192.168.1.5 tcp 22
+ ACCEPT loc
+fw tcp 22
+
+From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+connection with local system 192.168.1.5. I then create a second SSH
+connection
+from that computer to the firewall and confidently type "shorewall
+stop".
+As part of its stop processing, Shorewall removes eth0:0 which kills my
+SSH
+connection to 192.168.1.5!!!
+
Given
+the wide range of VPN software, I can never hope to add specific
+support for all of it. I have therefore decided to add "generic" tunnel
+support.
+
+Generic tunnels work pretty much like any of the other tunnel types.
+You usually add a zone to represent the systems at the other end of the
+tunnel and you add the appropriate rules/policies to
+implement your security policy regarding traffic to/from those systems.
+
+In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+generic:<protocol>[:<port>] <zone> <ip
+address> <gateway zones>
+
+where:
+
+ <protocol> is the protocol
+used by the tunnel
+ <port> if the protocol
+is 'udp' or 'tcp' then this is the destination port number used by the
+tunnel.
+ <zone> is the zone of
+the remote tunnel gateway
+ <ip address> is the IP
+address of the remote tunnel gateway.
+ <gateway zone>
+Optional. A comma-separated list of zone
+names. If specified, the remote gateway is to be considered part of
+these zones.
+
An 'arp_filter' option has been added to the
+/etc/shorewall/interfaces file. This option causes
+/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+result that this interface will only answer ARP 'who-has' requests from
+hosts that are routed out through that interface. Setting this option
+facilitates testing of your firewall where multiple firewall interfaces
+are connected to the same HUB/Switch (all interfaces connected to the
+single HUB/Switch should have this option specified). Note that using
+such a configuration in a production environment is strongly
+recommended against.
-
The "shorewall check" command now includes the chain
-name when printing the applicable policy for each pair of zones.
-
- Example:
-
- Policy for dmz to net is REJECT using chain all2all
-
- This means that the policy for connections from the dmz to the internet
-is REJECT and the applicable entry in the /etc/shorewall/policy was the all->all
-policy.
-
-
-
Support for the 2.6 Kernel series has been added.
-
The command "shorewall debug try <directory>"
- now correctly traces the attempt.
-
The INCLUDE directive now works properly in the
-zones file; previously, INCLUDE in that file was ignored.
-
/etc/shorewall/routestopped records with an empty
- second column are no longer ignored.
-
-
-
+
Previously, if TC_ENABLED is set to yes in shorewall.conf
+then Shorewall would fail to start with the error "ERROR: Traffic
+Control requires Mangle"; that problem has been corrected.
+
Corrected handling of MAC addresses in the SOURCE column of
+the
+tcrules file. Previously, these addresses resulted in an invalid
+iptables
+command.
+
The "shorewall stop" command is now disabled when
+/etc/shorewall/startup_disabled
+exists. This prevents people from shooting themselves in the foot prior
+to
+having configured Shorewall.
+
A change introduced in version 1.4.6 caused error messages
+during
+"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
+being
+added to a PPP interface; the addresses were successfully added in
+spite
+of the messages.
+
+The firewall script has been modified to eliminate the error messages.
-
-
-
New Features:
-
-
-
-
-
The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-]
- rule may now contain a list of addresses. If the list begins with "!'
- then the rule will take effect only if the original destination address
- in the connection request does not match any of the addresses listed.
-
-
-
-
-
-
6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
-
- The firewall at shorewall.net has been upgraded to the 2.4.21
- kernel and iptables 1.2.8 (using the "official" RPM from netfilter.org).
- No problems have been encountered with this set of software. The Shorewall
- version is 1.4.4b plus the accumulated changes for 1.4.5.
-
-
-
6/8/2003 - Updated Samples
-
-
-
Thanks to Francesca Smith, the samples have been updated to Shorewall
- version 1.4.4.
-
- Jacques Nilo and Eric
- Wolzak have a LEAF (router/firewall/gateway
- on a floppy, CD or compact flash) distribution
- called Bering that
- features Shorewall-1.4.2 and Kernel-2.4.20.
- You can find their work at:
- http://leaf.sourceforge.net/devel/jnilo
-
- Congratulations to Jacques
- and Eric on the recent release of Bering
- 1.2!!!
-
-
-
-
+ alt="(Leaf Logo)"> Jacques Nilo and Eric Wolzak have a LEAF
+(router/firewall/gateway on a floppy, CD or compact flash) distribution
+called Bering that features Shorewall-1.4.2 and Kernel-2.4.20.
+You can find their work at:
+http://leaf.sourceforge.net/devel/jnilo
+ Congratulations to Jacques and Eric on the recent release of
+Bering 1.2!!!
Setting up Shorewall on a standalone Linux system is very
- easy if you understand the basics and follow the documentation.
-
-
This guide doesn't attempt to acquaint you with all of the features of
- Shorewall. It rather focuses on what is required to configure Shorewall
- in one of its most common configurations:
-
+
Setting up Shorewall on a standalone Linux system is
+very easy if you understand the basics and follow the documentation.
+
This guide doesn't attempt to acquaint you with all of the features
+of Shorewall. It rather focuses on what is required to configure
+Shorewall in one of its most common configurations:
-
Linux system
-
Single external IP address
-
Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
-
+
Linux system
+
Single external IP address
+
Connection through Cable Modem, DSL, ISDN, Frame Relay,
+dial-up...
-
-
Shorewall requires that you have the iproute/iproute2 package installed
- (on RedHat, the package is called iproute). You can tell
- if this package is installed by the presence of an ip program on
- your firewall system. As root, you can use the 'which' command to check
- for this program:
-
+
Shorewall requires that you have the iproute/iproute2 package
+installed (on RedHat, the package is called iproute). You
+can tell if this package is installed by the presence of an ip
+program
+on your firewall system. As root, you can use the 'which' command to
+check for this program:
[root@gateway root]# which ip /sbin/ip [root@gateway root]#
-
-
I recommend that you read through the guide first to familiarize yourself
- with what's involved then go back through it again making your configuration
- changes. Points at which configuration changes are recommended are flagged
- with
- .
-
+
I recommend that you read through the guide first to familiarize
+yourself with what's involved then go back through it again making your
+configuration changes. Points at which configuration changes are
+recommended are
+flagged with .
- If you edit your configuration files on a Windows system, you
- must save them as Unix files if your editor supports that option or you
- must run them through dos2unix before trying to use them. Similarly, if
- you copy a configuration file from your Windows hard drive to a floppy
-disk, you must run dos2unix against the copy before using it with Shorewall.
-
+ If you edit your configuration files on a Windows
+system,
+you must save them as Unix files if your editor supports that option
+or you must run them through dos2unix before trying to use them.
+Similarly,
+if you copy a configuration file from your Windows hard drive to a
+floppy disk, you must run dos2unix against the copy before using it
+with Shorewall.
+ If you
+have an ADSL Modem and you use PPTP to communicate with a server in
+that modem, you must make the changes
+recommended here in addition to those described in the steps below.
+ADSL with PPTP is most commonly found in Europe, notably in Austria.
Shorewall Concepts
-
- The configuration files for Shorewall are contained in the directory
- /etc/shorewall -- for simple setups, you only need to deal with a few
-of these as described in this guide. After you have installed Shorewall, download the one-interface sample,
- un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall
- (they will replace files with the same names that were placed in /etc/shorewall
- during Shorewall installation).
-
-
As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration instructions
- and default entries.
-
-
Shorewall views the network where it is running as being composed of a
- set of zones. In the one-interface sample configuration, only
-one zone is defined:
-
+ alt=""> The configuration files for Shorewall are
+contained in the directory /etc/shorewall -- for simple setups, you
+only need to deal with a few of these as described in this guide. After
+you have installed Shorewall, download
+the one-interface
+sample, un-tar it (tar -zxvf one-interface.tgz) and and copy the
+files to /etc/shorewall (they will replace files with the same names
+that were placed in /etc/shorewall during Shorewall installation).
+
As each file is introduced, I suggest that you look through the
+actual file on your system -- each file contains detailed configuration
+instructions and default entries.
+
Shorewall views the network where it is running as being composed of
+a set of zones. In the one-interface sample configuration, only
+one zone is defined:
For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that file
- matches the connection request then the first policy in /etc/shorewall/policy
- that matches the request is applied. If that policy is REJECT or DROP
- the request is first checked against the rules in /etc/shorewall/common
- (the samples provide that file for you).
-
-
The /etc/shorewall/policy file included with the one-interface sample has
-the following policies:
-
-
+
For each connection request entering the firewall, the request is
+first checked against the /etc/shorewall/rules file. If no rule in that
+file matches the connection request then the first policy in
+/etc/shorewall/policy that matches the request is applied. If that
+policy is REJECT or DROP the request is first checked against the
+rules in /etc/shorewall/common (the samples provide that file for you).
+
The /etc/shorewall/policy file included with the one-interface
+sample
+has the following policies:
+
-
-
-
SOURCE ZONE
-
DESTINATION ZONE
-
POLICY
-
LOG LEVEL
-
LIMIT:BURST
-
-
-
fw
-
net
-
ACCEPT
-
-
-
-
-
net
-
all
-
-
DROP
-
info
-
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
+
+
+
SOURCE ZONE
+
DESTINATION ZONE
+
POLICY
+
LOG LEVEL
+
LIMIT:BURST
+
+
+
fw
+
net
+
ACCEPT
+
+
+
+
+
net
+
all
+
+
DROP
+
info
+
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
-
-
+
The above policy will:
-
-
allow all connection requests from the firewall to the internet
-
drop (ignore) all connection requests from the internet to
- your firewall
-
reject all other connection requests (Shorewall requires
-this catchall policy).
-
+
allow all connection requests from the firewall to the internet
+
drop (ignore) all connection requests from the internet
+to your firewall
+
reject all other connection requests (Shorewall requires this
+catchall policy).
-
-
At this point, edit your /etc/shorewall/policy and make any changes that
- you wish.
-
+
At this point, edit your /etc/shorewall/policy and make any changes
+that you wish.
External Interface
-
-
The firewall has a single network interface. Where Internet
- connectivity is through a cable or DSL "Modem", the External Interface
- will be the ethernet adapter (eth0) that is connected to that
-"Modem" unless you connect via Point-to-Point
-Protocol over Ethernet (PPPoE) or Point-to-Point
-Tunneling Protocol (PPTP) in which case the External
-Interface will be a ppp0. If you connect via a regular modem, your
-External Interface will also be ppp0. If you connect using ISDN,
-your external interface will be ippp0.
-
+
The firewall has a single network interface. Where
+Internet connectivity is through a cable or DSL "Modem", the External
+Interface will be the ethernet adapter (eth0) that is
+connected to that "Modem" unless you connect via Point-to-Point
+Protocol over Ethernet (PPPoE) or Point-to-Point
+Tunneling Protocol (PPTP) in which case the
+External Interface will be a ppp0. If you connect via a regular
+modem, your External Interface will also be ppp0. If you
+connect using ISDN, your external interface will be ippp0.
- The Shorewall one-interface sample configuration assumes that
-the external interface is eth0. If your configuration is different,
- you will have to modify the sample /etc/shorewall/interfaces file accordingly.
- While you are there, you may wish to review the list of options that
-are specified for the interface. Some hints:
-
+ height="13"> The Shorewall one-interface sample
+configuration assumes that the external interface is eth0. If
+your configuration is different, you will have to modify the sample
+/etc/shorewall/interfaces file accordingly. While you are there, you
+may wish to review the list of options that are specified for the
+interface. Some hints:
-
-
If your external interface is ppp0 or ippp0,
- you can replace the "detect" in the second column with "-".
-
-
-
If your external interface is ppp0 or ippp0
- or if you have a static IP address, you can remove "dhcp" from the
-option list.
-
-
+
+
If your external interface is ppp0 or ippp0,
+you can replace the "detect" in the second column with "-".
+
+
+
If your external interface is ppp0 or ippp0
+or if you have a static IP address, you can remove "dhcp" from the
+option list.
+
+
-
-
+
IP Addresses
-
-
-
-
RFC 1918 reserves several Private IP address ranges
- for use in private networks:
-
-
+
+
+
RFC 1918 reserves several Private IP address
+ranges for use in private networks:
These addresses are sometimes referred to as non-routable
- because the Internet backbone routers will not forward a packet whose
- destination address is reserved by RFC 1918. In some cases though, ISPs
- are assigning these addresses then using Network Address Translation
- to rewrite packet headers when forwarding to/from the internet.
-
+
+
These addresses are sometimes referred to as non-routable
+because the Internet backbone routers will not forward a packet whose
+destination address is reserved by RFC 1918. In some cases though,
+ISPs are assigning these addresses then using Network Address
+Translation to rewrite packet headers when forwarding to/from the
+internet.
- Before starting Shorewall, you should look at the IP address
- of your external interface and if it is one of the above ranges, you
- should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.
-
-
-
+ width="13" height="13"> Before starting
+Shorewall, you should look at the IP address of your external interface
+and if it is one of the above ranges, you should remove the 'norfc1918'
+option from the entry in /etc/shorewall/interfaces.
+
+
Enabling other Connections
-
-
-
-
If you wish to enable connections from the internet to your
- firewall, the general format is:
-
-
-
-
+
+
+
If you wish to enable connections from the internet to
+your firewall, the general format is:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
<protocol>
-
<port>
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
<protocol>
+
<port>
+
+
+
+
-
-
-
-
-
Example - You want to run a Web Server and a POP3 Server on
-your firewall system:
-
-
-
-
+
+
+
+
Example - You want to run a Web Server and a POP3
+Server
+on your firewall system:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
80
-
-
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
110
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
80
+
+
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
110
+
+
+
+
-
-
-
-
-
If you don't know what port and protocol a particular application
- uses, see here.
-
-
-
-
Important: I don't recommend enabling telnet to/from
- the internet because it uses clear text (even for login!). If you want
- shell access to your firewall from the internet, use SSH:
-
-
-
-
+
+
+
+
If you don't know what port and protocol a particular
+application uses, see here.
+
+
+
Important: I don't recommend enabling telnet
+to/from the internet because it uses clear text (even for login!). If
+you
+want shell access to your firewall from the internet, use SSH:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
22
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
22
+
+
+
+
-
-
-
-
+
+
+
- At this point, edit /etc/shorewall/rules to add other connections
- as desired.
-
-
-
+ height="13"> At this point, edit
+/etc/shorewall/rules to add other connections as desired.
+
+
Starting and Stopping Your Firewall
-
-
-
-
- The installation procedure configures
- your system to start Shorewall at system boot but beginning with Shorewall
- version 1.3.9 startup is disabled so that your system won't try to start
- Shorewall before configuration is complete. Once you have completed configuration
- of your firewall, you can enable Shorewall startup by removing the file
- /etc/shorewall/startup_disabled.
-
-
-
IMPORTANT: Users of the .deb
- package must edit /etc/default/shorewall and set 'startup=1'.
-
-
-
-
-
The firewall is started using the "shorewall start" command
- and stopped using "shorewall stop". When the firewall is stopped, routing
- is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A
- running firewall may be restarted using the "shorewall restart" command.
- If you want to totally remove any trace of Shorewall from your Netfilter
- configuration, use "shorewall clear".
-
-
-
-
WARNING: If you are connected to your firewall from
- the internet, do not issue a "shorewall stop" command unless you have
- added an entry for the IP address that you are connected from to /etc/shorewall/routestopped.
-Also, I don't recommend using "shorewall restart"; it is better to create
- an alternate configuration
- and test it using the "shorewall try" command.
The installation
+procedure configures your system to start Shorewall at system
+boot but beginning with Shorewall version 1.3.9 startup is disabled so
+that your system won't try to start Shorewall before configuration is
+complete. Once you have completed configuration of your firewall, you
+can enable Shorewall startup by removing the file
+/etc/shorewall/startup_disabled.
+
+
IMPORTANT: Users of the
+.deb package must edit /etc/default/shorewall and set 'startup=1'.
+
+
+
+
The firewall is started using the "shorewall start"
+command and stopped using "shorewall stop". When the firewall is
+stopped,
+routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped.
+A running firewall may be restarted using the "shorewall restart"
+command. If you want to totally remove any trace of Shorewall from your
+Netfilter configuration, use "shorewall clear".
+
+
+
WARNING: If you are connected to your firewall
+from the internet, do not issue a "shorewall stop" command unless you
+have added an entry for the IP address that you are connected from
+to /etc/shorewall/routestopped.
+Also, I don't recommend using "shorewall restart"; it is better to
+create an alternate
+configuration and test it using the "shorewall try" command.
If you have a permanent internet connection such as DSL or Cable,
- I recommend that you start the firewall automatically at boot.
- Once you have installed "firewall" in your init.d directory, simply
- type "chkconfig --add firewall". This will start the firewall
- in run levels 2-5 and stop it in run levels 1 and 6. If you want
-to configure your firewall differently from this default, you can
+
+
If you have a permanent internet connection such as DSL or Cable,
+ I recommend that you start the firewall automatically at boot.
+ Once you have installed "firewall" in your init.d directory, simply
+ type "chkconfig --add firewall". This will start the firewall
+ in run levels 2-5 and stop it in run levels 1 and 6. If you want
+ to configure your firewall differently from this default, you can
use the "--level" option in chkconfig (see "man chkconfig") or using
your favorite graphical run-level editor.
-
+
Important Notes:
-
-
+
+
-
Shorewall startup is disabled by default. Once you have
- configured your firewall, you can enable startup by removing the file
- /etc/shorewall/startup_disabled. Note: Users of the .deb package must
- edit /etc/default/shorewall and set 'startup=1'.
-
-
If you use dialup, you may want to start the firewall
- in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
- restart" in that script.
-
+
Shorewall startup is disabled by default. Once you
+have configured your firewall, you can enable startup by removing the
+file /etc/shorewall/startup_disabled. Note: Users of the .deb package
+must edit /etc/default/shorewall and set 'startup=1'.
+
+
If you use dialup, you may want to start the firewall
+ in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
+ restart" in that script.
+
-
+
-
-
You can manually start and stop Shoreline Firewall using the "shorewall"
- shell program:
-
+
+
You can manually start and stop Shoreline Firewall using the "shorewall"
+ shell program. Please refer to the Shorewall
+ State Diagram is shown at the bottom of this page.
+
-
shorewall start - starts the firewall
-
shorewall stop - stops the firewall
-
shorewall restart - stops the firewall (if it's
- running) and then starts it again
-
shorewall reset - reset the packet and byte counters
- in the firewall
-
shorewall clear - remove all rules and chains
-installed by Shoreline Firewall
shorewall stop - stops the firewall; the only traffic
+ permitted through the firewall is from systems listed in /etc/shorewall/routestopped
+(Beginning with version 1.4.7, if ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf
+then in addition, all existing connections are permitted and any new connections
+originating from the firewall itself are allowed).
+
shorewall restart - stops the firewall (if it's
+ running) and then starts it again
+
shorewall reset - reset the packet and byte counters
+ in the firewall
+
shorewall clear - remove all rules and chains
+ installed by Shoreline Firewall. The firewall is "wide open"
- If you include the keyword debug as the first argument,
-then a shell trace of the command is produced as in:
-
+ If you include the keyword debug as the first argument,
+ then a shell trace of the command is produced as in:
+
shorewall debug start 2> /tmp/trace
-
-
The above command would trace the 'start' command and place the trace
-information in the file /tmp/trace
-
The "shorewall" program may also be used to monitor the firewall.
-
-
-
shorewall status - produce a verbose report about the
- firewall (iptables -L -n -v)
-
shorewall show chain - produce a verbose report
- about chain (iptables -L chain -n -v)
-
shorewall show nat - produce a verbose report about
-the nat table (iptables -t nat -L -n -v)
-
shorewall show tos - produce a verbose report about
-the mangle table (iptables -t mangle -L -n -v)
-
shorewall show log - display the last 20 packet log
-entries.
-
shorewall show connections - displays the IP connections
- currently being tracked by the firewall.
-
shorewall
-show tc - displays
- information about the traffic control/shaping configuration.
-
shorewall monitor [ delay ] - Continuously display
-the firewall status, last 20 log entries and nat. When the
-log entry display changes, an audible alarm is sounded.
-
shorewall hits - Produces several reports about the
-Shorewall packet log messages in the current /var/log/messages
-file.
-
shorewall version - Displays the installed version
- number.
-
shorewall check - Performs a cursory validation of
-the zones, interfaces, hosts, rules and policy files.
-
- The "check" command is totally unsuppored
- and does not parse and validate the generated iptables commands.
-Even though the "check" command completes successfully, the configuration
- may fail to start. Problem reports that complain about errors that the 'check'
- command does not detect will not be accepted.
-
- See the recommended way to make configuration changes described
-below.
-
-
-
shorewall try configuration-directory [ timeout
- ] - Restart shorewall using the specified configuration and if
-an error occurs or if the timeout option is given and the new
-configuration has been up for that many seconds then shorewall is
-restarted using the standard configuration.
shorewall logwatch (added in version 1.3.2) - Monitors
- the LOGFILE and produces an audible alarm
-when new Shorewall messages are logged.
-
-
- Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of commands
-for dealing with IP addresses and IP address ranges:
+
+
The above command would trace the 'start' command and place the trace information
+in the file /tmp/trace
+
+
+
Beginning with version 1.4.7, shorewall can give detailed help about each
+of its commands:
+
-
shorewall ipcalc [ address mask | address/vlsm ] - displays
-the network address, broadcast address, network in CIDR notation and netmask
-corresponding to the input[s].
-
shorewall iprange address1-address2 - Decomposes the specified
-range of IP addresses into the equivalent list of network/host addresses.
-
+
shorewall help [ command | host | address ]
- Finally, the "shorewall" program may be used to dynamically alter the
- contents of a zone.
-
+
+
The "shorewall" program may also be used to monitor the firewall.
+
-
shorewall add interface[:host]zone -
- Adds the specified interface (and host if included) to the specified
-zone.
-
shorewall delete interface[:host]zone
- - Deletes the specified interface (and host if included) from
-the specified zone.
-
+
shorewall status - produce a verbose report about
+ the firewall (iptables -L -n -v)
+
shorewall show chain - produce a verbose
+report about chain (iptables -L chain
+-n -v)
+
shorewall show nat - produce a verbose report about
+ the nat table (iptables -t nat -L -n -v)
+
shorewall show tos - produce a verbose report about
+ the mangle table (iptables -t mangle -L -n -v)
+
shorewall show log - display the last 20 packet
+log entries.
+
shorewall show connections - displays the IP connections
+ currently being tracked by the firewall.
+
shorewall
+ show tc
+- displays information about the traffic control/shaping configuration.
+
shorewall monitor [ delay ] - Continuously display
+ the firewall status, last 20 log entries and nat. When the
+ log entry display changes, an audible alarm is sounded.
+
shorewall hits - Produces several reports about
+the Shorewall packet log messages in the current /var/log/messages
+ file.
+
shorewall version - Displays the installed
+version number.
+
shorewall check - Performs a cursory validation of
+ the zones, interfaces, hosts, rules and policy files.
+
+ The "check" command is totally
+ unsuppored and does not parse and validate the generated iptables
+ commands. Even though the "check" command completes successfully,
+the configuration may fail to start. Problem reports that complain about
+errors that the 'check' command does not detect will not be accepted.
+
+ See the recommended way to make configuration changes described
+ below.
+
+
+
shorewall try configuration-directory [
+ timeout ] - Restart shorewall using the specified configuration
+ and if an error occurs or if the timeout option is given
+and the new configuration has been up for that many seconds then
+shorewall is restarted using the standard configuration.
+
shorewall deny, shorewall reject, shorewall accept
+ and shorewall save implement dynamic blacklisting.
+
shorewall logwatch (added in version 1.3.2) - Monitors
+ the LOGFILE and produces an audible alarm
+when new Shorewall messages are logged.
+
-
+ Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of
+commands for dealing with IP addresses and IP address ranges:
+
+
+
shorewall ipcalc [ address mask | address/vlsm ]
+- displays the network address, broadcast address, network in CIDR notation
+ and netmask corresponding to the input[s].
+
shorewall iprange address1-address2 - Decomposes the specified
+ range of IP addresses into the equivalent list of network/host addresses.
+
+
shorewall drop <ip address list> - causes packets from
+the listed IP addresses to be silently dropped by the firewall.
+
shorewall reject <ip address list> - causes packets from
+the listed IP addresses to be rejected by the firewall.
+
shorewall allow <ip address list> - re-enables receipt
+of packets from hosts previously blacklisted by a drop or reject
+command.
+
shorewall save - save the dynamic blacklisting configuration so that
+it will be automatically restored the next time that the firewall is
+restarted.
+
show dynamic - displays the dynamic blacklisting chain.
+
+
+
+ Finally, the "shorewall" program may be used to dynamically alter the
+ contents of a zone.
+
+
+
shorewall add interface[:host]zone
+ - Adds the specified interface (and host if included) to the
+specified zone.
+
shorewall delete interface[:host]zone
+ - Deletes the specified interface (and host if included) from
+ the specified zone.
+
+
+
Examples:
-
-
shorewall add ipsec0:192.0.2.24 vpn1
- -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
- shorewall delete ipsec0:192.0.2.24
- vpn1 -- deletes the address 192.0.2.24 from interface ipsec0
- from zone vpn1
-
-
-
-
The shorewall start, shorewall restart, shorewall check, and
- shorewall try commands allow you to specify which Shorewall configuration
- to use:
-
-
+
+
shorewall add ipsec0:192.0.2.24 vpn1
+ -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
+ shorewall delete ipsec0:192.0.2.24
+ vpn1 -- deletes the address 192.0.2.24 from interface ipsec0
+ from zone vpn1
+
+
+
+
The shorewall start, shorewall restart, shorewall check, and
+ shorewall try commands allow you to specify which Shorewall configuration
+ to use:
If a configuration-directory is specified, each time that Shorewall
- is going to use a file in /etc/shorewall it will first look in the
- configuration-directory . If the file is present in the configuration-directory,
- that file will be used; otherwise, the file in /etc/shorewall will
+ shorewall try configuration-directory
+
+
+
If a configuration-directory is specified, each time that Shorewall
+ is going to use a file in /etc/shorewall it will first look in the
+ configuration-directory . If the file is present in the configuration-directory,
+ that file will be used; otherwise, the file in /etc/shorewall will
be used.
-
-
When changing the configuration of a production firewall, I recommend
- the following:
-
+
+
When changing the configuration of a production firewall, I recommend
+ the following:
+
-
mkdir /etc/test
-
cd /etc/test
-
<copy any files that you need to change
-from /etc/shorewall to . and change them here>
-
shorewall -c . check
-
<correct any errors found by check and check again>
-
mkdir /etc/test
+
cd /etc/test
+
<copy any files that you need to change
+ from /etc/shorewall to . and change them here>
+
shorewall -c . check
+
<correct any errors found by check and check again>
+
/sbin/shorewall try .
-
+
-
-
If the configuration starts but doesn't work, just "shorewall restart"
- to restore the old configuration. If the new configuration fails
-to start, the "try" command will automatically start the old one for
-you.
-
+
+
If the configuration starts but doesn't work, just "shorewall restart"
+ to restore the old configuration. If the new configuration fails
+ to start, the "try" command will automatically start the old one for
+ you.
+
When the new configuration works then just
-
+
-
cp * /etc/shorewall
-
cd
-
rm -rf /etc/test
-
+
cp * /etc/shorewall
+
cd
+
rm -rf /etc/test
+
-
+
The Shorewall State Diargram is depicted below.
-
-
+
+
-
-
-
+
+
+
-
- You will note that the commands that result in state transitions
- use the word "firewall" rather than "shorewall". That is because the
-actual transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall
- on Debian); /sbin/shorewall runs 'firewall" according to the following
-table:
-
-
+
+ You will note that the commands that result in state transitions
+ use the word "firewall" rather than "shorewall". That is because the
+actual transitions are done by /usr/share/shorewall/firewall; /sbin/shorewall
+ runs 'firewall" according to the following table:
+
+
-
-
-
shorewall start
-
-
firewall start
-
-
-
-
shorewall stop
-
-
firewall stop
-
-
-
-
shorewall restart
-
-
firewall restart
-
-
-
-
shorewall add
-
-
firewall add
-
-
-
-
shorewall delete
-
-
firewall delete
-
-
-
-
shorewall refresh
-
-
firewall refresh
-
-
-
-
shorewall try
-
-
firewall -c <new configuration> restart
- If unsuccessful then firewall start (standard configuration)
- If timeout then firewall restart (standard configuration)
-
-
-
-
+
+
+
/sbin/shorewall Command
+
+
Resulting /usr/share/shorewall/firewall Command
+
+
Effect if the Command Succeeds
+
+
+
+
shorewall start
+
+
firewall start
+
+
The system filters packets based on your current
+Shorewall Configuration
+
+
+
+
shorewall stop
+
+
firewall stop
+
+
Only traffic to/from hosts listed in /etc/shorewall/hosts
+ is passed to/from/through the firewall. For Shorewall versions beginning
+with 1.4.7, if ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf then
+in addition, all existing connections are retained and all connection requests
+from the firewall are accepted.
+
+
+
+
shorewall restart
+
+
firewall restart
+
+
Logically equivalent to "firewall stop;firewall
+start"
+
+
+
+
shorewall add
+
+
firewall add
+
+
Adds a host or subnet to a dynamic zone
+
+
+
+
shorewall delete
+
+
firewall delete
+
+
Deletes a host or subnet from a dynamic zone
+
+
+
+
shorewall refresh
+
+
firewall refresh
+
+
Reloads rules dealing with static blacklisting,
+traffic control and ECN.
+
+
+
+
shorewall clear
+
+
firewall clear
+
+
Removes all Shorewall rules, chains, addresses,
+routes and ARP entries.
+
+
+
+
shorewall try
+
+
firewall -c <new configuration>
+restart
+ If unsuccessful then firewall start (standard configuration)
+ If timeout then firewall restart (standard configuration)
+
+
- There are a number of sources of Shorewall information. Please
- try these before you post.
+ There are a number of sources of Shorewall information. Please
+ try these before you post.
-
Shorewall versions
- earlier that 1.3.0 are no longer supported.
-
More than half of the questions posted on the support
+ list have answers directly accessible from the Documentation
- Index
-
-
- The FAQ
- has solutions to more than 20 common problems.
-
-
- The Troubleshooting
- Information contains a number of tips to
- help you solve common problems.
-
- The Errata
-has links to download updated components.
-
- The Site and Mailing List Archives search facility can
- locate documents and posts about similar problems:
-
-
+ Index
+
+
+ The FAQ
+ has solutions to more than 20 common problems.
+
+
+ The Troubleshooting
+ Information contains a number of tips
+to help you solve common problems.
+
+ The Errata
+ has links to download updated components.
+
+ The Site and Mailing List Archives search facility
+can locate documents and posts about similar problems:
+
+
-
+
Site and Mailing List Archive Search
-
-
+
+
-
-
+
+
+
Problem Reporting Guidelines
-
-
+
+
-
Please remember we only
-know what is posted in your message. Do not leave out any
-information that appears to be correct, or was mentioned
- in a previous post. There have been countless posts by people
+
Please remember we only
+ know what is posted in your message. Do not leave out
+any information that appears to be correct, or was mentioned
+ in a previous post. There have been countless posts by people
who were sure that some part of their configuration was correct
- when it actually contained a small error. We tend to be skeptics
-where detail is lacking.
-
-
-
Please keep in mind that
-you're asking for free technical
-support. Any help we offer is an act of generosity, not an obligation.
- Try to make it easy for us to help you. Follow good, courteous
- practices in writing and formatting your e-mail. Provide details
+ when it actually contained a small error. We tend to be skeptics
+ where detail is lacking.
+
+
+
Please keep in mind that
+ you're asking for free technical
+ support. Any help we offer is an act of generosity, not an obligation.
+ Try to make it easy for us to help you. Follow good, courteous
+ practices in writing and formatting your e-mail. Provide details
that we need if you expect good answers. Exact quoting
of error messages, log entries, command output, and other output is
better than a paraphrase or summary.
-
-
-
- Please don't describe your environment and then
- ask us to send you custom configuration files.
- We're here to answer your questions but we can't
- do your job for you.
-
-
-
When reporting a problem,
- ALWAYS include this information:
-
-
-
-
-
-
-
the exact version of Shorewall
- you are running.
- shorewall version
-
-
-
-
-
-
-
-
-
-
-
the complete, exact output
- of
+
+ Please don't describe your environment and then
+ ask us to send you custom configuration files.
+ We're here to answer your questions but we can't
+ do your job for you.
- ip
- addr show
-
-
-
-
-
-
-
the complete, exact output
- of
-
- ip
- route show
-
-
-
-
-
-
-
-
-
+
+
When reporting a problem,
+ ALWAYS include this information:
+
-
+
-
+
+
-
THIS IS
-IMPORTANT! If your problem is
-that some type of connection to/from or through your firewall isn't working
-then please perform the following four steps:
-
- 1. /sbin/shorewall reset
-
- 2. Try making the connection that is failing.
-
- 3. /sbin/shorewall
- status > /tmp/status.txt
-
- 4. Post the /tmp/status.txt file as an attachment
-(you may compress it if you like).
-
-
-
the exact wording of any ping failure responses
-
-
-
If you installed Shorewall using one of the QuickStart
- Guides, please indicate which one.
-
-
-
If you are running Shorewall under Mandrake using
- the Mandrake installation of Shorewall, please say so.
-
-
-
+
the exact version of
+Shorewall you are running.
+
+ shorewall version
+
+
+
+
-
As a general matter, please do not edit the
-diagnostic information in an attempt to conceal
-your IP address, netmask, nameserver addresses, domain name,
-etc. These aren't secrets, and concealing them often misleads us
-(and 80% of the time, a hacker could derive them anyway from
-information contained in the SMTP headers of your post).
-
-
-
Do you see any "Shorewall" messages
- ("/sbin/shorewall show log")
- when you exercise the function that is giving you problems?
- If so, include the message(s) in your post along with a copy of
-your /etc/shorewall/interfaces file.
-
-
-
Please include any of the Shorewall configuration
- files (especially the /etc/shorewall/hosts file
- if you have modified that file) that you think are
- relevant. If you include /etc/shorewall/rules, please include
- /etc/shorewall/policy as well (rules are meaningless unless
- one also knows the policies).
-
-
-
If an error occurs when you try
-to "shorewall start", include
- a trace (See the
+
+
+
+
+
+
+
the complete, exact
+output of
+
+ ip
+ addr show
+
+
+
+
+
+
+
+
+
the complete, exact
+output of
+
+ ip
+ route show
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
THIS
+IS IMPORTANT! If your
+problem is that some type of connection to/from or through your firewall
+isn't working then please perform the following four steps:
+
+ 1. /sbin/shorewall reset
+
+ 2. Try making the connection that is failing.
+
+ 3. /sbin/shorewall
+ status > /tmp/status.txt
+
+ 4. Post the /tmp/status.txt file as an
+attachment (you may compress it if you like).
+
+
+
the exact wording of any ping failure responses
+
+
+
If you installed Shorewall using one of the QuickStart
+ Guides, please indicate which one.
+
+
+
If you are running Shorewall under Mandrake
+using the Mandrake installation of Shorewall, please say so.
+
+
+
+
+
+
+
As a general matter, please do not edit the
+ diagnostic information in an attempt to conceal
+ your IP address, netmask, nameserver addresses, domain name,
+ etc. These aren't secrets, and concealing them often misleads
+us (and 80% of the time, a hacker could derive them anyway
+from information contained in the SMTP headers of your post).
+
+
+
Do you see any "Shorewall" messages
+ ("/sbin/shorewall show log")
+ when you exercise the function that is giving you problems?
+ If so, include the message(s) in your post along with a copy of
+ your /etc/shorewall/interfaces file.
+
+
+
Please include any of the Shorewall configuration
+ files (especially the /etc/shorewall/hosts file
+ if you have modified that file) that you think are
+ relevant. If you include /etc/shorewall/rules, please include
+ /etc/shorewall/policy as well (rules are meaningless unless
+ one also knows the policies).
+
+
+
If an error occurs when you try
+ to "shorewall start", include
+ a trace (See the Troubleshooting
section for instructions).
-
-
-
The list server limits posts to 120kb
-so don't post GIFs of your network
+
+
+
The list server limits posts to 120kb
+ so don't post GIFs of your network
layout, etc. to the Mailing List -- your post will be
rejected.
When using the mailing list, please post in plain text
-
+
A growing number of MTAs serving list subscribers are
rejecting all HTML traffic. At least one MTA has gone so far as to
blacklist shorewall.net "for continuous abuse" because it has been
my policy to allow HTML in list posts!!
-
- I think that blocking all
-HTML is a Draconian way to control spam and that the ultimate
- losers here are not the spammers but the list subscribers
- whose MTAs are bouncing all shorewall.net mail. As one list
- subscriber wrote to me privately "These e-mail admin's need
- to get a (expletive deleted) life instead of trying to
-rid the planet of HTML based e-mail". Nevertheless, to allow
+
+ I think that blocking all
+ HTML is a Draconian way to control spam and that the
+ultimate losers here are not the spammers but the list subscribers
+ whose MTAs are bouncing all shorewall.net mail. As one list
+ subscriber wrote to me privately "These e-mail admin's need
+ to get a (expletive deleted) life instead of trying to
+ rid the planet of HTML based e-mail". Nevertheless, to allow
subscribers to receive list posts as must as possible, I have now
configured the list server at shorewall.net to strip all HTML from
outgoing posts.
-
- If you run your own outgoing mail server
- and it doesn't have a valid DNS PTR record, your email won't reach the
-lists unless/until the postmaster notices that your posts are being rejected.
-To avoid this problem, you should configure your MTA to forward posts to
-shorewall.net through an MTA that does have a valid PTR record (such
-as the one at your ISP).
-
-
+
+
Where to Send your Problem Report or to Ask for Help
-
-
+
+
If you run Shorewall under Bering -- please post your question or problem
- to the LEAF Users mailing
- list.
Setting up a Linux system as a firewall for a small network
- with DMZ is a fairly straight-forward task if you understand the
- basics and follow the documentation.
-
-
This guide doesn't attempt to acquaint you with all of the features of
- Shorewall. It rather focuses on what is required to configure Shorewall
- in one of its more popular configurations:
-
+
Setting up a Linux system as a firewall for a small
+network with DMZ is a fairly straight-forward task if you understand
+the basics and follow the documentation.
+
This guide doesn't attempt to acquaint you with all of the features
+of Shorewall. It rather focuses on what is required to configure
+Shorewall in one of its more popular configurations:
-
Linux system used as a firewall/router for a small
- local network.
Linux system used as a firewall/router for a small local network.
+
Single public IP address.
+
DMZ connected to a separate ethernet interface.
+
Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up,
+...
-
Here is a schematic of a typical installation.
-
-
-
-
Shorewall requires that you have the iproute/iproute2 package installed
- (on RedHat, the package is called iproute). You can
- tell if this package is installed by the presence of an ip
-program on your firewall system. As root, you can use the 'which' command
-to check for this program:
-
+ height="635">
+
Shorewall requires that you have the iproute/iproute2 package
+installed (on RedHat, the package is called iproute). You
+can tell if this package is installed by the presence of an ip
+program on your firewall system. As root, you can use the 'which'
+command to check for this program:
[root@gateway root]# which ip /sbin/ip [root@gateway root]#
-
-
I recommend that you first read through the guide to familiarize yourself
- with what's involved then go back through it again making your configuration
- changes. Points at which configuration changes are recommended
-are flagged with
- . Configuration notes that are unique to LEAF/Bering are marked with
-
-
+
I recommend that you first read through the guide to familiarize
+yourself with what's involved then go back through it again making your
+configuration changes. Points at which configuration changes are
+recommended are flagged with . Configuration notes that are unique to
+LEAF/Bering are marked with
- If you edit your configuration files on a Windows
-system, you must save them as Unix files if your editor supports
-that option or you must run them through dos2unix before trying to
-use them. Similarly, if you copy a configuration file from your Windows
-hard drive to a floppy disk, you must run dos2unix against the copy before
-using it with Shorewall.
-
+ If you edit your configuration files on a Windows
+system, you must save them as Unix files if your editor supports that
+option or you must run them through dos2unix before trying
+to use them. Similarly, if you copy a configuration file from your
+Windows hard drive to a floppy disk, you must run dos2unix against the
+copy before using it with Shorewall.
+ If you
+have an ADSL Modem and you use PPTP to communicate with a server in
+that modem, you must make the changes
+recommended here in addition to those detailed below. ADSL
+with PPTP is most commonly found in Europe, notably in Austria.
Shorewall Concepts
-
- The configuration files for Shorewall are contained in the
-directory /etc/shorewall -- for simple setups, you will only need to
-deal with a few of these as described in this guide. After you have installed Shorewall, download the three-interface
- sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy
- the files to /etc/shorewall (the files will replace files with the
- same names that were placed in /etc/shorewall when Shorewall was installed).
-
-
As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration
- instructions and default entries.
-
-
Shorewall views the network where it is running as being composed of a
- set of zones. In the three-interface sample configuration,
- the following zone names are used:
-
+ alt=""> The configuration files for Shorewall are
+contained in the directory /etc/shorewall -- for simple setups, you
+will only need
+to deal with a few of these as described in this guide. After you have
+installed Shorewall, download the three-interface
+sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the
+files to /etc/shorewall (the files will replace files with the same
+names that were placed in /etc/shorewall when Shorewall was
+installed).
+
As each file is introduced, I suggest that you look through the
+actual file on your system -- each file contains detailed configuration
+instructions and default entries.
+
Shorewall views the network where it is running as being composed of
+a set of zones. In the three-interface sample configuration,
+the following zone names are used:
For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that
- file matches the connection request then the first policy in /etc/shorewall/policy
- that matches the request is applied. If that policy is REJECT or
- DROP the request is first checked against the rules in /etc/shorewall/common
- (the samples provide that file for you).
-
-
The /etc/shorewall/policy file included with the three-interface sample
- has the following policies:
-
-
+
For each connection request entering the firewall, the request is
+first checked against the /etc/shorewall/rules file. If no rule in that
+file matches the connection request then the first policy in
+/etc/shorewall/policy that matches the request is applied. If that
+policy is REJECT
+or DROP the request is first checked against the rules in
+/etc/shorewall/common (the samples provide that file for you).
+
The /etc/shorewall/policy file included with the three-interface
+sample has the following policies:
+
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
loc
-
net
-
ACCEPT
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
loc
+
net
+
ACCEPT
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
-
-
-
-
In the three-interface sample, the line below is included but commented
- out. If you want your firewall system to have full access to servers
- on the internet, uncomment that line.
-
+
+
+
In the three-interface sample, the line below is included but
+commented out. If you want your firewall system to have full access to
+servers on the internet, uncomment that line.
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
fw
-
net
-
ACCEPT
-
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
fw
+
net
+
ACCEPT
+
+
+
+
-
-
+
The above policy will:
-
-
allow all connection requests from your local network
- to the internet
-
drop (ignore) all connection requests from the
-internet to your firewall or local network
-
optionally accept all connection requests from
-the firewall to the internet (if you uncomment the additional
-policy)
-
reject all other connection requests.
-
+
allow all connection requests from your local
+network to the internet
+
drop (ignore) all connection requests from the internet to your
+firewall or local network
+
optionally accept all connection requests from the firewall to
+the internet (if you uncomment the additional policy)
+
reject all other connection requests.
-
- At this point, edit your /etc/shorewall/policy file
- and make any changes that you wish.
-
+ At this point, edit your /etc/shorewall/policy file
+and make any changes that you wish.
Network Interfaces
-
-
-
-
The firewall has three network interfaces. Where Internet
- connectivity is through a cable or DSL "Modem", the External
-Interface will be the ethernet adapter that is connected to that
-"Modem" (e.g., eth0) unless you connect via Point-to-Point
- Protocol over Ethernet (PPPoE) or Point-to-Point
- Tunneling Protocol (PPTP) in which case the External
- Interface will be a ppp interface (e.g., ppp0). If you connect
- via a regular modem, your External Interface will also be ppp0.
- If you connect using ISDN, you external interface will be ippp0.
-
+ height="635">
+
The firewall has three network interfaces. Where
+Internet connectivity is through a cable or DSL "Modem", the External
+Interface will be the ethernet adapter that is connected to
+that "Modem" (e.g., eth0) unless you connect via Point-to-Point
+Protocol over Ethernet (PPPoE) or Point-to-Point
+Tunneling Protocol (PPTP) in which case the
+External Interface will be a ppp interface (e.g., ppp0). If you
+connect via a regular modem, your External Interface will also be ppp0.
+If you connect using ISDN, you external interface will be ippp0.
Your Local Interface will be an ethernet adapter (eth0,
- eth1 or eth2) and will be connected to a hub or switch. Your local
- computers will be connected to the same switch (note: If you have
- only a single local system, you can connect the firewall directly to
- the computer using a cross-over cable).
-
-
Your DMZ Interface will also be an ethernet adapter
- (eth0, eth1 or eth2) and will be connected to a hub or switch. Your
- DMZ computers will be connected to the same switch (note: If you
-have only a single DMZ system, you can connect the firewall directly
-to the computer using a cross-over cable).
-
+ height="13"> If your external interface is ppp0
+or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
+
Your Local Interface will be an ethernet
+adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
+Your local computers will be connected to the same switch (note: If you
+have only a single local system, you can connect the firewall directly
+to the computer using a cross-over cable).
+
Your DMZ Interface will also be an ethernet
+adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
+Your DMZ computers will be connected to the same switch (note: If
+you have only a single DMZ system, you can connect the firewall
+directly to the computer using a cross-over cable).
- Do not connect more than one interface to the
-same hub or switch (even for testing). It won't work the way that
-you expect it to and you will end up confused and believing that Shorewall
-doesn't work at all.
-
+ width="60" height="60"> Do not connect the internal and
+external interface to the same hub or switch except for testing AND you
+are running Shorewall version 1.4.7 or later. When using these
+recent
+versions, you can test using this kind of configuration if you specify
+the arp_filter
+option in /etc/shorewall/interfaces for all interfaces connected to the
+common hub/switch. Using such a setup with a production firewall is
+strongly recommended against.
- The Shorewall three-interface sample configuration
-assumes that the external interface is eth0, the local interface
-is eth1 and the DMZ interface is eth2. If your configuration
- is different, you will have to modify the sample /etc/shorewall/interfaces
- file accordingly. While you are there, you may wish to review the
-list of options that are specified for the interfaces. Some hints:
-
+ height="13"> The Shorewall three-interface sample
+configuration assumes that the external interface is eth0, the
+local interface is eth1 and the DMZ interface is eth2.
+If your configuration is different, you will have to modify the sample
+/etc/shorewall/interfaces file accordingly. While you are there, you
+may wish to review the list of options that are specified for the
+interfaces. Some hints:
-
-
If your external interface is ppp0 or ippp0,
- you can replace the "detect" in the second column with "-".
-
-
-
-
If your external interface is ppp0 or ippp0
- or if you have a static IP address, you can remove "dhcp" from
- the option list.
-
-
+
+
If your external interface is ppp0 or ippp0,
+you can replace the "detect" in the second column with "-".
+
+
+
If your external interface is ppp0 or ippp0
+or if you have a static IP address, you can remove "dhcp" from the
+option list.
+
-
IP Addresses
-
-
Before going further, we should say a few words about Internet
- Protocol (IP) addresses. Normally, your ISP will assign you
- a single Public IP address. This address may be assigned via
- the Dynamic Host Configuration Protocol (DHCP) or as part of
- establishing your connection when you dial in (standard modem) or establish
- your PPP connection. In rare cases, your ISP may assign you a static
- IP address; that means that you configure your firewall's external interface
- to use that address permanently.Regardless of how the address
- is assigned, it will be shared by all of your systems when you access
- the Internet. You will have to assign your own addresses for your internal
- network (the local and DMZ Interfaces on your firewall plus your other
-computers). RFC 1918 reserves several Private IP address ranges
-for this purpose:
-
-
+
Before going further, we should say a few words about
+Internet Protocol (IP) addresses. Normally, your ISP will
+assign
+you a single Public IP address. This address may be assigned
+via the Dynamic Host Configuration Protocol (DHCP) or as part
+of establishing your connection when you dial in (standard modem) or
+establish your PPP connection. In rare cases, your ISP may assign you
+a static IP address; that means that you configure your
+firewall's
+external interface to use that address permanently.Regardless
+of how the address is assigned, it will be shared by all of your
+systems
+when you access the Internet. You will have to assign your own
+addresses for your internal network (the local and DMZ Interfaces on
+your firewall
+plus your other computers). RFC 1918 reserves several Private IP
+address ranges for this purpose:
- Before starting Shorewall, you should look at the
- IP address of your external interface and if it is one of the above
- ranges, you should remove the 'norfc1918' option from the external
- interface's entry in /etc/shorewall/interfaces.
-
-
-
-
You will want to assign your local addresses from one
- sub-network or subnet and your DMZ addresses from another
- subnet. For our purposes, we can consider a subnet to consists of
- a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have
-a Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved
- as the Subnet Address and x.y.z.255 is reserved as the Subnet
- BroadcastAddress. In Shorewall, a subnet is described using Classless InterDomain Routing
- (CIDR) notation with consists of the subnet address followed
- by "/24". The "24" refers to the number of consecutive "1" bits
-from the left of the subnet mask.
-
-
-
+ height="13"> Before starting Shorewall, you should
+look at
+the IP address of your external interface and if it is one of
+the above ranges, you should remove the 'norfc1918' option from
+the external interface's entry in /etc/shorewall/interfaces.
+
+
+
You will want to assign your local addresses from one
+sub-network or subnet and your DMZ addresses from
+another subnet. For our purposes, we can consider a subnet to
+consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet
+will have a Subnet Mask of 255.255.255.0. The address x.y.z.0
+is reserved as the Subnet Address and x.y.z.255 is reserved
+as the Subnet BroadcastAddress. In Shorewall, a subnet
+is described using Classless
+InterDomain Routing (CIDR) notation with consists of the
+subnet address followed by "/24". The "24" refers to the number of
+consecutive "1" bits from the left of the subnet mask.
+
+
Example sub-network:
-
-
-
-
+
+
+
-
-
-
Range:
-
10.10.10.0 - 10.10.10.255
-
-
-
Subnet Address:
-
10.10.10.0
-
-
-
Broadcast Address:
-
10.10.10.255
-
-
-
CIDR Notation:
-
10.10.10.0/24
-
-
-
+
+
+
Range:
+
10.10.10.0 - 10.10.10.255
+
+
+
Subnet Address:
+
10.10.10.0
+
+
+
Broadcast Address:
+
10.10.10.255
+
+
+
CIDR Notation:
+
10.10.10.0/24
+
+
-
-
-
-
-
It is conventional to assign the internal interface either
- the first usable address in the subnet (10.10.10.1 in the above
- example) or the last usable address (10.10.10.254).
-
-
-
-
One of the purposes of subnetting is to allow all computers
- in the subnet to understand which other computers can be communicated
- with directly. To communicate with systems outside of the subnetwork,
- systems send packets through a gateway (router).
-
-
-
+
+
+
+
It is conventional to assign the internal interface
+either the first usable address in the subnet (10.10.10.1 in the above
+example) or the last usable address (10.10.10.254).
+
+
+
One of the purposes of subnetting is to allow all
+computers in the subnet to understand which other computers can be
+communicated with directly. To communicate with systems outside of the
+subnetwork, systems send packets through a gateway
+(router).
+
+
- Your local computers (Local Computers 1 &
-2) should be configured with their default gateway set
-to the IP address of the firewall's internal interface and your
-DMZ computers ( DMZ Computers 1 & 2) should be configured with
-their default gateway set to the IP address of the firewall's DMZ
-interface.
-
-
-
The foregoing short discussion barely scratches the surface
- regarding subnetting and routing. If you are interested in learning
- more about IP addressing and routing, I highly recommend "IP Fundamentals:
- What Everyone Needs to Know about Addressing & Routing",
- Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
-
-
The remainder of this quide will assume that you have configured
- your network as shown here:
-
+ height="13"> Your local computers (Local Computers
+1 & 2) should be configured with their default gateway set
+to
+the IP address of the firewall's internal interface and your DMZ
+computers ( DMZ Computers 1 & 2) should be configured with their
+default gateway set to the IP address of the firewall's DMZ
+interface.
+
+
+
The foregoing short discussion barely scratches the
+surface regarding subnetting and routing. If you are interested in
+learning more about IP addressing and routing, I highly recommend "IP
+Fundamentals: What Everyone Needs to Know about Addressing &
+Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
+
The remainder of this quide will assume that you have
+configured your network as shown here:
-
-
-
The default gateway for the DMZ computers would be 10.10.11.254
- and the default gateway for the Local computers would be 10.10.10.254.
-
-
+ height="635">
+
The default gateway for the DMZ computers would be
+10.10.11.254 and the default gateway for the Local computers would be
+10.10.10.254.
+
- WARNING: Your ISP might
- assign your external interface an RFC 1918 address. If that address is
- in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
- 1918 subnet for your local network and if it is in the 10.10.11.0/24 subnet
- then you will need to select a different RFC 1918 subnet for your DMZ.
-
-
+ height="13" alt=""> WARNING:
+Your ISP might assign your external interface an
+RFC 1918 address. If that address is in the 10.10.10.0/24 subnet then
+you will need to select a DIFFERENT RFC 1918 subnet for your local
+network and if it is in the 10.10.11.0/24 subnet then you will need to
+select a different RFC 1918 subnet for your DMZ.
+
IP Masquerading (SNAT)
-
-
The addresses reserved by RFC 1918 are sometimes referred
- to as non-routable because the Internet backbone routers don't
- forward packets which have an RFC-1918 destination address. When
-one of your local systems (let's assume local computer 1) sends a
-connection request to an internet host, the firewall must perform Network
-Address Translation (NAT). The firewall rewrites the source address
-in the packet to be the address of the firewall's external interface;
-in other words, the firewall makes it look as if the firewall itself
-is initiating the connection. This is necessary so that the destination
-host will be able to route return packets back to the firewall (remember
-that packets whose destination address is reserved by RFC 1918 can't
- be routed accross the internet). When the firewall receives a return
-packet, it rewrites the destination address back to 10.10.10.1 and forwards
-the packet on to local computer 1.
-
-
On Linux systems, the above process is often referred to as
- IP Masquerading and you will also see the term Source Network Address
- Translation (SNAT) used. Shorewall follows the convention used with
- Netfilter:
-
+
The addresses reserved by RFC 1918 are sometimes
+referred to as non-routable because the Internet backbone
+routers
+don't forward packets which have an RFC-1918 destination address.
+When one of your local systems (let's assume local computer 1) sends
+a connection request to an internet host, the firewall must perform
+Network Address Translation (NAT). The firewall rewrites the
+source address in the packet to be the address of the firewall's
+external
+interface; in other words, the firewall makes it look as if the
+firewall itself is initiating the connection. This is necessary
+so that the destination host will be able to route return packets back
+to the firewall (remember that packets whose destination address is
+reserved by RFC
+1918 can't be routed accross the internet). When the firewall receives
+a return packet, it rewrites the destination address back to 10.10.10.1
+and forwards the packet on to local computer 1.
+
On Linux systems, the above process is often referred
+to
+as IP Masquerading and you will also see the term Source
+Network
+Address Translation (SNAT) used. Shorewall follows the convention
+used
+with Netfilter:
-
-
Masquerade describes the case where you let your
- firewall system automatically detect the external interface address.
-
-
-
-
SNAT refers to the case when you explicitly specify
- the source address that you want outbound packets from your local
- network to use.
-
-
+
+
Masquerade describes the case where you let
+your firewall system automatically detect the external interface
+address.
+
+
+
SNAT refers to the case when you explicitly
+specify the source address that you want outbound packets from your
+local network to use.
+
-
-
In Shorewall, both Masquerading and SNAT are configured with
- entries in the /etc/shorewall/masq file.
-
+
In Shorewall, both Masquerading and SNAT are configured
+with entries in the /etc/shorewall/masq file.
- If your external firewall interface is eth0,
- your local interface eth1 and your DMZ interface is eth2
- then you do not need to modify the file provided with the sample. Otherwise,
- edit /etc/shorewall/masq and change it to match your configuration.
-
+ height="13"> If your external firewall interface is
+eth0, your local interface eth1 and your DMZ interface
+is eth2 then you do not need to modify the file provided with
+the sample.
+Otherwise, edit /etc/shorewall/masq and change it to match your
+configuration.
- If your external IP is static, you can enter it in
- the third column in the /etc/shorewall/masq entry if you like although
- your firewall will work fine if you leave that column empty. Entering
- your static IP in column 3 makes
- processing outgoing packets a little more efficient.
-
-
+ height="13"> If your external IP is static, you can
+enter it
+in the third column in the /etc/shorewall/masq entry if you like
+although your firewall will work fine if you leave that column empty.
+Entering your static IP in column 3 makes
+processing outgoing packets a little more efficient.
+
- If you are using the Debian package, please check your shorewall.conf
- file to ensure that the following are set correctly; if they are not,
- change them appropriately:
-
-
+ height="13" alt=""> If you are using the Debian
+package, please check your shorewall.conf file to ensure that the
+following are set correctly; if they are not, change them appropriately:
+
-
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
-
IP_FORWARDING=On
-
-
+
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
+
IP_FORWARDING=On
+
-
Port Forwarding (DNAT)
-
-
One of your goals will be to run one or more servers on your
- DMZ computers. Because these computers have RFC-1918 addresses, it
- is not possible for clients on the internet to connect directly to
- them. It is rather necessary for those clients to address their connection
- requests to your firewall who rewrites the destination address to
-the address of your server and forwards the packet to that server.
-When your server responds, the firewall automatically performs SNAT
-to rewrite the source address in the response.
-
-
The above process is called Port Forwarding or
- Destination Network Address Translation (DNAT). You configure
- port forwarding using DNAT rules in the /etc/shorewall/rules file.
-
-
The general form of a simple port forwarding rule in /etc/shorewall/rules
- is:
-
-
+
One of your goals will be to run one or more servers on
+your DMZ computers. Because these computers have RFC-1918 addresses,
+it is not possible for clients on the internet to connect directly
+to them. It is rather necessary for those clients to address their
+connection requests to your firewall who rewrites the destination
+address to the address of your server and forwards the packet to that
+server. When your server responds, the firewall automatically performs
+SNAT to rewrite the source address in the response.
+
The above process is called Port Forwarding or
+Destination Network Address Translation (DNAT). You configure port
+forwarding using DNAT rules in the /etc/shorewall/rules file.
+
The general form of a simple port forwarding rule in
+/etc/shorewall/rules is:
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
dmz:<server local ip address> [:<server
- port>]
-
<protocol>
-
<port>
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
dmz:<server local ip address> [:<server
+port>]
+
<protocol>
+
<port>
+
+
+
+
-
-
-
If you don't specify the <server port>, it is assumed to be
-the same as <port>.
-
-
Example - you run a Web Server on DMZ 2 and you want to forward incoming
- TCP port 80 to that system:
-
-
+
+
If you don't specify the <server port>, it is assumed
+to
+be the same as <port>.
+
Example - you run a Web Server on DMZ 2 and you want to forward
+incoming TCP port 80 to that system:
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
dmz:10.10.11.2
-
tcp
-
80
-
# Forward port 80
-
from the internet
-
-
-
ACCEPT
-
loc
-
dmz:10.10.11.2
-
tcp
-
80
-
#Allow connections
-
from the local network
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
dmz:10.10.11.2
+
tcp
+
80
+
# Forward port 80
+
from the internet
+
+
+
ACCEPT
+
loc
+
dmz:10.10.11.2
+
tcp
+
80
+
#Allow connections
+
from the local network
+
+
-
-
-
A couple of important points to keep in mind:
-
+
+
A couple of important points to keep in mind:
-
When you are connecting to your server from your
- local systems, you must use the server's internal IP address (10.10.11.2).
-
Many ISPs block incoming connection requests to
-port 80. If you have problems connecting to your web server, try
-the following rule and try connecting to port 5000 (e.g., connect
-to http://w.x.y.z:5000 where w.x.y.z
- is your external IP).
-
+
When you are connecting to your server from your local systems,
+you must use the server's internal IP address (10.10.11.2).
+
Many ISPs block incoming connection requests to port 80. If you
+have problems connecting to your web server,
+try the following rule and try connecting to port 5000 (e.g., connect
+to http://w.x.y.z:5000 where
+w.x.y.z is your external IP).
-
-
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
dmz:10.10.11.2:80
-
tcp
-
5000
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
dmz:10.10.11.2:80
+
tcp
+
5000
+
+
+
+
-
-
-
If you want to be able to access your server from the local network using
- your external address, then if you have a static external IP you
- can replace the loc->dmz rule above with:
-
-
+
+
If you want to be able to access your server from the local network
+using your external address, then if you have a static external IP you
+can replace the loc->dmz rule above with:
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
dmz:10.10.11.2:80
-
tcp
-
80
-
-
-
<external IP>
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
dmz:10.10.11.2:80
+
tcp
+
80
+
-
+
<external IP>
+
+
-
-
-
If you have a dynamic ip then you must ensure that your external interface
- is up before starting Shorewall and you must take steps as follows
- (assume that your external interface is eth0):
-
+
+
If you have a dynamic ip then you must ensure that your external
+interface is up before starting Shorewall and you must take steps as
+follows (assume that your external interface is eth0):
-
Include the following in /etc/shorewall/params:
-
- ETH0_IP=`find_interface_address eth0`
-
-
Make your loc->dmz rule:
-
+
Include the following in /etc/shorewall/params:
+
+ETH0_IP=`find_interface_address eth0`
+
+
Make your loc->dmz rule:
-
-
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
loc
-
-
dmz:10.10.11.2:80
-
tcp
-
80
-
-
-
$ETH0_IP
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
loc
+
+
dmz:10.10.11.2:80
+
tcp
+
80
+
-
+
$ETH0_IP
+
+
-
-
-
If you want to access your server from the DMZ using your external IP
-address, see FAQ 2a.
-
+
+
If you want to access your server from the DMZ using your external
+IP address, see FAQ 2a.
- At this point, add the DNAT and ACCEPT rules for
-your servers.
-
+ At this point, add the DNAT and ACCEPT rules for
+your servers.
Domain Name Server (DNS)
-
-
Normally, when you connect to your ISP, as part of getting
- an IP address your firewall's Domain Name Service (DNS) resolver
- will be automatically configured (e.g., the /etc/resolv.conf file
- will be written). Alternatively, your ISP may have given you the IP
- address of a pair of DNS name servers for you to manually configure
- as your primary and secondary name servers. It is your responsibility
- to configure the resolver in your internal systems. You can take
-one of two approaches:
-
+
Normally, when you connect to your ISP, as part of
+getting an IP address your firewall's Domain Name Service (DNS)
+resolver will be automatically configured (e.g., the /etc/resolv.conf
+file will be written). Alternatively, your ISP may have given you
+the IP address of a pair of DNS name servers for you to
+manually
+configure as your primary and secondary name servers. It is your
+responsibility to configure the resolver in your internal systems.
+You can take one of two approaches:
-
-
You can configure your internal systems to use your ISP's
- name servers. If you ISP gave you the addresses of their servers
- or if those addresses are available on their web site, you can configure
- your internal systems to use those addresses. If that information
- isn't available, look in /etc/resolv.conf on your firewall system
- -- the name servers are given in "nameserver" records in that file.
-
-
-
+
+
You can configure your internal systems to use your
+ISP's name servers. If you ISP gave you the addresses of their servers
+or if those addresses are available on their web site, you can
+configure your internal systems to use those addresses. If that
+information isn't available, look in /etc/resolv.conf on your firewall
+system -- the name servers are given in "nameserver" records in that
+file.
+
+
- You can configure a Caching Name Server on
-your firewall or in your DMZ.Red Hat has an RPM for a caching
- name server (which also requires the 'bind' RPM) and for Bering
-users, there is dnscache.lrp. If you take this approach, you configure
-your internal systems to use the caching name server as their primary
-(and only) name server. You use the internal IP address of the firewall
-(10.10.10.254 in the example above) for the name server address if
-you choose to run the name server on your firewall. To allow your local
-systems to talk to your caching name server, you must open port 53
-(both UDP and TCP) from the local network to the server; you do that
-by adding the rules in /etc/shorewall/rules.
-
-
+ width="13" height="13"> You can configure a
+Caching Name Server on your firewall or in your DMZ.Red
+Hat has an RPM for a caching name server (which also requires the
+'bind' RPM) and for Bering users, there is dnscache.lrp. If you take
+this approach, you configure your internal systems to use the caching
+name server as their primary (and only) name server. You use the
+internal IP address of the firewall (10.10.10.254 in the example above)
+for the name server address
+if you choose to run the name server on your firewall. To allow your
+local systems to talk to your caching name server, you must open
+port 53 (both UDP and TCP) from the local network to the server; you
+do that by adding the rules in /etc/shorewall/rules.
+
-
-
-
If you run the name server on the firewall:
-
+
+
If you run the name server on the firewall:
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
loc
-
fw
-
udp
-
53
-
-
-
-
-
ACCEPT
-
dmz
-
fw
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
dmz
-
fw
-
udp
-
53
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
loc
+
fw
+
udp
+
53
+
+
+
+
+
ACCEPT
+
dmz
+
fw
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
dmz
+
fw
+
udp
+
53
+
+
+
+
-
-
-
-
-
+
+
+
+
Run name server on DMZ computer 1
-
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
dmz:10.10.11.1
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
loc
-
dmz:10.10.11.1
-
udp
-
53
-
-
-
-
-
ACCEPT
-
fw
-
dmz:10.10.10.1
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
fw
-
dmz:10.10.10.1
-
udp
-
53
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
dmz:10.10.11.1
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
loc
+
dmz:10.10.11.1
+
udp
+
53
+
+
+
+
+
ACCEPT
+
fw
+
dmz:10.10.10.1
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
fw
+
dmz:10.10.10.1
+
udp
+
53
+
+
+
+
-
-
-
-
+
+
+
Other Connections
-
-
-
+
+
The three-interface sample includes the following rules:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
fw
-
net
-
udp
-
53
-
-
-
-
-
ACCEPT
-
fw
-
net
-
tcp
-
53
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
fw
+
net
+
udp
+
53
+
+
+
+
+
ACCEPT
+
fw
+
net
+
tcp
+
53
+
+
+
+
-
-
-
-
-
Those rules allow DNS access from your firewall and may be
- removed if you commented out the line in /etc/shorewall/policy
- allowing all connections from the firewall to the internet.
-
-
-
+
+
+
+
Those rules allow DNS access from your firewall and may
+be removed if you commented out the line in /etc/shorewall/policy
+allowing all connections from the firewall to the internet.
+
+
The sample also includes:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
22
-
-
-
-
-
ACCEPT
-
loc
-
dmz
-
tcp
-
22
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
22
+
+
+
+
+
ACCEPT
+
loc
+
dmz
+
tcp
+
22
+
+
+
+
-
-
-
-
-
That rule allows you to run an SSH server on your firewall
- and in each of your DMZ systems and to connect to those servers
- from your local systems.
-
-
-
-
If you wish to enable other connections between your systems,
- the general format is:
-
-
-
-
+
+
+
+
That rule allows you to run an SSH server on your
+firewall and in each of your DMZ systems and to connect to those
+servers from your local systems.
+
+
+
If you wish to enable other connections between your
+systems, the general format is:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
<source zone>
-
<destination zone>
-
<protocol>
-
<port>
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
<source zone>
+
<destination zone>
+
<protocol>
+
<port>
+
+
+
+
-
-
-
-
-
Example - You want to run a publicly-available DNS server
- on your firewall system:
-
-
-
-
+
+
+
+
Example - You want to run a publicly-available DNS
+server on your firewall system:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
53
-
#Allow DNS access
-
from the internet
-
-
-
ACCEPT
-
net
-
fw
-
udp
-
-
53
-
#Allow DNS access
-
from the internet
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
53
+
#Allow DNS access
+
from the internet
+
+
+
ACCEPT
+
net
+
fw
+
udp
+
+
53
+
#Allow DNS access
+
from the internet
+
+
-
-
-
-
-
Those two rules would of course be in addition to the rules
- listed above under "If you run the name server on your firewall".
-
-
-
-
If you don't know what port and protocol a particular application
- uses, look here.
-
-
-
-
Important: I don't recommend enabling telnet to/from
- the internet because it uses clear text (even for login!). If
-you want shell access to your firewall from the internet, use SSH:
-
-
-
-
+
+
+
+
Those two rules would of course be in addition to the
+rules listed above under "If you run the name server on your firewall".
+
+
+
If you don't know what port and protocol a particular
+application uses, look here.
+
+
+
Important: I don't recommend enabling telnet
+to/from the internet because it uses clear text (even for login!). If
+you want shell access to your firewall from the internet, use
+SSH:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
22
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
22
+
+
+
+
-
-
-
-
-
-
+
+
+
+
- Bering users will want to add the following two rules to be compatible
- with Jacques's Shorewall configuration.
-
-
-
-
+ width="49" height="36"> Bering users will want to
+add the following two rules to be compatible with Jacques's Shorewall
+configuration.
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
-
fw
-
udp
-
-
53
-
-
#Allow DNS Cache to
-
work
-
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
80
-
#Allow weblet to work
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
+
fw
+
udp
+
+
53
+
+
#Allow DNS Cache to
+
work
+
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
80
+
#Allow weblet to work
+
+
+
+
-
-
-
+
+
- Now modify /etc/shorewall/rules to add or remove
- other connections as required.
-
-
-
+ height="13"> Now modify /etc/shorewall/rules to add
+or remove other connections as required.
+
+
Starting and Stopping Your Firewall
-
-
-
-
- The installation procedure
- configures your system to start Shorewall at system boot but beginning
- with Shorewall version 1.3.9 startup is disabled so that your system
- won't try to start Shorewall before configuration is complete. Once
-you have completed configuration of your firewall, you can enable Shorewall
- startup by removing the file /etc/shorewall/startup_disabled.
-
-
+
+
+
The installation
+procedure configures your system to start Shorewall at system
+boot but beginning with Shorewall version 1.3.9 startup is
+disabled so that your system won't try to start Shorewall before
+configuration is complete. Once you have completed configuration of
+your firewall, you can enable Shorewall startup by removing the file
+/etc/shorewall/startup_disabled.
+
IMPORTANT: Users of the .deb package must edit /etc/default/shorewall
- and set 'startup=1'.
-
-
-
-
-
The firewall is started using the "shorewall start" command
- and stopped using "shorewall stop". When the firewall is stopped,
- routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A
- running firewall may be restarted using the "shorewall restart"
- command. If you want to totally remove any trace of Shorewall from
- your Netfilter configuration, use "shorewall clear".
-
-
-
+ color="#ff0000">Users of the .deb package must edit
+/etc/default/shorewall and set 'startup=1'.
+
+
+
+
The firewall is started using the "shorewall start"
+command and stopped using "shorewall stop". When the firewall is
+stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped.
+A running firewall may be restarted using the "shorewall restart"
+command. If you want to totally remove any trace of Shorewall
+from your Netfilter configuration, use "shorewall clear".
+
+
- The three-interface sample assumes that you want to
- enable routing to/from eth1 (your local network) and
-eth2 (DMZ) when Shorewall is stopped. If these two interfaces
-don't connect to your local network and DMZ or if you want to enable
-a different set of hosts, modify /etc/shorewall/routestopped accordingly.
-
-
-
-
WARNING: If you are connected to your firewall from
- the internet, do not issue a "shorewall stop" command unless you
- have added an entry for the IP address that you are connected from
- to /etc/shorewall/routestopped.
- Also, I don't recommend using "shorewall restart"; it is better to
-create an alternate
- configuration and test it using the "shorewall try" command.
WARNING: If you are connected to your firewall
+from the internet, do not issue a "shorewall stop" command unless
+you have added an entry for the IP address that you are connected
+from to /etc/shorewall/routestopped.
+Also, I don't recommend using "shorewall restart"; it is better to
+create an alternate
+configuration and test it using the "shorewall try" command.
- If you receive an error message when starting or restarting
- the firewall and you can't determine the cause, then do the following:
-
+If you receive an error message when starting or restarting the
+firewall and you can't determine the cause, then do the following:
-
Make a note of the error message that you see.
-
-
shorewall debug start 2> /tmp/trace
-
Look at the /tmp/trace file and see if that helps you
- determine what the problem is. Be sure you find the place in the log
- where the error message you saw is generated -- If you are using Shorewall
-1.4.0 or later, you should find the message near the end of the log.
-
If you still can't determine what's wrong then see the
- support page.
-
+
Make a note of the error message that you see.
+
+
shorewall debug start 2> /tmp/trace
+
Look at the /tmp/trace file and see if that helps you determine
+what the problem is. Be sure you find the place in the log where the
+error message you saw is generated -- If you are using Shorewall 1.4.0
+or later, you should find the message near the end of the log.
+
If you still can't determine what's wrong then see the support page.
- Here's an example. During startup, a user sees the following:
-
-
+Here's an example. During startup, a user sees the following:
+
Adding Common Rules iptables: No chain/target/match by that name Terminated
-
- A search through the trace for "No chain/target/match by that name"
-turned up the following:
-
+
+A search through the trace for "No chain/target/match by that name"
+turned up the following:
+
+ echo 'Adding Common Rules' + add_common_rules + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset ++ sed 's/!/! /g' + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset iptables: No chain/target/match by that name
-
- The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with
- tcp-reset". In this case, the user had compiled his own kernel and had
-forgotten to include REJECT target support (see kernel.htm)
-
+
+The command that failed was: "iptables -A reject -p tcp -j REJECT
+--reject-with tcp-reset". In this case, the user had compiled his own
+kernel and had
+forgotten to include REJECT target support (see kernel.htm)
Your network environment
-
-
Many times when people have problems with Shorewall, the problem is actually
-an ill-conceived network setup. Here are several popular snafus:
-
+
Many times when people have problems with Shorewall, the problem is
+actually an ill-conceived network setup. Here are several popular
+snafus:
-
Port Forwarding where client and server are
-in the same subnet. See FAQ 2.
-
Changing the IP address of a local system to be in the
- external subnet, thinking that Shorewall will suddenly believe
-that the system is in the 'net' zone.
-
Multiple interfaces connected to the same HUB or Switch.
- Given the way that the Linux kernel respond to ARP "who-has" requests,
- this type of setup does NOT work the way that you expect it to.
-
+
Port Forwarding where client and server are in the same subnet.
+See FAQ 2.
+
Changing the IP address of a local system to be in the external
+subnet, thinking that Shorewall will suddenly believe
+that the system is in the 'net' zone.
+
Multiple interfaces connected to the same HUB or Switch. Given
+the way that the Linux kernel respond to ARP "who-has" requests, this
+type of setup does NOT work the way that you expect it to. If you
+are running Shorewall version 1.4.7 or later, you can test using this
+kind of configuration if you specify
+the arp_filter
+option in /etc/shorewall/interfaces for all interfaces connected to the
+common hub/switch. Using such a setup with a production firewall is
+strongly recommended against.
-
If you are having connection problems:
-
-
If the appropriate policy for the connection that you are
- trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES
-TRYING TO MAKE IT WORK. Such additional rules will NEVER make it work,
-they add clutter to your rule set and they represent a big security hole
-in the event that you forget to remove them later.
-
-
I also recommend against setting all of your policies to
- ACCEPT in an effort to make something work. That robs you of one of
- your best diagnostic tools - the "Shorewall" messages that Netfilter
- will generate when you try to connect in a way that isn't permitted
- by your rule set.
-
-
Check your log ("/sbin/shorewall show log"). If you don't
- see Shorewall messages, then your problem is probably NOT a Shorewall
- problem. If you DO see packet messages, it may be an indication that
-you are missing one or more rules -- see FAQ 17.
-
-
While you are troubleshooting, it is a good idea to clear
- two variables in /etc/shorewall/shorewall.conf:
-
+
If the appropriate policy for the connection that you
+are trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES
+TRYING TO MAKE IT WORK. Such additional rules will NEVER make it work,
+they add clutter to your rule set and they represent a big security
+hole
+in the event that you forget to remove them later.
+
I also recommend against setting all of your policies
+to ACCEPT in an effort to make something work. That robs you of one of
+your best diagnostic tools - the "Shorewall" messages that Netfilter
+will generate when you try to connect in a way that isn't permitted by
+your rule set.
+
Check your log ("/sbin/shorewall show log"). If you
+don't see Shorewall messages, then your problem is probably NOT a
+Shorewall problem. If you DO see packet messages, it may be an
+indication that
+you are missing one or more rules -- see FAQ 17.
+
While you are troubleshooting, it is a good idea to
+clear two variables in /etc/shorewall/shorewall.conf:
LOGRATE=""
- LOGBURST=""
-
-
This way, you will see all of the log messages being generated
-(be sure to restart shorewall after clearing these variables).
-
+LOGBURST=""
+
This way, you will see all of the log messages being
+generated (be sure to restart shorewall after clearing these variables).
Let's look at the important parts of this message:
-
-
all2all:REJECT - This packet was REJECTed out of the
-all2all chain -- the packet was rejected under the "all"->"all"
-REJECT policy (see FAQ 17).
-
IN=eth2 - the packet entered the firewall via eth2
-
OUT=eth1 - if accepted, the packet would be sent on eth1
-
SRC=192.168.2.2 - the packet was sent by 192.168.2.2
-
DST=192.168.1.3 - the packet is destined for 192.168.1.3
-
PROTO=UDP - UDP Protocol
-
DPT=53 - DNS
-
+
all2all:REJECT - This packet was REJECTed out of the
+all2all chain -- the packet was rejected under the "all"->"all"
+REJECT policy (see FAQ 17).
+
IN=eth2 - the packet entered the firewall via eth2
+
OUT=eth1 - if accepted, the packet would be sent on eth1
+
SRC=192.168.2.2 - the packet was sent by 192.168.2.2
+
DST=192.168.1.3 - the packet is destined for 192.168.1.3
+
PROTO=UDP - UDP Protocol
+
DPT=53 - DNS
-
-
In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3
- is in the "loc" zone. I was missing the rule:
-
-
ACCEPT dmz loc udp 53
-
-
-
See FAQ 17 for additional information
- about how to interpret the chain name appearing in a Shorewall log message.
-
-
+
In this case, 192.168.2.2 was in the "dmz" zone and
+192.168.1.3 is in the "loc" zone. I was missing the rule:
+
ACCEPT dmz
+loc udp 53
+
+
See FAQ 17 for additional
+information about how to interpret the chain name appearing in a
+Shorewall log message.
+
'Ping' Problems?
- Either can't ping when you think you should be able to or are able to
-ping when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
-
+Either can't ping when you think you should be able to or are able to
+ping when you think that you shouldn't be allowed? Shorewall's 'Ping'
+Management is described here.
Other Gotchas
-
-
Seeing rejected/dropped packets logged out of the INPUT
- or FORWARD chains? This means that:
+
Seeing rejected/dropped packets logged out of the INPUT or
+FORWARD chains? This means that:
-
your zone definitions are screwed up and the host that
- is sending the packets or the destination host isn't in any zone
- (using an /etc/shorewall/hosts
- file are you?); or
-
the source and destination hosts are both connected
-to the same interface and you don't have a policy or rule for the
+
your zone definitions are screwed up and the host that is
+sending the packets or the destination host isn't in any zone (using an
+ /etc/shorewall/hosts file
+are you?); or
+
the source and destination hosts are both connected to the
+same interface and you don't have a policy or rule for the
source zone to or from the destination zone.
-
-
-
Remember that Shorewall doesn't automatically allow ICMP
- type 8 ("ping") requests to be sent between zones. If you want pings
- to be allowed between zones, you need a rule of the form:
-
- ACCEPT <source zone> <destination
-zone> icmp echo-request
-
- The ramifications of this can be subtle. For example, if
-you have the following in /etc/shorewall/nat:
-
- 10.1.1.2 eth0 130.252.100.18
-
- and you ping 130.252.100.18, unless you have allowed icmp
- type 8 between the zone containing the system you are pinging from
- and the zone containing 10.1.1.2, the ping requests will be dropped.
-
If you specify "routefilter" for an interface, that
- interface must be up prior to starting the firewall.
-
Is your routing correct? For example, internal systems
- usually need to be configured with their default gateway set to
-the IP address of their nearest firewall interface. One often overlooked
- aspect of routing is that in order for two hosts to communicate,
-the routing between them must be set up in both directions.
-So when setting up routing between A and B, be sure
-to verify that the route from B back to A is defined.
Shorewall requires the "ip" program. That program
- is generally included in the "iproute" package which should be included
- with your distribution (though many distributions don't install iproute
- by default). You may also download the latest source tarball from
- ftp://ftp.inr.ac.ru/ip-routing
- .
-
Problems with NAT? Be sure that you let
-Shorewall add all external addresses to be use with NAT unless you
-have set ADD_IP_ALIASES =No
+
+
Remember that Shorewall doesn't automatically allow ICMP type 8
+("ping") requests to be sent between zones. If you want pings to be
+allowed between zones, you need a rule of the form:
+
+ ACCEPT <source
+zone> <destination zone>
+icmp echo-request
+
+The ramifications of this can be subtle. For example, if you have the
+following in /etc/shorewall/nat:
+
+ 10.1.1.2 eth0
+130.252.100.18
+
+and you ping 130.252.100.18, unless you have allowed icmp type 8
+between the zone containing the system you are pinging from and the
+zone containing 10.1.1.2, the ping requests will be dropped.
+
If you specify "routefilter" for an interface, that interface
+must be up prior to starting the firewall.
+
Is your routing correct? For example, internal systems usually
+need to be configured with their default gateway set to
+the IP address of their nearest firewall interface. One often
+overlooked aspect of routing is that in order for two hosts to
+communicate,
+the routing between them must be set up in both directions.
+So when setting up routing between A and B, be sure
+to verify that the route from B back to A is defined.
Shorewall requires the "ip" program. That program is generally
+included in the "iproute" package which should be included with your
+distribution (though many distributions don't install iproute by
+default). You may also download the latest source tarball from
+ftp://ftp.inr.ac.ru/ip-routing .
+
Problems with NAT? Be sure that you let
+Shorewall add all external addresses to be use with NAT unless you
+have set ADD_IP_ALIASES =No
in /etc/shorewall/shorewall.conf.
Setting up a Linux system as a firewall for a small network
- is a fairly straight-forward task if you understand the basics
-and follow the documentation.
-
-
This guide doesn't attempt to acquaint you with all of the features of
- Shorewall. It rather focuses on what is required to configure Shorewall
- in its most common configuration:
-
+
Setting up a Linux system as a firewall for a small
+network is a fairly straight-forward task if you understand the basics
+and follow the documentation.
+
This guide doesn't attempt to acquaint you with all of the features
+of Shorewall. It rather focuses on what is required to configure
+Shorewall in its most common configuration:
-
Linux system used as a firewall/router for a
-small local network.
-
Single public IP address.
-
Internet connection through cable modem, DSL,
-ISDN, Frame Relay, dial-up ...
-
+
Linux system used as a firewall/router for a small local network.
+
Single public IP address.
+
Internet connection through cable modem, DSL, ISDN, Frame Relay,
+dial-up ...
-
Here is a schematic of a typical installation.
-
-
-
-
If you are running Shorewall under Mandrake 9.0 or later, you can easily
- configure the above setup using the Mandrake "Internet Connection Sharing"
- applet. From the Mandrake Control Center, select "Network & Internet"
- then "Connection Sharing".
-
-
-
Note however, that the Shorewall configuration produced by Mandrake
- Internet Connection Sharing is strange and is apt to confuse you if you
-use the rest of this documentation (it has two local zones; "loc" and "masq"
- where "loc" is empty; this conflicts with this documentation which assumes
- a single local zone "loc"). We therefore recommend that once you have set
- up this sharing that you uninstall the Mandrake Shorewall RPM and install
- the one from the download page then follow the
- instructions in this Guide.
-
-
-
Shorewall requires that you have the iproute/iproute2 package installed
- (on RedHat, the package is called iproute). You can
- tell if this package is installed by the presence of an ip
- program on your firewall system. As root, you can use the 'which'
-command to check for this program:
-
+ height="635">
+
If you are running Shorewall under Mandrake 9.0 or later, you can
+easily configure the above setup using the Mandrake "Internet
+Connection
+Sharing" applet. From the Mandrake Control Center, select "Network
+& Internet" then "Connection Sharing".
+
+
Note however, that the Shorewall configuration produced by
+Mandrake Internet Connection Sharing is strange and is apt to confuse
+you if you use the rest of this documentation (it has two local zones;
+"loc" and "masq" where "loc" is empty; this conflicts with this
+documentation which assumes a single local zone "loc"). We therefore
+recommend that once you have set up this sharing that you uninstall the
+Mandrake Shorewall RPM and install the one from the download page then follow the instructions in
+this Guide.
+
+
Shorewall requires that you have the iproute/iproute2 package
+installed (on RedHat, the package is called iproute). You
+can tell if this package is installed by the presence of an ip
+program on your firewall system. As root, you can use the 'which'
+command to check for this program:
[root@gateway root]# which ip /sbin/ip [root@gateway root]#
-
-
I recommend that you first read through the guide to familiarize yourself
- with what's involved then go back through it again making your
-configuration changes. Points at which configuration changes are
- recommended are flagged with
- . Configuration notes that are unique to LEAF/Bering
-are marked with
-
-
+
I recommend that you first read through the guide to familiarize
+yourself with what's involved then go back through it again making your
+configuration changes. Points at which configuration changes are
+recommended are flagged with . Configuration notes that are unique to
+LEAF/Bering are marked with
- If you edit your configuration files on a Windows
- system, you must save them as Unix files if your editor supports
- that option or you must run them through dos2unix before trying to
- use them. Similarly, if you copy a configuration file from your Windows
- hard drive to a floppy disk, you must run dos2unix against the copy
-before using it with Shorewall.
-
+ If you edit your configuration files on a Windows
+system, you must save them as Unix files if your editor supports that
+option or you must run them through dos2unix before trying
+to use them. Similarly, if you copy a configuration file from your
+Windows hard drive to a floppy disk, you must run dos2unix against the
+copy before using it with Shorewall.
+ If you
+have an ADSL Modem and you use PPTP to communicate with a server in
+that modem, you must make the changes
+recommended here in addition to those detailed below. ADSL with
+PPTP is most commonly found in Europe, notably in Austria.
Shorewall Concepts
-
- The configuration files for Shorewall are contained in
-the directory /etc/shorewall -- for simple setups, you will only need
-to deal with a few of these as described in this guide. After you have
-installed Shorewall, download the two-interface sample,
- un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to
- /etc/shorewall (these files will replace files with the same name).
-
-
As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration
- instructions and default entries.
-
-
Shorewall views the network where it is running as being composed of a
- set of zones. In the two-interface sample configuration,
- the following zone names are used:
-
+ alt=""> The configuration files for Shorewall are
+contained in the directory /etc/shorewall -- for simple setups, you
+will only need to deal with a few of these as described in this guide.
+After you have installed Shorewall, download
+the two-interface
+sample, un-tar it (tar -zxvf two-interfaces.tgz) and and copy the
+files
+to /etc/shorewall (these files will replace files with the same
+name).
+
As each file is introduced, I suggest that you look through the
+actual file on your system -- each file contains detailed configuration
+instructions and default entries.
+
Shorewall views the network where it is running as being composed of
+a set of zones. In the two-interface sample configuration, the
+following zone names are used:
For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that
- file matches the connection request then the first policy in /etc/shorewall/policy
- that matches the request is applied. If that policy is REJECT
-or DROP the request is first checked against the rules in /etc/shorewall/common
- (the samples provide that file for you).
-
-
The /etc/shorewall/policy file included with the two-interface sample has
-the following policies:
-
-
+
For each connection request entering the firewall, the request is
+first checked against the /etc/shorewall/rules file. If no rule in
+that file matches the connection request then the first policy
+in /etc/shorewall/policy that matches the request is applied.
+If that policy is REJECT or DROP the request is first checked
+against
+the rules in /etc/shorewall/common (the samples provide that file
+for you).
+
The /etc/shorewall/policy file included with the two-interface
+sample
+has the following policies:
+
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
loc
-
net
-
ACCEPT
-
-
-
-
-
net
-
all
-
DROP
-
info
-
-
-
-
all
-
all
-
REJECT
-
info
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
loc
+
net
+
ACCEPT
+
+
+
+
+
net
+
all
+
DROP
+
info
+
+
+
+
all
+
all
+
REJECT
+
info
+
+
+
-
-
-
-
In the two-interface sample, the line below is included but commented
- out. If you want your firewall system to have full access to servers
- on the internet, uncomment that line.
-
+
+
+
In the two-interface sample, the line below is included but
+commented out. If you want your firewall system to have full access to
+servers on the internet, uncomment that line.
-
-
-
Source Zone
-
Destination Zone
-
Policy
-
Log Level
-
Limit:Burst
-
-
-
fw
-
net
-
ACCEPT
-
-
-
-
-
+
+
+
Source Zone
+
Destination Zone
+
Policy
+
Log Level
+
Limit:Burst
+
+
+
fw
+
net
+
ACCEPT
+
+
+
+
-
-
+
The above policy will:
-
-
allow all connection requests from your local
-network to the internet
-
drop (ignore) all connection requests from the
- internet to your firewall or local network
-
optionally accept all connection requests from
- the firewall to the internet (if you uncomment the additional
-policy)
-
reject all other connection requests.
-
+
allow all connection requests from your local network to the
+internet
+
drop (ignore) all connection requests from the internet to your
+firewall or local network
+
optionally accept all connection requests from the firewall to
+the internet (if you uncomment the additional policy)
+
reject all other connection requests.
-
- At this point, edit your /etc/shorewall/policy and
- make any changes that you wish.
-
+ At this point, edit your /etc/shorewall/policy
+and make any changes that you wish.
Network Interfaces
-
-
-
-
The firewall has two network interfaces. Where Internet
-connectivity is through a cable or DSL "Modem", the External Interface
- will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)
- unless you connect via Point-to-Point Protocol
- over Ethernet (PPPoE) or Point-to-Point
- Tunneling Protocol (PPTP) in which case the External
- Interface will be a ppp interface (e.g., ppp0). If you connect
- via a regular modem, your External Interface will also be ppp0.
- If you connect via ISDN, your external interface will be ippp0.
-
+ height="635">
+
The firewall has two network interfaces. Where Internet
+connectivity
+is through a cable or DSL "Modem", the External Interface will
+be
+the ethernet adapter that is connected to that "Modem" (e.g., eth0)
+unless you connect via Point-to-Point
+Protocol over Ethernet (PPPoE) or Point-to-Point
+Tunneling Protocol (PPTP) in which case the
+External Interface will be a ppp interface (e.g., ppp0). If you
+connect via a regular modem, your External Interface will also be ppp0.
+If you connect via ISDN, your external interface will be ippp0.
Your Internal Interface will be an ethernet adapter
- (eth1 or eth0) and will be connected to a hub or switch. Your other
- computers will be connected to the same hub/switch (note: If you
- have only a single internal system, you can connect the firewall
-directly to the computer using a cross-over cable).
-
+ height="13"> If your external interface is ppp0
+or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
+
Your Internal Interface will be an ethernet
+adapter (eth1 or eth0) and will be connected to a hub or switch. Your
+other computers will be connected to the same hub/switch (note:
+If you have only a single internal system, you can connect the firewall
+directly to the computer using a cross-over cable).
- Do not connect the internal and external interface
- to the same hub or switch (even for testing). It won't work the way
- that you think that it will and you will end up confused and believing
- that Shorewall doesn't work at all.
-
+ width="60" height="60"> Do not connect the internal and
+external interface to the same hub or switch except for testing AND you
+are running Shorewall version 1.4.7 or later. When using these
+recent versions, you can test using this kind of configuration if you
+specify the arp_filter option
+in /etc/shorewall/interfaces for all interfaces connected to the common
+hub/switch. Using such a setup with a production firewall is strongly
+recommended against.
+
- The Shorewall two-interface sample configuration
-assumes that the external interface is eth0 and the internal
-interface is eth1. If your configuration is different, you
-will have to modify the sample /etc/shorewall/interfaces file
- accordingly. While you are there, you may wish to review the list
-of options that are specified for the interfaces. Some hints:
-
+ width="13" height="13"> The Shorewall two-interface
+sample configuration assumes that the external interface is eth0
+and the internal interface is eth1. If your configuration is
+different, you will have to modify the sample /etc/shorewall/interfaces file
+accordingly. While you are there, you may wish to review the list of
+options that are specified for the interfaces. Some hints:
-
-
If your external interface is ppp0 or ippp0,
- you can replace the "detect" in the second column with "-".
-
-
-
-
If your external interface is ppp0 or ippp0
- or if you have a static IP address, you can remove "dhcp" from
- the option list.
-
-
+
+
If your external interface is ppp0 or ippp0,
+you can replace the "detect" in the second column with "-".
+
+
+
If your external interface is ppp0 or ippp0
+or if you have a static IP address, you can remove "dhcp" from the
+option list.
+
-
IP Addresses
-
-
Before going further, we should say a few words about Internet
- Protocol (IP) addresses. Normally, your ISP will assign
-you a single Public IP address. This address may be assigned
-via the Dynamic Host Configuration Protocol (DHCP) or as part
-of establishing your connection when you dial in (standard modem) or
-establish your PPP connection. In rare cases, your ISP may assign you
-a static IP address; that means that you configure your firewall's
-external interface to use that address permanently.However your
-external address is assigned, it will be shared by all of your systems
-when you access the Internet. You will have to assign your own addresses
-in your internal network (the Internal Interface on your firewall plus
-your other computers). RFC 1918 reserves several Private IP address
-ranges for this purpose:
-
-
+
Before going further, we should say a few words about
+Internet Protocol (IP) addresses. Normally, your ISP will
+assign you a single Public IP address. This address may be
+assigned via the Dynamic Host Configuration Protocol (DHCP) or
+as part of establishing your connection when you dial in (standard
+modem) or establish your PPP connection. In rare cases, your ISP may
+assign you a static IP address; that means that you configure
+your firewall's external interface to use that address permanently.However
+your external address is assigned, it will be shared by all of your
+systems when you access the Internet. You will have to assign your own
+addresses in your internal network (the Internal Interface on your
+firewall plus your other computers). RFC 1918 reserves several Private
+IP address ranges for this purpose:
- Before starting Shorewall, you should look at
-the IP address of your external interface and if it is one of
-the above ranges, you should remove the 'norfc1918' option from
-the external interface's entry in /etc/shorewall/interfaces.
-
-
-
-
You will want to assign your addresses from the same
-sub-network (subnet). For our purposes, we can consider a subnet
- to consists of a range of addresses x.y.z.0 - x.y.z.255. Such
- a subnet will have a Subnet Mask of 255.255.255.0. The address
- x.y.z.0 is reserved as the Subnet Address and x.y.z.255
-is reserved as the Subnet BroadcastAddress. In Shorewall,
- a subnet is described using Classless InterDomain Routing
- (CIDR) notation with consists of the subnet address followed
- by "/24". The "24" refers to the number of consecutive leading "1"
- bits from the left of the subnet mask.
-
-
-
+ height="13"> Before starting Shorewall, you should
+look at the IP address of your external interface and if it is one of
+the above ranges, you should remove the 'norfc1918' option from the
+external interface's entry in /etc/shorewall/interfaces.
+
+
+
You will want to assign your addresses from the same
+sub-network (subnet). For our purposes, we can
+consider a subnet to consists of a range of addresses x.y.z.0 -
+x.y.z.255. Such a subnet will have a Subnet Mask of
+255.255.255.0. The
+address x.y.z.0 is reserved as the Subnet Address and x.y.z.255
+is reserved as the Subnet BroadcastAddress. In
+Shorewall, a subnet is described using Classless InterDomain
+Routing (CIDR) notation with consists of the subnet address
+followed by "/24". The "24" refers to the number of consecutive leading
+"1" bits from the left of the subnet mask.
+
+
Example sub-network:
-
-
-
-
+
+
+
-
-
-
Range:
-
10.10.10.0 - 10.10.10.255
-
-
-
Subnet Address:
-
10.10.10.0
-
-
-
Broadcast Address:
-
10.10.10.255
-
-
-
CIDR Notation:
-
10.10.10.0/24
-
-
-
+
+
+
Range:
+
10.10.10.0 - 10.10.10.255
+
+
+
Subnet Address:
+
10.10.10.0
+
+
+
Broadcast Address:
+
10.10.10.255
+
+
+
CIDR Notation:
+
10.10.10.0/24
+
+
-
-
-
-
-
It is conventional to assign the internal interface either
- the first usable address in the subnet (10.10.10.1 in the above
- example) or the last usable address (10.10.10.254).
-
-
-
-
One of the purposes of subnetting is to allow all computers
- in the subnet to understand which other computers can be communicated
- with directly. To communicate with systems outside of the subnetwork,
- systems send packets through a gateway (router).
-
-
-
+
+
+
+
It is conventional to assign the internal interface
+either the first usable address in the subnet (10.10.10.1 in the above
+example) or the last usable address (10.10.10.254).
+
+
+
One of the purposes of subnetting is to allow all
+computers in the subnet to understand which other computers can be
+communicated with directly. To communicate with systems outside of the
+subnetwork, systems send packets through a gateway
+(router).
+
+
- Your local computers (computer 1 and computer
-2 in the above diagram) should be configured with their default
- gateway to be the IP address of the firewall's internal interface.
-
-
-
-
The foregoing short discussion barely scratches the surface
- regarding subnetting and routing. If you are interested in learning
- more about IP addressing and routing, I highly recommend "IP
-Fundamentals: What Everyone Needs to Know about Addressing &
-Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
-
-
The remainder of this quide will assume that you have configured
- your network as shown here:
-
+ height="13"> Your local computers (computer 1 and
+computer 2 in the above diagram) should be configured with their
+default gateway to be the IP address of the firewall's internal
+interface.
+
+
The foregoing short discussion barely scratches the
+surface regarding subnetting and routing. If you are interested in
+learning more about IP addressing and routing, I highly recommend "IP
+Fundamentals: What Everyone Needs to Know about Addressing &
+Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
+
The remainder of this quide will assume that you have
+configured your network as shown here:
-
-
-
The default gateway for computer's 1 & 2 would be 10.10.10.254.
-
-
+ height="635">
+
The default gateway for computer's 1 & 2 would be
+10.10.10.254.
+
- WARNING: Your ISP might
- assign your external interface an RFC 1918 address. If that address is
- in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC
- 1918 subnet for your local network.
-
-
+ height="13" alt=""> WARNING:
+Your ISP might assign your external interface an RFC 1918
+address. If that address
+is in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT
+RFC 1918 subnet for your local network.
+
IP Masquerading (SNAT)
-
-
The addresses reserved by RFC 1918 are sometimes referred
- to as non-routable because the Internet backbone routers
-don't forward packets which have an RFC-1918 destination address.
-When one of your local systems (let's assume computer 1) sends a connection
- request to an internet host, the firewall must perform Network
- Address Translation (NAT). The firewall rewrites the source address
- in the packet to be the address of the firewall's external interface;
- in other words, the firewall makes it look as if the firewall itself
- is initiating the connection. This is necessary so that the destination
- host will be able to route return packets back to the firewall (remember
- that packets whose destination address is reserved by RFC 1918 can't
- be routed across the internet so the remote host can't address its
-response to computer 1). When the firewall receives a return packet,
-it rewrites the destination address back to 10.10.10.1 and forwards
-the packet on to computer 1.
-
-
On Linux systems, the above process is often referred to as
- IP Masquerading but you will also see the term Source Network Address
- Translation (SNAT) used. Shorewall follows the convention used with
- Netfilter:
-
+
The addresses reserved by RFC 1918 are sometimes
+referred to as non-routable because the Internet backbone
+routers don't forward packets which have an RFC-1918 destination
+address. When one of your local systems (let's assume computer 1) sends
+a
+connection request to an internet host, the firewall must perform
+Network Address Translation (NAT). The firewall rewrites
+the source address in the packet to be the address of the firewall's
+external interface; in other words, the firewall makes it look as
+if the firewall itself is initiating the connection. This is
+necessary
+so that the destination host will be able to route return packets back
+to the firewall (remember that packets whose destination address
+is reserved by RFC 1918 can't be routed across the internet so the
+remote host can't address its response to computer 1). When the
+firewall
+receives a return packet, it rewrites the destination address back to
+10.10.10.1 and forwards the packet on to computer 1.
+
On Linux systems, the above process is often referred
+to
+as IP Masquerading but you will also see the term Source
+Network
+Address Translation (SNAT) used. Shorewall follows the convention
+used
+with Netfilter:
-
-
Masquerade describes the case where you let your
- firewall system automatically detect the external interface address.
-
-
-
-
SNAT refers to the case when you explicitly specify
- the source address that you want outbound packets from your local
- network to use.
-
-
+
+
Masquerade describes the case where you let
+your firewall system automatically detect the external interface
+address.
+
+
+
SNAT refers to the case when you explicitly
+specify the source address that you want outbound packets from your
+local network to use.
+
-
-
In Shorewall, both Masquerading and SNAT are configured with
- entries in the /etc/shorewall/masq file. You will normally use
-Masquerading if your external IP is dynamic and SNAT if the IP is
-static.
-
+
In Shorewall, both Masquerading and SNAT are configured
+with entries in the /etc/shorewall/masq file. You will normally use
+Masquerading if your external IP is dynamic and SNAT if the IP
+is static.
- If your external firewall interface is eth0,
- you do not need to modify the file provided with the sample. Otherwise,
- edit /etc/shorewall/masq and change the first column to the name
- of your external interface and the second column to the name of
-your internal interface.
-
+ height="13"> If your external firewall interface is
+eth0, you do not need to modify the file provided with the
+sample. Otherwise, edit /etc/shorewall/masq and change the first column
+to the name of your external interface and the second column to the
+name of your internal interface.
- If your external IP is static, you can enter it
-in the third column in the /etc/shorewall/masq entry if you like
-although your firewall will work fine if you leave that column empty.
- Entering your static IP in column 3 makes processing outgoing packets
-a little more efficient.
-
-
- If you are using the Debian package, please check your shorewall.conf
- file to ensure that the following are set correctly; if they are not,
- change them appropriately:
-
-
+ height="13"> If your external IP is static, you can
+enter it in the third column in the /etc/shorewall/masq entry if you
+like although your firewall will work fine if you leave that column
+empty. Entering your static IP in column 3 makes processing outgoing
+packets a little more efficient.
+
+
+ If you are using the Debian package, please check
+your
+shorewall.conf file to ensure that the following are set correctly;
+if they are not, change them appropriately:
+
-
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
-
IP_FORWARDING=On
-
-
+
NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
+
IP_FORWARDING=On
+
-
Port Forwarding (DNAT)
-
-
One of your goals may be to run one or more servers on your
- local computers. Because these computers have RFC-1918 addresses,
- it is not possible for clients on the internet to connect directly
- to them. It is rather necessary for those clients to address their
-connection requests to the firewall who rewrites the destination address
-to the address of your server and forwards the packet to that server.
-When your server responds, the firewall automatically performs SNAT
-to rewrite the source address in the response.
-
-
The above process is called Port Forwarding or
- Destination Network Address Translation (DNAT). You configure
- port forwarding using DNAT rules in the /etc/shorewall/rules file.
-
-
The general form of a simple port forwarding rule in /etc/shorewall/rules
- is:
-
-
+
One of your goals may be to run one or more servers on
+your local computers. Because these computers have RFC-1918 addresses,
+it is not possible for clients on the internet to connect directly to
+them. It is rather necessary for those clients to address their
+connection requests to the firewall who rewrites the destination
+address to the address of your server and forwards the packet to
+that server. When your server responds, the firewall automatically
+performs SNAT to rewrite the source address in the response.
+
The above process is called Port Forwarding or
+Destination Network Address Translation (DNAT). You configure port
+forwarding using DNAT rules in the /etc/shorewall/rules file.
+
The general form of a simple port forwarding rule in
+/etc/shorewall/rules is:
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
loc:<server local ip address> [:<server
- port>]
-
<protocol>
-
<port>
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
loc:<server local ip address> [:<server
+port>]
+
<protocol>
+
<port>
+
+
+
+
-
-
-
Example - you run a Web Server on computer 2 and you want to forward incoming
- TCP port 80 to that system:
-
-
+
+
Example 1 - you run a Web Server on computer 2 and you want to
+forward
+incoming TCP port 80 to that system:
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
loc:10.10.10.2
-
tcp
-
80
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
loc:10.10.10.2
+
tcp
+
80
+
+
+
+
-
-
-
A couple of important points to keep in mind:
-
+
+
Example 2 - you run an FTP Server on computer 1 so you want to
+forward
+incoming TCP port 21 to that system:
+
+
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
loc:10.10.10.1
+
tcp
+
21
+
+
+
+
+
+
+
+
For FTP, you will also need to have FTP connection tracking and NAT
+support
+in your kernel. For vendor-supplied kernels, this means that the
+ip_conntrack_ftp
+and ip_nat_ftp modules must be loaded. Shorewall will automatically
+load
+these modules if they are available and located in the standard place
+under
+/lib/modules/<kernel version>/kernel/net/ipv4/netfilter.
+
+
A couple of important points to keep in mind:
-
You must test the above rule from a client outside
- of your local network (i.e., don't test from a browser running
-on computers 1 or 2 or on the firewall). If you want to be able
-to access your web server using the IP address of your external interface,
- see Shorewall FAQ #2.
-
Many ISPs block incoming connection requests
-to port 80. If you have problems connecting to your web server,
-try the following rule and try connecting to port 5000.
-
+
You must test the above rule from a client outside of your local
+network (i.e., don't test from a browser running on computers 1 or 2 or
+on the firewall). If you want to be able to access your web server
+and/or FTP server from inside your firewall using the IP address of
+your external interface, see Shorewall FAQ #2.
+
Many ISPs block incoming connection requests to port 80. If you
+have problems connecting to your web server, try the following rule and
+try connecting to port 5000.
-
-
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
DNAT
-
net
-
loc:10.10.10.2:80
-
tcp
-
5000
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
DNAT
+
net
+
loc:10.10.10.2:80
+
tcp
+
5000
+
+
+
+
-
-
+
- At this point, modify /etc/shorewall/rules to add
- any DNAT rules that you require.
-
+ At this point, modify /etc/shorewall/rules to
+add any DNAT rules that you require.
Domain Name Server (DNS)
-
-
Normally, when you connect to your ISP, as part of getting
- an IP address your firewall's Domain Name Service (DNS)
-resolver will be automatically configured (e.g., the /etc/resolv.conf
-file will be written). Alternatively, your ISP may have given you the
-IP address of a pair of DNS name servers for you to manually
-configure as your primary and secondary name servers. Regardless of
-how DNS gets configured on your firewall, it is your responsibility
-to configure the resolver in your internal systems. You can take one
-of two approaches:
-
+
Normally, when you connect to your ISP, as part of
+getting an IP address your firewall's Domain Name Service (DNS)
+resolver will be automatically configured (e.g., the /etc/resolv.conf
+file will be written). Alternatively, your ISP may have given you
+the IP address of a pair of DNS name servers for you to
+manually configure as your primary and secondary name servers.
+Regardless
+of how DNS gets configured on your firewall, it is your
+responsibility to configure the resolver in your internal systems. You
+can take
+one of two approaches:
-
-
You can configure your internal systems to use your ISP's
- name servers. If you ISP gave you the addresses of their servers
- or if those addresses are available on their web site, you can
-configure your internal systems to use those addresses. If that
-information isn't available, look in /etc/resolv.conf on your firewall
-system -- the name servers are given in "nameserver" records in that
-file.
-
-
+
+
You can configure your internal systems to use your
+ISP's name servers. If you ISP gave you the addresses of their servers
+or if those addresses are available on their web site, you can
+configure your internal systems to use those addresses. If that
+information isn't available, look in /etc/resolv.conf on your
+firewall system -- the name servers are given in "nameserver" records
+in that file.
+
+
- You can configure a Caching Name Server on
- your firewall.Red Hat has an RPM for a caching name
- server (the RPM also requires the 'bind' RPM) and for Bering users,
- there is dnscache.lrp. If you take this approach, you configure
-your internal systems to use the firewall itself as their primary
-(and only) name server. You use the internal IP address of the firewall
-(10.10.10.254 in the example above) for the name server address.
-To allow your local systems to talk to your caching name server,
-you must open port 53 (both UDP and TCP) from the local network to the
- firewall; you do that by adding the following rules in /etc/shorewall/rules.
-
-
-
+ height="13"> You can configure a Caching Name
+Server on your firewall.Red Hat has an RPM for a caching
+name server (the RPM also requires the 'bind' RPM) and for Bering
+users, there is dnscache.lrp. If you take this approach, you configure
+your internal systems to use the firewall itself as their primary (and
+only) name server. You use the internal IP address of the firewall
+(10.10.10.254 in the example above) for the name server address. To
+allow your local systems to talk to your caching name server, you
+must open port 53 (both UDP and TCP) from the local network to the
+firewall; you do that by adding the following rules in
+/etc/shorewall/rules.
+
-
-
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
loc
-
fw
-
udp
-
53
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
loc
+
fw
+
udp
+
53
+
+
+
+
-
-
-
+
+
Other Connections
-
-
-
+
+
The two-interface sample includes the following rules:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
fw
-
net
-
tcp
-
53
-
-
-
-
-
ACCEPT
-
fw
-
net
-
udp
-
53
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
fw
+
net
+
tcp
+
53
+
+
+
+
+
ACCEPT
+
fw
+
net
+
udp
+
53
+
+
+
+
-
-
-
-
-
Those rules allow DNS access from your firewall and may be
- removed if you uncommented the line in /etc/shorewall/policy
-allowing all connections from the firewall to the internet.
-
-
-
+
+
+
+
Those rules allow DNS access from your firewall and may
+be removed if you uncommented the line in /etc/shorewall/policy
+allowing all connections from the firewall to the internet.
+
+
The sample also includes:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
22
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
22
+
+
+
+
-
-
-
-
-
That rule allows you to run an SSH server on your firewall
- and connect to that server from your local systems.
-
-
-
-
If you wish to enable other connections between your firewall
- and other systems, the general format is:
-
-
-
-
+
+
+
+
That rule allows you to run an SSH server on your
+firewall and connect to that server from your local systems.
+
+
+
If you wish to enable other connections between your
+firewall and other systems, the general format is:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
<source zone>
-
<destination zone>
-
<protocol>
-
<port>
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
<source zone>
+
<destination zone>
+
<protocol>
+
<port>
+
+
+
+
-
-
-
-
-
Example - You want to run a Web Server on your firewall
+
+
+
+
Example - You want to run a Web Server on your firewall
system:
-
-
-
-
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
80
-
#Allow web access
-
from the internet
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
80
-
#Allow web access
-
from the local network
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
80
+
#Allow web access
+
from the internet
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
80
+
#Allow web access
+
from the local network
+
+
-
-
-
-
-
Those two rules would of course be in addition to the rules
- listed above under "You can configure a Caching Name Server on
- your firewall"
-
-
-
-
If you don't know what port and protocol a particular application
- uses, look here.
-
-
-
-
Important: I don't recommend enabling telnet to/from
- the internet because it uses clear text (even for login!). If
- you want shell access to your firewall from the internet, use SSH:
-
-
-
-
+
+
+
+
Those two rules would of course be in addition to the
+rules listed above under "You can configure a Caching Name Server
+on your firewall"
+
+
+
If you don't know what port and protocol a particular
+application uses, look here.
+
+
+
Important: I don't recommend enabling telnet
+to/from the internet because it uses clear text (even for login!).
+If you want shell access to your firewall from the internet,
+use SSH:
+
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
net
-
fw
-
tcp
-
22
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
net
+
fw
+
tcp
+
22
+
+
+
+
-
-
-
-
+
+
+
- Bering users will want to add the following two rules to be compatible
- with Jacques's Shorewall configuration.
-
-
-
+ width="49" height="36"> Bering users will want to
+add the following two rules to be
+compatible with Jacques's Shorewall configuration.
+
+
-
-
-
ACTION
-
SOURCE
-
DESTINATION
-
PROTOCOL
-
PORT
-
SOURCE PORT
-
ORIGINAL ADDRESS
-
-
-
ACCEPT
-
loc
-
-
fw
-
udp
-
-
53
-
-
#Allow DNS Cache to
-
work
-
-
-
-
ACCEPT
-
loc
-
fw
-
tcp
-
80
-
#Allow weblet to work
-
-
-
-
-
+
+
+
ACTION
+
SOURCE
+
DESTINATION
+
PROTOCOL
+
PORT
+
SOURCE PORT
+
ORIGINAL ADDRESS
+
+
+
ACCEPT
+
loc
+
+
fw
+
udp
+
+
53
+
+
#Allow DNS Cache to
+
work
+
+
+
+
ACCEPT
+
loc
+
fw
+
tcp
+
80
+
#Allow weblet to work
+
+
+
+
-
-
-
+
+
-
- Now edit your /etc/shorewall/rules file to add
- or delete other connections as required.
-
-
-
+
+ Now edit your /etc/shorewall/rules file to add or
+delete other connections as required.
+
+
Starting and Stopping Your Firewall
-
-
-
-
- The installation procedure
- configures your system to start Shorewall at system boot
-but beginning with Shorewall version 1.3.9 startup is disabled so
-that your system won't try to start Shorewall before configuration
-is complete. Once you have completed configuration of your firewall,
-you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
-
-
+
+
+
The installation
+procedure configures your system to start Shorewall at system
+boot but
+beginning with Shorewall version 1.3.9 startup is disabled so that
+your system won't try to start Shorewall before configuration is
+complete.
+Once you have completed configuration of your firewall, you can enable
+Shorewall startup by removing the file /etc/shorewall/startup_disabled.
+
IMPORTANT: Users of the .deb package must edit /etc/default/shorewall
- and set 'startup=1'.
-
-
-
-
-
The firewall is started using the "shorewall start" command
- and stopped using "shorewall stop". When the firewall is stopped,
- routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A
- running firewall may be restarted using the "shorewall restart"
- command. If you want to totally remove any trace of Shorewall
-from your Netfilter configuration, use "shorewall clear".
-
-
-
+ color="#ff0000">Users of the .deb package must edit
+/etc/default/shorewall and set 'startup=1'.
+
+
+
+
The firewall is started using the "shorewall start"
+command and stopped using "shorewall stop". When the firewall is
+stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped.
+A running firewall may be restarted using the "shorewall restart"
+command. If you want to totally remove any trace of Shorewall from your
+Netfilter configuration, use "shorewall clear".
+
+
- The two-interface sample assumes that you want to
- enable routing to/from eth1 (the local network) when Shorewall
- is stopped. If your local network isn't connected to eth1 or
- if you wish to enable access to/from other hosts, change /etc/shorewall/routestopped
- accordingly.
-
-
-
-
WARNING: If you are connected to your firewall from
- the internet, do not issue a "shorewall stop" command unless
-you have added an entry for the IP address that you are connected
-from to /etc/shorewall/routestopped.
- Also, I don't recommend using "shorewall restart"; it is better to
- create an alternate
- configuration and test it using the "shorewall try" command.
WARNING: If you are connected to your firewall
+from the internet, do not issue a "shorewall stop" command unless you
+have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped.
+Also, I don't recommend using "shorewall restart"; it is better
+to create an alternate
+configuration and test it using the "shorewall try" command.
diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh
index 0d37087d2..3379e2278 100755
--- a/Shorewall/fallback.sh
+++ b/Shorewall/fallback.sh
@@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
-VERSION=1.4.6-20030731
+VERSION=1.4.6-20030809
usage() # $1 = exit status
{
diff --git a/Shorewall/install.sh b/Shorewall/install.sh
index 08066e66e..97fae7882 100755
--- a/Shorewall/install.sh
+++ b/Shorewall/install.sh
@@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
-VERSION=1.4.6-20030731
+VERSION=1.4.6-20030809
usage() # $1 = exit status
{
diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec
index 87f1b4048..de36a3647 100644
--- a/Shorewall/shorewall.spec
+++ b/Shorewall/shorewall.spec
@@ -1,5 +1,5 @@
%define name shorewall
-%define version 1.4.6_20030731
+%define version 1.4.6_20030809
%define release 1
%define prefix /usr
@@ -106,6 +106,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
+* Sat Aug 09 2003 Tom Eastep
+- Changed version to 1.4.6_20030809-1
* Thu Jul 31 2003 Tom Eastep
- Changed version to 1.4.6_20030731-1
* Sun Jul 27 2003 Tom Eastep
diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh
index f187466e5..04e8586f8 100755
--- a/Shorewall/uninstall.sh
+++ b/Shorewall/uninstall.sh
@@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
-VERSION=1.4.6-20030731
+VERSION=1.4.6-20030809
usage() # $1 = exit status
{
-
- .
- 
-
- A couple of recent configuration changes at www.shorewall.net
- broke the Search facility:
-
- 
- 
- 
- Please observe the following general requirements:
- In all cases, Squid should be configured
- to run as a transparent proxy as described at 
+
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
-
- 
-
- 
- 
- 
- 
- 
- 
- 
- 
- .
- 
- If your external interface is ppp0 or ippp0
-then you will want to set CLAMPMSS=yes in 
- Edit the /etc/shorewall/interfaces file and define the
- network interfaces on your firewall and associate each interface
-with a zone. If you have a zone that is interfaced through more than
-one interface, simply include one entry for each interface and repeat
-the zone name as many times as necessary.
- 
- 
- 
- 
- 
- 
- 
- 
-