From 1905dd9d1cbdcd05f6e646d41d4b88d531728649 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 29 May 2003 14:48:09 +0000 Subject: [PATCH] Shorewall 1.4.4b git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@576 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Lrp/usr/share/shorewall/firewall | 4 +- Lrp/usr/share/shorewall/version | 2 +- STABLE/changelog.txt | 2 + STABLE/documentation/FAQ.htm | 2350 ++++---- STABLE/documentation/News.htm | 4765 +++++++++-------- STABLE/documentation/errata.htm | 459 +- STABLE/documentation/mailing_list.htm | 410 +- STABLE/documentation/myfiles.htm | 317 +- .../documentation/seattlefirewall_index.htm | 500 +- STABLE/documentation/shoreline.htm | 157 +- STABLE/documentation/sourceforge_index.htm | 530 +- STABLE/documentation/support.htm | 456 +- STABLE/fallback.sh | 2 +- STABLE/firewall | 4 +- STABLE/install.sh | 2 +- STABLE/shorewall.spec | 4 +- STABLE/uninstall.sh | 2 +- 17 files changed, 5017 insertions(+), 4949 deletions(-) diff --git a/Lrp/usr/share/shorewall/firewall b/Lrp/usr/share/shorewall/firewall index 5eae0f2a3..d9cb5dd97 100755 --- a/Lrp/usr/share/shorewall/firewall +++ b/Lrp/usr/share/shorewall/firewall @@ -926,7 +926,7 @@ log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates fo eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' ;; *) - eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-level $level --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' ;; esac @@ -943,7 +943,7 @@ log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates fo eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' ;; *) - eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-level $level --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' ;; esac diff --git a/Lrp/usr/share/shorewall/version b/Lrp/usr/share/shorewall/version index d0688623d..25b670fc2 100644 --- a/Lrp/usr/share/shorewall/version +++ b/Lrp/usr/share/shorewall/version @@ -1 +1 @@ -1.4.4a +1.4.4b diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 4e3e328a4..ed8f7bf06 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -10,4 +10,6 @@ Changes since 1.4.3a 4. Don't include log rule number when LOGFORMAT doesn't include "%d". +5. Add --log-level to LOG rules. + diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index a2fb782f3..5bb4fddd7 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,1305 +1,1301 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
+

Shorewall FAQs

-
- +

Looking for Step by Step Configuration Instructions? Check out the QuickStart Guides.
-

- + +

PORT FORWARDING
-

- -

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

- -

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

- -

1c. From the internet, I want to connect -to port 1022 on my firewall and have the firewall forward the connection -to port 22 on local system 192.168.1.3. How do I do that?
-

- -

DNS and PORT FORWARDING/NAT
-

- -

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.

- -

NETMEETING/MSN
-

- -

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

- -

OPEN PORTS
-

- -

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

- 4b. I have a port that I can't close no matter -how I change my rules.  -

CONNECTION PROBLEMS

- -

5. I've installed Shorewall and now - I can't ping through the firewall
-
- 15. My local systems can't see -out to the net

- -

LOGGING
-

- -

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

- -

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 - 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. 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 6 bytes in length.
-

- -

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?
-
- 21. I see these strange log entries - occasionally; what are they?
- -

STARTING AND STOPPING
-

- -

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

- -

8a. When I try to start Shorewall - on RedHat I get a message referring me to FAQ #8
-

- -

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

- 22. I have - some iptables commands that I want to run when Shorewall - starts. Which file do I put them in?
- -

ABOUT SHOREWALL
-

- -

10. What distributions does - it work with?

- -

11. What features does it -support?

- -

12. Is there a GUI?

- -

13. Why do you call it "Shorewall"?

- 23. Why do you -use such ugly fonts on your web site?
-
- 25. How to I tell which version of Shorewall - I am running?
- -

RFC 1918
-

- -

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.

- -

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
-

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

MISCELLANEOUS

- 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 server from the internet?
-
- 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. + +

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

+ +

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

+ +

1c. From the internet, I want to +connect to port 1022 on my firewall and have the firewall forward +the connection to port 22 on local system 192.168.1.3. How do I do that?
+

+ +

DNS and PORT FORWARDING/NAT
+

+ +

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.

+ +

NETMEETING/MSN
+

+ +

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

+ +

OPEN PORTS
+

+ +

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

+ 4b. I have a port that I can't close no matter +how I change my rules.  +

CONNECTION PROBLEMS

+ +

5. I've installed Shorewall and now + I can't ping through the firewall
+
+ 15. My local systems can't see + out to the net

+ +

LOGGING
+

+ +

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

+ +

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 + 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. 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 6 bytes in length.
+

+ +

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?
+
+ 21. I see these strange log entries + occasionally; what are they?
+ +

STARTING AND STOPPING
+

+ +

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

+ +

8a. When I try to start Shorewall + on RedHat I get a message referring me to FAQ #8
+

+ +

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

+ 22. I +have some iptables commands that I want to run when +Shorewall starts. Which file do I put them in?
+ +

ABOUT SHOREWALL
+

+ +

10. What distributions does + it work with?

+ +

11. What features does it support?

+ +

12. Is there a GUI?

+ +

13. Why do you call it "Shorewall"?

+ 23. Why do you +use such ugly fonts on your web site?
+
+ 25. How to I tell which version of Shorewall + I am running?
+ +

RFC 1918
+

+ +

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.

+ +

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
+

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

MISCELLANEOUS
+

+ 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 server from the internet?
+
+ 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.

- +

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format + 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 +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:<local +
DNATnetloc:<local IP address>[:<local port>]<protocol><port + <protocol><port #>
-
-

+
+
-
- -

So to forward UDP port 7777 to internal system 192.168.1.5, +

+ +

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

- -
+ +
- - - - - - - - + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-
-
DNATnetloc:192.168.1.5udp7777
+
+
-
- -
If - you want to forward requests directed to a particular address - ( <external IP> ) on your firewall to an internal +
+ +
If + you want to forward requests directed to a particular address + ( <external IP> ) on your firewall to an internal system:
- -
+ +
- - - - - - - - + + + + + + + - - - - - - + + + + - - + - - + - - - + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:<local +
DNATnetloc:<local IP address>[:<local port>]<protocol><port + <protocol><port #>-<external + -<external IP>
-
- 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

- -

Answer: That is usually the result of one of three - things:

- - - -

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

- Answer: To further -diagnose this problem:
- - - -

1c. From the internet, I want - to connect to port 1022 on my firewall and have the firewall forward -the connection to port 22 on local system 192.168.1.3. How do I do that?

- -
-
- - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATnet
- 		loc:192.168.1.3:22tcp1022
-
-
-
-
-
- -

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.

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

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

- -

If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for -those releases.
-

- -

If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please - upgrade to Shorewall 1.4.2 or later.
-

- -

Otherwise:
-

- +

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

+ +

Answer: That is usually the result of one of three + things:

+ - + +

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

+ Answer: To further + diagnose this problem:
+ - - - -
- - - - - - - - - - - - - - - - -
ZONE
- 		INTERFACE
- 		BROADCAST
- 		OPTIONS
-
loc
- 		eth1
- 		detect
- 		routeback
-
-
- - - - - -
- - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNAT
- 		locweb:192.168.1.5
- 		tcpwww -
- 		130.151.100.69:192.168.1.254
-
-
- -
-

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

-
- -
-
     ETH0_IP=`find_interface_address eth0`
-
- -
-

and make your DNAT rule:

-
- -
-
+ +

1c. From the internet, I want + to connect to port 1022 on my firewall and have the firewall forward the + connection to port 22 on local system 192.168.1.3. How do I do that?

+ +
+
- - - - - - - - + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
DNATnet
+ 		loc:192.168.1.3:22tcp1022
+
+
+
-
+
+
+ +

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.

+ + + +

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

+ +

If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for those +releases.
+

+ +

If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please + upgrade to Shorewall 1.4.2 or later.
+

+ +

Otherwise:
+

+ + + + + + + +
+ + + + + + + + + + + + + + + + +
ZONE
+ 		INTERFACE
+ 		BROADCAST
+ 		OPTIONS
+
loc
+ 		eth1
+ 		detect
+ 		routeback
+
+
+ + + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
DNAT
+ 		locweb:192.168.1.5
+ 		tcpwww -
+ 		130.151.100.69:192.168.1.254
+
+
+ +
+

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

- -
-

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) + +
+
     ETH0_IP=`find_interface_address eth0`
+
+ +
+

and make your DNAT rule:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
DNATlocweb: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.

+
+ +

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.

- -

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

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.

- -

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) Set the Z->Z policy to ACCEPT.
- b) Masquerade Z -to itself.
-
- Example:

- + b) 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.255
-
dmzeth2192.168.2.255
+
-
- +
+

In /etc/shorewall/policy:

- -
+ +
- - - + + - - - - - - - - - - - - + + + + + + + + + + + +
SOURCE +
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
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.
+

+ +

4b. I have a port that I can't close no matter how + I change my rules. 

+ I had a rule that allowed telnet from my local network to my firewall; +I removed that rule and restarted Shorewall but my telnet session still works!!!
+
+ Answer:  Rules only govern the establishment of new connections. + Once a connection is established through the firewall it will be usable +until disconnected (tcp) or until it times out (other protocols).  If you +stop telnet and try to establish a new session your firerwall will block +that attempt.
+ +

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

+ +

Answer: If you want your firewall to be totally open + for "ping",

+ +

a) Create /etc/shorewall/common if it doesn't already exist. +
+ b) Be sure that + the first command in the file is ". /etc/shorewall/common.def"
+ c) Add the following + to /etc/shorewall/common

+ +
+

run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
+

+
+ For a complete description of Shorewall + 'ping' management, see this page. + +

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

+ +

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

+ +

By default, older versions of Shorewall ratelimited log messages + through settings + in /etc/shorewall/shorewall.conf -- If you want +to log all messages, set:

+ +
+
     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 and in + the common.def file in Shorewall 1.4.0 and later.
+ +

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

+ What is labeled as the MAC address in a Shorewall log message + is actually the Ethernet frame header. IT contains:
+ + + Example:
+
+ MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
+ + + +

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

+ +

The 'stop' command is intended to place your firewall into + a safe state whereby only those hosts listed in + /etc/shorewall/routestopped' are activated. If +you want to totally open up your firewall, you must use the +'shorewall clear' command.

+ +

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

+ +

Answer: The output you will see looks something like + this:

+ +
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
+ +

This is usually cured by the following sequence of commands: +

+ +
+
     service ipchains stop
     chkconfig --delete ipchains
     rmmod ipchains
+
+ +
+

Also, be sure to check the errata + for problems concerning the version of iptables + (v1.2.3) shipped with RH7.2.
+

+ +

8a. When I try to start Shorewall on RedHat + I get a message referring me to FAQ #8

+ Answer: This is usually cured by the sequence of commands + shown above in FAQ #8 +
+ +

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

+ +

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

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

Why can't Shorewall detect my interfaces properly?

+
+ +
+

Answer: The above output is perfectly normal. The +Net zone is defined as all hosts that are connected through eth0 and the +local zone is defined as all hosts connected through eth1

+
+ +

10. What Distributions does it work + with?

+ +

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

+ +

11. What Features does it have?

+ +

Answer: See the Shorewall + Feature List.

+ +

12. Is there a GUI?

+ +

Answer: Yes. Shorewall support is included in Webmin + 1.060 and later versions. See http://www.webmin.com +

+ +

13. Why do you call it "Shorewall"?

+ +

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

+ +

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

+ +

Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 + address of the modem in/out but still block all other + rfc1918 addresses?

+ +

Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:

+ +
+
     run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
+
+ +
+

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

+
+ +
+
+ + + + + + + + + + + + +
SUBNET + TARGET
192.168.100.1RETURN
+
+
+ +
+

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

- -

4b. I have a port that I can't close no matter how - I change my rules. 

- I had a rule that allowed telnet from my local network to my firewall; -I removed that rule and restarted Shorewall but my telnet session still -works!!!
-
- Answer:  Rules only govern the establishment of new connections. -Once a connection is established through the firewall it will be usable until - disconnected (tcp) or until it times out (other protocols).  If you stop -telnet and try to establish a new session your firerwall will block that -attempt.
- -

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

- -

Answer: If you want your firewall to be totally open - for "ping",

- -

a) Create /etc/shorewall/common if it doesn't already exist. -
- b) Be sure that -the first command in the file is ". /etc/shorewall/common.def"
- c) Add the following - to /etc/shorewall/common

- -
-

run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT
-

-
- For a complete description of Shorewall - 'ping' management, see this page. - -

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

- -

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

- -

By default, older versions of Shorewall ratelimited log messages - through settings - in /etc/shorewall/shorewall.conf -- If you want -to log all messages, set:

- -
-
     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 and in - the common.def file in Shorewall 1.4.0 and later.
- -

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

- What is labeled as the MAC address in a Shorewall log message - is actually the Ethernet frame header. IT contains:
- -
    -
  • the destination MAC address (6 bytes)
    • -
  • the source MAC address (6 bytes)
    • -
  • the ethernet frame type (2 bytes)
    • - -
