From 70b9971612dc290817e59ff0b478aa5026978fbf Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 25 Feb 2003 19:26:18 +0000 Subject: [PATCH] Sync with CVS git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@473 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- STABLE/documentation/FAQ.htm | 2123 +++++------ STABLE/documentation/News.htm | 3099 +++++++++-------- .../documentation/Shorewall_Squid_Usage.html | 792 ++--- STABLE/documentation/errata.htm | 1136 +++--- STABLE/documentation/mailing_list.htm | 413 +-- .../documentation/seattlefirewall_index.htm | 497 +-- STABLE/documentation/sourceforge_index.htm | 475 +-- STABLE/documentation/spam_filters.htm | 79 +- STABLE/documentation/support.htm | 526 +-- STABLE/firewall | 17 +- 10 files changed, 4726 insertions(+), 4431 deletions(-) diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 401f1db4d..cdc341c7b 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -2,1256 +2,1289 @@ - - + + - - + + - - + + - - + + Shorewall FAQ - + - + - - - + + - + + - - - + + +
+
- +

Shorewall FAQs

-
- -

1. I want to forward UDP - port 7777 to my my personal PC with IP address 192.168.1.5. + +

1. I want to forward UDP + port 7777 to my my personal PC with IP address 192.168.1.5. I've looked everywhere and can't find how to do it.

- -

1a. Ok -- I followed those instructions - but it doesn't work.
-

+ +

1a. Ok -- I followed those instructions + but it doesn't work.
+

- -

1b. I'm still having problems with + +

1b. I'm still having problems with port forwarding

- -

2. I port forward www requests - to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 - in my local network. External clients can browse http://www.mydomain.com - but internal clients can't.

+ +

2. I port forward www requests + to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 + in my local network. External clients can browse http://www.mydomain.com + but internal clients can't.

- -

2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 - addresses to hosts in Z. Hosts in Z cannot communicate with - each other using their external (non-RFC1918 addresses) so they - can't access each other using their DNS names.

+ +

2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 + addresses to hosts in Z. Hosts in Z cannot communicate with + each other using their external (non-RFC1918 addresses) so +they can't access each other using their DNS names.

- -

3. I want to use Netmeeting - or MSN Instant Messenger with Shorewall. What do - I do?

+ +

3. I want to use Netmeeting + or MSN Instant Messenger with Shorewall. What +do I do?

- -

4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' - rather than 'blocked'. Why?

+ +

4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' + rather than 'blocked'. Why?

- -

4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!

+ +

4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!

- -

5. I've installed Shorewall and now - I can't ping through the firewall

+ +

5. I've installed Shorewall and now + I can't ping through the firewall

- -

6. Where are the log messages - written and how do I change the destination?

+ +

6. Where are the log messages + written and how do I change the destination?

- -

6a. Are there any log parsers - that work with Shorewall?

- + +

6a. Are there any log parsers + that work with Shorewall?

+

6b. DROP messages on port 10619 are flooding the logs with their connect - requests. Can i exclude these error messages for this port temporarily + href="#faq6b"> 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?
-

- -

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port.  +

+ +

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?
-

- -

6d. Why is the MAC address -in Shorewall log messages so long? I thought MAC addresses were only +

+ +

6d. Why is the MAC address +in Shorewall log messages so long? I thought MAC addresses were only 6 bytes in length.
-

-

7. When I stop Shorewall using -'shorewall stop', I can't connect to anything. Why doesn't that command - work?

+

+ +

7. When I stop Shorewall using + 'shorewall stop', I can't connect to anything. Why doesn't that command + work?

- -

8. When I try to start Shorewall - on RedHat I get messages about insmod failing -- what's - wrong?

+ +

8. When I try to start Shorewall + on RedHat I get messages about insmod failing -- what's + wrong?

- -

9. Why can't Shorewall detect - my interfaces properly?

+ +

9. Why can't Shorewall detect + my interfaces properly?

- -

10. What distributions does - it work with?

+ +

10. What distributions does + it work with?

- -

11. What features does it -support?

+ +

11. What features does it + support?

- +

12. Is there a GUI?

- +

13. Why do you call it "Shorewall"?

- -

14. I'm connected via a cable modem - and it has an internel web server that allows me to configure/monitor - it but as expected if I enable rfc1918 blocking for - my eth0 interface, it also blocks the cable modems web -server.

+ +

14. I'm connected via a cable modem + and it has an internel web server that allows me to configure/monitor + it but as expected if I enable rfc1918 blocking +for my eth0 interface, it also blocks the cable modems + web server.

- -

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.

+ +

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.

- -

15. My local systems can't see - out to the net

+ +

15. My local systems can't see + out to the net

- -

16. Shorewall is writing log messages - all over my console making it unusable!
-

- 17. How do I find out why this traffic is -getting logged?
-
- 18. Is there any way -to use aliased ip addresses with Shorewall, and maintain + +

16. Shorewall is writing log messages + all over my console making it unusable!
+

+ 17. How do I find out why this traffic is getting + logged?
+
+ 18. Is there any way + to use aliased ip addresses with Shorewall, and maintain separate rulesets for different IPs?
-
- 19. I have added entries - to /etc/shorewall/tcrules but they don't seem to do +
+ 19. I have added entries + to /etc/shorewall/tcrules but they don't seem to do anything. Why?
-
- 20. I have just set up -a server. Do I have to change Shorewall to allow access to my +
+ 20. I have just set up + a server. Do I have to change Shorewall to allow access to my server from the internet?
-
- 21. I see these strange +
+ 21. I see these strange log entries occasionally; what are they?
-
- 22. I have some iptables commands - that I want to run when Shorewall starts. Which file do -I put them in?
-
- 23. Why do you use such ugly fonts - on your web site?
-
- 24. How can I allow conections to -let's say the ssh port only from specific IP Addresses on the internet?
+
+ 22. I have some iptables commands + that I want to run when Shorewall starts. Which file do I + put them in?
+
+ 23. Why do you use such ugly fonts + on your web site?
+
+ 24. How can I allow conections to + let's say the ssh port only from specific IP Addresses on the +internet?

- -
-

1. I want to forward UDP port 7777 to - my my personal PC with IP address 192.168.1.5. I've looked - everywhere and can't find how to do it.

+25. How to I tell which version of Shorewall +I am running?
+
+ +
+

1. I want to forward UDP port 7777 to + my my personal PC with IP address 192.168.1.5. I've looked + everywhere and can't find how to do it.

- +

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format of a port-forwarding - rule to a local system is as follows:

+ href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding + rule to a local system is as follows:

- -
- + +
+ - + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>
-
-
DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>
+
+
-
- - -

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

- - -
+ + + +
+ + +

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

+ + +
+ - + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + - - - + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-
-
DNATnetloc:192.168.1.5udp7777
+
+
-
+
- -
If - you want to forward requests directed to a particular address ( <external + +
If + you want to forward requests directed to a particular address ( <external IP> ) on your firewall to an internal system:
- -
- + +
+ - + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + - - - + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>-<external IP>
DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>-<external IP>
-
+
-Finally, if you need to forward a range of ports, in the PORT column specify + Finally, if you need to forward a range of ports, in the PORT column specify the range as low-port:high-port.
- -

1a. Ok -- I followed those instructions - but it doesn't work

+ +

1a. Ok -- I followed those instructions + but it doesn't work

- +

Answer: That is usually the result of one of two things:

- +
    -
  • You are trying to test from inside - your firewall (no, that won't work -- see You are trying to test from +inside your firewall (no, that won't work -- see FAQ #2).
    • -
  • You have a more basic problem -with your local system such as an incorrect default gateway -configured (it should be set to the IP address of your firewall's -internal interface).
    • +
  • You have a more basic problem + with your local system such as an incorrect default gateway + configured (it should be set to the IP address of your firewall's + internal interface).
    • - +
- -

1b. I'm still having problems with port + +

1b. I'm still having problems with port forwarding

- Answer: To further diagnose this problem:
- + Answer: To further diagnose this problem:
+
    -
  • As root, type "iptables -t nat -Z". This +
  • As root, type "iptables -t nat -Z". This clears the NetFilter counters in the nat table.
    • -
  • Try to connect to the redirected port from - an external host.
    • -
  • As root type "shorewall show nat"
    • -
  • Locate the appropriate DNAT rule. It will - be in a chain called <source zone>_dnat ('net_dnat' +
  • Try to connect to the redirected port +from an external host.
    • +
  • As root type "shorewall show nat"
    • +
  • Locate the appropriate DNAT rule. It will + be in a chain called <source zone>_dnat ('net_dnat' in the above examples).
    • -
  • Is the packet count in the first column -non-zero? If so, the connection request is reaching the firewall -and is being redirected to the server. In this case, the problem -is usually a missing or incorrect default gateway setting on the -server (the server's default gateway should be the IP address of -the firewall's interface to the server).
    • -
  • If the packet count is zero:
    • +
  • Is the packet count in the first column + non-zero? If so, the connection request is reaching the firewall + and is being redirected to the server. In this case, the problem + is usually a missing or incorrect default gateway setting on +the server (the server's default gateway should be the IP address + of the firewall's interface to the server).
    • +
  • If the packet count is zero:
    • - +
      -
    • the connection request is not reaching +
    • the connection request is not reaching your server (possibly it is being blocked by your ISP); or
      • -
    • you are trying to connect to a secondary - IP address on your firewall and your rule is only redirecting -the primary IP address (You need to specify the secondary IP address - in the "ORIG. DEST." column in your DNAT rule); or
      • -
    • your DNAT rule doesn't match the connection - request in some other way. In that case, you may have to use a - packet sniffer such as tcpdump or ethereal to further diagnose the - problem.
      -
      • +
    • you are trying to connect to a secondary + IP address on your firewall and your rule is only redirecting +the primary IP address (You need to specify the secondary IP address + in the "ORIG. DEST." column in your DNAT rule); or
      • +
    • your DNAT rule doesn't match the connection + request in some other way. In that case, you may have to use +a packet sniffer such as tcpdump or ethereal to further diagnose +the problem.
      +
      • - +
    - +
- -

2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in my local network. - External clients can browse http://www.mydomain.com but internal - clients can't.

+ +

2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in my local +network. External clients can browse http://www.mydomain.com +but internal clients can't.

- +

Answer: I have two objections to this setup.

- +
    -
  • Having an internet-accessible -server in your local network is like raising foxes in the -corner of your hen house. If the server is compromised, there's - nothing between that server and your other internal systems. - For the cost of another NIC and a cross-over cable, you can put - your server in a DMZ such that it is isolated from your local -systems - assuming that the Server can be located near the Firewall, - of course :-)
    • -
  • The accessibility problem is -best solved using Bind -Version 9 "views" (or using a separate DNS server for local -clients) such that www.mydomain.com resolves to 130.141.100.69 -externally and 192.168.1.5 internally. That's what I do here at - shorewall.net for my local systems that use static NAT.
    • +
  • Having an internet-accessible + server in your local network is like raising foxes in +the corner of your hen house. If the server is compromised, +there's nothing between that server and your other internal + systems. For the cost of another NIC and a cross-over cable, + you can put your server in a DMZ such that it is isolated from +your local systems - assuming that the Server can be located +near the Firewall, of course :-)
    • +
  • The accessibility problem is +best solved using Bind + Version 9 "views" (or using a separate DNS server for local + clients) such that www.mydomain.com resolves to 130.141.100.69 + externally and 192.168.1.5 internally. That's what I do here at + shorewall.net for my local systems that use static NAT.
    • - +
- -

If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that your external - interface is eth0 and your internal interface is eth1 and - that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, - do the following:

+ +

If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that your external + interface is eth0 and your internal interface is eth1 +and that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, + do the following:

- -

a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1 (No longer required as of Shorewall version 1.3.9).

+ +

a) In /etc/shorewall/interfaces, specify "multi" as an option + for eth1 (No longer required as of Shorewall version +1.3.9).

- -
+ +

b) In /etc/shorewall/rules, add:

-
- - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
-
- -
-

That rule only works of course if you have a static external - IP address. If you have a dynamic IP address and are running - Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

-
+ +
+
+ + + + + + + + + + + + + + + + + + + + + - -
+ + + +
+ +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
+
+
+ + +
+

That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are +running Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

+
+ + +
     ETH0_IP=`find_interface_address eth0`
+
+ + +
+

and make your DNAT rule:

- -
-

and make your DNAT rule:

-
- - -
-
- + +
+
+ - + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + - - - + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
-
+
+
+ + +
+

Using this technique, you will want to configure your DHCP/PPPoE + client to automatically restart Shorewall each time that + you get a new IP address.

- -
-

Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each time that - you get a new IP address.

-
+ +

2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 addresses + to hosts in Z. Hosts in Z cannot communicate with each other + using their external (non-RFC1918 addresses) so they can't +access each other using their DNS names.

- -

2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 addresses - to hosts in Z. Hosts in Z cannot communicate with each other - using their external (non-RFC1918 addresses) so they can't access - each other using their DNS names.

+ +

Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external +and internal clients to access a NATed host using the host's +DNS name.

- -

Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both external and - internal clients to access a NATed host using the host's DNS - name.

+ +

Another good way to approach this problem is to switch from + static NAT to Proxy ARP. That way, the hosts in Z have +non-RFC1918 addresses and can be accessed externally and internally +using the same address.

- -

Another good way to approach this problem is to switch from - static NAT to Proxy ARP. That way, the hosts in Z have -non-RFC1918 addresses and can be accessed externally and -internally using the same address.

+ +

If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:

- -

If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:

- - -

a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces + +

a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces (If you are running a Shorewall version earlier than 1.3.9).
- b) Set the Z->Z policy to ACCEPT.
- c) Masquerade Z to itself.
-
- Example:

+ b) Set the Z->Z policy to ACCEPT.
+ c) Masquerade Z to itself.
+
+ Example:

- +

Zone: dmz
- Interface: eth2
- Subnet: 192.168.2.0/24

+ Interface: eth2
+ Subnet: 192.168.2.0/24

- +

In /etc/shorewall/interfaces:

- -
- + +
+ - + + + + + + + - - - - - - - - - - - + + + + + - - - + + +
ZONEINTERFACEBROADCASTOPTIONS
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255multi
dmzeth2192.168.2.255multi
-
+
- +

In /etc/shorewall/policy:

- -
- - - - - - - - - - - - - - - - - - - - - -
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
-
- - -

In /etc/shorewall/masq:

- - -
- - - - - - - - - - - - - - - - - - - -
INTERFACE - SUBNETADDRESS
eth2192.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.

- - -

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) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
- b) Copy /etc/shorewall/icmp.def to -/etc/shorewall/icmpdef
- c) Add the following to /etc/shorewall/icmpdef: -

- - +
- -

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:

- - -
-
     LOGLIMIT=""
     LOGBURST=""

Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
-
- - -

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:
- -
    -
  1. They are late-arriving replies to DNS queries.
    2. -
  2. They are corrupted reply packets.
    3. - -
- 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.
- -

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. In 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.

