diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index 26a4781bd..5da5adc16 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -1,1267 +1,1285 @@ - + - + - + - + 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.

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

- + but it doesn't work.
+

+

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

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

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

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

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

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

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

- + written and how do I change the destination?

+

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

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

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

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

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

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

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

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

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

- + 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?
- + + 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. + 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?
+ 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?
+
+ 26. When I try to use any of +the SYN options in nmap on or behind the firewall, I get "operation + not permitted". How can I use nmap with Shorewall?"

- 26. When I try to use any of the -SYN options in nmap on or behind the firewall, I get "operation -not permitted". How can I use nmap with Shorewall?"
- -
+ 27. I am compiling a new kernel for my firewall. +What should I look out for?
+
+28. How do I use Shorewall as a Bridging Firewall?
+ +

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

- + my my personal PC with IP address 192.168.1.5. + I've looked everywhere and can't find how to do +it. +

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

- -
+ do port forwarding under Shorewall. The format + of a port-forwarding rule to a local system is as follows:

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

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

- -
+ the rule is:

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

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

- + but it doesn't work +

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

- + things:

+ - +

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

- Answer: To further - diagnose this problem:
- + 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?

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

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

-
- -
-
     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 - externally and internally using the same address.

- -

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

- -

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

- -

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

- -

In /etc/shorewall/interfaces:

- -
- - - - - - - - - - - - - - - - -
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255
-
-
- -

In /etc/shorewall/policy:

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

In /etc/shorewall/masq:

- -
- - - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
-
-
- -

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

- -

Answer: There is an H.323 connection - tracking/NAT module that may help with Netmeeting. - Look here for -a solution for MSN IM but be aware that there are significant security - risks involved with this solution. Also check the Netfilter -mailing list archives at http://www.netfilter.org. + upgrade to Shorewall 1.4.2 or later.

-

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

+

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:

+
+ +
+
     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 + externally and internally using the same address.

+ +

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

+ +

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

+ +

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

+ +

In /etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + +
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255
+
+
+ +

In /etc/shorewall/policy:

+ +
+ + + + + + + + + + + + + + + + +
SOURCE + DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT +
+
+
+ +

In /etc/shorewall/masq:

+ +
+ + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
+
+
+ +

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

+ +

Answer: There is an H.323 connection + tracking/NAT module that may help with Netmeeting. + Look here for + a solution for MSN IM but be aware that there are significant +security risks involved with this solution. Also check the Netfilter + mailing list archives at http://www.netfilter.org. +

+ +

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

+

Answer: The common.def included with version 1.3.x - always rejects connection requests on TCP -port 113 rather than dropping them. This is necessary - to prevent outgoing connection problems to services - that use the 'Auth' mechanism for identifying requesting - users. Shorewall also rejects TCP ports 135, 137 and -139 as well as UDP ports 137-139. These are ports that are + 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.

- + your ISP preventing you from running a web + server in violation of your Service Agreement.

+

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

- + firewall and it showed 100s of ports as open!!!! +

Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing - back from your firewall then it reports the port + 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 + 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

- + can't ping through the firewall +

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

- + for "ping",

+

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

- -
+
+ b) Be sure +that the first command in the file is ". /etc/shorewall/common.def"
+ c) Add the +following to /etc/shorewall/common

+ +

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

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

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

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

- + and how do I change the destination? +

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

- + When you have changed /etc/syslog.conf, be sure + to restart syslogd (on a RedHat system, "service syslog + restart").

+

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

- -
+ through settings + in /etc/shorewall/shorewall.conf -- If you want + to log all messages, set:

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

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

- + 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. + 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:
- + are flooding the logs with their connect requests. Can + i exclude these error messages for this port temporarily from +logging in Shorewall? + Temporarily add the following rule:
+ 
	DROP    net    fw    udp    10619
- +

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port. - They get dropped, but what the heck are they?

- + of these DROP messages from port 53 to some high numbered port. + They get dropped, but what the heck are they? + 
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:
- + Answer: There are two possibilities:
+
    -
  1. They are late-arriving replies to DNS -queries.
    2. -
  2. They are corrupted reply packets.
    3. - +
  3. They are late-arriving replies to DNS + queries.
    4. +
  4. They are corrupted reply packets.
    5. +