- Example:
-
- MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
- -
    -
  • Destination MAC address = 00:04:4c:dc:e2:28
    • -
  • Source MAC address = 00:b0:8e:cf:3c:4c
    • -
  • Ethernet Frame Type = 08:00 (IP Version 4)
    • - -
- -

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

- -

The 'stop' command is intended to place your firewall into - a safe state whereby only those hosts listed -in /etc/shorewall/routestopped' are activated. -If you want to totally open up your firewall, you must use -the 'shorewall clear' command.

- -

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

- -

Answer: The output you will see looks something like - this:

- -
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
- -

This is usually cured by the following sequence of commands: -

- -
-
     service ipchains stop
     chkconfig --delete ipchains
     rmmod ipchains
-
- -
-

Also, be sure to check the errata - for problems concerning the version of iptables - (v1.2.3) shipped with RH7.2.
-

- -

8a. When I try to start Shorewall on RedHat - I get a message referring me to FAQ #8

- Answer: This is usually cured by the sequence of commands - shown above in FAQ #8 -
- -

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

- -

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

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

Why can't Shorewall detect my interfaces properly?

-
- -
-

Answer: The above output is perfectly normal. The Net - zone is defined as all hosts that are connected through eth0 and the local - zone is defined as all hosts connected through eth1

-
- -

10. What Distributions does it work - with?

- -

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

- -

11. What Features does it have?

- -

Answer: See the Shorewall - Feature List.

- -

12. Is there a GUI?

- -

Answer: Yes. Shorewall support is included in Webmin - 1.060 and later versions. See http://www.webmin.com -

- -

13. Why do you call it "Shorewall"?

- -

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

- -

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

- -

Is there any way it can add a rule before the rfc1918 blocking - that will let all traffic to and from the 192.168.100.1 - address of the modem in/out but still block all other - rfc1918 addresses?

- -

Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:

- -
-
     run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
-
- -
-

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

-
- -
-
- - - - - - - - - - - - -
SUBNET - TARGET
192.168.100.1RETURN
-
-
- -
-

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

+

14a. Even though it assigns public +IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable +RFC 1918 filtering on my external interface, my DHCP client cannot renew +its lease.

+
+ +
+

The solution is the same as FAQ 14 above. Simply substitute the IP address of your ISPs DHCP server.

-
- -

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

+ +

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

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 +

  2. + +

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

    -
    3. -
  3. - -

    The entry for the local network in the /etc/shorewall/masq +

    4. +
  4. + +

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

    -
    5. -
  5. - -

    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.

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

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

Answer: If you are running Shorewall version 1.4.4 +or 1.4.4a then check the errata. Otherwise, see +the 'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent +to the console is specified in /etc/sysconfig/init in the LOGLEVEL variable.
-

- -

17. How do I find out why this traffic is getting +

+ +

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:
- + 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 +
  2. man1918 - + The destination address is listed in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
    3. -
  3. rfc1918 -- The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 + - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
    4. -
  4. all2<zone>, - <zone>2all or all2all - - You have a policy -that specifies a log level and this packet is being -logged under that policy. If you intend to ACCEPT this -traffic then you need a rule to -that effect.
    -
    5. -
  5. <zone1>2<zone2> +
  6. all2<zone>, + <zone>2all or all2all + - You have a policy that + specifies a log level and this packet is being logged +under that policy. If you intend to ACCEPT this traffic +then you need a rule to that effect.
    +
    7. +
  7. <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.
    8. -
  8. <interface>_mac - - The packet is being logged under the maclist + href="Documentation.htm#Policy"> 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.
    9. +
  9. <interface>_mac + - The packet is being logged under the maclist interface option.
    -
    10. -
  10. logpkt -- The packet is being logged under the logunclean +
    11. +
  11. logpkt +- The packet is being logged under the logunclean interface option.
    12. -
  12. badpkt - - The packet is being logged under the dropunclean - interface option +
  13. badpkt - + The packet is being logged under the dropunclean + interface option as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    14. -
  14. blacklst - - The packet is being logged because the source IP - is blacklisted in the /etc/shorewall/blacklist +
  15. blacklst + - The packet is being logged because the source IP + is blacklisted in the /etc/shorewall/blacklist file.
    16. -
  16. 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 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.
    19. +
  19. 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.
    20. +
  20. logflags - The packet + is being logged because it failed the checks implemented + by the tcpflags interface option.
    -
    21. - + +
- -

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

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

- Answer: Yes. See -Shorewall and Aliased Interfaces. - -

19. I have added entries to /etc/shorewall/tcrules + Answer: Yes. See +Shorewall and Aliased Interfaces. + +

19. I have added entries to /etc/shorewall/tcrules but they don't seem to do anything. Why?

- You probably haven't set TC_ENABLED=Yes - in /etc/shorewall/shorewall.conf so the contents of + You probably haven't set TC_ENABLED=Yes + in /etc/shorewall/shorewall.conf so the contents of the tcrules file are simply being ignored.
- -

20. I have just set up a server. Do I have - to change Shorewall to allow access to my server from + +

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... + + 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 +
+ 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 +
+ 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 list of the host/subnet addresses as a comma-separated + 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
- +
- -

25. How to I tell which version of Shorewall + +

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

- At the shell prompt, type:
-
- /sbin/shorewall version
-
- Last updated 4/14/2003 - Tom Eastep + + At the shell prompt, type:
+
+ /sbin/shorewall version
+
+ Last updated 5/29/2003 - Tom Eastep

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

-
-
-
-
+

diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index c5b0ac99b..ef0fb56b0 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -14,1062 +14,1028 @@ - + - + - + - - - + + - + + - - + +
+
- +

Shorewall News Archive

-
- + +

5/29/2003 - Shorewall-1.4.4b

+

Groan -- This version corrects a problem whereby the --log-level was not +being set when logging via syslog. The most commonly reported symptom was +that Shorewall messages were being written to the console even though console +logging was correctly configured per FAQ 16.
+

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out - that the code in 1.4.4 restricts the length of short zone names to 4 characters. - I've produced version 1.4.4a that restores the previous 5-character limit - by conditionally omitting the log rule number when the LOGFORMAT doesn't + The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out + that the code in 1.4.4 restricts the length of short zone names to 4 characters. + I've produced version 1.4.4a that restores the previous 5-character limit + by conditionally omitting the log rule number when the LOGFORMAT doesn't contain '%d'.
- +

5/23/2003 - Shorewall-1.4.4

- I apologize for the rapid-fire releases but since there is a potential -configuration change required to go from 1.4.3a to 1.4.4, I decided to make -it a full release rather than just a bug-fix release.
-
-     Problems corrected:
- -
None.
-
-     New Features:
- -
    -
  1. A REDIRECT- rule target has been added. This target behaves for -REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter nat -table REDIRECT rule is added but not the companion filter table ACCEPT rule.
    -
    -
    2. -
  2. The LOGMARKER variable has been renamed LOGFORMAT and has been changed - to a 'printf' formatting template which accepts three arguments (the chain - name, logging rule number and the disposition). To use LOGFORMAT with fireparse - (http://www.fireparse.com), set it - as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in the - 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be -sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    -
    -
    3. -
  3. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the -logging now takes place in the nat table rather than in the filter table. -This way, only those connections that actually undergo DNAT or redirection -will be logged.
    -
    4. - -
- -

5/20/2003 - Shorewall-1.4.3a
-

- This version primarily corrects the documentation included in the .tgz - and in the .rpm. In addition:
- -
    -
  1. (This change is in 1.4.3 but is not documented) If you are running - iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies - as follows:
    -    a) tcp - RST
    -    b) udp - ICMP port unreachable
    -    c) icmp - ICMP host unreachable
    -    d) Otherwise - ICMP host prohibited
    - If you are running earlier software, Shorewall will follow it's traditional - convention:
    -    a) tcp - RST
    -    b) Otherwise - ICMP port unreachable
    2. -
  2. UDP port 135 is now silently dropped in the common.def chain. -Remember that this chain is traversed just before a DROP or REJECT policy -is enforced.
    -
    3. - -
- -

5/18/2003 - Shorewall 1.4.3
-

-     Problems Corrected:
- -
    -
  1. There were several cases where Shorewall would fail to remove -a temporary directory from /tmp. These cases have been corrected.
    2. -
  2. The rules for allowing all traffic via the loopback interface -have been moved to before the rule that drops status=INVALID packets. This -insures that all loopback traffic is allowed even if Netfilter connection -tracking is confused.
    3. - -
-     New Features:
- -
    -
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the /etc/shorewall/tunnels - file.
    2. -
  2. You may now change the leading portion of the --log-prefix - used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, - "Shorewall:" is used.
    -
    3. - -
- -

5/10/2003 - Shorewall Mirror in Asia
-

- -

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
-

- -

5/8/2003 - Shorewall Mirror in Chile

- Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago - Chile. -

4/21/2003 - Samples updated for Shorewall version 1.4.2

- -

Thanks to Francesca Smith, the sample configurations are now upgraded to -Shorewall version 1.4.2.

- -

4/9/2003 - Shorewall 1.4.2
-

- -

    Problems Corrected:

- -
-
    -
  1. TCP connection requests rejected out of the common - chain are now properly rejected with TCP RST; previously, some of these - requests were rejected with an ICMP port-unreachable response.
    2. -
  2. 'traceroute -I' from behind the firewall previously timed - out on the first hop (e.g., to the firewall). This has been worked around.
    3. - -
-
- -

    New Features:

- -
    -
  1. Where an entry in the/etc/shorewall/hosts file specifies -a particular host or network, Shorewall now creates an intermediate chain - for handling input from the related zone. This can substantially reduce - the number of rules traversed by connections requests from such zones.
    -
    -
    2. -
  2. Any file may include an INCLUDE directive. An INCLUDE directive - consists of the word INCLUDE followed by a file name and causes the -contents of the named file to be logically included into the file containing -the INCLUDE. File names given in an INCLUDE directive are assumed to -reside in /etc/shorewall or in an alternate configuration directory -if one has been specified for the command.
    -  
    -    Examples:
    -    shorewall/params.mgmt:
    -    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    -    TIME_SERVERS=4.4.4.4
    -    BACKUP_SERVERS=5.5.5.5
    -    ----- end params.mgmt -----
    -  
    -  
    -    shorewall/params:
    -    # Shorewall 1.3 /etc/shorewall/params
    -    [..]
    -    #######################################
    -  
    -    INCLUDE params.mgmt   
    -  
    -    # params unique to this host here
    -    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -    ----- end params -----
    -  
    -  
    -    shorewall/rules.mgmt:
    -    ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
    -    ACCEPT $FW          net:$TIME_SERVERS    udp    123
    -    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
    -    ----- end rules.mgmt -----
    -  
    -    shorewall/rules:
    -    # Shorewall version 1.3 - Rules File
    -    [..]
    -    #######################################
    -  
    -    INCLUDE rules.mgmt    
    -  
    -    # rules unique to this host here
    -    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT -REMOVE
    -    ----- end rules -----
    -  
    - INCLUDE's may be nested to a level of 3 -- further nested INCLUDE - directives are ignored with a warning message.
    -
    -
    3. -
  3. Routing traffic from an interface back out that interface - continues to be a problem. While I firmly believe that this should -never happen, people continue to want to do it. To limit the damage -that such nonsense produces, I have added a new 'routeback' option in -/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in /etc/shorewall/interfaces, -the 'ZONE' column may not contain '-'; in other words, 'routeback' can't -be used as an option for a multi-zone interface. The 'routeback' option -CAN be specified however on individual group entries in /etc/shorewall/hosts.
    -  
    - The 'routeback' option is similar to the old 'multi' option -with two exceptions:
    -  
    -    a) The option pertains to a particular zone,interface,address - tuple.
    -  
    -    b) The option only created infrastructure to pass traffic -from (zone,interface,address) tuples back to themselves (the 'multi' -option affected all (zone,interface,address) tuples associated with the -given 'interface').
    -  
    - See the 'Upgrade Issues' for - information about how this new option may affect your configuration.
    -
    4. - -
- -

3/24/2003 - Shorewall 1.4.1

- - - - - - - - - - - - - - - - - - - - -

This release follows up on 1.4.0. It corrects a problem introduced in -1.4.0 and removes additional warts.
-
- Problems Corrected:
-

- -
    -
  1. When Shorewall 1.4.0 is run under the ash shell (such as - on Bering/LEAF), it can attempt to add ECN disabling rules even if -the /etc/shorewall/ecn file is empty. That problem has been corrected -so that ECN disabling rules are only added if there are entries in /etc/shorewall/ecn.
    2. - -
- New Features:
- -
Note: In the list that follows, the term group refers to -a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a -host address) accessed through a particular interface. Examples:
- -
eth0:0.0.0.0/0
- eth2:192.168.1.0/24
- eth3:192.0.2.123
-
- You can use the "shorewall check" command to see the groups -associated with each of your zones.
-
- -
    -
  1. Beginning with Shorewall 1.4.1, if a zone Z comprises more - than one group then if there is no explicit Z to Z policy and -there are no rules governing traffic from Z to Z then Shorewall will permit - all traffic between the groups in the zone.
    2. -
  2. Beginning with Shorewall 1.4.1, Shorewall will never create - rules to handle traffic from a group to itself.
    3. -
  3. A NONE policy is introduced in 1.4.1. When a policy of -NONE is specified from Z1 to Z2:
    4. - -