-
- - -

- -

9. Why can't Shorewall detect my interfaces - properly?

- - -

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

- - -
-
     Processing /etc/shorewall/shorewall.conf ...
     Processing /etc/shorewall/params ...
     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
-
- - -
-

If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:

-
- - -
-
- - - - - + - - - + + + + + + + + + + + + + + +
SUBNET TARGET
192.168.100.1RETURN
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
+
+
+ + +

In /etc/shorewall/masq:

+ + +
+ + + + + + + + + + + + + + + + + + + +
INTERFACE + SUBNETADDRESS
eth2192.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.

+ + +

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) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
+ b) Copy /etc/shorewall/icmp.def to +/etc/shorewall/icmpdef
+ c) Add the following to /etc/shorewall/icmpdef: +

+ + +
+ +

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:

+ + +
+
     LOGLIMIT=""
     LOGBURST=""

Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
+
+ + +

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:
+ +
    +
  1. They are late-arriving replies to DNS queries.
    2. +
  2. They are corrupted reply packets.
    3. + +
+ 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.
+ +

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. In 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.

+
+ + +

+ +

9. Why can't Shorewall detect my interfaces + properly?

+ + +

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

+ + +
+
     Processing /etc/shorewall/shorewall.conf ...
     Processing /etc/shorewall/params ...
     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
+
+ + +
+

If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:

-
-

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
-
+ + + + + + + + + - - - + + + +
SUBNET TARGET
192.168.100.1RETURN
-
-
+ +
- -
-

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.

+ +
+

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.

-
-

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:

- - -
    -
  1. - - - -

    The default gateway on each local system isn't set to - the IP address of the local firewall interface.

    -
    2. -
  2. - - - -

    The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.

    -
    3. -
  3. - - - -

    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.

    -
    4. - - -
- - -

16. Shorewall is writing log messages - all over my console making it unusable!

+

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:

-

Answer: "man dmesg" -- 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:
-
    -
  1. man1918 - The destination address - is listed in /etc/shorewall/rfc1918 with a logdrop target - -- see /etc/shorewall/rfc1918.
    2. -
  2. rfc1918 - The source address - is listed in /etc/shorewall/rfc1918 with a logdrop target - -- see /etc/shorewall/rfc1918.
    3. -
  3. all2<zone>, <zone>2all +
  4. + + + +

    The default gateway on each local system isn't set to + the IP address of the local firewall interface.

    +
    5. +
  5. + + + +

    The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.

    +
    6. +
  6. + + + +

    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.

    +
    7. + + +
+ + +

16. Shorewall is writing log messages + all over my console making it unusable!

+ + +

Answer: "man dmesg" -- 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:
+ +
    +
  1. man1918 - The destination +address is listed in /etc/shorewall/rfc1918 with a logdrop + target -- see /etc/shorewall/rfc1918.
    2. +
  2. rfc1918 - The source address + is listed in /etc/shorewall/rfc1918 with a logdrop target + -- see /etc/shorewall/rfc1918.
    3. +
  3. 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 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.
    -
    4. -
  4. <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.
    5. -
  5. <interface>_mac - The packet -is being logged under the maclist +
  6. <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.
    7. +
  7. <interface>_mac - The packet + is being logged under the maclist interface option.
    -
    8. -
  8. logpkt - The packet is being +
    9. +
  9. logpkt - The packet is being logged under the logunclean interface option.
    10. -
  10. badpkt - The packet is being +
  11. badpkt - The packet is being logged under the dropunclean interface option as specified - in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    12. -
  12. blacklst - The packet is being + href="Documentation.htm#Interfaces">interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    13. +
  13. blacklst - The packet is being logged because the source IP is blacklisted in the /etc/shorewall/blacklist file.
    14. -
  14. 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.
    15. -
  15. 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.
    16. -
  16. logflags - The packet is being logged -because it failed the checks implemented by the tcpflags 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.
    17. +
  17. 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.
    18. +
  18. logflags - The packet is being logged + because it failed the checks implemented by the tcpflags interface option.
    -
    19. - + +
- -

18. Is there any way to use aliased ip addresses - with Shorewall, and maintain separate rulesets for different - IPs?

- Answer: Yes. You simply use the IP address - in your rules (or if you use NAT, use the local IP address in - your rules). Note: The ":n" notation (e.g., eth0:0) is deprecated - and will disappear eventually. Neither iproute (ip and tc) nor - iptables supports that notation so neither does Shorewall.
-
- Example 1:
-
- /etc/shorewall/rules - + +

18. Is there any way to use aliased ip addresses + with Shorewall, and maintain separate rulesets for different + IPs?

+ Answer: Yes. You simply use the IP address + in your rules (or if you use NAT, use the local IP address in + your rules). Note: The ":n" notation (e.g., eth0:0) is deprecated + and will disappear eventually. Neither iproute (ip and tc) +nor iptables supports that notation so neither does Shorewall. +
+
+ Example 1:
+
+ /etc/shorewall/rules + 
     # Accept AUTH but only on address 192.0.2.125

     ACCEPT	net	fw:192.0.2.125	tcp	auth
- Example - 2 (NAT):
-
- /etc/shorewall/nat
- + Example + 2 (NAT):
+
+ /etc/shorewall/nat
+ 
     192.0.2.126	eth0	10.1.1.126
- /etc/shorewall/rules - + /etc/shorewall/rules + 
     # Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)

     ACCEPT	net	loc:10.1.1.126	tcp	www
- Example 3 (DNAT):
- + Example 3 (DNAT):
+ 
     # Forward SMTP on external address 192.0.2.127 to local system 10.1.1.127

     DNAT	net	loc:10.1.1.127	tcp	smtp	-	192.0.2.127
+ +

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.
-

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 +

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; +

+ 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 + 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 + 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 + 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.
- + 
    net:<ip1>,<ip2>,...
- Example:
- + Example:
+ 
    ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
+

- +
- Last updated 2/6/2003 - Tom Eastep - -

Copyright -© 2001, 2002, 2003 Thomas M. Eastep.
-

+ +

25. How to I tell which version of Shorewall +I am running?
+

+ At the shell prompt, type:
+
+     /sbin/shorewall version
+
+Last updated 2/22/2003 - Tom Eastep + +

Copyright © +2001, 2002, 2003 Thomas M. Eastep.
+

+
diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 39e4b5262..00f18d51e 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -3,7 +3,7 @@ - + Shorewall News @@ -11,2198 +11,2281 @@ - + - + - + - - - + + - + + - - + +
+
- +

Shorewall News Archive

-
- -

2/8/2003 - Shoreawall 1.3.14

- -

New features include

- + +

2/21/2003 - Shorewall 1.4.0 Beta 1 

+ 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:
+
    -
  1. 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.
    -
    -
    2. -
  2. 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
    -  
    3. -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. -
  4. Support for VLAN devices with names of the form $DEV.$VID (e.g., -eth0.0)
    -
    +
  5. 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.
    +
    +
    6. +
  6. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces + now generate an error.
    +
    +
    7. +
  7. 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.
    +
    +
    8. +
  8. 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.
    +
    +
    9. +
  9. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
    +
    +
    10. +
  10. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    +
    +
    11. +
  11. The icmp.def file has been removed.
    +
    12. + +
+ Changes for 1.4 include:
+ +
    +
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
    +
    +
    2. +
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    3. +
  3. The firewall script and version file are now installed in /usr/share/shorewall.
    +
    +
    4. +
  4. Late arriving DNS replies are now silently dropped in the common +chain by default.
    +
    +
    5. +
  5. 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.
    6. -
  6. 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.
    + +
+ +

2/8/2003 - Shoreawall 1.3.14

+ +

New features include

+ +
    +
  1. 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.
    +
    +
    2. +
  2. 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
    +  
    3. +
  3. Support for OpenVPN Tunnels.
    +
    +
    4. +
  4. Support for VLAN devices with names of the form $DEV.$VID (e.g., + eth0.0)

    5. -
  5. 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
    -
    6. - -
- -


- 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:
-

- -
    -
  1. 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.
    -
    -
    2. -
  2. 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
    -  
    3. -
  3. 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 +
  4. 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.
    +
    +
    5. +
  5. 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) 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:
    -   
    - +  
    + 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?
    -  
    - +  
    +    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:
    - +  
    +    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
    -
    6. - + +
- + +


+ 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:
+

+ +
    +
  1. 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.
    +
    +
    2. +
  2. 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
    +  
    3. +
  3. 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
    +
    4. + +
+

1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

- +

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. - the PDF may be downloaded from

-     +     ftp://slovakia.shorewall.net/mirror/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.
-

- -

1/13/2003 - Shorewall 1.3.13
-

- -

Just includes a few things that I had on the burner:
-

- -
    -
  1. A new 'DNAT-' action has been added for entries in the -/etc/shorewall/rules file. DNAT- is intended for advanced users who -wish to minimize the number of rules that connection requests must traverse.
    -
    - A Shorewall DNAT rule actually generates two iptables rules: -a header rewriting rule in the 'nat' table and an ACCEPT rule in the -'filter' table. A DNAT- rule only generates the first of these rules. -This is handy when you have several DNAT rules that would generate the -same ACCEPT rule.
    -
    -    Here are three rules from my previous rules file:
    -
    -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
    -
    -    These three rules ended up generating _three_ copies of
    -
    -          ACCEPT net  dmz:206.124.146.177 tcp smtp
    -
    -    By writing the rules this way, I end up with only one copy -of the ACCEPT rule.
    -
    -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
    -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
    -
    -
    2. -
  2. The 'shorewall check' command now prints out the applicable - policy between each pair of zones.
    -
    -
    3. -
  3. 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.
    -
    -
    4. -
  4. 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.
    -
    5. - -
- -

1/6/2003 - BURNOUT -

- -

Until further notice, I will not be involved in either Shorewall Development - or Shorewall Support

- -

-Tom Eastep

+

1/13/2003 - Shorewall 1.3.13
+

+ +

Just includes a few things that I had on the burner:
+

+ +
    +
  1. A new 'DNAT-' action has been added for entries in the + /etc/shorewall/rules file. DNAT- is intended for advanced users who + wish to minimize the number of rules that connection requests must +traverse.
    +
    + A Shorewall DNAT rule actually generates two iptables rules: + a header rewriting rule in the 'nat' table and an ACCEPT rule in the + 'filter' table. A DNAT- rule only generates the first of these rules. + This is handy when you have several DNAT rules that would generate the + same ACCEPT rule.
    +
    +    Here are three rules from my previous rules file:
    +
    +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
    +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
    +
    +    These three rules ended up generating _three_ copies of
    +
    +          ACCEPT net  dmz:206.124.146.177 tcp smtp
    +
    +    By writing the rules this way, I end up with only one copy + of the ACCEPT rule.
    +
    +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
    +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
    +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
    +
    +
    2. +
  2. The 'shorewall check' command now prints out the applicable + policy between each pair of zones.
    +
    +
    3. +
  3. 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.
    +
    +
    4. +
  4. 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.
    +
    5. + +
+ +

1/6/2003 - BURNOUT +

+ +

Until further notice, I will not be involved in either Shorewall Development + or Shorewall Support

+ +

-Tom Eastep
+

+

12/30/2002 - Shorewall Documentation in PDF Format

- +

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. - the PDF may be downloaded from

- + 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:
-

- +

+
    -
  1. "shorewall refresh" now reloads the traffic shaping -rules (tcrules and tcstart).
    2. -
  2. "shorewall debug [re]start" now turns off debugging -after an error occurs. This places the point of the failure near +
  3. "shorewall refresh" now reloads the traffic shaping + rules (tcrules and tcstart).
    4. +
  4. "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.
    5. -
  5. "shorewall [re]start" has been speeded up by more than - 40% with my configuration. Your milage may vary.
    6. -
  6. 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"
    7. -
  7. 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 "shorewall [re]start" has been speeded up by more +than 40% with my configuration. Your milage may vary.
    8. +
  8. 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"
    9. +
  9. 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.
    10. -
  10. 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.
    11. -
  11. 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.
    12. -
  12. I have added a new RFC1918_LOG_LEVEL variable to 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.
    13. +
  13. 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.
    14. +
  14. 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.
    -
    15. - + the syslog level at which packets are logged as a result of entries + in the /etc/shorewall/rfc1918 file. Previously, these packets were always + logged at the 'info' level.
    + +
- +

12/20/2002 - Shorewall 1.3.12 Beta 3
-

- This version corrects a problem with Blacklist logging. In - Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall - would fail to start and "shorewall refresh" would also fail.
- +

+ This version corrects a problem with Blacklist logging. +In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the +firewall would fail to start and "shorewall refresh" would also fail.
+

12/20/2002 - Shorewall 1.3.12 Beta 2

- +

The first public Beta version of Shorewall 1.3.12 is now available (Beta - 1 was made available only to a limited audience).
-

- Features include:
- + 1 was made available only to a limited audience).
+

+ Features include:
+
    -
  1. "shorewall refresh" now reloads the traffic shaping - rules (tcrules and tcstart).
    2. -
  2. "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.
    3. -
  3. "shorewall [re]start" has been speeded up by more - than 40% with my configuration. Your milage may vary.
    4. -
  4. 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"
    5. -
  5. 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 "shorewall refresh" now reloads the traffic shaping + rules (tcrules and tcstart).
    6. +
  6. "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.
    7. +
  7. "shorewall [re]start" has been speeded up by +more than 40% with my configuration. Your milage may vary.
    8. +
  8. 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"
    9. +
  9. 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.
    10. -
  10. 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 +
  11. 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.
    12. -
  12. 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.
    13. - +
  13. 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.
    14. +
- 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 Powered by Mandrake Linux -

- Shorewall is at the center of MandrakeSoft's recently-announced -

+ Shorewall is at the center of MandrakeSoft's recently-announced + Multi - Network Firewall (MNF) product. Here is the product. Here is the press - release.
- + 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.

- + 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 + excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users who don't need rules of this type need not upgrade to 1.3.11.

- +

11/24/2002 - Shorewall 1.3.11

- +

In this version:

- +
    -
  • A 'tcpflags' option has been added to entries - in /etc/shorewall/interfaces. - This option causes Shorewall to make a set of sanity check on TCP packet - header flags.
    • -
  • It is now allowed to use 'all' in the SOURCE - or DEST column in a rule. - When used, 'all' must appear by itself (in may not be qualified) - and it does not enable intra-zone traffic. For example, the rule -
    -
    -     ACCEPT loc all tcp 80
    -
    - does not enable http traffic from 'loc' to 'loc'.
    • -
  • Shorewall's use of the 'echo' command is -now compatible with bash clones such as ash and dash.
    • -
  • fw->fw policies now generate a startup - error. fw->fw rules generate a warning and are ignored
    • - +
  • A 'tcpflags' option has been added to +entries in /etc/shorewall/interfaces. + This option causes Shorewall to make a set of sanity check on TCP packet + header flags.
    • +
  • It is now allowed to use 'all' in the +SOURCE or DEST column in a rule. When used, 'all' must +appear by itself (in may not be qualified) and it does not enable + intra-zone traffic. For example, the rule
    +
    +     ACCEPT loc all tcp 80
    +
    + does not enable http traffic from 'loc' to 'loc'.
    • +
  • Shorewall's use of the 'echo' command +is now compatible with bash clones such as ash and dash.
    • +
  • fw->fw policies now generate a startup + error. fw->fw rules generate a warning and are ignored
    • +
