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.
+
+By default, older versions of Shorewall ratelimited log messages
+ through settings
+ in /etc/shorewall/shorewall.conf -- If you want
+ to log all messages, set:
+
+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.
+
+This is usually cured by the following sequence of commands:
+
+
+I just installed Shorewall and when I issue the start command,
+ I see the following:
+
+Shorewall works with any GNU/Linux distribution that includes
+ the proper prerequisites.
+
+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?
+
+
+
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:
+
+
+
+
+
+
+ SUBNET
+ |
+ TARGET
+ |
| eth2 |
- 192.168.2.0/24 |
-
- |
-
-
-
-
-
-
-
3. I want to use Netmeeting or MSN Instant
- Messenger with Shorewall. What do I do?
-
-
Answer: There is an H.323 connection
- tracking/NAT module that may help 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?
-
-
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 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.
-
-
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.
-
-
4a. I just ran an nmap UDP scan of my
- 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.
-
-
-
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.
-
-
5. I've installed Shorewall and now I
- can't ping through the firewall
-
-
Answer: If you want your firewall to be totally open
- 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
-
-
- run_iptables -A icmpdef -p ICMP --icmp-type echo-request
- -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?
-
-
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").
-
-
By default, older versions of Shorewall ratelimited log messages
- through settings
- in /etc/shorewall/shorewall.conf -- If you want
-to log all messages, set:
-
-
-
-
6a. Are there any log parsers that work
- with Shorewall?
-
-
Answer: Here are several links that may be helpful:
-
-
-
- http://www.shorewall.net/pub/shorewall/parsefw/
- http://www.fireparse.com
- http://cert.uni-stuttgart.de/projects/fwlogwatch
- http://www.logwatch.org
- http://gege.org/iptables
-
-
- 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:
-
-
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?
-
-
Jan 8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
-
Answer: There are two possibilities:
-
-
- - They are late-arriving replies to DNS queries.
- - They are corrupted reply packets.
-
-
- You can distinguish the difference by setting
-the
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:
-
-
- #
# 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
-
- The above file is also include in all of my sample
- configurations available in the
Quick Start Guides and in
- the common.def file in Shorewall 1.4.0 and later.
-
-
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:
-
-
- - the destination MAC address (6 bytes)
- - the source MAC address (6 bytes)
- - the ethernet frame type (2 bytes)
-
-
- Example:
-
- MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
-
-
- - Destination MAC address = 00:04:4c:dc:e2:28
- - Source MAC address = 00:b0:8e:cf:3c:4c
- - Ethernet Frame Type = 08:00 (IP Version 4)
-
-
-
-
7. When I stop Shorewall using 'shorewall
- 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.
-
-
8. When I try to start Shorewall on RedHat,
- I get messages about insmod failing -- what's wrong?
-
-
Answer: The output you will see looks something like
- 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.
-
-
-
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
-
-
-
9. Why can't Shorewall detect my interfaces
- properly at startup?
-
-
I just installed Shorewall and when I issue the start command,
- I see the following:
-
-
-
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
Local Zone: eth1:0.0.0.0/0
Deleting user chains...
Creating input Chains...
...
-
-
-
-
Why can't Shorewall detect my interfaces properly?
-
-
-
-
Answer: The above output is perfectly normal. The
-Net zone is defined as all hosts that are connected through eth0 and the
-local zone is defined as all hosts connected through eth1
-
-
-
10. What Distributions does it work
- with?
-
-
Shorewall works with any GNU/Linux distribution that includes
- the proper prerequisites.
-
-
11. What Features does it have?
-
-
Answer: See the Shorewall
- Feature List.
-
-
12. Is there a GUI?
-
-
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.
-
-
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.
-
-
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?
-
-
Answer: If you are running a version of Shorewall
-earlier than 1.3.1, create /etc/shorewall/start and in it, place the
-following:
-
-
-
run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
-
-
-
-
-
-
-
-
-
- | SUBNET
- |
- 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:
-
-
-
-
-
-
- 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.
-
-
-
15. My local systems can't see out to
- 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:
-
+
+
+
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.
+
+
+
15. My local systems can't see out to
+ 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 default gateway on each local system isn't set to
- the IP address of the local firewall interface.
-
- -
-
-
The entry for the local network in the /etc/shorewall/masq
- 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
+
-
+
+
The default gateway on each local system isn't set to
+ the IP address of the local firewall interface.
+
+ -
+
+
The entry for the local network in the /etc/shorewall/masq
+ 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.
-
-
+
+
-
-
16. Shorewall is writing log messages
- 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.
-
-
-
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:
-
+
+
16. Shorewall is writing log messages
+ 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.
+
+
+
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:
+
- - man1918 -
- The destination address is listed in /etc/shorewall/rfc1918
- with a logdrop target -- see man1918 -
+ The destination address is listed in /etc/shorewall/rfc1918
+ with a logdrop target -- see /etc/shorewall/rfc1918.
- - rfc1918
- - The source address is listed in /etc/shorewall/rfc1918
- with a logdrop target -- see rfc1918
+ - 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 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 dropunclean
- interface option
- as specified in the LOGUNCLEAN setting in 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 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 dropunclean
+ interface option
+ as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
- - blacklst
- - The packet is being logged because the source IP
- is blacklisted in the /etc/shorewall/blacklist
- file.
- - newnotsyn
- - The packet is being logged because it is a
- TCP packet that is not part of any current connection yet
- it is not a syn packet. Options affecting the logging of such
- packets include NEWNOTSYN and LOGNEWNOTSYN
+
- blacklst
+ - The packet is being logged because the source IP
+ is blacklisted in the /etc/shorewall/blacklist
+ file.
+ - newnotsyn
+ - The packet is being logged because it is a
+TCP packet that is not part of any current connection yet
+it is not a syn packet. Options affecting the logging of such
+ packets include NEWNOTSYN and LOGNEWNOTSYN
in /etc/shorewall/shorewall.conf.
- - 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.
- - logflags - The packet
- is being logged because it failed the checks implemented
+
- 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.
+ - logflags - The
+packet is being logged because it failed the checks implemented
by the tcpflags interface option.
-
-
+
+
-
-
18. Is there any way to use aliased ip addresses
- with Shorewall, and maintain separate rulesets for
- different IPs?
-
Answer: Yes. See
-
Shorewall and Aliased Interfaces.
-
-
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.
-
-
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 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?
-
-
-
+
+18. Is there any way to use aliased ip addresses
+ with Shorewall, and maintain separate rulesets for
+ different IPs?
+ Answer: Yes. See
+ Shorewall and Aliased Interfaces.
+
+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.
+
+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
+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?
+
+
+
Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3
[SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
-
- 192.0.2.3 is external on my firewall...
- 172.16.0.0/24 is my internal LAN
+
+ 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.
-
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.
-
-
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
+ 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.
+
+
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.
-
-
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.
-
+
+
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.
+
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
-
-
Last updated 5/29/2003 - Tom Eastep
+
+
25. How to I tell which version of Shorewall
+ 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.
+
+
Last updated 6/29/2003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
+
+
diff --git a/Shorewall-docs/MAC_Validation.html b/Shorewall-docs/MAC_Validation.html
index 7c47fade6..39192f3d0 100644
--- a/Shorewall-docs/MAC_Validation.html
+++ b/Shorewall-docs/MAC_Validation.html
@@ -2,116 +2,119 @@
MAC Verification
-
+
-
+
-
+
-
-
- |
+ |
+
+
MAC Verification
-
-
- |
-
-
-
+
+
+
+
+
+
-
- All traffic from an interface or from a subnet on an interface
- can be verified to originate from a defined set of MAC addresses. Furthermore,
- each MAC address may be optionally associated with one or more IP addresses.
+
+ All traffic from an interface or from a subnet on an interface
+ can be verified to originate from a defined set of MAC addresses. Furthermore,
+ each MAC address may be optionally associated with one or more IP addresses.
-
-
Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
+
+ Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- module name ipt_mac.o).
-
- There are four components to this facility.
-
-
- - The maclist interface option in /etc/shorewall/interfaces. When
-this option is specified, all traffic arriving on the interface is subjet
-to MAC verification.
- - The maclist option in /etc/shorewall/hosts. When this option
- is specified for a subnet, all traffic from that subnet is subject to
-MAC verification.
- - The /etc/shorewall/maclist file. This file is used to associate
- MAC addresses with interfaces and to optionally associate IP addresses
- with MAC addresses.
- - The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables
- in /etc/shorewall/shorewall.conf.
- The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
-and determines the disposition of connection requests that fail MAC verification.
- The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
- requests that fail verification are to be logged. If set the the empty
-value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are
-not logged.
-
-
-
- The columns in /etc/shorewall/maclist are:
-
-
- - INTERFACE - The name of an ethernet interface on the Shorewall
- system.
- - MAC - The MAC address of a device on the ethernet segment
-connected by INTERFACE. It is not necessary to use the Shorewall MAC format
-in this column although you may use that format if you so choose.
- - IP Address - An optional comma-separated list of IP addresses
- for the device whose MAC is listed in the MAC column.
-
-
-
-Example 1: Here are my files:
- /etc/shorewall/shorewall.conf:
-
- MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
-
-
- #ZONE INTERFACE 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
wap eth3 192.168.3.255 dhcp,maclist
- texas 192.168.9.255
-
- /etc/shorewall/maclist:
-
-
- #INTERFACE MAC IP ADDRESSES (Optional)
eth3 00:A0:CC:A2:0C:A0 192.168.3.7 #Work Laptop
eth3 00:04:5a:fe:85:b9 192.168.3.250 #WAP11
eth3 00:06:25:56:33:3c #WET11
eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIPPER
-
- As shown above, I use MAC Verification on my wireless zone.
-
-Note: The WET11 is a somewhat curious device; when forwarding DHCP
-traffic, it uses the MAC address of the host (TIPPER) but for other forwarded
-traffic it uses it's own MAC address. Consequently, I don't assign the WET11
-a fixed IP address in /etc/shorewall/maclist.
-
-Example 2: Router in Local Zone
- Suppose now that I add a second wireless segment to my wireless
-zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15
- and IP address 192.168.3.253. Hosts in the second segment have IP addresses
- in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist
- file:
-
- eth3 00:06:43:45:C6:15 192.168.3.253,192.168.4.0/24
- This entry accomodates traffic from the router itself (192.168.3.253)
- and from the second wireless segment (192.168.4.0/24). Remember that
-all traffic being sent to my firewall from the 192.168.4.0/24 segment
-will be forwarded by the router so that traffic's MAC address will be
-that of the router (00:06:43:45:C6:15) and not that of the host sending
-the traffic.
- Updated 6/10/2002 - Tom Eastep
-
+
+ There are four components to this facility.
-
Copyright ©
+
+ - The maclist interface option in /etc/shorewall/interfaces. When this
+option is specified, all traffic arriving on the interface is subjet to MAC
+verification.
+ - The maclist option in /etc/shorewall/hosts. When this option
+ is specified for a subnet, all traffic from that subnet is subject to MAC
+ verification.
+ - The /etc/shorewall/maclist file. This file is used to associate
+ MAC addresses with interfaces and to optionally associate IP addresses
+ with MAC addresses.
+ - The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL
+ variables in /etc/shorewall/shorewall.conf.
+ The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
+and determines the disposition of connection requests that fail MAC verification.
+ The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
+ requests that fail verification are to be logged. If set the the empty
+value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are
+not logged.
+
+
+
+ The columns in /etc/shorewall/maclist are:
+
+
+ - INTERFACE - The name of an ethernet interface on the Shorewall
+ system.
+ - MAC - The MAC address of a device on the ethernet segment
+ connected by INTERFACE. It is not necessary to use the Shorewall MAC
+format in this column although you may use that format if you so choose.
+ - IP Address - An optional comma-separated list of IP addresses
+ for the device whose MAC is listed in the MAC column.
+
+
+
+Example 1: Here are my files (look here for
+details about my setup):
+ /etc/shorewall/shorewall.conf:
+
+ MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info
+ /etc/shorewall/interfaces:
+
+
+ #ZONE INTERFACE 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
+
+ /etc/shorewall/maclist:
+
+
+ #INTERFACE MAC IP ADDRESSES (Optional)
eth3 00:A0:CC:A2:0C:A0 192.168.3.7 #Work Laptop
eth3 00:04:5a:fe:85:b9 192.168.3.250 #WAP11
eth3 00:06:25:56:33:3c 192.168.3.225,192.168.3.8 #WET11
eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIPPER
+
+ As shown above, I use MAC Verification on my wireless zone.
+
+ Note: While marketed as a wireless bridge, the WET11 behaves like
+a wireless router with DHCP relay. When forwarding DHCP traffic, it uses
+the MAC address of the host (TIPPER) but for other forwarded traffic it uses
+it's own MAC address. Consequently, I list the IP addresses of both devices
+in /etc/shorewall/maclist.
+
+Example 2: Router in Wireless Zone
+ Suppose now that I add a second wireless segment to my wireless
+ zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15
+ and IP address 192.168.3.253. Hosts in the second segment have IP addresses
+ in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist
+ file:
+
+ eth3 00:06:43:45:C6:15 192.168.3.253,192.168.4.0/24
+ This entry accomodates traffic from the router itself (192.168.3.253)
+ and from the second wireless segment (192.168.4.0/24). Remember that all
+traffic being sent to my firewall from the 192.168.4.0/24 segment will
+be forwarded by the router so that traffic's MAC address will be that
+of the router (00:06:43:45:C6:15) and not that of the host sending the
+traffic.
+ Updated 6/30/2002 - Tom Eastep
+
+
+Copyright ©
2001, 2002, 2003 Thomas M. Eastep.
-
+
+
diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm
index 2d1316734..f4c928717 100644
--- a/Shorewall-docs/News.htm
+++ b/Shorewall-docs/News.htm
@@ -4,7 +4,7 @@
-
+
Shorewall News
@@ -14,1139 +14,1190 @@
-
+
-
+
-
+
-
+
-
+
- |
+ |
-
+
Shorewall News Archive
- |
+
-
+
-
-
+
+
-
-
6/17/2003 - Shorewall-1.4.5
-
Problems Corrected:
+
+
7/4/2003 - Shorewall-1.4.6 Beta 1
+
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.
+ - 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:
+
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.
+ - 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/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
+
6/17/2003 - Shorewall-1.4.5
-
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.
+
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.
-
+
+
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.
-
-
+
+
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
+ 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:
-
- eth0:0.0.0.0/0
- 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 group then 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.
-
-
- See the
upgrade issues
-for a discussion of how these changes may affect your configuration.
+ 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:
+
+ eth0:0.0.0.0/0
+ 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 group then 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.
+
+
+ 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 requires the iproute
- package ('ip' utility).
-
- Function from 1.3 that has been omitted from this
- version include:
-
+ 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 requires the
+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
+
- 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:
-
-
- - 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.
-
-
-
-
- - 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
-
-
+ - 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.
+
+
-
-
- 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)
-
-
1/25/2003 - Shorewall 1.3.14-Beta1
-
-
-
The Beta includes the following changes:
-
-
+ Changes for 1.4 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
+ - 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.
+
+
+
+
+ - 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
+
+
+ - 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.
-
+
+ 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
+
+ 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
+
+ In this case, the second entry in /etc/shorewall/masq
is no longer required.
-
- Example 3 -- What if your current configuration
- is like this?
-
+
+ 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:
+
+ 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
+
+
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)
+
+
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
+
+
+
+
1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format
-
-
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation.
+
+
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation.
the PDF may be downloaded from
-
+
ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-
http://slovakia.shorewall.net/pub/shorewall/pdf/
-
+
http://slovakia.shorewall.net/pub/shorewall/pdf/
+
1/17/2003 - shorewall.net has MOVED
-
+
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
+ - 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
+
+ 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
+
+ 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
+
+ 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.
-
+
+ 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
-
+
+
1/6/2003 - BURNOUT
+
-
-
Until further notice, I will not be involved in either Shorewall Development
- or Shorewall Support
+
+
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.
+
+
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation.
the PDF may be downloaded from
-
+
ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
+
-
+
12/27/2002 - Shorewall 1.3.12 Released
-
+
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.
- - 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.
+
+
+ - "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.
+
+
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)
+
- "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.
+ - 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:
-
+
http://www.shorewall.net/pub/shorewall/Beta
- ftp://ftp.shorewall.net/pub/shorewall/Beta
-
+
-
+
12/12/2002 - Mandrake Multi Network Firewall 
-
- Shorewall is at the center
- of MandrakeSoft's recently-announced
Multi
- Network Firewall (MNF) product. Here is the
press
+
+ Shorewall is at the center
+ of MandrakeSoft's recently-announced
Multi
+ 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.
-
+
12/6/2002 - Debian 1.3.11a Packages Available
-
+
-
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
12/3/2002 - Shorewall 1.3.11a
-
-
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
+
+
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
+
- 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
+
+ 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.
+
+
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation.
the PDF may be downloaded from
-
+
ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
+
+
+
+
11/09/2002 - Shorewall is Back at SourceForge
+
-
-
11/09/2002 - Shorewall is Back at SourceForge
-
-
The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
-
+
-
+
11/09/2002 - Shorewall 1.3.10
-
+
In this version:
-
-
-
-
-
10/24/2002 - Shorewall is now in Gentoo Linux
-
- Alexandru Hartmann
- reports that his Shorewall package is now a part
- of
the Gentoo Linux distribution.
- Thanks Alex!
-
-
-
10/23/2002 - Shorewall 1.3.10 Beta 1
- In this version:
-
-
+
- You may now
define the contents of a zone
- dynamically with the "shorewall add" and
- "shorewall delete" commands. These commands are
- expected to be used primarily within with the "shorewall add" and
+ "shorewall delete" commands. These commands are
+ expected to be used primarily within FreeS/Wan updown
scripts.
- 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.
+ 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
@@ -1160,111 +1211,187 @@ MAC addresses on the segment and you can optionally tie
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.
- 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.
+ 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:
-
+
+
10/24/2002 - Shorewall is now in Gentoo Linux
+
+ Alexandru Hartmann
+ reports that his Shorewall package is now a part
+of
the Gentoo Linux distribution.
+ Thanks Alex!
+
+
+
10/23/2002 - Shorewall 1.3.10 Beta 1
+ In this version:
+
+
+ You may download
+ the Beta from:
+
+
+
-
+
10/10/2002 - Debian 1.3.9b Packages Available
-
+
-
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
-
10/9/2002 - Shorewall 1.3.9b
- This release rolls
- up fixes to the installer and to the firewall script.
-
+
10/9/2002 - Shorewall 1.3.9b
+ 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.
+
+ 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.
-
-
-
9/30/2002 - TUNNELS Broken in 1.3.9!!!
- There is an
-updated firewall script at
ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
- -- copy that file to /usr/lib/shorewall/firewall.
+
+ 9/30/2002 -
+Shorewall 1.3.9a
+ Roles up the
+ fix for broken tunnels.
+
9/30/2002 - TUNNELS Broken in 1.3.9!!!
+ There is an
+updated firewall script at
ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
+ -- copy that file to /usr/lib/shorewall/firewall.
+
+
9/28/2002 - Shorewall 1.3.9
-
+
In this version:
-
+
-
+
- - 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
+
+
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:
+ 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.
+
+
+
+
+
+
+
+ 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
@@ -1272,2102 +1399,2082 @@ Debian.
- 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:
-
-
-
- - Mailing
- List Archive Search was not available.
- - The
- Site Search index was incomplete
- - Only
- one page of matches was presented.
-
-
+
- Hopefully
+ Hopefully
these problems are now corrected.
-
-
9/18/2002 - Debian 1.3.8 Packages Available
-
-
+
9/18/2002 - Debian 1.3.8 Packages Available
+
+
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
9/16/2002 - Shorewall 1.3.8
-
+
In this version:
-
+
-
+
- - 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.
+
+
+
+
-
+
9/11/2002 - Debian 1.3.7c Packages Available
-
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
9/2/2002 - Shorewall 1.3.7c
-
-This is a role up of a fix for "DNAT" rules where the source zone is $FW
+
+
This is a role up of a fix for "DNAT" rules where the source zone is $FW
(fw).
-
+
8/31/2002 - I'm not available
-
-I'm currently on vacation -- please respect my need for a couple of
-weeks free of Shorewall problem reports.
+
+I'm currently on vacation -- please respect my need for a couple of
+ weeks free of Shorewall problem reports.
-
+
-Tom
-
+
8/26/2002 - Shorewall 1.3.7b
-
-This is a role up of the "shorewall refresh" bug fix and the change which
- reverses the order of "dhcp" and "norfc1918"
+
+
This is a role up of the "shorewall refresh" bug fix and the change which
+ reverses the order of "dhcp" and "norfc1918"
checking.
-
+
8/26/2002 - French FTP Mirror is Operational
-
+
ftp://france.shorewall.net/pub/mirrors/shorewall
+ href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall
is now available.
-
+
8/25/2002 - Shorewall Mirror in France
-
-Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored
+
+
Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored
at http://france.shorewall.net.
-
+
8/25/2002 - Shorewall 1.3.7a Debian Packages Available
-
-Lorenzo Martignoni reports that the packages for version 1.3.7a are available
+
+
Lorenzo Martignoni reports that the packages for version 1.3.7a are available
at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
-8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
+
+
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
+
+
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.
+ - 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
+
- 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.
+ href="shorewall_extension_scripts.htm">/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.
+ - 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
+ - Shorewall now works with iptables 1.2.7
- - The documentation and web site no longer uses
- FrontPage themes.
+ - 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.
-
+
8/13/2002 - Documentation in the CVS Repository
-
-The Shorewall-docs project now contains just the HTML and image files
-- the Frontpage files have been removed.
+
+The Shorewall-docs project now contains just the HTML and image files -
+the Frontpage files have been removed.
-
+
8/7/2002 - STABLE branch added to CVS Repository
-
-This branch will only be updated after I release a new version of Shorewall
- so you can always update from this branch
+
+
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.
-
-8/7/2002 - Upgrade Issues section
-added to the Errata Page
+
+8/7/2002 - Upgrade Issues section added
+ to the Errata Page
-
-Now there is one place to go to look for issues involved with upgrading
+
+
Now there is one place to go to look for issues involved with upgrading
to recent versions of Shorewall.
-
+
8/7/2002 - Shorewall 1.3.6
-
+
This is primarily a bug-fix rollup with a couple of new features:
-
+
-
+
7/30/2002 - Shorewall 1.3.5b Released
-
+
This interim release:
-
+
-
+
7/29/2002 - New Shorewall Setup Guide Available
-
+
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
+ href="http://www.shorewall.net/shorewall_setup_guide.htm"> 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
-
-Lorenzo Martignoni reports that the packages are version 1.3.5a and are
+
+
Lorenzo Martignoni reports that the packages are version 1.3.5a and are
available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
7/27/2002 - Shorewall 1.3.5a Released
-
+
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.
+
+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.
+ - 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.
+ - 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.
+ - 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
+
- 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
+ href="Documentation.htm#Interfaces">/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
+
- 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
+
+
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.
+ - 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.
+ - 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.
+ - 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 QuickStart
+ Guide has been broken into three guides
+ and has been almost entirely rewritten.
- - The Samples have been updated to reflect the
+
- The Samples have been updated to reflect the
new capabilities in this release.
-
+
-
+
7/8/2002 - Shorewall 1.3.3 Debian Package Available
-
+
Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
7/6/2002 - Shorewall 1.3.3 Released
-
+
In this version:
-
+
- - Entries in /etc/shorewall/interface that use
- the wildcard character ("+") now have the "multi"
- option assumed.
+ - 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.
+ - 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.
+ - 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 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 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.
-
-
-
+ - 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
+
+
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
-
+
Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
6/19/2002 - Documentation Available in PDF Format
-
-
Thanks to Mike Martinez, the Shorewall Documentation is now available
-for download in Adobe PDF format.
+
+
Thanks to Mike Martinez, the Shorewall Documentation is now available for
+ download in Adobe
+ PDF format.
-
+
6/16/2002 - Shorewall 1.3.2 Released
-
+
In this version:
-
+
+
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.
+ - Ignore robot.txt files.
- - Recursively copy everything that they find.
+ - Recursively copy everything that they find.
- - Should be classified as weapons rather than tools.
-
-
-
+
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
-
+
Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
+
6/2/2002 - Samples Corrected
-
-
The 1.3.0 samples configurations had several serious problems that prevented
- DNS and SSH from working properly. These
+
+
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.
- - Adds an /etc/shorewall/rfc1918
+
- Adds an /etc/shorewall/rfc1918
file for defining the exact behavior of the 'norfc1918' interface option.
-
+
-
+
5/29/2002 - Shorewall 1.3.0 Released
-
-
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:
-
+
-
+
5/17/2002 - Shorewall 1.3 Beta 1 Available
-
-
Beta 1 carries the version designation 1.2.90 and implements the following
+
+
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.
+ - 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.
+ - 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.
-
-
-
+
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.
+
+
+
5/4/2002 - Shorewall 1.2.13 is Available
-
+
In this version:
-
+
+
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.
+
+
+
+
4/30/2002 - Shorewall Debian News
-
-
Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the
-Debian
- Testing Branch and the Debian
- Unstable Branch.
+
+
Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian
+Testing Branch and the Debian
+Unstable Branch.
-
+
4/20/2002 - Shorewall 1.2.12 is Available
-
+
- - The 'try' command works again
+ - The 'try' command works again
- - There is now a single RPM that also works with
- SuSE.
-
-
-
+
There is now a single RPM that also works with
+ SuSE.
+
+
+
4/17/2002 - Shorewall Debian News
-
+
Lorenzo Marignoni reports that:
-
+
+
Shorewall 1.2.11 is in the Debian
+ Unstable Branch
+
+
+
Thanks, Lorenzo!
-
+
4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE
-
-
Thanks to Stefan Mohr, there
+
+
Thanks to Stefan Mohr, there
is now a Shorewall 1.2.11
- SuSE RPM available.
+ href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">
+ SuSE RPM available.
-
+
4/13/2002 - Shorewall 1.2.11 Available
-
+
In this version:
-
+
- - 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.
+ - 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 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.
+ - 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.
+ - Simple "Yes/No" and "On/Off" values are now
+ case-insensitive in /etc/shorewall/shorewall.conf.
-
+
-
+
4/13/2002 - Hamburg Mirror now has FTP
-
+
Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.
+ href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.
Thanks Stefan!
-
+
4/12/2002 - New Mirror in Hamburg
-
-
Thanks to Stefan Mohr, there
- is now a mirror of the Shorewall website
- at http://germany.shorewall.net.
+
+
Thanks to Stefan Mohr, there
+ is now a mirror of the Shorewall website
+ at http://germany.shorewall.net.
-
+
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
+
+
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.
-
+
4/2/2002 - Updated Log Parser
-
-
John Lodge has provided an updated
+
+
John Lodge has provided an updated
version of his CGI-based log parser
- with corrected date handling.
+ href="pub/shorewall/parsefw/">CGI-based log parser
+ with corrected date handling.
-
+
3/30/2002 - Shorewall Website Search Improvements
-
-
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
+
+
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
+ href="http://lists.shorewall.net/mailing_list.htm">mailing list information
page.
-
+
3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)
-
+
+
Shorewall 1.2.9 is now in the Debian
+ Unstable Distribution.
+
+
+
3/25/2002 - Log Parser Available
-
+
John Lodge has provided a CGI-based log parser for Shorewall. Thanks
+ href="pub/shorewall/parsefw/">CGI-based log parser for Shorewall. Thanks
John.
-
+
3/20/2002 - Shorewall 1.2.10 Released
-
+
In this version:
-
+
- - 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 "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.
+ - 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.
-
-
-
+
Copyright notices have been added to the documenation.
+
+
+
3/11/2002 - Shorewall 1.2.9 Released
-
+
In this version:
-
+
-
+
3/1/2002 - 1.2.8 Debian Package is Available
-
+
See http://security.dsi.unimi.it/~lorenzo/debian.html
-
+
2/25/2002 - New Two-interface Sample
-
-
I've enhanced the two interface sample to allow access from the firewall
- to servers in the local zone -
- http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
-
+
I've enhanced the two interface sample to allow access from the firewall
+ to servers in the local zone -
+ http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
+
+
2/23/2002 - Shorewall 1.2.8 Released
-
-
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
+
+
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
+ - 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.
+ - 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.
+ - A 'shorewall check' command has been added
+that does a cursory validation of the zones, interfaces,
+ hosts, rules and policy files.
-
+
-
+
2/18/2002 - 1.2.6 Debian Package is Available
-
+
See http://security.dsi.unimi.it/~lorenzo/debian.html
-
+
2/8/2002 - Shorewall 1.2.6 Released
-
+
In this version:
-
+
- - $-variables may now be used anywhere in the
-configuration files except /etc/shorewall/zones.
+ - $-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.
+ - 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.
-
-
-
+
A problem occurring when BLACKLIST_LOGLEVEL
+ was not set has been corrected.
+
+
+
2/4/2002 - Shorewall 1.2.5 Debian Package Available
-
+
see http://security.dsi.unimi.it/~lorenzo/debian.html
-
+
2/1/2002 - Shorewall 1.2.5 Released
-
-
Due to installation problems with Shorewall 1.2.4, I have released Shorewall
- 1.2.5. Sorry for the rapid-fire development.
+
+
Due to installation problems with Shorewall 1.2.4, I have released Shorewall
+ 1.2.5. Sorry for the rapid-fire development.
-
+
In version 1.2.5:
-
+
- - The installation problems have been corrected.
+ - The installation problems have been corrected.
- - SNAT is now supported.
+ - SNAT is now supported.
- - A "shorewall version" command has been added
+ - A "shorewall version" command has been added
- - 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.
+
+
+
1/28/2002 - Shorewall 1.2.4 Released
-
+
-
+
1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html
-
+
1/20/2002 - Corrected firewall script available
-
-
Corrects a problem with BLACKLIST_LOGLEVEL. See the
- errata for details.
+
+
Corrects a problem with BLACKLIST_LOGLEVEL. See the
+ errata for details.
-
+
1/19/2002 - Shorewall 1.2.3 Released
-
+
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 status" command no longer hangs.
- - The "shorewall monitor" command now displays
- the icmpdef chain
+ - The "shorewall monitor" command now displays
+ the icmpdef chain
- - The CLIENT PORT(S) column in tcrules is no longer
+
- 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.
+ 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
+ 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
-
+
-
+
- - 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
+
- 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 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
+ 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.
+ - 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.
-
-
-
-
-
-
See the README file for upgrade instructions.
+
Orphan DNS replies are now silently dropped.
+
+
+
+
See the README file for upgrade instructions.
+
+
1/1/2002 - Shorewall Mailing List Moving
-
-
The Shorewall mailing list hosted at
- Sourceforge is moving to Shorewall.net.
- If you are a current subscriber to the list
-at Sourceforge, please see these instructions.
- If you would like to subscribe to the new
+
+
The Shorewall mailing list hosted at
+ Sourceforge is moving to Shorewall.net.
+ If you are a current subscriber to the list at
+ Sourceforge, please see these instructions.
+ If you would like to subscribe to the new
list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.
-
+
12/31/2001 - Shorewall 1.2.1 Released
-
+
In version 1.2.1:
-
+
+
'shorewall show tc' now correctly handles tunnels.
-
12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist
-releasing 1.2 on 12/21/2001
-
-
-
-
Version 1.2 contains the following new features:
-
-
-
-
-
-
-
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:
-
-
-
-
-
-
- rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
-
-
-
-
-
12/19/2001 - Thanks to Steve
- Cowles, there is now a Shorewall mirror
- in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall
- and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
-
-
-
-
11/30/2001 - A new set of the parameterized Sample
- Configurations has been released. In this version:
-
-
-
-
-
- - Ping is now allowed between the zones.
-
- - In the three-interface configuration, it is now
- possible to configure the internet services that
- are to be available to servers in the DMZ.
-
-
-
-
11/20/2001 - The current version of Shorewall is 1.1.18.
-
-
-
-
In this version:
-
-
-
-
-
- - The spelling of ADD_IP_ALIASES has been corrected
- in the shorewall.conf file
-
- - The logic for deleting user-defined chains has
- been simplified so that it avoids a bug in the LRP
-version of the 'cut' utility.
-
- - The /var/lib/lrpkg/shorwall.conf file has been
- corrected to properly display the NAT entry
-in that file.
-
-
-
-
-
-
-
11/19/2001 - Thanks to Juraj
- Ontkanin, there is now a Shorewall
- mirror in the Slovak Republic. The website
- is now mirrored at http://www.nrg.sk/mirror/shorewall
- and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
-
-
-
-
11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations.
- There are three sample configurations:
-
-
-
-
-
- - One Interface -- for a standalone system.
-
- - Two Interfaces -- A masquerading firewall.
-
- - Three Interfaces -- A masquerading firewall with
- DMZ.
-
-
-
+
12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing
+1.2 on 12/21/2001
+
Version 1.2 contains the following new features:
+
+
+
+
+
+
+
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:
+
+
+
+
+
+
+ rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
+
+
+
+
+
+
12/19/2001 - Thanks to Steve
+ Cowles, there is now a Shorewall
+mirror in Texas. This web site is mirrored
+at http://www.infohiiway.com/shorewall
+ and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
+
+
+
+
11/30/2001 - A new set of the parameterized Sample
+Configurations has been released. In this version:
+
+
+
+
+
+ - Ping is now allowed between the zones.
+
+ - In the three-interface configuration, it is
+now possible to configure the internet services that
+ are to be available to servers in the DMZ.
+
+
+
+
+
+
+
11/20/2001 - The current version of Shorewall is 1.1.18.
+
+
+
+
In this version:
+
+
+
+
+
+ - The spelling of ADD_IP_ALIASES has been corrected
+ in the shorewall.conf file
+
+ - The logic for deleting user-defined chains has
+ been simplified so that it avoids a bug in the LRP
+version of the 'cut' utility.
+
+ - The /var/lib/lrpkg/shorwall.conf file has been
+ corrected to properly display the NAT entry in
+ that file.
+
+
+
+
+
+
+
11/19/2001 - Thanks to Juraj
+ Ontkanin, there is now a Shorewall
+ mirror in the Slovak Republic. The website
+ is now mirrored at http://www.nrg.sk/mirror/shorewall
+ and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
+
+
+
+
11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations.
+ There are three sample configurations:
+
+
+
+
+
+ - One Interface -- for a standalone system.
+
+ - Two Interfaces -- A masquerading firewall.
+
+ - Three Interfaces -- A masquerading firewall
+with DMZ.
+
+
+
+
+
+
Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17
- . See the README file for instructions.
+ 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.
+
+
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.
-
+
In this version:
-
+
-
-
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
+
- A new "shorewall show connections" command has
been added.
- - In the "shorewall monitor" output, the currently
- tracked connections are now shown on a separate
+
- 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
+
- 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.
+
+
+
+
+
+
10/4/2001 - The current version of Shorewall is 1.1.14. In this
+ version
- - Support for nested zones has been improved.
-See the documentation
- for details
+ - 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:
- - Shorewall now correctly checks the alternate
- configuration directory for the 'zones' file.
+ 1. Create a New Directory
-
-
+ 2. Copy to that directory any of your configuration
+ files that you want to change.
-
-
10/4/2001 - The current version of Shorewall is 1.1.14. In this
- version
+ 3. Modify the copied files as needed.
-
-
+ 4. Restart Shorewall specifying the new directory.
- - 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:
+ - 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.
- 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
+
- Rules that specify multiple client ip addresses
or subnets no longer cause startup failures.
- - Zone names in the policy file are now validated
+
- Zone names in the policy file are now validated
against the zones file.
- - If you have packet
+
- 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.
+ href="Documentation.htm#Interfaces">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
+
+
9/12/2001 - The current version of Shorewall is 1.1.13. In this
version
-
+
-
-
8/28/2001 - The current version of Shorewall is 1.1.12. In this
+
+
8/28/2001 - The current version of Shorewall is 1.1.12. In this
version
-
+
- - Several columns in the rules file may now contain
+
- Several columns in the rules file may now contain
comma-separated lists.
- - Shorewall is now more rigorous in parsing the
+
- Shorewall is now more rigorous in parsing the
options in /etc/shorewall/interfaces.
- - Complementation using "!" is now supported in
- rules.
+ - Complementation using "!" is now supported
+in rules.
-
+
-
-
7/28/2001 - The current version of Shorewall is 1.1.11. In this
+
+
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"
+
- 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 /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
+
- 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"
+ - 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.
+ - 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.
+ - The "shorewall hits" command no longer lists
+ extraneous service names in its last report.
- - Erroneous instructions in the comments at the
+
- 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
-
+
-
-
6/18/2001 - The current version of Shorewall is 1.1.8. In this
-version
+
+
6/18/2001 - The current version of Shorewall is 1.1.8. In this version
-
+
-
+
6/2/2001 - The current version of Shorewall is 1.1.7. In this version
-
+
- - The TOS rules are now deleted when the firewall
+
- The TOS rules are now deleted when the firewall
is stopped.
- - The .rpm will now install regardless of which
- version of iptables is installed.
+ - The .rpm will now install regardless of which
+ version of iptables is installed.
- - The .rpm will now install without iproute2 being
+
- The .rpm will now install without iproute2 being
installed.
- - The documentation has been cleaned up.
+ - The documentation has been cleaned up.
- - The sample configuration files included in Shorewall
- have been formatted to 80 columns for ease of
+
- The sample configuration files included in Shorewall
+ have been formatted to 80 columns for ease of
editing on a VGA console.
-
+
-
-
5/25/2001 - The current version of Shorewall is 1.1.6. In this
-version
+
+
5/25/2001 - The current version of Shorewall is 1.1.6. In this version
-
+
- - You may now rate-limit
- the packet log.
+ - You may now rate-limit
+ the packet log.
- - 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.
+ - 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
+
- 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
-
+
-
-
5/10/2001 - The current version of Shorewall is 1.1.4. In this
-version
+
+
5/10/2001 - The current version of Shorewall is 1.1.4. In this version
-
+
- - Accepting RELATED
-connections is now optional.
+ - Accepting RELATED
+ connections is now optional.
- - Corrected problem where if "shorewall start"
- aborted early (due to kernel configuration errors
- for example), superfluous 'sed' error messages
+
- 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.
+ - Corrected rules generated for port redirection.
- - The order in which iptables kernel modules are
+
- 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).
+ - Correct message issued when Proxy ARP address
+ added (Thanks to Jason Kirtland).
- - /tmp/shorewallpolicy-$$ is now removed if there
+
- /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
+
- /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.
+ - 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
+
- 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
+
- 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
+
- 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
+
- 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
+
+
- - Port redirection now works again.
+ - Port redirection now works again.
- - The icmpdef and common chains The icmpdef and common chains may now be user-defined.
- - The firewall no longer fails to start if "routefilter"
- is specified for an interface that isn't started.
+
- 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
+
- The LRP Version is renamed "shorwall" for 8,3
MSDOS file system compatibility.
- - A couple of LRP-specific problems were corrected.
-
-
-
+
A couple of LRP-specific problems were corrected.
+
+
+
4/8/2001 - Shorewall is now affiliated with the Leaf Project 
-
+
+
-
4/5/2001 - The current version of Shorewall is 1.1.1. In this version:
-
+
- - The common chain is traversed from INPUT, OUTPUT
+
- The common chain is traversed from INPUT, OUTPUT
and FORWARD before logging occurs
- - The source has been cleaned up dramatically
+ - 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.
-
-
-
+
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:
-
+
- - Log messages now indicate the packet disposition.
+ - Log messages now indicate the packet disposition.
- - Error messages have been improved.
+ - Error messages have been improved.
- - The ability to define zones consisting of an
-enumerated set of hosts and/or subnetworks has been
+
- 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
+
- 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
+
- 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.
+ - 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.
-
-
-
+
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:
-
+
- - 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.
+ - 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
+
- Adds the ability to specify logging in entries
in the /etc/shorewall/rules file.
- - Correct handling of the icmp-def chain so that
+
- 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).
-
-
-
+
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.
+ - 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.
+ - DMZ-related chains are now correctly deleted
+ if the DMZ is deleted.
- - The interface OPTIONS for "gw" interfaces are
+
- 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.
-
-
Updated 6/17/2003 - Tom Eastep
+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.
+
+
+
+Updated 7/4/2003 - Tom Eastep
-
+
+
Copyright © 2001, 2002 Thomas M. Eastep.
-
+
+
diff --git a/Shorewall-docs/Shorewall_Squid_Usage.html b/Shorewall-docs/Shorewall_Squid_Usage.html
index 61a732279..a9d2b49fd 100644
--- a/Shorewall-docs/Shorewall_Squid_Usage.html
+++ b/Shorewall-docs/Shorewall_Squid_Usage.html
@@ -2,401 +2,367 @@
Shorewall Squid Usage
-
+
-
+
-
+
-
-
- 
-
- |
- Using Shorewall with Squid
- |
- 
-
- |
-
-
-
-
-
- This page covers Shorewall configuration to use with
Squid running as a
Transparent
- Proxy. 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.
-
-
- You must have NAT and MANGLE enabled in
-your /etc/shorewall/conf file
-
-
NAT_ENABLED=Yes
- MANGLE_ENABLED=Yes
-
- Three different configurations are covered:
-
-
- - Squid running
- on the Firewall.
- - Squid running in
- the local network
- - Squid running in
-the DMZ
-
-
-
-
Squid Running on the Firewall
- 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 |
-
- |
-
- |
-
-
-
-
-
-
- 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:
-
- run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
-
- 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.
-
-
-
- - 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.168.1.3 dev eth1 table www.out
ip route flush cache
echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
fi
-
-
-
-
-
+
+
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-
-
+
+
-
-
If you are running RedHat on the server, you can simply execute
- the following commands after you have typed the iptables command above:
-
-
-
+
+ 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 start
-
-
+
+
-
+
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.
-
+ 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
-
-
+ - 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.0.2.177 dev eth1 table www.out
ip route flush cache
fi
-
-
+
+
- - Do one of the following:
-
- A) In /etc/shorewall/start add
-
-
+ - 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:
-
-
-
-
+
+
+B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
+ and add the following entry in /etc/shorewall/tcrules:
+
+
+
+
@@ -414,7 +380,7 @@ following policy in place of the above rule:
- 202:P
+ | 202
|
eth2
|
@@ -427,105 +393,142 @@ following policy in place of the above rule:
-
|
-
-
+
+
-
-
+ 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:
-
+ - 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
- |
-
- |
-
- |
-
-
-
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DEST
+ |
+ PROTO
+ |
+ DEST
+ PORT(S)
+ |
+ CLIENT
+ PORT(2)
+ |
+ ORIGINAL
+ DEST
+ |
+
+
+ ACCEPT
+ |
+ loc
+ |
+ dmz
+ |
+ tcp
+ |
+ 80
+ |
+
+ |
+
+ |
+
+
+ ACCEPT
+ |
+ dmz
+ |
+ net
+ |
+ tcp
+ |
+ 80
+ |
+
+ |
+
+ |
+
+
+
-
-
-
-
-
- If you are running RedHat on the server, you can simply execute
- the following commands after you have typed the iptables command above:
+
-
-
+
+
+
+ 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 start
-
-
+
+
-
- Updated 5/29/2003 - Tom Eastep
-
+
+ Updated 6/27/2003 - Tom Eastep
+
- Copyright ©
+ Copyright ©
2003 Thomas M. Eastep.
-
-
diff --git a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
index e5f576ad1..b8d495c60 100644
--- a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
+++ b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
@@ -2,196 +2,165 @@
Shorewall and Aliased Interfaces
-
+
-
+
-
+
-
-
- |
+ |
+
+
Shorewall and Aliased Interfaces
- |
-
-
-
+
+
+
+
-
-
-Background
- 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:
-
-[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:
-
-
-[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.
-
-[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.
-
-
-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.
-
-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
- |
-
- |
-
- |
-
-
-
-
-
-
-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:
+
+Background
+ 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:
+
+[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:
+
+
+[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.
+
+[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.
+
+
+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.
+
+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
- |
-
-
- DNAT
+ |
+
+ ACTION
+ |
+ SOURCE
+ |
+ DESTINATION
+ |
+ PROTOCOL
+ |
+ PORT(S)
+ |
+ SOURCE PORT(S)
+ |
+ ORIGINAL DESTINATION
+ |
+
+
+ ACCEPT
+ |
+ net
+ |
+ fw:206.124.146.178
+ |
+ tcp
+ |
+ 22
+ |
+
|
- net
+ |
|
- loc:192.168.1.3
- |
- tcp
- |
- 80
- |
- -
- |
- 206.124.146.178
- |
-
-
-
+
+
+
-
+
+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
+ 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
- |
-
-
-
-
-
-
- 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:
-
-
+
+
+
@@ -203,65 +172,89 @@ the INTERFACE column as follows:
- eth0:0
+ | eth0
|
eth1
|
206.124.146.178
|
-
-
+
+
-
-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
- |
-
-
-
-
-
-
- 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
+ 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
+ |
+
+
+
+
+
+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
+ |
+
+
+
+
+
+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:
+
+
+
@@ -279,7 +272,7 @@ the INTERFACE column as follows:
206.124.146.178
|
- eth0:0
+ | eth0
|
192.168.1.3
|
@@ -288,259 +281,119 @@ the INTERFACE column as follows:
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
- |
-
- |
-
- |
-
-
-
-
+
+ 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
+ |
+ 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 and
-eth1:0 is 192.168.20.254. You want to simply route all requests between
+ 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.
-
+
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
- |
-
- |
-
-
-
-
-
-
- In /etc/shorewall/hosts:
-
-
-
-
-
- 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.
-
-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:
- |
-
-
-
-
-
-
- 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
- |
-
- |
-
- |
-
-
-
-
-
-
- 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:
-
-
-
-
-
+
ZONE
|
@@ -558,26 +411,65 @@ privileges).
192.168.1.255,192.168.20.255
|
- Note 1:
+ |
|
-
-
+
+
+
+
+ In /etc/shorewall/hosts:
+
+
+
+
+
+ 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.
+
+If you are running Shorewall 1.4.0 or earlier
+
+ 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/hosts:
-
-
+
+
ZONE
|
- HOSTS
+ | INTERFACE
+ |
+ BROADCAST
|
OPTIONS
|
@@ -585,39 +477,174 @@ privileges).
loc
|
- eth1:192.168.1.0/24
+ | 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.
+
+ 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
|
- eth1:192.168.20.0/24
+ | Local2
|
-
+ | Local Zone 2
|
-
-
+
+
-
-
- In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
- that you want to permit.
-
-
-Last Updated 5/8/2003 A - Tom Eastep
-
-Copyright ©
- 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
+
+ In /etc/shorewall/interfaces:
+
+
+
+
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ -
+ |
+ 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.
+
+ In /etc/shorewall/hosts:
+
+
+
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1:192.168.1.0/24
+ |
+
+ |
+
+
+ loc2
+ |
+ eth1:192.168.20.0/24
+ |
+
+ |
+
+
+
+
+
+
+ In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
+ that you want to permit.
+
+
+Last Updated 6/22/2003 A - Tom Eastep
+
+Copyright ©
+ 2001, 2002, 2003 Thomas M. Eastep.
+
diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm
index 97f753f49..36bf45f58 100644
--- a/Shorewall-docs/Shorewall_index_frame.htm
+++ b/Shorewall-docs/Shorewall_index_frame.htm
@@ -1,138 +1,139 @@
-
+
-
+
-
+
-
+
Shorewall Index
-
-
+
+
-
+
-
-
- |
-
+ |
+
+
+
Shorewall
- |
-
-
- |
-
+ |
+
+
+ |
+
-
+
-
+
-
+
- |
-
-
-
+
+
+
+
-
+
Copyright © 2001-2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm
index 4a2d44d7e..cc4ad44d8 100644
--- a/Shorewall-docs/Shorewall_sfindex_frame.htm
+++ b/Shorewall-docs/Shorewall_sfindex_frame.htm
@@ -1,138 +1,138 @@
-
+
-
+
-
+
-
+
Shorewall Index
-
-
+
+
-
+
-
-
- |
-
+ |
+
+
+
Shorewall
- |
-
-
- |
-
+ |
+
+
+ |
+
-
+
-
+
-
+
- |
-
-
-
+
+
+
+
-
+
Copyright © 2001-2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm
index f9f0bf69e..4b242c68d 100644
--- a/Shorewall-docs/configuration_file_basics.htm
+++ b/Shorewall-docs/configuration_file_basics.htm
@@ -1,407 +1,407 @@
-
+
-
+
-
+
-
+
Configuration File Basics
-
+
-
-
- |
+ |
+
+
Configuration Files
- |
-
-
-
+
+
+
+
-
-Warning: If you copy or edit your configuration
-files on a system running Microsoft Windows, you must
- run them through dos2unix
- before you use them with Shorewall.
-
-Files
-
-Shorewall's configuration files are in the directory /etc/shorewall.
-
-
- - /etc/shorewall/shorewall.conf - used to set
-several firewall parameters.
- - /etc/shorewall/params - use this file to set
- shell variables that you will expand in other files.
- - /etc/shorewall/zones - partition the firewall's
- view of the world into zones.
- - /etc/shorewall/policy - establishes firewall
- high-level policy.
- - /etc/shorewall/interfaces - describes the
-interfaces on the firewall system.
- - /etc/shorewall/hosts - allows defining zones
- in terms of individual hosts and subnetworks.
- - /etc/shorewall/masq - directs the firewall
-where to use many-to-one (dynamic) Network Address Translation
-(a.k.a. Masquerading) and Source Network Address Translation
-(SNAT).
- - /etc/shorewall/modules - directs the firewall
- to load kernel modules.
- - /etc/shorewall/rules - defines rules that
-are exceptions to the overall policies established in /etc/shorewall/policy.
- - /etc/shorewall/nat - defines static NAT rules.
- - /etc/shorewall/proxyarp - defines use of Proxy
- ARP.
- - /etc/shorewall/routestopped (Shorewall 1.3.4
- and later) - defines hosts accessible when Shorewall is stopped.
- - /etc/shorewall/tcrules - defines marking of
-packets for later use by traffic control/shaping or policy routing.
- - /etc/shorewall/tos - defines rules for setting
- the TOS field in packet headers.
- - /etc/shorewall/tunnels - defines IPSEC, GRE
-and IPIP tunnels with end-points on the firewall system.
- - /etc/shorewall/blacklist - lists blacklisted
- IP/subnet/MAC addresses.
- - /etc/shorewall/init - commands that you wish to execute at the
-beginning of a "shorewall start" or "shorewall restart".
- - /etc/shorewall/start - commands that you wish to execute at the
- completion of a "shorewall start" or "shorewall restart"
- - /etc/shorewall/stop - commands that you wish to execute at the
-beginning of a "shorewall stop".
- - /etc/shorewall/stopped - commands that you wish to execute at
-the completion of a "shorewall stop".
- - /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN
-- RFC 3168) to remote hosts or networks.
-
-
-
-
-Comments
-
-You may place comments in configuration files by making the first non-whitespace
- character a pound sign ("#"). You may also place comments at
- the end of any line, again by delimiting the comment from the
-rest of the line with a pound sign.
-
-Examples:
-
-# This is a comment
-
-ACCEPT net fw tcp www #This is an end-of-line comment
-
-Line Continuation
-
-You may continue lines in the configuration files using the usual backslash
- ("\") followed immediately by a new line character.
-
-Example:
-
-ACCEPT net fw tcp \
smtp,www,pop3,imap #Services running on the firewall
-
-INCLUDE Directive
- Beginning with Shorewall version 1.4.2, any file may contain INCLUDE directives.
-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.
-
-INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives
- are ignored with a warning message.
-
- 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 -----
-
-Using DNS Names
-
-
-
-WARNING: I personally recommend strongly against
- using DNS names in Shorewall configuration files. If you use DNS
-names and you are called out of bed at 2:00AM because Shorewall won't
-start as a result of DNS problems then don't say that you were not forewarned.
-
-
-
- -Tom
-
-
-Beginning with Shorwall 1.3.9, Host addresses in Shorewall
- configuration files may be specified as either IP addresses or DNS
- Names.
-
- DNS names in iptables rules aren't nearly as useful as
-they first appear. When a DNS name appears in a rule, the iptables
-utility resolves the name to one or more IP addresses and inserts
- those addresses into the rule. So changes in the DNS->IP address
-relationship that occur after the firewall has started have absolutely
-no effect on the firewall's ruleset.
-
- If your firewall rules include DNS names then:
-
-
- - If your /etc/resolv.conf is wrong then your firewall
- won't start.
- - If your /etc/nsswitch.conf is wrong then your firewall
- won't start.
- - If your Name Server(s) is(are) down then your firewall
- won't start.
- - If your startup scripts try to start your firewall
-before starting your DNS server then your firewall won't start.
-
- - Factors totally outside your control (your ISP's
-router is down for example), can prevent your firewall from starting.
- - You must bring up your network interfaces prior to
-starting your firewall.
-
-
-
-
- Each DNS name much be fully qualified and include a minumum
- of two periods (although one may be trailing). This restriction is
- imposed by Shorewall to insure backward compatibility with existing
- configuration files.
-
- Examples of valid DNS names:
-
-
-
- - mail.shorewall.net
- - shorewall.net. (note the trailing period).
-
-
- Examples of invalid DNS names:
-
-
- - mail (not fully qualified)
- - shorewall.net (only one period)
-
-
- DNS names may not be used as:
-
-
- - The server address in a DNAT rule (/etc/shorewall/rules
- file)
- - In the ADDRESS column of an entry in /etc/shorewall/masq.
- - In the /etc/shorewall/nat file.
-
-
- These restrictions are not imposed by Shorewall simply
-for your inconvenience but are rather limitations of iptables.
-
-Complementing an Address or Subnet
-
-Where specifying an IP address, a subnet or an interface, you can precede
-the item with "!" to specify the complement of the item. For example,
-!192.168.1.4 means "any host but 192.168.1.4". There must be no white space
-following the "!".
-
-Comma-separated Lists
-
-Comma-separated lists are allowed in a number of contexts within the
- configuration files. A comma separated list:
-
-
- - Must not have any embedded white space.
- Valid: routefilter,dhcp,norfc1918
- Invalid: routefilter, dhcp, norfc1818
- - If you use line continuation to break a comma-separated
- list, the continuation line(s) must begin in column 1 (or
- there would be embedded white space)
- - Entries in a comma-separated list may appear
- in any order.
-
-
-
-Port Numbers/Service Names
-
-Unless otherwise specified, when giving a port number you can use either
-an integer or a service name from /etc/services.
-
-Port Ranges
-
-If you need to specify a range of ports, the proper syntax is <low
- port number>:<high port number>. For example,
- if you want to forward the range of tcp ports 4000 through 4100 to
-local host 192.168.1.3, the entry in /etc/shorewall/rules is:
-
-
- DNAT net loc:192.168.1.3 tcp 4000:4100
- If you omit the low port number, a value of zero is assumed; if you omit
- the high port number, a value of 65535 is assumed.
-
-Using Shell Variables
-
-You may use the /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
-
-Example:
-
-
- NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
-
-
-
- Example (/etc/shorewall/interfaces record):
-
-
- net $NET_IF $NET_BCAST $NET_OPTIONS
-
-
-The result will be the same as if the record had been written
-
-
- net eth0 130.252.100.255 routefilter,norfc1918
-
-
-Variables may be used anywhere in the other configuration
- files.
-
-Using MAC Addresses
-
-Media Access Control (MAC) addresses can be used to specify packet
- source in several of the configuration files. To use this
-feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
- included.
-
-MAC addresses are 48 bits wide and each Ethernet Controller has a unique
-MAC address.
-
- In GNU/Linux, MAC addresses are usually written
-as a series of 6 hex numbers separated by colons. Example:
-
- [root@gateway root]# ifconfig eth0
- eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
- inet addr:206.124.146.176 Bcast:206.124.146.255
- Mask:255.255.255.0
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
- RX packets:2398102 errors:0 dropped:0 overruns:0
- frame:0
- TX packets:3044698 errors:0 dropped:0 overruns:0
- carrier:0
- collisions:30394 txqueuelen:100
- RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
- (1582.8 Mb)
- Interrupt:11 Base address:0x1800
-
- Because Shorewall uses colons as a separator for
-address fields, Shorewall requires MAC addresses to be written
-in another way. In Shorewall, MAC addresses begin with a tilde
-("~") and consist of 6 hex numbers separated by hyphens. In Shorewall,
-the MAC address in the example above would be written "~02-00-08-E3-FA-55".
-
-
-Note: It is not necessary to use the special Shorewall notation
- in the /etc/shorewall/maclist file.
-
-
-Shorewall Configurations
-
- Shorewall allows you to have configuration directories other than /etc/shorewall.
- The shorewall start
-and restart commands allow you to specify an alternate configuration
- directory and Shorewall will use the files in the alternate directory
- rather than the corresponding files in /etc/shorewall. The alternate
-directory need not contain a complete configuration; those files not
-in the alternate directory will be read from /etc/shorewall.
-
- This facility permits you to easily create a test or temporary configuration
- by:
-
-
- - copying the files that need modification
-from /etc/shorewall to a separate directory;
- - modify those files in the separate directory;
- and
- - specifying the separate directory in a shorewall
- start or shorewall restart command (e.g., shorewall -c /etc/testconfig
- restart )
-
-
-
- Updated 4/18/2003 - Tom Eastep
-
-Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
-
+Warning: If you copy or edit your configuration
+files on a system running Microsoft Windows, you must
+ run them through dos2unix
+ before you use them with Shorewall.
+
+Files
+
+Shorewall's configuration files are in the directory /etc/shorewall.
+
+
+ - /etc/shorewall/shorewall.conf - used to set
+ several firewall parameters.
+ - /etc/shorewall/params - use this file to
+set shell variables that you will expand in other files.
+ - /etc/shorewall/zones - partition the firewall's
+ view of the world into zones.
+ - /etc/shorewall/policy - establishes firewall
+ high-level policy.
+ - /etc/shorewall/interfaces - describes the
+interfaces on the firewall system.
+ - /etc/shorewall/hosts - allows defining zones
+ in terms of individual hosts and subnetworks.
+ - /etc/shorewall/masq - directs the firewall
+ where to use many-to-one (dynamic) Network Address Translation
+ (a.k.a. Masquerading) and Source Network Address Translation
+ (SNAT).
+ - /etc/shorewall/modules - directs the firewall
+ to load kernel modules.
+ - /etc/shorewall/rules - defines rules that
+are exceptions to the overall policies established in /etc/shorewall/policy.
+ - /etc/shorewall/nat - defines static NAT rules.
+ - /etc/shorewall/proxyarp - defines use of
+Proxy ARP.
+ - /etc/shorewall/routestopped (Shorewall 1.3.4
+ and later) - defines hosts accessible when Shorewall is stopped.
+ - /etc/shorewall/tcrules - defines marking
+of packets for later use by traffic control/shaping or policy
+routing.
+ - /etc/shorewall/tos - defines rules for setting
+ the TOS field in packet headers.
+ - /etc/shorewall/tunnels - defines IPSEC, GRE
+ and IPIP tunnels with end-points on the firewall system.
+ - /etc/shorewall/blacklist - lists blacklisted
+ IP/subnet/MAC addresses.
+ - /etc/shorewall/init - commands that you wish to execute at the
+ beginning of a "shorewall start" or "shorewall restart".
+ - /etc/shorewall/start - commands that you wish to execute at
+the completion of a "shorewall start" or "shorewall restart"
+ - /etc/shorewall/stop - commands that you wish to execute at the
+ beginning of a "shorewall stop".
+ - /etc/shorewall/stopped - commands that you wish to execute at
+ the completion of a "shorewall stop".
+ - /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN
+ - RFC 3168) to remote hosts or networks.
+
+
+
+
+Comments
+
+You may place comments in configuration files by making the first non-whitespace
+ character a pound sign ("#"). You may also place comments
+at the end of any line, again by delimiting the comment from
+the rest of the line with a pound sign.
+
+Examples:
+
+# This is a comment
+
+ACCEPT net fw tcp www #This is an end-of-line comment
+
+Line Continuation
+
+You may continue lines in the configuration files using the usual backslash
+ ("\") followed immediately by a new line character.
+
+Example:
+
+ACCEPT net fw tcp \
smtp,www,pop3,imap #Services running on the firewall
+
+INCLUDE Directive
+ Beginning with Shorewall version 1.4.2, any file may contain INCLUDE directives.
+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.
+ INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives
+ are ignored with a warning message.
+
+ 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 -----
+
+
+Using DNS Names
+
+
+
+WARNING: I personally recommend strongly against
+ using DNS names in Shorewall configuration files. If you use DNS
+ names and you are called out of bed at 2:00AM because Shorewall won't
+ start as a result of DNS problems then don't say that you were not
+forewarned.
+
+
+ -Tom
+
+
+Beginning with Shorewall 1.3.9, Host addresses in Shorewall
+ configuration files may be specified as either IP addresses or DNS
+ Names.
+
+ DNS names in iptables rules aren't nearly as useful as
+ they first appear. When a DNS name appears in a rule, the iptables
+ utility resolves the name to one or more IP addresses and inserts
+ those addresses into the rule. So changes in the DNS->IP address
+ relationship that occur after the firewall has started have absolutely
+ no effect on the firewall's ruleset.
+
+ If your firewall rules include DNS names then:
+
+
+ - If your /etc/resolv.conf is wrong then your firewall
+ won't start.
+ - If your /etc/nsswitch.conf is wrong then your firewall
+ won't start.
+ - If your Name Server(s) is(are) down then your firewall
+ won't start.
+ - If your startup scripts try to start your firewall
+ before starting your DNS server then your firewall won't start.
+
+ - Factors totally outside your control (your ISP's
+router is down for example), can prevent your firewall from starting.
+ - You must bring up your network interfaces prior to
+ starting your firewall.
+
+
+
+
+ Each DNS name much be fully qualified and include a minumum
+ of two periods (although one may be trailing). This restriction
+is imposed by Shorewall to insure backward compatibility with existing
+ configuration files.
+
+ Examples of valid DNS names:
+
+
+
+ - mail.shorewall.net
+ - shorewall.net. (note the trailing period).
+
+
+ Examples of invalid DNS names:
+
+
+ - mail (not fully qualified)
+ - shorewall.net (only one period)
+
+
+ DNS names may not be used as:
+
+
+ - The server address in a DNAT rule (/etc/shorewall/rules
+ file)
+ - In the ADDRESS column of an entry in /etc/shorewall/masq.
+ - In the /etc/shorewall/nat file.
+
+
+ These restrictions are not imposed by Shorewall simply
+ for your inconvenience but are rather limitations of iptables.
+
+Complementing an Address or Subnet
+
+Where specifying an IP address, a subnet or an interface, you can precede
+the item with "!" to specify the complement of the item. For example,
+!192.168.1.4 means "any host but 192.168.1.4". There must be no white space
+following the "!".
+
+Comma-separated Lists
+
+Comma-separated lists are allowed in a number of contexts within the
+ configuration files. A comma separated list:
+
+
+ - Must not have any embedded white space.
+ Valid: routefilter,dhcp,norfc1918
+ Invalid: routefilter, dhcp,
+norfc1818
+ - If you use line continuation to break a comma-separated
+ list, the continuation line(s) must begin in column 1 (or
+ there would be embedded white space)
+ - Entries in a comma-separated list may appear
+ in any order.
+
+
+
+Port Numbers/Service Names
+
+Unless otherwise specified, when giving a port number you can use either
+an integer or a service name from /etc/services.
+
+Port Ranges
+
+If you need to specify a range of ports, the proper syntax is <low
+ port number>:<high port number>. For
+example, if you want to forward the range of tcp ports 4000 through
+4100 to local host 192.168.1.3, the entry in /etc/shorewall/rules is:
+
+
+ DNAT net loc:192.168.1.3 tcp 4000:4100
+ If you omit the low port number, a value of zero is assumed; if you omit
+ the high port number, a value of 65535 is assumed.
+
+Using Shell Variables
+
+You may use the /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
+
+Example:
+
+
+ NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
+
+
+
+ Example (/etc/shorewall/interfaces record):
+
+
+ net $NET_IF $NET_BCAST $NET_OPTIONS
+
+
+The result will be the same as if the record had been written
+
+
+ net eth0 130.252.100.255 routefilter,norfc1918
+
+
+
+Variables may be used anywhere in the other configuration
+ files.
+
+Using MAC Addresses
+
+Media Access Control (MAC) addresses can be used to specify packet
+ source in several of the configuration files. To use this
+feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
+ included.
+
+MAC addresses are 48 bits wide and each Ethernet Controller has a unique
+MAC address.
+
+ In GNU/Linux, MAC addresses are usually written
+as a series of 6 hex numbers separated by colons. Example:
+
+ [root@gateway root]# ifconfig eth0
+ eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
+ inet addr:206.124.146.176 Bcast:206.124.146.255
+ Mask:255.255.255.0
+ UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
+ RX packets:2398102 errors:0 dropped:0 overruns:0
+ frame:0
+ TX packets:3044698 errors:0 dropped:0 overruns:0
+ carrier:0
+ collisions:30394 txqueuelen:100
+ RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
+ (1582.8 Mb)
+ Interrupt:11 Base address:0x1800
+
+ Because Shorewall uses colons as a separator for
+ address fields, Shorewall requires MAC addresses to be written
+ in another way. In Shorewall, MAC addresses begin with a tilde
+ ("~") and consist of 6 hex numbers separated by hyphens. In Shorewall,
+ the MAC address in the example above would be written "~02-00-08-E3-FA-55".
+
+
+Note: It is not necessary to use the special Shorewall notation
+ in the /etc/shorewall/maclist file.
+
+
+Shorewall Configurations
+
+ Shorewall allows you to have configuration directories other than /etc/shorewall.
+ The shorewall check,
+start and restart commands allow you to specify an alternate
+configuration directory and Shorewall will use the files in the alternate
+directory rather than the corresponding files in /etc/shorewall. The
+alternate directory need not contain a complete configuration; those
+files not in the alternate directory will be read from /etc/shorewall.
+
+ This facility permits you to easily create a test or temporary configuration
+ by:
+
+
+ - copying the files that need modification
+ from /etc/shorewall to a separate directory;
+ - modify those files in the separate directory;
+ and
+ - specifying the separate directory in a
+shorewall start or shorewall restart command (e.g., shorewall
+-c /etc/testconfig restart )
+
+
+The try command
+allows you to attempt to restart using an alternate configuration and if
+an error occurs to automatically restart the standard configuration.
+
+ Updated 6/29/2003 - Tom Eastep
+
+
+Copyright
+ © 2001, 2002, 2003 Thomas M. Eastep.
+
diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm
index 9c3fcd3e6..33ec13f8f 100644
--- a/Shorewall-docs/download.htm
+++ b/Shorewall-docs/download.htm
@@ -1,191 +1,217 @@
-
+
-
+
-
+
-
+
Download
-
+
-
-
- |
-
+ |
+
+
+
Shorewall Download
- |
-
-
-
+
+
+
+
-
+
I strongly urge you to read and print a copy of the Shorewall QuickStart Guide
for the configuration that most closely matches your own.
-
-
+
+
The entire set of Shorewall documentation is available in PDF format at:
-
+
ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- http://slovakia.shorewall.net/pub/shorewall/pdf/
- rsync://slovakia.shorewall.net/shorewall/pdf/
-
-
+ rsync://slovakia.shorewall.net/shorewall/pdf/
+
+
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
+
- 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
- Instructions if you have problems installing the RPM.
- - If you are running LRP, download the .lrp file
- (you might also want to download the .tgz so you will have a
-copy of the documentation).
- - If you run Debian
- and would like a .deb package, Shorewall is included in both
- the Installation
+ Instructions if you have problems installing the RPM.
+ - If you are running LRP, download the .lrp
+file (you might also want to download the .tgz so you will
+have a copy of the documentation).
+ - If you run Debian and would
+ like a .deb package, Shorewall is included in both the Debian
Testing Branch and the Debian Unstable
- Branch.
- - Otherwise, download the shorewall
- module (.tgz)
-
+ Branch.
+ - Otherwise, download the shorewall
+ module (.tgz)
+
-
+
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:
-
-
-
+ 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.
-
+ 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 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.
+
-
+
Download Sites:
-
-
+
+
-
-
+
+
CVS:
-
-
+
+
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.
-
-
-
-Last Updated 3/24/2003 - 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.
+
+
+
+Last Updated 6/19/2003 - Tom Eastep
-
+
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
+
+
+
diff --git a/Shorewall-docs/myfiles.htm b/Shorewall-docs/myfiles.htm
index ad126154b..e93b58c61 100644
--- a/Shorewall-docs/myfiles.htm
+++ b/Shorewall-docs/myfiles.htm
@@ -1,238 +1,244 @@
-
+
My Shorewall Configuration
-
+
-
+
-
+
-
+
-
-
- |
-
+ |
+
+
+
About My Network
- |
-
-
-
+
+
+
+
-
+
-
+
My Current Network
-
-
- 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.
-
-
- Warning 2: My
- configuration uses features introduced in Shorewall version 1.4.4b.
-
-
- 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).
-
+
+
+ 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.
+
+
+ Warning 2: The
+configuration shown here corresponds to Snapshot 1.4.5_20030629 plus a couple
+of patches.
+
+
+ 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).
+
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 the
-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.
-
-
- 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.
-
- 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.
-
- 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 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
+
+
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.
+
+
+ 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.
+
+ 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.
+
+ 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 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.
-
+ href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG running
+ 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,
+
+
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 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.
-
-
+ 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.
+
+
-
-
+
+
Shorewall.conf
-
-
- LOGFILE=/var/log/messages
LOGRATE=
LOGBURST=
LOGUNCLEAN=$LOG
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
RFC1918_LOG_LEVEL=$LOG
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SUBSYSLOCK=/var/lock/subsys/shorewall
STATEDIR=/var/state/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=Yes
ROUTE_FILTER=No
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
SHARED_DIR=/usr/share/shorewall
-
-
+
+
+ LOGFILE=/var/log/messages
LOGRATE=
LOGBURST=
LOGUNCLEAN=$LOG
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
RFC1918_LOG_LEVEL=$LOG
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHOREWALL_SHELL=/bin/ash
SUBSYSLOCK=/var/lock/subsys/shorewall
STATEDIR=/var/state/shorewall
MODULESDIR=
FW=fw
IP_FORWARDING=On
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=Yes
TC_ENABLED=Yes
CLEAR_TC=No
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=Yes
ROUTE_FILTER=No
NAT_BEFORE_RULES=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
SHARED_DIR=/usr/share/shorewall
+
+
Params File (Edited):
-
-
+
+
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.
-
-
-
+
+
+ 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.
-
-
-
+
+
+ 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.
+
+
+
#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
-
-
-Tom Eastep
- Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
+
+
+Last updated 6/30/2003 - Tom Eastep
+
+ Copyright
+ © 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
diff --git a/Shorewall-docs/quotes.htm b/Shorewall-docs/quotes.htm
index c38f3c18d..5c6f7a9cd 100644
--- a/Shorewall-docs/quotes.htm
+++ b/Shorewall-docs/quotes.htm
@@ -1,108 +1,115 @@
-
+
-
+
-
+
-
+
Quotes from Shorewall Users
-
+
-
-
- |
+ |
+
+
Quotes from Shorewall Users
- |
-
-
-
+
+
+
+
-
-"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
+ "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
+
+
"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:
-
+
+ "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
+
- 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!!!"
+ 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."
+
+
"[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
+
+
"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
+
+
"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
+
+
"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."
+
+
"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."
-- RP, Guatamala
-
-
-
-Updated 3/18/2003
- - Tom Eastep
-
-
-Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
+
+
+Updated 7/1/2003
+ - Tom Eastep
+
+
+Copyright
+ © 2001, 2002, 2003 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm
index 9dcad3225..2b5ed0fbd 100644
--- a/Shorewall-docs/seattlefirewall_index.htm
+++ b/Shorewall-docs/seattlefirewall_index.htm
@@ -2,67 +2,74 @@
-
+
+
Shoreline Firewall (Shorewall) 1.4
-
+
-
+
+
-
+
-
+
- 
- |
-
+ |
+
-
+
+
Shorewall 1.4 "iptables made easy"
- |
-
+ |
+
+
-
- |
-
+
+
+
+
-
-
+
+
-
-
-
+
+
+
+
-
+
-
+
- |
+ |
-
+
+
What is it?
-
+
+
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
@@ -70,34 +77,36 @@
-
+
+
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.
+ 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
+ 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
-
+
+
Copyright 2001, 2002, 2003 Thomas M. Eastep
@@ -106,360 +115,305 @@ the GNU General Public License
-
+
+
Running Shorewall on Mandrake with a two-interface setup?
- If so, almost NOTHING on this site will apply directly
- to your setup. If you want to use the documentation that you find here,
- it is best if you uninstall what you have and install a setup that
-matches the documentation on this site. See the on 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.
-
+
Getting Started with Shorewall
- New to Shorewall? Start by selecting the QuickStart Guide that most closely
- match your environment and follow the step by step instructions.
+ match your environment and follow the step by step instructions.
-
+
News
-
- 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/26/2003 - lists.shorewall.net Downtime
-
-
-
- The list server will be down this morning for upgrade to RH9.0.
-
-
-
-
- 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/12/2002 - Greater Seattle Linux Users Group Presentation
-
-
-
- This morning, I gave a
- Shorewall presentation to GSLUG. The presentation
- is in HTML format but was generated from Microsoft PowerPoint and
- is best viewed using Internet Explorer (although Konqueror also seems
- to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor
- Netscape work well to view the presentation.
-
+ 7/4/2003 - Shorewall-1.4.6 Beta 1
+
+
+
+ http://shorewall.net/pub/shorewall/testing
+ ftp://shorewall.net/pub/shorewall/testing
+
+
+ Problems Corrected:
+
+
+
+ - A problem seen on RH7.3 systems where Shorewall encountered
+start errors when started using the "service" mechanism has been worked around.
+
+
+ - Previously, 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.
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
More News
-
+
+
- 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.3.14 and Kernel-2.4.20. You
- can find their work at: 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!!!
+ Congratulations to Jacques and Eric on the recent
+ release of Bering 1.2!!!
-
+
+
Donations
- |
+
-
-
+
-
+
Extended Search
-
- |
+
+
-
+
-
-
+
+
+
-
+
-
Updated 6/17/2003 - Tom Eastep
-
-
+
+
+Updated 7/4/2003 - Tom Eastep
+
+
+
+
+
diff --git a/Shorewall-docs/shorewall_extension_scripts.htm b/Shorewall-docs/shorewall_extension_scripts.htm
index 9b9fbe0c5..cc49236ae 100644
--- a/Shorewall-docs/shorewall_extension_scripts.htm
+++ b/Shorewall-docs/shorewall_extension_scripts.htm
@@ -1,126 +1,114 @@
-
+
-
+
-
+
-
+
Shorewall Extension Scripts
-
-
+
-
-
-
-
- |
-
+ |
+
+
Extension Scripts
-
- |
-
-
-
-
-
+
+
+
+
-
-
+
Extension scripts are user-provided scripts that are invoked at various
-points during firewall start, restart, stop and clear. The scripts are
-placed in /etc/shorewall and are processed using the Bourne shell "source"
-mechanism. The following scripts can be supplied:
-
+ points during firewall start, restart, stop and clear. The scripts are
+ placed in /etc/shorewall and are processed using the Bourne shell "source"
+ mechanism.
+
+Caution:
+
+
+
+ - Be sure that you actually need to use an extension
+script to do what you want. Shorewall has a wide range of features that cover
+most requirements.
+ - DO NOT SIMPLY COPY RULES THAT YOU FIND ON
+THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK
+SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE DOING
+WITH RESPECT TO iptables/Netfilter
+
+The following scripts can be supplied:
+
- - init -- invoked early in "shorewall start" and "shorewall
-restart"
- - start -- invoked after the firewall has been started or restarted.
- - stop -- invoked as a first step when the firewall is being stopped.
- - stopped -- invoked after the firewall has been stopped.
- - clear -- invoked after the firewall has been cleared.
- - refresh -- invoked while the firewall is being refreshed but before
-the common and/or blacklst chains have been rebuilt.
- - newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn'
-chain has been created but before any rules have been added to it.
-
+ - init -- invoked early in "shorewall start" and "shorewall
+ restart"
+ - start -- invoked after the firewall has been started or restarted.
+ - stop -- invoked as a first step when the firewall is being stopped.
+ - stopped -- invoked after the firewall has been stopped.
+ - clear -- invoked after the firewall has been cleared.
+ - refresh -- invoked while the firewall is being refreshed but before
+ the common and/or blacklst chains have been rebuilt.
+ - newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn'
+ chain has been created but before any rules have been added to it.
+
-
-
-
-
+
If your version of Shorewall doesn't have the file that you want
-to use from the above list, you can simply create the file yourself.
-
+ to use from the above list, you can simply create the file yourself.
+
You can also supply a script with the same name as any of the filter
- chains in the firewall and the script will be invoked after the /etc/shorewall/rules
- file has been processed but before the /etc/shorewall/policy file has
-been processed.
-
-
-
-
+ chains in the firewall and the script will be invoked after the /etc/shorewall/rules
+ file has been processed but before the /etc/shorewall/policy file has
+ been processed.
+
The /etc/shorewall/common file receives special treatment. If this file
-is present, the rules that it defines will totally replace the default
-rules in the common chain. These default rules are contained in the
-file /etc/shorewall/common.def which may be used as a starting point
-for making your own customized file.
-
-
-
-
+ is present, the rules that it defines will totally replace the default
+ rules in the common chain. These default rules are contained in
+the file /etc/shorewall/common.def which may be used as a starting
+point for making your own customized file.
+
Rather than running iptables directly, you should run it using the
- function run_iptables. Similarly, rather than running "ip" directly,
-you should use run_ip. These functions accept the same arguments as the
- underlying command but cause the firewall to be stopped if an error occurs
- during processing of the command.
-
-
-
-
+ function run_iptables. Similarly, rather than running "ip" directly, you
+should use run_ip. These functions accept the same arguments as the underlying
+command but cause the firewall to be stopped if an error occurs during processing
+of the command.
+
If you decide to create /etc/shorewall/common it is a good idea to use
the following technique
-
-
-
-
+
/etc/shorewall/common:
-
-
-
-
-
-
+
+
. /etc/shorewall/common.def
<add your rules here>
-
-
+
+
If you need to supercede a rule in the released common.def file, you can
-add the superceding rule before the '.' command. Using this technique allows
- you to add new rules while still getting the benefit of the latest common.def
- file.
-
-
-
+ add the superceding rule before the '.' command. Using this technique
+allows you to add new rules while still getting the benefit of the latest
+common.def file.
+
Remember that /etc/shorewall/common defines rules that are only applied
-if the applicable policy is DROP or REJECT. These rules are NOT applied
-if the policy is ACCEPT or CONTINUE.
-
-
-
-Last updated 2/18/2003 -
+
+
+
+
+Last updated 6/30/2003 - Tom Eastep
-
+
Copyright 2002, 2003
-Thomas M. Eastep
+ Thomas M. Eastep
+
+
diff --git a/Shorewall-docs/shorewall_mirrors.htm b/Shorewall-docs/shorewall_mirrors.htm
index 396d6d401..c4d2f6b36 100644
--- a/Shorewall-docs/shorewall_mirrors.htm
+++ b/Shorewall-docs/shorewall_mirrors.htm
@@ -1,93 +1,96 @@
-
+
-
+
-
+
-
+
Shorewall Mirrors
-
+
-
-
- |
+ |
+
+
Shorewall Mirrors
- |
-
-
-
+
+
+
+
-
-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)
+
+
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.
-
+
The main Shorewall Web Site is http://shorewall.sf.net
+ href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net
and is located in California, USA. It is mirrored at:
-
+
-
+
The rsync site is mirrored via FTP at:
-
+
- Search results and the mailing list archives are always fetched from
-the site in Washington State.
-
-Last Updated 6/5/2003 -
+
+Last Updated 6/19/2003 - Tom Eastep
-
+
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
+
+
diff --git a/Shorewall-docs/shorewall_prerequisites.htm b/Shorewall-docs/shorewall_prerequisites.htm
index c6b27fda9..8d8aa82e3 100644
--- a/Shorewall-docs/shorewall_prerequisites.htm
+++ b/Shorewall-docs/shorewall_prerequisites.htm
@@ -1,68 +1,80 @@
-
+
-
+
-
+
-
+
Shorewall Prerequisites
-
+
-
-
- |
+ |
+
+
Shorewall Requirements
- |
-
-
-
+
+
+
+
-
- Shorewall Requires:
-
+
+ Shorewall Requires:
+
- - A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20.
-With current releases of Shorewall, Traffic Shaping/Control requires at least
-2.4.18. Check here for kernel configuration
- information. If you are looking for a firewall for use with
-2.2 kernels, see the Seattle Firewall
- site .
- - iptables 1.2 or later but beware version 1.2.3 -- see the A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20.
+ With current releases of Shorewall, Traffic Shaping/Control requires at
+least 2.4.18. Check here for kernel configuration
+ information. If you are looking for a firewall for use with
+ 2.2 kernels, see the Seattle
+Firewall site .
+ - iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The
- buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
- upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
- is available from RedHat
- and in the Shorewall Errata.
- - Iproute ("ip" utility). The iproute package is included with
-most distributions but may not be installed by default. The official
-download site is Shorewall Errata.
+ - Iproute ("ip" utility). The iproute package is included
+with most distributions but may not be installed by default. The official
+ download site is ftp://ftp.inr.ac.ru/ip-routing.
+
+ - A Bourne shell or derivative such as bash or ash. This shell
+must have correct support for variable expansion formats ${variable%pattern
+ }, ${variable%%pattern}, ${variable#pattern
+ } and ${variable##pattern}.
+ - Must produce a sensible result when a number n (128 <= n <= 255)
+is left shifted by 24 bits. You can check this at a shell prompt by:
+
+
+ - echo $((128 << 24))
- - A Bourne shell or derivative such as bash or ash. This shell must
- have correct support for variable expansion formats ${variable%pattern
- }, ${variable%%pattern}, ${variable#pattern
- } and ${variable##pattern}.
- - The firewall monitoring display is greatly improved if you have
- awk (gawk) installed.
-
+ - The result must be either 2147483648 or -2147483648.
+
+
+
+ - The firewall monitoring display is greatly improved if you have
+ awk (gawk) installed.
+
-
-Last updated 3/19/2003 - Last updated 7/4/2003 - Tom Eastep
-
+
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm
index 08fb15740..caac7ea7f 100644
--- a/Shorewall-docs/shorewall_setup_guide.htm
+++ b/Shorewall-docs/shorewall_setup_guide.htm
@@ -1,2613 +1,2617 @@
-
+
-
+
-
+
-
+
Shorewall Setup Guide
-
+
-
+
Shorewall Setup Guide
-
+
1.0 Introduction
- 2.0 Shorewall Concepts
- 3.0 Network Interfaces
- 4.0 Addressing, Subnets and Routing
-
-
+ 2.0 Shorewall Concepts
+ 3.0 Network Interfaces
+ 4.0 Addressing, Subnets and Routing
+
+
4.1 IP Addresses
- 4.2 Subnets
- 4.3 Routing
- 4.4 Address Resolution Protocol (ARP)
- 4.5 RFC 1918
-
-
+ 4.2 Subnets
+ 4.3 Routing
+ 4.4 Address Resolution Protocol (ARP)
+ 4.5 RFC 1918
+
+
5.0 Setting up your Network
-
-
+
+
5.1 Routed
- 5.2 Non-routed
-
-
+ 5.2 Non-routed
+
+
5.2.1 SNAT
- 5.2.2 DNAT
- 5.2.3 Proxy ARP
- 5.2.4 Static NAT
-
-
+ 5.2.2 DNAT
+ 5.2.3 Proxy ARP
+ 5.2.4 Static NAT
+
+
5.3 Rules
- 5.4 Odds and Ends
-
-
+ 5.4 Odds and Ends
+
+
6.0 DNS
- 7.0 Starting and Stopping the
-Firewall
-
+ 7.0 Starting and Stopping the
+ Firewall
+
1.0 Introduction
-
-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
+
+
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
+ 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:
-
+
+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.
+
-
+
2.0 Shorewall Concepts
-
-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
+
+
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:
-
+
+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:
+
-
+
+
+ | Name |
+ Description |
+
- | Name |
- Description |
-
-
- | net |
- The Internet |
-
-
- | loc |
- Your Local Network |
-
-
- | dmz |
- Demilitarized Zone |
-
-
-
+ net |
+ The Internet |
+
+
+ | loc |
+ Your Local Network |
+
+
+ | dmz |
+ Demilitarized Zone |
+
+
+
-
-Zones are defined in the /etc/shorewall/zones
- file.
-
-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
+
+
Zones are defined in the /etc/shorewall/zones
+ file.
+
+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
+ 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.
-
+
+Rules about what traffic to allow and what traffic to deny are expressed
+ in terms of zones.
+
-
- 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:
-
+
+ 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:
+
- - 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
+
+
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.
-
+
+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 |
+
- | Source Zone |
- Destination Zone |
- Policy |
- Log Level |
- Limit:Burst |
-
-
- | loc |
- net |
- ACCEPT |
- |
- |
-
-
- | net |
- all |
- DROP |
- info |
- |
-
-
- | all |
- all |
- REJECT |
- info |
- |
-
-
-
+ loc |
+ net |
+ ACCEPT |
+ |
+ |
+
+
+ | net |
+ all |
+ DROP |
+ info |
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+ |
+
+
+
-
-
+
+
The above policy will:
-
+
- - allow all connection requests from your local network
+
- 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.
-
+ - 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 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
+
- The Local Zone consists of systems Local 1, Local 2 and
Local 3.
- - All systems from the ISP outward comprise the Internet
-Zone.
-
+ - 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
+
+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.
-
+
+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.
+
- If your external interface is ppp0 or ippp0 then
- you will want to set CLAMPMSS=yes in 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
+
+
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.
-
+ 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.
+
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 |
+
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- detect |
- norfc1918 |
-
-
- | loc |
- eth1 |
- detect |
- |
-
-
- | dmz |
- eth2 |
- detect |
- |
-
-
-
+ 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.
-
+ 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 |
+
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- detect |
- norfc1918 |
-
-
- | loc |
- eth1 |
- detect |
- |
-
-
- | loc |
- eth2 |
- detect |
- dhcp |
-
-
-
+ 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.
-
+ 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 0-13-975483-0.
-
+
+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
+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
+
+
+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:
-
+
+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 last address in the subnet is reserved as the subnet's
- broadcast address.
-
-
+
+ -
+
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.
+
+
-
-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) |
+
- | 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 |
-
-
-
+ 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 |
+
- | 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 |
-
-
-
+ 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:
-
-
- 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0
- = 255.255.255.192
-
-
-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 CIDR Notation.
-
+
+
+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:
+
+
+ 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0
+ = 255.255.255.192
+
+
+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 CIDR Notation.
+
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 |
+
- | 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 |
-
-
-
+ 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.
-
-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
+
+
+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.
-
+
Example: 192.0.2.65/29
-
- The interface is configured with IP address 192.0.2.65
- and netmask 255.255.255.248.
-
+
+ The interface is configured with IP address 192.0.2.65
+ and netmask 255.255.255.248.
+
4.3 Routing
-
-One of the purposes of subnetting is that it forms the basis
- for routing. Here's the routing table on my firewall:
-
-
-
+
+One of the purposes of subnetting is that it forms the basis
+ for routing. Here's the routing table on my firewall:
+
+
+
[root@gateway root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
[root@gateway root]#
-
-
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:
+
+
+
+
+
[root@gateway root]# tcpdump -nei eth2 arp
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0
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' command:
-
-
-
+
+
+
+
+
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:
-
-
+ href="http://www.iana.org">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:
+
+
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
+
+
+
+
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.
-
-
-
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:
-
-
-
+
+
+
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
+
+
+
+
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.
-
-
-
-
-
-
In the subsections that follow, we'll look at each of these
- separately.
-
-
+
+
+
+ -
+
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.
+
+
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:
-
-
+ 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
- - IP_FORWARDING=On
-
-
+ - NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
+ - IP_FORWARDING=On
+
+
-
-
-
-
-
-
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.
-
-
-
+
+
+
+
+
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:
-
-
-
+
+
+
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.
-
-
-
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
+
+
+
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.
-
-
-
+
+
+
+
+
+
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.
-
-
-
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
+
+
+
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.
-
+
+
+
+
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).
-
-
- -
-
Destination Network Address Translation (DNAT)
- also known as Port Forwarding.
-
- -
+
-
+
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.
-
-
+
+ -
+
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.
-
Often a combination of these techniques is used. Each of
-these will be discussed in the sections that follow.
-
+
+
+
+
+
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.
-
-
-
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.
-
-
-
+
+
+
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 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).
-
+ 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).
-
+
-
-
-
+
+
+
-
-
- | 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 |
+
+
+
-
-
-
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
+
+
+
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.
-
-
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:
-
-
-
+
+
+
-
-
- | 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
+
+
+
+
+
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.
-
-
-
+
+
+
+
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.
+
+
+
-
-
+
+
+
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).
-
-
-
-
-
-
Let suppose that we decide to use Proxy ARP on the DMZ in
- our example network.
-
-
-
+
+
+
+ -
+
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
+
+
+
+
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.
-
+
-
+
-
-
+
+
+
-
-
- | 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 |
+
+
+
-
-
-
-
-
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,...
+ - (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
+ Illustrated, Vol 1 reveals that a
- "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
+ "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.
-
+
+ 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:
+
+
+
+
+
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):
-
-
-
-
-
+
+
+
+
We can now observe the tcpdump output:
-
-
-
+
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
+
+
+
+
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.
-
-
-
+
+
+
+
+
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:
-
-
-
+
+
+
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:
+
+
+
+
-
-
- | 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 |
+
+
+
-
-
-
-
+
+
+
+
- Suppose now that you have decided to give your daughter
- her own IP address (192.0.2.179) for both inbound and outbound connections.
- You would do that by adding an entry in /etc/shorewall/nat.
-
-
-
+
+
+
-
-
- | 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 |
+
+
+
-
+
+
+
+
+
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:
-
-
-
-
+ 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,
+
- (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
+ "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
+
+ 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:
+
+
-
-
-
Now from the 192.168.201.4, ping the ISP's gateway (which
+
+
+
+
Now from the 192.168.201.4, ping the ISP's gateway (which
we will assume is 192.0.2.254):
-
-
-
-
-
-
+
+
We can now observe the tcpdump output:
-
-
-
+
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.179 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.179 : icmp: echo reply
+
+
+
+
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
-
-
-
+ 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
+distribution.
-
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 |
+
+
+
-
-
+
+
+
+
+
+
+
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.
-
- .
- 
- 
- 
- 
- 
- 
-