- -
    -
  • There may be no rules created that govern connections from - Z1 to Z2.
    • -
  • Shorewall will not create any infrastructure to handle -traffic from Z1 to Z2.
    • - -
- See the upgrade issues for -a discussion of how these changes may affect your configuration. + I apologize for the rapid-fire releases but since there is a potential + configuration change required to go from 1.4.3a to 1.4.4, I decided to +make it a full release rather than just a bug-fix release.
+
+     Problems corrected:
+
None.
+
+     New Features:
+ +
    +
  1. A REDIRECT- rule target has been added. This target behaves for +REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter nat +table REDIRECT rule is added but not the companion filter table ACCEPT rule.
    +
    +
    2. +
  2. The LOGMARKER variable has been renamed LOGFORMAT and has been +changed to a 'printf' formatting template which accepts three arguments +(the chain name, logging rule number and the disposition). To use LOGFORMAT +with fireparse (http://www.fireparse.com), +set it as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log messages in +the 'show log', 'status' and 'hits' commands. This part should not be omitted + (the LOGFORMAT should not begin with "%") and the leading part should be + sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    +
    +
    3. +
  3. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the +logging now takes place in the nat table rather than in the filter table. +This way, only those connections that actually undergo DNAT or redirection +will be logged.
    +
    4. + +
+ +

5/20/2003 - Shorewall-1.4.3a
+

+ This version primarily corrects the documentation included in the .tgz + and in the .rpm. In addition:
+ +
    +
  1. (This change is in 1.4.3 but is not documented) If you are running + iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies + as follows:
    +    a) tcp - RST
    +    b) udp - ICMP port unreachable
    +    c) icmp - ICMP host unreachable
    +    d) Otherwise - ICMP host prohibited
    + If you are running earlier software, Shorewall will follow it's traditional + convention:
    +    a) tcp - RST
    +    b) Otherwise - ICMP port unreachable
    2. +
  2. UDP port 135 is now silently dropped in the common.def chain. +Remember that this chain is traversed just before a DROP or REJECT policy +is enforced.
    +
    3. + +
+ +

5/18/2003 - Shorewall 1.4.3
+

+     Problems Corrected:
+ +
    +
  1. There were several cases where Shorewall would fail to remove + a temporary directory from /tmp. These cases have been corrected.
    2. +
  2. The rules for allowing all traffic via the loopback interface + have been moved to before the rule that drops status=INVALID packets. +This insures that all loopback traffic is allowed even if Netfilter connection + tracking is confused.
    3. + +
+     New Features:
+ +
    +
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the /etc/shorewall/tunnels + file.
    2. +
  2. You may now change the leading portion of the --log-prefix + used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, + "Shorewall:" is used.
    +
    3. + +
+ +

5/10/2003 - Shorewall Mirror in Asia
+

+ +

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
+

+ +

5/8/2003 - Shorewall Mirror in Chile

+ Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago + Chile. +

4/21/2003 - Samples updated for Shorewall version 1.4.2

+ +

Thanks to Francesca Smith, the sample configurations are now upgraded +to Shorewall version 1.4.2.

+ +

4/9/2003 - Shorewall 1.4.2
+

+ +

    Problems Corrected:

+ +
+
    +
  1. TCP connection requests rejected out of the common + chain are now properly rejected with TCP RST; previously, some of these + requests were rejected with an ICMP port-unreachable response.
    2. +
  2. 'traceroute -I' from behind the firewall previously timed + out on the first hop (e.g., to the firewall). This has been worked around.
    3. + +
+
+ +

    New Features:

+ +
    +
  1. Where an entry in the/etc/shorewall/hosts file specifies + a particular host or network, Shorewall now creates an intermediate +chain for handling input from the related zone. This can substantially +reduce the number of rules traversed by connections requests from such +zones.
    +
    +
    2. +
  2. Any file may include an INCLUDE directive. An INCLUDE directive + consists of the word INCLUDE followed by a file name and causes the contents + of the named file to be logically included into the file containing the + INCLUDE. File names given in an INCLUDE directive are assumed to reside + in /etc/shorewall or in an alternate configuration directory if one +has been specified for the command.
    +  
    +    Examples:
    +    shorewall/params.mgmt:
    +    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    +    TIME_SERVERS=4.4.4.4
    +    BACKUP_SERVERS=5.5.5.5
    +    ----- end params.mgmt -----
    +  
    +  
    +    shorewall/params:
    +    # Shorewall 1.3 /etc/shorewall/params
    +    [..]
    +    #######################################
    +  
    +    INCLUDE params.mgmt   
    +  
    +    # params unique to this host here
    +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +    ----- end params -----
    +  
    +  
    +    shorewall/rules.mgmt:
    +    ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
    +    ACCEPT $FW          net:$TIME_SERVERS    udp    123
    +    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
    +    ----- end rules.mgmt -----
    +  
    +    shorewall/rules:
    +    # Shorewall version 1.3 - Rules File
    +    [..]
    +    #######################################
    +  
    +    INCLUDE rules.mgmt    
    +  
    +    # rules unique to this host here
    +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT +REMOVE
    +    ----- end rules -----
    +  
    + INCLUDE's may be nested to a level of 3 -- further nested INCLUDE + directives are ignored with a warning message.
    +
    +
    3. +
  3. Routing traffic from an interface back out that interface + continues to be a problem. While I firmly believe that this should never + happen, people continue to want to do it. To limit the damage that such + nonsense produces, I have added a new 'routeback' option in /etc/shorewall/interfaces + and /etc/shorewall/hosts. When used in /etc/shorewall/interfaces, the + 'ZONE' column may not contain '-'; in other words, 'routeback' can't + be used as an option for a multi-zone interface. The 'routeback' option + CAN be specified however on individual group entries in /etc/shorewall/hosts.
    +  
    + The 'routeback' option is similar to the old 'multi' option +with two exceptions:
    +  
    +    a) The option pertains to a particular zone,interface,address + tuple.
    +  
    +    b) The option only created infrastructure to pass traffic + from (zone,interface,address) tuples back to themselves (the 'multi' + option affected all (zone,interface,address) tuples associated with +the given 'interface').
    +  
    + See the 'Upgrade Issues' +for information about how this new option may affect your configuration.
    +
    4. + +
+ +

3/24/2003 - Shorewall 1.4.1

+ + + + + + + + + + + + + + + + + + + + +

This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0 +and removes additional warts.
+
+ Problems Corrected:
+

+ +
    +
  1. When Shorewall 1.4.0 is run under the ash shell (such +as on Bering/LEAF), it can attempt to add ECN disabling rules even +if the /etc/shorewall/ecn file is empty. That problem has been corrected +so that ECN disabling rules are only added if there are entries in /etc/shorewall/ecn.
    2. + +
+ New Features:
+ +
Note: In the list that follows, the term group refers +to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be +a host address) accessed through a particular interface. Examples:
+ +
eth0:0.0.0.0/0
+ eth2:192.168.1.0/24
+ eth3:192.0.2.123
+
+ You can use the "shorewall check" command to see the groups +associated with each of your zones.
+
+ +
    +
  1. Beginning with Shorewall 1.4.1, if a zone Z comprises +more than one group then if there is no explicit Z to Z policy +and there are no rules governing traffic from Z to Z then Shorewall will +permit all traffic between the groups in the zone.
    2. +
  2. Beginning with Shorewall 1.4.1, Shorewall will never create + rules to handle traffic from a group to itself.
    3. +
  3. A NONE policy is introduced in 1.4.1. When a policy of +NONE is specified from Z1 to Z2:
    4. + +
+ +
    +
  • There may be no rules created that govern connections +from Z1 to Z2.
    • +
  • Shorewall will not create any infrastructure to handle +traffic from Z1 to Z2.
    • + +
+ See the upgrade issues for + a discussion of how these changes may affect your configuration. +

3/17/2003 - Shorewall 1.4.0

- Shorewall 1.4 - represents the next step in the evolution of Shorewall. The main -thrust of the initial release is simply to remove the cruft that has -accumulated in Shorewall over time.
-
- IMPORTANT: Shorewall 1.4.0 requires the iproute - package ('ip' utility).
-
- Function from 1.3 that has been omitted from this version - include:
- + Shorewall +1.4 represents the next step in the evolution of Shorewall. The +main thrust of the initial release is simply to remove the cruft that +has accumulated in Shorewall over time.
+
+ IMPORTANT: Shorewall 1.4.0 requires the iproute + package ('ip' utility).
+
+ Function from 1.3 that has been omitted from this +version include:
+
    -
  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. -
  6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    7. -
  7. 802.11b devices with names of the form wlan<n> -now support the 'maclist' option.
    -
    -
    8. -
  8. Explicit Congestion Notification (ECN - RFC 3168) may - now be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
    -
    -    a) You must be running kernel 2.4.20
    -    b) You must have applied the patch in
    -    http://www.shorewall/net/pub/shorewall/ecn/patch.
    -    c) You must have iptables 1.2.7a installed.
    -
    -
    9. -
  9. The /etc/shorewall/params file is now processed first - so that variables may be used in the /etc/shorewall/shorewall.conf -file.
    -
    -
    10. -
  10. Shorewall now gives a more helpful diagnostic - when the 'ipchains' compatibility kernel module is loaded and a 'shorewall - start' command is issued.
    -
    -
    11. -
  11. The SHARED_DIR variable has been removed from shorewall.conf. - This variable was for use by package maintainers and was not documented - for general use.
    -
    -
    12. -
  12. Shorewall now ignores 'default' routes when detecting -masq'd networks.
    13. - -
- -

3/10/2003 - Shoreall 1.3.14a

- -

A roleup of the following bug fixes and other updates:

- -
    -
  • There is an updated rfc1918 file that reflects the resent - allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • - -
- -
    -
  • The documentation for the routestopped file claimed that - a comma-separated list could appear in the second column while the - code only supported a single host or network address.
    • -
  • Log messages produced by 'logunclean' and 'dropunclean' - were not rate-limited.
    • -
  • 802.11b devices with names of the form wlan<n> - don't support the 'maclist' interface option.
    • -
  • Log messages generated by RFC 1918 filtering are not rate - limited.
    • -
  • The firewall fails to start in the case where you have -"eth0 eth1" in /etc/shorewall/masq and the default route is through eth1
    • - -
- -

2/8/2003 - Shoreawall 1.3.14

- -

New features include

- -
    -
  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. 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.
    -
    -
    7. -
  7. 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
    -
    8. - +
  8. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
    +
    +
    9. +
  9. 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.
    +
    +
    10. +
  10. 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.
    +
    +
    11. +
  11. The Shorewall 1.2 syntax for DNAT and REDIRECT + rules is no longer accepted.
    +
    +
    12. +
  12. The ALLOWRELATED variable in shorewall.conf is + no longer supported. Shorewall 1.4 behavior is the same as 1.3 +with ALLOWRELATED=Yes.
    +
    +
    13. +
  13. The icmp.def file has been removed.
    +
    14. +
- -


- 2/5/2003 - Shorewall Support included in Webmin - 1.060

- -

Webmin version 1.060 now has Shorewall support included as standard. See - http://www.webmin.com.
-
- 2/4/2003 - Shorewall 1.3.14-RC1

- -

Includes the Beta 2 content plus support for OpenVPN tunnels.

- -

1/28/2003 - Shorewall 1.3.14-Beta2

- -

Includes the Beta 1 content plus restores VLAN device names of the form - $dev.$vid (e.g., eth0.1)

- -

1/25/2003 - Shorewall 1.3.14-Beta1
-

- -

The Beta includes the following changes:
-

- + Changes for 1.4 include:
+
    -
  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.
    -   
    +
  4. The /etc/shorewall/shorewall.conf file has been + completely reorganized into logical sections.
    +
    +
    5. +
  5. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    6. +
  6. The firewall script and version file are now +installed in /usr/share/shorewall.
    +
    +
    7. +
  7. Late arriving DNS replies are now silently dropped + in the common chain by default.
    +
    +
    8. +
  8. 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.
    +
    +
    9. +
  9. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    10. +
  10. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
    +
    +
    11. +
  11. Explicit Congestion Notification (ECN - RFC 3168) may + now be turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
    +
    +    a) You must be running kernel 2.4.20
    +    b) You must have applied the patch in
    +    http://www.shorewall/net/pub/shorewall/ecn/patch.
    +    c) You must have iptables 1.2.7a installed.
    +
    +
    12. +
  12. The /etc/shorewall/params file is now processed first + so that variables may be used in the /etc/shorewall/shorewall.conf file.
    +
    +
    13. +
  13. Shorewall now gives a more helpful diagnostic + when the 'ipchains' compatibility kernel module is loaded and a 'shorewall + start' command is issued.
    +
    +
    14. +
  14. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented + for general use.
    +
    +
    15. +
  15. Shorewall now ignores 'default' routes when detecting + masq'd networks.
    16. + +