- +

11/14/2002 - Shorewall Documentation in PDF Format

- +

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. - the PDF may be downloaded from

- + 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

- +

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 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:
- + - -

10/10/2002 -  Debian 1.3.9b Packages Available
-

+ 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/6/2002 - Shorewall.net now running on RH8.0
-
- The firewall and server here at shorewall.net - are now running RedHat release 8.0.
-
- 9/30/2002 - Shorewall 1.3.9a

- Roles up the fix for broken tunnels.
+ This release rolls up fixes to the installer + and to the firewall script.
+

10/6/2002 - Shorewall.net now running on RH8.0
+
+ The firewall and server here at shorewall.net + are now running RedHat release 8.0.
+
+ 9/30/2002 - Shorewall 1.3.9a

+ Roles up the fix for broken tunnels.
+

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.
- + -- 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 +
  • 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
-

- Brown Paper Bag - A couple of recent configuration - changes at www.shorewall.net broke the Search facility:
- - -
- -
    -
  1. Mailing List Archive Search - was not available.
    2. -
  2. The Site Search index was -incomplete
    3. -
  3. Only one page of matches -was presented.
    4. - - - -
-
- 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:
- - -
    -
  1. Mailing List Archive Search - was not available.
    2. -
  2. The Site Search index was -incomplete
    3. -
  3. Only one page of matches was - presented.
    4. - - -
- Hopefully these problems are now -corrected.
- - -

9/18/2002 -  Debian 1.3.8 Packages Available
-

+ + + + +

9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
+

+ Brown Paper Bag + A couple of recent configuration + changes at www.shorewall.net broke the Search facility:
+ + +
+ +
    +
  1. Mailing List Archive Search + was not available.
    2. +
  2. The Site Search index was + incomplete
    3. +
  3. Only one page of matches + was presented.
    4. + + + +
+
+ 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:
+ + +
    +
  1. Mailing List Archive Search + was not available.
    2. +
  2. The Site Search index was + incomplete
    3. +
  3. Only one page of matches +was presented.
    4. + + +
+ Hopefully these problems are now + corrected.
+ + +

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 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 + 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 +
  • 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 - (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.

- +

-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" checking.

+ reverses the order of "dhcp" and "norfc1918" checking.

- +

8/26/2002 - French FTP Mirror is Operational

- +

ftp://france.shorewall.net/pub/mirrors/shorewall - is now available.

+ is now available.

- +

8/25/2002 - Shorewall Mirror in France

- +

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 - 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 - -- Shorewall 1.3.7a released -

+

- +

1.3.7a corrects problems occurring in rules file processing when starting - Shorewall 1.3.7.

+ 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 The 'icmp.def' file +is now empty! The rules in that file were required in + ipchains firewalls but are not required in Shorewall. +Users who have ALLOWRELATED=No in shorewall.conf should see the Upgrade Issues.
    • -
  • A 'FORWARDPING' option - has been added to shorewall.conf. - The effect of setting this variable to Yes is the same - as the effect of adding an ACCEPT rule for ICMP echo-request - in /etc/shorewall/icmpdef. - Users who have such a rule in icmpdef are encouraged - to switch to FORWARDPING=Yes.
    • -
  • The loopback CLASS A -Network (127.0.0.0/8) has been added to the rfc1918 +
  • A 'FORWARDPING' option + has been added to shorewall.conf. + The effect of setting this variable to Yes is the same + as the effect of adding an ACCEPT rule for ICMP echo-request + in /etc/shorewall/icmpdef. + Users who have such a rule in icmpdef are encouraged + to switch to FORWARDPING=Yes.
    • +
  • The loopback CLASS +A Network (127.0.0.0/8) has been added to the rfc1918 file.
    • -
  • Shorewall now works with - iptables 1.2.7
    • -
  • The documentation and -web site no longer uses FrontPage themes.
    • +
  • Shorewall now works +with iptables 1.2.7
    • +
  • The documentation and + web site no longer uses FrontPage themes.
    • - +
- +

I would like to thank John Distler for his valuable input regarding TCP - SYN and ICMP treatment in Shorewall. That input has - led to marked improvement in Shorewall in the last two - releases.

+ 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.

- +

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 to get + 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

- +

Now there is one place to go to look for issues involved with upgrading - to recent versions of Shorewall.

+ 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 + 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 - 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.

- +

 In this version:

- + - +

7/16/2002 - New Mirror in Argentina

- +

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in - Argentina. Thanks Buanzo!!!

+ Argentina. Thanks Buanzo!!!

- +

7/16/2002 - Shorewall 1.3.4 Released

- +

In this version:

- + - +

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.
    • -
  • 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 +
  • Entries in /etc/shorewall/interface + that use the wildcard character ("+") now have the + "multi" option assumed.
    • +
  • The 'rfc1918' chain +in the mangle table has been renamed 'man1918' to + make log messages generated from that chain distinguishable + from those generated by the 'rfc1918' chain in the filter +table.
    • +
  • Interface names appearing + in the hosts file are now validated against the interfaces file.
    • -
  • The TARGET column in -the rfc1918 file is now checked for correctness.
    • -
  • The chain structure in - the nat table has been changed to reduce the number - of rules that a packet must traverse and to correct problems - with NAT_BEFORE_RULES=No
    • -
  • The "hits" command has - been enhanced.
    • +
  • The TARGET column in + the rfc1918 file is now checked for correctness.
    • +
  • The chain structure +in the nat table has been changed to reduce the number + of rules that a packet must traverse and to correct problems + with NAT_BEFORE_RULES=No
    • +
  • The "hits" command +has been enhanced.
    • - +
- +

6/25/2002 - Samples Updated for 1.3.2

- +

The comments in the sample configuration files have been updated to reflect - new features introduced in Shorewall 1.3.2.

+ 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.

- +

6/16/2002 - Shorewall 1.3.2 Released

- +

In this version:

- + - +

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:

- +
    -
  • Ignore robot.txt files.
    • -
  • Recursively copy everything - that they find.
    • -
  • Should be classified -as weapons rather than tools.
    • +
  • Ignore robot.txt files.
    • +
  • Recursively copy everything + that they find.
    • +
  • Should be classified + as weapons rather than tools.
    • - +
- +

These tools/weapons are particularly damaging when combined with CVS Web - because they doggedly follow every link in the cgi-generated - HTML resulting in 1000s of executions of the cvsweb.cgi - script. Yesterday, I spend several hours implementing -measures to block these tools but unfortunately, these measures - resulted in my server OOM-ing under even moderate load.

+ 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.

+ 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 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:

- + - +

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:

- +
    -
  • 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:

- +
    -
  • 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:

- +
    -
  • The structure of the -firewall is changed markedly. There is now an INPUT - and a FORWARD chain for each interface; this reduces the +
  • The structure of the + firewall is changed markedly. There is now an INPUT + and a FORWARD chain for each interface; this reduces the number of rules that a packet must traverse, especially in -complicated setups.
    • -
  • +
  • Sub-zones may now be excluded - from DNAT and REDIRECT rules.
    • -
  • The names of the columns - in a number of the configuration files have been -changed to be more consistent and self-explanatory and the + from DNAT and REDIRECT rules.
    • +
  • The names of the columns + in a number of the configuration files have been + changed to be more consistent and self-explanatory and the documentation has been updated accordingly.
    • -
  • The sample configurations - have been updated for 1.3.
    • +
  • The sample configurations + have been updated for 1.3.
    • - +
- +

5/17/2002 - Shorewall 1.3 Beta 1 Available

- +

Beta 1 carries the version designation 1.2.90 and implements the following - features:

+ features:

- +
    -
  • Simplified rule syntax - which makes the intent of each rule clearer and hopefully - makes Shorewall easier to learn.
    • -
  • Upward compatibility -with 1.2 configuration files has been maintained so +
  • Simplified rule syntax + which makes the intent of each rule clearer and +hopefully makes Shorewall easier to learn.
    • +
  • Upward compatibility + with 1.2 configuration files has been maintained so that current users can migrate to the new syntax at their -convenience.
    • -
  • +
  • WARNING:  Compatibility with the old parameterized sample configurations has NOT been maintained. Users still running those configurations should migrate - to the new sample configurations before upgrading to 1.3 - Beta 1.
    • + to the new sample configurations before upgrading to 1.3 + Beta 1. - +
- +

5/4/2002 - Shorewall 1.2.13 is Available

- +

In this version:

- + - +

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.

- +

4/20/2002 - Shorewall 1.2.12 is Available

- +
    -
  • The 'try' command works - again
    • -
  • There is now a single -RPM that also works with SuSE.
    • +
  • The 'try' command works + again
    • +
  • There is now a single + RPM that also works with SuSE.
    • - +
- +

4/17/2002 - Shorewall Debian News

- +

Lorenzo Marignoni reports that:

- + - +

Thanks, Lorenzo!

- +

4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

- +

Thanks to Stefan Mohr, there - is now a Shorewall 1.2.11 - SuSE RPM available.

+ 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.
    • -
  • Kernel route filtering - may now be enabled globally using the new ROUTE_FILTER - parameter in /etc/shorewall/shorewall.conf.
    • -
  • Individual IP source -addresses and/or subnets may now be excluded from - masquerading/SNAT.
    • -
  • Simple "Yes/No" and "On/Off" - values are now case-insensitive in /etc/shorewall/shorewall.conf.
    • +
  • The 'try' command now + accepts an optional timeout. If the timeout is given + in the command, the standard configuration will automatically + be restarted after the new configuration has been running + for that length of time. This prevents a remote admin from + being locked out of the firewall in the case where the new configuration + starts but prevents access.
    • +
  • Kernel route filtering + may now be enabled globally using the new ROUTE_FILTER + parameter in /etc/shorewall/shorewall.conf.
    • +
  • Individual IP source + addresses and/or subnets may now be excluded from + masquerading/SNAT.
    • +
  • Simple "Yes/No" and +"On/Off" values are now case-insensitive in /etc/shorewall/shorewall.conf.
    • - +
- +

4/13/2002 - Hamburg Mirror now has FTP

- +

Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  - Thanks Stefan!

+ 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. -

+

- +

4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available

- +

Version 1.1 of the QuickStart - Guide is now available. Thanks to those who have - read version 1.0 and offered their suggestions. Corrections - have also been made to the sample scripts.

+ 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.

+ 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.

+ 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 - version of his CGI-based - log parser with corrected date handling.

+ version of his 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 search form is also available - on the mailing - list information page.

+ The Extended Search + allows excluding the archives or restricting the search + to just the archives. An archive search form is also available + on the mailing + list information page.

- +

3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)

- + - +

3/25/2002 - Log Parser Available

- +

John Lodge has provided a CGI-based log parser for Shorewall. Thanks - John.

+ 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 +
  • A "shorewall try" command + has been added (syntax: shorewall try <configuration + directory>). This command attempts "shorewall -c <configuration directory> start" and if that results in the firewall being stopped due to an error, a "shorewall start" command is executed. The 'try' command allows you to create a new configuration - and attempt to start it; if there is an error that leaves -your firewall in the stopped state, it will automatically be restarted - using the default configuration (in /etc/shorewall).
    • -
  • A new variable ADD_SNAT_ALIASES - has been added to /etc/shorewall/shorewall.conf. - If this variable is set to "Yes", Shorewall will -automatically add IP addresses listed in the third -column of the /etc/shorewall/masq -file.
    • -
  • Copyright notices have - been added to the documenation.
    • + and attempt to start it; if there is an error that leaves + your firewall in the stopped state, it will automatically be restarted + using the default configuration (in /etc/shorewall). +
  • A new variable ADD_SNAT_ALIASES + has been added to /etc/shorewall/shorewall.conf. + If this variable is set to "Yes", Shorewall will + automatically add IP addresses listed in the third + column of the /etc/shorewall/masq + file.
    • +
  • Copyright notices have + been added to the documenation.
    • - +
- +

3/11/2002 - Shorewall 1.2.9 Released

- +

In this version:

- + - +

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

+ 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 may have caused.

+ operations from occuring simultaneously. My apologies + for any inconvenience my carelessness may have caused.

- +

2/22/2002 - Shorewall 1.2.7 Released

- +

In this version:

- +
    -
  • UPnP probes (UDP destination - port 1900) are now silently dropped in the common - chain
    • -
  • RFC 1918 checking in -the mangle table has been streamlined to no longer - require packet marking. RFC 1918 checking in the filter - table has been changed to require half as many rules as previously.
    • -
  • A 'shorewall check' command - has been added that does a cursory validation of the - zones, interfaces, hosts, rules and policy files.
    • +
  • UPnP probes (UDP destination + port 1900) are now silently dropped in the common + chain
    • +
  • RFC 1918 checking in + the mangle table has been streamlined to no longer + require packet marking. RFC 1918 checking in the filter + table has been changed to require half as many rules as previously.
    • +
  • A 'shorewall check' +command has been added that does a cursory validation + of the zones, interfaces, hosts, rules and policy files.
    • - +
- +

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.
    • -
  • The interfaces and hosts - files now have their contents validated before any - changes are made to the existing Netfilter configuration. - The appearance of a zone name that isn't defined in /etc/shorewall/zones - causes "shorewall start" and "shorewall restart" to abort - without changing the Shorewall state. Unknown options in either - file cause a warning to be issued.
    • -
  • A problem occurring when - BLACKLIST_LOGLEVEL was not set has been corrected.
    • +
  • $-variables may now +be used anywhere in the configuration files except + /etc/shorewall/zones.
    • +
  • The interfaces and +hosts files now have their contents validated before + any changes are made to the existing Netfilter configuration. + The appearance of a zone name that isn't defined in /etc/shorewall/zones + causes "shorewall start" and "shorewall restart" to abort + without changing the Shorewall state. Unknown options in either + file cause a warning to be issued.
    • +
  • A problem occurring +when BLACKLIST_LOGLEVEL was not set has been corrected.
    • - +
- +

2/4/2002 - Shorewall 1.2.5 Debian Package Available

- +

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.

+ 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.
    • -
  • 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.
    • +
  • 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.
    • - +
- +

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.

+ 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 monitor" - command now displays the icmpdef chain
    • -
  • The CLIENT PORT(S) column - in tcrules is no longer ignored
    • +
  • The "shorewall status" + command no longer hangs.
    • +
  • The "shorewall monitor" + command now displays the icmpdef chain
    • +
  • The CLIENT PORT(S) column + in tcrules is no longer ignored
    • - +
- +

1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release

- +

Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution - that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo - for details.

+ for details.

- +