- You can distinguish the difference by setting - the logunclean option (logunclean option (/etc/shorewall/interfaces) on your external interface (eth0 in the above example). If they get - logged twice, they are corrupted. I solve this problem by using - an /etc/shorewall/common file like this:
- -
+ logged twice, they are corrupted. I solve this problem by using + an /etc/shorewall/common file like this:
+ +
#
# Include the standard common.def file
#
. /etc/shorewall/common.def
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
-
- The above file is also include in all of my -sample configurations available in the + 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.
- + 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:
- + 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
- + 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?

- + stop', I can't connect to anything. Why doesn't + that command work? +

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

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

+

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

- + I get messages about insmod failing -- what's wrong? +

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

- + this:

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

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

- -
+

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

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

- + for problems concerning the version of iptables + (v1.2.3) shipped with RH7.2.
+

+

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

- Answer: This is usually cured by the sequence of commands - shown above in FAQ #8 -
- + I get a message referring me to FAQ #8 + Answer: This is usually cured by the sequence of commands + shown above in FAQ #8 +
+

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

- + properly at startup? +

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

- -
+ I see the following:

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

Why can't Shorewall detect my interfaces properly?

-
- -
+
+ +

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

-
- +
+

10. What Distributions does it work with?

- +

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

- +

11. What Features does it have?

- +

Answer: See the Shorewall - Feature List.

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

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

- + (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 + and it has an internal web server that allows + me to configure/monitor it but as expected if I + enable rfc1918 blocking for my eth0 interface (the internet one), it also blocks the cable modems web server.

- +

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

- + that will let all traffic to and from the 192.168.100.1 + address of the modem in/out but still block all +other rfc1918 addresses?

+

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

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

- -
+ interface to correspond to the modem address, + you must also make an entry in /etc/shorewall/rfc1918 + for that address. For example, if you configure the address + 192.168.100.2 on your firewall, then you would add two entries + to /etc/shorewall/rfc1918:
+

+ +
- - - + - - - - + + - - - - + + - - - - + + + +
+
SUBNET
- 		+ TARGET
-
+
192.168.100.1
- 		+ RETURN
-
+
192.168.100.2
- 		+ RETURN
-
-
-
- -
+ +
+ +

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

-
- -
+
+ +

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

-
- + the IP address of your ISPs DHCP server.

+ +

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

- + the net +

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

- + the net", I wonder where the poster bought +computers with eyes and what those computers will +"see" when things are working properly. That aside, + the most common causes of this problem are:

+
    -
  1. - +
  2. +

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

    -
    3. -
  3. - + the IP address of the local firewall interface.

    +
    4. +
  4. +

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

    -
    5. -
  5. - + file is wrong or missing.

    +
    6. +
  6. +

    The DNS settings on the local systems are wrong or the - user is running a DNS server on the firewall - and hasn't enabled UDP and TCP port 53 from the - firewall to the internet.

    -
    7. - + user is running a DNS server on the firewall + and hasn't enabled UDP and TCP port 53 from +the firewall to the internet.

    + +
- +

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

- + all over my console making it unusable! +

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

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

+

17. How do I find out why this traffic is getting - logged?

- Answer: Logging - occurs out of a number of chains (as indicated in - the log message) in Shorewall:
- + logged? + Answer: Logging + occurs out of a number of chains (as indicated in + the log message) in Shorewall:
+
    -
  1. man1918 - or logdrop - The destination address is +
  2. man1918 + or logdrop - The destination address is listed in /etc/shorewall/rfc1918 with a logdrop target - -- see /etc/shorewall/rfc1918.
    3. -
  3. rfc1918 - or logdrop - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see /etc/shorewall/rfc1918.
    4. +
  4. rfc1918 + or logdrop - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
    5. -
  5. 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 +
  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 +
  8. <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.
    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 - interface option.
    11. -
  11. badpkt - - The packet is being logged under the dropunclean - interface option - as specified in the LOGUNCLEAN setting in rule that + includes a log level.
    12. +
  12. <interface>_mac + - The packet is being logged under the maclist + interface option.
    +
    13. +
  13. logpkt + - The packet is being logged under the logunclean + interface option.
    14. +
  14. badpkt + - The packet is being logged under the dropunclean + interface option + as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    15. -
  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 +
  18. blacklst + - The packet is being logged because the source IP + is blacklisted in the /etc/shorewall/blacklist + file.
    19. +
  19. 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.
    20. +
  20. 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.
    21. -
  21. logflags - The -packet is being logged because it failed the checks implemented +
  22. logflags - The + packet is being logged because it failed the checks implemented by the tcpflags interface option.
    -
    23. - + +
- +

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. - + with Shorewall, and maintain separate rulesets for + different IPs? + Answer: Yes. +See Shorewall and Aliased +Interfaces.

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

- You probably haven't set -TC_ENABLED=Yes in /etc/shorewall/shorewall.conf so -the contents of the tcrules file are simply being ignored.
- + but they don't seem to do anything. Why? + You probably haven't set + TC_ENABLED=Yes in /etc/shorewall/shorewall.conf so + the contents of the tcrules file are simply being ignored.
+

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

- Yes. Consult the
+ + 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?
-

- -
+ what are they?
+ + +
Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
     SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 
     [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
-
- 192.0.2.3 is external on my -firewall... 172.16.0.0/24 is my internal LAN
-
- 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 +
+ 192.0.2.3 is external on my + firewall... 172.16.0.0/24 is my internal LAN
+
+ Answer: While most +people associate the Internet Control Message Protocol +(ICMP) with 'ping', ICMP is a key piece of the internet. + ICMP is used to report problems back to the sender of a packet; +this is what is happening here. Unfortunately, where NAT is involved + (including SNAT, DNAT and Masquerade), there are a lot of broken + implementations. That is what you are seeing with these messages.
+
+ Here is my interpretation of + what is happening -- to confirm this analysis, one would + have to have packet sniffers placed a both ends of the connection.
+
+ Host 172.16.1.10 behind NAT +gateway 206.124.146.179 sent a UDP DNS query to 192.0.2.3 +and your DNS server tried to send a response (the response information + is in the brackets -- note source port 53 which marks this as + a DNS reply). When the response was returned to to 206.124.146.179, + it rewrote the destination IP TO 172.16.1.10 and forwarded the + packet to 172.16.1.10 who no longer had a connection on UDP port + 2857. This causes a port unreachable (type 3, code 3) to be generated + back to 192.0.2.3. As this packet is sent back through 206.124.146.179, + that box correctly changes the source address in the packet to 206.124.146.179 + but doesn't reset the DST IP in the original DNS response similarly. + When the ICMP reaches your firewall (192.0.2.3), your firewall has + no record of having sent a DNS reply to 172.16.1.10 so this ICMP +doesn't appear to be related to anything that was sent. The final + result is that the packet gets logged and dropped in the all2all chain. +I have also seen cases where the source IP in the ICMP itself isn't +set back to the external IP of the remote NAT gateway; that causes your firewall to log and drop the packet out of the rfc1918 chain because -the source IP is reserved by RFC 1918.
- + 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 + 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 @@ -1270,47 +1288,64 @@ use the -A command which adds the rules to the end of the chain. Most chains that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT rule and any rules that you add after that will be ignored. Check "man iptables" and look at the -I (--insert) command.
- +

23. Why do you use such ugly fonts on your - web site?

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

24. How can I allow conections to let's say - the ssh port only from specific IP Addresses on the -internet?

- In the SOURCE column of the rule, follow -"net" by a colon and a list of the host/subnet addresses as -a comma-separated list.
- + the ssh port only from specific IP Addresses on the + internet? + In the SOURCE column of the rule, follow + "net" by a colon and a list of the host/subnet addresses as + a comma-separated list.
+ 
    net:<ip1>,<ip2>,...
- Example:
- + Example:
+ 
    ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
- +
- +

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

- At the shell prompt, type:
-
- /sbin/shorewall version
- + I am running?
+ + At the shell prompt, type:
+
+ /sbin/shorewall version
+

26. When I try to use any of the SYN options -in nmap on or behind the firewall, I get "operation not permitted". How can -I use nmap with Shorewall?"

- Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" -then restart Shorewall.
-
- Last updated 7/5/2003 - Tom Eastep + in nmap on or behind the firewall, I get "operation not permitted". How can + I use nmap with Shorewall?" + Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" + then restart Shorewall.
+ +

27. I'm compiling a new kernel for my firewall. What should +I look out for?

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

28. How do I use Shorewall as a Bridging Firewall?
+

+ Basically, you don't. While there are kernel patches that allow you to route +bridge traffic through Netfilter, the environment is so different from the +Layer 3 firewalling environment that very little of Shorewall works. In fact, +so much of Shorewall doesn't work that my official position is that "Shorewall +doesn't work with Layer 2 Bridging".
+
+ Last updated 7/9/2003 - Tom Eastep

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

+

+
+


diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 0cb348f92..082effe75 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -5,6 +5,7 @@ + Shorewall News @@ -15,1455 +16,1608 @@ + + - + - + - + - + - + - - + + +
+ - +

Shorewall News Archive

-
- -

7/7/2003 - Shorewall-1.4.6 Beta 2

- + +

7/15/2003 - Shorewall-1.4.6 RC 1
+

+

Problems Corrected:
-

- +

+
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered start errors +
  2. A problem seen on RH7.3 systems where Shorewall encountered start errors when started using the "service" mechanism has been worked around.
    -
    -
    3. +
    +
  3. Where a list of IP addresses appears in the DEST column of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat table (one for each element in the list). Shorewall now correctly creates a single DNAT rule with multiple "--to-destination" clauses.
    -
    +
  4. Corrected a problem in Beta 1 where DNS names containing a "-" were mis-handled when they appeared in the DEST column of a rule.
    -
    5. +
    + +
  5. A number of problems with rule parsing have been corrected. Corrections +involve the handling of "z1!z2" in the SOURCE column as well as lists in +the ORIGINAL DESTINATION column.
    +
- +

Migration Issues:
-

+

+
  1. In earlier versions, an undocumented feature allowed entries in the host file as follows:
    -
    -    z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    -This capability was never documented and has been removed in 1.4.6 to allow +
    +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    +
    + This capability was never documented and has been removed in 1.4.6 to allow entries of the following format:
    -
    -    z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    2. +
    +     z   eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically -detected by Shorewall (see below).
    -
    3. + detected by Shorewall (see below).
    +
+

New Features:
-

- +

+
  1. A 'newnotsyn' interface option has been added. This option may be specified -in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for packets -arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address +in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for +packets arriving on the associated interface.
    +
    +
    3. +
  3. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    4. +
    +
  4. Shorewall can now add IP addresses to subnets other than the first one on an interface.
    -
    -
    5. +
    +
  5. DNAT[-] rules may now be used to load balance (round-robin) over a - set of servers. Servers may be specified in a range of addresses given -as <first address>-<last address>.
    -
    - Example:
    -
    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    6. -
  6. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, + set of servers. Servers may be specified in a range of addresses given as +<first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    +
    7. +
  7. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether these + capabilities are present in the current kernel. The output of the start, restart and check commands have been enhanced to report the outcome:
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    -
    -
    8. +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
  8. Support for the Connection Tracking Match Extension has been added. This extension is available in recent kernel/iptables releases and allows for rules which match against elements in netfilter's connection tracking table. Shorewall automatically detects the availability of this extension and reports its availability in the output of the start, restart and check commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall is changed - in the following ways:
    9. +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall is +changed in the following ways: -
  9. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) +
  10. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    +
  11. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -      ipcalc [ <address> <netmask> | <address>/<vlsm> +
    +       ipcalc [ <address> <netmask> | <address>/<vlsm> ]
    -
    -Examples:
    -
    -      [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    -      [root@wookie root]#
    -
    -      [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    -      [root@wookie root]#
    -
    -Warning:
    -
    -If your shell only supports 32-bit signed arithmatic (ash or dash), then -the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 -and for /1 networks. Bash should produce correct information for all valid -IP addresses.
    -
    -
    12. +
    + Examples:
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    + Warning:
    +
    + If your shell only supports 32-bit signed arithmatic (ash or dash), then + the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 + and for /1 networks. Bash should produce correct information for all valid + IP addresses.
    +
    +
  12. An 'iprange' command has been added to /sbin/shorewall.
    -
    -      iprange <address>-<address>
    -
    -This command decomposes a range of IP addressses into a list of network and -host addresses. The command can be useful if you need to construct an efficient -set of rules that accept connections from a range of network addresses.
    -
    -Note: If your shell only supports 32-bit signed arithmetic (ash or dash) +
    +       iprange <address>-<address>
    +
    + This command decomposes a range of IP addressses into a list of network +and host addresses. The command can be useful if you need to construct an +efficient set of rules that accept connections from a range of network addresses.
    +
    + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) then the range may not span 128.0.0.0.
    -
    -Example:
    -
    -      [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    -      192.168.1.4/30
    -      192.168.1.8/29
    -      192.168.1.16/28
    -      192.168.1.32/27
    -      192.168.1.64/26
    -      192.168.1.128/25
    -      192.168.2.0/23
    -      192.168.4.0/22
    -      192.168.8.0/22
    -      192.168.12.0/29
    -      192.168.12.8/31
    -      [root@gateway root]#
    -
    -
    13. -
  13. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    -
    -Example:
    -
    -    foo    eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    14. -
-

7/4/2003 - Shorewall-1.4.6 Beta 1

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered start -errors when started using the "service" mechanism has been worked around.
    -
    -
    2. -
  2. Where a list of IP addresses appears in the DEST column of a DNAT[-] - rule, Shorewall incorrectly created multiple DNAT rules in the nat table -(one for each element in the list). Shorewall now correctly creates a single -DNAT rule with multiple "--to-destination" clauses.
    -
    3. - -
- -

New Features:
-

- -
    -
  1. A 'newnotsyn' interface option has been added. This option may be -specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No -for packets arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address - ranges.
    -
    -
    3. -
  3. Shorewall can now add IP addresses to subnets other than the first - one on an interface.
    -
    -
    4. -
  4. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Up to 256 servers may be specified in a range of addresses - given as <first address>-<last address>.

    Example:

    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    - Note that this capability has previously been available using a combination - of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable - for load-balancing over a large number of servers (> 16) since specifying - a range in the DNAT rule causes one filter table ACCEPT rule to be generated - for each IP address in the range.
    +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    +       192.168.1.4/30
    +       192.168.1.8/29
    +       192.168.1.16/28
    +       192.168.1.32/27
    +       192.168.1.64/26
    +       192.168.1.128/25
    +       192.168.2.0/23
    +       192.168.4.0/22
    +       192.168.8.0/22
    +       192.168.12.0/29
    +       192.168.12.8/31
    +       [root@gateway root]#

    5. -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, -restart and check commands have been enhanced to report the outcome:
    +
  6. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    + Example:

    -
    7. -
  7. Support for the Connection Tracking Match Extension has been added. - This extension is available in recent kernel/iptables releases and allows - for rules which match against elements in netfilter's connection tracking - table. Shorewall automatically detects the availability of this extension - and reports its availability in the output of the start, restart and check - commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall is changed - in the following ways:
    8. - -
      - -
    - - -
  8. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    9. - +     foo    eth1:192.168.1.0/24,192.168.2.0/24
- -

6/17/2003 - Shorewall-1.4.5

+

7/7/2003 - Shorewall-1.4.6 Beta 2

-

Problems Corrected:
+

Problems Corrected:

    -
  1. The command "shorewall debug try <directory>" now correctly - traces the attempt.
    2. -
  2. The INCLUDE directive now works properly in the zones file; previously, - INCLUDE in that file was ignored.
    3. -
  3. /etc/shorewall/routestopped records with an empty second column -are no longer ignored.
    +
  4. A problem seen on RH7.3 systems where Shorewall encountered start +errors when started using the "service" mechanism has been worked around.
    +
    +
    5. +
  5. Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat table +(one for each element in the list). Shorewall now correctly creates a single +DNAT rule with multiple "--to-destination" clauses.
    +
    +
    6. +
  6. Corrected a problem in Beta 1 where DNS names containing a "-" were +mis-handled when they appeared in the DEST column of a rule.
    +
    7. + +
+ +

Migration Issues:
+

+ +
    +
  1. In earlier versions, an undocumented feature allowed entries in the +host file as follows:
    +
    +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    +
    + This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
    +
    +     z   eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    2. +
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed +from /etc/shorewall/shorewall.conf. These capabilities are now automatically +detected by Shorewall (see below).
    +
    3. + +
+ +

New Features:
+

+ +
    +
  1. A 'newnotsyn' interface option has been added. This option may be +specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No +for packets arriving on the associated interface.
    +
    +
    2. +
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address + ranges.
    +
    +
    3. +
  3. Shorewall can now add IP addresses to subnets other than the first + one on an interface.
    +
    +
    4. +
  4. DNAT[-] rules may now be used to load balance (round-robin) over a + set of servers. Servers may be specified in a range of addresses given as +<first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    +
    5. +
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether these + capabilities are present in the current kernel. The output of the start, +restart and check commands have been enhanced to report the outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    6. +
  6. Support for the Connection Tracking Match Extension has been added. + This extension is available in recent kernel/iptables releases and allows + for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall is +changed in the following ways:
    7. + + +
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    +
    8. +
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +       ipcalc [ <address> <netmask> | <address>/<vlsm> +]
    +
    + Examples:
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    + Warning:
    +
    + If your shell only supports 32-bit signed arithmatic (ash or dash), then +the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 +and for /1 networks. Bash should produce correct information for all valid +IP addresses.
    +
    +
    9. +
  9. An 'iprange' command has been added to /sbin/shorewall.
    +
    +       iprange <address>-<address>
    +
    + This command decomposes a range of IP addressses into a list of network +and host addresses. The command can be useful if you need to construct an +efficient set of rules that accept connections from a range of network addresses.
    +
    + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) +then the range may not span 128.0.0.0.
    +
    + Example:
    +
    +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    +       192.168.1.4/30
    +       192.168.1.8/29
    +       192.168.1.16/28
    +       192.168.1.32/27
    +       192.168.1.64/26
    +       192.168.1.128/25
    +       192.168.2.0/23
    +       192.168.4.0/22
    +       192.168.8.0/22
    +       192.168.12.0/29
    +       192.168.12.8/31
    +       [root@gateway root]#
    +
    +
    10. +
  10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    +
    + Example:
    +
    +     foo    eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    11. + +
+ +

7/4/2003 - Shorewall-1.4.6 Beta 1

+ +

Problems Corrected:
+

+ +
    +
  1. A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked around.
    +
    +
    2. +
  2. Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat table +(one for each element in the list). Shorewall now correctly creates a single +DNAT rule with multiple "--to-destination" clauses.
-

New Features:
+

New Features:

    -
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now - contain a list of addresses. If the list begins with "!' then the rule will - take effect only if the original destination address in the connection request - does not match any of the addresses listed.
    2. +
  2. A 'newnotsyn' interface option has been added. This option may be + specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
    +
    +
    3. +
  3. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address + ranges.
    +
    +
    4. +
  4. Shorewall can now add IP addresses to subnets other than the first + one on an interface.
    +
    +
    5. +
  5. DNAT[-] rules may now be used to load balance (round-robin) over +a set of servers. Up to 256 servers may be specified in a range of addresses + given as <first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    + Note that this capability has previously been available using a combination + of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable + for load-balancing over a large number of servers (> 16) since specifying + a range in the DNAT rule causes one filter table ACCEPT rule to be generated + for each IP address in the range.
    +
    +
    6. +
  6. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether these + capabilities are present in the current kernel. The output of the start, +restart and check commands have been enhanced to report the outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    7. +
  7. Support for the Connection Tracking Match Extension has been added. + This extension is available in recent kernel/iptables releases and allows + for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall is +changed in the following ways:
    8. + +
      + +
    + + +
  8. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
-

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

+

6/17/2003 - Shorewall-1.4.5

-

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and - iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems - have been encountered with this set of software. The Shorewall version -is 1.4.4b plus the accumulated changes for 1.4.5.
+

Problems Corrected:

+
    +
  1. The command "shorewall debug try <directory>" now correctly + traces the attempt.
    2. +
  2. The INCLUDE directive now works properly in the zones file; previously, + INCLUDE in that file was ignored.
    3. +
  3. /etc/shorewall/routestopped records with an empty second column +are no longer ignored.
    +
    4. + +
+ +

New Features:
+

+ +
    +
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now + contain a list of addresses. If the list begins with "!' then the rule will + take effect only if the original destination address in the connection request + does not match any of the addresses listed.
    2. + +
+ +

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

+ +

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and + iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems + have been encountered with this set of software. The Shorewall version is + 1.4.4b plus the accumulated changes for 1.4.5.
+

+

6/8/2003 - Updated Samples

- -

Thanks to Francesca Smith, the samples have been updated to Shorewall version -1.4.4.

- + +

Thanks to Francesca Smith, the samples have been updated to Shorewall +version 1.4.4.

+

5/29/2003 - Shorewall-1.4.4b

- -

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

- + +

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

+

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed - out that the code in 1.4.4 restricts the length of short zone names to - 4 characters. I've produced version 1.4.4a that restores the previous 5-character - limit by conditionally omitting the log rule number when the LOGFORMAT - 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

- 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 - 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), +
  3. 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.
    +
    +
    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 +  
    +        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 +
  2. (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
    3. -
  3. 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.
    -
    4. - +    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. 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:
- -
    -
  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:

- +     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. +
  2. There were several cases where Shorewall would fail to + remove a temporary directory from /tmp. These cases have been corrected.
    3. +
  3. 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.
    4. + +
+     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.
    +
- 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:
+ +

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 + 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 +
  2. 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.
    3. -
  3. Beginning with Shorewall 1.4.1, Shorewall will never - create rules to handle traffic from a group to itself.
    4. -
  4. A NONE policy is introduced in 1.4.1. When a policy +
  5. Beginning with Shorewall 1.4.1, Shorewall will +never create rules to handle traffic from a group to itself.
    6. +
  6. A NONE policy is introduced in 1.4.1. When a policy of NONE is specified from Z1 to Z2:
    7. - +
- + - See the upgrade issues - for a discussion of how these changes may affect your configuration. - + 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 + 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:
- +
+ 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:

- - - - - -

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 +
  3. The /etc/shorewall/shorewall.conf file +has been completely reorganized into logical sections.
    +
    +
    4. +
  4. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    5. +
  5. The firewall script and version file are + now installed in /usr/share/shorewall.
    +
    +
    6. +
  6. Late arriving DNS replies are now silently + dropped in the common chain by default.
    +
    +
    7. +
  7. 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.
    +
    +
    8. +
  8. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    9. +
  9. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
    +
    +
    10. +
  10. 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.
    +
    +
    11. +
  11. The /etc/shorewall/params file is now processed + first so that variables may be used in the /etc/shorewall/shorewall.conf + file.
    +
    +
    12. +
  12. Shorewall now gives a more helpful +diagnostic when the 'ipchains' compatibility kernel module is loaded +and a 'shorewall start' command is issued.
    +
    +
    13. +
  13. 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.
    +
    +
    14. +
  14. Shorewall now ignores 'default' routes when detecting + masq'd networks.
    15. + +
+ +

3/10/2003 - Shoreall 1.3.14a

+ +

A roleup of the following bug fixes and other updates:

+ + + + + +

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. 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 +  
    +    a) In the INTERFACE column of /etc/shorewall/masq
    +    b) In the INTERFACE column of /etc/shorewall/nat
    +  
    4. +
  4. Support for OpenVPN Tunnels.
    +
    +
    5. +
  5. Support for VLAN devices with names + of the form $DEV.$VID (e.g., eth0.0)
    +
    +
    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 +    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.
    -   
    +  
    + Example 1 -- This is how it works in + 1.3.14.
    +   
    - + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    - + 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    -  
    - When upgrading to Shorewall 1.3.14, -if you have multiple local subnets connected to an interface - that is specified in the SUBNET column of an /etc/shorewall/masq - entry, your /etc/shorewall/masq file will need changing. In -most cases, you will simply be able to remove redundant entries. In -some cases though, you might want to change from using the interface - name to listing specific subnetworks if the change described above will -cause masquerading to occur on subnetworks that you don't wish to masquerade.
    -  
    - Example 2 -- Suppose that your current - config is as follows:
    -   
    +  
    + When upgrading to Shorewall 1.3.14, +if you have multiple local subnets connected to an interface + that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In + most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above +will cause masquerading to occur on subnetworks that you don't wish +to masquerade.
    +  
    + Example 2 -- Suppose that your current + config is as follows:
    +   
    - + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, the second entry in -/etc/shorewall/masq is no longer required.
    -  
    - Example 3 -- What if your current configuration +  
    +    In this case, the second entry in + /etc/shorewall/masq is no longer required.
    +  
    + Example 3 -- What if your current configuration is like this?
    -  
    +  
    - + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, you would want to change - the entry in  /etc/shorewall/masq to:
    +  
    +    In this case, you would want to +change the entry in  /etc/shorewall/masq to:
    + + 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    +
    8. + +
+ +


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

+ +

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

+ +

Includes the Beta 2 content plus support for OpenVPN tunnels.

+ +

1/28/2003 - Shorewall 1.3.14-Beta2

+ +

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

+ +

1/25/2003 - Shorewall 1.3.14-Beta1
+

+ +

The Beta includes the following changes:
+

+ + +
    +
  1. An OLD_PING_HANDLING option has + been added to shorewall.conf. When set to Yes, Shorewall +ping handling is as it has always been (see http://www.shorewall.net/ping.html).
    +
    + When OLD_PING_HANDLING=No, icmp echo + (ping) is handled via rules and policies just like any +other connection request. The FORWARDPING=Yes option in shorewall.conf + and the 'noping' and 'filterping' options in /etc/shorewall/interfaces + will all generate an error.
    +
    +
    2. +
  2. It is now possible to direct +Shorewall to create a "label" such as  "eth0:0" for IP addresses +that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. + This is done by specifying the label instead of just the interface + name:
    +  
    +    a) In the INTERFACE column of /etc/shorewall/masq
    +    b) In the INTERFACE column of /etc/shorewall/nat
    +  
    3. +
  3. When an interface name is entered + in the SUBNET column of the /etc/shorewall/masq file, Shorewall + previously masqueraded traffic from only the first subnet + defined on that interface. It did not masquerade traffic from:
    +  
    +    a) The subnets associated with other + addresses on the interface.
    +    b) Subnets accessed through local + routers.
    +  
    + Beginning with Shorewall 1.3.14, if +you enter an interface name in the SUBNET column, shorewall +will use the firewall's routing table to construct the masquerading/SNAT + rules.
    +  
    + Example 1 -- This is how it works in + 1.3.14.
    +   
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    + + + + + 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    +  
    + When upgrading to Shorewall 1.3.14, +if you have multiple local subnets connected to an interface + that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In + most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above +will cause masquerading to occur on subnetworks that you don't wish +to masquerade.
    +  
    + Example 2 -- Suppose that your current + config is as follows:
    +   
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    +  
    +    In this case, the second entry in + /etc/shorewall/masq is no longer required.
    +  
    + Example 3 -- What if your current configuration + is like this?
    +  
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    +  
    +    In this case, you would want to +change the entry in  /etc/shorewall/masq to:
    + + + + 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    4. - + + +