+ +

3/10/2003 - Shoreall 1.3.14a

+ +

A roleup of the following bug fixes and other updates:

+ +
    +
  • There is an updated rfc1918 file that reflects the resent + allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • + +
+ +
    +
  • The documentation for the routestopped file claimed that + a comma-separated list could appear in the second column while +the code only supported a single host or network address.
    • +
  • Log messages produced by 'logunclean' and 'dropunclean' + were not rate-limited.
    • +
  • 802.11b devices with names of the form wlan<n> + don't support the 'maclist' interface option.
    • +
  • Log messages generated by RFC 1918 filtering are not +rate limited.
    • +
  • The firewall fails to start in the case where you have + "eth0 eth1" in /etc/shorewall/masq and the default route is through +eth1
    • + +
+ +

2/8/2003 - Shoreawall 1.3.14

+ +

New features include

+ +
    +
  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 +  
    + 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:
    -   
    +  
    + Example 2 -- Suppose that your current config + is as follows:
    +   
    - + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, the second entry in /etc/shorewall/masq +  
    +    In this case, the second entry in /etc/shorewall/masq is no longer required.
    -  
    - Example 3 -- What if your current configuration - is like this?
    -  
    +  
    + Example 3 -- What if your current configuration + is like this?
    +  
    - + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, you would want to change the - entry in  /etc/shorewall/masq to:
    +  
    +    In this case, you would want to change +the entry in  /etc/shorewall/masq to:
    - + 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    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.
+
+ 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. + +

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

-     ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-     http://slovakia.shorewall.net/pub/shorewall/pdf/ - +     http://slovakia.shorewall.net/pub/shorewall/pdf/ +

1/17/2003 - shorewall.net has MOVED 

- +

Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and ftp.shorewall.net -are now hosted on a system in Bellevue, Washington. A big thanks to Alex -for making this happen.
-

- + href="http://www.rettc.com">Rett Consulting, www.shorewall.net and +ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A +big thanks to Alex for making this happen.
+

+

1/13/2003 - Shorewall 1.3.13
-

- +

+

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

- +

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

1/6/2003 - BURNOUT -

- -

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

- + +

1/6/2003 - BURNOUT +

+ +

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

+

-Tom Eastep
-

- +

+

12/30/2002 - Shorewall Documentation in PDF Format

- -

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. + +

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

- +

    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-     http://slovakia.shorewall.net/pub/shorewall/pdf/
-

+

- +

12/27/2002 - Shorewall 1.3.12 Released

- -

Features include:
-

- -
    -
  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 to a separate log file.
    6. -
  6. 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.
    7. -
  7. 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.
    8. -
  8. 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.
    -
    9. - -
- -

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

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 to a separate log file.
    6. +
  6. 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.
    7. +
  7. 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.
    8. +
  8. 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.
    +
    9. + + +
+ + +

12/20/2002 - Shorewall 1.3.12 Beta 3
+

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

12/20/2002 - Shorewall 1.3.12 Beta 2

- -

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

- Features include:
+ +

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

+ Features include:
- +
    -
  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 +
  5. "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) +
  10. 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.
    11. -
  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. 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.
    14. +
  14. 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.
    15. - +
- 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 Multi - Network Firewall (MNF) product. Here is the press +

+ Shorewall is at the center +of MandrakeSoft's recently-announced Multi + Network Firewall (MNF) product. Here is the press release.
- +

12/7/2002 - Shorewall Support for Mandrake 9.0

- -

Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. - I have installed 9.0 on one of my systems and I am -now in a position to support Shorewall users who run Mandrake + +

Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. + I have installed 9.0 on one of my systems and I am +now in a position to support Shorewall users who run Mandrake 9.0.

- +

12/6/2002 - Debian 1.3.11a Packages Available
-

+

- +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- +

12/3/2002 - Shorewall 1.3.11a

- -

This is a bug-fix roll up which includes Roger Aich's fix for DNAT with - excluded subnets (e.g., "DNAT foo!bar ..."). Current - 1.3.11 users who don't need rules of this type need not + +

This is a bug-fix roll up which includes Roger Aich's fix for DNAT with + excluded subnets (e.g., "DNAT foo!bar ..."). Current + 1.3.11 users who don't need rules of this type need not upgrade to 1.3.11.

- +

11/24/2002 - Shorewall 1.3.11

- +

In this version:

- + - +

11/14/2002 - Shorewall Documentation in PDF Format

- -

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. + +

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

- +

    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-     http://slovakia.shorewall.net/pub/shorewall/pdf/
-

+

- -

11/09/2002 - Shorewall is Back at SourceForge -

+ +

11/09/2002 - Shorewall is Back at SourceForge +

- +

The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
-

+

- +

11/09/2002 - Shorewall 1.3.10

- +

In this version:

- - - - -

10/24/2002 - Shorewall is now in Gentoo Linux
-

- Alexandru Hartmann -reports that his Shorewall package is now a part of - the Gentoo Linux distribution. - Thanks Alex!
- - -

10/23/2002 - Shorewall 1.3.10 Beta 1

- In this version:
- - + - You may download the - Beta from:
- + +

10/24/2002 - Shorewall is now in Gentoo Linux
+

+ Alexandru Hartmann +reports that his Shorewall package is now a part of + the Gentoo Linux distribution. + Thanks Alex!
+ + +

10/23/2002 - Shorewall 1.3.10 Beta 1

+ In this version:
+ + + You may download +the Beta from:
+ + + - +

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

+

- +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

10/9/2002 - Shorewall 1.3.9b

- This release rolls -up fixes to the installer and to the firewall script.
- -

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

10/9/2002 - Shorewall 1.3.9b

+ This release rolls + up fixes to the installer and to the firewall script.
- -

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

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

9/28/2002 - Shorewall 1.3.9

- +

In this version:
-

+

- + - -

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

- 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:
+ 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. The @@ -1190,2054 +1229,2022 @@ Site Search index was incomplete
  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 + Hopefully these problems are now corrected.
- -

9/18/2002 -  Debian 1.3.8 Packages Available
-

- +

9/18/2002 -  Debian 1.3.8 Packages Available
+

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

- +

9/16/2002 - Shorewall 1.3.8

- +

In this version:
-

+

- + + +

7/16/2002 - New Mirror in Argentina

- -

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in + +

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

- +

7/16/2002 - Shorewall 1.3.4 Released

- +

In this version:

- + +
  • A + DETECT_DNAT_ADDRS option has been added + to /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only +apply when the destination address is the + external interface's primary IP address.
    • +
  • The + QuickStart Guide + has been broken into three guides and has been + almost entirely rewritten.
    • +
  • The + Samples have been updated to reflect the new capabilities + in this release.
    • + + +

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

    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 file.
    • +
  • The + TARGET column in the rfc1918 file is now checked + for correctness.
    • +
  • The + chain structure in the nat table has been changed + to reduce the number of rules that a packet must +traverse and to correct problems with NAT_BEFORE_RULES=No
    • +
  • The + "hits" command has been enhanced.
    • + + +

    6/25/2002 - Samples Updated for 1.3.2

    - -

    The comments in the sample configuration files have been updated to reflect + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

    Thanks to Mike Martinez, the Shorewall Documentation is now available -for download in Adobe PDF format.

    + +

    Thanks to Mike Martinez, the Shorewall Documentation is now available for + download in Adobe + PDF format.

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + +
  • A + logwatch command + has been added to /sbin/shorewall.
    • +
  • A + dynamic blacklist facility + has been added.
    • +
  • Support + for the Netfilter multiport + match function has been added.
    • +
  • The + files firewall, functions and version + have been moved from /etc/shorewall to /var/lib/shorewall.
    • + + +

    6/6/2002 - Why CVS Web access is Password Protected

    - -

    Last weekend, I installed the CVS Web package to provide brower-based -access to the Shorewall CVS repository. Since then, I have had several -instances where my server was almost unusable due to the high load generated -by website copying tools like HTTrack and WebStripper. These mindless tools:

    + +

    Last weekend, I installed the CVS Web package to provide brower-based access + to the Shorewall CVS repository. Since then, I have had several instances +where my server was almost unusable due to the high load generated by website +copying tools like HTTrack and WebStripper. These mindless tools:

    - + - -

    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.

    + +

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

    - -

    Until I have the time to understand the cause of the OOM (or until I buy - more RAM if that is what is required), -CVS Web access will remain Password Protected. + +

    Until I have the time to understand the cause of the OOM (or until I buy + more RAM if that is what is required), +CVS Web access will remain Password Protected.

    - +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    6/2/2002 - Samples Corrected

    - -

    The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These + +

    The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These problems have been corrected in the 1.3.1 samples.

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

    In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 - includes:

    + +

    In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 + includes:

    - + +
  • A + 'filterping' interface option that allows ICMP echo-request + (ping) requests addressed to the firewall to + be handled by entries in /etc/shorewall/rules and +/etc/shorewall/policy.
    • + + +

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

    In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) - incorporates the following:

    + +

    In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) + incorporates the following:

    - + - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

    In addition to the changes in Beta 1, this release which carries the -designation 1.2.91 adds:

    + +

    In addition to the changes in Beta 1, this release which carries the + designation 1.2.91 adds:

    - + - +

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

    Beta 1 carries the version designation 1.2.90 and implements the following + +

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

    - + +
  • Simplified + rule syntax which makes the intent of each rule + clearer and hopefully makes Shorewall easier to learn.
    • +
  • 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.
    • + + +

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + +
  • The + order in which port forwarding DNAT and Static DNAT + can now be reversed + so that port forwarding rules can override the contents + of /etc/shorewall/nat. +
    • + + +

    4/30/2002 - Shorewall Debian News

    - -

    Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the -Debian - Testing Branch and the Debian - Unstable Branch.

    + +

    Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian +Testing Branch and the Debian +Unstable Branch.

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + +
  • Shorewall + 1.2.10 is in the Debian + Testing Branch
    • +
  • Shorewall + 1.2.11 is in the Debian + Unstable Branch
    • + + +

    Thanks, Lorenzo!

    - +

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

    - -

    Thanks to Stefan Mohr, there + +

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

    + href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm"> + SuSE RPM available.

    - +

    4/13/2002 - Shorewall 1.2.11 Available

    - +

    In this version:

    - + - +

    4/13/2002 - Hamburg Mirror now has FTP

    - +

    Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  + href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.  Thanks Stefan!

    - +

    4/12/2002 - New Mirror in Hamburg

    - -

    Thanks to Stefan Mohr, there - is now a mirror of the Shorewall website - at http://germany.shorewall.net. + +

    Thanks to Stefan Mohr, there + is now a mirror of the Shorewall website + at http://germany.shorewall.net.

    - +

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

    - -

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

    + +

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

    - +

    4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available

    - -

    Version 1.0 of the QuickStart - Guide is now available. This Guide -and its accompanying sample configurations are - expected to provide a replacement for the recently - withdrawn parameterized samples.

    + +

    Version 1.0 of the QuickStart + Guide is now available. This Guide +and its accompanying sample configurations are + expected to provide a replacement for the recently + withdrawn parameterized samples.

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

    Although the parameterized - samples have allowed people to get -a firewall up and running quickly, they have -unfortunately set the wrong level of expectation among -those who have used them. I am therefore withdrawing support - for the samples and I am recommending that they not be + href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized + samples have allowed people to get +a firewall up and running quickly, they have +unfortunately set the wrong level of expectation among +those who have used them. I am therefore withdrawing support + for the samples and I am recommending that they not be used in new Shorewall installations.

    - +

    4/2/2002 - Updated Log Parser

    - -

    John Lodge has provided an updated + +

    John Lodge has provided an updated version of his CGI-based log parser - with corrected date handling.

    + href="pub/shorewall/parsefw/">CGI-based log parser + with corrected date handling.

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

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

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

    - +

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

    - + +
  • Shorewall + 1.2.9 is now in the Debian + Unstable Distribution.
    • + + +

    3/25/2002 - Log Parser Available

    - +

    John Lodge has provided a CGI-based log parser for Shorewall. Thanks + href="pub/shorewall/parsefw/">CGI-based log parser for Shorewall. Thanks John.

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

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

    + + +

    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.

    + + + +

    2/22/2002 - Shorewall 1.2.7 Released

    + + + +

    In this version:

    + + + + + + + +

    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:

    + + + + + + +

    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.

    + + + +

    In version 1.2.5:

    + + + + + + +

    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.

    + + + +

    1/19/2002 - Shorewall 1.2.3 Released

    + + + +

    This is a minor feature and bugfix release. The single new feature is:

    + + + + + + +

    The following problems were corrected:

    + + + + + +

    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.

    + + + +

    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.

    + + + +

    1/8/2002 - Shorewall 1.2.2 Released

    + + + +

    In version 1.2.2

    + + + + + + +

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

    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 see these instructions. + If you would like to subscribe to the new list, + visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

    - +

    12/31/2001 - Shorewall 1.2.1 Released

    - +

    In version 1.2.1:

    - + +
  • 'shorewall + show tc' now correctly handles tunnels.
    • -

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist -releasing 1.2 on 12/21/2001

    - - - -

    Version 1.2 contains the following new features:

    - - - - - -

    For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version - 1.1.x users will not be forced into a quick upgrade - to 1.2.0 just to have access to bug fixes.

    - - -

    For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading - to 1.2.0:

    - - -
    - - -

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    -
    - - - -

    12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror - in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    - - - -

    11/30/2001 - A new set of the parameterized Sample - Configurations has been released. In this version:

    - - - - - - -

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    - - - -

    In this version:

    - - - - - - - -

    11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall - mirror in the Slovak Republic. The website -is now mirrored at http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

    - - - -

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. - There are three sample configurations:

    - - - - + +

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing +1.2 on 12/21/2001

    +

    Version 1.2 contains the following new features:

    + + + + + + +

    For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version + 1.1.x users will not be forced into a quick upgrade + to 1.2.0 just to have access to bug fixes.

    + + +

    For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading + to 1.2.0:

    + + +
    + + +

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    +
    + + + +

    12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror + in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    + + + +

    11/30/2001 - A new set of the parameterized Sample +Configurations has been released. In this version:

    + + + + + + +

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    + + + +

    In this version:

    + + + + + + + +

    11/19/2001 - Thanks to Juraj + Ontkanin, there is now a Shorewall + mirror in the Slovak Republic. The website + is now mirrored at http://www.nrg.sk/mirror/shorewall + and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

    + + + +

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. + There are three sample configurations:

    + + + + + + +

    Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17"> ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + . See the README file for instructions.

    - -

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend - this to be the last of the 1.1 Shorewall - releases.

    + +

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend + this to be the last of the 1.1 +Shorewall releases.

    - +

    In this version:

    - + - -

    10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:

    + +

    10/22/2001 - The current version of Shorewall is 1.1.16. In this + version:

    - + - -

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

    + +

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

    - + - -

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

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

    - + - -

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

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

    - + - -

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

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

    - + - -

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

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

    - + - -

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

    + +

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

    - + - -

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

    + +

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

    - + - -

    6/18/2001 - The current version of Shorewall is 1.1.8. In this -version

    + +

    6/18/2001 - The current version of Shorewall is 1.1.8. In this version

    - + - +

    6/2/2001 - The current version of Shorewall is 1.1.7. In this version

    - + - -

    5/25/2001 - The current version of Shorewall is 1.1.6. In this -version

    + +

    5/25/2001 - The current version of Shorewall is 1.1.6. In this version

    - + - -

    5/20/2001 - The current version of Shorewall is 1.1.5. In this -version

    + +

    5/20/2001 - The current version of Shorewall is 1.1.5. In this version

    - + - -

    5/10/2001 - The current version of Shorewall is 1.1.4. In this -version

    + +

    5/10/2001 - The current version of Shorewall is 1.1.4. In this version

    - + - - -

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

    - - - +
  • The + order in which iptables kernel modules are loaded + has been corrected (Thanks to Mark Pavlidis). 
    • -

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

    + - + +

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

    + + + + +

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

    + + + - +

    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:

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

    - + +
  • 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 the command to work if awk isn't installed + (although it's not pretty).
    • -

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

    + - + +

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

    + + - -

    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.

    + +

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

    - -

    Updated 5/27/2003 - Tom Eastep + +

    Updated 5/29/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    -
    -
    +

    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index e3046f3fe..f2502ca45 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -1,298 +1,313 @@ - + Shorewall 1.4 Errata - + - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. -

      If you use a Windows system to download - a corrected script, be sure to run the script through +

    2. +

      If you use a Windows system to download + a corrected script, be sure to run the script through dos2unix after you have moved + style="text-decoration: none;"> dos2unix after you have moved it to your Linux system.

      -
      3. -
    3. -

      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 +

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

      When the instructions say to install a corrected - firewall script in /usr/share/shorewall/firewall, you +

      6. +
    6. +

      When the instructions say to install a corrected + firewall script in /usr/share/shorewall/firewall, you may rename the existing file before copying in the new file.

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

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

    - +

    - + +

    1.4.4-1.4.4a

    +
      +
    • Log messages are being displayed on the system console even though +the log level for the console is set properly according to FAQ 16. This problem may be corrected by installing + this firewall script in /usr/share/shorewall/firewall +as described above.
      +
      • +

    1.4.4
    -

    + +
      -
    • If you have zone names that are 5 characters long, you may experience -problems starting Shorewall because the --log-prefix in a logging rule is +
    • If you have zone names that are 5 characters long, you may experience +problems starting Shorewall because the --log-prefix in a logging rule is too long. Upgrade to Version 1.4.4a to fix this problem..
      • +
    +

    1.4.3

    - + - +

    1.4.2

    - -
      -
    • When an 'add' or 'delete' command is executed, a temporary directory - created in /tmp is not being removed. This problem may be corrected by installing - this firewall script in /usr/share/shorewall/firewall as -described ablve.
      -
      • - -
    - -

    1.4.1a, 1.4.1 and 1.4.0

      -
    • Some TCP requests are rejected in the 'common' chain with an ICMP - port-unreachable response rather than the more appropriate TCP RST response. - This problem is corrected in this updated common.def file which may be installed in - /etc/shorewall/common.def.
      +
    • When an 'add' or 'delete' command is executed, a temporary directory + created in /tmp is not being removed. This problem may be corrected by +installing this firewall script in /usr/share/shorewall/firewall +as described above.
    -

    1.4.1

    +

    1.4.1a, 1.4.1 and 1.4.0

      -
    • When a "shorewall check" command is executed, each "rule" produces - the harmless additional message:
      -
      -      /usr/share/shorewall/firewall: line 2174: [: =: unary operator -expected
      -
      - You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall - as described above.
      +
    • Some TCP requests are rejected in the 'common' chain with an ICMP + port-unreachable response rather than the more appropriate TCP RST response. + This problem is corrected in this updated common.def file which may be installed in + /etc/shorewall/common.def.
    -

    1.4.0

    +

    1.4.1

      -
    • When running under certain shells Shorewall will attempt to create - ECN rules even when /etc/shorewall/ecn is empty. You may either just remove - /etc/shorewall/ecn or you can install this - correct script in /usr/share/shorewall/firewall as described above.
      +
    • When a "shorewall check" command is executed, each "rule" produces + the harmless additional message:
      +
      +      /usr/share/shorewall/firewall: line 2174: [: =: unary operator +expected
      +
      + You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall + as described above.
    -
    -

    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. 

    - -

    I have built a - 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.

    - -

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

    - -

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

    - -

    To install one of the above patches:

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

    Problems with kernels >= 2.4.18 and -RedHat iptables

    - -
    -

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

    - -
    - 
    # 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 to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    - -

    Problems installing/upgrading - RPM on SuSE

    - -

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

    - -

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

    - -

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

    - -

    Problems with iptables version 1.2.7 and - MULTIPORT=Yes

    - -

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

    +

    1.4.0

      -
    • set MULTIPORT=No - in /etc/shorewall/shorewall.conf; or -
      • -
    • if you are - running Shorewall 1.3.6 you may - install - this firewall script in /var/lib/shorewall/firewall - as described above.
      • - +
    • When running under certain shells Shorewall will attempt to +create ECN rules even when /etc/shorewall/ecn is empty. You may either +just remove /etc/shorewall/ecn or you can install this + correct script in /usr/share/shorewall/firewall as described above.
      +
      • +
    - + +
    +

    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. 

    + +

    I have built a + 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.

    + +

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

    + +

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

    + +

    To install one of the above patches:

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

    Problems with kernels >= 2.4.18 +and RedHat iptables

    + +
    +

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

    + +
    + 
    # 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 to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    + +

    Problems installing/upgrading + RPM on SuSE

    + +

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

    + +

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

    + +

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

    + +

    Problems with iptables version 1.2.7 and + MULTIPORT=Yes

    + +

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

    + +
      +
    • set MULTIPORT=No + in /etc/shorewall/shorewall.conf; or +
      • +
    • if you are + running Shorewall 1.3.6 you may + install + this firewall script in /var/lib/shorewall/firewall + as described above.
      • + +
    +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

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

    - The solution is to put "no" in the LOCAL column. Kernel - support for LOCAL=yes has never worked properly and 2.4.18-10 -has disabled it. The 2.4.19 kernel contains corrected support under + 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 5/27/2003 - Tom Eastep -

    - + +

    Last updated 5/29/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 2464ee0c2..120fb94b8 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -1,140 +1,144 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - - - - +
    +    
    + + + + +
    +

    Vexira Logo -

    - + - + +

     

    -     		- + +

    Shorewall Mailing Lists

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

    -
    -    
    -
    -
    + +

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

    -

    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

    - +

    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 tmeastep -at hotmail dot com.

    - + +

    You can report such problems by sending mail to tmeastep at +hotmail dot com.

    +

    A Word about the SPAM Filters at Shorewall.net 

    - -

    Please note that the mail server at shorewall.net -checks incoming mail:
    -

    - + +

    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 +
    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 +
    8. to ensure that the host name in the HELO/EHLO command is a valid fully-qualified DNS name that resolves.
      9. - +
    9. to ensure that the client system has a valid PTR record in DNS.
      +
      10. +
    - +

    Please post in plain text

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

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

    - +

    +

    Other Mail Delivery Problems

    - If you find that you are missing an occasional list post, -your e-mail admin may be blocking mail whose Received: headers -contain the names of certain ISPs. Again, I believe that such policies -hurt more than they help but I'm not prepared to go so far as to start + 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 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.
    - + If you want to trust X.509 certificates issued +by Shoreline Firewall (such as the one used on my web site), you +may download and install my CA certificate + in your browser. If you don't wish to trust my certificates +then you can either use unencrypted access when subscribing to +Shorewall mailing lists or you can use secure access (SSL) and +accept the server's certificate when prompted by your browser.
    +

    Shorewall Users Mailing List

    - -

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

    - -

    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 3/24/2003 - Last updated 5/29/2003 - Tom Eastep

    - -

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

    + +

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

    +


    diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index 8ccc6e696..53c7516ce 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,220 +1,229 @@ - + My Shorewall Configuration - + - + - + - + - - - + + - - - + + + +
    +

    About My Network

    -
    - +
    - +

    My Current Network

    - -
    -

    Warning 1: I - use a combination of Static NAT and Proxy ARP, neither of which are relevant - to a simple configuration with a single public IP address. - If you have just a single public IP address, most of what you see here won't - apply to your setup so beware of copying parts of this configuration and - expecting them to work for you. What you copy may or may not work in your -configuration.
    -

    - -

    Warning 2: My -configuration uses features introduced in Shorewall version 1.4.1.
    -

    - -

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). - My DSL "modem" (Fujitsu Speedport) - is connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

    +
    +

    Warning 1: I + use a combination of Static NAT and Proxy ARP, neither of which are relevant + to a simple configuration with a single public IP address. + If you have just a single public IP address, most of what you see here +won't apply to your setup so beware of copying parts of this configuration +and expecting them to work for you. What you copy may or may not work in +your configuration.
    +

    + +

    Warning 2: My + configuration uses features introduced in Shorewall version 1.4.1.
    +

    + +

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). + My DSL "modem" (Fujitsu Speedport) + is connected to eth0. I have a local network connected to eth2 (subnet + 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

    +

    I use:
    -

    - +

    +
      -
    • Static NAT for Ursa (my XP System) - Internal address -192.168.1.5 and external address 206.124.146.178.
      • -
    • Static NAT for Wookie (my Linux System). Internal address - 192.168.1.3 and external address 206.124.146.179.
      • -
    • SNAT through the primary gateway address (206.124.146.176) - for  my Wife's system (Tarry) and our  laptop (Tipper) which connects -through the Wireless Access Point (wap)
      • - +
    • Static NAT for Ursa (my XP System) - Internal address + 192.168.1.5 and external address 206.124.146.178.
      • +
    • Static NAT for Wookie (my Linux System). Internal address + 192.168.1.3 and external address 206.124.146.179.
      • +
    • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (Tarry) and our  laptop (Tipper) which connects +through the Wireless Access Point (wap) via a Wireless Bridge (bridge).
      +
      +Note:       While the distance between the WAP and where I usually use the +laptop isn't very far (25 feet or so), using a WAC11 (CardBus wireless card) +has proved very unsatisfactory (lots of lost connections). By replacing the +WAC11 with the WET11 wireless bridge, I have virtually eliminated these problems +(I was also able to eliminate them by hanging a piece of aluminum foil on +the family room wall but Tarry rejected that as a permanent solution :-).
      • +
    - +

    The firewall runs on a 256MB PII/233 with RH8.0.

    - -

    Wookie runs Samba and acts as the a WINS server.  Wookie is in its - own 'whitelist' zone called 'me'.

    - -

    My laptop (eastept1) is connected to eth3 using a cross-over cable. - It runs its own Sygate firewall -software and is managed by Proxy ARP. It connects to the local network -through a PPTP server running on Ursa.

    - -

    The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP - server (Pure-ftpd). The system also runs fetchmail to fetch our email - from our old and current ISPs. That server is managed through Proxy ARP.

    - -

    The firewall system itself runs a DHCP server that serves the local - network.

    - -

    All administration and publishing is done using ssh/scp. I have X installed - on both the firewall and the server but no X server or desktop is installed. - X applications tunnel through SSH to XWin.exe running on Ursa.

    - + +

    Wookie runs Samba and acts as the a WINS server.  Wookie is in its + own 'whitelist' zone called 'me'.

    + +

    My work laptop (easteplaptop) is connected to eth3 using a cross-over +cable. It runs its own Sygate +firewall software and is managed by Proxy ARP. It connects to the local +network through a PPTP server. running on Ursa.

    + +

    The single system in the DMZ (address 206.124.146.177) runs postfix, + Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP + server (Pure-ftpd). The system also runs fetchmail to fetch our email + from our old and current ISPs. That server is managed through Proxy +ARP.

    + +

    The firewall system itself runs a DHCP server that serves the local + network.

    + +

    All administration and publishing is done using ssh/scp. I have X installed + on both the firewall and the server but no X server or desktop is installed. + X applications tunnel through SSH to XWin.exe running on Ursa.

    +

    I run an SNMP server on my firewall to serve MRTG running - in the DMZ.

    - + href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG running + in the DMZ.

    +

    -

    - +

    +

     

    - -

    The ethernet interface in the Server is configured with IP address -206.124.146.177, netmask 255.255.255.0. The server's default gateway is - 206.124.146.254 (Router at my ISP. This is the same default -gateway used by the firewall itself). On the firewall, - Shorewall automatically adds a host route to - 206.124.146.177 through eth1 (192.168.2.1) because of - the entry in /etc/shorewall/proxyarp (see below).

    - -

    A similar setup is used on eth3 (192.168.3.1) which interfaces + +

    The ethernet interface in the Server is configured with IP address +206.124.146.177, netmask 255.255.255.0. The server's default gateway is + 206.124.146.254 (Router at my ISP. This is the same default +gateway used by the firewall itself). On the firewall, + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because of + the entry in /etc/shorewall/proxyarp (see below).

    + +

    A similar setup is used on eth3 (192.168.3.1) which interfaces to my laptop (206.124.146.180).
    -

    - -

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior - access.
    -

    - +

    + +

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior + access.
    +

    +

    -
    - +
    +

    Shorewall.conf

    - -
    + +
    SHARED_DIR=/usr/share/shorewall
    LOGFILE=/var/log/firewall
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=info
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    NAT_ENABLED=Yes
    MANGLE_ENABLED=Yes
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    MULTIPORT=Yes
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    -
    - +
    +

    - +

    Params File (Edited):

    - -
    + +
    MIRRORS=<list of shorewall mirror ip addresses>
    NTPSERVERS=<list of the NTP servers I sync with>
 TEXAS=<ip address of gateway in Dallas>
    LOG=ULOG
    -
    - +
    +

    Zones File

    - -
    + +
    #ZONE	DISPLAY		COMMENTS
    net     Internet        Internet
    me      Wookie          My Linux Workstation
    dmz     DMZ             Demilitarized zone
    loc     Local           Local networks
    tx      Texas           Peer Network in Dallas
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Interfaces File:

    - -
    -

    This is set up so that I can start the firewall before bringing up -my Ethernet interfaces.

    -
    - -
    + +
    +

    This is set up so that I can start the firewall before bringing up my +Ethernet interfaces.

    +
    + +
    #ZONE	INERFACE	BROADCAST	OPTIONS
    net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
    loc     eth2            192.168.1.255   dhcp,maclist
    dmz     eth1            192.168.2.255
    net     eth3            206.124.146.255
    -       texas           192.168.9.255
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Hosts File:

    - -
    + +
    #ZONE		HOST(S)			OPTIONS
    me              eth2:192.168.1.3
    tx              texas:192.168.8.0/22
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Routestopped File:

    - -
    + +
    #INTERFACQ	HOST(S)
    eth1            206.124.146.177
    eth2            -
    eth3            206.124.146.180
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Policy File:

    - -
    + +
    #SOURCE		DESTINATION	POLICY		LOG LEVEL	BURST:LIMIT
    me		loc		NONE
    loc		me		NONE
    me              all             ACCEPT
    tx              me              ACCEPT
    all             me              CONTINUE        -               2/sec:5
    loc             net             ACCEPT
    $FW             loc             ACCEPT
    $FW             tx              ACCEPT
    loc             tx              ACCEPT
    loc             fw              REJECT          $LOG
    net             all             DROP            $LOG            10/sec:40
    all             all             REJECT          $LOG
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Masq File:

    - -
    -

    Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with - laptops. Also, I masquerade wookie to the peer subnet in Texas.

    -
    - -
    + +
    +

    Although most of our internal systems use static NAT, my wife's system + (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors +with laptops. Also, I masquerade wookie to the peer subnet in Texas.

    +
    + +
    #INTERFACE              SUBNET          ADDRESS
    eth0:0.0.0.0/0          eth2            206.124.146.176
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    - +
    +

    NAT File:

    - -
    + +
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    206.124.146.178 eth0:0          192.168.1.5     No                      No
    206.124.146.179 eth0:1          192.168.1.3     No                      No
    192.168.1.193   eth2:0          206.124.146.177 No                      No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    - +
    +

    Proxy ARP File:

    - -
    + +
    #ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
    206.124.146.177         eth1            eth0            No
    206.124.146.180         eth3            eth0            No
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - +
    +

    Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):

    - -
    + +
    #TYPE			ZONE    GATEWAY         GATEWAY ZONE    PORT
    gre                     net     $TEXAS
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - +
    +

    Common File:

    - -
    + +
    . /etc/shorewall/common.def
    run_iptables -A common -p tcp --dport auth -j REJECT
    -
    - +
    +

    Rules File (The shell variables are set in /etc/shorewall/params):

    - -
    + +
    ################################################################################################################################################################
    #RESULT         CLIENT(S)                       SERVER(S)               PROTO   PORT(S)                                 CLIENT          ORIGINAL DEST:SNAT
    ################################################################################################################################################################
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:$LOG     loc                             net                     tcp     6667
    #
    # Stop NETBIOS crap since our policy is ACCEPT
    #
    REJECT          loc                             net                     tcp     137,445
    REJECT          loc                             net                     udp     137:139
    LOG:$LOG        loc                             net                     tcp     137:139
    ################################################################################################################################################################
    # Local Network to Firewall
    #
    ACCEPT          loc                             fw                      tcp     ssh,time,10000
    ACCEPT          loc                             fw                      udp     snmp
    ACCEPT          loc                             fw                      udp     ntp
    ################################################################################################################################################################
    # Local Network to DMZ (10027 is our SMTP backdoor that bypasses virus/spam filtering)
    #
    ACCEPT          loc                             dmz                     udp     domain
    ACCEPT          loc                             dmz                     tcp     smtp,domain,ssh,imap,https,imaps,cvspserver,www,ftp,10027,10000,8080    -
    ################################################################################################################################################################
    # Internet to DMZ
    #
    ACCEPT          net                             dmz                     tcp     www,smtp,ftp,imaps,domain,cvspserver,https,imap -
    ACCEPT          net                             dmz                     udp     domain
    ACCEPT          net:$MIRRORS                    dmz                     tcp     rsync
    ACCEPT:$LOG     net                             dmz                     tcp     32768:61000                             20
    DROP            net                             dmz                     tcp     1433
    ################################################################################################################################################################
    #
    # Net to Local
    #
    # My laptop isn't NATTED when in its docking station. To allow access to the local lan, I need a VPN to Ursa which is enabled by the following "half"-rules.
    #
    DNAT-           net                             loc:192.168.1.5         tcp     1723                                    -               206.124.146.178
    DNAT-           net                             loc:192.168.1.5         gre     -                                       -               206.124.146.178
    #
    # When I'm "on the road", the following two rules allow me VPN access back home.
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     1723
    ACCEPT          net                             loc:192.168.1.5         gre
    #
    # ICQ to Ursa
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     4000:4100
    ################################################################################################################################################################
    # Net to me
    #
    ACCEPT          net                             me:192.168.1.3          tcp     4000:4100
    ################################################################################################################################################################
    # DMZ to Internet
    #
    ACCEPT          dmz                             net                     tcp     smtp,domain,www,https,whois,echo,2702,21,2703,ssh
    ACCEPT          dmz                             net                     udp     domain
    ACCEPT          dmz                             net:206.124.128.8       tcp     pop3
    ACCEPT          dmz                             net:66.216.26.115       tcp     pop3
    #
    # Something is wrong with the FTP connection tracking code or there is some client out there
    # that is sending a PORT command which that code doesn't understand. Either way,
    # the following works around the problem.
    #
    ACCEPT:$LOG     dmz                             net                     tcp     1024:                                   20
    ################################################################################################################################################################
    # DMZ to Firewall -- ntp & snmp
    #
    ACCEPT          dmz                             fw                      udp     ntp                                     ntp
    ACCEPT          dmz                             fw                      tcp     snmp
    ACCEPT          dmz                             fw                      udp     snmp
    ################################################################################################################################################################
    #
    # DMZ to Local Network
    #
    ACCEPT          dmz                             loc                     tcp     smtp
    ################################################################################################################################################################
    #
    # DMZ to Me -- NFS
    #
    ACCEPT          dmz                             me                      tcp     111
    ACCEPT          dmz                             me                      udp     111
    ACCEPT          dmz                             me                      udp     2049
    ACCEPT          dmz                             me                      udp     32700:
    ################################################################################################################################################################
    # Internet to Firewall
    #
    ACCEPT          net:eth3:206.124.146.180        fw                      udp     ntp                                     ntp
    REJECT          net                             fw                      tcp     www
    DROP            net                             fw                      tcp     1433
    DROP            net:eth3:!206.124.146.180       fw                      all
    ################################################################################################################################################################
    # Firewall to Internet
    #
    ACCEPT          fw                              net:$NTPSERVERS         udp     ntp                                     ntp
    ACCEPT          fw                              net                     udp     domain
    ACCEPT          fw                              net                     tcp     domain,www,https,ssh,1723,whois,1863
    ACCEPT          fw                              net                     udp     33435:33535
    ACCEPT          fw                              net                     icmp    8
    ################################################################################################################################################################
    # Firewall to DMZ
    #
    ACCEPT          fw                              dmz                     tcp     www,ftp,ssh,smtp
    ACCEPT          fw                              dmz                     udp     domain
    ACCEPT          fw                              dmz                     icmp    8
    REJECT          fw                              dmz                     udp     137:139
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - +
    +

    Tom Eastep

    - Copyright -© 2001, 2002, 2003 Thomas M. Eastep.
    + Copyright + © 2001, 2002, 2003 Thomas M. Eastep.
    +
    diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index bc913d13d..4ebd9e654 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -2,117 +2,119 @@ - + Shoreline Firewall (Shorewall) 1.4 - - + - + - + - - + + - - + +
    + - +

    Shorwall Logo - (Shorewall Logo) -

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

    Shorewall 1.4 "iptables made easy"
    -
    +
    -

    -
    + +
    - + +

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is a - Netfilter (iptables) based firewall - that can be used on a dedicated firewall system, a multi-function - 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.

    - -

    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

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -121,287 +123,303 @@ General Public License as published by the Free Software - +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, almost NOTHING on this site will apply directly to -your setup. If you want to use the documentation that you find here, it -is best if you uninstall what you have and install a setup that matches -the documentation on this site. See the Two-interface -QuickStart Guide for details.
    - + If so, almost NOTHING on this site will apply directly to +your setup. If you want to use the documentation that you find here, it +is best if you uninstall what you have and install a setup that matches +the documentation on this site. See the Two-interface + QuickStart Guide for details.
    +

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    + New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
    - +

    News

    - + + +

    5/29/2003 - Shorewall-1.4.4b (New) +

    + +

    Groan -- This version corrects a problem whereby the --log-level +was not being set when logging via syslog. The most commonly reported symptom +was that Shorewall messages were being written to the console even though +console logging was correctly configured per FAQ +16.
    +

    +

    5/27/2003 - Shorewall-1.4.4a (New) -

    - The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out - that the code in 1.4.4 restricts the length of short zone names to 4 characters. - I've produced version 1.4.4a that restores the previous 5-character limit - by conditionally omitting the log rule number when the LOGFORMAT doesn't -contain '%d'. +

    + The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out + that the code in 1.4.4 restricts the length of short zone names to 4 characters. + I've produced version 1.4.4a that restores the previous 5-character limit + by conditionally omitting the log rule number when the LOGFORMAT doesn't +contain '%d'.

    5/23/2003 - Shorewall-1.4.4 (New) -

    - I apologize for the rapid-fire releases but since there is a potential -configuration change required to go from 1.4.3a to 1.4.4, I decided to make -it a full release rather than just a bug-fix release.
    -
    -     Problems corrected:
    - +

    + I apologize for the rapid-fire releases but since there is a potential + configuration change required to go from 1.4.3a to 1.4.4, I decided to +make it a full release rather than just a bug-fix release.
    +
    +     Problems corrected:
    +
    None.
    -
    -     New Features:
    -     + +     New Features:
    +
      -
    1. A REDIRECT- rule target has been added. This target behaves - for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter - nat table REDIRECT rule is added but not the companion filter table ACCEPT +
    2. A REDIRECT- rule target has been added. This target behaves + for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter + nat table REDIRECT rule is added but not the companion filter table ACCEPT rule.
      -
      -
      3. -
    3. The LOGMARKER variable has been renamed LOGFORMAT and has -been changed to a 'printf' formatting template which accepts three arguments -(the chain name, logging rule number and the disposition). To use LOGFORMAT -with fireparse (http://www.fireparse.com), - set it as:
      -  
      -        LOGFORMAT="fp=%s:%d a=%s "
      -  
      - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in -the 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be +
      +
      4. +
    4. The LOGMARKER variable has been renamed LOGFORMAT and has +been changed to a 'printf' formatting template which accepts three arguments + (the chain name, logging rule number and the disposition). To use LOGFORMAT + with fireparse (http://www.fireparse.com), + set it as:
      +  
      +        LOGFORMAT="fp=%s:%d a=%s "
      +  
      + CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log messages in the + 'show log', 'status' and 'hits' commands. This part should not be omitted + (the LOGFORMAT should not begin with "%") and the leading part should be sufficiently unique for /sbin/shorewall to identify Shorewall messages.
      -
      -
      5. -
    5. When logging is specified on a DNAT[-] or REDIRECT[-] rule, - the logging now takes place in the nat table rather than in the filter table. - This way, only those connections that actually undergo DNAT or redirection - will be logged.
      -
      6. - +
      + +
    6. When logging is specified on a DNAT[-] or REDIRECT[-] rule, + the logging now takes place in the nat table rather than in the filter table. + This way, only those connections that actually undergo DNAT or redirection + will be logged.
      +
      7. +
    - +

    5/20/2003 - Shorewall-1.4.3a
    -

    - This version primarily corrects the documentation included in the .tgz - and in the .rpm. In addition:
    - +

    + This version primarily corrects the documentation included in the .tgz + and in the .rpm. In addition:
    +
      -
    1. (This change is in 1.4.3 but is not documented) If you are - running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject - replies as follows:
      -    a) tcp - RST
      -    b) udp - ICMP port unreachable
      -    c) icmp - ICMP host unreachable
      -    d) Otherwise - ICMP host prohibited
      - If you are running earlier software, Shorewall will follow it's traditional - convention:
      -    a) tcp - RST
      -    b) Otherwise - ICMP port unreachable
      2. -
    2. UDP port 135 is now silently dropped in the common.def chain. - Remember that this chain is traversed just before a DROP or REJECT policy - is enforced.
      -
      3. - +
    3. (This change is in 1.4.3 but is not documented) If you +are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return +reject replies as follows:
      +    a) tcp - RST
      +    b) udp - ICMP port unreachable
      +    c) icmp - ICMP host unreachable
      +    d) Otherwise - ICMP host prohibited
      + If you are running earlier software, Shorewall will follow it's traditional + convention:
      +    a) tcp - RST
      +    b) Otherwise - ICMP port unreachable
      4. +
    4. UDP port 135 is now silently dropped in the common.def +chain. Remember that this chain is traversed just before a DROP or REJECT +policy is enforced.
      +
      5. +
    - +

    5/18/2003 - Shorewall 1.4.3
    -

    -     Problems Corrected:
    -     +

    +     Problems Corrected:
    +     +
      -
    1. There were several cases where Shorewall would fail to -remove a temporary directory from /tmp. These cases have been corrected.
      2. -
    2. The rules for allowing all traffic via the loopback interface - have been moved to before the rule that drops status=INVALID packets. -This insures that all loopback traffic is allowed even if Netfilter connection +
    3. There were several cases where Shorewall would fail to + remove a temporary directory from /tmp. These cases have been corrected.
      4. +
    4. The rules for allowing all traffic via the loopback interface + have been moved to before the rule that drops status=INVALID packets. +This insures that all loopback traffic is allowed even if Netfilter connection tracking is confused.
      5. - +
    -     New Features:
    -     +     New Features:
    +     +
      -
    1.  IPV6-IPV4 (6to4) tunnels are now - supported in the /etc/shorewall/tunnels file.
      2. -
    2. You may now change the leading portion of the --log-prefix - used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, +
    3.  IPV6-IPV4 (6to4) tunnels are +now supported in the /etc/shorewall/tunnels file.
      4. +
    4. You may now change the leading portion of the --log-prefix + used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, "Shorewall:" is used.
      -
      5. - -
    - -

    5/10/2003 - Shorewall Mirror in Asia
    -

    - Ed Greshko has established a mirror in Taiwan -- Thanks Ed! + - + + + +

    5/10/2003 - Shorewall Mirror in Asia
    +

    + Ed Greshko has established a mirror in Taiwan -- Thanks Ed! + +

    5/8/2003 - Shorewall Mirror in Chile  

    - +

    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
    -

    +

    - +

    4/26/2003 - lists.shorewall.net Downtime

    - +

    The list server will be down this morning for upgrade to RH9.0.
    -

    +

    - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 -

    - - - -

    Thanks to Francesca Smith, the sample configurations are now upgraded - to Shorewall version 1.4.2.

    - - - -

    4/12/2002 - Greater Seattle Linux Users Group Presentation + +

    4/21/2003 - Samples updated for Shorewall version 1.4.2

    - -
    This morning, I gave a - Shorewall presentation to GSLUG. The presentation is - in HTML format but was generated from Microsoft PowerPoint and is best - viewed using Internet Explorer (although Konqueror also seems to work - reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape -work well to view the presentation.
    -
    + +

    Thanks to Francesca Smith, the sample configurations are now upgraded + to Shorewall version 1.4.2.

    - + +

    4/12/2002 - Greater Seattle Linux Users Group Presentation +

    + + + +
    This morning, I gave a + Shorewall presentation to GSLUG. The presentation +is in HTML format but was generated from Microsoft PowerPoint and +is best viewed using Internet Explorer (although Konqueror also seems +to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor +Netscape work well to view the presentation.
    +
    + + +

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

    More News

    - + +

    (Leaf Logo) - Jacques Nilo and Eric Wolzak have - a LEAF (router/firewall/gateway on a floppy, - CD or compact flash) distribution called - Bering that features Shorewall-1.3.14 - and Kernel-2.4.20. You can find their - work at: Jacques Nilo and Eric Wolzak have + a LEAF (router/firewall/gateway on a floppy, + CD or compact flash) distribution called + Bering that features Shorewall-1.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.2!!!
    - + Congratulations to Jacques and Eric on the recent release + of Bering 1.2!!!
    + +

    Donations

    -     		- + +
    -
    - Note: -     Search is unavailable - Daily 0200-0330 GMT.
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> +
    + Note: +     Search is unavailable + Daily 0200-0330 GMT.
    + - +

    Quick Search
    - + name="config" value="htdig">

    -
    - +

    Extended Search

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

    -

    +

    - -

    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 5/27/2003 - Tom Eastep -
    -

    -
    -
    + +

    Updated 5/29/2003 - Tom Eastep +
    +

    diff --git a/STABLE/documentation/shoreline.htm b/STABLE/documentation/shoreline.htm index 48b7e9a8e..08ec79f06 100644 --- a/STABLE/documentation/shoreline.htm +++ b/STABLE/documentation/shoreline.htm @@ -1,135 +1,136 @@ - + About the Shorewall Author - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Tom Eastep

    -
    - +

    Tom on the PCT - 1991 -

    - +

    +

    Tarry & Tom -- August 2002
    -
    -

    - +
    +

    + - -

    I am currently a member of the design team for the next-generation operating - system from the NonStop Enterprise Division of HP.

    - -

    I became interested in Internet Security when I established a home office - in 1999 and had DSL service installed in our home. I investigated - ipchains and developed the scripts which are now collectively known - as Seattle Firewall. - Expanding on what I learned from Seattle Firewall, I then designed - and wrote Shorewall.

    - + +

    I am currently a member of the design team for the next-generation operating + system from the NonStop Enterprise Division of HP.

    + +

    I became interested in Internet Security when I established a home office + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known + as Seattle Firewall. + Expanding on what I learned from Seattle Firewall, I then +designed and wrote Shorewall.

    +

    I telework from our home in Shoreline, Washington where -I live with my wife Tarry. 

    - + href="http://www.cityofshoreline.com">Shoreline, Washington +where I live with my wife Tarry. 

    +

    Our current home network consists of:

    - +
      -
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB -& 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows +
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB + & 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Serves as a PPTP server for Road Warrior access. Dual boots Mandrake 9.0.
      • -
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) - NIC - My personal Linux System which runs Samba configured -as a WINS server. This system also has VMware installed and can run both - Debian Woody and Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) + NIC - My personal Linux System which runs Samba configured as + a WINS server. This system also has VMware installed and can run +both Debian Woody and SuSE 8.1 in virtual machines.
      • -
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 - NIC  - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP +
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 + NIC  - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd), DNS server (Bind 9).
      • -
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - -3 LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall - 1.4.2  and a DHCP server.
      • -
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 +
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - +3 LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall +1.4.4a  and a DHCP server.
      • +
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My wife's personal system.
      • -
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, -built-in EEPRO100, EEPRO100 in expansion base and LinkSys WAC11 - My - work system.
      • -
    • XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC and LinkSys -WAC11 - Our Laptop.
      -
      • - +
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, + built-in EEPRO100, EEPRO100 in expansion base and LinkSys WAC11 - My + work system.
      • +
    • XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC and LinkSys + WET11 - Our Laptop.
      +
      • +
    - +

    For more about our network see my Shorewall Configuration.

    - +

    All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs.

    - +

    - - - + - Powered by Mandrake - Protected by Shorewall - (Opera Logo) -     -

    - +

    +

    Last updated 5/8/2003 - Tom Eastep

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



    diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index 27258896c..441f66055 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -2,420 +2,430 @@ - + Shoreline Firewall (Shorewall) 1.3 - + + - + - + - + - - + + + - - + +
    + - +

    Shorwall Logo - Shorewall 1.4 - - "iptables made -easy"
    - Shorewall 1.4 + - "iptables made easy"
    +
    -     + -

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is - a Netfilter - (iptables) based firewall that can be used -on a dedicated firewall system, a multi-function - 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.

    - -

    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

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    - +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, almost NOTHING on this site will apply directly to -your setup. If you want to use the documentation that you find here, it -is best if you uninstall what you have and install a setup that matches -the documentation on this site. See the Two-interface -QuickStart Guide for details.
    - + If so, almost NOTHING on this site will apply directly to +your setup. If you want to use the documentation that you find here, it +is best if you uninstall what you have and install a setup that matches +the documentation on this site. See the Two-interface + QuickStart Guide for details.
    +

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely + New to Shorewall? Start by selecting the QuickStart Guide that most closely match your environment and follow the step by step instructions.
    - +

    News

    - + - + +

    5/29/2003 - Shorewall-1.4.4b (New) +

    + +

    Groan -- This version corrects a problem whereby the --log-level +was not being set when logging via syslog. The most commonly reported symptom +was that Shorewall messages were being written to the console even though +console logging was correctly configured per FAQ +16.
    +

    +

    5/27/2003 - Shorewall-1.4.4a (New) -

    - The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out - that the code in 1.4.4 restricts the length of short zone names to 4 characters. - I've produced version 1.4.4a that restores the previous 5-character limit - by conditionally omitting the log rule number when the LOGFORMAT doesn't -contain '%d'. +

    + The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed +out that the code in 1.4.4 restricts the length of short zone names to 4 +characters. I've produced version 1.4.4a that restores the previous 5-character +limit by conditionally omitting the log rule number when the LOGFORMAT doesn't +contain '%d'.

    5/23/2003 - Shorewall-1.4.4 (New) -

    - I apologize for the rapid-fire releases but since there is a potential - configuration change required to go from 1.4.3a to 1.4.4, I decided to make +

    + I apologize for the rapid-fire releases but since there is a potential + configuration change required to go from 1.4.3a to 1.4.4, I decided to make it a full release rather than just a bug-fix release.
    -
    -     Problems corrected:
    - +
    +     Problems corrected:
    +
    None.
    -
    -     New Features:
    -     + +     New Features:
    +
      -
    1. A REDIRECT- rule target has been added. This target behaves - for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter - nat table REDIRECT rule is added but not the companion filter table ACCEPT +
    2. A REDIRECT- rule target has been added. This target behaves + for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter + nat table REDIRECT rule is added but not the companion filter table ACCEPT rule.
      -
      -
      3. -
    3. The LOGMARKER variable has been renamed LOGFORMAT and has -been changed to a 'printf' formatting template which accepts three arguments -(the chain name, logging rule number and the disposition). To use LOGFORMAT -with fireparse (http://www.fireparse.com), - set it as:
      -  
      -        LOGFORMAT="fp=%s:%d a=%s "
      -  
      - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in -the 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be - sufficiently unique for /sbin/shorewall to identify Shorewall messages.
      -
      -
      4. -
    4. When logging is specified on a DNAT[-] or REDIRECT[-] rule, - the logging now takes place in the nat table rather than in the filter table. - This way, only those connections that actually undergo DNAT or redirection - will be logged.
      5. - -
    - -

    5/20/2003 - Shorewall-1.4.3a -
    -

    - This version primarily corrects the documentation included in the .tgz - and in the .rpm. In addition:
    - -
      -
    1. (This change is in 1.4.3 but is not documented) If you are - running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject - replies as follows:
      -    a) tcp - RST
      -    b) udp - ICMP port unreachable
      -    c) icmp - ICMP host unreachable
      -    d) Otherwise - ICMP host prohibited
      - If you are running earlier software, Shorewall will follow it's traditional - convention:
      -    a) tcp - RST
      -    b) Otherwise - ICMP port unreachable
      2. -
    2. UDP port 135 is now silently dropped in the common.def chain. - Remember that this chain is traversed just before a DROP or REJECT policy - is enforced.
      -
      3. - -
    - -

    5/18/2003 - Shorewall 1.4.3
    -

    -     Problems Corrected:
    -     -
      -
    1. There were several cases where Shorewall would fail to -remove a temporary directory from /tmp. These cases have been corrected.
      2. -
    2. The rules for allowing all traffic via the loopback interface - have been moved to before the rule that drops status=INVALID packets. -This insures that all loopback traffic is allowed even if Netfilter connection - tracking is confused.
      3. - -
    -     New Features:
    -     -
      -
    1.  IPV6-IPV4 (6to4) - tunnels are now supported in the /etc/shorewall/tunnels file.
      2. -
    2. You may now change the leading portion of the - --log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf. - By default, "Shorewall:" is used.
      +
      3. - +
    3. The LOGMARKER variable has been renamed LOGFORMAT and has +been changed to a 'printf' formatting template which accepts three arguments + (the chain name, logging rule number and the disposition). To use LOGFORMAT + with fireparse (http://www.fireparse.com), + set it as:
      +  
      +        LOGFORMAT="fp=%s:%d a=%s "
      +  
      + CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log messages in the + 'show log', 'status' and 'hits' commands. This part should not be omitted + (the LOGFORMAT should not begin with "%") and the leading part should be + sufficiently unique for /sbin/shorewall to identify Shorewall messages.
      +
      +
      4. +
    4. When logging is specified on a DNAT[-] or REDIRECT[-] rule, + the logging now takes place in the nat table rather than in the filter table. + This way, only those connections that actually undergo DNAT or redirection + will be logged.
      5. +
    - + +

    5/20/2003 - Shorewall-1.4.3a +
    +

    + This version primarily corrects the documentation included in the .tgz + and in the .rpm. In addition:
    + +
      +
    1. (This change is in 1.4.3 but is not documented) If you +are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return +reject replies as follows:
      +    a) tcp - RST
      +    b) udp - ICMP port unreachable
      +    c) icmp - ICMP host unreachable
      +    d) Otherwise - ICMP host prohibited
      + If you are running earlier software, Shorewall will follow it's traditional + convention:
      +    a) tcp - RST
      +    b) Otherwise - ICMP port unreachable
      2. +
    2. UDP port 135 is now silently dropped in the common.def +chain. Remember that this chain is traversed just before a DROP or REJECT +policy is enforced.
      +
      3. + +
    + +

    5/18/2003 - Shorewall 1.4.3
    +

    +     Problems Corrected:
    +     + +
      +
    1. There were several cases where Shorewall would fail to + remove a temporary directory from /tmp. These cases have been corrected.
      2. +
    2. The rules for allowing all traffic via the loopback interface + have been moved to before the rule that drops status=INVALID packets. +This insures that all loopback traffic is allowed even if Netfilter connection + tracking is confused.
      3. + +
    +     New Features:
    +     + +
      +
    1.  IPV6-IPV4 +(6to4) tunnels are now supported in the /etc/shorewall/tunnels file.
      2. +
    2. You may now change the leading portion of the + --log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf. + By default, "Shorewall:" is used.
      +
      3. + +
    +

    5/10/2003 - Shorewall Mirror in Asia
    -

    - Ed Greshko has established a mirror in Taiwan -- Thanks Ed! - - +

    + Ed Greshko has established a mirror in Taiwan -- Thanks Ed! + +

    5/8/2003 - Shorewall Mirror in Chile  

    - +

    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
    -

    +

    - +

    4/26/2003 - lists.shorewall.net Downtime  

    - +

    The list server will be down this morning for upgrade to RH9.0.
    -

    +

    - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 + +

    4/21/2003 - Samples updated for Shorewall version 1.4.2

    - -

    Thanks to Francesca Smith, the sample configurations are now upgraded - to Shorewall version 1.4.2.

    - -

    4/12/2002 - Greater Seattle Linux Users Group Presentation +

    Thanks to Francesca Smith, the sample configurations are now upgraded + to Shorewall version 1.4.2.

    + + +

    4/12/2002 - Greater Seattle Linux Users Group Presentation

    - +
    This morning, I gave a Shorewall presentation to GSLUG. The presentation - is in HTML format but was generated from Microsoft PowerPoint and - is best viewed using Internet Explorer (although Konqueror also seems - to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape - work well to view the presentation.
    + target="_top">a Shorewall presentation to GSLUG. The presentation + is in HTML format but was generated from Microsoft PowerPoint and + is best viewed using Internet Explorer (although Konqueror also seems + to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor +Netscape work well to view the presentation. - +

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

    - - - + +
    + + + +

    + + + +

    More News

    - + - +

    - + - +

    (Leaf Logo) - Jacques Nilo and Eric Wolzak have - a LEAF (router/firewall/gateway on a floppy, - CD or compact flash) distribution called - Bering that features -Shorewall-1.3.14 and Kernel-2.4.20. You can find - their work at: Jacques Nilo and Eric Wolzak +have a LEAF (router/firewall/gateway on +a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.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.2!!!
    - + Congratulations to Jacques and Eric + on the recent release of Bering 1.2!!!
    + +

    SourceForge Logo -

    - +     + - +

    - + - +

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

    - + - +

    Donations

    -     		- + +
    + action="http://lists.shorewall.net/cgi-bin/htsearch"> - +


    - Note:     - Search is unavailable Daily 0200-0330 - GMT.
    -  

    + Note: + Search is unavailable Daily 0200-0330 + GMT.
    +  

    - +

    Quick Search
    - - +

    - -
    + value="[http://lists.shorewall.net/pipermail/*]"> + - +

    Extended Search

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

    -

    +

    - -

    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 5/27/2003 - Tom Eastep -
    -

    -
    -
    -
    + +

    Updated 5/29/2003 - Tom Eastep +
    +

    diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 368f20fa9..775227cf0 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,81 +1,81 @@ - + - + Shorewall Support Guide - + - - - + + - - - + + + + +
    - +
    +

    Shorewall Support Guide -

    -
    - +

    Before Reporting a Problem or Asking a Question
    -

    - There -are a number of sources of Shorewall information. Please try these -before you post. + + There +are a number of sources of Shorewall information. Please try these +before you post. - +

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + action="http://lists.shorewall.net/cgi-bin/htsearch"> Match: + - Format: - + Format: + - Sort by: - + Sort by: + - Include Mailing List Archives: - + size="-1"> Include Mailing List Archives: + -
    - Search:
    + Search:
    - -
    - + +
    +

    Problem Reporting Guidelines
    -

    - + +
      -
    • Please remember we only know what - is posted in your message. Do not leave out any information - that appears to be correct, or was mentioned in a previous post. - There have been countless posts by people 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 - 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 +
    • 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 or summary.
      +
      +
      • +
    • + Please don't describe your environment and then ask +us to send you custom configuration files. We're +here to answer your questions but we can't do +your job for you.
      +
      +
      • +
    • When reporting a problem, ALWAYS include this information:
      • - +
    - +
      - +
        -
      • the exact version of Shorewall +
      • the exact version of Shorewall you are running.
        -
        - shorewall +
        + shorewall version
        -
        -
        • - +
        + +
      - +
        -
      • the exact kernel version you +
      • the exact kernel version you are running
        -
        - uname +
        + uname -a
        -
        -
        • - +
        +         +
      - +
        -
      • the complete, exact output of
        -
        - ip addr +
      • the complete, exact output of
        +
        + ip addr show
        -
        -
        • - +
        +         +
      - +
        -
      • the complete, exact output of
        -
        - ip route - show
        -
        -
        • - +
      • the complete, exact output of
        +
        + ip route + show
        +
        +
        • +
      - +
        -
      • If your kernel is modularized, +
      • If your kernel is modularized, the exact output from
        -
        - lsmod
        -
        • +
        + lsmod
        + +
      - +
    - +
      - +
        -
      • 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.
        -
        -
        • -
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart - Guides, please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using -the Mandrake installation of Shorewall, please say so.
        -
        -
        • - -
      -
    • As - a general matter, please do not edit the diagnostic -information in an attempt to conceal your IP address, -netmask, nameserver addresses, domain name, etc. These aren't -secrets, and concealing them often misleads us (and 80% of the time, -a hacker could derive them anyway from information contained in -the SMTP headers of your post).
      -
      -
      • -
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when - you exercise the function that is giving you problems? If -so, include the message(s) in your post along with a copy of your -/etc/shorewall/interfaces file.
      -
      -
      • -
    • Please include any of the Shorewall configuration - files (especially the /etc/shorewall/hosts file -if you have modified that file) that you think are - relevant. If you include /etc/shorewall/rules, please include -/etc/shorewall/policy as well (rules are meaningless unless -one also knows the policies).
      -
      -
      • -
    • If an error occurs when you try to "shorewall start", include a trace - (See the Troubleshooting - section for instructions).
      -
      -
      • -
    • The list server limits posts to 120kb so don't - post GIFs of your network 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 http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    -
    - -

    When using the mailing list, please post in plain text

    - -
    A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist - shorewall.net "for continuous abuse" because it has been my policy - to allow HTML in list posts!!
    +
  • 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.

    - 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.
    +
    • +
  • the exact wording of any ping failure responses
    +
    +
    • +
  • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
    +
    +
    • +
  • If you are running Shorewall under Mandrake using + the Mandrake installation of Shorewall, please say so.
    +
    +
    • + + +
  • As + a general matter, please do not edit the diagnostic + information in an attempt to conceal your IP address, + netmask, nameserver addresses, domain name, etc. These aren't + secrets, and concealing them often misleads us (and 80% of the time, + a hacker could derive them anyway from information contained in + the SMTP headers of your post).
    +
    +
    • +
  • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when + you exercise the function that is giving you problems? If so, + include the message(s) in your post along with a copy of your /etc/shorewall/interfaces + file.
    +
    +
    • +
  • Please include any of the Shorewall configuration + files (especially the /etc/shorewall/hosts file +if you have modified that file) that you think are + relevant. If you include /etc/shorewall/rules, please include +/etc/shorewall/policy as well (rules are meaningless unless one +also knows the policies).
    +
    +
    • +
  • If an error occurs when you try to "shorewall start", include a trace + (See the Troubleshooting + section for instructions).
    +
    +
    • +
  • The list server limits posts to 120kb so don't + post GIFs of your network 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 http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    - + +

    When using the mailing list, please post in plain text

    + +
    A growing number of MTAs serving list subscribers are +rejecting all HTML traffic. At least one MTA has gone so far as to +blacklist shorewall.net "for continuous abuse" because it has been +my policy to allow HTML in list posts!!
    +
    + I think that blocking all HTML +is a Draconian way to control spam and that the ultimate +losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list subscriber + wrote to me privately "These e-mail admin's need to get a (expletive + deleted) life instead of trying to rid the planet of HTML based + e-mail". Nevertheless, to allow 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 + style="font-weight: 400;">please post your question or problem to the LEAF Users mailing + href="mailto:leaf-user@lists.sourceforge.net">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 + 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 + href="mailto:shorewall-users@lists.shorewall.net">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 + 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 .
    -

    -
    - +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 5/19/2003 - Tom Eastep

    - +

    + +

    Last Updated 5/28/2003 - Tom Eastep

    +

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

    +

    +
    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 8f2c746b0..cb1efc4c7 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.4a +VERSION=1.4.4b usage() # $1 = exit status { diff --git a/STABLE/firewall b/STABLE/firewall index 5eae0f2a3..d9cb5dd97 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -926,7 +926,7 @@ log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates fo eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' ;; *) - eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-level $level --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' ;; esac @@ -943,7 +943,7 @@ log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates fo eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' ;; *) - eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-level $level --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' ;; esac diff --git a/STABLE/install.sh b/STABLE/install.sh index 09b6691a0..09c34d68f 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.4a +VERSION=1.4.4b usage() # $1 = exit status { diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 8fad31c0d..9f0f91acf 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.4a +%define version 1.4.4b %define release 1 %define prefix /usr @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Thu May 29 2003 Tom Eastep +- Changed version to 1.4.4b-1 * Tue May 27 2003 Tom Eastep - Changed version to 1.4.4a-1 * Thu May 22 2003 Tom Eastep diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index e38f3710d..d8cff3b55 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.4.4a +VERSION=1.4.4b usage() # $1 = exit status {