1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2 - Shorewall Debian package is now available. There is -a link to Lorenzo's site from the Shorewall download page.

- +

1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores - the "shorewall status" command to health.

+ 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 RST packet.
      • -
    • TCP connection requests - rejected because of a protocol=all rule in /etc/shorewall/rules - are now replied with a TCP RST packet.
      • +
    • TCP connection requests + rejected because of a REJECT policy are now +replied with a TCP RST packet.
      • +
    • TCP connection requests + rejected because of a protocol=all rule in /etc/shorewall/rules + are now replied with a TCP RST packet.
      • - +
    -
    • -
  • A +
  • 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.
    • + messages. - +
- +

1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates - to the previously-released samples. There are two new - rules added:

+ to the previously-released samples. There are two +new rules added:

- +
    -
  • Unless you have explicitly - enabled Auth connections (tcp port 113) to your firewall, - these connections will be REJECTED rather than DROPPED. - This speeds up connection establishment to some servers.
    • -
  • Orphan DNS replies are -now silently dropped.
    • +
  • Unless you have explicitly + enabled Auth connections (tcp port 113) to your firewall, + these connections will be REJECTED rather than DROPPED. + This speeds up connection establishment to some servers.
    • +
  • 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 list, visit - http://www.shorewall.net/mailman/listinfo/shorewall-users.

+ 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:

- + - +

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.

+ 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:

+ 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 , 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. 
    • +
  • 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.
    • +
  • 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 , 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:

+ There are three sample configurations:

- +
    -
  • One Interface -- for a -standalone system.
    • -
  • Two Interfaces -- A masquerading - firewall.
    • -
  • Three Interfaces -- A -masquerading firewall with DMZ.
    • +
  • 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.

+ . 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.

+ 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:

- - -
    -
  • A new "shorewall show -connections" command has been added.
    • -
  • In the "shorewall monitor" - output, the currently tracked connections are now -shown on a separate page.
    • -
  • Prior to this release, -Shorewall unconditionally added the external IP adddress(es) - specified in /etc/shorewall/nat. Beginning with version - 1.1.16, a new parameter (ADD_IP_ALIASES) - may be set to "no" (or "No") to inhibit this behavior. - This allows IP aliases created using your distribution's - network configuration tools to be used in static -NAT. 
    • - - -
+ version:

+
    +
  • A new "shorewall show + connections" command has been added.
    • +
  • In the "shorewall monitor" + output, the currently tracked connections are now + shown on a separate page.
    • +
  • Prior to this release, + Shorewall unconditionally added the external IP +adddress(es) specified in /etc/shorewall/nat. Beginning with +version 1.1.16, a new parameter (ADD_IP_ALIASES) may be +set to "no" (or "No") to inhibit this behavior. This + allows IP aliases created using your distribution's network + configuration tools to be used in static NAT. 
    • + + +
+ +

10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:

+ version:

- + - +

10/4/2001 - The current version of Shorewall is 1.1.14. In this - version

+ version

- + - +

9/12/2001 - The current version of Shorewall is 1.1.13. In this - version

+ version

- + - +

8/28/2001 - The current version of Shorewall is 1.1.12. In this - version

+ version

- +
    -
  • Several columns in the -rules file may now contain comma-separated lists.
    • -
  • Shorewall is now more -rigorous in parsing the options in /etc/shorewall/interfaces.
    • -
  • Complementation using -"!" is now supported in rules.
    • +
  • Several columns in the + rules file may now contain comma-separated lists.
    • +
  • Shorewall is now more + rigorous in parsing the options in /etc/shorewall/interfaces.
    • +
  • Complementation using + "!" is now supported in rules.
    • - +
- +

7/28/2001 - The current version of Shorewall is 1.1.11. In this - version

+ version

- +
    -
  • A "shorewall refresh" -command has been added to allow for refreshing the -rules associated with the broadcast address on a dynamic - interface. This command should be used in place of "shorewall - restart" when the internet interface's IP address changes.
    • -
  • The /etc/shorewall/start - file (if any) is now processed after all temporary -rules have been deleted. This change prevents the accidental - removal of rules added during the processing of that file.
    • -
  • The "dhcp" interface option - is now applicable to firewall interfaces used by a -DHCP server running on the firewall.
    • -
  • The RPM can now be built - from the .tgz file using "rpm -tb" 
    • +
  • A "shorewall refresh" + command has been added to allow for refreshing the + rules associated with the broadcast address on a dynamic + interface. This command should be used in place of "shorewall + restart" when the internet interface's IP address changes.
    • +
  • The /etc/shorewall/start + file (if any) is now processed after all temporary + rules have been deleted. This change prevents the accidental + removal of rules added during the processing of that file.
    • +
  • The "dhcp" interface +option is now applicable to firewall interfaces used +by a DHCP server running on the firewall.
    • +
  • The RPM can now be built + from the .tgz file using "rpm -tb" 
    • - +
- +

7/6/2001 - The current version of Shorewall is 1.1.10. In this version

- +
    -
  • Shorewall now enables -Ipv4 Packet Forwarding by default. Packet forwarding - may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. - If you don't want Shorewall to enable or disable packet - forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf - file.
    • -
  • The "shorewall hits" command - no longer lists extraneous service names in its last - report.
    • -
  • Erroneous instructions -in the comments at the head of the firewall script -have been corrected.
    • +
  • Shorewall now enables + Ipv4 Packet Forwarding by default. Packet forwarding + may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. + If you don't want Shorewall to enable or disable packet + forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf + file.
    • +
  • The "shorewall hits" +command no longer lists extraneous service names in +its last report.
    • +
  • Erroneous instructions + in the comments at the head of the firewall script + have been corrected.
    • - +
- +

6/23/2001 - The current version of Shorewall is 1.1.9. In this version

- + - +

6/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 is stopped.
    • -
  • The .rpm will now install - regardless of which version of iptables is installed.
    • -
  • The .rpm will now install - without iproute2 being installed.
    • -
  • The documentation has -been cleaned up.
    • -
  • The sample configuration - files included in Shorewall have been formatted -to 80 columns for ease of editing on a VGA console.
    • +
  • 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 + without iproute2 being installed.
    • +
  • The documentation has + been cleaned up.
    • +
  • 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

- +
    -
  • You may now rate-limit the packet log.
    • -
  • Previous versions - of Shorewall have an implementation of Static NAT which violates +
  • 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 +
  • 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 @@ -2210,221 +2293,225 @@ gateway is a standalone system has been improved. Previously, 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/10/2001 - The current version of Shorewall is 1.1.4. In this version

- +
    -
  • Accepting RELATED connections is now optional.
    • -
  • Corrected problem where - if "shorewall start" aborted early (due to kernel +
  • Corrected problem where + if "shorewall start" aborted early (due to kernel configuration errors for example), superfluous 'sed' error messages were reported.
    • -
  • Corrected rules generated - for port redirection.
    • -
  • The order in which iptables - kernel modules are loaded has been corrected (Thanks - to Mark Pavlidis). 
    • +
  • Corrected rules generated + for port redirection.
    • +
  • The order in which iptables + kernel modules are loaded has been corrected (Thanks + to Mark Pavlidis). 
    • - +
- +

4/28/2001 - The current version of Shorewall is 1.1.3. In this version

- +
    -
  • Correct message issued -when Proxy ARP address added (Thanks to Jason Kirtland).
    • -
  • /tmp/shorewallpolicy-$$ - is now removed if there is an error while starting +
  • Correct message issued + when Proxy ARP address added (Thanks to Jason Kirtland).
    • +
  • /tmp/shorewallpolicy-$$ + is now removed if there is an error while starting the firewall.
    • -
  • /etc/shorewall/icmp.def - and /etc/shorewall/common.def are now used to define - the icmpdef and common chains unless overridden by the - presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
    • -
  • In the .lrp, the file -/var/lib/lrpkg/shorwall.conf has been corrected. An -extra space after "/etc/shorwall/policy" has been removed - and "/etc/shorwall/rules" has been added.
    • -
  • When a sub-shell encounters - a fatal error and has stopped the firewall, it now -kills the main shell so that the main shell will not continue.
    • -
  • A problem has been corrected - where a sub-shell stopped the firewall and main shell - continued resulting in a perplexing error message referring - to "common.so" resulted.
    • -
  • Previously, placing "-" - in the PORT(S) column in /etc/shorewall/rules resulted - in an error message during start. This has been corrected.
    • -
  • The first line of "install.sh" - has been corrected -- I had inadvertently deleted the - initial "#".
    • +
  • /etc/shorewall/icmp.def + and /etc/shorewall/common.def are now used to define + the icmpdef and common chains unless overridden by the + presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
    • +
  • In the .lrp, the file + /var/lib/lrpkg/shorwall.conf has been corrected. An + extra space after "/etc/shorwall/policy" has been removed + and "/etc/shorwall/rules" has been added.
    • +
  • When a sub-shell encounters + a fatal error and has stopped the firewall, it now + kills the main shell so that the main shell will not +continue.
    • +
  • A problem has been corrected + where a sub-shell stopped the firewall and main shell + continued resulting in a perplexing error message referring + to "common.so" resulted.
    • +
  • Previously, placing +"-" in the PORT(S) column in /etc/shorewall/rules resulted + in an error message during start. This has been corrected.
    • +
  • The first line of "install.sh" + has been corrected -- I had inadvertently deleted the + initial "#".
    • - +
- +

4/12/2001 - The current version of Shorewall is 1.1.2. In this version

- +
    -
  • Port redirection now works - again.
    • -
  • 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. A warning message is now - issued in this case.
    • -
  • The LRP Version is renamed - "shorwall" for 8,3 MSDOS file system compatibility.
    • -
  • A couple of LRP-specific - problems were corrected.
    • +
  • Port redirection now +works again.
    • +
  • 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. A warning message is now + issued in this case.
    • +
  • The LRP Version is renamed + "shorwall" for 8,3 MSDOS file system compatibility.
    • +
  • 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 and FORWARD before logging -occurs
    • -
  • The source has been cleaned - up dramatically
    • -
  • DHCP DISCOVER packets -with RFC1918 source addresses no longer generate +
  • The common chain is +traversed from INPUT, OUTPUT and FORWARD before + logging occurs
    • +
  • The source has been +cleaned up dramatically
    • +
  • DHCP DISCOVER packets + with RFC1918 source addresses no longer generate log messages. Linux DHCP clients generate such packets and it's annoying to see them logged. 
    • - +
- +

3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

- +
    -
  • Log messages now indicate - the packet disposition.
    • -
  • Error messages have been - improved.
    • -
  • The ability to define -zones consisting of an enumerated set of hosts -and/or subnetworks has been added.
    • -
  • The zone-to-zone chain -matrix is now sparse so that only those chains that -contain meaningful rules are defined.
    • -
  • 240.0.0.0/4 and 169.254.0.0/16 - have been added to the source subnetworks whose packets - are dropped under the norfc1918 interface - option.
    • -
  • Exits are now provided -for executing an user-defined script when a chain -is defined, when the firewall is initialized, when the firewall - is started, when the firewall is stopped and when the - firewall is cleared.
    • -
  • The Linux kernel's route - filtering facility can now be specified selectively - on network interfaces.
    • +
  • Log messages now indicate + the packet disposition.
    • +
  • Error messages have +been improved.
    • +
  • The ability to define + zones consisting of an enumerated set of hosts + and/or subnetworks has been added.
    • +
  • The zone-to-zone chain + matrix is now sparse so that only those chains that + contain meaningful rules are defined.
    • +
  • 240.0.0.0/4 and 169.254.0.0/16 + have been added to the source subnetworks whose packets + are dropped under the norfc1918 interface + option.
    • +
  • Exits are now provided + for executing an user-defined script when a chain + is defined, when the firewall is initialized, when the firewall + is started, when the firewall is stopped and when the + firewall is cleared.
    • +
  • The Linux kernel's route + filtering facility can now be specified selectively + on network interfaces.
    • - +
- +

3/19/2001 - The current version of Shorewall is 1.0.4. This version:

- +
    -
  • Allows user-defined zones. - Shorewall now has only one pre-defined zone (fw) - with the remaining zones being defined in the new configuration - file /etc/shorewall/zones. The /etc/shorewall/zones - file released in this version provides behavior that is -compatible with Shorewall 1.0.3. 
    • -
  • Adds the ability to specify - logging in entries in the /etc/shorewall/rules file.
    • -
  • Correct handling of the - icmp-def chain so that only ICMP packets are sent - through the chain.
    • -
  • Compresses the output -of "shorewall monitor" if awk is installed. Allows +
  • Allows user-defined +zones. Shorewall now has only one pre-defined +zone (fw) with the remaining zones being defined in the new +configuration file /etc/shorewall/zones. The /etc/shorewall/zones + file released in this version provides behavior that +is compatible with Shorewall 1.0.3. 
    • +
  • Adds the ability to +specify logging in entries in the /etc/shorewall/rules + file.
    • +
  • Correct handling of +the icmp-def chain so that only ICMP packets are + sent through the chain.
    • +
  • Compresses the output + of "shorewall monitor" if awk is installed. Allows the command to work if awk isn't installed (although it's -not pretty).
    • + not pretty). - +
- +

3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix - release with no new features.

+ release with no new features.

- +
    -
  • The PATH variable in the - firewall script now includes /usr/local/bin and -/usr/local/sbin.
    • -
  • DMZ-related chains are -now correctly deleted if the DMZ is deleted.
    • -
  • The interface OPTIONS -for "gw" interfaces are no longer ignored.
    • +
  • The PATH variable in +the firewall script now includes /usr/local/bin + and /usr/local/sbin.
    • +
  • DMZ-related chains are + now correctly deleted if the DMZ is deleted.
    • +
  • The interface OPTIONS + for "gw" interfaces are no longer ignored.
    • - +
- +

3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for tunnels and it -supports IPSEC tunnels with end-points on the firewall. -There is also a .lrp available now.

+ 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 2/13/2003 - Tom Eastep -

+ +

Updated 2/21/2003 - Tom Eastep +

- +

Copyright © 2001, 2002 Thomas M. Eastep.
-

+

+
+
diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index 814a48dcd..6444873e3 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,371 +2,335 @@ Shorewall Squid Usage - + - + - + - - - + - + - - - - +
+ + + +
+
-
-
+ 		Using Shorewall with Squid
- 		+ -
-
-
- This page covers Shorewall configuration to use with Squid running as a Transparent +
+ This page covers Shorewall configuration to use with Squid running as a Transparent Proxy. 
-
-
+ Caution -     Please observe the following general requirements:
-
- -     In all cases, Squid should be configured to run +     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 iproute2 (ip utility) installed +
+ +     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 iproute2 (ip utility) installed on your firewall.
-
- -     You must have iptables installed on your Squid +
+ +     You must have iptables installed on your Squid server.
-
- -     You must have NAT and MANGLE enabled in your +
+ +     You must have NAT and MANGLE enabled in your /etc/shorewall/conf file
-
-         NAT_ENABLED=Yes
-         MANGLE_ENABLED=Yes
-
- Three different configurations are covered:
- +
+         NAT_ENABLED=Yes
+         MANGLE_ENABLED=Yes
+
+ Three different configurations are covered:
+
    -
  1. Squid running on +
  2. Squid running on the Firewall.
    3. -
  3. Squid running in the -local network
    4. -
  4. Squid running in the DMZ
    5. - +
  5. Squid running in the + local network
    6. +
  6. Squid running in the +DMZ
    7. +