- + +

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

- -

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

+ +

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 several DNAT rules that would generate the same ACCEPT rule.
    -
    -    Here are three rules from my +
  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 rules file:
    -
    -         DNAT   net  dmz:206.124.146.177 +
    +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    -         DNAT   net  dmz:206.124.146.177 +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
    -
    -    These three rules ended up generating - _three_ copies of
    -
    -          ACCEPT net  dmz:206.124.146.177 - tcp smtp
    -
    -    By writing the rules this way, +
    +    These three rules ended up generating + _three_ copies of
    +
    +          ACCEPT net  dmz:206.124.146.177 + tcp smtp
    +
    +    By writing the rules this way, I end up with only one copy of the ACCEPT rule.
    -
    -         DNAT-  net  dmz:206.124.146.177 +
    +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
    -         DNAT-  net  dmz:206.124.146.177 +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 +         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 +
    +
    4. +
  4. The 'shorewall check' command + now prints out the applicable policy between each pair of zones.
    -
    -
    5. -
  5. 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.
    -
    -
    6. -
  6. 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 +
    +
    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 -

+ +

1/6/2003 - BURNOUT +

- -

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

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

- +

-Tom Eastep
-

+

- +

12/30/2002 - Shorewall Documentation in PDF Format

- -

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

+ +

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

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

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