- +

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:
-
+ 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:
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
REDIRECTloc3128tcpwww -
+ 		!206.124.146.177
ACCEPTfwnettcpwww
+
+
+
+
+ +

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
+
+ +
    +
  • In /etc/shorewall/rules:
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPT
    +     		locloc
    +     		tcpwww
    +
    +
    +
    +
    • +
  • Alternativfely, you can have the following policy:
    +
    + + + + + + + + + + + + + + + + + + + +
    SOURCE
    +     		DESTINATION
    +     		POLICY
    +     		LOG LEVEL
    +     		BURST PARAMETERS
    +
    loc
    +     		loc
    +     		ACCEPT
    +
    +
    +
    +
    +
    • +
  • In /etc/shorewall/start add:
    +
    • + +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
-
+ 
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-

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
-
- -
    -
  • In /etc/shorewall/rules:
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPT
    -     		locloc
    -     		tcpwww
    -
    -
    -
    -
    • -
  • Alternativfely, you can have the following policy:
    -
    - - - - - - - - - - - - - - - - - - - -
    SOURCE
    -     		DESTINATION
    -     		POLICY
    -     		LOG LEVEL
    -     		BURST PARAMETERS
    -
    loc
    -     		loc
    -     		ACCEPT
    -
    -
    -
    -
    -
    • -
  • In /etc/shorewall/start add:
    -
    • - -
- -
- 
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-
- -
    -
  • On 192.168.1.3, arrange for the following command to be executed - after networking has come up
    - +
  • On 192.168.1.3, arrange for the following command to be executed + after networking has come up
    + 
    iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
    -
    • - + +
- -
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
    +
- -
- 
if [ -z "`ip rule list | grep www.out`" ] ; then
	ip rule add fwmark 202 table www.out
	ip route add default via 192.0.2.177 dev eth1 table www.out
	ip route flush cache
fi
-
- -
    -
  •  Do one of the following:
    -
    - A) In /etc/shorewall/start add
    -
    • - -
- -
- 
	iptables -t nat -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:
-
- + +
+ 
	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:
+
+
@@ -386,7 +350,7 @@ and add the following entry in /etc/shorewall/tcrules:
- @@ -403,90 +367,130 @@ and add the following entry in /etc/shorewall/tcrules:
202:P
+ 		202
 eth2
-
-
- + C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
+ + +
+
+ + + + + + + + + + + + + + + + + + + + +
MARK
+ 		SOURCE
+ 		DESTINATION
+ 		PROTOCOL
+ 		PORT
+ 		CLIENT PORT
+
202:P
+ 		eth2
+ 		0.0.0.0/0
+ 		tcp
+ 		80
+ 		-
+
+
+
+
+
    -
  • In /etc/shorewall/rules, you will need:
    • - -
- -
- - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		CLIENT
- PORT(2)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		dmz
- 		net
- 		tcp
- 		80
-
-
-
-
-
- -
    -
  • On 192.0.2.177 (your Web/Squid server), arrange for the following - command to be executed after networking has come up
    - - 
    iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
    -
    • +
  • In /etc/shorewall/rules, you will need:
- -
If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
-
- +
+ + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		CLIENT
+ PORT(2)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		dmz
+ 		net
+ 		tcp
+ 		80
+
+
+
+
+
+ +
    +
  • On 192.0.2.177 (your Web/Squid server), arrange for the following + command to be executed after networking has come up
    + + 
    iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
    +
    • + +
+ +
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 1/23/2003 - Tom Eastep + +

Updated 2/22/2003 - Tom Eastep

- Copyright © 2003 Thomas M. Eastep.
-
-
-
+
+
+
+



diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index 5853a15cb..2c92f7539 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -2,702 +2,698 @@ - + Shorewall 1.3 Errata - + - + - + - + - - - + + - + + - - + +
+
- +

Shorewall Errata/Upgrade Issues

-
- +

IMPORTANT

- +
    -
  1. +
  2. - -

    If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved - it to your Linux system.

    -
    3. -
  3. + +

    If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + it to your Linux system.

    +
    4. +
  4. - -

    If you are installing Shorewall for the first -time and plan to use the .tgz and install.sh script, you can untar -the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

    -
    5. -
  5. + +

    If you are installing Shorewall for the +first time and plan to use the .tgz and install.sh script, you can +untar the archive, replace the 'firewall' script in the untarred directory + with the one you downloaded below, and then run install.sh.

    +
    6. +
  6. - -

    If you are running a Shorewall version earlier - than 1.3.11, when the instructions say to install a corrected firewall - script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite - the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall - or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall - and /var/lib/shorewall/firewall are symbolic links that point - to the 'shorewall' file used by your system initialization scripts - to start Shorewall during boot. It is that file that must be -overwritten with the corrected script. Beginning with Shorewall -1.3.11, you may rename the existing file before copying in the new file.

    -
    7. -
  7. - -

    DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. - For example, do NOT install the 1.3.9a firewall script if you are running - 1.3.7c.
    -

    -
    8. + +

    If you are running a Shorewall version earlier + than 1.3.11, when the instructions say to install a corrected +firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to +overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD +/etc/shorewall/firewall or /var/lib/shorewall/firewall before +you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall + are symbolic links that point to the 'shorewall' file used by +your system initialization scripts to start Shorewall during +boot. It is that file that must be overwritten with the corrected +script. Beginning with Shorewall 1.3.11, you may rename the existing file +before copying in the new file.

    + +
  8. +

    DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. + For example, do NOT install the 1.3.9a firewall script if you are running + 1.3.7c.
    +

    +
    9. +
- + - -
+ +

Problems in Version 1.3

- +

Version 1.3.14

- +
    -
  • There is an updated - rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and -223.0.0.0/8.
    • +
  • There is an updated + rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • +
+
    -
  • The documentation for the routestopped file claimed that a comma-separated - list could appear in the second column while the code only supported a single +
  • 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.
    • - +
  • 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.
    +
    • +
- Both problems have been corrected in this - firewall script which may be installed in /usr/lib/shorewall as described + These three problems have been corrected in this + firewall script which may be installed in /usr/lib/shorewall as described above.
- +

Version 1.3.13

- -
    -
  • The 'shorewall add' command produces an error message referring - to 'find_interfaces_by_maclist'.
    • -
  • The 'shorewall delete' command can leave behind undeleted rules.
    • -
  • The 'shorewall add' command can fail with "iptables: Index of insertion - too big".
    -
    • - -
- All three problems are corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
- -
    -
  • VLAN interface names of the form "ethn.m" (e.g., -eth0.1) are not supported in this version or in 1.3.12. If you need such -support, post on the users list and I can provide you with a patched version.
    -
    • - -
- -

Version 1.3.12

    -
  • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect - is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem - is corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
    • -
  • VLAN interface names of the form "ethn.m" (e.g., -eth0.1) are not supported in this version or in 1.3.13. If you need such +
  • The 'shorewall add' command produces an error message referring + to 'find_interfaces_by_maclist'.
    • +
  • The 'shorewall delete' command can leave behind undeleted rules.
    • +
  • The 'shorewall add' command can fail with "iptables: Index of insertion + too big".
    +
    • + +
+ All three problems are corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
+ +
    +
  • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.12. If you need such support, post on the users list and I can provide you with a patched version.
    • - +
- -

Version 1.3.12 LRP

+ +

Version 1.3.12

    -
  • The .lrp was missing the /etc/shorewall/routestopped file -- - a new lrp (shorwall-1.3.12a.lrp) has been released which corrects this - problem.
    -
    • +
  • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect + is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem + is corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
    • +
  • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.13. If you need such +support, post on the users list and I can provide you with a patched version.
    +
-

Version 1.3.11a

+

Version 1.3.12 LRP

    -
  • This - copy of /etc/shorewall/rfc1918 reflects the recent allocation of 82.0.0.0/8.
    +
  • The .lrp was missing the /etc/shorewall/routestopped file +-- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects +this problem.
+

Version 1.3.11a

+ + +

Version 1.3.11

- +
    -
  • When installing/upgrading using the .rpm, you may receive - the following warnings:
    -
    -      user teastep does not exist - using root
    -      group teastep does not exist - using root
    -
    - These warnings are harmless and may be ignored. Users downloading - the .rpm from shorewall.net or mirrors should no longer see these warnings - as the .rpm you will get from there has been corrected.
    • -
  • DNAT rules that exclude a source subzone (SOURCE column -contains ! followed by a sub-zone list) result in an error message and +
  • When installing/upgrading using the .rpm, you may receive + the following warnings:
    +
    +      user teastep does not exist - using root
    +      group teastep does not exist - using root
    +
    + These warnings are harmless and may be ignored. Users downloading + the .rpm from shorewall.net or mirrors should no longer see these warnings + as the .rpm you will get from there has been corrected.
    • +
  • DNAT rules that exclude a source subzone (SOURCE column +contains ! followed by a sub-zone list) result in an error message and Shorewall fails to start.
    +
    + Install this + corrected script in /usr/lib/shorewall/firewall to correct this +problem. Thanks go to Roger Aich who analyzed this problem and provided +a fix.

    - Install this - corrected script in /usr/lib/shorewall/firewall to correct this problem. - Thanks go to Roger Aich who analyzed this problem and provided a fix.
    -
    - This problem is corrected in version 1.3.11a.
    -
    • - + This problem is corrected in version 1.3.11a.
    + +
- +

Version 1.3.10

- +
    -
  • If you experience problems connecting to a PPTP server - running on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, - this - version of the firewall script may help. Please report any cases - where installing this script in /usr/lib/shorewall/firewall solved your - connection problems. Beginning with version 1.3.10, it is safe to save - the old version of /usr/lib/shorewall/firewall before copying in the -new one since /usr/lib/shorewall/firewall is the real script now and not -just a symbolic link to the real script.
    -
    • - +
  • If you experience problems connecting to a PPTP server + running on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, + this + version of the firewall script may help. Please report any cases + where installing this script in /usr/lib/shorewall/firewall solved +your connection problems. Beginning with version 1.3.10, it is safe +to save the old version of /usr/lib/shorewall/firewall before copying +in the new one since /usr/lib/shorewall/firewall is the real script +now and not just a symbolic link to the real script.
    +
    • +
- +

Version 1.3.9a

- -
    -
  • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No - then the following message appears during "shorewall [re]start":
    • - -
+
    +
  • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
    • + +
+ 
          recalculate_interfacess: command not found
- +
The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall + target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + corrects this problem.Copy the script to /usr/lib/shorewall/firewall as described above.
-
- -
Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
-
- -
    -
  • The installer (install.sh) issues a misleading message - "Common functions installed in /var/lib/shorewall/functions" whereas - the file is installed in /usr/lib/shorewall/functions. The installer -also performs incorrectly when updating old configurations that had the -file /etc/shorewall/functions. Here - is an updated version that corrects these problems.
    -
    • - -
+ + +
Alternatively, edit /usr/lob/shorewall/firewall and change the + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
+
-

Version 1.3.9

- 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 as described above.
-
- Version 1.3.8
    -
  • Use of shell variables in the LOG LEVEL or SYNPARMS - columns of the policy file doesn't work.
    • -
  • A DNAT rule with the same original and new IP addresses - but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 - tcp 25 - 10.1.1.1")
    -
    • - +
  • The installer (install.sh) issues a misleading message + "Common functions installed in /var/lib/shorewall/functions" whereas + the file is installed in /usr/lib/shorewall/functions. The installer + also performs incorrectly when updating old configurations that had the + file /etc/shorewall/functions. Here + is an updated version that corrects these problems.
    +
    • +
- Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these - problems. -

Version 1.3.7b

- - -

DNAT rules where the source zone is 'fw' ($FW) - result in an error message. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this -problem.

- - -

Version 1.3.7a

- - -

"shorewall refresh" is not creating the proper - rule for FORWARDPING=Yes. Consequently, after - "shorewall refresh", the firewall will not forward - icmp echo-request (ping) packets. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this -problem.

- - -

Version <= 1.3.7a

- - -

If "norfc1918" and "dhcp" are both specified as - options on a given interface then RFC 1918 - checking is occurring before DHCP checking. This - means that if a DHCP client broadcasts using an - RFC 1918 source address, then the firewall will - reject the broadcast (usually logging it). This - has two problems:

- - -
    -
  1. If the firewall -is running a DHCP server, the client - won't be able to obtain an IP address - lease from that server.
    2. -
  2. With this order -of checking, the "dhcp" option cannot - be used as a noise-reduction measure - where there are both dynamic and static - clients on a LAN segment.
    3. - -
- - -

- This version of the 1.3.7a firewall script - corrects the problem. It must be -installed in /var/lib/shorewall as -described above.

- - -

Version 1.3.7

- - -

Version 1.3.7 dead on arrival -- please use - version 1.3.7a and check your version against - these md5sums -- if there's a difference, please - download again.

- - -
	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
- -

In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

- -

I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

- -

Version 1.3.6

- + +

Version 1.3.9

+ 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 as described above.
+
+ Version 1.3.8
    -
  • - - -

    If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, - an error occurs when the firewall script attempts to -add an SNAT alias.

    -
    • -
  • - - -

    The logunclean and dropunclean options - cause errors during startup when Shorewall is run with iptables - 1.2.7.

    +
  • Use of shell variables in the LOG LEVEL or SYNPARMS + columns of the policy file doesn't work.
    • +
  • A DNAT rule with the same original and new IP +addresses but with different port numbers doesn't work (e.g., "DNAT +loc dmz:10.1.1.1:24 tcp 25 - 10.1.1.1")
- -

These problems are fixed in - this correct firewall script which must be installed in - /var/lib/shorewall/ as described above. These problems are also - corrected in version 1.3.7.

- -

Two-interface Samples 1.3.6 (file two-interfaces.tgz)

- -

A line was inadvertently deleted from the "interfaces - file" -- this line should be added back in if the version that you - downloaded is missing it:

- -

net    eth0    detect    routefilter,dhcp,norfc1918

- -

If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

- -

Version 1.3.5-1.3.5b

- -

The new 'proxyarp' interface option doesn't work :-( - This is fixed in - this corrected firewall script which must be installed in - /var/lib/shorewall/ as described above.

- -

Versions 1.3.4-1.3.5a

- -

Prior to version 1.3.4, host file entries such as the - following were allowed:

- -
-
	adm	eth0:1.2.4.5,eth0:5.6.7.8
-
- -
-

That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. - This problem is corrected by this - modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall - as instructed above.

-
- -
-

This problem is corrected in version 1.3.5b.

-
- -

Version 1.3.5

- -

REDIRECT rules are broken in this version. Install - - this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version - 1.3.5a.

- -

Version 1.3.n, n < 4

- -

The "shorewall start" and "shorewall restart" commands - to not verify that the zones named in the /etc/shorewall/policy file - have been previously defined in the /etc/shorewall/zones file. -The "shorewall check" command does perform this verification so -it's a good idea to run that command after you have made configuration - changes.

- -

Version 1.3.n, n < 3

- -

If you have upgraded from Shorewall 1.2 and after - "Activating rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include in - /etc/shorewall/interfaces. To correct this problem, you - must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 -and later versions produce a clearer error message in this -case.

- -

Version 1.3.2

- -

Until approximately 2130 GMT on 17 June 2002, the - download sites contained an incorrect version of the .lrp file. That - file can be identified by its size (56284 bytes). The correct version - has a size of 38126 bytes.

- -
    -
  • The code to detect a duplicate interface - entry in /etc/shorewall/interfaces contained a typo that - prevented it from working correctly.
    • -
  • "NAT_BEFORE_RULES=No" was broken; it - behaved just like "NAT_BEFORE_RULES=Yes".
    • - -
- -

Both problems are corrected in - this script which should be installed in /var/lib/shorewall - as described above.

- -
    -
  • + Installing + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects these + problems. +

    Version 1.3.7b

    - -

    The IANA have just announced the allocation of subnet - 221.0.0.0/8. This - updated rfc1918 file reflects that allocation.

    -
    • - + +

    DNAT rules where the source zone is 'fw' ($FW) + result in an error message. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this + problem.

    + + +

    Version 1.3.7a

    + + +

    "shorewall refresh" is not creating the proper + rule for FORWARDPING=Yes. Consequently, after + "shorewall refresh", the firewall will not forward + icmp echo-request (ping) packets. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this + problem.

    + + +

    Version <= 1.3.7a

    + + +

    If "norfc1918" and "dhcp" are both specified as + options on a given interface then RFC 1918 + checking is occurring before DHCP checking. This + means that if a DHCP client broadcasts using an + RFC 1918 source address, then the firewall will + reject the broadcast (usually logging it). This + has two problems:

    + + +
      +
    1. If the firewall + is running a DHCP server, the +client won't be able to obtain an IP address + lease from that server.
      2. +
    2. With this order + of checking, the "dhcp" option +cannot be used as a noise-reduction + measure where there are both dynamic and static + clients on a LAN segment.
      3. + +
    + + +

    + This version of the 1.3.7a firewall script + corrects the problem. It must be +installed in /var/lib/shorewall as +described above.

    + + +

    Version 1.3.7

    + + +

    Version 1.3.7 dead on arrival -- please use + version 1.3.7a and check your version against + these md5sums -- if there's a difference, please + download again.

    + + +
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    + +

    In other words, type "md5sum <whatever package you downloaded> + and compare the result with what you see above.

    + +

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the + .7 version in each sequence from now on.

    + +

    Version 1.3.6

    + +
      +
    • + + +

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, + an error occurs when the firewall script attempts to + add an SNAT alias.

      +
      • +
    • + + +

      The logunclean and dropunclean options + cause errors during startup when Shorewall is run with iptables + 1.2.7.

      +
      • +
    - + +

    These problems are fixed in + this correct firewall script which must be installed in + /var/lib/shorewall/ as described above. These problems are also + corrected in version 1.3.7.

    + +

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    + +

    A line was inadvertently deleted from the "interfaces + file" -- this line should be added back in if the version that you + downloaded is missing it:

    + +

    net    eth0    detect    routefilter,dhcp,norfc1918

    + +

    If you downloaded two-interfaces-a.tgz then the above + line should already be in the file.

    + +

    Version 1.3.5-1.3.5b

    + +

    The new 'proxyarp' interface option doesn't work :-( + This is fixed in + this corrected firewall script which must be installed in + /var/lib/shorewall/ as described above.

    + +

    Versions 1.3.4-1.3.5a

    + +

    Prior to version 1.3.4, host file entries such as the + following were allowed:

    + +
    +
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    +
    + +
    +

    That capability was lost in version 1.3.4 so that it is only + possible to  include a single host specification on each line. + This problem is corrected by this + modified 1.3.5a firewall script. Install the script in +/var/lib/pub/shorewall/firewall as instructed above.

    +
    + +
    +

    This problem is corrected in version 1.3.5b.

    +
    + +

    Version 1.3.5

    + +

    REDIRECT rules are broken in this version. Install + + this corrected firewall script in /var/lib/pub/shorewall/firewall + as instructed above. This problem is corrected in version + 1.3.5a.

    + +

    Version 1.3.n, n < 4

    + +

    The "shorewall start" and "shorewall restart" commands + to not verify that the zones named in the /etc/shorewall/policy +file have been previously defined in the /etc/shorewall/zones +file. The "shorewall check" command does perform this verification +so it's a good idea to run that command after you have made configuration + changes.

    + +

    Version 1.3.n, n < 3

    + +

    If you have upgraded from Shorewall 1.2 and after + "Activating rules..." you see the message: "iptables: No chains/target/match + by that name" then you probably have an entry in /etc/shorewall/hosts + that specifies an interface that you didn't include +in /etc/shorewall/interfaces. To correct this problem, you + must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 + and later versions produce a clearer error message in +this case.

    + +

    Version 1.3.2

    + +

    Until approximately 2130 GMT on 17 June 2002, the + download sites contained an incorrect version of the .lrp file. That + file can be identified by its size (56284 bytes). The correct +version has a size of 38126 bytes.

    + +
      +
    • The code to detect a duplicate interface + entry in /etc/shorewall/interfaces contained a typo that + prevented it from working correctly.
      • +
    • "NAT_BEFORE_RULES=No" was broken; +it behaved just like "NAT_BEFORE_RULES=Yes".
      • + +
    + +

    Both problems are corrected in + this script which should be installed in /var/lib/shorewall + as described above.

    + +
      +
    • + + +

      The IANA have just announced the allocation of subnet + 221.0.0.0/8. This + updated rfc1918 file reflects that allocation.

      +
      • + +
    +

    Version 1.3.1

    - +
      -
    • TCP SYN packets may be double counted - when LIMIT:BURST is included in a CONTINUE or ACCEPT policy - (i.e., each packet is sent through the limit chain twice).
      • -
    • An unnecessary jump to the policy chain - is sometimes generated for a CONTINUE policy.
      • -
    • When an option is given for more than - one interface in /etc/shorewall/interfaces then depending - on the option, Shorewall may ignore all but the first - appearence of the option. For example:
      -
      - net    eth0    dhcp
      - loc    eth1    dhcp
      -
      - Shorewall will ignore the 'dhcp' on eth1.
      • -
    • Update 17 June 2002 - The bug described - in the prior bullet affects the following options: dhcp, - dropunclean, logunclean, norfc1918, routefilter, multi, - filterping and noping. An additional bug has been found - that affects only the 'routestopped' option.
      -
      - Users who downloaded the corrected script - prior to 1850 GMT today should download and install -the corrected script again to ensure that this second -problem is corrected.
      • - +
    • TCP SYN packets may be double counted + when LIMIT:BURST is included in a CONTINUE or ACCEPT policy + (i.e., each packet is sent through the limit chain twice).
      • +
    • An unnecessary jump to the policy +chain is sometimes generated for a CONTINUE policy.
      • +
    • When an option is given for more than + one interface in /etc/shorewall/interfaces then depending + on the option, Shorewall may ignore all but the first + appearence of the option. For example:
      +
      + net    eth0    dhcp
      + loc    eth1    dhcp
      +
      + Shorewall will ignore the 'dhcp' on eth1.
      • +
    • Update 17 June 2002 - The bug described + in the prior bullet affects the following options: +dhcp, dropunclean, logunclean, norfc1918, routefilter, +multi, filterping and noping. An additional bug has been +found that affects only the 'routestopped' option.
      +
      + Users who downloaded the corrected script + prior to 1850 GMT today should download and install + the corrected script again to ensure that this second + problem is corrected.
      • +
    - +

    These problems are corrected in - this firewall script which should be installed in /etc/shorewall/firewall - as described above.

    - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall"> + this firewall script which should be installed in /etc/shorewall/firewall + as described above.

    +

    Version 1.3.0

    - +
      -
    • Folks who downloaded 1.3.0 from the -links on the download page before 23:40 GMT, 29 May -2002 may have downloaded 1.2.13 rather than 1.3.0. The -"shorewall version" command will tell you which version - that you have installed.
      • -
    • The documentation NAT.htm file uses -non-existent wallpaper and bullet graphic files. The - - corrected version is here.
      • - +
    • Folks who downloaded 1.3.0 from the + links on the download page before 23:40 GMT, 29 May + 2002 may have downloaded 1.2.13 rather than 1.3.0. +The "shorewall version" command will tell you which version + that you have installed.
      • +
    • The documentation NAT.htm file uses + non-existent wallpaper and bullet graphic files. The + + corrected version is here.
      • +
    - -
    + +

    Upgrade Issues

    - +

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with - iptables version 1.2.3

    - -
    - -

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, -RedHat released this buggy iptables in RedHat 7.2. 

    + +
    +

    Problem with + iptables version 1.2.3

    + +
    + +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

    - +

    I have built a - corrected 1.2.3 rpm which you can download here  and I have + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm"> + corrected 1.2.3 rpm which you can download here  and I have also built an - iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

    + href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm"> +iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can -download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works + +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you can + download from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works fine.

    - -

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification - while this patch + +

    If you would like to patch iptables 1.2.3 yourself, + the patches are available for download. This patch + which corrects a problem with parsing of the --log-level specification + while this patch corrects a problem in handling the  TOS target.

    - +

    To install one of the above patches:

    - +
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • + + +
    +
    + + +

    Problems with kernels >= 2.4.18 + and RedHat iptables

    + +
    + +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + may experience the following:

    -
- - - -

Problems with kernels >= 2.4.18 - and RedHat iptables

- -
- -

Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

- - -
- +
+ 
# shorewall start
Processing /etc/shorewall/shorewall.conf ...
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
-
+
- -

The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 version - of iptables, you will need to specify the --oldpackage option + +

The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem +by installing + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

-
+ - -

Problems installing/upgrading - RPM on SuSE

+ +

Problems installing/upgrading + RPM on SuSE

- -

If you find that rpm complains about a conflict - with kernel <= 2.2 yet you have a 2.4 kernel - installed, simply use the "--nodeps" option to - rpm.

+ +

If you find that rpm complains about a conflict + with kernel <= 2.2 yet you have a 2.4 kernel + installed, simply use the "--nodeps" option to + rpm.

- +

Installing: rpm -ivh --nodeps <shorewall rpm>

- +

Upgrading: rpm -Uvh --nodeps <shorewall rpm>

- -

Problems with - iptables version 1.2.7 and MULTIPORT=Yes

+ +

Problems with + iptables version 1.2.7 and MULTIPORT=Yes

- -

The iptables 1.2.7 release of iptables has made - an incompatible change to the syntax used to - specify multiport match rules; as a consequence, - if you install iptables 1.2.7 you must be running - Shorewall 1.3.7a or later or:

+ +

The iptables 1.2.7 release of iptables has made + an incompatible change to the syntax used to + specify multiport match rules; as a consequence, + if you install iptables 1.2.7 you must be running + Shorewall 1.3.7a or later or:

- +
    -
  • set MULTIPORT=No +
  • set MULTIPORT=No in /etc/shorewall/shorewall.conf; or
    • -
  • if you are running - Shorewall 1.3.6 you may install +
  • if you are running + Shorewall 1.3.6 you may install - this firewall script in /var/lib/shorewall/firewall - as described above.
    • - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall"> + this firewall script in /var/lib/shorewall/firewall + as described above. +
- +

Problems with RH Kernel 2.4.18-10 and NAT
-

- /etc/shorewall/nat entries of the following form will result - in Shorewall being unable to start:
-
- + + /etc/shorewall/nat entries of the following form will result + in Shorewall being unable to start:
+
+ 
#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
192.0.2.22      eth0            192.168.9.22    yes                     yes
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
- Error message is:
- + Error message is:
+ 
Setting up NAT...
iptables: Invalid argument
Terminated

- The solution is to put "no" in the LOCAL column. Kernel -support for LOCAL=yes has never worked properly and 2.4.18-10 has -disabled it. The 2.4.19 kernel contains corrected support under a new + The solution is to put "no" in the LOCAL column. Kernel +support for LOCAL=yes has never worked properly and 2.4.18-10 has +disabled it. The 2.4.19 kernel contains corrected support under a new kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
- -

Last updated 2/18/2003 - - Tom Eastep

- + +

Last updated 2/18/2003 - + Tom Eastep

+

Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-

-
-
-
-
-
-
-
-
-
-
-
-
+

diff --git a/STABLE/documentation/mailing_list.htm b/STABLE/documentation/mailing_list.htm index 094d29e17..ff74b41a7 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -2,152 +2,156 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - - - - - -
+
- +

Vexira Logo -

+ - - - + +

 

- 		- + +

Shorewall Mailing Lists

- 		+ (Postfix Logo) -
- +
+ -
- + +
+

-
- Powered by Postfix    
-
-
+
+ Powered by Postfix    
+
+ + -

If you experience problems with any of these lists, please + + + + +

REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please +read the Shorewall Support +Guide.
+

+

If you experience problems with any of these lists, please let me know

- +

Not able to Post Mail to shorewall.net?

- -

You can report such problems by sending mail to tom dot eastep - at hp dot com.

- + +

You can report such problems by sending mail to tom dot eastep + at hp dot com.

+

A Word about SPAM Filters 

- -

Before subscribing please read my policy - about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
-

- + +

Before subscribing please read my policy + about list traffic that bounces. Also please note that the mail server + at shorewall.net checks incoming mail:
+