+ Features include:
- +
    -
  1. "shorewall refresh" - now reloads the traffic shaping rules (tcrules and +
  2. "shorewall refresh" + now reloads the traffic shaping rules (tcrules and tcstart).
    3. -
  3. "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.
    4. -
  4. "shorewall [re]start" - has been speeded up by more than 40% with my configuration. +
  5. "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.
    6. +
  6. "shorewall [re]start" + has been speeded up by more than 40% with my configuration. Your milage may vary.
    7. -
  7. A "shorewall show -classifiers" command has been added which shows the -current packet classification filters. The output from this +
  8. A "shorewall show +classifiers" command has been added which shows the +current packet classification filters. The output from this command is also added as a separate page in "shorewall monitor"
    9. -
  9. ULOG (must be all -caps) is now accepted as a valid syslog level and causes -the subject packets to be logged using the ULOG target rather - than the LOG target. This allows you to run ulogd (available -from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages ULOG (must be all +caps) is now accepted as a valid syslog level and causes +the subject packets to be logged using the ULOG target rather + than the LOG target. This allows you to run ulogd (available from + http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
    10. -
  10. If you are running -a kernel that has a FORWARD chain in the mangle table -("shorewall show mangle" will show you the chains in the mangle -table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. - This allows for marking input packets based on their destination +
  11. If you are running + a kernel that has a FORWARD chain in the mangle table + ("shorewall show mangle" will show you the chains in the +mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. + This allows for marking input packets based on their destination even when you are using Masquerading or SNAT.
    12. -
  12. I have cluttered up - the /etc/shorewall directory with empty 'init', 'start', - 'stop' and 'stopped' files. If you already have a file with - one of these names, don't worry -- the upgrade process won't - overwrite your file.
    13. +
  13. I have cluttered +up the /etc/shorewall directory with empty 'init', + 'start', 'stop' and 'stopped' files. If you already have a +file with one of these names, don't worry -- the upgrade process + won't overwrite your file.
    14. - +
- You may download the Beta + 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 +

+ Shorewall is at the +center of MandrakeSoft's recently-announced Multi + Network Firewall (MNF) product. Here is the press - release.
+ href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press + release.
- +

12/7/2002 - Shorewall Support for Mandrake 9.0

- -

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

+ +

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

- +

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

+

- +

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

- +

12/3/2002 - Shorewall 1.3.11a

- -

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

+ +

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

- +

11/24/2002 - Shorewall 1.3.11

- +

In this version:

- + - +

11/14/2002 - Shorewall Documentation in PDF Format

- -

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

+ +

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

-

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

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

9/28/2002 - Shorewall 1.3.9

+

10/23/2002 - Shorewall 1.3.10 Beta 1

+ In this version:
- -

In this version:
-

+ + + You may download + the Beta from:
- -

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

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

-

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

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

- A couple - of recent configuration changes at www.shorewall.net - had the negative effect of breaking the Search -facility:
- - -
    -
  1. Mailing - List Archive Search was not available.
    2. -
  2. The - Site Search index was incomplete
    3. -
  3. Only - one page of matches was presented.
    4. - - -
- Hopefully - these problems are now corrected.
- - -

9/18/2002 -  Debian 1.3.8 Packages Available
-

- - +

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

+ +

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

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

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

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

+ A +couple of recent configuration changes at www.shorewall.net + had the negative effect of breaking the Search + facility:
+ +
    + +
  1. Mailing List Archive Search was not available.
    2. + +
  2. The Site Search index was incomplete
    3. + +
  3. Only one page of matches was presented.
    4. + + +
+ Hopefully + these problems are now corrected.
+ + +

9/18/2002 -  Debian 1.3.8 Packages Available
+

+ + +

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

+ +

9/16/2002 - Shorewall 1.3.8

+

In this version:
-

+

+ + + +

7/16/2002 - New Mirror in Argentina

- -

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

+ +

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

- +

7/16/2002 - Shorewall 1.3.4 Released

- +

In this version:

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

    - + +
  • The "hits" command has been enhanced.
    • + + + +

    6/25/2002 - Samples Updated for 1.3.2

    - -

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

    + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    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:

    - + - +

    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 - problems have been corrected in the 1.3.1 samples.

    + +

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

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    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:

    - + - +

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

    + +

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

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

    - + - +

    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

    - + +
  • There is now a single RPM that also works + with SuSE.
    • + + + +

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

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

    Thanks, Lorenzo!

    - +

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

    - -

    Thanks to Stefan Mohr, there - is now a Shorewall 1.2.11 + +

    Thanks to Stefan Mohr, there + is now a Shorewall 1.2.11 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.  - Thanks Stefan!

    + 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 used in new Shorewall installations.

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

    - +

    4/2/2002 - Updated Log Parser

    - -

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

    + +

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

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

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

    + +

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

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

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

    - + +
  • Copyright notices have been added to the +documenation.
    • + + + +

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - - - -
  • Several bugs have been fixed
    • - -
  • The 1.2.9 Debian Package is also available - at http://security.dsi.unimi.it/~lorenzo/debian.html.
    • - - - - +

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

    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.

    + +

    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:

    - + +
  • A problem occurring when BLACKLIST_LOGLEVEL + was not set has been corrected.
    • + + + +

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - +

    see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/1/2002 - Shorewall 1.2.5 Released

    - -

    Due to installation problems with Shorewall 1.2.4, I have released Shorewall + +

    Due to installation problems with Shorewall 1.2.4, I have released Shorewall 1.2.5. Sorry for the rapid-fire development.

    - +

    In version 1.2.5:

    - + +
  • The default value of the STATEDIR variable + in /etc/shorewall/shorewall.conf has been changed + to /var/lib/shorewall in order to conform to the + GNU/Linux File Hierarchy Standard, Version 2.2.
    • -

    1/28/2002 - Shorewall 1.2.4 Released

    - - - - - + +

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

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

    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 + href="http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo for details.

    - +

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

    + href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni, a 1.2.2 + Shorewall Debian package is now available. + There is a link to Lorenzo's site from the +Shorewall download page.

    - +

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

    + href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version restores + the "shorewall status" command to health.

    - +

    1/8/2002 - Shorewall 1.2.2 Released

    - +

    In version 1.2.2

    - + - +

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

    + target="_blank">version 1.2.0) released. These are minor updates + to the previously-released samples. +There are two new rules added:

    - + - +

    See the README file for upgrade instructions.

    - +

    1/1/2002 - Shorewall Mailing List Moving

    - -

    The Shorewall mailing list hosted at - Sourceforge is moving to Shorewall.net. - If you are a current subscriber to the list -at Sourceforge, please see these instructions. - If you would like to subscribe to the new - list, visit The Shorewall mailing list hosted at + Sourceforge is moving to Shorewall.net. + If you are a current subscriber to the list + at Sourceforge, please see these instructions. + If you would like to subscribe to the +new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

    - +

    12/31/2001 - Shorewall 1.2.1 Released

    - +

    In version 1.2.1:

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

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

    - - - -

    Version 1.2 contains the following new features:

    - - - - - -

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

    + +

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

    - -

    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:

    + +

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

    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:

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">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 + +

    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 + href="http://www.nrg.sk/mirror/shorewall" target="_top">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. + +

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

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

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

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

    + +

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

    + +

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

    + +

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

    + +

    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

    + +

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

    - + +
  • The first line of "install.sh" has been corrected + -- I had inadvertently deleted the initial "#".
    • -

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

    + - + +

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

    + + + +
  • A couple of LRP-specific problems were corrected.
    • + + + +

    4/8/2001 - Shorewall is now affiliated with the Leaf Project -

    +

    - +

    4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

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

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

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

    - + +
  • The interface OPTIONS for "gw" interfaces + are no longer ignored.
    • -

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

    + - -

    Updated 7/7/2003 - Tom Eastep -

    + +

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

    - + +

    Updated 7/15/2003 - Tom Eastep +

    + + +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    -
    -
    -
    +

    diff --git a/Shorewall-docs/Shorewall_Doesnt.html b/Shorewall-docs/Shorewall_Doesnt.html new file mode 100644 index 000000000..9f55bd60f --- /dev/null +++ b/Shorewall-docs/Shorewall_Doesnt.html @@ -0,0 +1,50 @@ + + + + What Shorewall Cannot Do + + + + + + + + + + + + + + + + + + +
    +

    Some things that Shorewall + Cannot Do

    +
    +
    +     Shorewall cannot:
    + + +
    + Last updated 7/9/2003 - Tom Eastep + +

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

    +
    +
    + + diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm index 36bf45f58..c2cb321af 100644 --- a/Shorewall-docs/Shorewall_index_frame.htm +++ b/Shorewall-docs/Shorewall_index_frame.htm @@ -1,141 +1,145 @@ - + - + - + - + Shorewall Index - - + - + - - - + + - - - + + + - - - + + + +
    - +
    +

    Shorewall

    -
    - +
    + - + -
    - +

    Copyright © 2001-2003 Thomas M. Eastep.
    -

    +

    +
    diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm index cc4ad44d8..a1905c9e3 100644 --- a/Shorewall-docs/Shorewall_sfindex_frame.htm +++ b/Shorewall-docs/Shorewall_sfindex_frame.htm @@ -1,140 +1,144 @@ - + - + - + - + Shorewall Index - - + + - + - - - + + - - - + + + - - - + + + +
    - +
    +

    Shorewall

    -
    - +
    + - + -
    - +

    Copyright © 2001-2003 Thomas M. Eastep.
    -

    +

    +
    diff --git a/Shorewall-docs/mailing_list.htm b/Shorewall-docs/mailing_list.htm index bbe056d61..81d6b6a0e 100644 --- a/Shorewall-docs/mailing_list.htm +++ b/Shorewall-docs/mailing_list.htm @@ -1,153 +1,146 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - - - - +
    + + + + +
    - +
    +

    Vexira Logo -

    - + - - + +

      (Razor Logo) -

    -     		- +

    +     		+

    Shorewall Mailing Lists

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

    -
    -
    -
    - -

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

    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 +

    + +

    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 against Spamassassin (including Vipul's Razor).
      -
      2. -
    2. to ensure that the sender address is fully +
      3. +
    3. to ensure that the sender address is fully qualified.
      4. -
    4. to verify that the sender's domain has an -A or MX record in DNS.
      5. -
    5. to ensure that the host name in the HELO/EHLO - command is a valid fully-qualified DNS name that resolves.
      6. -
    6. to ensure that the sending system has a valid PTR record in DNS.
      7. - +
    7. to verify that the sender's domain has an + A or MX record in DNS.
      8. +
    8. to ensure that the host name in the HELO/EHLO + command is a valid fully-qualified DNS name that resolves.
      9. +
    -This last point is important. If you run your -own outgoing mail server and it doesn't have a valid DNS PTR record, your -email won't reach the lists unless/until the postmaster notices that your -posts are being rejected. To avoid this problem, you should configure your -MTA to forward posts to shorewall.net through an MTA that does have -a valid PTR record (such as the one at your ISP).
    - +

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

    Mailing Lists Archive Search

    - -
    - -

    Match: + + + +

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

    - - -

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

    - + + +

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

    +

    Shorewall CA Certificate

    - If you want to trust X.509 certificates issued - by Shoreline 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 + +

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

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

    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 +

    • + +

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

      • +
    • + +

      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 +

      • +
    • + +

      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 6/14/2003 - Last updated 7/7/2003 - Tom Eastep

    - -

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

    + +

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

    +
    diff --git a/Shorewall-docs/ping.html b/Shorewall-docs/ping.html index 47e4a6e2c..30f17ad53 100644 --- a/Shorewall-docs/ping.html +++ b/Shorewall-docs/ping.html @@ -2,191 +2,189 @@ ICMP Echo-request (Ping) - + - + - + - - - + + - - - + + + +
    +

    ICMP Echo-request (Ping)

    -
    -
    - Shorewall 'Ping' management has evolved over time with the latest change - coming in Shorewall version 1.4.0.
    - -

    Shorewall Versions >= 1.4.0

    -In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just -like any other connection request.
    -
    - In order to accept ping requests from zone z1 to zone z2 where the policy -for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the -form:
    - -
    ACCEPT    z1    z2    - icmp    8
    -
    - Example:
    -
    - To permit ping from the local zone to the firewall:
    - -
    ACCEPT    loc    fw    - icmp    8
    -
    - If you would like to accept 'ping' by default even when the relevant - policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't - already exist and in that file place the following command:
    - -
    - 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    -
    - With that rule in place, if you want to ignore 'ping' from z1 to z2 then - you need a rule of the form:
    - -
    DROP    z1    z2    - icmp    8
    -
    - Example:
    -
    - To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    -
    - -
    DROP    net    fw    - icmp    8
    -
    - -

    Shorewall Versions >= 1.3.14  and < 1.4.0 with OLD_PING_HANDLING=No -in /etc/shorewall/shorewall.conf

    - In 1.3.14, Ping handling was put under control of the rules and policies - just like any other connection request. In order to accept ping requests -from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you -need a rule in /etc/shoreall/rules of the form:
    - -
    ACCEPT    z1    z2    - icmp    8
    -
    - Example:
    -
    - To permit ping from the local zone to the firewall:
    - -
    ACCEPT    loc    fw    - icmp    8
    -
    - If you would like to accept 'ping' by default even when the relevant - policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't - already exist and in that file place the following command:
    - -
    - 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    -
    - With that rule in place, if you want to ignore 'ping' from z1 to z2 then - you need a rule of the form:
    - -
    DROP    z1    z2    - icmp    8
    -
    - Example:
    -
    - To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    - -
    DROP    net    fw    - icmp    8
    -
    - -
    - -

    Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
    -

    - There are several aspects to the old Shorewall Ping management:
    - -
      -
    1. The noping and filterping interface options in /etc/shorewall/interfaces.
      2. -
    2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
      3. -
    3. Explicit rules in /etc/shorewall/rules.
      4. - -
    - There are two cases to consider:
    - -
      -
    1. Ping requests addressed to the firewall itself; and
      2. -
    2. Ping requests being forwarded to another system. Included here -are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and -simple routing.
      3. - -
    - These cases will be covered separately.
    - -

    Ping Requests Addressed to the Firewall Itself

    - For ping requests addressed to the firewall, the sequence is as follows:
    - -
      -
    1. If neither noping nor filterping are specified for - the interface that receives the ping request then the request will be responded - to with an ICMP echo-reply.
      2. -
    2. If noping is specified for the interface that receives -the ping request then the request is ignored.
      3. -
    3. If filterping is specified for the interface then the request - is passed to the rules/policy evaluation.
      4. - -
    - -

    Ping Requests Forwarded by the Firewall

    - These requests are always passed to rules/policy evaluation.
    - -

    Rules Evaluation

    - Ping requests are ICMP type 8. So the general rule format is:
    -
    -     Target    Source    - Destination    icmp    8
    -
    - Example 1. Accept pings from the net to the dmz (pings are responded -to with an ICMP echo-reply):
    -
    -     ACCEPT    net    dmz    - icmp    8
    -
    - Example 2. Drop pings from the net to the firewall
    -
    -     DROP    net    fw    - icmp    8
    - -

    Policy Evaluation

    - If no applicable rule is found, then the policy for the source to the -destination is applied.
    - -
      -
    1. If the relevant policy is ACCEPT then the request is responded -to with an ICMP echo-reply.
      2. -
    2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf - then the request is responded to with an ICMP echo-reply.
      3. -
    3. Otherwise, the relevant REJECT or DROP policy is used and the -request is either rejected or simply ignored.
      4. - -
    - -

    Updated 5/4/2003 - Tom Eastep -

    - -

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


    -
    -
    -
    -
    + Shorewall 'Ping' management has evolved over time with the latest change + coming in Shorewall version 1.4.0. To find out which version of Shorewall +you are running, at a shell prompt type "/sbin/shorewall +version". If that command gives you an error, it's time to upgrade +since you have a very old version of Shorewall installed (1.2.4 or earlier).
    + +

    Shorewall Versions >= 1.4.0

    + In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just +like any other connection request.

    + In order to accept ping requests from zone z1 to zone z2 where the policy + for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the + form:
    + +
    ACCEPT    z1    z2    + icmp    8
    +
    + Example:
    +
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    + icmp    8
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    + 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 +then you need a rule of the form:
    + +
    DROP    z1    z2    + icmp    8
    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    +
    + +
    DROP    net    fw    + icmp    8
    +
    + +

    Shorewall Versions >= 1.3.14  and < 1.4.0 with OLD_PING_HANDLING=No +in /etc/shorewall/shorewall.conf

    + In 1.3.14, Ping handling was put under control of the rules and policies + just like any other connection request. In order to accept ping requests + from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you +need a rule in /etc/shoreall/rules of the form:
    + +
    ACCEPT    z1    z2    + icmp    8
    +
    + Example:
    +
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    + icmp    8
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    + 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 +then you need a rule of the form:
    + +
    DROP    z1    z2    + icmp    8
    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    + +
    DROP    net    fw    + icmp    8
    +
    + +
    + +

    Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
    +

    + There are several aspects to the old Shorewall Ping management:
    + +
      +
    1. The noping and filterping interface options in + /etc/shorewall/interfaces.
      2. +
    2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
      3. +
    3. Explicit rules in /etc/shorewall/rules.
      4. + +
    + There are two cases to consider:
    + +
      +
    1. Ping requests addressed to the firewall itself; and
      2. +
    2. Ping requests being forwarded to another system. Included here + are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP +and simple routing.
      3. + +
    + These cases will be covered separately.
    + +

    Ping Requests Addressed to the Firewall Itself

    + For ping requests addressed to the firewall, the sequence is as follows:
    + +
      +
    1. If neither noping nor filterping are specified +for the interface that receives the ping request then the request will +be responded to with an ICMP echo-reply.
      2. +
    2. If noping is specified for the interface that receives +the ping request then the request is ignored.
      3. +
    3. If filterping is specified for the interface then the +request is passed to the rules/policy evaluation.
      4. + +
    + +

    Ping Requests Forwarded by the Firewall

    + These requests are always passed to rules/policy evaluation.
    + +

    Rules Evaluation

    + Ping requests are ICMP type 8. So the general rule format is:
    +
    +     Target    Source    + Destination    icmp    8
    +
    + Example 1. Accept pings from the net to the dmz (pings are responded + to with an ICMP echo-reply):
    +
    +     ACCEPT    net    dmz    + icmp    8
    +
    + Example 2. Drop pings from the net to the firewall
    +
    +     DROP    net    fw    + icmp    8
    + +

    Policy Evaluation

    + If no applicable rule is found, then the policy for the source to the + destination is applied.
    + +
      +
    1. If the relevant policy is ACCEPT then the request is responded + to with an ICMP echo-reply.
      2. +
    2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf + then the request is responded to with an ICMP echo-reply.
      3. +
    3. Otherwise, the relevant REJECT or DROP policy is used and the +request is either rejected or simply ignored.
      4. + +
    + +

    Updated 7/7/2003 - Tom Eastep +

    + +

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

    diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index a7f339ac6..af54d4af8 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -3,111 +3,111 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - + - + - - + - + - + +
    + + - - + +
    - + - +

    Shorewall 1.4 "iptables made easy"

    -     		- + +

    (Shorewall Logo) -

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

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

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

    @@ -117,384 +117,409 @@ General Public License for more 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.
    +

    Looking for Information?

    - The Documentation -Index is a good place to start as is the Quick Search to your right. - + The Documentation + Index is a good place to start as is the Quick Search to your right. +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, the documentation on this site will not - apply directly to your setup. If you want to use the documentation - that you find here, you will want to consider uninstalling what you have - and installing a setup that matches the documentation on this site. - See the Two-interface QuickStart Guide + If so, the documentation on this site will not + apply directly to your setup. If you want to use the documentation + that you find here, you will want to consider uninstalling what you have + and installing a setup that matches the documentation on this site. + See the Two-interface QuickStart Guide for details.
    - +

    News

    - +

    +
      - +
    - -

    7/7/2003 - Shorewall-1.4.6 Beta 2 7/15/2003 - Shorewall-1.4.6 RC 1 (New) -
    -

    +

    +
    +

    http://shorewall.net/pub/shorewall/testing
    + ftp://shorewall.net/pub/shorewall/testing
    +

    +
    +

    Problems Corrected:
    -

    - +

    +
      -
    1. A problem seen on RH7.3 systems where Shorewall encountered start -errors when started using the "service" mechanism has been worked around.
      -
      -
      2. -
    2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat -table (one for each element in the list). Shorewall now correctly creates +
    3. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been worked +around.
      +
      +
      4. +
    4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat +table (one for each element in the list). Shorewall now correctly creates a single DNAT rule with multiple "--to-destination" clauses.
      -
      -
      5. -
    5. Corrected a problem in Beta 1 where DNS names containing a "-" +
      +
      6. +
    6. Corrected a problem in Beta 1 where DNS names containing a "-" were mis-handled when they appeared in the DEST column of a rule.
      -
      7. +
      + +
    7. A number of problems with rule parsing have been corrected. Corrections +involve the handling of "z1!z2" in the SOURCE column as well as lists in +the ORIGINAL DESTINATION column.
      +
      8. +
    - +

    Migration Issues:
    -

    - -
      -
    1. In earlier versions, an undocumented feature allowed entries -in the host file as follows:
      -
      -     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      -
      - This capability was never documented and has been removed in 1.4.6 to allow -entries of the following format:
      -
      -     z   eth1:192.168.1.0/24,192.168.2.0/24
      -
      -
      2. -
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically -detected by Shorewall (see below).
      -
      3. -
    - -

    New Features:

    - +
      -
    1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No -for packets arriving on the associated interface.
      +
    2. In earlier versions, an undocumented feature allowed entries +in the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24

      3. -
    3. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address +
    4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically + detected by Shorewall (see below).
      +
      5. + +
    + +

    New Features:
    +

    + +
      +
    1. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
      -
      -
      3. -
    3. Shorewall can now add IP addresses to subnets other than the +
      +
      4. +
    4. Shorewall can now add IP addresses to subnets other than the first one on an interface.
      +
      +
      5. +
    5. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      6. +
    6. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that detects whether +these capabilities are present in the current kernel. The output of the +start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      7. +
    7. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables releases and +allows for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall is +changed in the following ways:
      8. + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' filtering in +the filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; +one in the nat table and one in the filter table. If the Connection Tracking +Match Extension is available, the rule in the filter table is extended to +check that the original destination address was the same as specified (or +defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    8. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      9. +
    9. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> +]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), then + the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 + and for /1 networks. Bash should produce correct information for all valid + IP addresses.

      10. -
    10. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses given -as <first address>-<last address>.
      +
    11. An 'iprange' command has been added to /sbin/shorewall.
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of network +and host addresses. The command can be useful if you need to construct an +efficient set of rules that accept connections from a range of network addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) +then the range may not span 128.0.0.0.

      Example:

      -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#

      12. -
    12. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, -restart and check commands have been enhanced to report the outcome:
      +
    13. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

      - Shorewall has detected the following iptables/netfilter capabilities:
      -    NAT: Available
      -    Packet Mangling: Available
      -    Multi-port Match: Available
      - Verifying Configuration...
      + Example:

      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      14. -
    14. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases and -allows for rules which match against elements in netfilter's connection -tracking table. Shorewall automatically detects the availability of this -extension and reports its availability in the output of the start, restart -and check commands.
      -
      - Shorewall has detected the following iptables/netfilter capabilities:
      -    NAT: Available
      -    Packet Mangling: Available
      -    Multi-port Match: Available
      -    Connection Tracking Match: Available
      - Verifying Configuration...
      -
      - If this extension is available, the ruleset generated by Shorewall is changed - in the following ways:
      15. -
        -
      • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
        • -
      • Recall that Shorewall DNAT rules generate two netfilter rules; -one in the nat table and one in the filter table. If the Connection Tracking -Match Extension is available, the rule in the filter table is extended to -check that the original destination address was the same as specified (or -defaulted to) in the DNAT rule.
        -
        -
        • -
      -
    15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      -
      -
      16. -
    16. An 'ipcalc' command has been added to /sbin/shorewall.
      -
      -       ipcalc [ <address> <netmask> | <address>/<vlsm> -]
      -
      - Examples:
      -
      -       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      -          CIDR=192.168.1.0/24
      -          NETMASK=255.255.255.0
      -          NETWORK=192.168.1.0
      -          BROADCAST=192.168.1.255
      -       [root@wookie root]#
      -
      -       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      -          CIDR=192.168.1.0/24
      -          NETMASK=255.255.255.0
      -          NETWORK=192.168.1.0
      -          BROADCAST=192.168.1.255
      -       [root@wookie root]#
      -
      - Warning:
      -
      - If your shell only supports 32-bit signed arithmatic (ash or dash), then -the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 -and for /1 networks. Bash should produce correct information for all valid -IP addresses.
      -
      -
      17. -
    17. An 'iprange' command has been added to /sbin/shorewall.
      -
      -       iprange <address>-<address>
      -
      - This command decomposes a range of IP addressses into a list of network -and host addresses. The command can be useful if you need to construct an -efficient set of rules that accept connections from a range of network addresses.
      -
      - Note: If your shell only supports 32-bit signed arithmetic (ash or dash) -then the range may not span 128.0.0.0.
      -
      - Example:
      -
      -       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      -       192.168.1.4/30
      -       192.168.1.8/29
      -       192.168.1.16/28
      -       192.168.1.32/27
      -       192.168.1.64/26
      -       192.168.1.128/25
      -       192.168.2.0/23
      -       192.168.4.0/22
      -       192.168.8.0/22
      -       192.168.12.0/29
      -       192.168.12.8/31
      -       [root@gateway root]#
      -
      -
      18. -
    18. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
      -
      - Example:
      -
      -     foo    eth1:192.168.1.0/24,192.168.2.0/24
      -
      19. +
    +

    6/17/2003 - Shorewall-1.4.5

    - -

    Problems Corrected:
    -

    - -
      -
    1. The command "shorewall debug try <directory>" now - correctly traces the attempt.
      2. -
    2. The INCLUDE directive now works properly in the zones -file; previously, INCLUDE in that file was ignored.
      3. -
    3. /etc/shorewall/routestopped records with an empty second - column are no longer ignored.
      -
      4. - -
    - -

    New Features:
    -

    - -
      -
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule - may now contain a list of addresses. If the list begins with "!' then -the rule will take effect only if the original destination address in -the connection request does not match any of the addresses listed.
      2. - -
    - -

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 -

    -

    The firewall at shorewall.net has been upgraded to the 2.4.21 kernel - and iptables 1.2.8 (using the "official" RPM from netfilter.org). No -problems have been encountered with this set of software. The Shorewall -version is 1.4.4b plus the accumulated changes for 1.4.5.
    +

    Problems Corrected:

    +
      +
    1. The command "shorewall debug try <directory>" now + correctly traces the attempt.
      2. +
    2. The INCLUDE directive now works properly in the zones +file; previously, INCLUDE in that file was ignored.
      3. +
    3. /etc/shorewall/routestopped records with an empty second + column are no longer ignored.
      +
      4. + +
    + +

    New Features:
    +

    + +
      +
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] +rule may now contain a list of addresses. If the list begins with "!' +then the rule will take effect only if the original destination address +in the connection request does not match any of the addresses listed.
      2. + +
    + +

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 +

    + +

    The firewall at shorewall.net has been upgraded to the 2.4.21 kernel + and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems + have been encountered with this set of software. The Shorewall version + is 1.4.4b plus the accumulated changes for 1.4.5.
    +

    +

    6/8/2003 - Updated Samples

    -

    Thanks to Francesca Smith, the samples have been updated to Shorewall - version 1.4.4.

    + +

    Thanks to Francesca Smith, the samples have been updated to Shorewall + version 1.4.4.

    +

    - +
      - + +
    - + +

    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.4.2 and Kernel-2.4.20. You - can find their work at: Jacques Nilo and Eric Wolzak + have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.4.2 and Kernel-2.4.20. You + can find their work at: http://leaf.sourceforge.net/devel/jnilo
    -

    +

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

    Donations

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

    Quick Search
    - -

    - +

    + - +

    Extended Search

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

    (Starlight Logo) -

    +

    - +


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

    Updated 7/15/2003 - Tom Eastep
    -

    +

    +
    diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm index a23d64d03..98ca67d23 100644 --- a/Shorewall-docs/shoreline.htm +++ b/Shorewall-docs/shoreline.htm @@ -1,135 +1,137 @@ - + About the Shorewall Author - + + - + - + - + - - - + + - - - + + + +
    - +
    +

    Tom Eastep

    -
    - +

    Tom - June 2003 -

    - + alt="Aging Geek - June 2003" width="320" height="240"> +

    +

    Tom -- June 2003
    -
    -

    - +
    +

    + - -

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

    + +

    Last updated 7/14/2003 - Tom Eastep

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

    diff --git a/Shorewall-docs/shorewall_prerequisites.htm b/Shorewall-docs/shorewall_prerequisites.htm index 8d8aa82e3..1b52d32bb 100644 --- a/Shorewall-docs/shorewall_prerequisites.htm +++ b/Shorewall-docs/shorewall_prerequisites.htm @@ -1,78 +1,80 @@ - + - + - + - + Shorewall Prerequisites - + - - - + + - - - + + + +
    +

    Shorewall Requirements

    -
    -
    - Shorewall Requires:
    - +
    + Shorewall Requires:
    +
      -
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20. - With current releases of Shorewall, Traffic Shaping/Control requires at -least 2.4.18.  Check here for kernel configuration - information. If you are looking for a firewall for use with - 2.2 kernels, see the Seattle -Firewall site .
      • -
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The - buggy iptables version 1.2.3 is included in RedHat 7.2 and you should - upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 - is available from RedHat +
    • A kernel that supports netfilter. I've tested with 2.4.2 - +2.4.20. With current releases of Shorewall, Traffic Shaping/Control requires +at least 2.4.18.  Check here for kernel +configuration information. If you are looking for a firewall +for use with 2.2 kernels, see + the Seattle Firewall site .
      • +
    • iptables 1.2 or later but beware version 1.2.3 -- see the + Errata. WARNING: + The buggy iptables version 1.2.3 is included in RedHat +7.2 and you should upgrade to iptables 1.2.4 prior to installing Shorewall. +Version 1.2.4 is available from RedHat and in the Shorewall Errata.
      • -
    • Iproute ("ip" utility). The iproute package is included -with most distributions but may not be installed by default. The official +
    • Iproute ("ip" utility). The iproute package is included + with most distributions but may not be installed by default. The official download site is ftp://ftp.inr.ac.ru/ip-routing. + target="_blank"> ftp://ftp.inr.ac.ru/ip-routing.
      • -
    • A Bourne shell or derivative such as bash or ash. This shell -must have correct support for variable expansion formats ${variable%pattern - }, ${variable%%pattern}, ${variable#pattern +
    • A Bourne shell or derivative such as bash or ash. This shell + must have correct support for variable expansion formats ${variable%pattern + }, ${variable%%pattern}, ${variable#pattern } and ${variable##pattern}.
      • -
    • Must produce a sensible result when a number n (128 <= n <= 255) -is left shifted by 24 bits. You can check this at a shell prompt by:
      • - +
    • Your shell must produce a sensible result when a number n (128 <= +n <= 255) is left shifted by 24 bits. You can check this at a shell prompt +by:
      • +
        -
      • echo $((128 << 24))
        -
        • -
      • The result must be either 2147483648 or -2147483648.
        -
        • - +
      • echo $((128 << 24))
        +
        • +
      • The result must be either 2147483648 or -2147483648.
        +
        • +
      -
    • The firewall monitoring display is greatly improved if you have - awk (gawk) installed.
      • - +
    • The firewall monitoring display is greatly improved if you +have awk (gawk) installed.
      • +
    - -

    Last updated 7/4/2003 - Last updated 7/8/2003 - Tom Eastep

    - +

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

    -
    +
    +



    diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 7d0b069d3..ab8b6ef7f 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -3,556 +3,575 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - + - + - - + + + + + + + +
    - + + + + + +

    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

    - -

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

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

    Looking for Information?

    - The Documentation -Index is a good place to start as is the Quick Search to your right. - + The Documentation + Index is a good place to start as is the Quick Search to your right. +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, the documentation on this site will not - apply directly to your setup. If you want to use the documentation - that you find here, you will want to consider uninstalling what you have - and installing a setup that matches the documentation on this site. - See the Two-interface QuickStart Guide - for details. + If so, the documentation on this site will +not apply directly to your setup. If you want to use the documentation + that you find here, you will want to consider uninstalling what you have + and installing a setup that matches the documentation on this site. + See the Two-interface QuickStart Guide + for details.

    - +

    News

    -

    7/7/2003 - Shorewall-1.4.6 Beta 2 7/15/2003 - Shorewall-1.4.6 RC 1 (New)
    -

    - +

    +
    http://shorewall.net/pub/shorewall/testing
    +ftp://shorewall.net/pub/shorewall/testing
    +

    Problems Corrected:
    -

    - +

    +
      -
    1. A problem seen on RH7.3 systems where Shorewall encountered start -errors when started using the "service" mechanism has been worked around.
      -
      -
      2. -
    2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat -table (one for each element in the list). Shorewall now correctly creates +
    3. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been worked +around.
      +
      +
      4. +
    4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat +table (one for each element in the list). Shorewall now correctly creates a single DNAT rule with multiple "--to-destination" clauses.
      -
      -
      5. -
    5. Corrected a problem in Beta 1 where DNS names containing a "-" +
      +
      6. +
    6. Corrected a problem in Beta 1 where DNS names containing a "-" were mis-handled when they appeared in the DEST column of a rule.
      +
      +
      7. +
    7. A number of problems with rule parsing have been corrected. +Corrections involve the handling of "z1!z2" in the SOURCE column as well +as lists in the ORIGINAL DESTINATION column.
      8. +
    - +

    Migration Issues:
    -

    - -
      -
    1. In earlier versions, an undocumented feature allowed entries -in the host file as follows:
      -
      -     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      -
      - This capability was never documented and has been removed in 1.4.6 to allow -entries of the following format:
      -
      -     z   eth1:192.168.1.0/24,192.168.2.0/24
      -
      -
      2. -
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically -detected by Shorewall (see below).
      -
      3. -
    - -

    New Features:

    - +
      -
    1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No -for packets arriving on the associated interface.
      +
    2. In earlier versions, an undocumented feature allowed entries +in the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24

      3. -
    3. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address +
    4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically + detected by Shorewall (see below).
      +
      5. + +
    + +

    New Features:
    +

    + +
      +
    1. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
      -
      -
      3. -
    3. Shorewall can now add IP addresses to subnets other than the +
      +
      4. +
    4. Shorewall can now add IP addresses to subnets other than the first one on an interface.
      +
      +
      5. +
    5. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      6. +
    6. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that detects whether +these capabilities are present in the current kernel. The output of the +start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      7. +
    7. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables releases and +allows for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall is +changed in the following ways:
      8. + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' filtering in +the filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; +one in the nat table and one in the filter table. If the Connection Tracking +Match Extension is available, the rule in the filter table is extended to +check that the original destination address was the same as specified (or +defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    8. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      9. +
    9. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> +]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), then + the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 + and for /1 networks. Bash should produce correct information for all valid + IP addresses.

      10. -
    10. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses given -as <first address>-<last address>.
      +
    11. An 'iprange' command has been added to /sbin/shorewall.
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of network +and host addresses. The command can be useful if you need to construct an +efficient set of rules that accept connections from a range of network addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) +then the range may not span 128.0.0.0.

      Example:

      -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#

      12. -
    12. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, -restart and check commands have been enhanced to report the outcome:
      +
    13. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

      - Shorewall has detected the following iptables/netfilter capabilities:
      -    NAT: Available
      -    Packet Mangling: Available
      -    Multi-port Match: Available
      - Verifying Configuration...
      + Example:

      -
      14. -
    14. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases and -allows for rules which match against elements in netfilter's connection -tracking table. Shorewall automatically detects the availability of this -extension and reports its availability in the output of the start, restart -and check commands.
      -
      - Shorewall has detected the following iptables/netfilter capabilities:
      -    NAT: Available
      -    Packet Mangling: Available
      -    Multi-port Match: Available
      -    Connection Tracking Match: Available
      - Verifying Configuration...
      -
      - If this extension is available, the ruleset generated by Shorewall is changed - in the following ways:
      15. -
        -
      • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
        • -
      • Recall that Shorewall DNAT rules generate two netfilter rules; -one in the nat table and one in the filter table. If the Connection Tracking -Match Extension is available, the rule in the filter table is extended to -check that the original destination address was the same as specified (or -defaulted to) in the DNAT rule.
        -
        -
        • -
      -
    15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      -
      -
      16. -
    16. An 'ipcalc' command has been added to /sbin/shorewall.
      -
      -       ipcalc [ <address> <netmask> | <address>/<vlsm> -]
      -
      - Examples:
      -
      -       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      -          CIDR=192.168.1.0/24
      -          NETMASK=255.255.255.0
      -          NETWORK=192.168.1.0
      -          BROADCAST=192.168.1.255
      -       [root@wookie root]#
      -
      -       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      -          CIDR=192.168.1.0/24
      -          NETMASK=255.255.255.0
      -          NETWORK=192.168.1.0
      -          BROADCAST=192.168.1.255
      -       [root@wookie root]#
      -
      - Warning:
      -
      - If your shell only supports 32-bit signed arithmatic (ash or dash), then -the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 -and for /1 networks. Bash should produce correct information for all valid -IP addresses.
      -
      -
      17. -
    17. An 'iprange' command has been added to /sbin/shorewall.
      -
      -       iprange <address>-<address>
      -
      - This command decomposes a range of IP addressses into a list of network -and host addresses. The command can be useful if you need to construct an -efficient set of rules that accept connections from a range of network addresses.
      -
      - Note: If your shell only supports 32-bit signed arithmetic (ash or dash) -then the range may not span 128.0.0.0.
      -
      - Example:
      -
      -       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      -       192.168.1.4/30
      -       192.168.1.8/29
      -       192.168.1.16/28
      -       192.168.1.32/27
      -       192.168.1.64/26
      -       192.168.1.128/25
      -       192.168.2.0/23
      -       192.168.4.0/22
      -       192.168.8.0/22
      -       192.168.12.0/29
      -       192.168.12.8/31
      -       [root@gateway root]#
      -
      -
      18. -
    18. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
      -
      - Example:
      -
      -     foo    eth1:192.168.1.0/24,192.168.2.0/24
      19. +     foo    eth1:192.168.1.0/24,192.168.2.0/24 +
    - +
      - +
    - +

    6/17/2003 - Shorewall-1.4.5

    - +

    Problems Corrected:
    -

    - +

    +
      -
    1. The command "shorewall debug try <directory>" now +
    2. The command "shorewall debug try <directory>" now correctly traces the attempt.
      3. -
    3. The INCLUDE directive now works properly in the zones +
    4. The INCLUDE directive now works properly in the zones file; previously, INCLUDE in that file was ignored.
      5. -
    5. /etc/shorewall/routestopped records with an empty second - column are no longer ignored.
      -
      6. - +
    6. /etc/shorewall/routestopped records with an empty second + column are no longer ignored.
      +
      7. +
    - +

    New Features:
    -

    - +

    +
      -
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule - may now contain a list of addresses. If the list begins with "!' then -the rule will take effect only if the original destination address in -the connection request does not match any of the addresses listed.
      2. - +
    2. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] +rule may now contain a list of addresses. If the list begins with "!' +then the rule will take effect only if the original destination address +in the connection request does not match any of the addresses listed.
      3. +
    - -

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 + +

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

    - The firewall at shorewall.net has been upgraded to the 2.4.21 kernel - and iptables 1.2.8 (using the "official" RPM from netfilter.org). No -problems have been encountered with this set of software. The Shorewall -version is 1.4.4b plus the accumulated changes for 1.4.5. - + The firewall at shorewall.net has been upgraded to the 2.4.21 +kernel and iptables 1.2.8 (using the "official" RPM from netfilter.org). +No problems have been encountered with this set of software. The Shorewall +version is 1.4.4b plus the accumulated changes for 1.4.5. +

    6/8/2003 - Updated Samples

    - -

    Thanks to Francesca Smith, the samples have been updated to Shorewall - version 1.4.4.

    - + +

    Thanks to Francesca Smith, the samples have been updated to Shorewall + version 1.4.4.

    + +

    - +
      - +
    - +

    - +

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

    - + - +

    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.4.2 and Kernel-2.4.20. You - can find their work at: Jacques Nilo and Eric Wolzak + have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.4.2 and Kernel-2.4.20. +You can find their work at: http://leaf.sourceforge.net/devel/jnilo

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

    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 + 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 + Shorewall is free but if you try it + and find it useful, please consider making a donation + to Starlight Children's Foundation. Thanks!

    -
    - -

    Updated 7/7/2003 - Tom Eastep -
    + +

    Updated 7/15/2003 - Tom Eastep +

    diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 6367fef2a..ccdca78a0 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,84 +1,84 @@ - + - + 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. -
      -
    • Shorewall versions -earlier that 1.3.0 are no longer supported.
      -
      • -
    • More than half of the questions posted on the support - list have answers directly accessible from the Documentation - Index
      -
      • -
    • - The FAQ -has solutions to more than 20 common problems. -
      • -
    • -The Troubleshooting - Information contains a number of tips to -help you solve common problems.
      • -
    • The - Errata has links - to download updated components.
      • -
    • -The Site and Mailing List Archives search facility can -locate documents and posts about similar problems: -
      • - -
    - -

    Site and Mailing List Archive Search

    - -
    -
    Match: + - +There are a number of sources of Shorewall information. Please + try these before you post. +
      +
    • Shorewall versions +earlier that 1.3.0 are no longer supported.
      +
      • +
    • More than half of the questions posted on the support + list have answers directly accessible from the Documentation + Index
      +
      • +
    • + The FAQ + has solutions to more than 20 common problems. +
      • +
    • + The Troubleshooting + Information contains a number of tips to +help you solve common problems.
      • +
    • +The Errata +has links to download updated components.
      • +
    • + The Site and Mailing List Archives search facility can +locate documents and posts about similar problems: +
      • + +
    + +

    Site and Mailing List Archive Search

    + +
    + 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 include this information:
      • - -
    - -
      - -
        -
      • the exact version of Shorewall - you are running.
        -
        - shorewall - version
        -
        -
        • - -
      - -
        - + -
      - -
        -
      • the complete, exact output - of
        -
        - ip - addr show
        -
        -
        • - -
      - -
        -
      • the complete, exact output - of
        -
        - ip - route show
        -
        • - -
      - -
        - - -
      - -
    -
      - +
    • 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:
      • + +
    + +
      +
        -
      • THIS IS IMPORTANT!
        -
        -         If your problem is that some type of connection -to/from or through your firewall isn't working then please:
        -
        -1. /sbin/shorewall reset
        -
        - 2. Try making the connection that is failing.
        -
        - 3. /sbin/shorewall -status > /tmp/status.txt
        -
        - 4. Post the /tmp/status.txt file as an attachment.
        -
        -
        • -
      • the exact wording of any the exact version of Shorewall + you are running.
        +
        + shorewall + version
        +
        +
        • + +
      + +
        + + +
      + +
        +
      • the complete, exact output + of
        +
        + ip + addr show
        +
        +
        • + +
      + +
        +
      • the complete, exact output + of
        +
        + ip + route show
        +
        • + +
      + +
        + + +
      + +
    + +
      + +
        +
      • THIS IS +IMPORTANT! If your problem +is that some type of connection to/from or through your firewall isn't working +then please perform the following four steps:
        +
        + 1. /sbin/shorewall reset
        +
        + 2. Try making the connection that is failing.
        +
        + 3. /sbin/shorewall + status > /tmp/status.txt
        +
        + 4. Post the /tmp/status.txt file as an attachment +(you may compress it if you like).
        +
        +
        • +
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart +
        +
        • +
      • If you installed Shorewall using one of the QuickStart Guides, please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using +
        +
        • +
      • 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 +
    • 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.
      • - +
      + +
    • 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 + +
    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.
    -
    - If you run your own outgoing mail server - and it doesn't have a valid DNS PTR record, your email won't reach the lists - unless/until the postmaster notices that your posts are being rejected. To - avoid this problem, you should configure your MTA to forward posts to shorewall.net - through an MTA that does have a valid PTR record (such as the one -at your ISP).
    -
    - + +
    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.
    +
    + If you run your own outgoing mail server + and it doesn't have a valid DNS PTR record, your email won't reach the lists + unless/until the postmaster notices that your posts are being rejected. +To avoid this problem, you should configure your MTA to forward posts to +shorewall.net through an MTA that does have a valid PTR record (such +as the one at your ISP).
    +
    +

    Where to Send your Problem Report or to Ask for Help

    - -
    + +

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

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

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

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

    +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users - .
    -

    -
    - + href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users + .
    +

    +
    +

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

    - -

    Last Updated 7/6/2003 - Tom Eastep

    - +

    + +

    Last Updated 7/9/2003 - Tom Eastep

    +

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

    -
    -
    +

    diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh index c28c9dd1a..57f79d550 100755 --- a/Shorewall/fallback.sh +++ b/Shorewall/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.6Beta2 +VERSION=1.4.6RC1 usage() # $1 = exit status { diff --git a/Shorewall/install.sh b/Shorewall/install.sh index 133f2fb85..7b034d70a 100755 --- a/Shorewall/install.sh +++ b/Shorewall/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.6Beta2 +VERSION=1.4.6RC1 usage() # $1 = exit status { diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec index 5790cb91f..2d27b5060 100644 --- a/Shorewall/shorewall.spec +++ b/Shorewall/shorewall.spec @@ -1,6 +1,6 @@ %define name shorewall %define version 1.4.6 -%define release 0Beta2 +%define release 0RC1 %define prefix /usr Summary: Shoreline Firewall is an iptables-based firewall for Linux systems. @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Mon Jul 14 2003 Tom Eastep +- Changed version to 1.4.6-0RC1 * Mon Jul 07 2003 Tom Eastep - Changed version to 1.4.6-0Beta2 * Fri Jul 04 2003 Tom Eastep diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh index 1bcb70fea..2c626790f 100755 --- a/Shorewall/uninstall.sh +++ b/Shorewall/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.4.6Beta2 +VERSION=1.4.6RC1 usage() # $1 = exit status {