+
    -
  1. against Spamassassin - (including Vipul's Razor).
    -
    2. -
  2. to ensure that the sender address is fully qualified.
    3. -
  3. to verify that the sender's domain has an A or MX +
  4. against Spamassassin + (including Vipul's Razor).
    +
    5. +
  5. to ensure that the sender address is fully qualified.
    6. +
  6. to verify that the sender's domain has an A or MX record in DNS.
    7. -
  7. to ensure that the host name in the HELO/EHLO command +
  8. to ensure that the host name in the HELO/EHLO command is a valid fully-qualified DNS name that resolves.
    9. - +
- +

Please post in plain text

- A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net - "for continuous abuse" because it has been my policy to allow HTML in + A growing number of MTAs serving list subscribers are rejecting + all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net + "for continuous abuse" because it has been my policy to allow HTML in list posts!!
-
- I think that blocking all HTML is a Draconian way to control spam - and that the ultimate losers here are not the spammers but the list -subscribers whose MTAs are bouncing all shorewall.net mail. As one list -subscriber wrote to me privately "These e-mail admin's need to get a (explitive - deleted) life instead of trying to rid the planet of HTML based e-mail". - Nevertheless, to allow subscribers to receive list posts as must as possible, - I have now configured the list server at shorewall.net to strip all HTML - from outgoing posts. This means that HTML-only posts will be bounced by -the list server.
- +
+ I think that blocking all HTML is a Draconian way to control +spam and that the ultimate losers here are not the spammers but the +list subscribers whose MTAs are bouncing all shorewall.net mail. As +one list subscriber wrote to me privately "These e-mail admin's need to +get a (explitive deleted) life instead of trying to rid the planet +of HTML based e-mail". Nevertheless, to allow subscribers to receive list +posts as must as possible, I have now configured the list server at shorewall.net +to strip all HTML from outgoing posts. This means that HTML-only posts +will be bounced by the list server.
+

Note: The list server limits posts to 120kb.
-

- +

+

Other Mail Delivery Problems

- If you find that you are missing an occasional list post, your e-mail - admin may be blocking mail whose Received: headers contain the -names of certain ISPs. Again, I believe that such policies hurt more than -they help but I'm not prepared to go so far as to start stripping Received: - headers to circumvent those policies.
- + If you find that you are missing an occasional list post, your +e-mail admin may be blocking mail whose Received: headers contain +the names of certain ISPs. Again, I believe that such policies hurt more +than they help but I'm not prepared to go so far as to start stripping Received: + headers to circumvent those policies.
+

Mailing Lists Archive Search

- -
- -

Match: - + + + +

Match: + - Format: - + Format: + - Sort by: - + Sort by: + -
- Search:

- + - -

Please do not try to download the -entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply -won't stand the traffic. If I catch you, you will be blacklisted.
-

- + +

Please do not try to download the entire +Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't +stand the traffic. If I catch you, you will be blacklisted.
+

+

Shorewall CA Certificate

- If you want to trust X.509 certificates issued by Shoreline + If you want to trust X.509 certificates issued by Shoreline Firewall (such as the one used on my web site), you may download and install my CA certificate - in your browser. If you don't wish to trust my certificates then -you can either use unencrypted access when subscribing to Shorewall -mailing lists or you can use secure access (SSL) and accept the server's -certificate when prompted by your browser.
- + href="Shorewall_CA_html.html">download and install my CA certificate + in your browser. If you don't wish to trust my certificates then + you can either use unencrypted access when subscribing to Shorewall + mailing lists or you can use secure access (SSL) and accept the server's + certificate when prompted by your browser.
+

Shorewall Users Mailing List

- -

The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information -of general interest to the Shorewall user community is also posted -to this list.

- -

Before posting a problem report to this list, please see - the problem reporting - guidelines.

- -

To subscribe to the mailing list:
-

- - - -

To post to the list, post to shorewall-users@lists.shorewall.net.

- -

The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

- -

Note that prior to 1/1/2002, the mailing list was hosted at -Sourceforge. The archives from that list -may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

- -

Shorewall Announce Mailing List

- -

This list is for announcements of general interest to the - Shorewall community. To subscribe:
-

- -

- - - -


- The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

- -

Shorewall Development Mailing List

- -

The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

- + +

The Shorewall Users Mailing list provides a way for users + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also posted + to this list.

+ +

Before posting a problem report to this list, please see + the problem reporting + guidelines.

+

To subscribe to the mailing list:

- + + +

To post to the list, post to shorewall-users@lists.shorewall.net.

+ +

The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

+ +

Note that prior to 1/1/2002, the mailing list was hosted +at Sourceforge. The archives from that +list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

+ +

Shorewall Announce Mailing List

+ +

This list is for announcements of general interest to the + Shorewall community. To subscribe:
+

+ +

+ + + +


+ The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

+ +

Shorewall Development Mailing List

+ +

The Shorewall Development Mailing list provides a forum for + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

+ +

To subscribe to the mailing list:
+

+ + - +

To post to the list, post to shorewall-devel@lists.shorewall.net. 

- +

The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.

- -

How to Unsubscribe from one of - the Mailing Lists

- -

There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists although Mailman 2.1 has attempted to - make this less confusing. To unsubscribe:

- + +

How to Unsubscribe from one of + the Mailing Lists

+ +

There seems to be near-universal confusion about unsubscribing + from Mailman-managed lists although Mailman 2.1 has attempted +to make this less confusing. To unsubscribe:

+
    -
  • - -

    Follow the same link above that you used to subscribe - to the list.

    -
    • -
  • - -

    Down at the bottom of that page is the following text: - " To unsubscribe from <list name>, get a password - reminder, or change your subscription options enter your subscription - email address:". Enter your email address in the box and -click on the "Unsubscribe or edit options" button.

    -
    • -
  • - -

    There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, - there is another button that will cause your password to be emailed - to you.

    -
    • - +
  • + +

    Follow the same link above that you used to subscribe + to the list.

    +
    • +
  • + +

    Down at the bottom of that page is the following text: + " To unsubscribe from <list name>, get a +password reminder, or change your subscription options enter +your subscription email address:". Enter your email address + in the box and click on the "Unsubscribe or edit options" button.

    +
    • +
  • + +

    There will now be a box where you can enter your password + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.

    +
    • +
- -
+ +

Frustrated by having to Rebuild Mailman to use it with Postfix?

- +

Check out these instructions

- -

Last updated 2/18/2003 - Last updated 2/24/2003 - Tom Eastep

- -

Copyright -© 2001, 2002, 2003 Thomas M. Eastep.
-

+ +

Copyright © +2001, 2002, 2003 Thomas M. Eastep.
+

+


diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index a37f4e966..844c6a6e2 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -6,7 +6,7 @@ - + Shoreline Firewall (Shorewall) 1.3 @@ -15,22 +15,22 @@ - + - + - + - + - + + + + + + + - - -
- - - - - - - - - - - - + +
+ @@ -39,15 +39,16 @@ - + +

Shorwall Logo - Shorewall - 1.3 - "iptables - made easy"

+ Shorewall + 1.3 - "iptables + made easy" @@ -57,43 +58,43 @@ + + + +
+ +
- -
- -
- + +
+ +
+ - + - + - + - - + - - - + + +
+ @@ -103,7 +104,7 @@ - +

What is it?

@@ -115,11 +116,12 @@ - -

The Shoreline Firewall, more commonly known as "Shorewall", is -a Netfilter (iptables) based -firewall that can be used on a dedicated firewall system, a multi-function - gateway/router/server or on a standalone GNU/Linux system.

+ + +

The Shoreline Firewall, more commonly known as "Shorewall", is a + Netfilter (iptables) based firewall + that can be used on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

@@ -130,29 +132,30 @@ firewall that can be used on a dedicated firewall system, a multi-functio - -

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 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

@@ -163,7 +166,8 @@ MA 02139, USA

- + +

Copyright 2001, 2002, 2003 Thomas M. Eastep

@@ -175,32 +179,33 @@ MA 02139, USA

- + +

- 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.10 and Kernel-2.4.18. - You can find their work at: http://leaf.sourceforge.net/devel/jnilo
-

+ 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: + http://leaf.sourceforge.net/devel/jnilo
+

- -

Congratulations to Jacques and Eric on the recent release of -Bering 1.0 Final!!!
-

+ +

Congratulations to Jacques and Eric on the recent release of Bering +1.1!!!
+

- -

This is a mirror of the main Shorewall web site at SourceForge -(http://shorewall.sf.net)

+ +

This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)

@@ -214,7 +219,7 @@ Bering 1.0 Final!!!
- +

News

@@ -226,7 +231,7 @@ Bering 1.0 Final!!!
- +

@@ -235,127 +240,193 @@ Bering 1.0 Final!!!
- -

2/8/2003 - Shorewall 1.3.14 (New) -

- -

New features include

- -
    -
  1. 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.
    -
    -
    2. -
  2. 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
    -  
    3. -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. -
  4. Support for VLAN devices with names of the form $DEV.$VID -(e.g., eth0.0)
    -
    -
    5. -
  5. 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.
    -
    -
    6. -
  6. 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.
    -   
    - +

    2/21/2003 - Shorewall 1.4.0 Beta 1 (New) +  

    + 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:
    + +
      +
    1. 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.
      +
      +
      2. +
    2. Interface names of the form <device>:<integer> in +/etc/shorewall/interfaces now generate an error.
      +
      +
      3. +
    3. 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.
      +
      +
      4. +
    4. 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.
      +
      +
      5. +
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
      +
      +
      6. +
    6. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
      7. +
    7. The icmp.def file has been removed.
      +
      8. + +
    + Changes for 1.4 include:
    + +
      +
    1. The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
      +
      +
      2. +
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      3. +
    3. The firewall script and version file are now installed in /usr/share/shorewall.
      +
      +
      4. +
    4. Late arriving DNS replies are now silently dropped in the common + chain by default.
      +
      +
      5. +
    5. 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. +
      6. + +
    + +

    2/8/2003 - Shorewall 1.3.14

    + +

    New features include

    + +
      +
    1. 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.
      +
      +
      2. +
    2. 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
      +  
      3. +
    3. Support for OpenVPN Tunnels.
      +
      +
      4. +
    4. Support for VLAN devices with names of the form $DEV.$VID + (e.g., eth0.0)
      +
      +
      5. +
    5. 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.
      +
      +
      6. +
    6. 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:
      -   
      +  
      + 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?
      -  
      +  
      +    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:
      +  
      +    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
      -
      7. - + +
    -
    - -

    2/5/2003 - Shorewall Support included in Webmin 1.060 - (New) -

    - Webmin version 1.060 now has Shorewall support included as standard. - See http://www.webmin.com. - +
    + +

    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. +

    - +

    - +
      - +
    @@ -363,7 +434,7 @@ listing specific subnetworks if the change described above will cause masquerad - +

    More News

    @@ -375,44 +446,45 @@ listing specific subnetworks if the change described above will cause masquerad - + +

    Donations

    -
M
-
+
-
+
- + - + - + - + - + - - - + + +
- + @@ -420,12 +492,13 @@ listing specific subnetworks if the change described above will cause masquerad - + +

-  

+  

@@ -436,31 +509,35 @@ listing specific subnetworks if the change described above will cause masquerad - -

Shorewall is free -but if you try it and find it useful, please consider making a donation - to Starlight -Children's Foundation. Thanks!

+ +

Shorewall is free but +if you try it and find it useful, please consider making a donation + to Starlight Children's +Foundation. Thanks!

-
- -

Updated 2/13/2003 - Tom Eastep - -
-

+ + +

Updated 2/21/2003 - Tom Eastep + +
+

+
+
+
diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index ceebf3c3f..40d2f62b4 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -6,7 +6,7 @@ - + Shoreline Firewall (Shorewall) 1.3 @@ -15,22 +15,24 @@ - + - + - + - + - - + + - - - + + +
+ @@ -40,13 +42,12 @@ -

Shorwall Logo - Shorewall 1.3 - "iptables made easy"

@@ -59,35 +60,36 @@ - + + -
- -
- -
- + +
+ +
+ - + - + - + - + - + - - - + + +
+ @@ -97,7 +99,8 @@ - + +

What is it?

@@ -110,12 +113,12 @@ - -

The Shoreline Firewall, more commonly known as  "Shorewall", is - a Netfilter (iptables) -based firewall that can be used on a dedicated firewall system, -a multi-function gateway/router/server or on a standalone GNU/Linux -system.

+ +

The Shoreline Firewall, more commonly known as  "Shorewall", is + a Netfilter (iptables) + based firewall that can be used on a dedicated firewall system, + a multi-function gateway/router/server or on a standalone GNU/Linux + system.

@@ -127,29 +130,29 @@ system.

- -

This program is free software; you can redistribute it and/or modify - it under the terms - of Version - 2 of the GNU General Public License as published by the Free Software - Foundation.
+ +

This program is 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

@@ -161,7 +164,7 @@ for more details.
- +

Copyright 2001, 2002, 2003 Thomas M. Eastep

@@ -174,23 +177,23 @@ for more details.
- +

- 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.10 - and Kernel-2.4.18. You can find their work at: - http://leaf.sourceforge.net/devel/jnilo

- Congratulations to Jacques - and Eric on the recent release of Bering 1.0 Final!!!
- + 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: + http://leaf.sourceforge.net/devel/jnilo

+ Congratulations to Jacques + and Eric on the recent release of Bering 1.1!!!
+ - +

News

@@ -205,107 +208,180 @@ for more details.
- -

2/8/2003 - Shorewall 1.3.14 2/21/2003 - Shorewall 1.4.0 Beta 1 (New) -

- -

New features 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:
+
    -
  1. 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.
    -
    -
    2. -
  2. 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
    -  
    3. -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. -
  4. Support for VLAN devices with names of the form $DEV.$VID -(e.g., eth0.0)
    -
    -
    5. -
  5. 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.
    +
  6. 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.
    +
    +
    7. +
  7. Interface names of the form <device>:<integer> in +/etc/shorewall/interfaces now generate an error.
    +
    +
    8. +
  8. 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.
    +
    +
    9. +
  9. 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.
    +
    +
    10. +
  10. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
    +
    +
    11. +
  11. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.

    12. -
  12. 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
    -
    13. - +
  13. The icmp.def file has been removed.
    +
    14. +
- -

2/5/2003 - Shorewall Support included in Webmin 1.060 - (New) -

- Webmin version 1.060 now has Shorewall support included as standard. - See http://www.webmin.com - + Changes for 1.4 include:
+ +
    +
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
    +
    +
    2. +
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    3. +
  3. The firewall script and version file are now installed in /usr/share/shorewall.
    +
    +
    4. +
  4. Late arriving DNS replies are now silently dropped in the common + chain by default.
    +
    +
    5. +
  5. 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. +
    6. + +
+ +

2/8/2003 - Shorewall 1.3.14

+ +

New features include

+ +
    +
  1. 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.
    +
    +
    2. +
  2. 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
    +  
    3. +
  3. Support for OpenVPN Tunnels.
    +
    +
    4. +
  4. Support for VLAN devices with names of the form $DEV.$VID + (e.g., eth0.0)
    +
    +
    5. +
  5. 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.
    +
    +
    6. +
  6. 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
    +
    7. + +
+ +

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 +

@@ -315,7 +391,7 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- +
    @@ -324,7 +400,7 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
    - +
@@ -333,7 +409,7 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- +

More News

@@ -346,31 +422,31 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- +

- +

SourceForge Logo -

+ - +

- +

This site is hosted by the generous folks at SourceForge.net

@@ -378,44 +454,44 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- +

Donations

-
-
-
+
-
+
- + - + - + - + +

Shorewall is free but +if you try it and find it useful, please consider making a donation + to Starlight Children's +Foundation. Thanks!

- + + + - - - + + +
+ @@ -424,12 +500,13 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- + +

-

+

@@ -440,32 +517,36 @@ masquerading to occur on subnetworks that you don't wish to masquerade.
- -

Shorewall is free -but if you try it and find it useful, please consider making a donation - to Starlight -Children's Foundation. Thanks!

-
- -

Updated 2/14/2003 - Tom Eastep - -
-

+ +

Updated 2/19/2003 - Tom Eastep + +
+

+
+
+
diff --git a/STABLE/documentation/spam_filters.htm b/STABLE/documentation/spam_filters.htm index b44664292..11ba8eb3d 100644 --- a/STABLE/documentation/spam_filters.htm +++ b/STABLE/documentation/spam_filters.htm @@ -1,62 +1,69 @@ - + - + - + - + SPAM Filters - + - - - + + - - - + + + +
+

SPAM Filters

-
- +


- (SpamAssassin Logo) - -

- -

Like all of you, I'm concerned about the increasing volume of Unsolicited -Commercial Email (UCE or SPAM). I am therefore sympathetic with those of -you who are installing SPAM filters on your mail servers. A couple of recent -incidents involving mis-configured filters have prompted me to establish -this page to spell out what I will do when these filters bounce list postings.

- -

When your SPAM filter bounces/rejects list mail, I will:

- + + +

Like all of you, I'm concerned about the increasing volume of Unsolicited + Commercial Email (UCE or SPAM). I am therefore sympathetic with those of +you who are installing SPAM filters on your mail servers. A couple of recent +incidents involving mis-configured filters have prompted me to establish this +page to spell out what I will do when these filters bounce list postings.

+ +

When your SPAM filter bounces/rejects list mail and I can identify +who you are, I will:

+
    -
  1. immediately turn off delivery to you from all Shorewall lists to which -you subscribe.
    2. -
  2. try to send you an email from a source other than shorewall.net
    3. - +
  3. immediately turn off delivery to you from all Shorewall lists to +which you subscribe.
    4. +
  4. try to send you an email from a source other than shorewall.net
    5. +
- -

When you have corrected the problem, please let me know and I will re-enable -delivery (or you can reenable delivery yourself).

- + +

When you have corrected the problem, please let me know and I will re-enable + delivery (or you can reenable delivery yourself).
+

+

Note that many brain-dead spam filters inform the sender that a post was +rejected as spam but fail to provide any clue about the original addressee!!! +If I don't know who you are, I can't tell you about the problem...
+

+

Last Updated 1/29/2003 - Tom Eastep

- -

Copyright + +

Copyright © 2001, 2002, 2003 Thomas M. Eastep.

-
+
+
diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index ba24f7016..9dbdce6a8 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -2,129 +2,131 @@ - + - + - + - + Support - + + - - - + + - + + + - - + +
+
- +

Shorewall Support -

-
-

While I don't answer Shorewall  questions - emailed directly to me, I try to spend some time each day answering questions + +

While I don't answer Shorewall  questions + emailed directly to me, I try to spend some time each day answering questions on the Shorewall Users Mailing List.

- +

-Tom Eastep

- +

Before Reporting a Problem

- "Well at least you tried to read the documentation, which is a lot more -than some people on this list appear to do."
-
- + "Well at least you tried to read the documentation, which is a lot more + than some people on this list appear to do."
+
+
- Wietse Venema - On the Postfix mailing list
-
-
- There are a number of sources for - problem solution information. Please try these before you post. +
+
+ There are a number of sources for + problem solution information. Please try these before you post.

- +

- +
    -
  • More than half of the questions posted on the support +
  • More than half of the questions posted on the support list have answers directly accessible from the Documentation Index
    -
    -
    • -
  • The FAQ - has solutions to more than 20 common problems.
    • - +
    + +
  • The FAQ + has solutions to more than 20 common problems.
    • +
- +

- + - +

- +
    -
  • The Errata has links to download updated - components.
    • - +
  • The Errata has links to download updated + components.
    • +
- +

- +
    -
  • The Mailing List - Archives search facility can locate posts about similar +
  • The Mailing List + Archives search facility can locate posts about similar problems:
    • - +
- +

- +

Mailing List Archive Search

- -
- - -

Match: - + + + + +

Match: + - Format: - + Format: + - Sort by: - + Sort by: + -
- Search:

- - + +

Problem Reporting Guidelines

- "Let me see if I can translate your message into a real-world - example. It would be like saying that you have three rooms at home, - and when you walk into one of the rooms, you detect this strange smell. + "Let me see if I can translate your message into a real-world + example. It would be like saying that you have three rooms at home, + and when you walk into one of the rooms, you detect this strange smell. Can anyone tell you what that strange smell is?
-
- Now, all of us could do some wonderful guessing as to the -smell and even what's causing it. You would be absolutely amazed at -the range and variety of smells we could come up with. Even more amazing -is that all of the explanations for the smells would be completely plausible."
-
- +
+ Now, all of us could do some wonderful guessing as to the + smell and even what's causing it. You would be absolutely amazed +at the range and variety of smells we could come up with. Even more +amazing is that all of the explanations for the smells would be completely +plausible."
+
+
- Russell Mosemann on the Postfix mailing list
-
-
+ +
- +

- +
    -
  • Please remember we only know what is posted in your message. - Do not leave out any information that appears to be correct, or was -mentioned in a previous post. There have been countless posts by people -who were sure that some part of their configuration was correct when -it actually contained a small error. We tend to be skeptics where detail +
  • Please remember we only know what is posted in your message. + Do not leave out any information that appears to be correct, or was +mentioned in a previous post. There have been countless posts by people +who were sure that some part of their configuration was correct when it +actually contained a small error. We tend to be skeptics where detail is lacking.
    -
    -
    • -
  • Please keep in mind that you're asking for free - technical support. Any help we offer is an act of generosity, not an -obligation. Try to make it easy for us to help you. Follow good, courteous -practices in writing and formatting your e-mail. Provide details that -we need if you expect good answers. Exact quoting of error messages, -log entries, command output, and other output is better than a paraphrase +
    +
    • +
  • Please keep in mind that you're asking for free + technical support. Any help we offer is an act of generosity, not an +obligation. Try to make it easy for us to help you. Follow good, courteous +practices in writing and formatting your e-mail. Provide details that +we need if you expect good answers. Exact quoting of error messages, +log entries, command output, and other output is better than a paraphrase or summary.
    -
    -
    • -
  • Please don't describe -your environment and then ask us to send you custom -configuration files. We're here to answer your questions but -we can't do your job for you.
    -
    -
    • -
  • When reporting a problem, ALWAYS include -this information:
    • - +
    + +
  • Please don't describe +your environment and then ask us to send you custom +configuration files. We're here to answer your questions but we + can't do your job for you.
    +
    +
    • +
  • When reporting a problem, ALWAYS include + this information:
    • + +
+ +
    + +
      +
    • the exact version of Shorewall you are running.
      +
      + shorewall version
      +
      +
      • + +
    + +
      +
    • the exact kernel version you are running
      +
      + uname -a
      +
      +
      • + +
    + +
      +
    • the complete, exact output of
      +
      + ip addr show
      +
      +
      • + +
    + +
      +
    • the complete, exact output of
      +
      + ip route show
      +
      +
      • + +
    + +
      +
    • If your kernel is modularized, the exact output from
      +
      + lsmod
      +
      +
      • +
    • the exact wording of any ping failure responses
      +
      +
      • +
    • If you installed Shorewall using one of the QuickStart Guides, +please indicate which one.
      +
      +
      • +
    • If you are running Shorewall under Mandrake using the Mandrake + installation of Shorewall, please say so.
      +
      +
      • + +
    +
    - -
      -
    • the exact version of Shorewall you are running.
      -
      - shorewall version
      -
      -
      • - -
    - -
      -
    • the exact kernel version you are running
      -
      - uname -a
      -
      -
      • - -
    - -
      -
    • the complete, exact output of
      -
      - ip addr show
      -
      -
      • - -
    - -
      -
    • the complete, exact output of
      -
      - ip route show
      -
      -
      • - -
    - -
      -
    • If your kernel is modularized, the exact output from
      -
      - lsmod
      -
      -
      • -
    • the exact wording of any ping failure responses
      -
      -
      • -
    • If you installed Shorewall using one of the QuickStart Guides, -please indicate which one.
      -
      -
      • -
    • If you are running Shorewall under Mandrake using the Mandrake - installation of Shorewall, please say so.
      -
      -
      • - -
    - -
- -
    -
  • NEVER include the output of "iptables -L". Instead, if you are having -connection problems of any kind, post the exact output of
    -
    - /sbin/shorewall status
    -
    -     Since that command generates a lot of output, we -suggest that you redirect the output to a file and attach the file to -your post
    -
    - /sbin/shorewall status > /tmp/status.txt
    -
    -
    • -
  • As a general matter, please do not edit the diagnostic - information in an attempt to conceal your IP address, netmask, - nameserver addresses, domain name, etc. These aren't secrets, and concealing - them often misleads us (and 80% of the time, a hacker could derive them +
  • NEVER include the output of "iptables -L". Instead, if you are having connection problems of +any kind then:
    +
    +1. /sbin/shorewall/reset
    +
    +2. Try the connection that is failing.
    +
    +3. /sbin/shorewall status > /tmp/status.txt
    +
    +4. Post the /tmp/status.txt file as an attachment.
    +
    +
    • +
  • As a general matter, please do not edit the diagnostic + information in an attempt to conceal your IP address, netmask, + nameserver addresses, domain name, etc. These aren't secrets, and concealing + them often misleads us (and 80% of the time, a hacker could derive them anyway from information contained in the SMTP headers of your post).
    • - +
- +
    - +
- +

- +
    - +
- +

- +
    -
  • Do you see any -"Shorewall" messages ("/sbin/shorewall show -log") when you exercise the function that is giving -you problems? If so, include the message(s) in your post along with a +
  • Do you see any +"Shorewall" messages ("/sbin/shorewall show +log") when you exercise the function that is giving +you problems? If so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces file.
    -
    -
    • -
  • Please include any of the Shorewall configuration files - (especially the /etc/shorewall/hosts file if you have modified - that file) that you think are relevant. If you include /etc/shorewall/rules, - please include /etc/shorewall/policy as well (rules are meaningless -unless one also knows the policies).
    • - +
    + +
  • Please include any of the Shorewall configuration files + (especially the /etc/shorewall/hosts file if you have modified + that file) that you think are relevant. If you include /etc/shorewall/rules, + please include /etc/shorewall/policy as well (rules are meaningless unless + one also knows the policies).
    • +
- +

- +
    - +
- +

- +
    -
  • If an error occurs -when you try to "shorewall start", - include a trace (See the Troubleshooting +
  • If an error occurs + when you try to "shorewall start", + include a trace (See the Troubleshooting section for instructions).
    • - +
- +

- +
    -
  • +
  • + +

    The list server limits posts to 120kb so don't post GIFs of + your network layout, etc. to the Mailing List -- your + post will be rejected.

    +
    • -

    The list server limits posts to 120kb so don't post GIFs of - your network layout, etc. to the Mailing List -- your - post will be rejected.

    - -
- The author gratefully acknowleges that the above list was heavily - plagiarized from the excellent LEAF document by Ray Olszewski - found at Ray
 Olszewski + found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
- +

Please post in plain text

- +
- A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net - "for continuous abuse" because it has been my policy to allow HTML in - list posts!!
-
- I think that blocking all HTML is a Draconian way to control - spam and that the ultimate losers here are not the spammers but the list - subscribers whose MTAs are bouncing all shorewall.net mail. As one -list subscriber wrote to me privately "These e-mail admin's need to get -a (expletive deleted) life instead of trying to rid the planet -of HTML based e-mail". Nevertheless, to allow subscribers to receive list -posts as must as possible, I have now configured the list server at shorewall.net -to strip all HTML from outgoing posts.
- + A growing number of MTAs serving list subscribers are rejecting + all HTML traffic. At least one MTA has gone so far as to blacklist +shorewall.net "for continuous abuse" because it has been my policy to +allow HTML in list posts!!
+
+ I think that blocking all HTML is a Draconian way to control + spam and that the ultimate losers here are not the spammers but the +list subscribers whose MTAs are bouncing all shorewall.net mail. As +one list subscriber wrote to me privately "These e-mail admin's need +to get a (expletive deleted) life instead of trying to rid the +planet of HTML based e-mail". Nevertheless, to allow subscribers to receive +list posts as must as possible, I have now configured the list server +at shorewall.net to strip all HTML from outgoing posts.
+

Where to Send your Problem Report or to Ask for Help

- -
+ +

If you run Shorewall under Bering -- please post your question or problem - to the LEAF Users - mailing list.

- If you run Shorewall under MandrakeSoft Multi Network Firewall - (MNF) and you have not purchased an MNF license from MandrakeSoft then - you can post non MNF-specific Shorewall questions to the Shorewall users mailing - list. Do not expect to get free MNF support on the list.
- + style="font-weight: 400;">please post your question or problem + to the LEAF Users + mailing list. + If you run Shorewall under MandrakeSoft Multi Network +Firewall (MNF) and you have not purchased an MNF license from MandrakeSoft +then you can post non MNF-specific Shorewall questions to the Shorewall users mailing + list. Do not expect to get free MNF support on the list.
+

Otherwise, please post your question or problem to the Shorewall users mailing - list.

-
+ href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing + list.

+
- +

To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users + href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users .

- -

Last Updated 2/9/2003 - Tom Eastep

+ +

Last Updated 2/22/2003 - Tom Eastep

+

Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-

-
-
-
+

+
+
+
+



diff --git a/STABLE/firewall b/STABLE/firewall index daa6d72df..3be57778f 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -1577,10 +1577,10 @@ setup_mac_lists() { # for interface in $maclist_interfaces; do case $interface in - eth*) + eth*|wlan*) ;; *) - fatal_error "Error: MAC verification is only supported on ethernet devices: $interface" + fatal_error "Error: MAC verification is only supported on ethernet and 802.11b devices: $interface" ;; esac @@ -3084,12 +3084,11 @@ setup_intrazone() # $1 = zone { eval hosts=\$${1}_hosts - if [ "$hosts" != "${hosts% *}" ] || \ - have_interfaces_in_zone_with_option $1 multi - then + if have_interfaces_in_zone_with_option $1 multi; then ensurechain ${1}2${1} fi } + # # Add a record to the blacklst chain # @@ -3521,10 +3520,10 @@ add_common_rules() { if [ -n "$LOGUNCLEAN" ]; then if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:badpkt:DROP:" + logoptions="-j ULOG $LOGPARMS --ulog-prefix Shorewall:badpkt:DROP:" logoptions="$logoptions --log-ip-options" else - logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" + logoptions="-j LOG $LOGPARMS --log-prefix Shorewall:badpkt:DROP:" logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" fi @@ -3553,10 +3552,10 @@ add_common_rules() { [ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:logpkt:LOG:" + logoptions="-j ULOG $LOGPARMS --ulog-prefix Shorewall:logpkt:LOG:" logoptions="$logoptions --log-ip-options" else - logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" + logoptions="-j LOG $LOGPARMS --log-prefix Shorewall:logpkt:LOG:" logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" fi