diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 6156439da..6330272b5 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,18 +1,44 @@ -Changes since 1.3.8 +Changes since 1.3.9 -1. DNAT rules that remap a port but leave the IP address unchanged are - now handled properly. +1. Fix dumb bug in 1.3.9 Tunnel Handling. -2. The use of shell variables in the LOG LEVEL or SYNPARMS columns of - the policy file now works correctly. +2. First implementaiton of dynamic zones. -3. Added support for /etc/shorewall/startup_disabled. +3. Corrections to Dynamic Zones. -4. Added support for DNS names in config files. +4. More fixes for Dynamic Zones. -5. Don't insist on state NEW for protocols other than tcp, udp and - icmp. Workaround for conntrack glitches in other protocols. +5. Correct a typo in an error message. -6. Move 'functions', 'version' and 'firewall' to /usr/lib/shorewall. +6. Fix rule insertion algorithms for Dynamic Zones. + +7. Optimize dynamic zones code + +8. Remove iptables 1.2.7 hacks. + +9. Fix dumb typo in 1.3.9 (recalculate_interfacess) + +10. Add PATH assignment to the install script + +11. Correct 'functions' file handling in the install script. + +12. Add ipsecnat tunnel type. + +13. Correct typo in the shorewall.spec file. + +14. Add support for PPTP client and server to the tunnels file. + +15. Move the main firewall script to /usr/lib/shorewall + +16. Allow SNAT using primary IP and ADD_SNAT_ALIASES=Yes + +17. Add MAC verificaiton + +18. Conserve space by removing comment decorations. + +19. Improve comments in interfaces file re: use of aliases + +20. Clear nat and mangle counters during 'shorewall reset' + +21. Verify interface names in the SOURCE column of /etc/shorewall/tcrules -7. Fix problems with oddball shells. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index c6b44de34..5bc38e28f 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,1103 +1,1132 @@ - + - + - + Shorewall 1.3 Documentation - - + - + - + - - - + + - - - -
+

Shorewall 1.3 Reference

-
- -

This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall in common setups - may be found in the QuickStart - Guides.

- -

Components

- -

Shorewall consists of the following components:

+ + + + + +

This documentation is intended primarily for reference. + Step-by-step instructions for configuring Shorewall in common setups + may be found in the QuickStart + Guides.

+ +

Components

+ +

Shorewall consists of the following components:

+ - +

/etc/shorewall/params

- +

You may use the file /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.

- + that you can then use in some of the other configuration files.

+

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

- + within the Shorewall programs

+

Example:

- +
 	NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,norfc1918
- +

Example (/etc/shorewall/interfaces record):

- +
	net $NET_IF $NET_BCAST $NET_OPTIONS
- +

The result will be the same as if the record had been written

- +
	net eth0 130.252.100.255 noping,norfc1918
- +

Variables may be used anywhere in the other configuration - files.

- + files.

+

/etc/shorewall/zones

- +

This file is used to define the network zones. There is one entry - in /etc/shorewall/zones for each zone; Columns in an entry are:

- + in /etc/shorewall/zones for each zone; Columns in an entry are:

+ - +

The /etc/shorewall/zones file released with Shorewall is as follows:

- + - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - - + +
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
- +

You may add, delete and modify entries in the /etc/shorewall/zones file - as desired so long as you have at least one zone defined.

- + as desired so long as you have at least one zone defined.

+

Warning 1: If you rename or delete a zone, you should perform "shorewall - stop; shorewall start" to install the change rather than "shorewall restart".

- + stop; shorewall start" to install the change rather than "shorewall restart".

+

Warning 2: The order of entries in the /etc/shorewall/zones file is - significant in some cases.

- + significant in some cases.

+

/etc/shorewall/interfaces

- +

This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There will be one entry in /etc/shorewall/interfaces - for each of your interfaces. Columns in an entry are:

- + interfaces are connected to which zone. There will be one entry in +/etc/shorewall/interfaces for each of your interfaces. Columns in an entry + are:

+ - -

Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local network and eth0 - gets its IP address via DHCP. You want to ignore ping requests from the - internet and you want to check all packets entering from - the internet against the black list. - Your /etc/shorewall/interfaces file would be as follows:

-
- - - - - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918,blacklist
loceth1detect 
-
+

Example 1: You have a conventional firewall setup in which eth0 connects + to a Cable or DSL modem and eth1 connects to your local network and eth0 + gets its IP address via DHCP. You want to ignore ping requests from the + internet and you want to check all packets entering from + the internet against the black list. + Your /etc/shorewall/interfaces file would be as follows:

-

Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:

- - -
+
- + - - - - - - - - - - - + + + + + + + + + + + + + + + + + - +
ZONE INTERFACE BROADCAST OPTIONS
netppp0  
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918,blacklist
loceth1detect 
-
+
- -

Example 3: You have local interface eth1 with two IP - addresses - 192.168.1.1/24 and 192.168.12.1/24

- -
+ +

Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:

+ + +
- - - - - - - - - - - - - + + + + + + + + + + + + + - - + + +
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255 
ZONE INTERFACE BROADCAST OPTIONS
netppp0  
- + +

Example 3: You have local interface eth1 with two IP + addresses - 192.168.1.1/24 and 192.168.12.1/24

+ +
+ + + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255 
+
+ +

/etc/shorewall/hosts - Configuration

- + Configuration +

For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.

- +

WARNING: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.

- +

Columns in this file are:

- + - -
- -
    - -
  1. An IP address (example - eth1:192.168.1.3)
  2. - -
  3. A subnet in the form <subnet address>/<width> - (example - eth2:192.168.2.0/2)
  4. - - -
- - -

The interface name much match an entry in /etc/shorewall/interfaces.

-
- - - - +
+
    + +
  1. An IP address (example - eth1:192.168.1.3)
  2. + +
  3. A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
  4. + + +
+ + +

The interface name much match an entry in /etc/shorewall/interfaces.

+
+ + + + +
+

routestopped - Beginning with Shorewall 1.3.4, this option is deprecated in favor of the /etc/shorewall/routestopped file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will occur between - this host and other routestopped interfaces and hosts.

-
+ this host (these hosts) will be accepted and routing will occur between + this host and other routestopped interfaces and hosts.
+
+ maclist - Added in version 1.3.10. If specified, connection requests +from the hosts specified in this entry are subject to MAC Verification. This option is only valid +for ethernet interfaces.
+

+
- +

If you don't define any hosts for a zone, the hosts in the zone default - to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces - to the zone.

+ to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces + to the zone.

- +

Note 1: You probably DON'T want to specify any hosts for your internet zone since the hosts that you specify will be the only ones that you will be able to access without adding additional rules.

- +

Note 2: The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the host file is - processed. Please read the description of that + in /etc/shorewall/shorewall.conf + has an important effect on how the host file +is processed. Please read the description of that variable carefully.

- +

Example:

- +

Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:

- + you want to make into separate zones:

+ - +

Your /etc/shorewall/interfaces file might look like:

- -
+ +
- - - - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918
-eth1detect 
-
- - -

The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces - to multiple zones.

- - -

Your /etc/shorewall/hosts file might look like:

- - -
- - - + - - - - - - - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25 
loc2eth1:192.168.1.128/25routestopped
-
- - -

Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.

- - -

Nested and Overlapping Zones

- - -

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow -you to define nested or overlapping zones. Such overlapping/nested zones - are allowed and Shorewall processes zones in the order that they appear - in the /etc/shorewall/zones file. So if you have nested zones, you want - the sub-zone to appear before the super-zone and in the case of overlapping - zones, the rules that will apply to hosts that belong to both zones is - determined by which zone appears first in /etc/shorewall/zones.

- - -

Hosts that belong to more than one zone may be managed by the rules - of all of those zones. This is done through use of the special CONTINUE policy described below.

- - -

- /etc/shorewall/policy Configuration.

- - -

This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms of clients - who initiate connections and servers who receive those connection - requests. Policies defined in /etc/shorewall/policy describe which zones - are allowed to establish connections with other zones.

- - -

Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to a particular - connection request then the policy from /etc/shorewall/policy is applied.

- - -

Four policies are defined:

- - - - - -

For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time that the policy - is applied.

- - -

Entries in /etc/shorewall/policy have four columns as follows:

- - -
    - -
  1. SOURCE - The name of a client - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
  2. - -
  3. DEST - The name of a destination - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
  4. - -
  5. POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION zone.
  6. - -
  7. LOG LEVEL - Optional. If -left empty, no log message is generated when the policy is applied. -Otherwise, this column should contain an integer or name indicating -a syslog level. See the syslog.conf man page for a description of -each log level.
  8. - -
  9. LIMIT:BURST - Optional. If left - empty, TCP connection requests from the SOURCE zone to the DEST - zone will not be rate-limited. Otherwise, this column specifies the maximum - rate at which TCP connection requests will be accepted followed by a colon - (":") followed by the maximum burst size that will be tolerated. Example: - 10/sec:40 specifies that the maximum rate of TCP connection - requests allowed will be 10 per second and a burst of 40 connections will - be tolerated. Connection requests in excess of these limits will be dropped.
  10. - - -
- - -

In the SOURCE and DEST columns, you can enter "all" to indicate all - zones. 

- - -

The policy file installed by default is as follows:

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - +
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918
-eth1detect 
-
+
- -

This table may be interpreted as follows:

- - - -

WARNING:

- -

The firewall script processes  the - /etc/shorewall/policy file from top to bottom and uses the first applicable - policy that it finds. For example, in the following policy file, - the policy for (loc, loc) connections would be ACCEPT as specified in -the first entry even though the third entry in the file specifies REJECT.

- -
+ +

The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.

+ + +

Your /etc/shorewall/hosts file might look like:

+ + +
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - +
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT  
netallDROPinfo 
loclocREJECTinfo 
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25 
loc2eth1:192.168.1.128/25routestopped
-
- -

- The CONTINUE policy

- -

Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones to be managed - under the rules of all of these zones. Let's look at an example:

- -

/etc/shorewall/zones:

- -
+
+ + +

Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.

+ + +

Nested and Overlapping Zones

+ + +

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow +you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that they appear + in the /etc/shorewall/zones file. So if you have nested zones, you want + the sub-zone to appear before the super-zone and in the case of overlapping + zones, the rules that will apply to hosts that belong to both zones is + determined by which zone appears first in /etc/shorewall/zones.

+ + +

Hosts that belong to more than one zone may be managed by the rules + of all of those zones. This is done through use of the special CONTINUE policy described below.

+ + +

+ /etc/shorewall/policy Configuration.

+ + +

This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in terms of clients + who initiate connections and servers who receive those connection + requests. Policies defined in /etc/shorewall/policy describe which zones + are allowed to establish connections with other zones.

+ + +

Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to a particular + connection request then the policy from /etc/shorewall/policy is applied.

+ + +

Four policies are defined:

+ + + + + +

For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that the policy + is applied.

+ + +

Entries in /etc/shorewall/policy have four columns as follows:

+ + +
    + +
  1. SOURCE - The name of a +client zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
  2. + +
  3. DEST - The name of a destination + zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
  4. + +
  5. POLICY - The default policy + for connection requests from the SOURCE zone to the DESTINATION zone.
  6. + +
  7. LOG LEVEL - Optional. If + left empty, no log message is generated when the policy is applied. + Otherwise, this column should contain an integer or name indicating + a syslog level. See the syslog.conf man page for a description of +each log level.
  8. + +
  9. LIMIT:BURST - Optional. If +left empty, TCP connection requests from the SOURCE zone to the + DEST zone will not be rate-limited. Otherwise, this column +specifies the maximum rate at which TCP connection requests will be accepted +followed by a colon (":") followed by the maximum burst size that will +be tolerated. Example: 10/sec:40 specifies that the maximum +rate of TCP connection requests allowed will be 10 per second and a burst +of 40 connections will be tolerated. Connection requests in excess of +these limits will be dropped.
  10. + + +
+ + +

In the SOURCE and DEST columns, you can enter "all" to indicate all + zones. 

+ + +

The policy file installed by default is as follows:

+ + +
+ - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - +
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
-
+
+ + +

This table may be interpreted as follows:

+ + -

/etc/shorewall/interfaces:

+

WARNING:

-
+

The firewall script processes  the + /etc/shorewall/policy file from top to bottom and uses the first applicable + policy that it finds. For example, in the following policy file, + the policy for (loc, loc) connections would be ACCEPT as specified in + the first entry even though the third entry in the file specifies REJECT.

+ +
- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - +
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,noping,norfc1918
loceth1detectroutestopped
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT  
netallDROPinfo 
loclocREJECTinfo 
-
+
-

/etc/shorewall/hosts:

+

+ The CONTINUE policy

-
+

Where zones are nested or overlapping , the + CONTINUE policy allows hosts that are within multiple zones to be managed + under the rules of all of these zones. Let's look at an example:

+ +

/etc/shorewall/zones:

+ +
- - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - +
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0 
sameth0:206.191.149.197routestopped
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
-
+
-

Note that Sam's home system is a member of both the sam zone - and the net zone and as described above , that means that sam must -be listed before net  in /etc/shorewall/zones.

+

/etc/shorewall/interfaces:

-

/etc/shorewall/policy:

- -
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - +
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT 
samallCONTINUE 
netallDROPinfo
allallREJECTinfo
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,noping,norfc1918
loceth1detectroutestopped
-
+
-

The second entry above says that when Sam is the client, connection - requests should first be process under rules where the source zone is sam - and if there is no match then the connection request should be treated under - rules where the source zone is net. It is important that this policy - be listed BEFORE the next policy (net to all).

+

/etc/shorewall/hosts:

-

Partial /etc/shorewall/rules:

- -
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
...      
DNATsamloc:192.168.1.3tcpssh- 
DNATnetloc:192.168.1.5tcpwww- 
...      
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0 
sameth0:206.191.149.197routestopped
-
+
-

Given these two rules, Sam can connect to the firewall's internet interface - with ssh and the connection request will be forwarded to 192.168.1.3. Like - all hosts in the net zone, Sam can connect to the firewall's internet - interface on TCP port 80 and the connection request will be forwarded to - 192.168.1.5. The order of the rules is not significant.

- -

Sometimes it is necessary to suppress port forwarding - for a sub-zone. For example, suppose that all hosts can SSH to the firewall - and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the - firewall's external IP, he should be connected to the firewall itself. - Because of the way that Netfilter is constructed, this requires two rules - as follows:

- -
-

 

- Note that Sam's home system is a member of both the sam zone + and the net zone and as described above , that means that sam must +be listed before net  in /etc/shorewall/zones.

+ +

/etc/shorewall/policy:

+ +
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
       
...      
DNATsamfwtcpssh- 
DNATnet!samloc:192.168.1.3tcpssh- 
...      
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT 
samallCONTINUE 
netallDROPinfo
allallREJECTinfo
+

The second entry above says that when Sam is the client, connection + requests should first be process under rules where the source zone is +sam and if there is no match then the connection request should be +treated under rules where the source zone is net. It is important +that this policy be listed BEFORE the next policy (net to all).

+ +

Partial /etc/shorewall/rules:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
...      
DNATsamloc:192.168.1.3tcpssh- 
DNATnetloc:192.168.1.5tcpwww- 
...      
+
+ +

Given these two rules, Sam can connect to the firewall's internet interface + with ssh and the connection request will be forwarded to 192.168.1.3. +Like all hosts in the net zone, Sam can connect to the firewall's +internet interface on TCP port 80 and the connection request will be forwarded +to 192.168.1.5. The order of the rules is not significant.

+ +

Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can SSH to the firewall + and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the + firewall's external IP, he should be connected to the firewall itself. + Because of the way that Netfilter is constructed, this requires two +rules as follows:

+ +
+

 

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
       
...      
DNATsamfwtcpssh- 
DNATnet!samloc:192.168.1.3tcpssh- 
...      
+
+

The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the @@ -1106,387 +1135,392 @@ be listed before net connection port forwarded to 192.168.1.3. If you need to exclude more than one zone in this way, - you can list the zones separated - by commas (e.g., net!sam,joe,fred). - This technique also may be used - when the ACTION is REDIRECT.

+ you can list the zones separated + by commas (e.g., net!sam,joe,fred). + This technique also may be +used when the ACTION is REDIRECT.

+

/etc/shorewall/rules

+

The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules - for each of these rules. 

+ in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules + for each of these rules. 

- +

Entries in the file have the following columns:

- + - +

Example 1. You wish to forward all - ssh connection requests from the internet to local system 192.168.1.3. 

- + ssh connection requests from the internet to local system 192.168.1.3. 

+
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
DNATnetloc:192.168.1.3tcpssh  
-
- -

Example 2. You want to redirect all local www connection requests - EXCEPT those to your own - http server (206.124.146.177) - to a Squid transparent proxy - running on the firewall and listening on port 3128. Squid will of course - require access to remote web servers. This example shows yet - another use for the ORIGINAL - DEST column; here, connection - requests that were NOT - - (notice the "!") originally - destined to 206.124.146.177 - are redirected to local -port 3128.

- -
- - + - - - - - - - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
REDIRECTloc3128tcpwww !206.124.146.177
ACCEPTfwnettcpwww  
-
- -

Example 3. You want to run a web server at 155.186.235.222 in -your DMZ and have it accessible remotely and locally. the DMZ is managed - by Proxy ARP or by classical sub-netting.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + - +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
ACCEPTnetdmz:155.186.235.222tcpwww- 
ACCEPTlocdmz:155.186.235.222tcpwww  
DNATnetloc:192.168.1.3tcpssh  
-
- - -

Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 and you want -the FTP server to be accessible from the internet in addition to the local - 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that since the - server is in the 192.168.2.0/24 subnetwork, we can assume that access -to the server from that subnet will not involve the firewall (but see FAQ 2). Note that unless you - have more than one external - IP address, you can leave - the ORIGINAL DEST column - blank in the first rule. - You cannot leave it -blank in the second rule -though because then -all ftp connections - originating in the local - subnet 192.168.1.0/24 would - be sent to 192.168.2.2 - regardless of the site that - the user was trying to - connect to. That is - clearly not what you want - - .

- - -
+
+ +

Example 2. You want to redirect all local www connection requests + EXCEPT those to your own + http server (206.124.146.177) + to a Squid transparent +proxy running on the firewall and listening on port 3128. Squid will of +course require access to remote web servers. This example shows yet + another use for the ORIGINAL + DEST column; here, connection + requests that were NOT + + (notice the "!") originally + destined to 206.124.146.177 + are redirected to local + port 3128.

+ +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
DNATnetdmz:192.168.2.2tcpftp  
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
REDIRECTloc3128tcpwww !206.124.146.177
ACCEPTfwnettcpwww  
+
+ +

Example 3. You want to run a web server at 155.186.235.222 in +your DMZ and have it accessible remotely and locally. the DMZ is managed + by Proxy ARP or by classical sub-netting.

+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
ACCEPTnetdmz:155.186.235.222tcpwww- 
ACCEPTlocdmz:155.186.235.222tcpwww  
-
+
+ + +

Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded + DMZ. Your internet interface address is 155.186.235.151 and you want + the FTP server to be accessible from the internet in addition to the local + 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that since +the server is in the 192.168.2.0/24 subnetwork, we can assume that access + to the server from that subnet will not involve the firewall (but see FAQ 2). Note that unless you + have more than one external + IP address, you can leave + the ORIGINAL DEST +column blank in the +first rule. You cannot +leave it blank in the + second rule though because + then all ftp connections + originating in the local + subnet 192.168.1.0/24 would + be sent to 192.168.2.2 + regardless of the site that + the user was trying to + connect to. That is + clearly not what you +want + .

+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
DNATnetdmz:192.168.2.2tcpftp  
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
+
+ + +

If you are running wu-ftpd, you should restrict the range of passive in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions - so I use port range 65500-65535. In /etc/ftpaccess, this entry is appropriate:

+ so I use port range 65500-65535. In /etc/ftpaccess, this entry is appropriate:

- +
- +

passive ports  0.0.0.0/0 65500 65534

-
+ - +

If you are running pure-ftpd, you would include "-p 65500:65534" on - the pure-ftpd runline.

+ the pure-ftpd runline.

- +

The important point here is to ensure that the port range used for FTP - passive connections is unique and will not overlap with any usage on the - firewall system.

+ passive connections is unique and will not overlap with any usage on the + firewall system.

- +

Example 5. You wish to allow unlimited DMZ access to the host @@ -1494,51 +1528,51 @@ though because then 02:00:08:E3:FA:55.

- +
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall   
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall   
-
+ - +

Look here for information on other services. -

+

- +

/etc/shorewall/common

- +

Shorewall allows definition of rules that apply between all zones. @@ -1548,157 +1582,160 @@ though because then but may be modified to suit individual requirements. Rather - than modify - /etc/shorewall/common.def, - you should copy -that file to - /etc/shorewall/common - and modify that file.

+ than modify + /etc/shorewall/common.def, + you should copy + that file to + /etc/shorewall/common + and modify that +file.

- +

The /etc/shorewall/common - file is expected - to contain iptables - commands; rather - than running iptables - directly, you should - run it indirectly - using the Shorewall - function 'run_iptables'. - That way, if iptables - encounters an error, the - firewall will be safely - stopped.

+ file is expected + to contain iptables + commands; rather + than running iptables + directly, you should + run it indirectly + using the Shorewall + function 'run_iptables'. + That way, if iptables + encounters an error, the + firewall will be safely + stopped.

- +

/etc/shorewall/masq

- +

The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation  (SNAT). There is one entry in the - file for each subnet that you want to masquerade. In order to make use -of this feature, you must have NAT enabled .

+ and Source Network Address Translation  (SNAT). There is one entry in the + file for each subnet that you want to masquerade. In order to make use + of this feature, you must have NAT enabled + .

- +

Columns are:

- + - +

Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq - file would look like:    

+ connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like:    

- +
- + - - - - - - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24 
-
- - -

Example 2: You have a number of IPSEC tunnels through ipsec0 - and you want to masquerade traffic from your 192.168.9.0/24 subnet to -the remote subnet 10.1.0.0/16 only.

- - -
- - - + - - - - - - - - - + + + + + + + + + + -
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24 
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24 
-
+ +

Example 2: You have a number of IPSEC tunnels through ipsec0 + and you want to masquerade traffic from your 192.168.9.0/24 subnet to + the remote subnet 10.1.0.0/16 only.

+ + +
+ + + + + + + + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24 
+
+ +

Example 3: You have a DSL line connected on eth0 and a local - network (192.168.10.0/24) - connected to + network (192.168.10.0/24) + connected to eth1. You want all local->net connections to use source address 206.124.146.176.

- -
+ +
- - - - - - + - - - - + + + + + + + + + - - + +
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
-
+
- +

Example 4: Same as example 3 except that you wish @@ -1708,34 +1745,34 @@ all local->net the SNAT rule.

- +
- + - - - - - - + - - - - + + + + + + + + + - - + +
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
-
+ - +

/etc/shorewall/proxyarp

- +

If you want to use proxy ARP on an entire sub-network, @@ -1744,30 +1781,30 @@ all local->net http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide - to use the technique - described in - that HOWTO, -you can set the -proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by including the + If you decide + to use the +technique described +in that HOWTO, + you can set +the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by including the proxyarp - option in the - interface's -record in - /etc/shorewall/interfaces. - When using Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp. -

+ option in the + interface's + record in + /etc/shorewall/interfaces. + When using Proxy ARP + sub-netting, you do + NOT include + any entries in + /etc/shorewall/proxyarp. +

- +

The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -1775,47 +1812,47 @@ record in - + in this file + for each system + using proxy + ARP. Columns are:

+ - +

Note: After you have made a change to the /etc/shorewall/proxyarp - file, you may need to flush the ARP cache of all routers on the LAN segment - connected to the interface specified in the EXTERNAL column of the change/added - entry(s). If you are having problems communicating between an individual - host (A) on that segment and a system whose entry has changed, you may -need to flush the ARP cache on host A as well.

+ file, you may need to flush the ARP cache of all routers on the LAN segment + connected to the interface specified in the EXTERNAL column of the change/added + entry(s). If you are having problems communicating between an individual + host (A) on that segment and a system whose entry has changed, you may + need to flush the ARP cache on host A as well.

- +

ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may take a long @@ -1824,92 +1861,94 @@ to delete a stale entry in order to restore a system to working order after changing my proxy ARP settings.

- +

Example: You have public IP addresses 155.182.235.0/28. You configure your - firewall as follows:

- + firewall as follows:

+ - +

In your DMZ, you want to install a Web/FTP server with public address - 155.186.235.4. On the Web server, you subnet just like the firewall's eth0 - and you configure 155.186.235.1 as the default gateway. In your /etc/shorewall/proxyarp - file, you will have:

+ 155.186.235.4. On the Web server, you subnet just like the firewall's +eth0 and you configure 155.186.235.1 as the default gateway. In your + /etc/shorewall/proxyarp file, you will have:

- +
- + - - - - - - - - - - - - - + + + + + + + + + + + + + + + - +
ADDRESS INTERFACE EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
ADDRESS INTERFACE EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
-
- + +

Note: You may want to configure the servers in your DMZ with a subnet - that is smaller than the subnet of your internet interface. See the Proxy - ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) - for details. In this case you will want to place "Yes" in the HAVEROUTE - column.

- + for details. In this case you will want to place "Yes" in the HAVEROUTE + column.

+

To learn how I use Proxy ARP in my DMZ, see my configuration files.

- +

Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. - If you start or restart Shorewall with an IPSEC tunnel active, the proxied - IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) - rather than to the interface that you specify in the INTERFACE column of - /etc/shorewall/proxyarp. I haven't had the time to debug this problem so -I can't say if it is a bug in the Kernel or in FreeS/Wan. 

- + If you start or restart Shorewall with an IPSEC tunnel active, the proxied + IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) + rather than to the interface that you specify in the INTERFACE column of + /etc/shorewall/proxyarp. I haven't had the time to debug this problem so + I can't say if it is a bug in the Kernel or in FreeS/Wan. 

+

You might be able to work around this problem using the following - (I haven't tried it):

- + (I haven't tried it):

+

In /etc/shorewall/init, include:

- +

     qt service ipsec stop

- +

In /etc/shorewall/start, include:

- +

    qt service ipsec start

- +

/etc/shorewall/nat

- +

The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that you wish to define. - In order to make use of this feature, you must have NAT enabled .

- +

IMPORTANT: If @@ -1921,9 +1960,9 @@ I can't say if it is a bug in the Kernel or in FreeS/Wan. static NAT. Port forwarding can be accomplished - with simple - entries in - the rules file. Also, in most @@ -1938,387 +1977,397 @@ be accomplished are accessed using the same IP address internally - and externally.

+ and externally.

- +

Columns in an entry are:

- + - +

Look here for additional information and an example. -

+

- +

/etc/shorewall/tunnels

- -

The /etc/shorewall/tunnels file allows you to define IPSec, GRE and - IPIP tunnels with end-points on your firewall. To use ipsec, you must -install version 1.9, 1.91 or the current The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP +and PPTP tunnels with end-points on your firewall. To use ipsec, you must + install version 1.9, 1.91 or the current FreeS/WAN development snapshot. 

- +

Note: For kernels 2.4.4 and above, you will need to use version 1.91 - or a development snapshot as patching with version 1.9 results in kernel - compilation errors.

+ or a development snapshot as patching with version 1.9 results in kernel + compilation errors.

- +

Instructions for setting up IPSEC tunnels may - be found here and instructions for IPIP - tunnels are here . Look here for information - about setting up PPTP - tunnels under - Shorewall.

+ be found here, instructions for IPIP and +GRE tunnels are here  and instructions for +PPTP tunnels are here.

+ +

/etc/shorewall/shorewall.conf

- -

- /etc/shorewall/shorewall.conf

- - +

This file is used to set the following firewall parameters:

- + - +

/etc/shorewall/modules Configuration

- +

The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall will source - this file during start/restart provided that it exists and that the directory - specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf - above).

+ modules required by Shorewall-defined firewall rules. Shorewall will +source this file during start/restart provided that it exists and that +the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).

- +

The file that is released with Shorewall calls the Shorewall function - "loadmodule" for the set of modules that I load.

+ "loadmodule" for the set of modules that I load.

- +

The loadmodule function is called as follows:

- +
- - + +

loadmodule <modulename> [ <module parameters> ]

-
+ - +

where

- +
- +

<modulename>                

- +
- +

is the name of the modules without the trailing ".o" (example ip_conntrack).

-
+
- +

<module parameters>

- +
- +

Optional parameters to the insmod utility.

+
- - +

The function determines if the module named by <modulename> - is already loaded and if not then the function determines if the - ".o" file corresponding to the module exists in the moduledirectory; - if so, then the following command is executed:

+ is already loaded and if not then the function determines if the + ".o" file corresponding to the module exists in the moduledirectory; + if so, then the following command is executed:

- +
- +

insmod moduledirectory/<modulename>.o <module - parameters>

-
+ parameters>

+ - +

If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports compressed @@ -2504,391 +2553,399 @@ it does, the function assumes that the running configuration supports compress - +

- +

insmod moduledirectory/<modulename>.o.gz <module - parameters>

-
+ parameters>

+ - +

/etc/shorewall/tos Configuration

- +

The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, protocol, - source port and destination port. In order for this file to be processed - by Shorewall, you must have mangle support enabled + in packet headers based on packet source, packet destination, protocol, + source port and destination port. In order for this file to be processed + by Shorewall, you must have mangle support enabled .

- +

Entries in the file have the following columns:

- + - +
- +
- +

Minimize-Delay (16)
- Maximize-Throughput (8)
- Maximize-Reliability (4)
- Minimize-Cost (2)
- Normal-Service (0)

-
-
+ Maximize-Throughput (8)
+ Maximize-Reliability (4)
+ Minimize-Cost (2)
+ Normal-Service (0)

+ + - +

The /etc/shorewall/tos file that is included with Shorewall contains - the following entries.

+ the following entries.

- -
+ +
- + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
SOURCEDESTPROTOCOLSOURCE
- PORT(S)
DEST PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
SOURCEDESTPROTOCOLSOURCE
+ PORT(S)
DEST PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
-
+
- +

WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file.

+ adding the ESP and AH protocols to the /etc/shorewall/tos file.

- +

/etc/shorewall/blacklist

- +

Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall - Format - or - subnet - address. - Example:

+ an + IP + address, a MAC address in Shorewall + Format + or + subnet + address. + Example:

- +
      130.252.100.69
206.124.146.0/24
- +

Packets from hosts listed in - the - blacklist - file - will - be - disposed + the + blacklist + file + will + be + disposed - of - according - to - the - value - assigned + of + according + to + the + value + assigned - to - the BLACKLIST_DISPOSITION - and - BLACKLIST_LOGLEVEL variables - in - /etc/shorewall/shorewall.conf. + to + the BLACKLIST_DISPOSITION - Only - packets - arriving - on - interfaces +and BLACKLIST_LOGLEVEL variables + in + /etc/shorewall/shorewall.conf. + + Only + packets + arriving + on + interfaces that have the 'blacklist' - option - in - /etc/shorewall/interfaces - are + option + in + /etc/shorewall/interfaces + are - checked - against - the - blacklist. The black list is + checked + against + the + blacklist. The black list is designed to prevent listed hosts/subnets from accessing services on your - network.
-

- + network.
+

+

Beginning with Shorewall 1.3.8, the blacklist file has three columns:
-

- +

+ - +

Shorewall also has a dynamic blacklist - capability.

+ capability.

- +

IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, I suggest that - you install and configure Squid (http://www.squid-cache.org). -

+ designed to police your users' web browsing -- to do that, I suggest that + you install and configure Squid (http://www.squid-cache.org). +

- +

/etc/shorewall/rfc1918 (Added in Version 1.3.1)

- +

This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:

+ interface option. Columns in the file are:

- + - -

25. /etc/shorewall/routestopped (Added in Version -1.3.4)

+ +

/etc/shorewall/routestopped (Added in Version + 1.3.4)

- -

This fine defines the hosts that are accessible from the firewall when - the firewall is stopped.  Columns in the file are:

+ +

This file defines the hosts that are accessible from the firewall when + the firewall is stopped.  Columns in the file are:

- + - +

Example: When your firewall is stopped, you want firewall accessibility - from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces through - eth1 and your local hosts through eth2.

+ from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces through + eth1 and your local hosts through eth2.

- +
- + - - + + - + - + - + - + - + - + - + - + - + - + - + - - + +
INTERFACEINTERFACEHOST(S)HOST(S)
eth2eth2192.168.1.0/24192.168.1.0/24
eth1eth1--
-
+ - -

Updated 9/28/2002 - Tom Eastep -

+ +

/etc/shorewall/maclist (Added in Version 1.3.10)

+ This file is described in the MAC Validation +Documentation.
+
+ +

Updated 10/28/2002 - Tom Eastep +

- +

Copyright - © 2001, 2002 Thomas M. Eastep.

+ © 2001, 2002 Thomas M. Eastep.

-
+
+



diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 030efb9d2..03ca89fce 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,734 +1,856 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
+
+

Shorewall FAQs

-
- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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 7.x, I get messages about insmod failing -- what's wrong?

- -

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

- -

10. What distributions does - it work with?

- -

11. What features does it -support?

- + +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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 7.x, I get messages about insmod failing -- what's wrong?

+ +

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

+ +

10. What distributions does + it work with?

+ +

11. What features does it + support?

+

12. Why isn't there a GUI

- +

13. Why do you call it "Shorewall"?

- -

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

- -

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

- -

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

- -

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

- -
-

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.

- + +

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

+ +

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

+ +

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

+ +

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

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

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

+

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. Assuming that you have a dynamic external - IP address, the format of a port-forwarding rule to a local system is as -follows:

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

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

- -
+
+ +

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

+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-

-
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
+

+
-
- -
+
+ +
     DNAT net loc:192.168.1.5 udp 7777
-
- -

If you want to forward requests directed to a particular -address ( <external IP> ) on your firewall to an internal system:

- -
+ + +

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

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

- +
+ +

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

+

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

- + - -

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.

- + +

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

+ Answer: To further diagnose this problem:
+ + + +

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

+

Answer: I have two objections to this setup.

- + - -

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

- -

a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1.

- -
+ +

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

+ +

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

+ +

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

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

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

-
- -
+
+ +
+

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

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

and make your DNAT rule:

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

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

-
- -

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) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces.
- b) Set the Z->Z policy to ACCEPT.
- c) Masquerade Z to itself.
-
- Example:

- + +
+ +
+

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

+

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

- + Interface: eth2
+ Subnet: 192.168.2.0/24

+

In /etc/shorewall/interfaces:

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

In /etc/shorewall/policy:

- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
+
-
- -
+
+ +
     dmz    dmz    ACCEPT
-
- + +

In /etc/shorewall/masq:

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

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

- +
+ +

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

+

Answer: There is an H.323 connection - tracking/NAT module that may help. Also check the Netfilter mailing list - archives at http://netfilter.samba.org. -

- -

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

- -

Answer: The common.def included with version 1.3.x - always rejects connection requests on TCP port 113 rather than dropping - them. This is necessary to prevent outgoing connection problems to services - that use the 'Auth' mechanism for identifying requesting users. Shorewall - also rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139. -These are ports that are used by Windows (Windows can be configured -to use the DCE cell locator on port 135). Rejecting these connection requests - rather than dropping them cuts down slightly on the amount of Windows -chatter on LAN segments connected to the Firewall.

- -

If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web server in violation of your - Service Agreement.

- -

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

- -

Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing back from your firewall - then it reports the port as open. If you want to see which UDP ports are - really open, temporarily change your net->all policy to REJECT, restart - Shorewall and do the nmap UDP scan again.

- -

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

- -

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

- + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help. Also check the Netfilter mailing + list archives at http://netfilter.samba.org. +

+ +

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

+ +

Answer: The common.def included with version 1.3.x + always rejects connection requests on TCP port 113 rather than dropping + them. This is necessary to prevent outgoing connection problems to + services that use the 'Auth' mechanism for identifying requesting +users. Shorewall also rejects TCP ports 135, 137 and 139 as well as +UDP ports 137-139. These are ports that are used by Windows (Windows +can be configured to use the DCE cell locator on port 135). +Rejecting these connection requests rather than dropping them cuts +down slightly on the amount of Windows chatter on LAN segments connected + to the Firewall.

+ +

If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server in violation of +your Service Agreement.

+ +

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

+ +

Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing back from your + firewall then it reports the port as open. If you want to see which + UDP ports are really open, temporarily change your net->all policy + to REJECT, restart Shorewall and do the nmap UDP scan again.

+ +

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

+ +

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

+

a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
- b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
- c) Add the following to /etc/shorewall/icmpdef:

- -
-

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

-
- -

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

- -

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

- -

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

- -
+ b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
+ c) Add the following to /etc/shorewall/icmpdef:

+ +
+

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

+
+ +

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

+ +

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

+ +

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

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

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

- -

Answer: Here are several links that may be helpful: -

- -
+
+ +

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

+ +

Answer: Here are several links that may be helpful: +

+ +

http://www.shorewall.net/pub/shorewall/parsefw/
- http://www.fireparse.com
- http://cert.uni-stuttgart.de/projects/fwlogwatch

-
- -

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

- -

The 'stop' command is intended to place your firewall into - a safe state whereby only those interfaces/hosts having the 'routestopped' - option in /etc/shorewall/interfaces and /etc/shorewall/hosts 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 - 7.x, I get messages about insmod failing -- what's wrong?

- -

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

- + http://www.fireparse.com
+ http://cert.uni-stuttgart.de/projects/fwlogwatch
+http://www.logwatch.org

+

+ + +

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

+ +

The 'stop' command is intended to place your firewall into + a safe state whereby only those interfaces/hosts having the 'routestopped' + option in /etc/shorewall/interfaces and /etc/shorewall/hosts 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 + 7.x, I get messages about insmod failing -- what's wrong?

+ +

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

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

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

- -
+ +

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.

-
- +
+ +
+

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

+
+

- -

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

- -

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

- -
+ +

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

+ +

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

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

Why can't Shorewall detect my interfaces properly?

-
- -
-

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

-
- -

10. What Distributions does it work - with?

- -

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

- +
+ +
+

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.

- + +

Answer: See the Shorewall + Feature List.

+

12. Why isn't there a GUI?

- -

Answer: Every time I've started to work on one, I find -myself doing other things. I guess I just don't care enough if Shorewall -has a GUI to invest the effort to create one myself. There are several -Shorewall GUI projects underway however and I will publish links to -them when the authors feel that they are ready.

- + +

Answer: Every time I've started to work on one, I +find myself doing other things. I guess I just don't care enough if +Shorewall has a GUI to invest the effort to create one myself. There +are several Shorewall GUI projects underway however and I will publish +links to them when the authors feel that they are ready.

+

13. Why do you call it "Shorewall"?

- -

Answer: Shorewall is a concatenation of "Shoreline" - (the city where I live) - and "Firewall".

- -

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

- -

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

- -

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

- -
+ +

Answer: Shorewall is a concatenation of "Shoreline" + (the city where I live) + and "Firewall".

+ +

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

+ +

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

+ +

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

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

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

-
- -
-
+
+ +
+

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

- -
+

+ +

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

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

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

-
- -
-

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

-
- -

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

- -

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

- + +
+ +
+

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

+
+ +
+

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

+
+ +

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

+ +

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

+
    -
  1. -

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

    -
  2. -
  3. -

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

    -
  4. -
  5. -

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

    -
  6. - +
  7. +

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

    +
  8. +
  9. +

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

    +
  10. +
  11. +

    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.

    +
  12. +
- -

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

- -

Answer: "man dmesg" -- add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. Under RedHat, - the max log level that is sent to the console is specified in /etc/sysconfig/init - in the LOGLEVEL variable.

- + +

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

+ +

Answer: "man dmesg" -- add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. Under + RedHat, the max log level that is sent to the console is specified +in /etc/sysconfig/init in the LOGLEVEL variable.
+

+ +

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

+ Answer: Logging occurs out of a number of chains (as indicated + in the log message) in Shorewall:
+ +
    +
  1. man1918 - The destination address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
  2. +
  3. rfc1918 - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
  4. +
  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 then you need a rule to that effect.
    +
  6. +
  7. <zone1>2<zone2> - Either you have a policy for <zone1> to + <zone2> that specifies a log level and this packet is being + logged under that policy or this packet matches a rule that include a log level.
  8. +
  9. logpkt - The packet is being logged under the logunclean + interface option.
  10. +
  11. badpkt - The packet is being logged under the dropunclean + interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
  12. +
  13. blacklst - The packet is being logged because the source + IP is blacklisted in the /etc/shorewall/blacklist + file.
  14. +
  15. 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.
  16. +
  17. INPUT or FORWARD - The packet has a source IP address + that isn't in any of your defined zones ("shorewall check" and look at the + printed zone definitions) or the chain is FORWARD and the destination IP + isn't in any of your defined zones.
  18. + +
+ +

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

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

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

ACCEPT net loc:10.1.1.126 tcp www
+
- -

Last updated 10/8/2002 - Last updated 11/09/2002 - Tom Eastep

- -

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

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

- +
diff --git a/STABLE/documentation/IPSEC.htm b/STABLE/documentation/IPSEC.htm index fee400531..e3518fd2e 100644 --- a/STABLE/documentation/IPSEC.htm +++ b/STABLE/documentation/IPSEC.htm @@ -1,284 +1,367 @@ - - + + Shorewall IPSec Tunneling - - - - - - - - - - - - -
-

IPSEC Tunnels

-
-

Configuring FreeS/Wan

-There is an excellent guide to configuring IPSEC tunnels at - http://jixen.tripod.com -. I highly recommend that you consult that site for information about confuring -FreeS/Wan. 

Warning: Do not use Proxy ARP - and FreeS/Wan on the same system unless you are prepared to suffer the - consequences. If you start or restart Shorewall with an IPSEC tunnel active, - the proxied IP addresses are mistakenly assigned to the IPSEC tunnel device - (ipsecX) rather than to the interface that you specify in the INTERFACE column - of /etc/shorewall/proxyarp. I haven't had the time to debug this problem so I - can't say if it is a bug in the Kernel or in FreeS/Wan. 

-

You might be able to work around this problem using the following (I - haven't tried it):

-

In /etc/shorewall/init, include:

-

     qt service ipsec stop

-

In /etc/shorewall/start, include:

-

    qt service ipsec start

-

- -IPSec Gateway -on the Firewall System -

- -

Suppose that we have the following sutuation:

- - - -

- -

- -
- -

We want systems -in the 192.168.1.0/24 sub-network to be able to communicate with systems -in the 10.0.0.0/8 network.

- -

To make this work, we need to do two things:

- -

a) Open the firewall so that the IPSEC tunnel can be established -(allow the ESP and AH protocols and UDP Port 500).

- -

b) Allow traffic through the tunnel.

- -

Opening the firewall for the IPSEC tunnel is accomplished by -adding an entry to the /etc/shorewall/tunnels file.

- -

In /etc/shorewall/tunnels -on system A, we need the following 

- -
- - - - - - - - - - - - - - - - -
- TYPE - ZONE - GATEWAY - GATEWAY ZONE
ipsecnet134.28.54.2 
- -

In /etc/shorewall/tunnels -on system B, we would have:

- -
- - - - - - - - - - - - - - - - -
- TYPE - ZONE - GATEWAY - GATEWAY ZONE
ipsecnet206.161.148.9 
- -

You need to define a zone for the remote subnet or include - it in your local zone. In this example, we'll assume that you have created a - zone called "vpn" to represent the remote subnet.

- -
- - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
-
- -

At both -systems, ipsec0 would be included in /etc/shorewall/interfaces as a "vpn" -interface:

- -
- - - - - - - - - - - - - - - - -
- ZONE - INTERFACE - BROADCAST - OPTIONS
vpnipsec0  
- -

You will need to allow traffic between the "vpn" zone and - the "loc" zone -- if you simply want to admit all traffic in both - directions, you can use the policy file:

- - -
- - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
-
- -

Once -you have these entries in place, restart Shorewall (type shorewall restart); -you are now ready to configure the tunnel in - FreeS/WAN - .

- - -

- Mobile System (Road Warrior)

- -

Suppose that you have -a laptop system (B) that you take with you when you travel and you want to -be able to establish a secure connection back to your local network.

- -

- -

- -

You need to define a zone for the laptop or include it in - your local zone. In this example, we'll assume that you have created a zone - called "vpn" to represent the remote host.

- -
- - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
-
- -

In this -instance, the mobile system (B) has IP address 134.28.54.2 but that cannot -be determined in advance. In the /etc/shorewall/tunnels file on system A, -the following entry should be made:

- -
- - - - - - - - - - - - - - - -
- TYPE - ZONE - GATEWAY - GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
+ + + + + + + + + + + + + +
+

IPSEC Tunnels

+
+ +

Configuring FreeS/Wan

+ There is an excellent guide to configuring IPSEC tunnels at http://jixen.tripod.com . I highly recommend +that you consult that site for information about confuring FreeS/Wan.  +

Warning: Do not use Proxy ARP and +FreeS/Wan on the same system unless you are prepared to suffer the consequences. +If you start or restart Shorewall with an IPSEC tunnel active, the proxied +IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) +rather than to the interface that you specify in the INTERFACE column of +/etc/shorewall/proxyarp. I haven't had the time to debug this problem so I + can't say if it is a bug in the Kernel or in FreeS/Wan. 

+ +

You might be able to work around this problem using the following +(I haven't tried it):

+ +

In /etc/shorewall/init, include:

+ +

     qt service ipsec stop

+ +

In /etc/shorewall/start, include:

+ +

    qt service ipsec start

+ +

IPSec Gateway on the Firewall System

+ +

Suppose that we have the following sutuation:

+ +

+

+
+

We want systems in the 192.168.1.0/24 sub-network to be able +to communicate with systems in the 10.0.0.0/8 network.

+ +

To make this work, we need to do two things:

+ +

a) Open the firewall so that the IPSEC tunnel can be established + (allow the ESP and AH protocols and UDP Port 500).

+ +

b) Allow traffic through the tunnel.

+ +

Opening the firewall for the IPSEC tunnel is accomplished +by adding an entry to the /etc/shorewall/tunnels file.

+ +

In /etc/shorewall/tunnels on system A, we need the following 

+ +
+ + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet134.28.54.2 
+
-

Note that the GATEWAY -ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the -gateway system itself comprises the peer subnetwork; in other words, the -remote gateway is a standalone system.

- - -

You will need to configure /etc/shorewall/interfaces and establish - your "through the tunnel" policy as shown under the first example above.

- - -

Last -updated 8/20/2002 - - Tom Eastep +

In /etc/shorewall/tunnels on system B, we would have:

+ +
+ + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
+
+ +

Note: If either of the endpoints is behind a NAT gateway +then the tunnels file entry on the other endpoint should specify +a tunnel type of ipsecnat rather than ipsec and the GATEWAY +address should specify the external address of the NAT gateway.
+

+

You need to define a zone for the remote subnet or include + it in your local zone. In this example, we'll assume that you have created +a zone called "vpn" to represent the remote subnet.

+ +
+ + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
+
+ +

At both systems, ipsec0 would be included in /etc/shorewall/interfaces +as a "vpn" interface:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
vpnipsec0  
+
+ +

You will need to allow traffic between the "vpn" zone and + the "loc" zone -- if you simply want to admit all traffic in both + directions, you can use the policy file:

+ +
+ + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
+
+ +

Once you have these entries in place, restart Shorewall (type +shorewall restart); you are now ready to configure the tunnel in FreeS/WAN .

+ +

Mobile System (Road +Warrior)

+ +

Suppose that you have a laptop system (B) that you take with you when you +travel and you want to be able to establish a secure connection back to your +local network.

+ +

+ +

+ +

You need to define a zone for the laptop or include it in + your local zone. In this example, we'll assume that you have created +a zone called "vpn" to represent the remote host.

+ +
+ + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
+
+ +

In this instance, the mobile system (B) has IP address 134.28.54.2 +but that cannot be determined in advance. In the /etc/shorewall/tunnels file +on system A, the following entry should be made:

+ +
+ + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
+
+ +

Note that the GATEWAY ZONE column contains the name of the zone corresponding +to peer subnetworks. This indicates that the gateway system itself comprises +the peer subnetwork; in other words, the remote gateway is a standalone system.

+ +

You will need to configure /etc/shorewall/interfaces and establish + your "through the tunnel" policy as shown under the first example above.

- - -

- Copyright © 2001, 2002 Thomas M. Eastep.

- + +

Dynamic RoadWarrior Zones

+ Beginning with Shorewall release 1.3.10, you can define multiple VPN zones +and add and delete remote endpoints dynamically using /sbin/shorewall. In +/etc/shorewall/zones:
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
ZONE
+
DISPLAY
+
COMMENTS
+
vpn1
+
VPN-1
+
First VPN Zone
+
vpn2
+
VPN-2
+
Second VPN Zone
+
vpn3
+
VPN-3
+
Third VPN Zone
+
+
+
+ In /etc/shorewall/tunnels:
+ +
+ + + + + + + + + + + + + + + + +
TYPE
+
ZONE
+
GATEWAY
+
GATEWAY ZONE
+
ipsec
+
net
+
0.0.0.0/0
+
vpn1,vpn2,vpn3
+
+
+
+ When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall +will issue warnings to that effect. These warnings may be safely ignored. +FreeS/Wan may now be configured to have three different Road Warrior connections +with the choice of connection being based on X-509 certificates or some other +means. Each of these connectioins will utilize a different updown script that +adds the remote station to the appropriate zone when the connection comes +up and that deletes the remote station when the connection comes down. For +example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of the +script will issue the command":
+
+ +
/sbin/shorewall add ipsec0:134.28.54.2 vpn2
+
+ and the 'down' part will:
+ +
/sbin/shorewall delete ipsec0:134.28.54.2 vpn
+ +

Last updated 10/23/2002 - + Tom Eastep

+ +

+ Copyright © 2001, 2002 Thomas M. Eastep.

+
+
- \ No newline at end of file + diff --git a/STABLE/documentation/Install.htm b/STABLE/documentation/Install.htm index 9b5b55523..1b7565f5a 100644 --- a/STABLE/documentation/Install.htm +++ b/STABLE/documentation/Install.htm @@ -1,207 +1,207 @@ - + Shorewall Installation - + - + - + - - - + + - - - + + + +
-

Shorewall Installation and +

+

Shorewall Installation and Upgrade

-
- +

Before upgrading, be sure to review the Upgrade Issues

- +

Install using RPM
- Install using tarball
- Upgrade using RPM
- Upgrade using tarball
- Configuring Shorewall
- Uninstall/Fallback

- + Install using tarball
+ Upgrade using RPM
+ Upgrade using tarball
+ Configuring Shorewall
+ Uninstall/Fallback

+

To install Shorewall using the RPM:

- -

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a -shell prompt, type "/sbin/iptables --version"), you must upgrade to version + +

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a +shell prompt, type "/sbin/iptables --version"), you must upgrade to version 1.2.4 either from the RedHat update - site or from the Shorewall Errata page before + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update + site or from the Shorewall Errata page before attempting to start Shorewall.

- + - -

To install Shorewall using the tarball + +

To install Shorewall using the tarball and install script:

- + - -

If you already have the Shorewall RPM installed + +

If you already have the Shorewall RPM installed and are upgrading to a new version:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version -and you have entries in the /etc/shorewall/hosts file then please check -your /etc/shorewall/interfaces file to be sure that it contains an entry -for each interface mentioned in the hosts file. Also, there are certain -1.2 rule forms that are no longer supported under 1.3 (you must use the -new 1.3 syntax). See the upgrade issues for -details. You can check your rules and host file for 1.3 compatibility using -the "shorewall check" command after installing the latest version of 1.3.

- + +

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and +you have entries in the /etc/shorewall/hosts file then please check your + /etc/shorewall/interfaces file to be sure that it contains an entry for +each interface mentioned in the hosts file. Also, there are certain 1.2 +rule forms that are no longer supported under 1.3 (you must use the new +1.3 syntax). See the upgrade issues for details. +You can check your rules and host file for 1.3 compatibility using the "shorewall +check" command after installing the latest version of 1.3.

+
    -
  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: If -you are installing version 1.2.0 and have one of the 1.2.0 Beta RPMs -installed, you must use the "--oldpackage" option to rpm (e.g., "rpm - -Uvh --oldpackage shorewall-1.2-0.noarch.rpm"). -

    Note: Some SuSE users have encountered a problem whereby -rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel -is installed. If this happens, simply use the --nodeps option to rpm (rpm +

  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: If +you are installing version 1.2.0 and have one of the 1.2.0 Beta RPMs installed, + you must use the "--oldpackage" option to rpm (e.g., "rpm -Uvh --oldpackage +shorewall-1.2-0.noarch.rpm"). +

    Note: Some SuSE users have encountered a problem whereby +rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel is +installed. If this happens, simply use the --nodeps option to rpm (rpm -Uvh --nodeps <shorewall rpm>).
    -  

    -
  • -
  • See if there are any incompatibilities between your configuration and -the new Shorewall version (type "shorewall check") and correct as necessary.
  • -
  • Restart the firewall (shorewall restart).
  • - -
- -

If you already have Shorewall installed -and are upgrading to a new version using the tarball:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version -and you have entries in the /etc/shorewall/hosts file then please check -your /etc/shorewall/interfaces file to be sure that it contains an entry -for each interface mentioned in the hosts file.  Also, there are certain -1.2 rule forms that are no longer supported under 1.3 (you must use the -new 1.3 syntax). See the upgrade issues -for details. You can check your rules and host file for 1.3 compatibility -using the "shorewall check" command after installing the latest version -of 1.3.

- -
    -
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
  • -
  • cd to the shorewall directory (the version is encoded in the - directory name as in "shorewall-3.0.1").
  • -
  • If you are using Caldera, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
  • -
  • If you are using SuSe then type - "./install.sh /etc/init.d"
  • -
  • If your distribution has directory /etc/rc.d/init.d or -/etc/init.d then type "./install.sh"
  • -
  • For other distributions, determine where your distribution -installs init scripts and type "./install.sh <init script -directory>
  • +  

    +
  • See if there are any incompatibilities between your configuration and the new Shorewall version (type "shorewall check") and correct as necessary.
  • -
  • Restart the firewall by typing "shorewall restart"
  • - +
  • Restart the firewall (shorewall restart).
  • +
- -

Configuring Shorewall

- -

You will need to edit some or all of these configuration files to match -your setup. In most cases, the Shorewall - QuickStart Guides contain all of the information you need.

- + +

If you already have Shorewall installed and +are upgrading to a new version using the tarball:

+ +

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and +you have entries in the /etc/shorewall/hosts file then please check your + /etc/shorewall/interfaces file to be sure that it contains an entry for +each interface mentioned in the hosts file.  Also, there are certain 1.2 +rule forms that are no longer supported under 1.3 (you must use the new +1.3 syntax). See the upgrade issues for +details. You can check your rules and host file for 1.3 compatibility using +the "shorewall check" command after installing the latest version of 1.3.

+
    -
  • /etc/shorewall/shorewall.conf - used to set several firewall - parameters.
  • -
  • /etc/shorewall/params - use this file to set shell variables that -you will expand in other files.
  • -
  • /etc/shorewall/zones - partition the firewall's view of the world - into zones.
  • -
  • /etc/shorewall/policy - establishes firewall high-level policy.
  • -
  • /etc/shorewall/interfaces - describes the interfaces on the - firewall system.
  • -
  • /etc/shorewall/hosts - allows defining zones in terms of individual - hosts and subnetworks.
  • -
  • /etc/shorewall/masq - directs the firewall where to use many-to-one - (dynamic) NAT a.k.a. Masquerading.
  • -
  • /etc/shorewall/modules - directs the firewall to load kernel modules.
  • -
  • /etc/shorewall/rules - defines rules that are exceptions to the - overall policies established in /etc/shorewall/policy.
  • -
  • /etc/shorewall/nat - defines static NAT rules.
  • -
  • /etc/shorewall/proxyarp - defines use of Proxy ARP.
  • -
  • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines -hosts accessible when Shorewall is stopped.
  • -
  • /etc/shorewall/tcrules - defines marking of packets for later use -by traffic control/shaping.
  • -
  • /etc/shorewall/tos - defines rules for setting the TOS field in packet - headers.
  • -
  • /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on - the firewall system.
  • -
  • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
  • - +
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
  • +
  • cd to the shorewall directory (the version is encoded in the + directory name as in "shorewall-3.0.1").
  • +
  • If you are using Caldera, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
  • +
  • If you are using SuSe then type + "./install.sh /etc/init.d"
  • +
  • If your distribution has directory /etc/rc.d/init.d or +/etc/init.d then type "./install.sh"
  • +
  • For other distributions, determine where your distribution +installs init scripts and type "./install.sh <init script directory>
  • +
  • See if there are any incompatibilities between your configuration +and the new Shorewall version (type "shorewall check") and correct as necessary.
  • +
  • Restart the firewall by typing "shorewall restart"
  • +
- -

Updated 10/9/2002 - Tom Eastep + +

Configuring Shorewall

+ +

You will need to edit some or all of these configuration files to match +your setup. In most cases, the Shorewall + QuickStart Guides contain all of the information you need.

+ +
    +
  • /etc/shorewall/shorewall.conf - used to set several firewall + parameters.
  • +
  • /etc/shorewall/params - use this file to set shell variables that +you will expand in other files.
  • +
  • /etc/shorewall/zones - partition the firewall's view of the world + into zones.
  • +
  • /etc/shorewall/policy - establishes firewall high-level policy.
  • +
  • /etc/shorewall/interfaces - describes the interfaces on the + firewall system.
  • +
  • /etc/shorewall/hosts - allows defining zones in terms of individual + hosts and subnetworks.
  • +
  • /etc/shorewall/maclist - verification of the MAC addresses of devices.
    +
  • +
  • /etc/shorewall/masq - directs the firewall where to use many-to-one + (dynamic) NAT a.k.a. Masquerading.
  • +
  • /etc/shorewall/modules - directs the firewall to load kernel modules.
  • +
  • /etc/shorewall/rules - defines rules that are exceptions to the + overall policies established in /etc/shorewall/policy.
  • +
  • /etc/shorewall/nat - defines static NAT rules.
  • +
  • /etc/shorewall/proxyarp - defines use of Proxy ARP.
  • +
  • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines +hosts accessible when Shorewall is stopped.
  • +
  • /etc/shorewall/tcrules - defines marking of packets for later use +by traffic control/shaping.
  • +
  • /etc/shorewall/tos - defines rules for setting the TOS field in packet + headers.
  • +
  • /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on + the firewall system.
  • +
  • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
  • + +
+ +

Updated 10/28/2002 - Tom Eastep

- -

Copyright + +

Copyright © 2001, 2002 Thomas M. Eastep.

-
+
+
diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html new file mode 100644 index 000000000..427184e89 --- /dev/null +++ b/STABLE/documentation/MAC_Validation.html @@ -0,0 +1,107 @@ + + + + MAC Verification + + + + + + + + + + + + + + +
+ +

MAC Verification
+

+
+
+
+ Beginning with Shorewall version 1.3.10, all traffic from an interface +or from a subnet on an interface can be verified to originate from a defined + set of MAC addresses. Furthermore, each MAC address may be optionally associated + with one or more IP addresses. There are four components to this facility.
+ +
    +
  1. The maclist interface option in /etc/shorewall/interfaces. When +this option is specified, all traffic arriving on the interface is subjet +to MAC verification.
  2. +
  3. The maclist option in /etc/shorewall/hosts. + When this option is specified for a subnet, all traffic from that subnet +is subject to MAC verification.
  4. +
  5. The /etc/shorewall/maclist file. This file is used to associate MAC + addresses with interfaces and to optionally associate IP addresses with +MAC addresses.
  6. +
  7. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables + in /etc/shorewall/shorewall.conf. The + MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and determines + the disposition of connection requests that fail MAC verification. The MACLIST_LOG_LEVEL + variable gives the syslogd level at which connection requests that fail +verification are to be logged. If set the the empty value (e.g., MACLIST_LOG_LEVEL="") + then failing connection requests are not logged.
    +
  8. + +
+ The columns in /etc/shorewall/maclist are:
+ +
    +
  • INTERFACE - The name of an ethernet interface on the Shorewall system.
  • +
  • MAC - The MAC address of a device on the ethernet segment connected + by INTERFACE. It is not necessary to use the Shorewall MAC format in this + column although you may use that format if you so choose.
  • +
  • IP Address - An optional comma-separated list of IP addresses for +the device whose MAC is listed in the MAC column.
  • + +
+ +

Example 1: Here are my files:

+ /etc/shorewall/shorewall.conf:
+
+
     MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info
+ /etc/shorewall/interfaces:
+ +
     #ZONE           INTERFACE       BROADCAST       OPTIONS
net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist
loc eth2 192.168.1.255 dhcp,filterping,maclist
dmz eth1 192.168.2.255 filterping
net eth3 206.124.146.255 filterping,blacklist
- texas 192.168.9.255 filterping
loc ppp+ - filterping
+ /etc/shorewall/maclist:
+ +
     #INTERFACE              MAC                     IP ADDRESSES (Optional)
eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie
eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry
eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa
eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)
eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap
+ As shown above, I use MAC Verification on my local + zone.
+ +

Example 2: Router in Local Zone

+ Suppose now that I add a second ethernet segment to my local zone and gateway + that segment via a router with MAC address 00:06:43:45:C6:15 and IP address + 192.168.1.253. Hosts in the second segment have IP addresses in the subnet + 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist + file:
+ +
     eth2                     00:06:43:45:C6:15       192.168.1.253,192.168.2.0/24
+ This entry accomodates traffic from the router itself (192.168.1.253) and + from the second LAN segment (192.168.2.0/24). Remember that all traffic +being sent to my firewall from the 192.168.2.0/24 segment will be forwarded +by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) + and not that of the host sending the traffic. +

Updated 10/23/2002 - Tom Eastep +

+ + + +

Copyright + © 2001, 2002 Thomas M. Eastep.

+
+
+
+
+ + diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 46a69385d..6016710da 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -1,1357 +1,1455 @@ - + Shorewall News - + - + - + - - - + + - - - + + + +
- +
+

Shorewall News Archive

-
- -

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

- + +

11/09/2002 - Shorewall 1.3.10

+

In this version:

    -
  • DNS Names - are now allowed in Shorewall config files (although I recommend against - using them).
  • -
  • The connection SOURCE may now be qualified by both interface -and IP address in a Shorewall rule.
  • -
  • Shorewall startup is now disabled after initial installation -until the file /etc/shorewall/startup_disabled is removed. This avoids -nasty surprises during reboot for users who install Shorewall but don't configure -it.
  • -
  • The 'functions' and 'version' files and the 'firewall' symbolic -link have been moved from /var/lib/shorewall to /usr/lib/shorewall to appease - the LFS police at Debian.
    -
  • - +
  • You may now define the contents of a zone +dynamically with the "shorewall +add" and "shorewall delete" commands. These commands are expected to +be used primarily within FreeS/Wan updown scripts.
  • +
  • Shorewall can now do MAC verification + on ethernet segments. You can specify the set of allowed MAC addresses +on the segment and you can optionally tie each MAC address to one or more +IP addresses.
  • +
  • PPTP Servers and Clients running on the firewall system may now be +defined in the /etc/shorewall/tunnels file.
  • +
  • A new 'ipsecnat' tunnel type is supported for use when the + remote IPSEC endpoint is behind a NAT gateway.
  • +
  • The PATH used by Shorewall may now be specified in /etc/shorewall/shorewall.conf.
  • +
  • The main firewall script is now /usr/lib/shorewall/firewall. The script +in /etc/init.d/shorewall is very small and uses /sbin/shorewall to do the +real work. This change makes custom distributions such as for Debian and +for Gentoo easier to manage since it is /etc/init.d/shorewall that tends +to have distribution-dependent code
- -

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. -
  3. The Site Search index was incomplete
  4. -
  5. Only one page of matches was presented.
  6. - -
-
- 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. -
  3. The Site Search index was incomplete
  4. -
  5. Only one page of matches was presented.
  6. - -
- Hopefully these problems are now corrected.
- -

9/18/2002 -  Debian 1.3.8 Packages Available
-

+

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.

- -

9/16/2002 - Shorewall 1.3.8

- + +

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

- +

+
    -
  • A NEWNOTSYN option -has been added to shorewall.conf. This option determines whether Shorewall - accepts TCP packets which are not part of an established connection -and that are not 'SYN' packets (SYN flag on and ACK flag off).
  • -
  • The need for the 'multi' option to communicate between zones - za and zb on the same interface is removed in the case where the chain - 'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
  • - -
      -
    • There is a policy for za to zb; or
    • -
    • There is at least one rule for za to zb.
    • +
    • DNS Names + are now allowed in Shorewall config files (although I recommend against + using them).
    • +
    • The connection SOURCE may now be qualified by both interface + and IP address in a Shorewall rule.
    • +
    • Shorewall startup is now disabled after initial installation + until the file /etc/shorewall/startup_disabled is removed. This avoids + nasty surprises during reboot for users who install Shorewall but don't + configure it.
    • +
    • The 'functions' and 'version' files and the 'firewall' symbolic + link have been moved from /var/lib/shorewall to /usr/lib/shorewall to +appease the LFS police at Debian.
      +
    • + +
    + +

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

    + 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. +
    3. The Site Search index was incomplete
    4. +
    5. Only one page of matches was presented.
    6. -
+ + + 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. +
  3. The Site Search index was incomplete
  4. +
  5. Only one page of matches was presented.
  6. + +
+ 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:
+

+
    -
  • The /etc/shorewall/blacklist file now contains three columns. - In addition to the SUBNET/ADDRESS column, there are optional PROTOCOL - and PORT columns to block only certain applications from the blacklisted - addresses.
    -
  • - -
- -

9/11/2002 - Debian 1.3.7c Packages Available

+
  • A NEWNOTSYN option + has been added to shorewall.conf. This option determines whether Shorewall + accepts TCP packets which are not part of an established connection +and that are not 'SYN' packets (SYN flag on and ACK flag off).
  • +
  • The need for the 'multi' option to communicate between + zones za and zb on the same interface is removed in the case where +the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
  • +
      +
    • There is a policy for za to zb; or
    • +
    • There is at least one rule for za to zb.
    • + +
    + + + +
      +
    • The /etc/shorewall/blacklist file now contains three +columns. In addition to the SUBNET/ADDRESS column, there are optional +PROTOCOL and PORT columns to block only certain applications from the +blacklisted addresses.
      +
    • + +
    + +

    9/11/2002 - Debian 1.3.7c Packages Available

    +

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

    - +

    9/2/2002 - Shorewall 1.3.7c

    - -

    This is a role up of a fix for "DNAT" rules where the source zone is $FW - (fw).

    - + +

    This is a role up of a fix for "DNAT" rules where the source zone is $FW + (fw).

    +

    8/31/2002 - I'm not available

    - -

    I'm currently on vacation  -- please respect my need for a couple of - weeks free of Shorewall problem reports.

    - + +

    I'm currently on vacation  -- please respect my need for a couple of +weeks free of Shorewall problem reports.

    +

    -Tom

    - +

    8/26/2002 - Shorewall 1.3.7b

    - -

    This is a role up of the "shorewall refresh" bug fix and the change which - reverses the order of "dhcp" and "norfc1918" checking.

    - + +

    This is a role up of the "shorewall refresh" bug fix and the change which + reverses the order of "dhcp" and "norfc1918" checking.

    +

    8/26/2002 - French FTP Mirror is Operational

    - +

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

    - + href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall + is now available.

    +

    8/25/2002 - Shorewall Mirror in France

    - -

    Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored - at http://france.shorewall.net.

    - + +

    Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored + at http://france.shorewall.net.

    +

    8/25/2002 - Shorewall 1.3.7a Debian Packages Available

    - -

    Lorenzo Martignoni reports that the packages for version 1.3.7a are available - at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - -

    8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author - -- Shorewall 1.3.7a releasedLorenzo Martignoni reports that the packages for version 1.3.7a are available + at http://security.dsi.unimi.it/~lorenzo/debian.html.

    + +

    8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author + -- Shorewall 1.3.7a released -

    - -

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

    - +

    + +

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

    +

    8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

    - +

    Features in this release include:

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

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

    - + +

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

    +

    8/13/2002 - Documentation in the CVS Repository

    - -

    The Shorewall-docs project now contains just the HTML and image files - -the Frontpage files have been removed.

    - + +

    The Shorewall-docs project now contains just the HTML and image files +- the Frontpage files have been removed.

    +

    8/7/2002 - STABLE branch added to CVS Repository

    - -

    This branch will only be updated after I release a new version of Shorewall - so you can always update from this branch to get the latest stable -tree.

    - -

    8/7/2002 - Upgrade Issues section added - to the Errata Page

    - -

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

    - + +

    This branch will only be updated after I release a new version of Shorewall + so you can always update from this branch to get the latest stable + tree.

    + +

    8/7/2002 - Upgrade Issues section +added to the Errata Page

    + +

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

    +

    8/7/2002 - Shorewall 1.3.6

    - +

    This is primarily a bug-fix rollup with a couple of new features:

    - + - +

    7/30/2002 - Shorewall 1.3.5b Released

    - +

    This interim release:

    - + - +

    7/29/2002 - New Shorewall Setup Guide Available

    - +

    The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. - The guide is intended for use by people who are setting up Shorewall - to manage multiple public IP addresses and by people who want to learn - more about Shorewall than is described in the single-address guides. - Feedback on the new guide is welcome.

    - + href="http://www.shorewall.net/shorewall_setup_guide.htm"> http://www.shorewall.net/shorewall_setup_guide.htm. + The guide is intended for use by people who are setting up Shorewall + to manage multiple public IP addresses and by people who want to +learn more about Shorewall than is described in the single-address +guides. Feedback on the new guide is welcome.

    +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    - -

    Lorenzo Martignoni reports that the packages are version 1.3.5a and are - available at Lorenzo Martignoni reports that the packages are version 1.3.5a and are + available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - -

    This will be the last Shorewall release for a while. I'm going to be - focusing on rewriting a lot of the documentation.

    - + +

    This will be the last Shorewall release for a while. I'm going to be +focusing on rewriting a lot of the documentation.

    +

     In this version:

    - +
      -
    • Empty and invalid source and destination qualifiers are - now detected in the rules file. It is a good idea to use the 'shorewall - check' command before you issue a 'shorewall restart' command be -be sure that you don't have any configuration problems that will -prevent a successful restart.
    • -
    • Added MERGE_HOSTS variable in shorewall.conf to provide saner behavior - of the /etc/shorewall/hosts file.
    • -
    • The time that the counters were last reset is now displayed - in the heading of the 'status' and 'show' commands.
    • -
    • A proxyarp option has been added for entries in - /etc/shorewall/interfaces. - This option facilitates Proxy ARP sub-netting as described in the Proxy - ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). - Specifying the proxyarp option for an interface causes Shorewall -to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • -
    • The Samples have been updated to reflect the new capabilities - in this release.
    • - +
    • Empty and invalid source and destination qualifiers +are now detected in the rules file. It is a good idea to use the +'shorewall check' command before you issue a 'shorewall restart' +command be be sure that you don't have any configuration problems +that will prevent a successful restart.
    • +
    • Added MERGE_HOSTS variable in shorewall.conf to provide saner behavior + of the /etc/shorewall/hosts file.
    • +
    • The time that the counters were last reset is now displayed + in the heading of the 'status' and 'show' commands.
    • +
    • A proxyarp option has been added for entries +in /etc/shorewall/interfaces. + This option facilitates Proxy ARP sub-netting as described in the Proxy + ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). + Specifying the proxyarp option for an interface causes Shorewall + to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • +
    • The Samples have been updated to reflect the new capabilities + in this release.
    • +
    - +

    7/16/2002 - New Mirror in Argentina

    - -

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

    - + +

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

    +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

    - +
      -
    • A new /etc/shorewall/routestopped - file has been added. This file is intended to eventually replace -the routestopped option in the /etc/shorewall/interface -and /etc/shorewall/hosts files. This new file makes remote firewall -administration easier by allowing any IP or subnet to be enabled while -Shorewall is stopped.
    • -
    • An /etc/shorewall/stopped extension script has been added. - This script is invoked after Shorewall has stopped.
    • -
    • A DETECT_DNAT_ADDRS option has been added to - /etc/shoreall/shorewall.conf. When -this option is selected, DNAT rules only apply when the destination -address is the external interface's primary IP address.
    • -
    • The QuickStart - Guide has been broken into three guides and has been almost +
    • A new +/etc/shorewall/routestopped file has been added. This file is +intended to eventually replace the routestopped option +in the /etc/shorewall/interface and /etc/shorewall/hosts files. +This new file makes remote firewall administration easier by allowing + any IP or subnet to be enabled while Shorewall is stopped.
    • +
    • An /etc/shorewall/stopped extension script has been added. + This script is invoked after Shorewall has stopped.
    • +
    • A DETECT_DNAT_ADDRS option has been added to + /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only apply when the destination + address is the external interface's primary IP address.
    • +
    • The QuickStart + Guide has been broken into three guides and has been almost entirely rewritten.
    • -
    • The Samples have been updated to reflect the new capabilities - in this release.
    • - +
    • The Samples have been updated to reflect the new capabilities + in this release.
    • +
    - +

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

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

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

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

    - -

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

    - + +

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

    + +

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

    +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    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:

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    - + +

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

    + - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

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

    - + +

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

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

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

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

    - + +

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

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

    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

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + - +

    Thanks, Lorenzo!

    - +

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

    - -

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

    - + +

    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:

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

    4/13/2002 - Hamburg Mirror now has FTP

    - +

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

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

    - + - +

    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:

    - + - +

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - +

    3/1/2002 - 1.2.8 Debian Package is Available

    - +

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

    - +

    2/25/2002 - New Two-interface Sample

    - -

    I've enhanced the two interface sample to allow access from the firewall - to servers in the local zone - - http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    - + +

    I've enhanced the two interface sample to allow access from the firewall + to servers in the local zone - + http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    +

    2/23/2002 - Shorewall 1.2.8 Released

    - -

    Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects - problems associated with the lock file used to prevent multiple state-changing - operations from occuring simultaneously. My apologies for any inconvenience - my carelessness may have caused.

    - + +

    Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects + problems associated with the lock file used to prevent multiple state-changing + operations from occuring simultaneously. My apologies for any inconvenience + my carelessness may have caused.

    +

    2/22/2002 - Shorewall 1.2.7 Released

    - +

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    - +

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

    - +

    2/8/2002 - Shorewall 1.2.6 Released

    - +

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - +

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

    - +

    2/1/2002 - Shorewall 1.2.5 Released

    - -

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

    - + +

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

    +

    In version 1.2.5:

    - +
      -
    • The installation problems have been corrected.
    • -
    • SNAT is now supported.
    • -
    • A "shorewall version" command has been added
    • -
    • The default value of the STATEDIR variable in /etc/shorewall/shorewall.conf - has been changed to /var/lib/shorewall in order to conform to the - GNU/Linux File Hierarchy Standard, Version 2.2.
    • - +
    • The installation problems have been corrected.
    • +
    • SNAT is now supported.
    • +
    • A "shorewall version" command has been added
    • +
    • The default value of the STATEDIR variable in /etc/shorewall/shorewall.conf + has been changed to /var/lib/shorewall in order to conform to +the GNU/Linux File Hierarchy Standard, Version 2.2.
    • +
    - +

    1/28/2002 - Shorewall 1.2.4 Released

    - +
      -
    • The "fw" zone may now be -given a different name.
    • -
    • You may now place end-of-line comments (preceded by '#') - in any of the configuration files
    • -
    • There is now protection against against two state changing - operations occuring concurrently. This is implemented using the -'lockfile' utility if it is available (lockfile is part of procmail); -otherwise, a less robust technique is used. The lockfile is created -in the STATEDIR defined in /etc/shorewall/shorewall.conf and has the -name "lock".
    • -
    • "shorewall start" no longer fails if "detect" is specified - in /etc/shorewall/interfaces - for an interface with subnet mask 255.255.255.255.
    • - +
    • The "fw" zone may now +be given a different name.
    • +
    • You may now place end-of-line comments (preceded by +'#') in any of the configuration files
    • +
    • There is now protection against against two state changing + operations occuring concurrently. This is implemented using the + 'lockfile' utility if it is available (lockfile is part of procmail); + otherwise, a less robust technique is used. The lockfile is created + in the STATEDIR defined in /etc/shorewall/shorewall.conf and has the + name "lock".
    • +
    • "shorewall start" no longer fails if "detect" is + specified in /etc/shorewall/interfaces + for an interface with subnet mask 255.255.255.255.
    • +
    - +

    1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    1/20/2002 - Corrected firewall script available 

    - -

    Corrects a problem with BLACKLIST_LOGLEVEL. See the - errata for details.

    - + +

    Corrects a problem with BLACKLIST_LOGLEVEL. See the + errata for details.

    +

    1/19/2002 - Shorewall 1.2.3 Released

    - +

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

    - +
      -
    • Support for TCP MSS Clamp to PMTU -- This support is usually - required when the internet connection is via PPPoE or PPTP and may - be enabled using the CLAMPMSS - option in /etc/shorewall/shorewall.conf.
    • - +
    • Support for TCP MSS Clamp to PMTU -- This support is +usually required when the internet connection is via PPPoE or PPTP +and may be enabled using the CLAMPMSS + option in /etc/shorewall/shorewall.conf.
    • +
    - +

    The following problems were corrected:

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

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

    - -

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

    - + +

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

    +

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

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

    +

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

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

    +

    1/8/2002 - Shorewall 1.2.2 Released

    - +

    In version 1.2.2

    - +
      -
    • Support for IP blacklisting has been added - +
    • Support for IP blacklisting has been added +
        -
      • You specify whether you want packets from blacklisted -hosts dropped or rejected using the BLACKLIST_DISPOSITION setting - in /etc/shorewall/shorewall.conf
      • -
      • You specify whether you want packets from blacklisted -hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL setting +
      • You specify whether you want packets from blacklisted + hosts dropped or rejected using the BLACKLIST_DISPOSITION setting in /etc/shorewall/shorewall.conf
      • -
      • You list the IP addresses/subnets that you wish to blacklist - in /etc/shorewall/blacklist
      • -
      • You specify the interfaces you want checked against the - blacklist using the new "blacklist" option in - /etc/shorewall/interfaces.
      • -
      • The black list is refreshed from /etc/shorewall/blacklist - by the "shorewall refresh" command.
      • - +
      • You specify whether you want packets from blacklisted + hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL setting + in /etc/shorewall/shorewall.conf
      • +
      • You list the IP addresses/subnets that you wish to +blacklist in /etc/shorewall/blacklist
      • +
      • You specify the interfaces you want checked against + the blacklist using the new "blacklist" option in + /etc/shorewall/interfaces.
      • +
      • The black list is refreshed from /etc/shorewall/blacklist + by the "shorewall refresh" command.
      • + +
      -
    • -
    • Use of TCP RST replies has been expanded  - +
    • +
    • Use of TCP RST replies has been expanded  +
        -
      • TCP connection requests rejected because of a REJECT -policy are now replied with a TCP RST packet.
      • -
      • TCP connection requests rejected because of a protocol=all - rule in /etc/shorewall/rules are now replied with a TCP RST +
      • TCP connection requests rejected because of a REJECT + policy are now replied with a TCP RST packet.
      • +
      • TCP connection requests rejected because of a protocol=all + rule in /etc/shorewall/rules are now replied with a TCP RST packet.
      • - + +
      -
    • -
    • A LOGFILE specification - has been added to /etc/shorewall/shorewall.conf. LOGFILE is used -to tell the /sbin/shorewall program where to look for Shorewall messages.
    • - + +
    • A LOGFILE specification + has been added to /etc/shorewall/shorewall.conf. LOGFILE is used + to tell the /sbin/shorewall program where to look for Shorewall messages.
    • +
    - +

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

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

    +
      -
    • Unless you have explicitly enabled Auth connections (tcp - port 113) to your firewall, these connections will be REJECTED rather - than DROPPED. This speeds up connection establishment to some servers.
    • -
    • Orphan DNS replies are now silently dropped.
    • - +
    • Unless you have explicitly enabled Auth connections +(tcp port 113) to your firewall, these connections will be REJECTED +rather than DROPPED. This speeds up connection establishment to +some servers.
    • +
    • Orphan DNS replies are now silently dropped.
    • +
    - +

    See the README file for upgrade instructions.

    - +

    1/1/2002 - Shorewall Mailing List Moving

    - -

    The Shorewall mailing list hosted at - Sourceforge is moving to Shorewall.net. If you are a current subscriber - to the list at Sourceforge, please see these instructions. - If you would like to subscribe to the new list, visit 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:

    - + - -

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

    - + +

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

    +

    Version 1.2 contains the following new features:

    - + - -

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

    - -

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

    - -
    + +

    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 +

    + +

    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. 

    - + target="_top">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:

    +
      -
    • Ping is now allowed between the zones.
    • -
    • In the three-interface configuration, it is now possible - to configure the internet services that are to be available to servers - in the DMZ. 
    • - +
    • Ping is now allowed between the zones.
    • +
    • In the three-interface configuration, it is now possible + to configure the internet services that are to be available to servers + in the DMZ. 
    • +
    - +

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

    - +

    In this version:

    - -
      -
    • The spelling of ADD_IP_ALIASES has been corrected in the - shorewall.conf file
    • -
    • The logic for deleting user-defined chains has been simplified - so that it avoids a bug in the LRP version of the 'cut' utility.
    • -
    • The /var/lib/lrpkg/shorwall.conf file has been corrected - to properly display the NAT entry in that file.
    • - -
    - -

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

    -

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

    -
      -
    • One Interface -- for a standalone system.
    • -
    • Two Interfaces -- A masquerading firewall.
    • -
    • Three Interfaces -- A masquerading firewall with DMZ.
    • - +
    • The spelling of ADD_IP_ALIASES has been corrected in +the shorewall.conf file
    • +
    • The logic for deleting user-defined chains has been +simplified so that it avoids a bug in the LRP version of the 'cut' +utility.
    • +
    • The /var/lib/lrpkg/shorwall.conf file has been corrected + to properly display the NAT entry in that file.
    • +
    - + +

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

    + +

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

    + +
      +
    • One Interface -- for a standalone system.
    • +
    • Two Interfaces -- A masquerading firewall.
    • +
    • Three Interfaces -- A masquerading firewall with DMZ.
    • + +
    +

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

    - -

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

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

    + +

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

    +

    In this version:

    - + - -

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

    - + +

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

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

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

    + +
      +
    • Support for nested zones has been improved. See the documentation for details
    • +
    • Shorewall now correctly checks the alternate configuration + directory for the 'zones' file.
    • +
    -

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

    +
      -
    • Support for nested zones has been improved. See the documentation for details
    • -
    • Shorewall now correctly checks the alternate configuration - directory for the 'zones' file.
    • - +
    • Shorewall now supports alternate configuration directories. + When an alternate directory is specified when starting or restarting + Shorewall (e.g., "shorewall -c /etc/testconf restart"), Shorewall + will first look for configuration files in the alternate directory +then in /etc/shorewall. To create an alternate configuration simply:
      + 1. Create a New Directory
      + 2. Copy to that directory any of your configuration files + that you want to change.
      + 3. Modify the copied files as needed.
      + 4. Restart Shorewall specifying the new directory.
    • +
    • The rules for allowing/disallowing icmp echo-requests + (pings) are now moved after rules created when processing the +rules file. This allows you to add rules that selectively allow/deny +ping based on source or destination address.
    • +
    • Rules that specify multiple client ip addresses or subnets + no longer cause startup failures.
    • +
    • Zone names in the policy file are now validated against + the zones file.
    • +
    • If you have packet mangling support +enabled, the "norfc1918" + interface option now logs and drops any incoming packets on the interface + that have an RFC 1918 destination address.
    • +
    - -

    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

    +
      -
    • Shorewall now supports alternate configuration directories. - When an alternate directory is specified when starting or restarting - Shorewall (e.g., "shorewall -c /etc/testconf restart"), Shorewall - will first look for configuration files in the alternate directory then - in /etc/shorewall. To create an alternate configuration simply:
      - 1. Create a New Directory
      - 2. Copy to that directory any of your configuration files -that you want to change.
      - 3. Modify the copied files as needed.
      - 4. Restart Shorewall specifying the new directory.
    • -
    • The rules for allowing/disallowing icmp echo-requests (pings) - are now moved after rules created when processing the rules file. - This allows you to add rules that selectively allow/deny ping based - on source or destination address.
    • -
    • Rules that specify multiple client ip addresses or subnets - no longer cause startup failures.
    • -
    • Zone names in the policy file are now validated against -the zones file.
    • -
    • If you have packet - mangling support enabled, the "norfc1918" interface option - now logs and drops any incoming packets on the interface that have - an RFC 1918 destination address.
    • - +
    • Shell variables can now be used to parameterize Shorewall + rules.
    • +
    • The second column in the hosts file may now contain +a comma-separated list.
      +
      + Example:
      +     sea    eth0:130.252.100.0/24,206.191.149.0/24
    • +
    • Handling of multi-zone interfaces has been improved. +See the documentation for +the /etc/shorewall/interfaces file.
    • +
    - -

    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

    +
      -
    • Shell variables can now be used to parameterize Shorewall - rules.
    • -
    • The second column in the hosts file may now contain a comma-separated - list.
      -
      - Example:
      -     sea    eth0:130.252.100.0/24,206.191.149.0/24
    • -
    • Handling of multi-zone interfaces has been improved. See - the documentation for the - /etc/shorewall/interfaces file.
    • - +
    • Several columns in the rules file may now contain comma-separated + lists.
    • +
    • Shorewall is now more rigorous in parsing the options + in /etc/shorewall/interfaces.
    • +
    • Complementation using "!" is now supported in rules.
    • +
    - -

    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

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

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

    +
      -
    • A "shorewall refresh" command has been added to allow for - refreshing the rules associated with the broadcast address on a dynamic - interface. This command should be used in place of "shorewall - restart" when the internet interface's IP address changes.
    • -
    • The /etc/shorewall/start file (if any) is now processed -after all temporary rules have been deleted. This change prevents -the accidental removal of rules added during the processing of that -file.
    • -
    • The "dhcp" interface option is now applicable to firewall - interfaces used by a DHCP server running on the firewall.
    • -
    • The RPM can now be built from the .tgz file using "rpm --tb" 
    • - +
    • Shorewall now enables Ipv4 Packet Forwarding by default. + Packet forwarding may be disabled by specifying IP_FORWARD=Off in + /etc/shorewall/shorewall.conf. If you don't want Shorewall to enable + or disable packet forwarding, add IP_FORWARDING=Keep to your + /etc/shorewall/shorewall.conf file.
    • +
    • The "shorewall hits" command no longer lists extraneous + service names in its last report.
    • +
    • Erroneous instructions in the comments at the head of + the firewall script have been corrected.
    • +
    - -

    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

    +
      -
    • Shorewall now enables Ipv4 Packet Forwarding by default. - Packet forwarding may be disabled by specifying IP_FORWARD=Off in - /etc/shorewall/shorewall.conf. If you don't want Shorewall to enable - or disable packet forwarding, add IP_FORWARDING=Keep to your -/etc/shorewall/shorewall.conf file.
    • -
    • The "shorewall hits" command no longer lists extraneous -service names in its last report.
    • -
    • Erroneous instructions in the comments at the head of the - firewall script have been corrected.
    • - +
    • The "tunnels" file really is in the RPM now.
    • +
    • SNAT can now be applied to port-forwarded connections.
    • +
    • A bug which would cause firewall start failures in some + dhcp configurations has been fixed.
    • +
    • The firewall script now issues a message if you have +the name of an interface in the second column in an entry in /etc/shorewall/masq + and that interface is not up.
    • +
    • You can now configure Shorewall so that it doesn't require the NAT and/or +mangle netfilter modules.
    • +
    • Thanks to Alex  Polishchuk, the "hits" command from + seawall is now in shorewall.
    • +
    • Support for IPIP tunnels has +been added.
    • +
    - -

    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

    +
      -
    • The "tunnels" file really is in the RPM now.
    • -
    • SNAT can now be applied to port-forwarded connections.
    • -
    • A bug which would cause firewall start failures in some -dhcp configurations has been fixed.
    • -
    • The firewall script now issues a message if you have the - name of an interface in the second column in an entry in /etc/shorewall/masq - and that interface is not up.
    • -
    • You can now configure Shorewall so that it doesn't require the NAT and/or mangle -netfilter modules.
    • -
    • Thanks to Alex  Polishchuk, the "hits" command from -seawall is now in shorewall.
    • -
    • Support for IPIP tunnels has been - added.
    • - -
    - -

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

    - - - +

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

    - +
      -
    • The TOS rules are now deleted when the firewall is stopped.
    • -
    • The .rpm will now install regardless of which version of - iptables is installed.
    • -
    • The .rpm will now install without iproute2 being installed.
    • -
    • The documentation has been cleaned up.
    • -
    • The sample configuration files included in Shorewall have - been formatted to 80 columns for ease of editing on a VGA console.
    • - +
    • The TOS rules are now deleted when the firewall is stopped.
    • +
    • The .rpm will now install regardless of which version + of iptables is installed.
    • +
    • The .rpm will now install without iproute2 being installed.
    • +
    • The documentation has been cleaned up.
    • +
    • The sample configuration files included in Shorewall +have been formatted to 80 columns for ease of editing on a VGA +console.
    • +
    - -

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

    - + +

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

    +
      -
    • You may now rate-limit - the packet log.
    • -
    •  Previous -versions of Shorewall have an implementation of Static NAT which -violates the principle of least surprise.  NAT only occurs for packets -arriving at (DNAT) or send from (SNAT) the interface named in the -INTERFACE column of /etc/shorewall/nat. Beginning with version 1.1.6, -NAT effective regardless of which interface packets come from or are -destined to. To get compatibility with prior versions, I have added a -new "ALL "ALL INTERFACES"  column to /etc/shorewall/nat. - By placing "no" or "No" in the new column, the NAT behavior of - prior versions may be retained. 
    • -
    • The treatment of IPSEC -Tunnels where the remote gateway is a standalone system has been -improved. Previously, it was necessary to include an additional -rule allowing UDP port 500 traffic to pass through the tunnel. Shorewall -will now create this rule automatically when you place the name of -the remote peer's zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
    • - +
    • You may now rate-limit + the packet log.
    • +
    •  Previous + versions of Shorewall have an implementation of Static NAT which + violates the principle of least surprise.  NAT only occurs for +packets arriving at (DNAT) or send from (SNAT) the interface named +in the INTERFACE column of /etc/shorewall/nat. Beginning with version +1.1.6, NAT effective regardless of which interface packets come from +or are destined to. To get compatibility with prior versions, I have +added a new "ALL "ALL INTERFACES"  column +to /etc/shorewall/nat. By placing "no" or "No" in the new column, + the NAT behavior of prior versions may be retained. 
    • +
    • The treatment of IPSEC + Tunnels where the remote gateway is a standalone system has been + improved. Previously, it was necessary to include an additional + rule allowing UDP port 500 traffic to pass through the tunnel. Shorewall + will now create this rule automatically when you place the name of + the remote peer's zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
    • +
    - -

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

    - + +

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

    + - -

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

    - + +

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

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

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

    - + +

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

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

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

    - + +

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

    +
      -
    • Port redirection now works again.
    • -
    • The icmpdef and common chains Port redirection now works again.
    • +
    • The icmpdef and common chains may now be user-defined.
    • -
    • The firewall no longer fails to start if "routefilter" -is specified for an interface that isn't started. A warning message -is now issued in this case.
    • -
    • The LRP Version is renamed "shorwall" for 8,3 MSDOS file - system compatibility.
    • -
    • A couple of LRP-specific problems were corrected.
    • - +
    • The firewall no longer fails to start if "routefilter" + is specified for an interface that isn't started. A warning message + is now issued in this case.
    • +
    • The LRP Version is renamed "shorwall" for 8,3 MSDOS +file system compatibility.
    • +
    • A couple of LRP-specific problems were corrected.
    • +
    - +

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

    - +

    +

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

    - +
      -
    • The common chain is traversed from INPUT, OUTPUT and FORWARD - before logging occurs
    • -
    • The source has been cleaned up dramatically
    • -
    • DHCP DISCOVER packets with RFC1918 source addresses no -longer generate log messages. Linux DHCP clients generate such packets -and it's annoying to see them logged. 
    • - +
    • The common chain is traversed from INPUT, OUTPUT and +FORWARD before logging occurs
    • +
    • The source has been cleaned up dramatically
    • +
    • DHCP DISCOVER packets with RFC1918 source addresses +no longer generate log messages. Linux DHCP clients generate such +packets and it's annoying to see them logged. 
    • +
    - +

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

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

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

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

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

    - + +

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

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

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

    - -

    Updated 10/9/2002 - Tom Eastep -

    - -

    Copyright2001, 2002 Thomas M. 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 11/09/2002 - Tom Eastep +

    + +

    +Copyright © 2001, 2002 Thomas M. Eastep.

    +
    +

    +



    diff --git a/STABLE/documentation/PPTP.htm b/STABLE/documentation/PPTP.htm index b8a61e6c4..21aa4560b 100644 --- a/STABLE/documentation/PPTP.htm +++ b/STABLE/documentation/PPTP.htm @@ -1,575 +1,411 @@ + - - - - - -Shorewall PPTP + + + + + + + + + Shorewall PPTP - - - - - - - + + +
    -

    PPTP

    -
    + + + + + +
    +

    PPTP

    +
    - +

    Shorewall easily supports PPTP in a number of configurations:

    + +

    1. PPTP Server Running on your Firewall

    -

    I will try to give you an idea of how to set up a PPTP server -on your firewall system. This isn't a detailed HOWTO but rather an example of -how I have set up a working PPTP server on my own firewall.

    + +

    I will try to give you an idea of how to set up a PPTP server on your firewall +system. This isn't a detailed HOWTO but rather an example of how I have set +up a working PPTP server on my own firewall.

    +

    The steps involved are:

    +
      -
    1. Patching and building pppd
    2. -
    3. Patching and building your Kernel
    4. -
    5. Configuring Samba
    6. -
    7. Configuring pppd
    8. -
    9. Configuring pptpd
    10. -
    11. Configuring Shorewall
    12. +
    13. Patching and building pppd
    14. +
    15. Patching and building your Kernel
    16. +
    17. Configuring Samba
    18. +
    19. Configuring pppd
    20. +
    21. Configuring pptpd
    22. +
    23. Configuring Shorewall
    24. +
    +

    Patching and Building pppd

    +

    To run pppd on a 2.4 kernel, you need the pppd 2.4.1 or later. The primary -site for releases of pppd is ftp://ftp.samba.org/pub/ppp.

    + site for releases of pppd is ftp://ftp.samba.org/pub/ppp.

    +

    You will need the following patches:

    + -

    You may also want the following patch if you want to require remote hosts to -use encryption:

    + +

    You may also want the following patch if you want to require remote hosts +to use encryption:

    + +

    Un-tar the pppd source and uncompress the patches into one directory (the -patches and the ppp-2.4.1 directory are all in a single parent directory):

    + patches and the ppp-2.4.1 directory are all in a single parent directory):

    +
      -
    • cd ppp-2.4.1
    • -
    • patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
    • -
    • patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
    • -
    • (Optional) patch -p1 < ../require-mppe.diff
    • -
    • ./configure
    • -
    • make
    • +
    • cd ppp-2.4.1
    • +
    • patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
    • +
    • patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
    • +
    • (Optional) patch -p1 < ../require-mppe.diff
    • +
    • ./configure
    • +
    • make
    • +
    -

    You will need to install the resulting binary on your firewall system. To do -that, I NFS mount my source filesystem and use "make install" from the + +

    You will need to install the resulting binary on your firewall system. +To do that, I NFS mount my source filesystem and use "make install" from the ppp-2.4.1 directory.

    +

    Patching and Building your Kernel

    +

    You will need one of the following patches depending on your kernel version:

    + +

    Uncompress the patch into the same directory where your top-level kernel -source is located and:

    + source is located and:

    +
      -
    • cd <your GNU/Linux source top-level directory>
    • -
    • patch -p1 < ../linux-2.4.16-openssl-0.9.6b-mppe.patch
    • +
    • cd <your GNU/Linux source top-level directory>
    • +
    • patch -p1 < ../linux-2.4.16-openssl-0.9.6b-mppe.patch
    • +
    +

    Now configure your kernel. Here is my ppp configuration:

    -
    -

    -
    + +
    +

    +

    +
    +

    Configuring Samba

    -

    You will need a WINS server (Samba configured to run as a WINS server is -fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) is:

    -
    -
    [global]
    -     workgroup = TDM-NSTOP
    -     netbios name = WOOKIE
    -     server string = GNU/Linux Box
    -     encrypt passwords = Yes
    -     log file = /var/log/samba/%m.log
    -     max log size = 0
    -     socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    -     os level = 65
    -     domain master = True
    -     preferred master = True
    -     dns proxy = No
    -     wins support = Yes
    -     printing = lprng
    -
    -[homes]
    -     comment = Home Directories
    -     valid users = %S
    -     read only = No
    -     create mask = 0664
    -     directory mask = 0775
    -
    -[printers]
    -     comment = All Printers
    -     path = /var/spool/samba
    -     printable = Yes
    -
    + +

    You will need a WINS server (Samba configured to run as a WINS server is + fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) +is:

    + +
    +
    [global]
    workgroup = TDM-NSTOP
    netbios name = WOOKIE
    server string = GNU/Linux Box
    encrypt passwords = Yes
    log file = /var/log/samba/%m.log
    max log size = 0
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    os level = 65
    domain master = True
    preferred master = True
    dns proxy = No
    wins support = Yes
    printing = lprng

    [homes]
    comment = Home Directories
    valid users = %S
    read only = No
    create mask = 0664
    directory mask = 0775

    [printers]
    comment = All Printers
    path = /var/spool/samba
    printable = Yes
    +
    +

    Configuring pppd

    +

    Here is a copy of my /etc/ppp/options.poptop file:

    -
    + +

    ipparam PoPToP
    - lock
    - mtu 1490
    - mru 1490
    - ms-wins 192.168.1.3
    - ms-dns 206.124.146.177
    - multilink
    - proxyarp
    - auth
    - +chap
    - +chapms
    - +chapms-v2
    - ipcp-accept-local
    - ipcp-accept-remote
    - lcp-echo-failure 30
    - lcp-echo-interval 5
    - deflate 0
    - mppe-128
    - mppe-stateless
    - require-mppe
    - require-mppe-stateless

    -
    + lock
    + mtu 1490
    + mru 1490
    + ms-wins 192.168.1.3
    + ms-dns 206.124.146.177
    + multilink
    + proxyarp
    + auth
    + +chap
    + +chapms
    + +chapms-v2
    + ipcp-accept-local
    + ipcp-accept-remote
    + lcp-echo-failure 30
    + lcp-echo-interval 5
    + deflate 0
    + mppe-128
    + mppe-stateless
    + require-mppe
    + require-mppe-stateless

    +
    +

    Notes:

    +
      -
    • Since the firewall itself is acting as a WINS server, I have included the - firewall's internal IP as the 'ms-wins' value.
    • -
    • I have pointed the remote clients at my DNS server -- it has external - address 206.124.146.177.
    • -
    • I am requiring 128-bit stateless compression (my kernel is built with the - 'require-mppe.diff' patch mentioned above.
    • +
    • System 192.168.1.3 acts as a WINS server so I have included that +IP as the 'ms-wins' value.
    • +
    • I have pointed the remote clients at my DNS server -- it has external + address 206.124.146.177.
    • +
    • I am requiring 128-bit stateless compression (my kernel is built +with the 'require-mppe.diff' patch mentioned above.
    • +
    +

    Here's my /etc/ppp/chap-secrets:

    -
    + +

    Secrets for authentication using CHAP
    - # client        server    secret    - IP addresses
    - CPQTDM\\TEastep *         <shhhhhh> - 192.168.1.7
    - TEastep         *         - <shhhhhh> 192.168.1.7

    -
    -

    I am the only user who connects to the server but I may connect either with -or without a domain being specified. The system I connect from is my laptop so I -give it the same IP address when tunneled in as it has when it is in its docking -station.

    + # client        server    secret    IP addresses
    + CPQTDM\\TEastep *         <shhhhhh> 192.168.1.7
    + TEastep         *         <shhhhhh> 192.168.1.7

    +
    + +

    I am the only user who connects to the server but I may connect either +with or without a domain being specified. The system I connect from is my +laptop so I give it the same IP address when tunneled in at it has when I +use its wireless LAN card around the house.

    +

    You will also want the following in /etc/modules.conf:

    -
         alias ppp-compress-18 ppp_mppe
    -     alias ppp-compress-21 bsd_comp
    -     alias ppp-compress-24 ppp_deflate
    -     alias ppp-compress-26 ppp_deflate
    + +
         alias ppp-compress-18 ppp_mppe
    alias ppp-compress-21 bsd_comp
    alias ppp-compress-24 ppp_deflate
    alias ppp-compress-26 ppp_deflate
    +

    Configuring pptpd

    +

    PoPTop (pptpd) is available from http://poptop.lineo.com/.

    +

    Here is a copy of my /etc/pptpd.conf file:

    -
    + +

    option /etc/ppp/options.poptop
    - speed 115200
    - localip 192.168.1.254
    - remoteip 192.168.1.33-38

    -
    + speed 115200
    + localip 192.168.1.254
    + remoteip 192.168.1.33-38

    +
    +

    Notes:

    + +

    I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd:

    -
    + +

    #!/bin/sh
    - #
    - # /etc/rc.d/init.d/pptpd
    - #
    - # chkconfig: 5 12 85
    - # description: control pptp server
    - #
    -
    - case "$1" in
    - start)
    -     echo 1 > /proc/sys/net/ipv4/ip_forward
    -     modprobe ppp_async
    -     modprobe ppp_generic
    -     modprobe ppp_mppe
    -     modprobe slhc
    -     if /usr/local/sbin/pptpd; then
    -         touch /var/lock/subsys/pptpd
    -     fi
    -     ;;
    - stop)
    -     killall pptpd
    -     rm -f /var/lock/subsys/pptpd
    -     ;;
    - restart)
    -     killall pptpd
    -     if /usr/local/sbin/pptpd; then
    -         touch /var/lock/subsys/pptpd
    -     fi
    -     ;;
    - status)
    -     ifconfig
    -     ;;
    - *)
    -     echo "Usage: $0 {start|stop|restart|status}"
    -     ;;
    - esac

    -
    + #
    + # /etc/rc.d/init.d/pptpd
    + #
    + # chkconfig: 5 12 85
    + # description: control pptp server
    + #
    +
    + case "$1" in
    + start)
    +     echo 1 > /proc/sys/net/ipv4/ip_forward
    +     modprobe ppp_async
    +     modprobe ppp_generic
    +     modprobe ppp_mppe
    +     modprobe slhc
    +     if /usr/local/sbin/pptpd; then
    +         touch /var/lock/subsys/pptpd
    +     fi
    +     ;;
    + stop)
    +     killall pptpd
    +     rm -f /var/lock/subsys/pptpd
    +     ;;
    + restart)
    +     killall pptpd
    +     if /usr/local/sbin/pptpd; then
    +         touch /var/lock/subsys/pptpd
    +     fi
    +     ;;
    + status)
    +     ifconfig
    +     ;;
    + *)
    +     echo "Usage: $0 {start|stop|restart|status}"
    +     ;;
    + esac

    +
    +

    Configuring Shorewall

    +

    I consider hosts connected to my PPTP server to be just like local systems. -My key Shorewall entries are:

    + My key Shorewall entries are:

    +

    /etc/shorewall/zones:

    -
    - - - - - - - - - - - - - - - - + +
    +
    ZONEDISPLAYCOMMENTS
    netInternetThe Internet
    locLocalMy Local Network including remote PPTP clients
    + + + + + + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    netInternetThe Internet
    locLocalMy Local Network including remote PPTP clients
    -
    + +

    /etc/shorewall/interfaces:

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - + +
    +
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255noping,norfc1918
    loceth2192.168.1.255 
    -ppp+  
    + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255noping,norfc1918
    loceth2192.168.1.255 
    -ppp+  
    -
    + +

    /etc/shorewall/hosts:

    -
    - - - - - - - - - - - - - - - - + +
    +
    ZONEHOST(S)OPTIONS
    loceth2:192.168.1.0/24routestopped
    locppp+:192.168.1.0/24 
    + + + + + + + + + + + + + + + + + +
    ZONEHOST(S)OPTIONS
    loceth2:192.168.1.0/24routestopped
    locppp+:192.168.1.0/24 
    -
    + +

    /etc/shorewall/policy:

    -
    - - - - - - - - - - - - - + +
    +
    SOURCEDESTPOLICYLOG LEVEL
    loclocACCEPT 
    + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVEL
    loclocACCEPT 
    -
    -

    /etc/shorewall/rules:

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST - PROTODEST
    - PORT(S)
    SOURCE
    - PORT(S)
    ORIGINAL
    - DEST
    ACCEPTnetfwtcp1723  
    ACCEPTnetfw47-  
    ACCEPTfwnet47-  
    -
    -

    Note: I have multiple ppp interfaces on my firewall. If you - have a single ppp interface, you probably want:

    -

    /etc/shorewall/interfaces:

    -
    - - - - - - - + + +

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b):

    + +
    + +
    ZONEINTERFACEBROADCASTOPTIONS
    + + + + + + + + + + + - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)
    SOURCE
    + PORT(S)
    ORIGINAL
    + DEST
    ACCEPT neteth0206.124.146.255noping,norfc1918
    loceth2192.168.1.255 
    locppp0  
    -
    -

    and no entries in /etc/shorewall/hosts.

    -

    2. PPTP Server Running Behind your Firewall

    -

    If you have a single external IP address, add the following to your - /etc/shorewall/rules file:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST - PROTODEST
    - PORT(S)
    SOURCE
    - PORT(S)
    ORIGINAL
    - DEST
    DNATnetloc:<server address>tcp1723  
    DNATnetloc:<server address>47-  
    -

    If you have multiple external IP address and you want to forward a single <external -address>, add the following to your /etc/shorewall/rules file:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST - PROTODEST
    - PORT(S)
    SOURCE
    - PORT(S)
    ORIGINAL
    - DEST
    DNATnetloc:<server address>tcp1723-<external address>
    DNATnetloc:<server address>47--<external address>
    -

    3. PPTP Clients Running Behind your Firewall

    -

    You shouldn't have to take any special action for this case unless you wish -to connect multiple clients to the same external server. In that case, you will -need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html. -I recommend that you also add these two lines to your /etc/shorewall/modules -file: -

    -

    loadmodule ip_conntrack_pptp
    - loadmodule ip_nat_pptp -

    -

    4. PPTP Client Running on your Firewall.

    -

    The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.    -Rather than use the configuration script that comes with the client, I built my -own. I also build my own kernel as described above -rather than using the mppe package that is available with the client. My -/etc/ppp/options file is mostly unchanged from what came with the client (see -below).

    -

    The key elements of this setup are as follows: -

      -
    1. Define a zone for the remote network accessed via PPTP.
    2. -
    3. Associate that zone with a ppp interface.
    4. -
    5. Define rules for PPTP traffic to/from the firewall.
    6. -
    7. Define rules for traffic two and from the remote zone.
    8. -
    -

    Here are examples from my setup:

    -

    /etc/shorewall/zones

    -
    - - - - - - - - - - - -
    ZONEDISPLAYCOMMENTS
    cpqCompaqCompaq Intranet
    -
    -

    /etc/shorewall/interfaces

    -
    - - - - - - - - - - - - - -
    ZONEINTERFACEBROADCASTOPTIONS
    -ppp+  
    -
    -

    /etc/shorewall/hosts

    -
    - - - - - - - - - - - -
    ZONEHOST(S)OPTIONS
    -ppp+:!192.168.1.0/24 
    -
    -

    /etc/shorewall/rules

    -
    - - - - - - - - - - - - - - - - - + + + + + + + + + + + @@ -577,160 +413,487 @@ below).

    - - + + + + +
    ACTIONSOURCEDEST - PROTODEST
    - PORT(S)
    SOURCE
    - PORT(S)
    ORIGINAL
    - DEST
    ACCEPT fwnet tcp 1723    
    ACCEPTnetfw47-  
    ACCEPT net 47 -    
    +
    + +

    /etc/shoreawll/tunnels (For Shorewall versions 1.3.10 +and later)
    +

    +
    + + + + + + + + + + + + + + +
    TYPE
    +
    ZONE
    +
    GATEWAY
    +
    GATEWAY ZONE
    +
    pptpserver
    +
    net
    +
    0.0.0.0/0
    +

    +
    -

    I use the combination of interface and hosts file to define the 'cpq' zone -because I also run a PPTP server on my firewall (see above). Using this -technique allows me to distinguish clients of my own PPTP server from arbitrary -hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and -Compaq doesn't use that RFC1918 Class C subnet. -

    I use this script in /etc/init.d to control the client. The reason that I -disable ECN when connecting is that the Compaq tunnel servers don't do ECN yet -and reject the initial TCP connection request if I enable ECN :-( +


    +Note: I have multiple ppp interfaces on my firewall. If you have a single +ppp interface, you probably want:

    + +

    /etc/shorewall/interfaces:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255noping,norfc1918
    loceth2192.168.1.255 
    locppp0  
    +
    + +

    and no entries in /etc/shorewall/hosts.

    + +

    2. PPTP Server Running Behind +your Firewall

    + +

    If you have a single external IP address, add the following to your /etc/shorewall/rules +file:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)
    SOURCE
    + PORT(S)
    ORIGINAL
    + DEST
    DNATnetloc:<server address>tcp1723  
    DNATnetloc:<server address>47-  
    + +

    If you have multiple external IP address and you want to forward a single +<external address>, add the following to your /etc/shorewall/rules +file:

    + +

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)
    SOURCE
    + PORT(S)
    ORIGINAL
    + DEST
    DNATnetloc:<server address>tcp1723-<external address>
    DNATnetloc:<server address>47--<external address>
    +

    + +

    3. PPTP Clients Running Behind +your Firewall

    + +

    You shouldn't have to take any special action for this case unless you +wish to connect multiple clients to the same external server. In that case, +you will need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html. + I recommend that you also add these two lines to your /etc/shorewall/modules + file:

    + +
    +

    loadmodule ip_conntrack_pptp
    + loadmodule ip_nat_pptp

    +
    + +

    4. PPTP Client Running on your Firewall.

    + +

    The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.    + Rather than use the configuration script that comes with the client, I built +my own. I also build my own kernel as described above + rather than using the mppe package that is available with the client. My +/etc/ppp/options file is mostly unchanged from what came with the client +(see below).

    + +

    The key elements of this setup are as follows:

    + +
      +
    1. Define a zone for the remote network accessed via PPTP.
    2. +
    3. Associate that zone with a ppp interface.
    4. +
    5. Define rules for PPTP traffic to/from the firewall.
    6. +
    7. Define rules for traffic two and from the remote zone.
    8. + +
    + +

    Here are examples from my setup:

    + +

    /etc/shorewall/zones

    + +
    + + + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    cpqCompaqCompaq Intranet
    +
    + +

    /etc/shorewall/interfaces

    + +
    + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    -ppp+  
    +
    + +

    /etc/shorewall/hosts

    + +
    + + + + + + + + + + + + + + +
    ZONEHOST(S)OPTIONS
    -ppp+:!192.168.1.0/24 
    +
    + +

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b)

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)
    SOURCE
    + PORT(S)
    ORIGINAL
    + DEST
    ACCEPTfwnettcp1723  
    ACCEPTfwnet47-  
    +
    + +

    /etc/shorewall/tunnels (For Shorewall versions 1.3.10 and later)
    +

    -

    #!/bin/sh
    -#
    -# /etc/rc.d/init.d/pptp
    -#
    -# chkconfig: 5 60 85
    -# description: PPTP Link Control
    -#
    -NAME="Tandem"
    -ADDRESS=tunnel-tandem.compaq.com
    -USER='Tandem\tommy'
    -ECN=0
    -DEBUG=
    -
    -start_pptp() {
    -    echo $ECN > /proc/sys/net/ipv4/tcp_ecn
    -    if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
    -        touch /var/lock/subsys/pptp
    -        echo "PPTP Connection to $NAME Started"
    -    fi
    -}
    -
    -stop_pptp() {
    -    if killall /usr/sbin/pptp 2> /dev/null; then
    -        echo "Stopped pptp"
    -    else
    -        rm -f /var/run/pptp/*
    -    fi
    -
    -    # if killall pppd; then
    -    # echo "Stopped pppd"
    -    # fi
    -
    -    rm -f /var/lock/subsys/pptp
    -
    -    echo 1 > /proc/sys/net/ipv4/tcp_ecn
    -}
    -
    -
    -case "$1" in
    - start)
    -    echo "Starting PPTP Connection to ${NAME}..."
    -    start_pptp
    -    ;;
    - stop)
    -    echo "Stopping $NAME PPTP Connection..."
    -    stop_pptp
    -    ;;
    - restart)
    -    echo "Restarting $NAME PPTP Connection..."
    -    stop_pptp
    -    start_pptp
    -    ;;
    - status)
    -    ifconfig
    -    ;;
    - *)
    -    echo "Usage: $0 {start|stop|restart|status}"
    -    ;;
    -esac
    -
    -

    -

    Here's my /etc/ppp/options file: -

    -

    #
    -# Identify this connection
    -#
    -ipparam Compaq
    -#
    -# Lock the port
    -#
    -lock
    -#
    -# We don't need the tunnel server to authenticate itself
    -#
    -noauth
    -
    -+chap
    -+chapms
    -+chapms-v2
    -
    -multilink
    -mrru 1614
    -#
    -# Turn off transmission protocols we know won't be used
    -#
    -nobsdcomp
    -nodeflate
    -
    -#
    -# We want MPPE
    -#
    -mppe-128
    -mppe-stateless
    -
    -#
    -# We want a sane mtu/mru
    -#
    -mtu 1000
    -mru 1000
    -
    -#
    -# Time this thing out of it goes poof
    -#
    -lcp-echo-failure 10
    -lcp-echo-interval 10
    -

    -

    My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq -traffic through the PPTP tunnel: -

    -

    #/bin/sh
    + + + + + + + + + + + + + + + +
    TYPE
    +
    ZONE
    +
    GATEWAY
    +
    GATEWAY ZONE
    +
    pptpclient
    +
    net
    +
    0.0.0.0/0
    +

    +

    - case $6 in
    - Compaq)
    -     route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
    -     route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
    -     route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
    -     ...
    -     ;;
    - esac

    -

    Finally, I run the following script every five minutes under crond to - restart the tunnel if it fails:

         #!/bin/sh
    -     restart_pptp() {
    -         /sbin/service pptp stop
    -         sleep 10
    -         if /sbin/service pptp start; then
    -             /usr/bin/logger "PPTP Restarted"
    -         fi
    -     }
    -
    -     if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then
    -         exit 0
    -     fi
    -
    -     echo "Attempting to restart PPTP"
    -
    -     restart_pptp > /dev/null 2>&1 &
    -
    -

    Here's a script - and corresponding ip-up.local from Jerry - Vonau that controls two PPTP connections.

    -

    Last modified 7/11/2002 - Tom -Eastep

    -Copyright © 2001, 2002 Thomas M. Eastep. \ No newline at end of file + +

    I use the combination of interface and hosts file to define the 'cpq' zone +because I also run a PPTP server on my firewall (see above). Using this technique +allows me to distinguish clients of my own PPTP server from arbitrary hosts +at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and Compaq +doesn't use that RFC1918 Class C subnet.

    + +

    I use this script in /etc/init.d to control the client. The reason that +I disable ECN when connecting is that the Compaq tunnel servers don't do ECN +yet and reject the initial TCP connection request if I enable ECN :-(

    + +
    +

    #!/bin/sh
    + #
    + # /etc/rc.d/init.d/pptp
    + #
    + # chkconfig: 5 60 85
    + # description: PPTP Link Control
    + #
    + NAME="Tandem"
    + ADDRESS=tunnel-tandem.compaq.com
    + USER='Tandem\tommy'
    + ECN=0
    + DEBUG=
    +
    + start_pptp() {
    +     echo $ECN > /proc/sys/net/ipv4/tcp_ecn
    +     if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
    +         touch /var/lock/subsys/pptp
    +         echo "PPTP Connection to $NAME Started"
    +     fi
    + }
    +
    + stop_pptp() {
    +     if killall /usr/sbin/pptp 2> /dev/null; then
    +         echo "Stopped pptp"
    +     else
    +         rm -f /var/run/pptp/*
    +     fi
    +
    +     # if killall pppd; then
    +     # echo "Stopped pppd"
    +     # fi
    +
    +     rm -f /var/lock/subsys/pptp
    +
    +     echo 1 > /proc/sys/net/ipv4/tcp_ecn
    + }
    +
    +
    + case "$1" in
    + start)
    +     echo "Starting PPTP Connection to ${NAME}..."
    +     start_pptp
    +     ;;
    + stop)
    +     echo "Stopping $NAME PPTP Connection..."
    +     stop_pptp
    +     ;;
    + restart)
    +     echo "Restarting $NAME PPTP Connection..."
    +     stop_pptp
    +     start_pptp
    +     ;;
    + status)
    +     ifconfig
    +     ;;
    + *)
    +     echo "Usage: $0 {start|stop|restart|status}"
    +     ;;
    + esac
    +

    +
    + +

    Here's my /etc/ppp/options file:

    + +
    +

    #
    + # Identify this connection
    + #
    + ipparam Compaq
    + #
    + # Lock the port
    + #
    + lock
    + #
    + # We don't need the tunnel server to authenticate itself
    + #
    + noauth
    +
    + +chap
    + +chapms
    + +chapms-v2
    +
    + multilink
    + mrru 1614
    + #
    + # Turn off transmission protocols we know won't be used
    + #
    + nobsdcomp
    + nodeflate
    +
    + #
    + # We want MPPE
    + #
    + mppe-128
    + mppe-stateless
    +
    + #
    + # We want a sane mtu/mru
    + #
    + mtu 1000
    + mru 1000
    +
    + #
    + # Time this thing out of it goes poof
    + #
    + lcp-echo-failure 10
    + lcp-echo-interval 10

    +
    + +

    My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq + traffic through the PPTP tunnel:

    + +
    +

    #/bin/sh
    +
    + case $6 in
    + Compaq)
    +     route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
    +     route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
    +     route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
    +     ...
    +     ;;
    + esac

    +
    + +

    Finally, I run the following script every five minutes under crond to + restart the tunnel if it fails:

    + +
         #!/bin/sh
    restart_pptp() {
    /sbin/service pptp stop
    sleep 10
    if /sbin/service pptp start; then
    /usr/bin/logger "PPTP Restarted"
    fi
    }

    if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then
    exit 0
    fi

    echo "Attempting to restart PPTP"

    restart_pptp > /dev/null 2>&1 &
    + +

    Here's a script + and corresponding ip-up.local from Jerry Vonau that controls two PPTP connections.

    + +

    Last modified 10/23/2002 - Tom Eastep

    + +

    Copyright2001, 2002 Thomas M. Eastep.

    +
    +
    + + diff --git a/STABLE/documentation/Shorewall_index_frame.htm b/STABLE/documentation/Shorewall_index_frame.htm index 2bb250bd1..42a295f8d 100644 --- a/STABLE/documentation/Shorewall_index_frame.htm +++ b/STABLE/documentation/Shorewall_index_frame.htm @@ -1,114 +1,121 @@ - + - + - + - + Shorewall Index - + - + - - - + + - - - + + + - - - + + + + + + +
    - +
    +

    Shorewall

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

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

    Quick Search
    -

    -
    - + + +

    Extended Search

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    - +

    -

    -
    -
    -
    -
    -
    -
    -
    -
    +
    +

    diff --git a/STABLE/documentation/configuration_file_basics.htm b/STABLE/documentation/configuration_file_basics.htm index b7b76e842..c8657434e 100644 --- a/STABLE/documentation/configuration_file_basics.htm +++ b/STABLE/documentation/configuration_file_basics.htm @@ -1,300 +1,319 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
    +

    Configuration Files

    -
    - -

    Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must - run them through dos2unix -before you use them with Shorewall.

    - -

    Files

    - -

    Shorewall's configuration files are in the directory /etc/shorewall.

    - - - -

    Comments

    - -

    You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at the end -of any line, again by delimiting the comment from the rest of the line -with a pound sign.

    - -

    Examples:

    - -
    # This is a comment
    - -
    ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
    - -

    Line Continuation

    - -

    You may continue lines in the configuration files using the usual backslash -("\") followed immediately by a new line character.

    - -

    Example:

    - -
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap #Services running on the firewall
    - -

    Using DNS Names

    - -

    - -

    WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS names and - you are called out of bed at 2:00AM because Shorewall won't start as a result -of DNS problems then don't say that you were not forewarned.
    -

    - -

        -Tom
    -

    - -

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall -configuration files may be specified either as IP addresses or as DNS Names.
    -
    - DNS names in iptables rules aren't nearly as useful as they first appear. -When a DNS name appears in a rule, the iptables utility resolves the name -to one or more IP addresses and inserts those addresses into the rule. So -change in the DNS->IP address relationship that occur after the firewall -has started have absolutely no effect on the firewall's ruleset.

    - -

    If your firewall rules include DNS names then:

    - - - -

    Each DNS name much be fully qualified and include a minumum -of two periods (although one may be trailing). This restriction is imposed -by Shorewall to insure backward compatibility with existing configuration -files.
    -
    - Examples of valid DNS names:
    -

    - - - Examples of invalid DNS names:
    - - - DNS names may not be used as:
    - - - These are iptables restrictions and are not simply imposed for your inconvenience -by Shorewall.
    -
    - -

    Complementing an Address or Subnet

    - -

    Where specifying an IP address, a subnet or an interface, you can - precede the item with "!" to specify the complement of the item. For - example, !192.168.1.4 means "any host but 192.168.1.4".

    - -

    Comma-separated Lists

    - -

    Comma-separated lists are allowed in a number of contexts within the - configuration files. A comma separated list:

    - - - -

    Port Numbers/Service Names

    - -

    Unless otherwise specified, when giving a port number you can use - either an integer or a service name from /etc/services.

    - -

    Port Ranges

    - -

    If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>.

    - -

    Using Shell Variables

    - -

    You may use the file /etc/shorewall/params file to set shell variables -that you can then use in some of the other configuration files.

    - -

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally -within the Shorewall programs

    - -

    Example:

    - -
    -
    NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=noping,norfc1918
    -
    - -


    - Example (/etc/shorewall/interfaces record):

    - -
    -
    net $NET_IF $NET_BCAST $NET_OPTIONS
    -
    -
    + +

    Warning: If you copy or edit your + configuration files on a system running Microsoft Windows, you must + run them through dos2unix + before you use them with Shorewall.

    -

    The result will be the same as if the record had been written

    - -
    -
    net eth0 130.252.100.255 noping,norfc1918
    -
    -
    - -

    Variables may be used anywhere in the other configuration -files.

    +

    Files

    + +

    Shorewall's configuration files are in the directory /etc/shorewall.

    + + + +

    Comments

    + +

    You may place comments in configuration files by making the first non-whitespace + character a pound sign ("#"). You may also place comments at the end + of any line, again by delimiting the comment from the rest of the +line with a pound sign.

    + +

    Examples:

    + +
    # This is a comment
    + +
    ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
    + +

    Line Continuation

    + +

    You may continue lines in the configuration files using the usual backslash + ("\") followed immediately by a new line character.

    + +

    Example:

    + +
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap #Services running on the firewall
    + +

    Using DNS Names

    + +

    + +

    WARNING: I personally recommend strongly against + using DNS names in Shorewall configuration files. If you use DNS names and + you are called out of bed at 2:00AM because Shorewall won't start as a +result of DNS problems then don't say that you were not forewarned.
    +

    + +

        -Tom
    +

    + +

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall + configuration files may be specified either as IP addresses or as DNS Names.
    +
    + DNS names in iptables rules aren't nearly as useful as they first appear. + When a DNS name appears in a rule, the iptables utility resolves the name + to one or more IP addresses and inserts those addresses into the rule. +So change in the DNS->IP address relationship that occur after the firewall + has started have absolutely no effect on the firewall's ruleset.

    + +

    If your firewall rules include DNS names then:

    + + + +

    Each DNS name much be fully qualified and include a minumum + of two periods (although one may be trailing). This restriction is imposed + by Shorewall to insure backward compatibility with existing configuration + files.
    +
    + Examples of valid DNS names:
    +

    + + + Examples of invalid DNS names:
    + + + DNS names may not be used as:
    + + + These are iptables restrictions and are not simply imposed for your +inconvenience by Shorewall.
    +
    + +

    Complementing an Address or Subnet

    + +

    Where specifying an IP address, a subnet or an interface, you can + precede the item with "!" to specify the complement of the item. For + example, !192.168.1.4 means "any host but 192.168.1.4". There must +be no white space following the "!".

    + +

    Comma-separated Lists

    + +

    Comma-separated lists are allowed in a number of contexts within the + configuration files. A comma separated list:

    + + + +

    Port Numbers/Service Names

    + +

    Unless otherwise specified, when giving a port number you can use + either an integer or a service name from /etc/services.

    + +

    Port Ranges

    + +

    If you need to specify a range of ports, the proper syntax is <low + port number>:<high port number>. For example, + if you want to forward the range of tcp ports 4000 through 4100 to local +host 192.168.1.3, the entry in /etc/shorewall/rules is:
    +

    + +
         DNAT	net	loc:192.168.1.3	tcp	4000:4100
    + +

    Using Shell Variables

    + +

    You may use the /etc/shorewall/params file to set shell variables + that you can then use in some of the other configuration files.

    + +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally + within the Shorewall programs

    + +

    Example:

    + +
    +
    NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=noping,norfc1918
    +
    +


    + Example (/etc/shorewall/interfaces record):

    + +
    +
    net $NET_IF $NET_BCAST $NET_OPTIONS
    +
    +
    + +

    The result will be the same as if the record had been written

    + +
    +
    net eth0 130.252.100.255 noping,norfc1918
    +
    +
    + +

    Variables may be used anywhere in the other configuration + files.

    +

    Using MAC Addresses

    - -

    Media Access Control (MAC) addresses can be used to specify packet -source in several of the configuration files. To use this feature, -your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) -included.

    - -

    MAC addresses are 48 bits wide and each Ethernet Controller has a - unique MAC address.
    -
    - In GNU/Linux, MAC addresses are usually written as a series of 6 -hex numbers separated by colons. Example:
    -
    -      [root@gateway root]# ifconfig eth0
    -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    -      inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
    -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    -      RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
    -      TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
    -      collisions:30394 txqueuelen:100
    -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 Mb)
    -      Interrupt:11 Base address:0x1800
    -
    - Because Shorewall uses colons as a separator for address fields, -Shorewall requires MAC addresses to be written in another way. In -Shorewall, MAC addresses begin with a tilde ("~") and consist of 6 -hex numbers separated by hyphens. In Shorewall, the MAC address in -the example above would be written "~02-00-08-E3-FA-55".

    - + +

    Media Access Control (MAC) addresses can be used to specify packet + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + included.

    + +

    MAC addresses are 48 bits wide and each Ethernet Controller has a + unique MAC address.
    +
    + In GNU/Linux, MAC addresses are usually written as a series of +6 hex numbers separated by colons. Example:
    +
    +      [root@gateway root]# ifconfig eth0
    +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    +      inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
    +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    +      RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
    +      TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
    +      collisions:30394 txqueuelen:100
    +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 + Mb)
    +      Interrupt:11 Base address:0x1800
    +
    + Because Shorewall uses colons as a separator for address fields, + Shorewall requires MAC addresses to be written in another way. In +Shorewall, MAC addresses begin with a tilde ("~") and consist of 6 +hex numbers separated by hyphens. In Shorewall, the MAC address in +the example above would be written "~02-00-08-E3-FA-55".
    +

    +

    Note: It is not necessary to use the special Shorewall notation +in the /etc/shorewall/maclist file.
    +

    +

    Shorewall Configurations

    - -

    Shorewall allows you to have configuration directories other than /etc/shorewall. -The shorewall start and restart - commands allow you to specify an alternate configuration directory and - Shorewall will use the files in the alternate directory rather than the corresponding - files in /etc/shorewall. The alternate directory need not contain a complete - configuration; those files not in the alternate directory will be read from - /etc/shorewall.

    - -

    This facility permits you to easily create a test or temporary configuration - by:

    - + +

    Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start and restart + commands allow you to specify an alternate configuration directory and + Shorewall will use the files in the alternate directory rather than the + corresponding files in /etc/shorewall. The alternate directory need not +contain a complete configuration; those files not in the alternate directory +will be read from /etc/shorewall.

    + +

    This facility permits you to easily create a test or temporary configuration + by:

    +
      -
    1. copying the files that need modification from /etc/shorewall -to a separate directory;
    2. -
    3. modify those files in the separate directory; and
    4. -
    5. specifying the separate directory in a shorewall start or -shorewall restart command (e.g., shorewall -c /etc/testconfig restart - ).
    6. - +
    7. copying the files that need modification from /etc/shorewall + to a separate directory;
    8. +
    9. modify those files in the separate directory; and
    10. +
    11. specifying the separate directory in a shorewall start +or shorewall restart command (e.g., shorewall -c /etc/testconfig + restart ).
    12. +
    - -

    Updated 9/24/2002 - Tom Eastep -

    + +

    Updated 10/24/2002 - Tom Eastep +

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    -
    +
    +
    +
    +

    diff --git a/STABLE/documentation/dhcp.htm b/STABLE/documentation/dhcp.htm index c66b6fe65..d736f42eb 100644 --- a/STABLE/documentation/dhcp.htm +++ b/STABLE/documentation/dhcp.htm @@ -1,60 +1,82 @@ + - - - - - -DHCP + + + + + + + + + DHCP - - - - - - - + + +
    -

    DHCP

    -
    + + + + + +
    +

    DHCP

    +
    -

    DHCP Server on your firewall

    + +

    If you want to Run a DHCP Server on your firewall

    + -

    A Firewall Interface gets its IP Address via DHCP

    + +

    If a Firewall Interface gets its IP Address via DHCP

    + -

    Last updated 1/26/2002 - Tom -Eastep

    - -

    Copyright2001, 2002 Thomas M. Eastep.

    - + +

    Last updated 11/03/2002 - Tom Eastep

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    +
    - - \ No newline at end of file + diff --git a/STABLE/documentation/download.htm b/STABLE/documentation/download.htm index 5c4aff566..e9405790c 100644 --- a/STABLE/documentation/download.htm +++ b/STABLE/documentation/download.htm @@ -1,304 +1,310 @@ - + - + - + - + Download - + - - - + + - - - + + + +
    +

    Shorewall Download

    -
    - +

    I strongly urge you to read and print a copy of the Shorewall QuickStart Guide for the configuration that most closely matches your own.

    - +

    Once you've done that, download one of the modules:

    - + - +

    The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.

    - + and there is an documentation .deb that also contains the documentation.

    +

    Please verify the version that you have downloaded -- during the - release of a new version of Shorewall, the links below may point -to a newer or an older version than is shown below.

    - + release of a new version of Shorewall, the links below may point + to a newer or an older version than is shown below.

    + - +

    Once you have verified the version, check the - errata errata to see if there are updates that apply to the version - that you have downloaded.

    - + that you have downloaded.

    +

    WARNING - YOU CAN NOT SIMPLY - INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION - IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration -of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.

    - -

    Download Latest Version (1.3.9a): Remember that updates to the - mirrors occur 1-12 hours after an update to the primary site.

    - -
    + INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION + IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration + of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.

    + +

    Download Latest Version (1.3.10): Remember that updates to the + mirrors occur 1-12 hours after an update to the primary site.

    + +
    - - - - - - - - - - - - + + + + + + + + + + - - - - - + + + - - - - - - + + + + + - + - - - - - + + + + + - + - - - - - + + + - + - - - - - - + + + + + + - - - + .lrp + + +
    SERVER LOCATIONDOMAINHTTPFTP
    Washington State, USAShorewall.netDownload - .rpm
    - Download - .tgz 
    - Download - .lrp
    Download .rpm 
    - +
    SERVER LOCATIONDOMAINHTTPFTP
    Washington State, USAShorewall.netDownload .rpm
    + Download + .tgz 
    + Download + .lrp
    + Download .rpm 
    + Download .tgz 
    - Download .lrp
    Slovak RepublicShorewall.net +
    Slovak RepublicShorewall.netDownload .rpm
    - Download .tgz 
    - Download .lrp
    Download - .rpm  
    -   
    +
    Download - .tgz 
    -  
    +
    Download - .rpm
    Texas, USAInfohiiway.com
    Texas, USAInfohiiway.comDownload - .rpm
    -
    +
    Download - .tgz 
    -  
    +
    Download - .lrp
    Download .rpm  
    - Download .tgz 
    - Download - .lrp
    Hamburg, GermanyShorewall.net
    Hamburg, GermanyShorewall.net Download - .rpm
    - Download - .tgz
    - Download - .lrp

    +
    Download + .tgz
    + Download + .lrp
    Download - .rpm  
    -   
    +
    Download .tgz 
    - Download .lrp
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar +
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download - .rpm  
    -   
    +
    Download - .tgz 
    -  
    +
    - Download .lrp
    Download - .rpm  
    -   
    +
    Download - .tgz 
    -  
    +
    - Download .lrp
    Paris, FranceShorewall.netDownload - .rpm
    - Download - .tgz 
    - Download - .lrp
    Download - .rpm  
    - Download + Download .lrp
    Paris, FranceShorewall.netDownload + .rpm
    + Download .tgz 
    - Download + .lrp
    Download + .rpm  
    + Download + .tgz 
    + Download - .lrp
    -
    - +
    +

    Browse Download Sites:

    - -
    + +
    - - - - - - - - - - - - + + + + + + + + + + - - - - - - + + + + - - - - - - + + + + - - - - - - + + + + - - - - - + + + - - - - - - + + + - - - - - - - - - - + + + + + + + + +
    SERVER LOCATIONDOMAINHTTPFTP
    Washington State, USAShorewall.netBrowse +
    SERVER LOCATIONDOMAINHTTPFTP
    Washington State, USAShorewall.netBrowseBrowse
    Slovak RepublicShorewall.netBrowse +
    Slovak RepublicShorewall.netBrowse Browse
    Texas, USAInfohiiway.comBrowse +
    Texas, USAInfohiiway.comBrowseBrowse
    Hamburg, GermanyShorewall.netBrowse +
    Hamburg, GermanyShorewall.netBrowseBrowse
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar +
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
    FranceShorewall.net +
    FranceShorewall.netBrowse Browse
    California, USA (Incomplete)Sourceforge.netBrowseN/A
    California, USA (Incomplete)Sourceforge.netBrowseN/A
    -
    - +
    +

    CVS:

    - -
    + +

    The CVS repository at - cvs.shorewall.net contains the latest snapshots of the each Shorewall - component. There's no guarantee that what you find there will work at all.

    -
    - -

    Last Updated 9/26/2002 - contains the latest snapshots of the each Shorewall + component. There's no guarantee that what you find there will work at +all.

    +
    + +

    Last Updated 11/9/2002 - Tom Eastep

    - +

    Copyright - © 2001, 2002 Thomas M. Eastep.

    + © 2001, 2002 Thomas M. Eastep.

    +

    +


    diff --git a/STABLE/documentation/images/TomNTarry.png b/STABLE/documentation/images/TomNTarry.png new file mode 100644 index 000000000..2c8845665 Binary files /dev/null and b/STABLE/documentation/images/TomNTarry.png differ diff --git a/STABLE/documentation/images/netfilterlogo.png b/STABLE/documentation/images/netfilterlogo.png new file mode 100644 index 000000000..aef7adaca Binary files /dev/null and b/STABLE/documentation/images/netfilterlogo.png differ diff --git a/STABLE/documentation/images/openlogo-nd-50.png b/STABLE/documentation/images/openlogo-nd-50.png new file mode 100644 index 000000000..91f2a5c6f Binary files /dev/null and b/STABLE/documentation/images/openlogo-nd-50.png differ diff --git a/STABLE/documentation/mailing_list_problems.htm b/STABLE/documentation/mailing_list_problems.htm index 95adcd8c2..612ae8c83 100644 --- a/STABLE/documentation/mailing_list_problems.htm +++ b/STABLE/documentation/mailing_list_problems.htm @@ -1,49 +1,53 @@ - + - + - + - + Mailing List Problems - + - - - + + - - - + + + +
    +

    Mailing List Problems

    -
    - +

    Shorewall.net is currently experiencing mail delivery problems - to at least one address in each of the following domains:

    - -
    -
    -
    2020ca - delivery to this domain has been disabled (cause unknown)
    arundel.homelinux.org - delivery to this domain has been disabled (connection timed out, connection refused)
    excite.com - delivery to this domain has been disabled (cause unknown)
    epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
    familie-fleischhacker.de - (connection timed out)
    gmx.net - delivery to this domain has been disabled (cause unknown)
    hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
    intercom.net - delivery to this domain has been disabled (cause unknown)
    ionsphere.org - (connection timed out)
    initialcs.com - delivery to this domain has been disabled (cause unknown)
    intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
    khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
    kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
    littleblue.de - (connection timed out)
    navair.navy.mil - delivery to this domain has been disabled (A restriction in the system prevented delivery of the message)
    opermail.net - delivery to this domain has been disabled (cause unknown)
    penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
    scip-online.de - delivery to this domain has been disabled (cause unknown)
    spctnet.com - connection timed out - delivery to this domain has been disabled
    telusplanet.net - delivery to this domain has been disabled (cause unknown)
    yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
    -
    -
    - -

    Last updated 10/6/2002 20:30 GMT - + +

    +
    +
    2020ca - delivery to this domain has been disabled (cause unknown)
    arundel.homelinux.org - delivery to this domain has been disabled (connection timed out, connection refused)
    asurfer.com - (Mailbox full)
    cuscominc.com - delivery to this domain has been disable (bouncing mail from all sources with "Mail rejected because the server you are sending to is misconfigured").
    excite.com - delivery to this domain has been disabled (cause unknown)
    epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
    freefish.dyndns.org - delivery to this domain has been disabled (Name Server Problem -- Host not found)
    gmx.net - delivery to this domain has been disabled (cause unknown)
    hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
    intercom.net - delivery to this domain has been disabled (cause unknown)
    ionsphere.org - (connection timed out)
    initialcs.com - delivery to this domain has been disabled (cause unknown)
    intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
    khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
    kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
    littleblue.de - (connection timed out)
    navair.navy.mil - delivery to this domain has been disabled (A restriction in the system prevented delivery of the message)
    opermail.net - delivery to this domain has been disabled (cause unknown)
    opus.homeip.net - (SpamAssassin is missing the HiRes Time module)
    penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
    scip-online.de - delivery to this domain has been disabled (cause unknown)
    spctnet.com - connection timed out - delivery to this domain has been disabled
    telusplanet.net - delivery to this domain has been disabled (cause unknown)
    yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
    +
    +
    + +

    Last updated 11/3/2002 16:00 GMT - Tom Eastep

    - +

    Copyright © 2002 Thomas M. Eastep.

    - +

     

    +
    +
    +

    +

    diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index ed93a3856..cef30a5e6 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,133 +1,134 @@ - + My Shorewall Configuration - + - + - + - + - - - + + - - - + + + +
    +

    About My Network

    -
    - +
    - +

    My Current Network

    - -
    + +

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

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

    +

    I use:
    -

    - +

    +
      -
    • Static NAT for ursa (my XP System) - Internal address 192.168.1.5 - and external address 206.124.146.178.
    • -
    • Proxy ARP for wookie (my Linux System). This system has two IP -addresses: 192.168.1.3/24 and 206.124.146.179/24.
    • -
    • SNAT through the primary gateway address (206.124.146.176) for  -my Wife's system (tarry) and the Wireless Access Point (wap)
    • - +
    • Static NAT for ursa (my XP System) - Internal address 192.168.1.5 + and external address 206.124.146.178.
    • +
    • Proxy ARP for wookie (my Linux System). This system has two IP + addresses: 192.168.1.3/24 and 206.124.146.179/24.
    • +
    • SNAT through the primary gateway address (206.124.146.176) for  + my Wife's system (tarry) and the Wireless Access Point (wap)
    • +
    - +

    The firewall runs on a 128MB PII/233 with RH7.2 and Kernel 2.4.20-pre6.

    - +

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

    - + own 'whitelist' zone called 'me'.

    +

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

    - + It runs its own Sygate firewall software + and is managed by Proxy ARP. It connects to the local network through +the PopTop server running on my firewall.

    +

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

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

    +

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

    - + network.

    +

    All administration and publishing is done using ssh/scp.

    - +

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

    - + in the DMZ.

    +

    -

    - +

    +

     

    - +

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

    - + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because + of the entry in /etc/shorewall/proxyarp (see +below).

    +

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

    - +

    Note: My files - use features not available before Shorewall + use features not available before Shorewall version 1.3.4.

    -
    - -

    Shorewall.conf

    - -
    	SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall

    LOGRATE=
    LOGBURST=

    ADD_IP_ALIASES="Yes"

    CLAMPMSS=Yes

    MULTIPORT=Yes
    - -

    Zones File:

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

    Interfaces File:

    +
    -
    +

    Shorewall.conf

    + +
    	SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall

    LOGRATE=
    LOGBURST=

    ADD_IP_ALIASES="Yes"

    CLAMPMSS=Yes

    MULTIPORT=Yes
    + +

    Zones File:

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

    Interfaces File:

    + +

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

    -
    - -
    	#ZONE    INTERFACE	BROADCAST 	OPTIONS
    net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping
    loc eth2 192.168.1.255 dhcp
    dmz eth1 206.124.146.255 -
    net eth3 206.124.146.255 norfc1918
    - texas -
    loc ppp+
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    - +
    + +
    	#ZONE    INTERFACE	BROADCAST 	OPTIONS
    net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping
    loc eth2 192.168.1.255 dhcp,filterping,maclist
    dmz eth1 206.124.146.255 filterping
    net eth3 206.124.146.255 filterping,blacklist
    - texas - filterping
    loc ppp+ - filterping
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +

    Hosts File:

    - +
    	#ZONE 		HOST(S)			OPTIONS
    me eth2:192.168.1.3,eth2:206.124.146.179
    tx texas:192.168.9.0/24
    #LAST LINE -- ADD YOUR ENTRIES ABOVE -- DO NOT REMOVE
    - +

    Routestopped File:

    - +
    	#INTERFACE	HOST(S)
    eth1 206.124.146.177
    eth2 -
    eth3 206.124.146.180
    - +

    Common File:

    - +
    	. /etc/shorewall/common.def
    run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
    run_iptables -A common -p tcp --dport 113 -j REJECT
    - +

    Policy File:

    - +
    
     	#SOURCE	DEST	POLICY	LOG LEVEL	LIMIT:BURST
     	me	all	ACCEPT
    @@ -135,37 +136,39 @@ my Ethernet  interfaces. 

    all me CONTINUE #WARNING: You must be running Shorewall 1.3.1 or later for
    # this policy to work as expected!!!
    loc loc ACCEPT
    loc net ACCEPT
    $FW loc ACCEPT
    $FW tx ACCEPT
    loc tx ACCEPT
    loc fw REJECT
    net net ACCEPT
    net all DROP info 10/sec:40
    all all REJECT info
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTE
    - +

    Masq File:

    - -
    + +

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

    -
    - +
    +
    	#INTERFACE 	SUBNET		ADDRESS
    eth0 192.168.1.0/24 206.124.146.176
    texas 206.124.146.179 192.168.1.254
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - +

    NAT File:

    - +
    	#EXTERNAL	INTERFACE	INTERNAL	ALL	LOCAL
    206.124.146.178 eth0 192.168.1.5 No No
    206.124.146.179 eth0 192.168.1.3 No No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - +

    Proxy ARP File:

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

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

    - +
         	#ACTION		SOURCE 		DEST 			PROTO	DEST 	SOURCE  ORIGINAL
    # PORT(S) PORT(S) PORT(S) DEST
    #
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:info loc net tcp 6667
    #
    # Local Network to Firewall
    #
    ACCEPT loc fw tcp ssh
    ACCEPT loc fw tcp time
    #
    # Local Network to DMZ
    #
    ACCEPT loc dmz udp domain
    ACCEPT loc dmz tcp smtp
    ACCEPT loc dmz tcp domain
    ACCEPT loc dmz tcp ssh
    ACCEPT loc dmz tcp auth
    ACCEPT loc dmz tcp imap
    ACCEPT loc dmz tcp https
    ACCEPT loc dmz tcp imaps
    ACCEPT loc dmz tcp cvspserver
    ACCEPT loc dmz tcp www
    ACCEPT loc dmz tcp ftp
    ACCEPT loc dmz tcp pop3
    ACCEPT loc dmz icmp echo-request
    #
    # Internet to DMZ
    #
    ACCEPT net dmz tcp www
    ACCEPT net dmz tcp smtp
    ACCEPT net dmz tcp ftp
    ACCEPT net dmz tcp auth
    ACCEPT net dmz tcp https
    ACCEPT net dmz tcp imaps
    ACCEPT net dmz tcp domain
    ACCEPT net dmz tcp cvspserver
    ACCEPT net dmz udp domain
    ACCEPT net dmz icmp echo-request
    ACCEPT net:$MIRRORS dmz tcp rsync
    #
    # Net to Me (ICQ chat and file transfers)
    #
    ACCEPT net me tcp 4000:4100
    #
    # Net to Local
    #
    ACCEPT net loc tcp auth
    REJECT net loc tcp www
    #
    # DMZ to Internet
    #
    ACCEPT dmz net icmp echo-request
    ACCEPT dmz net tcp smtp
    ACCEPT dmz net tcp auth
    ACCEPT dmz net tcp domain
    ACCEPT dmz net tcp www
    ACCEPT dmz net tcp https
    ACCEPT dmz net tcp whois
    ACCEPT dmz net tcp echo
    ACCEPT dmz net udp domain
    ACCEPT dmz net:$NTPSERVERS udp ntp
    ACCEPT dmz net:$POPSERVERS tcp pop3
    #
    # The following compensates for a bug, either in some FTP clients or in the
    # Netfilter connection tracking code that occasionally denies active mode
    # FTP clients
    #
    ACCEPT:info dmz net tcp 1024: 20
    #
    # DMZ to Firewall -- snmp
    #
    ACCEPT dmz fw tcp snmp
    ACCEPT dmz fw udp snmp
    #
    # DMZ to Local Network
    #
    ACCEPT dmz loc tcp smtp
    ACCEPT dmz loc tcp auth
    ACCEPT dmz loc icmp echo-request
    # Internet to Firewall
    #
    ACCEPT net fw tcp 1723
    ACCEPT net fw gre
    REJECT net fw tcp www
    #
    # Firewall to Internet
    #
    ACCEPT fw net:$NTPSERVERS udp ntp
    ACCEPT fw net udp domain
    ACCEPT fw net tcp domain
    ACCEPT fw net tcp www
    ACCEPT fw net tcp https
    ACCEPT fw net tcp ssh
    ACCEPT fw net tcp whois
    ACCEPT fw net icmp echo-request
    #
    # Firewall to DMZ
    #
    ACCEPT fw dmz tcp www
    ACCEPT fw dmz tcp ftp
    ACCEPT fw dmz tcp ssh
    ACCEPT fw dmz tcp smtp
    ACCEPT fw dmz udp domain
    #
    # Let Texas Ping
    #
    ACCEPT tx fw icmp echo-request
    ACCEPT tx loc icmp echo-request

    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    - -

    Last updated 10/1/2002 - + +

    Last updated 10/14/2002 - Tom Eastep -

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

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


    diff --git a/STABLE/documentation/ports.htm b/STABLE/documentation/ports.htm index f205236fe..2ab74c0a0 100644 --- a/STABLE/documentation/ports.htm +++ b/STABLE/documentation/ports.htm @@ -1,122 +1,192 @@ + - - -Shorewall Port Information - - + + + Shorewall Port Information + + + + - - - - - - + + +
    -

    Ports required for Various Services/Applications

    -
    + + + + + +
    +

    Ports required for Various +Services/Applications

    +
    - -

    In addition to those applications described in the -/etc/shorewall/rules documentation, here are some other -services/applications that you may need to configure your firewall to accommodate.

    - + +

    In addition to those applications described in the /etc/shorewall/rules documentation, here +are some other services/applications that you may need to configure your firewall +to accommodate.

    +

    NTP (Network Time Protocol)

    -
    + +

    UDP Port 123

    -
    -

    rdate

    -
    +
    + +

    rdate

    + +

    TCP Port 37

    -
    -

    UseNet (NNTP)

    -
    +
    + +

    UseNet (NNTP)

    + +

    TCP Port 119

    -
    +
    +

    DNS

    -
    -

    UDP Port 53. If you are configuring a DNS client, you will probably want to - open TCP Port 53 as well.
    - If you are configuring a server, only open TCP Port 53 if you will return long - replies to queries or if you need to enable ZONE transfers. In the latter - case, be sure that your server is properly configured.

    -
    -

    ICQ   

    -
    -

    UDP Port 4000. You will also need to open a range of TCP ports which you - can specify to your ICQ client. By default, clients use 4000-4100.

    -
    + +
    +

    UDP Port 53. If you are configuring a DNS client, you will probably want +to open TCP Port 53 as well.
    + If you are configuring a server, only open TCP Port 53 if you will return +long replies to queries or if you need to enable ZONE transfers. In the +latter case, be sure that your server is properly configured.

    +
    + +

    ICQ   

    + +
    +

    UDP Port 4000. You will also need to open a range of TCP ports which +you can specify to your ICQ client. By default, clients use 4000-4100.

    +
    +

    PPTP

    -
    -

    Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more - information here).

    -
    + +
    +

    Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more information here).

    +
    +

    IPSEC

    -
    -

    Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port 500. - These should be opened in both directions.

    -
    + +
    +

    Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port +500. These should be opened in both directions.

    +
    +

    SMTP

    -
    -

     TCP Port 25.

    -
    + +
    +

     TCP Port 25.

    +
    +

    POP3

    -
    + +

    TCP Port 110.

    -
    +
    +

    TELNET

    -
    + +

    TCP Port 23.

    -
    +
    +

    SSH

    -
    + +

    TCP Port 22.

    -
    +
    +

    Auth (identd)

    -
    + +

    TCP Port 113

    -
    - -

    Web Access

    -
    +
    + +

    Web Access

    + +

    TCP Ports 80 and 443.

    -
    -

    FTP

    -
    -

    Server configuration is covered on in the - /etc/shorewall/rules documentation,

    +
    + +

    FTP

    + +
    +

    Server configuration is covered on in the /etc/shorewall/rules documentation,

    +

    For a client, you must open outbound TCP port 21 and be sure that your - kernel is compiled to support FTP connection tracking. If you build this - support as a module, Shorewall will automatically load the module from - /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 

    -
    - -

    SMB/NMB (Samba/Windows Browsing/File Sharing)

    -
    + kernel is compiled to support FTP connection tracking. If you build this + support as a module, Shorewall will automatically load the module from + /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
    +

    + +

    If you run an FTP server on a nonstandard port or you need to access +such a server, then you must specify that port in /etc/shorewall/modules. +For example, if you run an FTP server that listens on port 49 then you would +have:
    +

    + +
    +

    loadmodule ip_conntrack_ftp ports=21,49
    + loadmodule ip_nat_ftp ports=21,49
    +

    +
    + +

    Note that you MUST include port 21 in the ports list or you may +have problems accessing regular FTP servers.

    +

    If there is a possibility that these modules might be loaded before Shorewall +starts, then you should include the port list in /etc/modules.conf:
    +

    + +
    +

    options ip_conntrack_ftp ports=21,49
    + options ip_nat_ftp ports=21,49
    +

    +
    +
    + +

    SMB/NMB (Samba/Windows Browsing/File Sharing)

    + +
    + +

    TCP Ports 137, 139 and 445.
    - UDP Ports 137-139.
    -
    - Also, see this page.

    -
    - -

    Traceroute

    -
    + UDP Ports 137-139.
    +
    + Also, see this page.

    +
    + +

    Traceroute

    + +

    UDP ports 33434 through 33434+<max number of hops>-1

    -
    -

    NFS

    -
    -

    There's some good information at  - - http://nfs.sourceforge.net/nfs-howto/security.html

    -
    -

    Didn't find what you are looking for -- have you looked in your own - /etc/services file?

    - -

    Still looking? Try - - http://www.networkice.com/advice/Exploits/Ports

    - -

    Last updated 8/21/2002 - -Tom -Eastep

    -Copyright2001, 2002 Thomas M. Eastep. \ No newline at end of file +
    + +

    NFS

    + +
    +

    There's some good information at  http://nfs.sourceforge.net/nfs-howto/security.html

    +
    + +

    Didn't find what you are looking for -- have you looked in your own /etc/services +file?

    + +

    Still looking? Try http://www.networkice.com/advice/Exploits/Ports

    + +

    Last updated 10/22/2002 - Tom Eastep

    + Copyright + © 2001, 2002 Thomas M. Eastep.
    +
    + + diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index 1a87a34cc..d373b1aeb 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -2,362 +2,396 @@ - + + Shoreline Firewall (Shorewall) 1.3 - + + - + - - - + + - + +
    + + - - + + +
    +
    - + +

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

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

    + + + +

    This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the GNU +General Public License as published by the Free Software Foundation.
    +
    + This program is distributed + in the hope that it will be useful, but WITHOUT +ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General + Public License for more details.
    +
    + You should have received + a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, + Inc., 675 Mass Ave, Cambridge, MA 02139, USA

    - + + +

    Copyright 2001, 2002 Thomas M. Eastep

    - + + +

    - Jacques Nilo and Eric Wolzak have - a LEAF distribution called Bering that features - Shorewall-1.3.3 and Kernel-2.4.18. You can find their work at: - http://leaf.sourceforge.net/devel/jnilo

    + Jacques Nilo and + Eric Wolzak have a LEAF (router/firewall/gateway on a floppy, CD +or compact flash) distribution called Bering that + features Shorewall-1.3.9b and Kernel-2.4.18. You can find +their work at: http://leaf.sourceforge.net/devel/jnilo

    - + + + +

    Thinking of Downloading this Site for Offline Browsing?

    + You might want to reconsider -- this site is 213 MB!!! +and you will almost certainly be blacklisted before you download the whole +thing (my SDSL is only 384kbs so I'll have lots of time to catch you). Besides, +if you simply download the product and install it, you get the essential +parts of the site in a fraction of the time. And do you really want to download:
    + +
      +
    • Both text and HTML versions of every post ever made on three + different mailing lists (65 MB)?
    • +
    • Every .rpm, .tgz and .lrp ever released for both Shorewall + and Seawall (92MB and 10MB respectively)?
    • +
    • A 2.2.17-14 i586 RedHat Kernel RPM (6.9MB)?
      +
    • +
    • Several ancient RPMs for courier-imap and maildrop (1.5MB).
      +
    • + +
    + You get all that and more if you do a blind recurive copy of this site. + Happy downloading!
    +

    News

    - + + +

    - -

    10/9/2002 - Shorewall 1.3.9b (New) -

    -This release rolls up fixes to the installer and to the firewall script.
    -
    -10/6/2002 - Shorewall.net now running on RH8.0
    (New) -
    -
    - 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!!! -

    - Brown Paper Bag - There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
    - -


    -

    - -


    -

    - -


    - 9/28/2002 - Shorewall 1.3.9 

    - - -

    In this version:
    -

    - - -
      -
    • DNS - Names are now allowed in Shorewall config files (although I recommend - against using them).
    • -
    • The connection SOURCE may now be qualified by both - interface and IP address in a Shorewall - rule.
    • -
    • Shorewall startup is now disabled after initial installation - until the file /etc/shorewall/startup_disabled is removed. This avoids - nasty surprises at reboot for users who install Shorewall but don't -configure it.
    • -
    • The 'functions' and 'version' files and the 'firewall' - symbolic link have been moved from /var/lib/shorewall to /usr/lib/shorewall - to appease the LFS police at Debian.
      -
    • - - -
    - - -

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

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

    9/18/2002 - Debian 1.3.8 Packages Available  -
    -

    - - - -

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

    - - - -

    9/16/2002 - Shorewall 1.3.8

    - - - -

    In this version:
    -

    - - - -
      -
    • A NEWNOTSYN option has been added to -shorewall.conf. This option determines whether Shorewall accepts -TCP packets which are not part of an established connection and -that are not 'SYN' packets (SYN flag on and ACK flag off).
    • -
    • The need for the 'multi' option to communicate - between zones za and zb on the same interface is removed in the - case where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will -exist if: - - -
    • + +

      10/9/2002 - Shorewall 1.3.9b (New) +

      + This release rolls up fixes to the installer and to the +firewall script.
      +
      + 10/6/2002 - Shorewall.net now running on RH8.0
      (New) +
      +
      + 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!!! +

      + Brown Paper Bag + 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:
    +

    + + + +
      -
    • The /etc/shorewall/blacklist file now - contains three columns. In addition to the SUBNET/ADDRESS column, - there are optional PROTOCOL and PORT columns to block only certain - applications from the blacklisted addresses.
      -
    • +
    • DNS Names are now + allowed in Shorewall config files (although I recommend against + using them).
    • +
    • The connection SOURCE may now be +qualified by both interface and IP address in a Shorewall rule.
    • +
    • Shorewall startup is now disabled + after initial installation until the file /etc/shorewall/startup_disabled + is removed. This avoids nasty surprises at reboot for users +who install Shorewall but don't configure it.
    • +
    • The 'functions' and 'version' files + and the 'firewall' symbolic link have been moved from /var/lib/shorewall + to /usr/lib/shorewall to appease the LFS police at Debian.
      +
    • - + +
    - -

    9/11/2002 - Debian 1.3.7c Packages Available

    - -

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

    - - - -

    9/2/2002 - Shorewall 1.3.7c

    - - - - -

    This is a role up of a fix for "DNAT" rules where the source zone - is $FW (fw).

    - - - - -

    8/26/2002 - Shorewall 1.3.7b

    - - - - -

    This is a role up of the "shorewall refresh" bug fix and the change - which reverses the order of "dhcp" and "norfc1918" checking.

    - - - - -

    8/26/2002 - French FTP Mirror is Operational

    - - - - -

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

    - - - - -

    8/25/2002 - Shorewall Mirror in France

    - - - - -

    Thanks to a Shorewall user in Paris, the Shorewall web site is now - mirrored at http://france.shorewall.net.

    - - - - +

    More News

    - -

    Donations

    -
    M
    -
    -
    +

    Donations

    - + + M + + + + + + +
    +
    + + - - - + + - + + - - + + +
    - +
    - + + +

    -  

    +  

    - -

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

    -
    - -

    Updated 10/9/2002 - Tom Eastep - -
    -

    -
    + +

    Updated 11/9/2002 - Tom Eastep + +
    +

    diff --git a/STABLE/documentation/shoreline.htm b/STABLE/documentation/shoreline.htm index 51c72836f..ddb722719 100644 --- a/STABLE/documentation/shoreline.htm +++ b/STABLE/documentation/shoreline.htm @@ -1,113 +1,116 @@ - + About the Shorewall Author - + - + - + - + - - - + + - - - + + + +
    +
    +

    Tom Eastep

    -
    - -

    Tom on the PCT - 1991 -

    - -

    Tom on the Pacific Crest Trail north of Stevens Pass, - Washington  -- Sept 1991.
    - Photo by Ken Mazawa

    - + +

    Tom on the PCT - 1991 +

    + +

    Tarry & Tom -- August 2002
    +
    +

    + - +

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

    - +

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

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

    - + Washington where I live with my wife Tarry.

    +

    Our current home network consists of:

    - -
      -
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 8GB IDE HDs - and LNE100TX (Tulip) NIC - My personal Windows system. Also has SuSE - 8.0 installed.
    • -
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) NIC -- My personal Linux System which runs Samba configured as a WINS server. - This system also has VMware installed - and can run both Debian and - SuSE in virtual machines.
    • -
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  - Mail -(Postfix & Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), DNS server - (Bind).
    • -
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX  -(Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.9a  and a DHCP - server.  Also runs PoPToP for road warrior access.
    • -
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My wife's - personal system.
    • -
    • PII/400 Laptop, Win2k SP2, 224MB RAM, 12GB HD, onboard EEPRO100 - and EEPRO100 in expansion base and LinkSys WAC11 - My main work system.
    • - -
    - -

    For more about our network see my Shorewall Configuration.

    +
      +
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 8GB IDE +HDs and LNE100TX (Tulip) NIC - My personal Windows system. Also has +RedHat 8.0 installed.
    • +
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) NIC + - My personal Linux System which runs Samba configured as a WINS server. + This system also has VMware installed + and can run both Debian Woody +and SuSE 8.1 in virtual machines.
    • +
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  - Mail + (Postfix & Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), DNS server + (Bind).
    • +
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX  + (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.9a  and a DHCP + server.  Also runs PoPToP for road warrior access.
    • +
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My wife's + personal system.
    • +
    • PII/400 Laptop, Win2k SP2, 224MB RAM, 12GB HD, onboard EEPRO100 + and EEPRO100 in expansion base and LinkSys WAC11 - My main work system.
    • + +
    + +

    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.

    - +

    - - - -

    - -

    Last updated 10/6/2002 -

    + +

    Last updated 10/28/2002 - Tom Eastep

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



    diff --git a/STABLE/documentation/shorewall_features.htm b/STABLE/documentation/shorewall_features.htm index 02ac60f3d..87c11864a 100644 --- a/STABLE/documentation/shorewall_features.htm +++ b/STABLE/documentation/shorewall_features.htm @@ -1,91 +1,111 @@ + - - - - - -Shorewall Features + + + + + + + + + Shorewall Features - - - - - - - + + +
    -

    Shorewall Features

    -
    + + + + + +
    +

    Shorewall Features

    +
    +
      -
    • Uses Netfilter's connection tracking facilities for stateful packet - filtering.
    • -
    • Can be used in a wide range of router/firewall/gateway applications. -
        -
      • Completely customizable using configuration files.
      • -
      • No limit on the number of network interfaces.
      • -
      • Allows you to partitions the network into zones - and gives you complete control over the connections permitted between - each pair of zones.
      • -
      • Multiple interfaces per zone and multiple zones per interface - permitted.
      • -
      • Supports nested and overlapping zones.
      • -
      -
    • -
    • QuickStart Guides to help - get your first firewall up and running quickly
    • -
    • Extensive documentation - included in the .tgz and .rpm downloads.
    • -
    • Flexible address management/routing support (and you can use all - types in the same firewall): - -
    • -
    • Blacklisting of individual - IP addresses and subnetworks is supported.
    • -
    • Operational support: -
        -
      • Commands to start, stop and clear the firewall
      • -
      • Supports status monitoring - with an audible alarm when an "interesting" packet is detected.
      • -
      • Wide variety of informational commands.
      • -
      -
    • -
    • VPN Support - -
    • -
    • Support for Traffic Control/Shaping - integration.
    • -
    • Wide support for different GNU/Linux Distributions. - -
    • +
    • Uses Netfilter's connection tracking facilities for stateful packet + filtering.
    • +
    • Can be used in a wide range of router/firewall/gateway applications. + +
        +
      • Completely customizable using configuration files.
      • +
      • No limit on the number of network interfaces.
      • +
      • Allows you to partitions the network into zones and gives you complete +control over the connections permitted between each pair of zones.
      • +
      • Multiple interfaces per zone and multiple zones per interface + permitted.
      • +
      • Supports nested and overlapping zones.
      • + +
      +
    • +
    • QuickStart Guides to +help get your first firewall up and running quickly
    • +
    • Extensive documentation + included in the .tgz and .rpm downloads.
    • +
    • Flexible address management/routing support (and you can use +all types in the same firewall): + +
    • +
    • Blacklisting of individual + IP addresses and subnetworks is supported.
    • +
    • Operational support: + +
        +
      • Commands to start, stop and clear the firewall
      • +
      • Supports status monitoring with an audible alarm +when an "interesting" packet is detected.
      • +
      • Wide variety of informational commands.
      • + +
      +
    • +
    • VPN Support + +
    • +
    • Support for Traffic Control/Shaping + integration.
    • +
    • Wide support for different GNU/Linux Distributions. + + +
    • +
    • Media Access Control (MAC) Address + Verification
      +

      +
    • +
    -

    Last updated 7/14/2002 - Tom -Eastep

    -

    -Copyright © 2001,2002 Thomas M. Eastep.

    - + +

    Last updated 11/09/2002 - Tom Eastep

    + +

    Copyright © 2001,2002 Thomas M. Eastep.
    +

    - - \ No newline at end of file + diff --git a/STABLE/documentation/shorewall_quickstart_guide.htm b/STABLE/documentation/shorewall_quickstart_guide.htm index f3c896786..173ea0601 100644 --- a/STABLE/documentation/shorewall_quickstart_guide.htm +++ b/STABLE/documentation/shorewall_quickstart_guide.htm @@ -1,210 +1,220 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - + + - - - + Version 3.1 + + + +
    +

    Shorewall QuickStart Guides
    - Version 3.1

    -
    - -

    With thanks to Richard who reminded me once again that -we must all first walk before we can run.

    - + +

    With thanks to Richard who reminded me once again that we +must all first walk before we can run.

    +

    The Guides

    - -

    These guides provide step-by-step instructions for configuring Shorewall - in common firewall setups.

    - -

    The following guides are for users who have a single public IP address:

    - + +

    These guides provide step-by-step instructions for configuring Shorewall + in common firewall setups.

    + +

    The following guides are for users who have a single public IP address:

    +
      -
    • Standalone Linux System
    • -
    • Two-interface Linux System acting - as a firewall/router for a small local network
    • -
    • Three-interface Linux System acting - as a firewall/router for a small local network and a DMZ.
    • - +
    • Standalone Linux System
    • +
    • Two-interface Linux System acting + as a firewall/router for a small local network
    • +
    • Three-interface Linux System + acting as a firewall/router for a small local network and a DMZ.
    • +
    - -

    The above guides are designed to get your first firewall up and running - quickly in the three most common Shorewall configurations.

    - -

    The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple public - IP addresses involved or if you want to learn more about Shorewall than -is explained in the single-address guides above.

    - + +

    The above guides are designed to get your first firewall up and running + quickly in the three most common Shorewall configurations.

    + +

    The Shorewall Setup Guide outlines + the steps necessary to set up a firewall where there are multiple public + IP addresses involved or if you want to learn more about Shorewall than + is explained in the single-address guides above.

    + - +

    Additional Documentation

    - -

    The following documentation covers a variety of topics and supplements - the QuickStart Guides described - above. Please review the appropriate guide before trying to use this documentation -directly.

    - + +

    The following documentation covers a variety of topics and supplements + the QuickStart Guides described + above. Please review the appropriate guide before trying to use this + documentation directly.

    + + +
  • Configuration File Reference Manual + -
  • -
  • Proxy ARP
  • -
  • Samba
  • -
  • +
  • DHCP
  • +
  • Extension Scripts +(How to extend Shorewall without modifying Shorewall code)
  • +
  • Fallback/Uninstall
  • +
  • Firewall Structure
  • +
  • Kernel Configuration
  • +
  • My Configuration Files (How I personally + use Shorewall)
  • +
  • Port Information + +
      +
    • Which applications use which ports
    • +
    • Ports used by Trojans
    • + +
    +
  • +
  • Proxy ARP
  • +
  • Samba
  • +
  • Starting/stopping the Firewall
  • -
  • Static NAT
  • -
  • Traffic Shaping/Control
  • -
  • VPN +
  • Static NAT
  • +
  • Traffic Shaping/Control
  • +
  • VPN -
  • -
  • White List Creation
  • - + +
  • White List Creation
  • + - +

    If you use one of these guides and have a suggestion for improvement please let me know.

    - -

    Last modified 10/5/2002 - Last modified 11/3/2002 - Tom Eastep

    - +

    Copyright 2002 Thomas M. Eastep

    +
    +

    +


    diff --git a/STABLE/documentation/starting_and_stopping_shorewall.htm b/STABLE/documentation/starting_and_stopping_shorewall.htm index f216e4f9e..cad46fc6e 100644 --- a/STABLE/documentation/starting_and_stopping_shorewall.htm +++ b/STABLE/documentation/starting_and_stopping_shorewall.htm @@ -1,13 +1,13 @@ - + - + - + - + Starting and Stopping Shorewall @@ -15,211 +15,227 @@ - + - - + + - + - + - - + +
    - -

    Starting/Stopping and Monitoring -the Firewall

    +
    + +

    Starting/Stopping and Monitoring + the Firewall

    -
    - -

    If you have a permanent internet connection such as DSL or Cable, -I recommend that you start the firewall automatically at boot. Once you - have installed "firewall" in your init.d directory, simply type - "chkconfig --add firewall". This will start the firewall in run levels -2-5 and stop it in run levels 1 and 6. If you want to configure your firewall -differently from this default, you can use the "--level" option in - chkconfig (see "man chkconfig") or using your favorite graphical run-level -editor.

    - - - - - - - -

    Important Notes:
    -

    - -
      -
    1. Shorewall startup is disabled by default. Once you have configured -your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. -Note: Users of the .deb package must edit /etc/default/shorewall and set -'startup=1'.
      -
    2. -
    3. If you use dialup, you may want to start the firewall in your -/etc/ppp/ip-up.local script. I recommend just placing "shorewall restart" -in that script.
    4. - -
    - -

    -

    - - - -

    You can manually start and stop Shoreline Firewall using the "shorewall" +

    If you have a permanent internet connection such as DSL or Cable, + I recommend that you start the firewall automatically at boot. Once +you have installed "firewall" in your init.d directory, simply type + "chkconfig --add firewall". This will start the firewall in run levels + 2-5 and stop it in run levels 1 and 6. If you want to configure your +firewall differently from this default, you can use the "--level" option +in chkconfig (see "man chkconfig") or using your favorite graphical +run-level editor.

    + + + + + + + +

    Important Notes:
    +

    + +
      +
    1. Shorewall startup is disabled by default. Once you have configured + your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. + Note: Users of the .deb package must edit /etc/default/shorewall and set +'startup=1'.
      +
    2. +
    3. If you use dialup, you may want to start the firewall in your +/etc/ppp/ip-up.local script. I recommend just placing "shorewall restart" +in that script.
    4. + +
    + +

    +

    + + + + +

    You can manually start and stop Shoreline Firewall using the "shorewall" shell program:

    - +
      -
    • shorewall start - starts the firewall
    • -
    • shorewall stop - stops the firewall
    • -
    • shorewall restart - stops the firewall (if it's running) -and then starts it again
    • -
    • shorewall reset - reset the packet and byte counters - in the firewall
    • -
    • shorewall clear - remove all rules and chains installed -by Shoreline Firewall
    • -
    • shorewall refresh - refresh the rules involving the broadcast - addresses of firewall interfaces and the black and white lists.
    • - +
    • shorewall start - starts the firewall
    • +
    • shorewall stop - stops the firewall
    • +
    • shorewall restart - stops the firewall (if it's running) + and then starts it again
    • +
    • shorewall reset - reset the packet and byte counters + in the firewall
    • +
    • shorewall clear - remove all rules and chains installed + by Shoreline Firewall
    • +
    • shorewall refresh - refresh the rules involving the broadcast + addresses of firewall interfaces and the black and white lists.
    • +
    - +

    The "shorewall" program may also be used to monitor the firewall.

    - +
      -
    • shorewall status - produce a verbose report about the firewall - (iptables -L -n -v)
    • -
    • shorewall show chain - produce a verbose report about chain - (iptables -L chain -n -v)
    • -
    • shorewall show nat - produce a verbose report about the nat table - (iptables -t nat -L -n -v)
    • -
    • shorewall show tos - produce a verbose report about the mangle table - (iptables -t mangle -L -n -v)
    • -
    • shorewall show log - display the last 20 packet log entries.
    • -
    • shorewall show connections - displays the IP connections currently -being tracked by the firewall.
    • -
    • shorewall - show - tc - displays information -about the traffic control/shaping configuration.
    • -
    • shorewall monitor [ delay ] - Continuously display the firewall - status, last 20 log entries and nat. When the log entry display - changes, an audible alarm is sounded.
    • -
    • shorewall hits - Produces several reports about the Shorewall packet -log messages in the current /var/log/messages file.
    • -
    • shorewall version - Displays the installed version number.
    • -
    • shorewall check - Performs a cursory validation of the -zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate the -generated iptables commands so even though the "check" command completes -successfully, the configuration may fail to start. See the recommended -way to make configuration changes described below.
    • -
    • shorewall try configuration-directory [ timeout ] -- Restart shorewall using the specified configuration and if an error -occurs or if the timeout option is given and the new configuration -has been up for that many seconds then shorewall is restarted using the -standard configuration.
    • -
    • shorewall deny, shorewall reject, shorewall accept and shorewall -save implement dynamic blacklisting.
    • -
    • shorewall logwatch (added in version 1.3.2) - Monitors the LOGFILE and produces an audible alarm when new Shorewall - messages are logged.
    • - +
    • shorewall status - produce a verbose report about the firewall + (iptables -L -n -v)
    • +
    • shorewall show chain - produce a verbose report about chain + (iptables -L chain -n -v)
    • +
    • shorewall show nat - produce a verbose report about the nat table + (iptables -t nat -L -n -v)
    • +
    • shorewall show tos - produce a verbose report about the mangle +table (iptables -t mangle -L -n -v)
    • +
    • shorewall show log - display the last 20 packet log entries.
    • +
    • shorewall show connections - displays the IP connections currently + being tracked by the firewall.
    • +
    • shorewall + show + tc - displays information + about the traffic control/shaping configuration.
    • +
    • shorewall monitor [ delay ] - Continuously display the firewall + status, last 20 log entries and nat. When the log entry display + changes, an audible alarm is sounded.
    • +
    • shorewall hits - Produces several reports about the Shorewall packet + log messages in the current /var/log/messages file.
    • +
    • shorewall version - Displays the installed version number.
    • +
    • shorewall check - Performs a cursory validation of +the zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate the + generated iptables commands so even though the "check" command completes + successfully, the configuration may fail to start. See the recommended + way to make configuration changes described below.
    • +
    • shorewall try configuration-directory [ timeout ] +- Restart shorewall using the specified configuration and if an error + occurs or if the timeout option is given and the new configuration + has been up for that many seconds then shorewall is restarted using +the standard configuration.
    • +
    • shorewall deny, shorewall reject, shorewall accept and shorewall + save implement dynamic blacklisting.
    • +
    • shorewall logwatch (added in version 1.3.2) - Monitors the LOGFILE and produces an audible alarm when new Shorewall + messages are logged.
    • +
    +Finally, the "shorewall" program may be used to dynamically alter the contents +of a zone.
    +
      +
    • shorewall add interface[:host] zone - Adds the +specified interface (and host if included) to the specified zone.
    • +
    • shorewall delete interface[:host] zone - Deletes +the specified interface (and host if included) from the specified zone.
    • +
    +
    Examples:
    +
    shorewall add ipsec0:192.0.2.24 vpn1 -- adds the address 192.0.2.24 +from interface ipsec0 to the zone vpn1
    +shorewall delete ipsec0:192.0.2.24 vpn1 -- deletes the address 192.0.2.24 +from interface ipsec0 from zone vpn1
    +
    +
    - -

    The shorewall start, shorewall restart, shorewall check  and + +

    The shorewall start, shorewall restart, shorewall check  and shorewall try commands allow you to specify which Shorewall configuration to use:

    - -
    - + +
    +

    shorewall [ -c configuration-directory ] {start|restart|check}
    - shorewall try configuration-directory

    -
    + shorewall try configuration-directory

    +
    - -

    If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the configuration-directory - . If the file is present in the configuration-directory, that file + +

    If a configuration-directory is specified, each time that Shorewall + is going to use a file in /etc/shorewall it will first look in the configuration-directory + . If the file is present in the configuration-directory, that file will be used; otherwise, the file in /etc/shorewall will be used.

    - -

    When changing the configuration of a production firewall, I recommend -the following:

    + +

    When changing the configuration of a production firewall, I recommend + the following:

    - +
      -
    • mkdir /etc/test
    • +
    • mkdir /etc/test
    • -
    • cd /etc/test
    • +
    • cd /etc/test
    • -
    • <copy any files that you need to change from /etc/shorewall -to . and change them here>
    • +
    • <copy any files that you need to change from /etc/shorewall + to . and change them here>
    • -
    • shorewall -c . check
    • +
    • shorewall -c . check
    • -
    • <correct any errors found by check and check again>
    • +
    • <correct any errors found by check and check again>
    • -
    • /sbin/shorewall try .
    • - +
    • /sbin/shorewall try .
    • +
    - -

    If the configuration starts but doesn't work, just "shorewall restart" -to restore the old configuration. If the new configuration fails to start, -the "try" command will automatically start the old one for you.

    + +

    If the configuration starts but doesn't work, just "shorewall restart" + to restore the old configuration. If the new configuration fails to start, + the "try" command will automatically start the old one for you.

    - +

    When the new configuration works then just

    - +
      -
    • cp * /etc/shorewall
    • +
    • cp * /etc/shorewall
    • -
    • cd
    • +
    • cd
    • -
    • rm -rf /etc/test
    • - +
    • rm -rf /etc/test
    • +
    - -

    Updated 9/26/2002 - Tom Eastep + +

    Updated 10/23/2002 - Tom Eastep

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    -
    +
    +

    diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index f22c2bd51..cf59cad7c 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,77 +1,78 @@ - + - + - + - + Support - + - + - - - + + - - - + + + +
    +

    Shorewall Support

    -
    - -

    "It is -easier to post a problem than to use your own brain" -- "It +is easier to post a problem than to use your own brain" -- Wietse Venema (creator of Postfix)

    - -

    "Any sane computer will tell you how it works -- you just - have to ask it the right questions" -- Tom Eastep

    - + +

    "Any sane computer will tell you how it works -- you +just have to ask it the right questions" -- Tom Eastep

    +
    - -

    "It irks me when people believe that - free software comes at no cost. The cost is incredibly high." -- Wietse Venema

    +

    "It irks me when people believe that + free software comes at no cost. The cost is incredibly high." + - Wietse Venema

    +

    Before Reporting a Problem

    - +

    There are a number of sources for problem solution information.

    - +
      -
    • The FAQ has solutions to common problems.
    • -
    • The Troubleshooting Information +
    • The FAQ has solutions to 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 Mailing List Archives search facility can locate posts about +
    • The Errata has links to download updated + components.
    • +
    • The Mailing List Archives search facility can locate posts about similar problems:
    • - +
    - +

    Mailing List Archive Search

    + +
    - -

    Match: +

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

    - - + +

    Problem Reporting Guidelines

    - +
      -
    • When reporting a problem, give as much information as you can. +
    • When reporting a problem, give as much information as you can. Reports that say "I tried XYZ and it didn't work" are not at all helpful.
    • -
    • 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.
    • -
    • Do you see any "Shorewall" messages in /var/log/messages when - you exercise the function that is giving you problems?
    • -
    • Have you looked at the packet flow with a tool like tcpdump - to try to understand what is going on?
    • -
    • Have you tried using the diagnostic capabilities of the application - that isn't working? For example, if "ssh" isn't able to connect, using - the "-v" option gives you a lot of valuable diagnostic information.
    • -
    • 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 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 +
    • 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.
    • +
    • Do you see any "Shorewall" messages in /var/log/messages when + you exercise the function that is giving you problems?
    • +
    • Have you looked at the packet flow with a tool like tcpdump + to try to understand what is going on?
    • +
    • Have you tried using the diagnostic capabilities of the application + that isn't working? For example, if "ssh" isn't able to connect, using + the "-v" option gives you a lot of valuable diagnostic information.
    • +
    • 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 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.
    • - +
    - +

    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 +

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

    - +

    Otherwise, please post your question or problem to the Shorewall users mailing list; - there are lots of folks there who are willing to help you. Your question/problem - description and their responses will be placed in the mailing list archives - to help people who have a similar question or problem in the future.

    - -

    I don't look at problems sent to me directly but I try to spend some amount - of time each day responding to problems posted on the mailing list.

    - + href="mailto:shorewall-users@shorewall.net">Shorewall users mailing list; + there are lots of folks there who are willing to help you. Your question/problem + description and their responses will be placed in the mailing list archives + to help people who have a similar question or problem in the future.

    + +

    I don't look at problems sent to me directly but I try to spend some amount + of time each day responding to problems posted on the mailing list.

    +

    -Tom

    - +

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

    - -

    Last Updated 9/27/2002 - Tom Eastep

    - + +

    Last Updated 10/13/2002 - Tom Eastep

    +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    +
    +



    diff --git a/STABLE/documentation/three-interface.htm b/STABLE/documentation/three-interface.htm index f6c767173..a87918901 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,764 +1,484 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1

    - +

    Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the basics - and follow the documentation.

    - + with DMZ is a fairly straight-forward task if you understand the basics + and follow the documentation.

    +

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall -in one of its more popular configurations:

    - + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its more popular configurations:

    +
      -
    • Linux system used as a firewall/router for a small local network.
    • -
    • Single public IP address.
    • -
    • DMZ connected to a separate ethernet interface.
    • -
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, - ...
    • - +
    • Linux system used as a firewall/router for a small local network.
    • +
    • Single public IP address.
    • +
    • DMZ connected to a separate ethernet interface.
    • +
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, + ...
    • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - +

    +

    This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell if - this package is installed by the presence of an ip program on your - firewall system. As root, you can use the 'which' command to check for -this program:

    - + (on RedHat, the package is called iproute). You can tell +if this package is installed by the presence of an ip program on +your firewall system. As root, you can use the 'which' command to check +for this program:

    +
         [root@gateway root]# which ip
    /sbin/ip
    [root@gateway root]#
    - +

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are flagged - with -

    - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with +

    +

    -     If you edit your configuration files on a Windows system, you must - save them as Unix files if your editor supports that option or you must -run them through dos2unix before trying to use them. Similarly, if you copy -a configuration file from your Windows hard drive to a floppy disk, you -must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, you must + save them as Unix files if your editor supports that option or you must + run them through dos2unix before trying to use them. Similarly, if you +copy a configuration file from your Windows hard drive to a floppy disk, +you must run dos2unix against the copy before using it with Shorewall.

    + - +

    Shorewall Concepts

    - +

    The configuration files for Shorewall are contained in the directory /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the -files to /etc/shorewall (the files will replace files with the same names -that were placed in /etc/shorewall when Shorewall was installed).

    - + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the + files to /etc/shorewall (the files will replace files with the same names + that were placed in /etc/shorewall when Shorewall was installed).

    +

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - + file on your system -- each file contains detailed configuration instructions + and default entries.

    +

    Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, the following - zone names are used:

    - + set of zones. In the three-interface sample configuration, the following + zone names are used:

    + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    - +

    Zone names are defined in /etc/shorewall/zones.

    - +

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - + the firewall itself is known as fw.

    +

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - + in terms of zones.

    + - +

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file matches - the connection request then the first policy in /etc/shorewall/policy that - matches the request is applied. If that policy is REJECT or DROP  the -request is first checked against the rules in /etc/shorewall/common (the + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common (the samples provide that file for you).

    - +

    The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

    - -
    + has the following policies:

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -
    +
    + +

    In the three-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers on -the internet, uncomment that line.

    - + out. If you want your firewall system to have full access to servers on + the internet, uncomment that line.

    + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network to the internet
    2. -
    3. drop (ignore) all connection requests from the internet to your -firewall or local network
    4. -
    5. optionally accept all connection requests from the firewall to -the internet (if you uncomment the additional policy)
    6. -
    7. reject all other connection requests.
    8. - +
    9. allow all connection requests from your local network to the +internet
    10. +
    11. drop (ignore) all connection requests from the internet to your + firewall or local network
    12. +
    13. optionally accept all connection requests from the firewall to + the internet (if you uncomment the additional policy)
    14. +
    15. reject all other connection requests.
    16. +
    - +

    -     At this point, edit your /etc/shorewall/policy file and make any -changes that you wish.

    - +     At this point, edit your /etc/shorewall/policy file and make any + changes that you wish.

    +

    Network Interfaces

    - +

    -

    - +

    +

    The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point Tunneling Protocol (PPTP) in which case the External Interface will be a ppp interface (e.g., ppp0). If you connect via a regular modem, -your External Interface will also be ppp0. If you connect using ISDN, - you external interface will be ippp0.

    - +your External Interface will also be ppp0. If you connect using ISDN, + you external interface will be ippp0.

    +

    -     If your external interface is ppp0 or ippp0 then you - will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    - +     If your external interface is ppp0 or ippp0 then +you will want to set CLAMPMSS=yes in +/etc/shorewall/shorewall.conf.

    +

    Your Local Interface will be an ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local computers - will be connected to the same switch (note: If you have only a single local - system, you can connect the firewall directly to the computer using a cross-over - cable).

    - + eth1 or eth2) and will be connected to a hub or switch. Your local computers + will be connected to the same switch (note: If you have only a single local + system, you can connect the firewall directly to the computer using a +cross-over cable).

    +

    Your DMZ Interface will also be an ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ -computers will be connected to the same switch (note: If you have only a -single DMZ system, you can connect the firewall directly to the computer -using a cross-over cable).

    - + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ + computers will be connected to the same switch (note: If you have only a + single DMZ system, you can connect the firewall directly to the computer + using a cross-over cable).

    +

    - Do not connect more than one interface to the same hub or switch - (even for testing). It won't work the way that you expect it to and you -will end up confused and believing that Shorewall doesn't work at all.

    - + Do not connect more than one interface to the same hub or switch + (even for testing). It won't work the way that you expect it to and you + will end up confused and believing that Shorewall doesn't work at all.

    +

    -     The Shorewall three-interface sample configuration assumes that the - external interface is eth0, the local interface is eth1 and - the DMZ interface is eth2. If your configuration is different, -you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interfaces. Some hints:

    - +     The Shorewall three-interface sample configuration assumes that + the external interface is eth0, the local interface is eth1 +and the DMZ interface is eth2. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that are + specified for the interfaces. Some hints:

    +
      -
    • +
    • If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
    • -
    • + you can replace the "detect" in the second column with "-".

      +
    • +
    • If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

      -
    • - + or if you have a static IP address, you can remove "dhcp" from the option + list.

      + +
    - +

    IP Addresses

    - +

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic - Host Configuration Protocol (DHCP) or as part of establishing your connection - when you dial in (standard modem) or establish your PPP connection. In -rare cases, your ISP may assign you a static IP address; that means -that you configure your firewall's external interface to use that address -permanently. Regardless of how the address is assigned, it will be -shared by all of your systems when you access the Internet. You will have -to assign your own addresses for your internal network (the local and DMZ -Interfaces on your firewall plus your other computers). RFC 1918 reserves + Protocol (IP) addresses. Normally, your ISP will assign you a single + Public IP address. This address may be assigned via the Dynamic + Host Configuration Protocol (DHCP) or as part of establishing your +connection when you dial in (standard modem) or establish your PPP connection. +In rare cases, your ISP may assign you a static IP address; that +means that you configure your firewall's external interface to use that +address permanently. Regardless of how the address is assigned, it +will be shared by all of your systems when you access the Internet. You will +have to assign your own addresses for your internal network (the local and +DMZ Interfaces on your firewall plus your other computers). RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    + +
         10.0.0.0    - 10.255.255.255
    172.16.0.0 - 172.31.255.255
    192.168.0.0 - 192.168.255.255
    -
    - -
    +
    + +

    -     Before starting Shorewall, you should look at the IP address of -your external interface and if it is one of the above ranges, you should -remove the 'norfc1918' option from the external interface's entry in - /etc/shorewall/interfaces.

    -
    - -
    +     Before starting Shorewall, you should look at the IP address +of your external interface and if it is one of the above ranges, you +should remove the 'norfc1918' option from the external interface's entry +in /etc/shorewall/interfaces.

    +
    + +

    You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another + sub-network or subnet and your DMZ addresses from another subnet. For our purposes, we can consider a subnet to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet -Address and x.y.z.255 is reserved as the Subnet Broadcast Address. -In Shorewall, a subnet is described using Classless -InterDomain Routing (CIDR) notation with consists of the subnet address -followed by "/24". The "24" refers to the number of consecutive "1" -bits from the left of the subnet mask.

    -
    - -
    + Address and x.y.z.255 is reserved as the Subnet Broadcast Address. + In Shorewall, a subnet is described using Classless + InterDomain Routing (CIDR) notation with consists of the subnet +address followed by "/24". The "24" refers to the number of consecutive +"1" bits from the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    + +
    + +

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

    -
    - -
    + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

    +
    + +

    One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated -with directly. To communicate with systems outside of the subnetwork, systems -send packets through a  gateway  (router).

    -
    - -
    + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, +systems send packets through a  gateway  (router).

    +
    + +

    -     Your local computers (Local Computers 1 & 2) should be configured - with their default gateway set to the IP address of the firewall's - internal interface and your DMZ computers ( DMZ Computers 1 & 2) should - be configured with their default gateway set to the IP address of the -firewall's DMZ interface.  

    -
    - +     Your local computers (Local Computers 1 & 2) should be configured + with their default gateway set to the IP address of the firewall's + internal interface and your DMZ computers ( DMZ Computers 1 & 2) +should be configured with their default gateway set to the IP address +of the firewall's DMZ interface.  

    +
    +

    The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning more - about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas -A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - + regarding subnetting and routing. If you are interested in learning more + about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    +

    The remainder of this quide will assume that you have configured - your network as shown here:

    - + your network as shown here:

    +

    -

    - -

    The default gateway for the DMZ computers would be 10.10.10.254 - and the default gateway for the Local computers would be 10.10.10.254.

    - +

    + +

    The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.

    +

    IP Masquerading (SNAT)

    - +

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't forward - packets which have an RFC-1918 destination address. When one of your local - systems (let's assume local computer 1) sends a connection request to an - internet host, the firewall must perform Network Address Translation -(NAT). The firewall rewrites the source address in the packet to be the -address of the firewall's external interface; in other words, the firewall -makes it look as if the firewall itself is initiating the connection.  This -is necessary so that the destination host will be able to route return packets - back to the firewall (remember that packets whose destination address is - reserved by RFC 1918 can't be routed accross the internet). When the firewall - receives a return packet, it rewrites the destination address back to 10.10.10.1 - and forwards the packet on to local computer 1.

    - + to as non-routable because the Internet backbone routers don't forward + packets which have an RFC-1918 destination address. When one of your local + systems (let's assume local computer 1) sends a connection request to an + internet host, the firewall must perform Network Address Translation + (NAT). The firewall rewrites the source address in the packet to be +the address of the firewall's external interface; in other words, the firewall + makes it look as if the firewall itself is initiating the connection.  This + is necessary so that the destination host will be able to route return packets + back to the firewall (remember that packets whose destination address +is reserved by RFC 1918 can't be routed accross the internet). When the +firewall receives a return packet, it rewrites the destination address +back to 10.10.10.1 and forwards the packet on to local computer 1.

    +

    On Linux systems, the above process is often referred to as IP Masquerading and you will also see the term Source Network Address Translation (SNAT) used. Shorewall follows the convention used with Netfilter:

    - +
      -
    • +
    • Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
    • -
    • + firewall system automatically detect the external interface address. +

      +
    • +
    • SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local network - to use.

      -
    • - + the source address that you want outbound packets from your local network + to use.

      + +
    - +

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

    - + entries in the /etc/shorewall/masq file.

    +

    -     If your external firewall interface is eth0, your local interface - eth1 and your DMZ interface is eth2 then you do not need to - modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq - and change it to match your configuration.

    - +     If your external firewall interface is eth0, your local +interface eth1 and your DMZ interface is eth2 then you do +not need to modify the file provided with the sample. Otherwise, edit +/etc/shorewall/masq and change it to match your configuration.

    +

    -     If your external IP is static, you can enter it in the third column - in the /etc/shorewall/masq entry if you like although your firewall will - work fine if you leave that column empty. Entering your static IP in column - 3 makes processing outgoing packets a little more efficient.

    - +     If your external IP is static, you can enter it in the third column + in the /etc/shorewall/masq entry if you like although your firewall will + work fine if you leave that column empty. Entering your static IP in column + 3 makes processing outgoing packets a little more efficient.

    +

    Port Forwarding (DNAT)

    - +

    One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it is not - possible for clients on the internet to connect directly to them. It is -rather necessary for those clients to address their connection requests to -your firewall who rewrites the destination address to the address of your + DMZ computers. Because these computers have RFC-1918 addresses, it is not + possible for clients on the internet to connect directly to them. It is + rather necessary for those clients to address their connection requests +to your firewall who rewrites the destination address to the address of your server and forwards the packet to that server. When your server responds, -the firewall automatically performs SNAT to rewrite the source address in -the response.

    - + the firewall automatically performs SNAT to rewrite the source address in + the response.

    +

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure port + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - +

    The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server -port>]<protocol><port>  
    -
    - -

    If you don't specify the <server port>, it is assumed to be -the same as <port>.

    - -

    Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    -
    - -

    A couple of important points to keep in mind:

    - -
      -
    • When you are connecting to your server from your local systems, -you must use the server's internal IP address (10.10.11.2).
    • -
    • Many ISPs block incoming connection requests to port 80. If you -have problems connecting to your web server, try the following rule and -try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
    • - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    -
    - -

    If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can replace - the loc->dmz rule above with:

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    - -

    If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows (assume - that your external interface is eth0):

    - -
      -
    1. Include the following in /etc/shorewall/params:
      -
      - ETH0_IP=`find_interface_address eth0`
      -  
    2. -
    3. Make your loc->dmz rule:
    4. - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    - -

    If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

    - -

    -     At this point, add the DNAT and ACCEPT rules for your servers.

    - -

    Domain Name Server (DNS)

    - -

    Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver -will be automatically configured (e.g., the /etc/resolv.conf file will be -written). Alternatively, your ISP may have given you the IP address of a -pair of DNS name servers for you to manually configure as your primary -and secondary name servers. It is your responsibility to configure -the resolver in your internal systems. You can take one of two approaches:

    - -
      -
    • -

      You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers or if - those addresses are available on their web site, you can configure your - internal systems to use those addresses. If that information isn't available, - look in /etc/resolv.conf on your firewall system -- the name servers are - given in "nameserver" records in that file.

      -
    • -
    • -

      -     You can configure a Caching Name Server on your firewall -or in your DMZ. Red Hat has an RPM for a caching name server (which -also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. -If you take this approach, you configure your internal systems to use the -caching name server as their primary (and only) name server. You use the -internal IP address of the firewall (10.10.10.254 in the example above) - for the name server address if you choose to run the name server on your - firewall. To allow your local systems to talk to your caching name server, - you must open port 53 (both UDP and TCP) from the local network to the - server; you do that by adding the rules in /etc/shorewall/rules.

      -
    • - -
    - -
    -

    If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    -

    Run name server on DMZ computer 1

    - + is:

    + +
    - + @@ -768,192 +488,225 @@ internal IP address of the firewall (10.10.10.254 in the example above) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTION SOURCE DESTINATIONORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    -
    -
    - -
    -

    Other Connections

    -
    - -
    -

    The three-interface sample includes the following rules:

    -
    - -
    -
    - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwDNAT netudp53  
    ACCEPTfwnettcp53  
    -
    -
    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

    -
    - -
    -

    The sample also includes:

    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    -
    -
    - -
    -

    That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers from - your local systems.

    -
    - -
    -

    If you wish to enable other connections between your systems, - the general format is:

    -
    - -
    -
    - - - - - - - - - - - - - - - + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone>dmz:<server local ip address> [:<server + port>] <protocol> <port>    
    -
    - -
    -

    Example - You want to run a publicly-available DNS server - on your firewall system:

    -
    - -
    -
    + +

    If you don't specify the <server port>, it is assumed to be +the same as <port>.

    + +

    Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

    + +
    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    +
    + +

    A couple of important points to keep in mind:

    + +
      +
    • When you are connecting to your server from your local systems, + you must use the server's internal IP address (10.10.11.2).
    • +
    • Many ISPs block incoming connection requests to port 80. If you + have problems connecting to your web server, try the following rule and + try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
    • + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    +
    + +

    If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you can replace + the loc->dmz rule above with:

    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    +
    + +

    If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows (assume + that your external interface is eth0):

    + +
      +
    1. Include the following in /etc/shorewall/params:
      +
      + ETH0_IP=`find_interface_address eth0`
      +  
    2. +
    3. Make your loc->dmz rule:
    4. + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +
    dmz:10.10.11.2:80tcp80-$ETH0_IP
    +
    + +

    If you want to access your server from the DMZ using your external IP +address, see FAQ 2a.

    + +

    +     At this point, add the DNAT and ACCEPT rules for your servers. +

    + +

    Domain Name Server (DNS)

    + +

    Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file will be + written). Alternatively, your ISP may have given you the IP address of +a pair of DNS name servers for you to manually configure as your +primary and secondary name servers. It is your responsibility to +configure the resolver in your internal systems. You can take one of two +approaches:

    + +
      +
    • +

      You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers or if + those addresses are available on their web site, you can configure your + internal systems to use those addresses. If that information isn't available, + look in /etc/resolv.conf on your firewall system -- the name servers +are given in "nameserver" records in that file.

      +
    • +
    • +

      +     You can configure a Caching Name Server on your firewall + or in your DMZ. Red Hat has an RPM for a caching name server (which + also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. + If you take this approach, you configure your internal systems to use +the caching name server as their primary (and only) name server. You use +the internal IP address of the firewall (10.10.10.254 in the example above) + for the name server address if you choose to run the name server on your + firewall. To allow your local systems to talk to your caching name server, + you must open port 53 (both UDP and TCP) from the local network to the + server; you do that by adding the rules in /etc/shorewall/rules.

      +
    • + +
    + +
    +

    If you run the name server on the firewall: + + + + @@ -964,137 +717,392 @@ internal IP address of the firewall (10.10.10.254 in the example above) - + - - + + - + + + + + + + + + + - - + + - - + + + + + + + + + + +
    ACTION SOURCE DESTINATION
    ACCEPTnetloc fw tcp 53#Allow DNS accessfrom the internet  
    ACCEPTnetlocfwudp53  
    ACCEPTdmz fw tcp 53#Allow DNS accessfrom the internet  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    +

    + + +
    +
    +

    Run name server on DMZ computer 1

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    +
    +
    + +
    +

    Other Connections

    +
    + +
    +

    The three-interface sample includes the following rules:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    +
    +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

    +
    + +
    +

    The sample also includes:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    +
    +
    + +
    +

    That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers from + your local systems.

    +
    + +
    +

    If you wish to enable other connections between your systems, + the general format is:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    +
    +
    + +
    +

    Example - You want to run a publicly-available DNS server + on your firewall system:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    +
    +
    + +

    Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

    -
    - -
    + listed above under "If you run the name server on your firewall".

    +
    + +

    If you don't know what port and protocol a particular application uses, look here.

    -
    - -
    +
    + +

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want - shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    -     Now modify /etc/shorewall/rules to add or remove other connections - as required.

    -
    - -
    +     Now modify /etc/shorewall/rules to add or remove other connections + as required.

    +
    + +

    Starting and Stopping Your Firewall

    -
    - -
    +
    + +

    Arrow -     The installation procedure configures -your system to start Shorewall at system boot  but beginning with Shorewall -version 1.3.9 startup is disabled so that your system won't try to start +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start Shorewall before configuration is complete. Once you have completed configuration of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
    -

    - +

    +

    IMPORTANT: Users of the .deb package must edit /etc/default/shorewall -and set 'startup=1'.
    -

    -
    - -
    + and set 'startup=1'.
    +

    +
    + +

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

    -
    - -
    + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

    +
    + +

    -     The three-interface sample assumes that you want to enable routing - to/from eth1 (your local network) and eth2 (DMZ) when Shorewall - is stopped. If these two interfaces don't connect to your local network - and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped - accordingly.

    -
    - -
    +     The three-interface sample assumes that you want to enable routing + to/from eth1 (your local network) and eth2 (DMZ) when Shorewall + is stopped. If these two interfaces don't connect to your local network + and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped + accordingly.

    +
    + +

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have -added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall -try" command.

    -
    - -

    Last updated 9/26/2002 - alternate configuration + and test it using the "shorewall + try" command.

    +
    + +

    Last updated 10/22/2002 - Tom Eastep

    - +

    Copyright 2002 Thomas - M. Eastep

    + M. Eastep

    +

    +



    diff --git a/STABLE/documentation/traffic_shaping.htm b/STABLE/documentation/traffic_shaping.htm index 4593e1f70..ddff1c3b7 100644 --- a/STABLE/documentation/traffic_shaping.htm +++ b/STABLE/documentation/traffic_shaping.htm @@ -1,214 +1,257 @@ + - - - - - -Traffic Shaping + + + + + + + + + Traffic Shaping - - - - - - - + + +
    -

    Traffic Shaping/Control

    -
    + + + + + +
    +

    Traffic Shaping/Control

    +
    -

    Beginning with version 1.2.0, Shorewall has limited support for traffic -shaping/control. In order to use traffic shaping under Shorewall, it is -essential that you get a copy of the Linux Advanced Routing -and Shaping HOWTO, version 0.3.0 or later. You must also install -the iproute (iproute2) package to provide the "ip" and "tc" -utilities.

    - + +

    Beginning with version 1.2.0, Shorewall has limited support +for traffic shaping/control. In order to use traffic shaping under Shorewall, +it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO, +version 0.3.0 or later. You must also install the iproute (iproute2) package +to provide the "ip" and "tc" utilities.

    +

    Shorewall traffic shaping support consists of the following:

    - +
      -
    • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic - Shaping also requires that you enable packet mangling.
      -
    • -
    • /etc/shorewall/tcrules - A file where you can specify - firewall marking of packets. The firewall mark value may be used to classify - packets for traffic shaping/control.
      -
    • -
    • /etc/shorewall/tcstart - A user-supplied file that is - sourced by Shorewall during "shorewall start" and which you can - use to define your traffic shaping disciplines and classes. I have provided - a sample that does - table-driven CBQ shaping but if you read the traffic shaping sections of the - HOWTO mentioned above, you can probably code your own faster than you can - learn how to use my sample. I personally use HTB - (see below). HTB - support may eventually become an integral part of Shorewall since HTB is a - lot simpler and better-documented than CBQ. HTB is currently not a standard - part of either the kernel or iproute2 so both must be patched in order to - use it.
      -
      - In tcstart, when you want to run the 'tc' utility, use the run_tc function - supplied by shorewall.
      -
    • -
    • /etc/shorewall/tcclear - A user-supplied file that is - sourced by Shorewall when it is clearing traffic shaping. This file is - normally not required as Shorewall's method of clearing qdisc and filter - definitions is pretty general.
    • +
    • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping +also requires that you enable packet mangling.
      +
    • +
    • /etc/shorewall/tcrules - A file where you can specify firewall +marking of packets. The firewall mark value may be used to classify packets +for traffic shaping/control.
      +
    • +
    • /etc/shorewall/tcstart - A user-supplied file that is sourced +by Shorewall during "shorewall start" and which you can use to define +your traffic shaping disciplines and classes. I have provided a sample that does + table-driven CBQ shaping but if you read the traffic shaping sections of +the HOWTO mentioned above, you can probably code your own faster than +you can learn how to use my sample. I personally use HTB (see below). HTB + support may eventually become an integral part of Shorewall since HTB +is a lot simpler and better-documented than CBQ. HTB is currently not +a standard part of either the kernel or iproute2 so both must be patched +in order to use it.
      +
      + In tcstart, when you want to run the 'tc' utility, use the run_tc function + supplied by shorewall.
      +
    • +
    • /etc/shorewall/tcclear - A user-supplied file that is sourced +by Shorewall when it is clearing traffic shaping. This file is normally +not required as Shorewall's method of clearing qdisc and filter definitions +is pretty general.
    • +
    +

    Kernel Configuration

    +

    This screen shot show how I've configured QoS in my Kernel:

    -

    + +

    +

    +

    /etc/shorewall/tcrules

    +

    The fwmark classifier provides a convenient way to classify -packets for traffic shaping. The /etc/shorewall/tcrules file provides a means -for specifying these marks in a tabular fashion.

    + packets for traffic shaping. The /etc/shorewall/tcrules file provides a +means for specifying these marks in a tabular fashion.

    +

    Columns in the file are as follows:

    +
      -
    • MARK - Specifies the mark value is to be assigned in case of - a match. This is an integer in the range 1-255.
      -
      - Example - 5
      -
    • -
    • SOURCE - The source of the packet. If the packet originates - on the firewall, place "fw" in this column. Otherwise, this is a - comma-separated list of interface names, IP addresses, MAC addresses in - Shorewall Format and/or Subnets.
      -
      - Examples
      -     eth0
      -     192.168.2.4,192.168.1.0/24
      -
    • -
    • DEST -- Destination of the packet. Comma-separated list of - IP addresses and/or subnets.
      -
    • -
    • PROTO - Protocol - Must be the name of a protocol from - /etc/protocol, a number or "all"
      -
    • -
    • PORT(S) - Destination Ports. A comma-separated list of Port - names (from /etc/services), port numbers or port ranges (e.g., 21:22); if - the protocol is "icmp", this column is interpreted as the - destination icmp type(s).
      -
    • -
    • CLIENT PORT(S) - (Optional) Port(s) used by the client. If - omitted, any source port is acceptable. Specified as a comma-separate list - of port names, port numbers or port ranges.
    • +
    • MARK - Specifies the mark value is to be assigned in case of +a match. This is an integer in the range 1-255.
      +
      + Example - 5
      +
    • +
    • SOURCE - The source of the packet. If the packet originates on +the firewall, place "fw" in this column. Otherwise, this is a comma-separated +list of interface names, IP addresses, MAC addresses in Shorewall Format and/or Subnets.
      +
      + Examples
      +     eth0
      +     192.168.2.4,192.168.1.0/24
      +
    • +
    • DEST -- Destination of the packet. Comma-separated list of IP +addresses and/or subnets.
      +
    • +
    • PROTO - Protocol - Must be the name of a protocol from /etc/protocol, +a number or "all"
      +
    • +
    • PORT(S) - Destination Ports. A comma-separated list of Port names +(from /etc/services), port numbers or port ranges (e.g., 21:22); if the +protocol is "icmp", this column is interpreted as the destination icmp +type(s).
      +
    • +
    • CLIENT PORT(S) - (Optional) Port(s) used by the client. If omitted, +any source port is acceptable. Specified as a comma-separate list of port +names, port numbers or port ranges.
    • +
    -

    Example 1 - All packets arriving on eth1 should be marked with -1. All packets arriving on eth2 should be marked with 2. All packets originating -on the firewall itself should be marked with 3.

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

    Example 1 - All packets arriving on eth1 should be marked +with 1. All packets arriving on eth2 should be marked with 2. All packets +originating on the firewall itself should be marked with 3.

    + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    1eth10.0.0.0/0all  
    2eth20.0.0.0/0all  
    3fw0.0.0.0/0all  
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    1eth10.0.0.0/0all  
    2eth20.0.0.0/0all  
    3fw0.0.0.0/0all  
    -

    Example 2 - All GRE (protocol 47) packets not originating on the -firewall and destined for 155.186.235.151 should be marked with 12.

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

    Example 2 - All GRE (protocol 47) packets not originating +on the firewall and destined for 155.186.235.151 should be marked with 12.

    + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    120.0.0.0/0155.186.235.15147  
    + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    120.0.0.0/0155.186.235.15147  
    -

    Example 3 - All SSH packets originating in 192.168.1.0/24 and -destined for 155.186.235.151 should be marked with 22.

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

    Example 3 - All SSH packets originating in 192.168.1.0/24 +and destined for 155.186.235.151 should be marked with 22.

    + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    22192.168.1.0/24155.186.235.151tcp22 
    + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    22192.168.1.0/24155.186.235.151tcp22 
    +

    Hierarchical Token Bucket

    -

    I personally use HTB. I have found a couple of things that may be of -use to others.

    + +

    I personally use HTB. I have found a couple of things that may be of use +to others.

    +
      -
    • The gzipped tc binary at the HTB - website didn't work for me -- I had to download the lastest version of - the iproute2 sources and patch - them for HTB.
    • -
    • The HTB example in the HOWTO seems to be full of errors. I'm currently - running with this set of shaping rules in my tcstart file so I know that it works.
    • +
    • The gzipped tc binary at the HTB website didn't work +for me -- I had to download the lastest version of the iproute2 sources and patch +them for HTB.
    • +
    • I'm currently running with this set of shaping rules in my tcstart +file. I recently changed from using a ceiling of 10Mbit (interface speed) +to 384kbit (DSP Uplink speed).
      +
      +
    • +
    -
    -

    run_tc qdisc add dev eth0 root handle 1: htb default 30
    -
    - run_tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k
    -
    - run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 150kbit ceil 10mbit burst 15k
    - run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 234kbit ceil 10mbit burst 15k
    - run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil   - 10mbit burst 15k
    -
    - run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
    - run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
    - run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10
    -
    - run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
    - run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
    - run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30 -

    -

    My tcrules file is shown in Example 1 above. You can look at my network - configuration to get an idea of why I want these particular rules.
    -

    -
    -

    Last Updated 8/24/2002 - Tom -Eastep

    - + +
    +
    run_tc qdisc add dev eth0 root handle 1: htb default 30
    run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

    echo "   Added Top Level Class -- rate 384kbit"
    + +
    run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k
    run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k
    run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500
    + +
    echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
    + +
    run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
    run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
    run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10
    + +
    echo "   Enabled SFQ on Second Level Classes"
    + +
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
    + +
    echo "   Defined fwmark filters"
    + +

    My tcrules file is shown in Example 1 above. You can look at my network configuration to get an idea of why I want +these particular rules.
    +

    +
    + +

    Last Updated 10/25/2002 - Tom Eastep

    +

    Copyright2001, 2002 Thomas M. Eastep.

    - + © 2001, 2002 Thomas M. Eastep.

    +
    +
    - - \ No newline at end of file + diff --git a/STABLE/documentation/troubleshoot.htm b/STABLE/documentation/troubleshoot.htm index 964d3df21..1e69a028e 100644 --- a/STABLE/documentation/troubleshoot.htm +++ b/STABLE/documentation/troubleshoot.htm @@ -1,205 +1,199 @@ - - + + Shorewall Troubleshooting - + - + - - - + - - - - - - - -
    -

    Shorewall Troubleshooting

    -
    + + + + + + + + +
    +

    Shorewall Troubleshooting

    +
    + +

    Check the Errata

    + +

    Check the Shorewall Errata to be +sure that there isn't an update that you are missing for your version of +the firewall.

    + +

    Check the FAQs

    + +

    Check the FAQs for solutions to common +problems.

    + +

    If the firewall fails to start

    + If you receive an error message when starting or restarting the firewall +and you can't determine the cause, then do the following: +
      +
    • shorewall debug start 2> /tmp/trace
    • +
    • Look at the /tmp/trace file and see if that helps you determine +what the problem is.
    • +
    • If you still can't determine what's wrong then see the support page.
    • - - -

      Check the Errata

      - -

      Check the Shorewall Errata - to be sure that there isn't an update that you are missing for your version -of the firewall.

      - -

      Check the FAQs

      - -

      Check the FAQs for solutions to common problems.

      - - - -

      If the firewall fails to start

      - - If you -receive an error message when starting or restarting the firewall and you -can't determine the cause, then do the following: -
        -
      • shorewall debug start 2> /tmp/trace
      • -
      • Look at the /tmp/trace file and see if that helps you determine what -the problem is.
      • -
      • If you still can't determine what's wrong then see the - support page.
      • -
      -

      Your test environment

      -

      Many times when people have problems with Shorewall, the problem is - actually an ill-conceived test setup. Here are several popular snafus:

      -
        -
      • Port - Forwarding where client and server are in the same subnet. See FAQ - 2.
      • -
      • Changing the IP address of a local system to be in the external subnet, - thinking that Shorewall will suddenly believe that the system is in the - 'net' zone.
      • -
      • Multiple interfaces connected to the same HUB or Switch. Given the way - that the Linux kernel respond to ARP "who-has" requests, this type of setup - does NOT work the way that you expect it to.
      • -
      - -

      If you are having -connection problems:

      - -

      If the appropriate policy for the connection that you -are trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING -TO MAKE IT WORK. Such additional rules will NEVER make it work, they add -clutter to your rule set and they represent a big security hole in the event -that you forget to remove them later.

      - -

      I also recommend against setting all of your policies to - ACCEPT in an effort to make something work. That robs you of one of your - best diagnostic tools - the "Shorewall" messages that Netfilter will - generate when you try to connect in a way that isn't permitted by your - rule set.

      - -

      Check your log. If you don't see Shorewall messages, -then your problem is probably NOT a Shorewall problem. If you DO see packet -messages, it is an indication that you are missing one or more rules.

      - -

      While you are troubleshooting, it is a good idea to clear +

    + +

    Your test environment

    + +

    Many times when people have problems with Shorewall, the problem is + actually an ill-conceived test setup. Here are several popular snafus:

    + +
      +
    • Port Forwarding where client and server are in the same +subnet. See FAQ 2.
    • +
    • Changing the IP address of a local system to be in the external +subnet, thinking that Shorewall will suddenly believe that the system +is in the 'net' zone.
    • +
    • Multiple interfaces connected to the same HUB or Switch. Given the +way that the Linux kernel respond to ARP "who-has" requests, this type +of setup does NOT work the way that you expect it to.
    • + +
    + +

    If you are having connection problems:

    + +

    If the appropriate policy for the connection that you are +trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING +TO MAKE IT WORK. Such additional rules will NEVER make it work, they add clutter +to your rule set and they represent a big security hole in the event that +you forget to remove them later.

    + +

    I also recommend against setting all of your policies to + ACCEPT in an effort to make something work. That robs you of one of +your best diagnostic tools - the "Shorewall" messages that Netfilter +will generate when you try to connect in a way that isn't permitted +by your rule set.

    + +

    Check your log. If you don't see Shorewall messages, then +your problem is probably NOT a Shorewall problem. If you DO see packet messages, +it may be an indication that you are missing one or more rules -- see FAQ 17.

    + +

    While you are troubleshooting, it is a good idea to clear two variables in /etc/shorewall/shorewall.conf:

    - -

    LOGRATE=""
    - LOGBURST=""

    - -

    This way, you will see all of the log messages being - generated (be sure to restart shorewall after clearing these variables).

    - -

    Example:

    - - - -

    Jun 27 15:37:56 gateway kernel: - Shorewall:all2all:REJECT:IN=eth2 -OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 -ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47

    - -
    - -

    Let's look at the important parts of this message:

    + +

    LOGRATE=""
    + LOGBURST=""

    + +

    This way, you will see all of the log messages being + generated (be sure to restart shorewall after clearing these variables).

    + +

    Example:

    + +

    Jun 27 15:37:56 gateway kernel: + Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 +LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47

    +
    +

    Let's look at the important parts of this message:

    + +
      +
    • all2all:REJECT - This packet was REJECTed out of the all2all chain +-- the packet was rejected under the "all"->"all" REJECT policy (see + FAQ 17).
    • +
    • IN=eth2 - the packet entered the firewall via eth2
    • +
    • OUT=eth1 - if accepted, the packet would be sent on eth1
    • +
    • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
    • +
    • DST=192.168.1.3 - the packet is destined for 192.168.1.3
    • +
    • PROTO=UDP - UDP Protocol
    • +
    • DPT=53 - DNS
    • -
        -
      • all2all:REJECT - the packet was rejected under the "all"->"all" REJECT -policy
      • -
      • IN=eth2 - the packet entered the firewall via eth2
      • -
      • OUT=eth1 - if accepted, the packet would be sent on eth1
      • -
      • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
      • -
      • DST=192.168.1.3 - the packet is destined for 192.168.1.3
      • -
      • PROTO=UDP - UDP Protocol
      • -
      • DPT=53 - DNS
      • -
      - -

      In this case, 192.168.2.2 was in the "dmz" zone and -192.168.1.3 is in the "loc" zone. I was missing the rule:

      - -

      ACCEPT    dmz    loc    udp    53

      - - - -

      Other Gotchas

      - -
        -
      • Seeing rejected/dropped packets logged out of the INPUT or FORWARD - chains? This means that:
          -
        1. your zone definitions are screwed up and the host that is sending the - packets or the destination host isn't in any zone (using an - /etc/shorewall/hosts file are you?); - or
        2. -
        3. the source and destination hosts are both connected to the same - interface and that interface doesn't have the 'multi' option specified in - /etc/shorewall/interfaces.
        4. +
      + +

      In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 +is in the "loc" zone. I was missing the rule:

      + +

      ACCEPT    dmz    loc    udp    53

      + +

      Other Gotchas

      + +
        +
      • Seeing rejected/dropped packets logged out of the INPUT or FORWARD + chains? This means that: +
          +
        1. your zone definitions are screwed up and the host that is sending +the packets or the destination host isn't in any zone (using an + /etc/shorewall/hosts file are you?); + or
        2. +
        3. the source and destination hosts are both connected to the same + interface and that interface doesn't have the 'multi' option specified +in /etc/shorewall/interfaces.
        4. +
        -
      • -
      • Remember that Shorewall doesn't automatically allow ICMP type 8 ("ping") -requests to be sent between zones. If you want pings to be allowed between -zones, you need a rule of the form:
        -
        -     ACCEPT    <source zone>    <destination zone>    +
      • +
      • Remember that Shorewall doesn't automatically allow ICMP type +8 ("ping") requests to be sent between zones. If you want pings to be +allowed between zones, you need a rule of the form:
        +
        +     ACCEPT    <source zone>    <destination zone>    icmp    echo-request
        -
        - The ramifications of this can be subtle. For example, if you have the - following in /etc/shorewall/nat:
        -
        -     10.1.1.2    eth0    130.252.100.18
        -
        - and you ping 130.252.100.18, unless you have allowed icmp type 8 between -the zone containing the system you are pinging from and the zone containing - 10.1.1.2, the ping requests will be dropped. This is true even if you +
        + The ramifications of this can be subtle. For example, if you have the + following in /etc/shorewall/nat:
        +
        +     10.1.1.2    eth0    130.252.100.18
        +
        + and you ping 130.252.100.18, unless you have allowed icmp type 8 between +the zone containing the system you are pinging from and the zone containing + 10.1.1.2, the ping requests will be dropped. This is true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.
      • -
      • If you specify "routefilter" for an interface, that interface must be -up prior to starting the firewall.
      • -
      • Is your routing correct? For example, internal systems usually need to - be configured with their default gateway set to the IP address of their - nearest firewall interface. One often overlooked aspect of routing is that - in order for two hosts to communicate, the routing between them must be set - up in both directions. So when setting up routing between A - and B, be sure to verify that the route from B back to A - is defined.
      • -
      • Some versions of LRP (EigerStein2Beta for example) have a shell with -broken variable expansion. -You can get a corrected shell from the Shorewall Errata download site. -
      • -
      • Do you have your kernel properly configured? Click - here to see my kernel configuration.
      • -
      • Some features require the "ip" program. That program is generally included -in the "iproute" package which should be included with your distribution -(though many distributions don't install iproute by default). You -may also download the latest source tarball from -ftp://ftp.inr.ac.ru/ip-routing +
      • If you specify "routefilter" for an interface, that interface +must be up prior to starting the firewall.
      • +
      • Is your routing correct? For example, internal systems usually need +to be configured with their default gateway set to the IP address of +their nearest firewall interface. One often overlooked aspect of routing +is that in order for two hosts to communicate, the routing between them +must be set up in both directions. So when setting up routing +between A and B, be sure to verify that the route from + B back to A is defined.
      • +
      • Some versions of LRP (EigerStein2Beta for example) have a shell +with broken variable expansion. You can get a corrected +shell from the Shorewall Errata download site.
      • +
      • Do you have your kernel properly configured? Click here to see my kernel configuration.
      • +
      • Some features require the "ip" program. That program is generally +included in the "iproute" package which should be included with your +distribution (though many distributions don't install iproute by +default). You may also download the latest source tarball from ftp://ftp.inr.ac.ru/ip-routing .
      • -
      • If you have any entry for a zone in /etc/shorewall/hosts then the -zone must be entirely defined in /etc/shorewall/hosts unless you have - specified MERGE_HOSTS=Yes (Shorewall version 1.3.5 and later). For example, if -a zone has two interfaces but only one interface has an entry in /etc/shorewall/hosts -then hosts attached to the other interface will not be considered -part of the zone.
      • -
      • Problems with NAT? Be sure that you let Shorewall add all external addresses -to be use with NAT unless you have set -ADD_IP_ALIASES -=No in /etc/shorewall/shorewall.conf.
      • -
      -

      Still Having Problems?

      -

      See the support page.

      +
    • If you have any entry for a zone in /etc/shorewall/hosts +then the zone must be entirely defined in /etc/shorewall/hosts unless you +have specified MERGE_HOSTS=Yes (Shorewall version 1.3.5 and later). +For example, if a zone has two interfaces but only one interface has an +entry in /etc/shorewall/hosts then hosts attached to the other interface +will not be considered part of the zone.
    • +
    • Problems with NAT? Be sure that you let Shorewall add all external +addresses to be use with NAT unless you have set ADD_IP_ALIASES =No in /etc/shorewall/shorewall.conf.
    • + +
    + +

    Still Having Problems?

    + +

    See the support page.

    + +
    +
    +

    Last updated 10/17/2002 - Tom Eastep

    - - -
    - -
    - -

    Last updated 9/13/2002 - -Tom Eastep -

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    - +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    +
    - \ No newline at end of file + diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index d815e38dd..ba8f2ce32 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,170 +1,178 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    +

    Upgrade Issues

    -
    - +

    For upgrade instructions see the Install/Upgrade page.

    - + +

    Version 1.3.10

    +If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version +1.3.10, you will need to use the '--force' option:
    +
    +
    +
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. If you have -an application that uses functions from that file, your application will need -to be changed to reflect this change of location.
    - + The 'functions' file has moved to /usr/lib/shorewall/functions. If you +have an application that uses functions from that file, your application +will need to be changed to reflect this change of location.
    +

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - + +

    If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

    +

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following rules in - their /etc/shorewall/icmpdef file (creating - this file if necessary):

    - + +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following rules +in their /etc/shorewall/icmpdef file (creating + this file if necessary):

    +
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

    - -

    Upgrading Bering to - Shorewall >= 1.3.3

    - -

    To properly upgrade with Shorewall version - 1.3.3 and later:

    - + +

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

    + +

    Upgrading Bering to + Shorewall >= 1.3.3

    + +

    To properly upgrade with Shorewall version + 1.3.3 and later:

    +
      -
    1. Be sure you have a backup -- you -will need to transcribe any Shorewall configuration - changes that you have made to the new - configuration.
    2. -
    3. Replace the shorwall.lrp package -provided on the Bering floppy with the -later one. If you did not obtain the later -version from Jacques's site, see additional -instructions below.
    4. -
    5. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall entry - if present. Then do not forget to backup - root.lrp !
    6. - +
    7. Be sure you have a backup -- you +will need to transcribe any Shorewall configuration + changes that you have made to the new + configuration.
    8. +
    9. Replace the shorwall.lrp package +provided on the Bering floppy with the later +one. If you did not obtain the later version +from Jacques's site, see additional instructions + below.
    10. +
    11. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall +entry if present. Then do not forget to +backup root.lrp !
    12. +
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions - for setting up a two-interface firewall plus you also need to add the - following two Bering-specific rules to /etc/shorewall/rules:

    - -
    + +

    The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions + for setting up a two-interface firewall plus you also need to add +the following two Bering-specific rules to /etc/shorewall/rules:

    + +
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - +
    +

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions 1.3.6 and - 1.3.7

    - + +

    If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions 1.3.6 +and 1.3.7

    +
      -
    1. -

      Create the file /etc/shorewall/newnotsyn and in it add - the following rule
      -
      - run_iptables -A newnotsyn -j RETURN # +

    2. +

      Create the file /etc/shorewall/newnotsyn and in it add + the following rule
      +
      + run_iptables -A newnotsyn -j RETURN # So that the connection tracking table can be rebuilt
      -                                     # from non-SYN packets -after takeover.
      -  

      -
    3. -
    4. -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A common -p tcp --tcp-flags - ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
      -                                                                     - #tracking table.
      - . /etc/shorewall/common.def

      -
    5. - +                                     # from non-SYN packets + after takeover.
      +  

      + +
    6. +

      Create /etc/shorewall/common (if you don't already + have that file) and include the following:
      +
      + run_iptables -A common -p tcp --tcp-flags + ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
      +                                                                     + #tracking table.
      + . /etc/shorewall/common.def

      +
    7. +
    - +

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no - longer supported.

    - + +

    Some forms of pre-1.3.0 rules file syntax are no + longer supported.

    +

    Example 1:

    - -
    + +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - +
    +

    Must be replaced with:

    - -
    + +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    - -
    +
    + +

    Example 2:

    -
    - -
    +
    + +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    - -
    +
    + +

    Must be replaced with:

    -
    - -
    +
    + +
    	REDIRECT	loc	3128	tcp	80
    -
    - +
    +

    Version >= 1.3.2

    - -

    The functions and versions files together with the - 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

    - -

    Last updated 9/30/2002 - - Tom Eastep

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    -
    + +

    The functions and versions files together with the + 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

    + +

    Last updated 11/09/2002 - + Tom Eastep

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    +
    +



    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 506ebe8c8..76fa4491f 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.9b +VERSION=1.3.10 usage() # $1 = exit status { @@ -38,7 +38,7 @@ usage() # $1 = exit status restore_file() # $1 = file to restore { - if [ -f ${1}-${VERSION}.bkout ]; then + if [ -f ${1}-${VERSION}.bkout -o -L ${1}-${VERSION}.bkout ]; then if (mv -f ${1}-${VERSION}.bkout $1); then echo echo "$1 restored" @@ -62,6 +62,10 @@ if [ -L /usr/lib/shorewall/firewall ]; then elif [ -L /var/lib/shorewall/firewall ]; then FIREWALL=`ls -l /var/lib/shorewall/firewall | sed 's/^.*> //'` restore_file $FIREWALL +elif [ -L /usr/lib/shorewall/init ]; then + FIREWALL=`ls -l /usr/lib/shorewall/init | sed 's/^.*> //'` + restore_file $FIREWALL + restore_file /usr/lib/shorewall/firewall fi restore_file /sbin/shorewall @@ -73,6 +77,7 @@ restore_file /etc/shorewall/shorewall.conf restore_file /etc/shorewall/functions restore_file /usr/lib/shorewall/functions restore_file /var/lib/shorewall/functions +restore_file /usr/lib/shorewall/firewall restore_file /etc/shorewall/common.def @@ -96,6 +101,8 @@ restore_file /etc/shorewall/proxyarp restore_file /etc/shorewall/routestopped +restore_file /etc/shorewall/maclist + restore_file /etc/shorewall/masq restore_file /etc/shorewall/modules diff --git a/STABLE/firewall b/STABLE/firewall index 04c56de17..b44f429ae 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -1,5 +1,4 @@ #!/bin/sh -RCDLINKS="2,S41 3,S41 6,K41" # # The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.3 6/14/2002 # @@ -42,23 +41,10 @@ RCDLINKS="2,S41 3,S41 6,K41" # shorewall check Verify the more heavily-used # configuration files. -#### BEGIN INIT INFO -# Provides: shorewall -# Required-Start: $network -# Required-Stop: -# Default-Start: 2 3 5 -# Default-Stop: 0 1 6 -# Description: starts and stops the shorewall firewall -### END INIT INFO - -# chkconfig: 2345 25 90 -# description: Packet filtering firewall # - -############################################################################### -# Search a list looking for a match -- returns zero if a match found # -# 1 otherwise # -############################################################################### +# Search a list looking for a match -- returns zero if a match found +# 1 otherwise +# list_search() # $1 = element to search for , $2-$n = list { local e=$1 @@ -70,21 +56,22 @@ list_search() # $1 = element to search for , $2-$n = list return 1 } -############################################################################### -# Function to count list elements # -############################################################################### + +# +# Function to count list elements +# list_count() { local temp="`separate_list $1`" echo $temp | wc -w } -############################################################################### -# Mutual exclusion -- These functions are jackets for the mutual exclusion # -# routines in /usr/lib/shorewall/functions. They invoke # -# the corresponding function in that file if the user did # -# not specify "nolock" on the runline. # -############################################################################### +# +# Mutual exclusion -- These functions are jackets for the mutual exclusion +# routines in /usr/lib/shorewall/functions. They invoke +# the corresponding function in that file if the user did +# not specify "nolock" on the runline. +# my_mutex_on() { [ -n "$nolock" ] || { mutex_on; have_mutex=Yes; } } @@ -93,17 +80,17 @@ my_mutex_off() { [ -n "$have_mutex" ] && { mutex_off; have_mutex=; } } -############################################################################### -# Message to stderr # -############################################################################### +# +# Message to stderr +# error_message() # $* = Error Message { echo " $@" >&2 } -############################################################################### -# Fatal error -- stops the firewall after issuing the error message # -############################################################################### +# +# Fatal error -- stops the firewall after issuing the error message +# fatal_error() # $* = Error Message { echo " $@" >&2 @@ -111,10 +98,10 @@ fatal_error() # $* = Error Message exit 2 } -############################################################################### -# Fatal error during startup -- generate an error message and abend with # -# altering the state of the firewall # -############################################################################### +# +# Fatal error during startup -- generate an error message and abend with +# altering the state of the firewall +# startup_error() # $* = Error Message { echo " $@" >&2 @@ -124,25 +111,25 @@ startup_error() # $* = Error Message exit 2 } -############################################################################### -# Send a message to STDOUT and the System Log # -############################################################################### +# +# Send a message to STDOUT and the System Log +# report () { # $* = message echo "$@" logger "$@" } -############################################################################### -# Perform variable substitution on the passed argument and echo the result # -############################################################################### +# +# Perform variable substitution on the passed argument and echo the result +# expand() # $1 = contents of variable which may be the name of another variable { eval echo \"$1\" } -############################################################################### -# Perform variable substitition on the values of the passed list of variables # -############################################################################### +# +# Perform variable substitition on the values of the passed list of variables +# expandv() # $* = list of variable names { local varval @@ -154,50 +141,50 @@ expandv() # $* = list of variable names done } -################################################################################ -# Run iptables and if an error occurs, stop the firewall and quit # -################################################################################ +# +# Run iptables and if an error occurs, stop the firewall and quit +# run_iptables() { if ! iptables `echo $@ | sed 's/!/! /g'`; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } -################################################################################ -# Run ip and if an error occurs, stop the firewall and quit # -################################################################################ +# +# Run ip and if an error occurs, stop the firewall and quit +# run_ip() { if ! ip $@ ; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } -################################################################################ -# Run arp and if an error occurs, stop the firewall and quit # -################################################################################ +# +# Run arp and if an error occurs, stop the firewall and quit +# run_arp() { if ! arp $@ ; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } -################################################################################ -# Run tc and if an error occurs, stop the firewall and quit # -################################################################################ +# +# Run tc and if an error occurs, stop the firewall and quit +# run_tc() { if ! tc $@ ; then [ -z "$stopping" ] && { stop_firewall; exit 2; } fi } -################################################################################ -# Create a filter chain # -# # -# If the chain isn't one of the common chains then add a rule to the chain # -# allowing packets that are part of an established connection. Create a # -# variable ${1}_exists and set its value to Yes to indicate that the chain now # -# exists. # -################################################################################ +# +# Create a filter chain +# +# If the chain isn't one of the common chains then add a rule to the chain +# allowing packets that are part of an established connection. Create a +# variable ${1}_exists and set its value to Yes to indicate that the chain now +# exists. +# createchain() # $1 = chain name, $2 = If non-null, don't create default rules { local target @@ -215,41 +202,41 @@ createchain() # $1 = chain name, $2 = If non-null, don't create default rules eval ${1}_exists=Yes } -################################################################################ -# Determine if a chain exists # -# # -# When we create a chain "chain", we create a variable named chain_exists and # -# set its value to Yes. This function tests for the "_exists" variable # -# corresponding to the passed chain having the value of "Yes". # -################################################################################ +# +# Determine if a chain exists +# +# When we create a chain "chain", we create a variable named chain_exists and +# set its value to Yes. This function tests for the "_exists" variable +# corresponding to the passed chain having the value of "Yes". +# havechain() # $1 = name of chain { eval test \"\$${1}_exists\" = Yes } -################################################################################ -# Ensure that a chain exists (create it if it doesn't) # -################################################################################ +# +# Ensure that a chain exists (create it if it doesn't) +# ensurechain() # $1 = chain name { havechain $1 || createchain $1 } -################################################################################ -# Add a rule to a chain creating the chain if necessary # -################################################################################ +# +# Add a rule to a chain creating the chain if necessary +# addrule() # $1 = chain name, remainder of arguments specify the rule { ensurechain $1 run_iptables -A $@ } -################################################################################ -# Create a nat chain # -# # -# Create a variable ${1}_nat_exists and set its value to Yes to indicate that # -# the chain now exists. # -################################################################################ +# +# Create a nat chain +# +# Create a variable ${1}_nat_exists and set its value to Yes to indicate that +# the chain now exists. +# createnatchain() # $1 = chain name { run_iptables -t nat -N $1 @@ -257,73 +244,73 @@ createnatchain() # $1 = chain name eval ${1}_nat_exists=Yes } -################################################################################ -# Determine if a nat chain exists # -# # -# When we create a chain "chain", we create a variable named chain_nat_exists # -# and set its value to Yes. This function tests for the "_exists" variable # -# corresponding to the passed chain having the value of "Yes". # -################################################################################ +# +# Determine if a nat chain exists +# +# When we create a chain "chain", we create a variable named chain_nat_exists +# and set its value to Yes. This function tests for the "_exists" variable +# corresponding to the passed chain having the value of "Yes". +# havenatchain() # $1 = name of chain { eval test \"\$${1}_nat_exists\" = Yes } -################################################################################ -# Ensure that a chain exists (create it if it doesn't) # -################################################################################ +# +# Ensure that a chain exists (create it if it doesn't) +# ensurenatchain() # $1 = chain name { havenatchain $1 || createnatchain $1 } -################################################################################ -# Add a rule to a nat chain creating the chain if necessary # -################################################################################ +# +# Add a rule to a nat chain creating the chain if necessary +# addnatrule() # $1 = chain name, remainder of arguments specify the rule { ensurenatchain $1 run_iptables -t nat -A $@ } -################################################################################ -# Delete a chain if it exists # -################################################################################ +# +# Delete a chain if it exists +# deletechain() # $1 = name of chain { qt iptables -L $1 -n && qt iptables -F $1 && qt iptables -X $1 } -################################################################################ -# Set a standard chain's policy # -################################################################################ +# +# Set a standard chain's policy +# setpolicy() # $1 = name of chain, $2 = policy { run_iptables -P $1 $2 } -################################################################################ -# Set a standard chain to enable established connections # -################################################################################ +# +# Set a standard chain to enable established connections +# setcontinue() # $1 = name of chain { run_iptables -A $1 -m state --state ESTABLISHED -j ACCEPT } -################################################################################ -# Flush one of the NAT table chains # -################################################################################ +# +# Flush one of the NAT table chains +# flushnat() # $1 = name of chain { run_iptables -t nat -F $1 } -################################################################################ -# Find interfaces to a given zone # -# # -# Read the interfaces file and for each record matching the passed ZONE, # -# echo the expanded contents of the "INTERFACE" column # -################################################################################ +# +# Find interfaces to a given zone +# +# Read the interfaces file and for each record matching the passed ZONE, +# echo the expanded contents of the "INTERFACE" column +# find_interfaces() # $1 = interface zone { local zne=$1 @@ -333,9 +320,9 @@ find_interfaces() # $1 = interface zone done < $TMP_DIR/interfaces } -################################################################################ -# Chain name base for an interface # -################################################################################ +# +# Chain name base for an interface +# chain_base() #$1 = interface { local c=${1%%+*} @@ -343,57 +330,75 @@ chain_base() #$1 = interface echo ${c:=common} } -################################################################################ -# Forward Chain for an interface # -################################################################################ +# +# Forward Chain for an interface +# forward_chain() # $1 = interface { echo `chain_base $1`_fwd } -################################################################################ -# Input Chain for an interface # -################################################################################ +# +# Input Chain for an interface +# input_chain() # $1 = interface { echo `chain_base $1`_in } -################################################################################ -# Output Chain for an interface # -################################################################################ +# +# Input Chains (input and forward) for an interface +# +input_chains() # $1 = interface +{ + local base=`chain_base $1` + + echo ${base}_in ${base}_fwd +} + +# +# Output Chain for an interface +# output_chain() # $1 = interface { echo `chain_base $1`_out } -################################################################################ -# Masquerade Chain for an interface # -################################################################################ +# +# Masquerade Chain for an interface +# masq_chain() # $1 = interface { echo `chain_base $1`_masq } -################################################################################ -# DNAT Chain from a zone # -################################################################################ +# +# MAC Verification Chain for an interface +# +mac_chain() # $1 = interface +{ + echo `chain_base $1`_mac +} + +# +# DNAT Chain from a zone +# dnat_chain() # $1 = zone { echo ${1}_dnat } -################################################################################ -# SNAT Chain to a zone # -################################################################################ +# +# SNAT Chain to a zone +# snat_chain() # $1 = zone { echo ${1}_snat } -################################################################################ -# First chains for an interface # -################################################################################ +# +# First chains for an interface +# first_chains() #$1 = interface { local c=`chain_base $1` @@ -401,12 +406,12 @@ first_chains() #$1 = interface echo ${c}_fwd ${c}_in } -################################################################################ -# Find hosts in a given zone # -# # -# Read hosts file and for each record matching the passed ZONE, # -# echo the expanded contents of the "HOST(S)" column # -################################################################################ +# +# Find hosts in a given zone +# +# Read hosts file and for each record matching the passed ZONE, +# echo the expanded contents of the "HOST(S)" column +# find_hosts() # $1 = host zone { local hosts @@ -416,12 +421,12 @@ find_hosts() # $1 = host zone done < $TMP_DIR/hosts } -################################################################################ -# Determine the interfaces on the firewall # -# # -# For each zone, create a variable called ${zone}_interfaces. This # -# variable contains a space-separated list of interfaces to the zone # -################################################################################ +# +# Determine the interfaces on the firewall +# +# For each zone, create a variable called ${zone}_interfaces. This +# variable contains a space-separated list of interfaces to the zone +# determine_interfaces() { for zone in $zones; do interfaces=`find_interfaces $zone` @@ -430,9 +435,9 @@ determine_interfaces() { done } -################################################################################ -# Determine the defined hosts in each zone and generate report # -################################################################################ +# +# Determine the defined hosts in each zone and generate report +# determine_hosts() { do_a_zone() { @@ -470,19 +475,19 @@ determine_hosts() { hosts=`echo $hosts` # Remove extra trash if [ -n "MERGE_HOSTS" ]; then - #################################################################### + # # Zone will be the union of its host and interface definitions # do_a_zone recalculate_interfaces elif [ -n "$hosts" ]; then - #################################################################### + # # Zone is defined in terms of hosts -- derive the interface list # from the host list # - recalculate_interfaces + recalculate_interface else - #################################################################### + # # If no hosts are defined for a zone then the zone consists of any # host that can send us messages via the interfaces to the zone # @@ -500,17 +505,17 @@ determine_hosts() { done } -################################################################################ -# Ensure that the passed zone is defined in the zones file or is the firewall # -################################################################################ +# +# Ensure that the passed zone is defined in the zones file or is the firewall +# validate_zone() # $1 = zone { list_search $1 $zones $FW } -################################################################################ -# Validate the zone names and options in the interfaces file # -################################################################################ +# +# Validate the zone names and options in the interfaces file +# validate_interfaces_file() { while read z interface subnet options; do expandv z interface subnet options @@ -526,7 +531,7 @@ validate_interfaces_file() { case $option in dhcp|noping|filterping|routestopped|norfc1918|multi) ;; - routefilter|dropunclean|logunclean|blacklist|proxyarp|-) + routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) ;; *) error_message "Warning: Invalid option ($option) in record \"$r\"" @@ -539,9 +544,9 @@ validate_interfaces_file() { done < $TMP_DIR/interfaces } -################################################################################ -# Validate the zone names and options in the hosts file # -################################################################################ +# +# Validate the zone names and options in the hosts file +# validate_hosts_file() { while read z hosts options; do expandv z hosts options @@ -556,7 +561,7 @@ validate_hosts_file() { for option in `separate_list $options`; do case $option in - routestopped|-) + routestopped|maclist|-) ;; *) error_message "Warning: Invalid option ($option) in record \"$r\"" @@ -567,28 +572,28 @@ validate_hosts_file() { done < $TMP_DIR/hosts } -################################################################################ -# Format a match by the passed MAC address # -# The passed address begins with "~" and uses "-" as a separator between bytes # -# Example: ~01-02-03-04-05-06 # -################################################################################ +# +# Format a match by the passed MAC address +# The passed address begins with "~" and uses "-" as a separator between bytes +# Example: ~01-02-03-04-05-06 +# mac_match() # $1 = MAC address formated as described above { echo "--match mac --mac-source `echo $1 | sed 's/~//;s/-/:/g'`" } -################################################################################ -# validate a record from the rules file # -# # -# The caller has loaded the column contents from the record into the following # -# variables: # -# # -# target clients servers protocol ports cports address # -# # -# and has loaded a space-separated list of their values in "rule". # -################################################################################ +# +# validate a record from the rules file +# +# The caller has loaded the column contents from the record into the following +# variables: +# +# target clients servers protocol ports cports address +# +# and has loaded a space-separated list of their values in "rule". +# validate_rule() { - ############################################################################ + # # Ensure that the passed comma-separated list has 15 or fewer elements # validate_list() { @@ -597,11 +602,11 @@ validate_rule() { [ `echo $temp | wc -w` -le 15 ] } - ############################################################################ + # # validate one rule # validate_a_rule() { - ######################################################################## + # # Determine the format of the client # cli= @@ -646,7 +651,7 @@ validate_rule() { serv= ;; esac - ################################################################ + # # Setup PROTOCOL, PORT and STATE variables # sports="" @@ -710,11 +715,11 @@ validate_rule() { fi if [ -n "${serv}${servport}" ]; then - ################################################################## + # # Destination is a Specific Server or we're redirecting a port # if [ -n "$addr" -a "$addr" != "$serv" ]; then - ############################################################## + # # Must use Prerouting DNAT # if [ -z "$NAT_ENABLED" ]; then @@ -733,9 +738,9 @@ validate_rule() { " a DNAT or REDIRECT rule: \"$rule\"" fi } - ############################################################################ + # # V a l i d a t e _ R u l e S t a r t s H e r e - ############################################################################ + # # Parse the Target and Clients columns # if [ "$target" = "${target%:*}" ]; then @@ -794,9 +799,9 @@ validate_rule() { [ "$logtarget" = DNAT ] || [ "$logtarget" = REDIRECT ] ||\ startup_error "Error: Exclude list only allowed with DNAT or REDIRECT" fi - ############################################################################ + # # Validate the Source Zone - + # if ! validate_zone $clientzone; then startup_error "Error: Undefined Client Zone in rule \"$rule\"" fi @@ -805,7 +810,7 @@ validate_rule() { [ $source = $FW ] && source_hosts= || eval source_hosts=\"\$${source}_hosts\" - ############################################################################ + # # Parse the servers column # if [ "$servers" = "${servers%:*}" ] ; then @@ -826,7 +831,7 @@ validate_rule() { startup_error "Error: Empty destination zone or qualifier: rule \"$rule\"" fi fi - ############################################################################ + # # Validate the destination zone # if ! validate_zone $serverzone; then @@ -834,7 +839,7 @@ validate_rule() { fi dest=$serverzone - ############################################################################ + # # Check length of port lists if MULTIPORT set # if [ -n "$MULTIPORT" ]; then @@ -844,7 +849,7 @@ validate_rule() { error_message "Warning: Too many source ports: Rule \"$rule\"" fi - ############################################################################ + # # Iterate through the various lists validating individual rules # for client in `separate_list ${clients:=-}`; do @@ -860,9 +865,9 @@ validate_rule() { echo " Rule \"$rule\" validated." } -################################################################################ -# validate the rules file # -################################################################################ +# +# validate the rules file +# validate_rules() # $1 = name of rules file { strip_file rules @@ -883,9 +888,9 @@ validate_rules() # $1 = name of rules file done < $TMP_DIR/rules } -################################################################################ -# validate the policy file # -################################################################################ +# +# validate the policy file +# validate_policy() { strip_file policy $policy @@ -921,9 +926,9 @@ validate_policy() done < $TMP_DIR/policy } -################################################################################ -# Find broadcast addresses # -################################################################################ +# +# Find broadcast addresses +# find_broadcasts() { while read z interface bcast options; do expandv interface bcast @@ -940,10 +945,34 @@ find_broadcasts() { done < $TMP_DIR/interfaces } -################################################################################ -# Find interface address--returns the first IP address assigned to the passed # -# device # -################################################################################ +# +# Find interface broadcast addresses +# +find_interface_broadcasts() # $1 = Interface name +{ + while read z interface bcast options; do + expandv interface bcast + if [ "$interface" = "$1" ]; then + if [ "x$bcast" = "xdetect" ]; then + addr="`ip addr show $interface 2> /dev/null`" + if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then + addr="`echo "$addr" | \ + grep "inet " | sed 's/^.* inet.*brd //;s/scope.*//'`" + echo $addr | cut -d' ' -f 1 + fi + elif [ "x${bcast}" != "x-" ]; then + echo `separate_list $bcast` + fi + + return + fi + done < $TMP_DIR/interfaces +} + +# +# Find interface address--returns the first IP address assigned to the passed +# device +# find_interface_address() # $1 = interface { # @@ -961,9 +990,9 @@ find_interface_address() # $1 = interface echo $addr | sed 's/inet //;s/\/.*//;s/ peer.*//' } -################################################################################ -# Find interfaces that have the passed option specified # -################################################################################ +# +# Find interfaces that have the passed option specified +# find_interfaces_by_option() # $1 = option { while read ignore interface subnet options; do @@ -973,9 +1002,9 @@ find_interfaces_by_option() # $1 = option done < $TMP_DIR/interfaces } -################################################################################ -# Find hosts with the passed option # -################################################################################ +# +# Find hosts with the passed option +# find_hosts_by_option() # $1 = option { while read ignore hosts options; do @@ -991,11 +1020,11 @@ find_hosts_by_option() # $1 = option done < $TMP_DIR/interfaces } -################################################################################ -# Determine if there are interfaces of the given zone and option # -# # -# Returns zero if any such interfaces are found and returns one otherwise. # -################################################################################ +# +# Determine if there are interfaces of the given zone and option +# +# Returns zero if any such interfaces are found and returns one otherwise. +# have_interfaces_in_zone_with_option() # $1 = zone, $2 = option { local zne=$1 @@ -1008,17 +1037,17 @@ have_interfaces_in_zone_with_option() # $1 = zone, $2 = option return 1 } -################################################################################ -# Flush and delete all user-defined chains in the filter table # -################################################################################ +# +# Flush and delete all user-defined chains in the filter table +# deleteallchains() { run_iptables -F run_iptables -X } -################################################################################ -# Source a user exit file if it exists # -################################################################################ +# +# Source a user exit file if it exists +# run_user_exit() # $1 = file name { local user_exit=`find_file $1` @@ -1029,9 +1058,9 @@ run_user_exit() # $1 = file name fi } -################################################################################ -# Stop the Firewall - # -################################################################################ +# +# Stop the Firewall +# stop_firewall() { stopping="Yes" @@ -1115,9 +1144,9 @@ stop_firewall() { esac } -################################################################################ -# Remove all rules and remove all user-defined chains # -################################################################################ +# +# Remove all rules and remove all user-defined chains +# clear_firewall() { stop_firewall @@ -1134,33 +1163,39 @@ clear_firewall() { logger "Shorewall Cleared" } -################################################################################ -# Set up ipsec tunnels # -################################################################################ +# +# Set up ipsec tunnels +# setup_tunnels() # $1 = name of tunnels file { local inchain local outchain - setup_one_ipsec() # $1 = gateway $2 = gateway zone + setup_one_ipsec() # $1 = gateway $2 = Tunnel Kind $3 = gateway zones { options="-m state --state NEW -j ACCEPT" addrule $inchain -p 50 -s $1 -j ACCEPT addrule $outchain -p 50 -d $1 -j ACCEPT run_iptables -A $inchain -p 51 -s $1 -j ACCEPT run_iptables -A $outchain -p 51 -d $1 -j ACCEPT - run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options - run_iptables -A $outchain -p udp -d $1 --dport 500 --sport 500 $options - if [ -n "$2" ]; then - if validate_zone $2; then - addrule ${FW}2${2} -p udp --sport 500 --dport 500 $options - addrule ${2}2${FW} -p udp --sport 500 --dport 500 $options + run_iptables -A $outchain -p udp -d $1 --dport 500 --sport 500 $options + + if [ $2 = ipsec ]; then + run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options + else + run_iptables -A $inchain -p udp -s $1 --dport 500 $options + fi + + for z in `separate_list $3`; do + if validate_zone $z; then + addrule ${FW}2${z} -p udp --sport 500 --dport 500 $options + addrule ${z}2${FW} -p udp --sport 500 --dport 500 $options else - error_message "Warning: Invalid gateway zone ($2)" \ + error_message "Warning: Invalid gateway zone ($z)" \ " -- Tunnel \"$tunnel\" may encounter keying problems" fi - fi + done echo " IPSEC tunnel to $gateway defined." } @@ -1170,7 +1205,23 @@ setup_tunnels() # $1 = name of tunnels file addrule $inchain -p $3 -s $2 -j ACCEPT addrule $outchain -p $3 -d $2 -j ACCEPT - echo " $1 tunnel to $gateway defined." + echo " $1 tunnel to $2 defined." + } + + setup_pptp_client() # $1 = gateway + { + addrule $outchain -p 47 -d $1 -j ACCEPT + addrule $outchain -p tcp --dport 1723 -d $1 -j ACCEPT + + echo " PPTP tunnel to $1 defined." + } + + setup_pptp_server() + { + addrule $inchain -p 47 -j ACCEPT + addrule $inchain -p tcp --dport 1723 -j ACCEPT + + echo " PPTP server defined." } strip_file tunnels $1 @@ -1183,13 +1234,22 @@ setup_tunnels() # $1 = name of tunnels file outchain=${FW}2${z} case $kind in ipsec|IPSEC) - setup_one_ipsec $gateway $z1 + setup_one_ipsec $gateway ipsec $z1 + ;; + ipsecnat|IPSECNAT) + setup_one_ipsec $gateway ipsecnat $z1 ;; ipip|IPIP) setup_one_other IPIP $gateway 4 ;; gre|GRE) - setup_one_other GRE $gateway 47 + setup_one_other GRE $gateway 47 + ;; + pptpclient|PPTPCLIENT) + setup_pptp_client $gateway + ;; + pptpserver|PPTPSERVER) + setup_pptp_server ;; *) error_message "Tunnels of type $kind are not supported:" \ @@ -1203,9 +1263,9 @@ setup_tunnels() # $1 = name of tunnels file done < $TMP_DIR/tunnels } -################################################################################ -# Setup Proxy ARP # -################################################################################ +# +# Setup Proxy ARP +# setup_proxy_arp() { print_error() { @@ -1260,9 +1320,133 @@ setup_proxy_arp() { done } -############################################################################### -# Set up SYN flood protection # -############################################################################### +# +# Set up MAC Verification +# +setup_mac_lists() { + local interface + local mac + local addresses + local address + local chain + local logpart + local macpart + local blob + local hosts + # + # Generate the list of interfaces having MAC verification + # + maclist_interfaces= + + for hosts in $maclist_hosts; do + interface=${hosts%:*} + if ! list_search $interface $maclist_interfaces; then\ + if [ -z "$maclist_interfaces" ]; then + maclist_interfaces=$interface + else + maclist_interfaces="$maclist_interfaces $interface" + fi + fi + done + + echo "Setting up MAC Verification on $maclist_interfaces..." + # + # Be sure that they are all ethernet interfaces + # + for interface in $maclist_interfaces; do + case $interface in + eth*) + ;; + *) + fatal_error "Error: MAC verification is only supported on ethernet devices: $interface" + ;; + esac + + createchain `mac_chain $interface` no + done + # + # Process the maclist file producing the verification rules + # + strip_file maclist + + while read interface mac addresses; do + expandv interface mac addresses + + chain=`mac_chain $interface` + + if ! havechain $chain ; then + fatal_error "Error: No hosts on $interface have the maclist option specified" + fi + + macpart=`mac_match $mac` + + if [ -z "$addresses" ]; then + run_iptables -A $chain $macpart -j RETURN + else + for address in `separate_list $addresses` ; do + run_iptables -A $chain $macpart -s $address -j RETURN + done + fi + done < $TMP_DIR/maclist + # + # Setup Logging variables + # + if [ -n "$MACLIST_LOG_LEVEL" ]; then + logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" + else + logpart= + fi + # + # Must take care of our own broadcasts and multicasts then terminate the verification + # chains + # + for interface in $maclist_interfaces; do + chain=`mac_chain $interface` + blob=`ip addr show $interface 2> /dev/null | grep inet | sed 's/inet //; s/brd //; s/scope.*//;'` + + [ -z "$blob" ] && \ + fatal_error "Error: Interface $interface must be up before Shorewall can start" + + set -- $blob + + while [ $# -gt 0 ]; do + address=${1%/*} + + case $1 in + */32) + ;; + *) + run_iptables -A $chain -s $address -d $2 -j RETURN + shift + ;; + esac + + run_iptables -A $chain -s $address -d 255.255.255.255 -j RETURN + run_iptables -A $chain -s $address -d 224.0.0.0/4 -j RETURN + shift + done + + [ -n "$logpart" ] && \ + run_iptables -A $chain $logpart "Shorewall:$chain:$MACLIST_DISPOSITION:" + + run_iptables -A $chain -j $maclist_target + done + # + # Generate jumps from the input and forward chains + # + for hosts in $maclist_hosts; do + interface=${hosts%:*} + hosts=${hosts#*:} + for chain in `input_chains $interface` ; do + run_iptables -A $chain -s $hosts -m state --state NEW \ + -j `mac_chain $interface` + done + done +} + +# +# Set up SYN flood protection +# setup_syn_flood_chain () # $1 = policy chain # $2 = synparams @@ -1278,21 +1462,21 @@ setup_syn_flood_chain () run_iptables -A @$chain -j DROP } -################################################################################ -# Enable SYN flood protection on a chain # -# -----------------------------------------------------------------------------# -# Insert a jump rule to the protection chain from the first chain. Inserted # -# as the second rule and restrict the jump to SYN packets # -################################################################################ +# +# Enable SYN flood protection on a chain +# +# Insert a jump rule to the protection chain from the first chain. Inserted +# as the second rule and restrict the jump to SYN packets +# enable_syn_flood_protection() # $1 = chain, $2 = protection chain { run_iptables -I $1 2 -p tcp --syn -j @$2 echo " Enabled SYN flood protection" } -################################################################################ -# Delete existing Proxy ARP # -################################################################################ +# +# Delete existing Proxy ARP +# delete_proxy_arp() { if [ -f ${STATEDIR}/proxyarp ]; then while read address interface external haveroute; do @@ -1310,9 +1494,9 @@ delete_proxy_arp() { done } -################################################################################ -# Setup Static Network Address Translation (NAT) # -################################################################################ +# +# Setup Static Network Address Translation (NAT) +# setup_nat() { local allints # @@ -1356,9 +1540,9 @@ setup_nat() { done < $TMP_DIR/nat } -################################################################################ -# Delete existing Static NAT # -################################################################################ +# +# Delete existing Static NAT +# delete_nat() { run_iptables -t nat -F run_iptables -t nat -X @@ -1374,9 +1558,9 @@ delete_nat() { [ -d ${STATEDIR} ] && touch ${STATEDIR}/nat } -################################################################################ -# Process TC Rule # -################################################################################ +# +# Process a TC Rule +# process_tc_rule() { add_a_tc_rule() { @@ -1385,18 +1569,22 @@ process_tc_rule() if [ "x$source" != "x-" ]; then case $source in - *.*.*) - r="-s $source " - ;; - ~*) - r=`mac_match $source` - ;; - $FW) - chain=tcout - ;; - *) - r="-i $source " - ;; + *.*.*) + r="-s $source " + ;; + ~*) + r=`mac_match $source` + ;; + $FW) + chain=tcout + ;; + *) + if ! list_search $source $all_interfaces; then + fatal_error "Error: Unknown interface $source" + fi + + r="-i $source " + ;; esac fi [ "x$dest" = "x-" ] || r="${r}-d $dest " @@ -1421,9 +1609,9 @@ process_tc_rule() echo " TC Rule \"$rule\" added" } -################################################################################ -# Setup queuing and classes # -################################################################################ +# +# Setup queuing and classes +# setup_tc() { echo "Setting up Traffic Control Rules..." @@ -1453,9 +1641,9 @@ setup_tc() { } -################################################################################ -# Clear Traffic Shaping # -################################################################################ +# +# Clear Traffic Shaping +# delete_tc() { clear_one_tc() { @@ -1477,21 +1665,21 @@ delete_tc() done } -################################################################################ -# Add a NAT rule - Helper function for the rules file processor # -#------------------------------------------------------------------------------# -# The caller has established the following variables: # -# cli = Source IP, interface or MAC Specification # -# serv = Destination IP Specification # -# servport = Port the server is listening on # -# dest_interface = Destination Interface Specification # -# proto = Protocol Specification # -# addr = Original Destination Address # -# dports = Destination Port Specification. 'dports' may be changed # -# by this function # -# cport = Source Port Specification # -# multiport = String to invoke multiport match if appropriate # -################################################################################ +# +# Add a NAT rule - Helper function for the rules file processor +# +# The caller has established the following variables: +# cli = Source IP, interface or MAC Specification +# serv = Destination IP Specification +# servport = Port the server is listening on +# dest_interface = Destination Interface Specification +# proto = Protocol Specification +# addr = Original Destination Address +# dports = Destination Port Specification. 'dports' may be changed +# by this function +# cport = Source Port Specification +# multiport = String to invoke multiport match if appropriate +# add_nat_rule() { local chain @@ -1605,20 +1793,20 @@ add_nat_rule() { fi } -################################################################################ -# Add one Filter Rule -- Helper function for the rules file processor # -#------------------------------------------------------------------------------# -# The caller has established the following variables: # -# client = SOURCE IP or MAC # -# server = DESTINATION IP or interface # -# protocol = Protocol # -# address = Original Destination Address # -# port = Destination Port # -# cport = Source Port # -# multioption = String to invoke multiport match if appropriate # -# servport = Port the server listens on # -# chain = The canonical chain for this rule # -################################################################################ +# +# Add one Filter Rule -- Helper function for the rules file processor +# +# The caller has established the following variables: +# client = SOURCE IP or MAC +# server = DESTINATION IP or interface +# protocol = Protocol +# address = Original Destination Address +# port = Destination Port +# cport = Source Port +# multioption = String to invoke multiport match if appropriate +# servport = Port the server listens on +# chain = The canonical chain for this rule +# add_a_rule() { # Set source variables @@ -1777,19 +1965,19 @@ add_a_rule() fi } -################################################################################ -# Process a record from the rules file # -# # -# The caller has loaded the column contents from the record into the following # -# variables: # -# # -# target clients servers protocol ports cports address # -# # -# and has loaded a space-separated list of their values in "rule". # -# # -# The 'multioption' variable has also been loaded appropriately to reflect # -# the setting of the MULTIPORT option in /etc/shorewall/shorewall.conf # -################################################################################ +# +# Process a record from the rules file +# +# The caller has loaded the column contents from the record into the following +# variables: +# +# target clients servers protocol ports cports address +# +# and has loaded a space-separated list of their values in "rule". +# +# The 'multioption' variable has also been loaded appropriately to reflect +# the setting of the MULTIPORT option in /etc/shorewall/shorewall.conf +# process_rule() { # Function Body -- isolate log level @@ -1916,9 +2104,9 @@ process_rule() { echo " Rule \"$rule\" added." } -################################################################################ -# Process the rules file # -################################################################################ +# +# Process the rules file +# process_rules() # $1 = name of rules file { strip_file rules @@ -1939,18 +2127,18 @@ process_rules() # $1 = name of rules file done < $TMP_DIR/rules } -################################################################################ -# Process a record from the tos file # -# # -# The caller has loaded the column contents from the record into the following # -# variables: # -# # -# src dst protocol sport dport tos # -# # -# and has loaded a space-separated list of their values in "rule". # -################################################################################ +# +# Process a record from the tos file +# +# The caller has loaded the column contents from the record into the following +# variables: +# +# src dst protocol sport dport tos +# +# and has loaded a space-separated list of their values in "rule". +# process_tos_rule() { - ############################################################################ + # # Parse the contents of the 'src' variable # if [ "$src" = "${src%:*}" ]; then @@ -1992,7 +2180,7 @@ process_tos_rule() { ;; esac - ############################################################################ + # # Parse the contents of the 'dst' variable # if [ "$dst" = "${dst%:*}" ]; then @@ -2033,7 +2221,7 @@ process_tos_rule() { ;; esac - ############################################################################ + # # Setup PROTOCOL and PORT variables # sports="" @@ -2103,9 +2291,9 @@ process_tos_rule() { echo " Rule \"$rule\" added." } -################################################################################ -# Process the tos file # -################################################################################ +# +# Process the tos file +# process_tos() # $1 = name of tos file { echo "Processing $1..." @@ -2125,9 +2313,9 @@ process_tos() # $1 = name of tos file run_iptables -t mangle -A OUTPUT -j outtos } -################################################################################ -# Load a Kernel Module # -################################################################################ +# +# Load a Kernel Module +# loadmodule() # $1 = module name, $2 - * arguments { local modulename=$1 @@ -2153,18 +2341,18 @@ loadmodule() # $1 = module name, $2 - * arguments fi } -################################################################################ -# Display elements of a list with leading white space # -################################################################################ +# +# Display elements of a list with leading white space +# display_list() # $1 = List Title, rest of $* = list to display { [ $# -gt 1 ] && echo " $*" } -################################################################################ -# Add rules to the "common" chain to silently drop packets addressed to any of # -# the passed addresses # -################################################################################ +# +# Add rules to the "common" chain to silently drop packets addressed to any of +# the passed addresses +# drop_broadcasts() # $* = broadcast addresses { while [ $# -gt 0 ]; do @@ -2173,9 +2361,9 @@ drop_broadcasts() # $* = broadcast addresses done } -################################################################################ -# Add policy rule ( and possibly logging rule) to the passed chain # -################################################################################ +# +# Add policy rule ( and possibly logging rule) to the passed chain +# policy_rules() # $1 = chain to add rules to # $2 = policy # $3 = loglevel @@ -2207,16 +2395,16 @@ policy_rules() # $1 = chain to add rules to [ -n "$target" ] && run_iptables -A $1 -j $target } -################################################################################ -# Generate default policy & log level rules for the passed client & server # -# zones # -#------------------------------------------------------------------------------# -# This function is only called when the canonical chain for this client/server # -# pair is known to exist. If the default policy for this pair specifies the # -# same chain then we add the policy (and logging) rule to the canonical chain; # -# otherwise add a rule to the canonical chain to jump to the appropriate # -# policy chain. # -################################################################################ +# +# Generate default policy & log level rules for the passed client & server +# zones +# +# This function is only called when the canonical chain for this client/server +# pair is known to exist. If the default policy for this pair specifies the +# same chain then we add the policy (and logging) rule to the canonical chain; +# otherwise add a rule to the canonical chain to jump to the appropriate +# policy chain. +# default_policy() # $1 = client $2 = server { local chain="${1}2${2}" @@ -2225,7 +2413,7 @@ default_policy() # $1 = client $2 = server local chain1 jump_to_policy_chain() { - ######################################################################## + # # Add a jump to from the canonical chain to the policy chain. On return, # $chain is set to the name of the policy chain # @@ -2235,36 +2423,36 @@ default_policy() # $1 = client $2 = server apply_default() { - ######################################################################## + # # Add the appropriate rules to the canonical chain ($chain) to enforce # the specified policy - #----------------------------------------------------------------------- + # # Construct policy chain name # chain1=${client}2${server} if [ "$chain" = "$chain1" ]; then - #################################################################### + # # The policy chain is the canonical chain; add policy rule to it # The syn flood jump has already been added if required. # policy_rules $chain $policy $loglevel else - #################################################################### + # # The policy chain is different from the canonical chain -- approach # depends on the policy # case $policy in ACCEPT) if [ -n "$synparams" ]; then - ############################################################ + # # To avoid double-counting SYN packets, enforce the policy # in this chain. # enable_syn_flood_protection $chain $chain1 policy_rules $chain $policy $loglevel else - ############################################################ + # # No problem with double-counting so just jump to the # policy chain. # @@ -2272,7 +2460,7 @@ default_policy() # $1 = client $2 = server fi ;; CONTINUE) - ################################################################ + # # Silly to jump to the policy chain -- add any logging # rules and enable SYN flood protection if requested # @@ -2281,7 +2469,7 @@ default_policy() # $1 = client $2 = server policy_rules $chain $policy $loglevel ;; *) - ################################################################ + # # DROP or REJECT policy -- enforce in the policy chain and # enable SYN flood protection if requested. # @@ -2318,7 +2506,7 @@ default_policy() # $1 = client $2 = server fatal_error "Error: No default policy for zone $1 to zone $2" } -################################################################################ +# # Complete a standard chain # # - run any supplied user exit @@ -2326,7 +2514,7 @@ default_policy() # $1 = client $2 = server # appropriate # - If no applicable policy is found, add rules for an assummed # policy of DROP INFO -################################################################################ +# complete_standard_chain() # $1 = chain, $2 = source zone, $3 = destination zone { local policy= @@ -2360,13 +2548,13 @@ complete_standard_chain() # $1 = chain, $2 = source zone, $3 = destination zone policy_rules $1 DROP INFO } -################################################################################ -# Find the appropriate chain to pass packets from a source zone to a # -# destination zone # -# # -# If the canonical chain for this zone pair exists, echo it's name; otherwise # -# locate and echo the name of the appropriate policy chain # -################################################################################ +# +# Find the appropriate chain to pass packets from a source zone to a +# destination zone +# +# If the canonical chain for this zone pair exists, echo it's name; otherwise +# locate and echo the name of the appropriate policy chain +# rules_chain() # $1 = source zone, $2 = destination zone { local chain=${1}2${2} @@ -2394,9 +2582,9 @@ rules_chain() # $1 = source zone, $2 = destination zone fatal_error "Error: No appropriate chain for zone $1 to zone $2" } -################################################################################ -# Set up Source NAT (including masquerading) # -################################################################################ +# +# Set up Source NAT (including masquerading) +# setup_masq() { setup_one() { @@ -2439,7 +2627,7 @@ setup_masq() iface="-o $interface" ;; *) - ipaddr="`run_ip addr show $subnet | grep 'inet '`" + ipaddr="`ip addr show $subnet 2> /dev/null | grep 'inet '`" source="$subnet" if [ -z "$ipaddr" ]; then fatal_error \ @@ -2500,9 +2688,9 @@ setup_masq() done < $TMP_DIR/masq } -################################################################################ -# Setup Intrazone chain if appropriate # -################################################################################ +# +# Setup Intrazone chain if appropriate +# setup_intrazone() # $1 = zone { eval hosts=\$${1}_hosts @@ -2513,13 +2701,13 @@ setup_intrazone() # $1 = zone ensurechain ${1}2${1} fi } -############################################################################### -# Add a record to the blacklst chain # -# # -# $source = address match # -# $proto = protocol selector # -# $dport = destination port selector # -############################################################################### +# +# Add a record to the blacklst chain +# +# $source = address match +# $proto = protocol selector +# $dport = destination port selector +# add_blacklist_rule() { [ -n "$BLACKLIST_LOGLEVEL" ] && \ run_iptables -A blacklst $source $proto $dport -j \ @@ -2529,13 +2717,13 @@ add_blacklist_rule() { run_iptables -A blacklst $source $proto $dport -j $disposition } -############################################################################### -# Process a record from the blacklist file # -# # -# $subnet = address/subnet # -# $protocol = Protocol Number/Name # -# $port = Port Number/Name # -############################################################################### +# +# Process a record from the blacklist file +# +# $subnet = address/subnet +# $protocol = Protocol Number/Name +# $port = Port Number/Name +# process_blacklist_rec() { local source local addr @@ -2604,9 +2792,9 @@ process_blacklist_rec() { done } -############################################################################### -# Setup the Black List # -############################################################################### +# +# Setup the Black List +# setup_blacklist() { local interfaces=`find_interfaces_by_option blacklist` local f=`find_file blacklist` @@ -2637,9 +2825,9 @@ setup_blacklist() { fi } -############################################################################### -# Refresh the Black List # -############################################################################### +# +# Refresh the Black List +# refresh_blacklist() { local f=`find_file blacklist` local disposition=$BLACKLIST_DISPOSITION @@ -2660,9 +2848,9 @@ refresh_blacklist() { fi } -############################################################################### -# Verify that kernel has netfilter support # -############################################################################### +# +# Verify that kernel has netfilter support +# verify_os_version() { osversion=`uname -r` @@ -2676,11 +2864,15 @@ verify_os_version() { esac } -################################################################################ -# Add IP Aliases # -################################################################################ +# +# Add IP Aliases +# add_ip_aliases() { + local external + local interface + local primary + do_one() { # @@ -2716,18 +2908,19 @@ add_ip_aliases() while [ $# -gt 0 ]; do external=$1 interface=$2 + primary=`find_interface_address $interface` shift;shift - do_one + [ "x${primary}" = "x${external}" ] || do_one done } -################################################################################ -# Load kernel modules required for Shorewall # -################################################################################ +# +# Load kernel modules required for Shorewall +# load_kernel_modules() { - [ -z "$MODULESDIR" ] && - MODULESDIR=/lib/modules/$osversion/kernel/net/ipv4/netfilter + [ -z "$MODULESDIR" ] && \ + MODULESDIR=/lib/modules/$osversion/kernel/net/ipv4/netfilter modules=`find_file modules` @@ -2737,14 +2930,14 @@ load_kernel_modules() { fi } -################################################################################ -# Perform Initialization # -# - Delete all old rules # -# - Delete all user chains # -# - Set the POLICY on all standard chains and add a rule to allow packets# -# that are part of established connections. # +# +# Perform Initialization +# - Delete all old rules +# - Delete all user chains +# - Set the POLICY on all standard chains and add a rule to allow packets +# that are part of established connections # - Determine the zones -################################################################################ +# initialize_netfilter () { echo "Determining Zones..." @@ -2800,6 +2993,9 @@ initialize_netfilter () { # # Allow DNS lookups during startup for FQDNs # + run_iptables -A INPUT -p udp --dport 53 -j ACCEPT # I suppose that there + # is an idiot somewhere + # who needs this run_iptables -A OUTPUT -p udp --dport 53 -j ACCEPT run_iptables -A FORWARD -p udp --dport 53 -j ACCEPT @@ -2846,20 +3042,20 @@ initialize_netfilter () { done } -################################################################################ -# Build the common chain -- called during [re]start and refresh # -################################################################################ +# +# Build the common chain -- called during [re]start and refresh +# build_common_chain() { - ########################################################################### + # # PING # [ -n "$FORWARDPING" ] && \ run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT - ############################################################################ + # # Common ICMP rules # run_user_exit icmpdef - ############################################################################ + # # Common rules in each chain # common=`find_file common` @@ -2869,33 +3065,33 @@ build_common_chain() { else . `find_file common.def` fi - ########################################################################### + # # New Not Syn Stuff # if [ -n "$NEWNOTSYN" ]; then run_iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT run_iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT fi - ########################################################################### + # # BROADCASTS # drop_broadcasts `find_broadcasts` } -################################################################################ -# Construct zone-independent rules # -################################################################################ +# +# Construct zone-independent rules +# add_common_rules() { logdisp() # $1 = Chain Name { echo "LOG --log-prefix "Shorewall:${1}:DROP:" --log-level info" } - ############################################################################ + # # Reject Rules # run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset run_iptables -A reject -j REJECT - ############################################################################ + # # dropunclean rules # interfaces="`find_interfaces_by_option dropunclean`" @@ -2907,8 +3103,7 @@ add_common_rules() { logoptions="$LOGPARAMS --log-prefix Shorewall:badpkt:DROP:" logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" run_iptables -A badpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A badpkt -p tcp -j DROP # Workaround for iptables 1.2.7 - run_iptables -A badpkt -j LOG $logoptions + run_iptables -A badpkt -p ! tcp -j LOG $logoptions fi run_iptables -A badpkt -j DROP @@ -2921,7 +3116,7 @@ add_common_rules() { echo " $interface" done fi - ############################################################################ + # # logunclean rules # interfaces="`find_interfaces_by_option logunclean`" @@ -2933,8 +3128,7 @@ add_common_rules() { logoptions="$LOGPARAMS --log-prefix Shorewall:logpkt:LOG:" logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" run_iptables -A logpkt -p tcp -j LOG $logoptions --log-tcp-options - run_iptables -A logpkt -p tcp -j RETURN # Workaround for iptables 1.2.7 - run_iptables -A logpkt -j LOG $logoptions + run_iptables -A logpkt -p ! tcp -j LOG $logoptions echo "Mangled/Invalid Packet Logging enabled on:" @@ -2948,7 +3142,7 @@ add_common_rules() { build_common_chain - ########################################################################### + # # DHCP # echo "Adding rules for DHCP" @@ -2958,7 +3152,7 @@ add_common_rules() { run_iptables -A OUTPUT -o $interface -p udp --dport 67:68 -j ACCEPT done - ########################################################################### + # # RFC 1918 # norfc1918_interfaces="`find_interfaces_by_option norfc1918`" @@ -2975,7 +3169,7 @@ add_common_rules() { run_iptables -A logdrop -j DROP if [ -n "$MANGLE_ENABLED" ]; then - #################################################################### + # # Mangling is enabled -- create a chain in the mangle table to # filter RFC1918 destination addresses. This must be done in the # mangle table before we apply any DNAT rules in the nat table @@ -2998,7 +3192,7 @@ add_common_rules() { esac run_iptables -A rfc1918 -s $subnet -j $target - #################################################################### + # # If packet mangling is enabled, trap packets with an # RFC1918 destination # @@ -3017,21 +3211,22 @@ add_common_rules() { done fi - ############################################################################ + # # Process Black List # setup_blacklist - ############################################################################ + # # Enable the Loopback interface # run_iptables -A INPUT -i lo -j ACCEPT run_iptables -A OUTPUT -o lo -j ACCEPT - ############################################################################ + + # # Enable icmp output # run_iptables -A OUTPUT -m state --state ! INVALID -p icmp -j ACCEPT - ############################################################################ + # # Route Filtering # for f in /proc/sys/net/ipv4/conf/*/rp_filter; do @@ -3059,7 +3254,7 @@ add_common_rules() { done fi fi - ############################################################################ + # # IP Forwarding # case "$IP_FORWARDING" in @@ -3074,12 +3269,12 @@ add_common_rules() { esac } -################################################################################ -# Scan the policy file defining the necessary chains # -# Add the appropriate policy rule(s) to the end of each canonical chain # -################################################################################ +# +# Scan the policy file defining the necessary chains +# Add the appropriate policy rule(s) to the end of each canonical chain +# apply_policy_rules() { - ############################################################################ + # # Create policy chains # while read client server policy loglevel synparams; do @@ -3113,7 +3308,7 @@ apply_policy_rules() { fi done < $TMP_DIR/policy - ############################################################################ + # # Add policy rules to canonical chains # for zone in $FW $zones; do @@ -3128,14 +3323,14 @@ apply_policy_rules() { done } -################################################################################ -# Activate the rules # -################################################################################ +# +# Activate the rules +# activate_rules() { local PREROUTING_rule=1 local POSTROUTING_rule=1 - ############################################################################ + # # Jump to a NAT chain from one of the builtin nat chains # addnatjump() # $1 = BUILTIN chain, $2 = user chain, $3 - * other arguments @@ -3148,9 +3343,9 @@ activate_rules() run_iptables -t nat -A $sourcechain $@ -j $destchain } - ############################################################################ + # # Jump to a RULES chain from one of the builtin nat chains - #--------------------------------------------------------------------------- + # # If NAT_BEFORE_RULES then append the rule to the chain; otherwise, insert # the jump near the front of the builtin chain # @@ -3184,23 +3379,34 @@ activate_rules() multi_interfaces=`find_interfaces_by_option multi` + > ${STATEDIR}/chains + > ${STATEDIR}/zones + for zone in $zones; do eval source_hosts=\$${zone}_hosts + echo $zone $source_hosts >> ${STATEDIR}/zones + + chain1=`rules_chain $FW $zone` + chain2=`rules_chain $zone $FW` + + echo "$FW $zone $chain1" >> ${STATEDIR}/chains + echo "$zone $FW $chain2" >> ${STATEDIR}/chains + for host in $source_hosts; do interface=${host%:*} subnet=${host#*:} - run_iptables -A OUTPUT -o \ - $interface -d $subnet -j `rules_chain $FW $zone` + run_iptables -A OUTPUT -o $interface -d $subnet -j $chain1 + # # Add jumps from the builtin chains for DNAT and SNAT rules # addrulejump PREROUTING `dnat_chain $zone` -i $interface -s $subnet addrulejump POSTROUTING `snat_chain $zone` -o $interface -d $subnet - run_iptables -A `input_chain $interface` -s $subnet \ - -j `rules_chain $zone $FW` + run_iptables -A `input_chain $interface` -s $subnet -j $chain2 + done for zone1 in $zones; do @@ -3208,6 +3414,8 @@ activate_rules() chain="`rules_chain $zone $zone1`" + echo "$zone $zone1 $chain" >> ${STATEDIR}/chains + if havechain ${zone}2${zone1} || havechain ${zone1}2${zone}; then have_canonical=Yes else @@ -3255,17 +3463,18 @@ activate_rules() complete_standard_chain OUTPUT $FW all complete_standard_chain FORWARD all all - run_iptables -D INPUT 1 - run_iptables -D OUTPUT 1 - run_iptables -D FORWARD 1 + run_iptables -D INPUT -m state --state ESTABLISHED -j ACCEPT + run_iptables -D OUTPUT -m state --state ESTABLISHED -j ACCEPT + run_iptables -D FORWARD -m state --state ESTABLISHED -j ACCEPT + run_iptables -D INPUT -p udp --dport 53 -j ACCEPT run_iptables -D OUTPUT -p udp --dport 53 -j ACCEPT run_iptables -D FORWARD -p udp --dport 53 -j ACCEPT } -################################################################################ -# Start/Restart the Firewall # -################################################################################ +# +# Start/Restart the Firewall +# define_firewall() # $1 = Command (Start or Restart) { if [ -f /etc/shorewall/startup_disabled ]; then @@ -3303,6 +3512,12 @@ define_firewall() # $1 = Command (Start or Restart) [ -f $tunnels ] && \ echo "Processing $tunnels..." && setup_tunnels $tunnels + maclist_hosts=`find_hosts_by_option maclist` + + if [ -n "$maclist_hosts" ] ; then + setup_mac_lists + fi + rules=`find_file rules` echo "Processing $rules..." @@ -3362,9 +3577,9 @@ define_firewall() # $1 = Command (Start or Restart) rm -rf $TMP_DIR } -################################################################################ -# Check the configuration # -################################################################################ +# +# Check the configuration +# check_config() { echo "Verifying Configuration..." @@ -3406,9 +3621,9 @@ check_config() { echo "Configuration Validated" } -################################################################################ -# Rebuild the common chain # -################################################################################ +# +# Rebuild the common chain +# refresh_firewall() { echo "Refreshing Shorewall..." @@ -3429,7 +3644,7 @@ refresh_firewall() build_common_chain - ########################################################################### + # # Blacklist # refresh_blacklist @@ -3439,9 +3654,343 @@ refresh_firewall() rm -rf $TMP_DIR } -################################################################################ -# Determine the value for a parameter that defaults to Yes # -################################################################################ +# +# Query NetFilter about the existence of a filter chain +# +chain_exists() # $1 = chain name +{ + qt iptables -L $1 -n +} + +# +# Add a host or subnet to a zone +# +add_to_zone() # $1 = [:] $2 = zone +{ + local base + + nat_chain_exists() # $1 = chain name + { + qt iptables -t nat -L $1 -n + } + + do_iptables() # $@ = command + { + if ! iptables $@ ; then + startup_error "Error: can't add $1 to zone $2" + fi + } + + output_rule_num() { + local num=`iptables -L OUTPUT -n --line-numbers | grep icmp | cut -d' ' -f1 | head -n1` + + [ -n "$num" ] && echo $(($num+1)) + } + # + # Isolate interface and host parts + # + interface=${1%:*} + host=${1#*:} + + [ -z "$host" ] && host="0.0.0.0/0" + # + # Load $zones + # + determine_zones + # + # Validate Zone + # + zone=$2 + + validate_zone $zone || startup_error "Error: Unknown zone: $zone" + + [ "$zone" = $FW ] && startup_error "Error: Can't add $1 to firewall zone" + # + # Be sure that Shorewall has been restarted using a DZ-aware version of the code + # + [ -f ${STATEDIR}/chains ] || startup_error "Error: ${STATEDIR}/chains -- file not found" + [ -f ${STATEDIR}/zones ] || startup_error "Error: ${STATEDIR}/zones -- file not found" + # + # Be sure that the interface was present at last [re]start + # + if ! chain_exists `input_chain $interface` ; then + startup_error "Error: Unknown interface $interface" + fi + # + # Build lists of interfaces with special rules + # + dhcp_interfaces=`find_interfaces_by_option dhcp` + blacklist_interfaces=`find_interfaces_by_option blacklist` + filterping_interfaces=`find_interfaces_by_option filterping` + maclist_interfaces=`find_interfaces_by_maclist` + # + # Normalize the first argument to this function + # + newhost="$interface:$host" + # + # Create a new Zone state file + # + > ${STATEDIR}/zones_$$ + # + # Add $1 to the Zone state file + # + while read z hosts; do + if [ "$z" = "$zone" ]; then + for h in $hosts; do + if [ "$h" = "$newhost" ]; then + rm -f ${STATEDIR}/zones_$$ + startup_error "Error: $1 already in zone $zone" + fi + done + + [ -z "$hosts" ] && hosts=$newhost || hosts="$hosts $newhost" + fi + + eval ${z}_hosts=\"$hosts\" + + echo "$z $hosts" >> ${STATEDIR}/zones_$$ + done < ${STATEDIR}/zones + + mv -f ${STATEDIR}/zones_$$ ${STATEDIR}/zones + # + # If the zone passed in the command has a dnat chain then insert a rule in + # the nat table PREROUTING chain to jump to that chain when the source + # matches the new host(s) + # + chain=${zone}_dnat + + if nat_chain_exists $chain; then + do_iptables -t nat -I PREROUTING -i $interface -s $host -j $chain + fi + # + # Insert new rules into the input chains for the passed interface + # + while read z1 z2 chain; do + if [ "$z1" = "$zone" ]; then + if [ "$z2" = "$FW" ]; then + # + # We will insert the rule right after the DHCP, 'ping' and + # MAC rules (if any) + # + if list_search $interface $dhcp_interfaces; then + rulenum=3 + else + rulenum=2 + fi + + if ! list_search $interface $filterping_interfaces; then + rulenum=$(($rulenum + 1)) + fi + + if ! list_search $interface $maclist_interfaces; then + rulenum=$(($rulenum + 1)) + fi + + do_iptables -I `input_chain $interface` $rulenum -s $host -j $chain + else + # + # Insert rules into the passed interface's forward chain + # + # We insert them after any blacklist/MAC verification rules + # + source_chain=`forward_chain $interface` + eval dest_hosts=\"\$${z2}_hosts\" + + base=`chain_base $interface` + + eval rulenum=\$${base}_rulenum + + if [ -z "$rulenum" ]; then + if list_search $interface $blacklist_interfaces; then + rulenum=3 + else + rulenum=2 + fi + + if ! list_search $interface $maclist_interfaces; then + rulenum=$(($rulenum + 1)) + fi + fi + + for h in $dest_hosts; do + iface=${h%:*} + hosts=${h#*:} + + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then + do_iptables -I $source_chain $rulenum -s $host -o $iface -d $hosts -j $chain + rulenum=$(($rulenum + 1)) + fi + done + + eval ${base}_rulenum=$rulenum + + fi + elif [ "$z2" = "$zone" ]; then + if [ "$z1" = "$FW" ]; then + # + # Add a rule to the OUTPUT chain -- always after the icmp * ACCEPT rule + # + do_iptables -I OUTPUT `output_rule_num` -o $interface -d $host -j $chain + else + # + # Insert rules into the source interface's forward chain + # + # We insert them after any blacklist rules + # + eval source_hosts=\"\$${z1}_hosts\" + + for h in $source_hosts; do + iface=${h%:*} + hosts=${h#*:} + + base=`chain_base $iface` + + eval rulenum=\$${base}_rulenum + + if [ -z "$rulenum" ]; then + if list_search $iface $blacklist_interfaces; then + rulenum=3 + else + rulenum=2 + fi + fi + + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then + do_iptables -I `forward_chain $iface` $rulenum -s $hosts -o $interface -d $host -j $chain + rulenum=$(($rulenum + 1)) + fi + + eval ${base}_rulenum=$rulenum + done + fi + fi + done < ${STATEDIR}/chains + + echo "$1 added to zone $2" +} + +# +# Delete a host or subnet from a zone +# +delete_from_zone() # $1 = [:] $2 = zone +{ + # + # Delete the subnect host(s) from the zone state file + # + delete_from_zones_file() + { + > ${STATEDIR}/zones_$$ + + while read z hosts; do + if [ "$z" = "$zone" ]; then + temp=$hosts + hosts= + + for h in $temp; do + if [ "$h" = "$delhost" ]; then + echo Yes + else + hosts="$hosts $h" + fi + done + fi + + echo "$z $hosts" >> ${STATEDIR}/zones_$$ + done < ${STATEDIR}/zones + + mv -f ${STATEDIR}/zones_$$ ${STATEDIR}/zones + } + # + # Isolate interface and host parts + # + interface=${1%:*} + host=${1#*:} + + [ -z "$host" ] && host="0.0.0.0/0" + # + # Load $zones + # + determine_zones + + zone=$2 + + validate_zone $zone || startup_error "Error: Unknown zone: $zone" + + [ "$zone" = $FW ] && startup_error "Error: Can't remove $1 from firewall zone" + # + # Be sure that Shorewall has been restarted using a DZ-aware version of the code + # + [ -f ${STATEDIR}/chains ] || startup_error "Error: ${STATEDIR}/chains -- file not found" + [ -f ${STATEDIR}/zones ] || startup_error "Error: ${STATEDIR}/zones -- file not found" + # + # Be sure that the interface was present at last [re]start + # + if ! chain_exists `input_chain $interface` ; then + startup_error "Error: Unknown interface $interface" + fi + # + # Normalize the first argument to this function + # + delhost="$interface:$host" + # + # Delete the passed hosts from the zone state file + # + [ -z "`delete_from_zones_file`" ] && \ + error_message "Warning: $1 does not appear to be in zone $2" + # + # Construct the zone host maps + # + while read z hosts; do + eval ${z}_hosts=\"$hosts\" + done < ${STATEDIR}/zones + # + # Delete any nat table entries for the host(s) + # + qt iptables -t nat -D PREROUTING -i $interface -s $host -j ${zone}_dnat + # + # Delete rules rules the input chains for the passed interface + # + while read z1 z2 chain; do + if [ "$z1" = "$zone" ]; then + if [ "$z2" = "$FW" ]; then + qt iptables -D `input_chain $interface` -i $interface -s $host -j $chain + else + source_chain=`forward_chain $interface` + eval dest_hosts=\"\$${z2}_hosts\" + + for h in $dest_hosts $delhost; do + iface=${h%:*} + hosts=${h#*:} + + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then + qt iptables -D $source_chain -s $host -o $iface -d $hosts -j $chain + fi + done + fi + elif [ "$z2" = "$zone" ]; then + if [ "$z1" = "$FW" ]; then + qt iptables -D OUTPUT -o $interface -d $host -j $chain + else + eval source_hosts=\"\$${z1}_hosts\" + + for h in $source_hosts; do + iface=${h%:*} + hosts=${h#*:} + + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then + qt iptables -D `forward_chain $iface` -s $hosts -o $interface -d $host -j $chain + fi + done + fi + fi + done < ${STATEDIR}/chains + + echo "$1 removed from zone $2" +} + +# +# Determine the value for a parameter that defaults to Yes +# added_param_value_yes() # $1 = Parameter Name, $2 = Parameter value { local val="$2" @@ -3462,9 +4011,9 @@ added_param_value_yes() # $1 = Parameter Name, $2 = Parameter value fi } -################################################################################ -# Determine the value for a parameter that defaults to No # -################################################################################ +# +# Determine the value for a parameter that defaults to No +# added_param_value_no() # $1 = Parameter Name, $2 = Parameter value { local val="$2" @@ -3485,9 +4034,9 @@ added_param_value_no() # $1 = Parameter Name, $2 = Parameter value fi } -################################################################################ -# Initialize this program # -################################################################################ +# +# Initialize this program +# do_initialize() { # Run all utility programs using the C locale # @@ -3496,7 +4045,7 @@ do_initialize() { export LC_ALL=C PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin - ############################################################################ + # # Clear all configuration variables # version= @@ -3525,6 +4074,8 @@ do_initialize() { NEWNOTSYN= LOGNEWNOTSYN= FORWARDPING= + MACLIST_DISPOSITION= + MACLIST_LOG_LEVEL= stopping= have_mutex= masq_seq=1 @@ -3604,19 +4155,37 @@ do_initialize() { MERGE_HOSTS=`added_param_value_no MERGE_HOSTS $MERGE_HOSTS` FORWARDPING=`added_param_value_no FORWARDPING $FORWARDPING` NEWNOTSYN=`added_param_value_yes NEWNOTSYN $NEWNOTSYN` + + maclist_target=reject + + if [ -n "$MACLIST_DISPOSITION" ] ; then + case $MACLIST_DISPOSITION in + REJECT) + ;; + ACCEPT|DROP) + maclist_target=$MACLIST_DISPOSITION + ;; + *) + startup_error "Invalid value ($MACLIST_DISPOSITION) for MACLIST_DISPOSITION" + ;; + esac + else + MACLIST_DISPOSITION=REJECT + fi + } -################################################################################ -# Give Usage Information # -################################################################################ +# +# Give Usage Information +# usage() { - echo "Usage: $0 [debug] {start|stop|reset|restart|status|refresh|clear]}" + echo "Usage: $0 [debug] {start|stop|reset|restart|status|refresh|clear|{add|delete} [:hosts] zone}}" exit 1 } -################################################################################ -# E X E C U T I O N B E G I N S H E R E # -################################################################################ +# +# E X E C U T I O N B E G I N S H E R E +# # # Start trace if first arg is "debug" # @@ -3626,14 +4195,13 @@ nolock= [ $# -gt 1 ] && [ "$1" = "nolock" ] && { nolock=Yes; shift ; } -[ $# -ne 1 ] && usage - trap "my_mutex_off; exit 2" 1 2 3 4 5 6 9 command="$1" case "$command" in stop) + [ $# -ne 1 ] && usage do_initialize my_mutex_on echo -n "Stopping Shorewall..." @@ -3645,6 +4213,7 @@ case "$command" in ;; start) + [ $# -ne 1 ] && usage do_initialize my_mutex_on if qt iptables -L shorewall -n ; then @@ -3659,6 +4228,7 @@ case "$command" in ;; restart) + [ $# -ne 1 ] && usage do_initialize my_mutex_on if qt iptables -L shorewall -n ; then @@ -3673,17 +4243,31 @@ case "$command" in ;; status) + [ $# -ne 1 ] && usage echo -e "Shorewall-$version Status at $HOSTNAME - `date`\\n" iptables -L -n -v ;; reset) - iptables -L -n -Z -v + [ $# -ne 1 ] && usage + do_initialize + my_mutex_on + if ! qt iptables -L shorewall -n ; then + echo "Shorewall Not Started" + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR + my_mutex_off + exit 2; + fi + iptables -Z + iptables -t nat -Z + iptables -t mangle -Z report "Shorewall Counters Reset" date > $STATEDIR/restarted + my_mutex_off ;; refresh) + [ $# -ne 1 ] && usage do_initialize my_mutex_on if ! qt iptables -L shorewall -n ; then @@ -3697,6 +4281,7 @@ case "$command" in ;; clear) + [ $# -ne 1 ] && usage do_initialize my_mutex_on echo -n "Clearing Shorewall..." @@ -3708,9 +4293,38 @@ case "$command" in ;; check) + [ $# -ne 1 ] && usage do_initialize check_config ;; + + add) + [ $# -ne 3 ] && usage + do_initialize + my_mutex_on + if ! qt iptables -L shorewall -n ; then + echo "Shorewall Not Started" + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR + my_mutex_off + exit 2; + fi + add_to_zone $2 $3 + my_mutex_off + ;; + + delete) + [ $# -ne 3 ] && usage + do_initialize + my_mutex_on + if ! qt iptables -L shorewall -n ; then + echo "Shorewall Not Started" + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR + my_mutex_off + exit 2; + fi + delete_from_zone $2 $3 + my_mutex_off + ;; *) usage diff --git a/STABLE/functions b/STABLE/functions index e8d0c797d..340c0d9b2 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -80,17 +80,17 @@ determine_zones() } -############################################################################### +# # The following functions may be used by apps that wish to ensure that # the state of Shorewall isn't changing -#------------------------------------------------------------------------------ +# # This function loads the STATEDIR variable (directory where Shorewall is to # store state files). If your application supports alternate Shorewall # configurations then the name of the alternate configuration directory should # be in $SHOREWALL_DIR at the time of the call. # # If the shorewall.conf file does not exist, this function does not return -############################################################################### +# get_statedir() { MUTEX_TIMEOUT= @@ -107,7 +107,7 @@ get_statedir() [ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall } -############################################################################### +# # Call this function to assert MUTEX with Shorewall. If you invoke the # /sbin/shorewall program while holding MUTEX, you should pass "nolock" as # the first argument. Example "shorewall nolock refresh" @@ -115,7 +115,7 @@ get_statedir() # This function uses the lockfile utility from procmail if it exists. # Otherwise, it uses a somewhat race-prone algorithm to attempt to simulate the # behavior of lockfile. -############################################################################### +# mutex_on() { local try=0 @@ -145,18 +145,18 @@ mutex_on() fi } -############################################################################### +# # Call this function to release MUTEX -############################################################################### +# mutex_off() { rm -f $STATEDIR/lock } -############################################################################### -# Strip comments and blank lines from a file and place the result in the # -# temporary directory # -############################################################################### +# +# Strip comments and blank lines from a file and place the result in the +# temporary directory +# strip_file() # $1 = Base Name of the file, $2 = Full Name of File (optional) { local fname diff --git a/STABLE/hosts b/STABLE/hosts index 6158a3571..9ce4bc3ab 100644 --- a/STABLE/hosts +++ b/STABLE/hosts @@ -35,6 +35,12 @@ # route messages to and from this # member when the firewall is in the # stopped state +# maclist - Connection requests from these hosts +# are compared against the contents of +# /etc/shorewall/maclist. If this option +# is specified, the interface must be +# an ethernet NIC and must be up before +# Shorewall is started. # # #ZONE HOST(S) OPTIONS diff --git a/STABLE/init.sh b/STABLE/init.sh new file mode 100644 index 000000000..f775dfc32 --- /dev/null +++ b/STABLE/init.sh @@ -0,0 +1,75 @@ +#!/bin/sh +RCDLINKS="2,S41 3,S41 6,K41" +# +# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.3 6/14/2002 +# +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# +# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# +# On most distributions, this file should be called: +# /etc/rc.d/init.d/shorewall or /etc/init.d/shorewall +# +# Complete documentation is available at http://shorewall.net +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of Version 2 of the GNU General Public License +# as published by the Free Software Foundation. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA +# +# If an error occurs while starting or restarting the firewall, the +# firewall is automatically stopped. +# +# Commands are: +# +# shorewall start Starts the firewall +# shorewall restart Restarts the firewall +# shorewall stop Stops the firewall +# shorewall status Displays firewall status +# +#### BEGIN INIT INFO +# Provides: shorewall +# Required-Start: $network +# Required-Stop: +# Default-Start: 2 3 5 +# Default-Stop: 0 1 6 +# Description: starts and stops the shorewall firewall +### END INIT INFO + +# chkconfig: 2345 25 90 +# description: Packet filtering firewall +# + +################################################################################ +# Give Usage Information # +################################################################################ +usage() { + echo "Usage: $0 start|stop|restart|status" + exit 1 +} + +################################################################################ +# E X E C U T I O N B E G I N S H E R E # +################################################################################ +command="$1" + +case "$command" in + + stop|start|restart|status) + + exec /sbin/shorewall $@ + ;; + *) + + usage + ;; + +esac diff --git a/STABLE/install.sh b/STABLE/install.sh index ebb36befc..b14387446 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.9b +VERSION=1.3.10 usage() # $1 = exit status { @@ -237,7 +237,7 @@ if [ -n "$RUNLEVELS" ]; then echo "/# chkconfig/ { print \"# chkconfig: $RUNLEVELS\" ; next }" > awk.temp echo "{ print }" >> awk.temp - awk -f awk.temp firewall > firewall.temp + awk -f awk.temp init.sh > init.temp if [ $? -ne 0 ]; then echo -e "\nERROR: Error running awk." @@ -246,11 +246,11 @@ if [ -n "$RUNLEVELS" ]; then exit 1 fi - install_file_with_backup firewall.temp ${PREFIX}${DEST}/$FIREWALL 0544 + install_file_with_backup init.temp ${PREFIX}${DEST}/$FIREWALL 0544 - rm -f firewall.temp awk.tmp + rm -f init.temp awk.tmp else - install_file_with_backup firewall ${PREFIX}${DEST}/$FIREWALL 0544 + install_file_with_backup init.sh ${PREFIX}${DEST}/$FIREWALL 0544 fi echo -e "\nShorewall script installed in ${PREFIX}${DEST}/$FIREWALL" @@ -382,6 +382,15 @@ else echo -e "\nStopped Routing file installed as ${PREFIX}/etc/shorewall/routestopped" fi # +# Install the Mac List file +# +if [ -f ${PREFIX}/etc/shorewall/maclist ]; then + backup_file /etc/shorewall/maclist +else + run_install -o $OWNER -g $GROUP -m 0600 maclist ${PREFIX}/etc/shorewall/maclist + echo -e "\nMAC list file installed as ${PREFIX}/etc/shorewall/maclist" +fi +# # Install the Masq file # if [ -f ${PREFIX}/etc/shorewall/masq ]; then @@ -476,13 +485,15 @@ chmod 644 ${PREFIX}/usr/lib/shorewall/version if [ -z "$PREFIX" ]; then rm -f /etc/shorewall/firewall rm -f /var/lib/shorewall/firewall - rm -f /usr/lib/shorewall/firewall - ln -s ${DEST}/${FIREWALL} /usr/lib/shorewall/firewall -else - pushd ${PREFIX}/usr/lib/shorewall/ >> /dev/null && ln -s ../../..${DEST}/${FIREWALL} firewall && popd >> /dev/null + [ -L /usr/lib/shorewall/firewall ] && \ + mv -f /usr/lib/shorewall/firewall /usr/lib/shorewall/firewall-${VERSION}.bkout + rm -f /usr/lib/shorewall/init + ln -s ${DEST}/${FIREWALL} /usr/lib/shorewall/init fi - -echo -e "\n${PREFIX}/usr/lib/shorewall/firewall linked to ${PREFIX}$DEST/$FIREWALL" +# +# Install the firewall script +# +install_file_with_backup firewall ${PREFIX}/usr/lib/shorewall/firewall 0544 if [ -z "$PREFIX" -a -n "$first_install" ]; then if [ -x /sbin/insserv -o -x /usr/sbin/insserv ]; then diff --git a/STABLE/interfaces b/STABLE/interfaces index eb20f46cd..8be1de806 100644 --- a/STABLE/interfaces +++ b/STABLE/interfaces @@ -16,7 +16,9 @@ # place "-" in this column. # # INTERFACE Name of interface. Each interface may be listed only -# once in this file. +# once in this file. You may NOT specify the name of +# an alias (e.g., eth0:0) here; see +# http://www.shorewall.net/FAQ.htm#faq18 # # BROADCAST The broadcast address for the subnetwork to which the # interface belongs. For P-T-P interfaces, this @@ -81,6 +83,12 @@ # . . blacklist - Check packets arriving on this interface # against the /etc/shorewall/blacklist # file. +# maclist - Connection requests from this interface +# are compared against the contents of +# /etc/shorewall/maclist. If this option +# is specified, the interface must be +# an ethernet NIC and must be up before +# Shorewall is started. # proxyarp - # Sets # /proc/sys/net/ipv4/conf//proxy_arp. diff --git a/STABLE/maclist b/STABLE/maclist new file mode 100644 index 000000000..37c61a38f --- /dev/null +++ b/STABLE/maclist @@ -0,0 +1,18 @@ +# +# Shorewall 1.3 - MAC list file +# +# /etc/shorewall/maclist +# +# Columns are: +# +# INTERFACE Network interface to a host +# +# MAC MAC address of the host -- you do not need to use +# the Shorewall format for MAC addresses here +# +# IP ADDRESSES Optional -- if specified, both the MAC and IP address +# must match. This column can contain a comma-separated +# list of host and/or subnet addresses. +############################################################################## +#INTERFACE MAC IP ADDRESSES (Optional) +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index d398a9346..ca1daccde 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -1,16 +1,27 @@ -This is a minor release of Shorewall which rolls up a number of bug -fixes. +This is a minor release of Shorewall that has a number of new features.. New features include: -1. DNS Names are now allowed in Shorewall config files. +1) You may now define the contents of a zone dynamically with the + "shorewall add" and "shorewall delete" commands. These commands + are expected to be used primarily within FreeS/Wan updown scripts. + +2) Shorewall can now do MAC verification on ethernet segments. You can + specify the set of allowed MAC addresses on the segment and you can + optionally tie each MAC address to an IP address. + +3) PPTP Servers and Clients running on the firewall system may now be + defined in the /etc/shorewall/tunnels file. -2. The connection SOURCE may now be qualified by both interface - and IP address in a Shorewall rule. - -3. Shorewall startup is now disabled after initial installation until - the file /etc/shorewall/startup_disabled is removed. - -4. The 'functions' and 'version' files and the 'firewall' symbolic link - have been moved from /var/lib/shorewall to /usr/lib/shorewall to - appease the LFS police at Debian. +4) A new 'ipsecnat' tunnel type is supported for use when the remote + IPSEC endpoint is behind a NAT gateway. + +5) The PATH used by Shorewall may now be specified in + /etc/shorewall/shorewall.conf. + +6) The main firewall script is now /usr/lib/shorewall/firewall. The + script in /etc/init.d/shorewall is very small and uses + /sbin/shorewall to do the real work. This change makes custom + distributions such as for Debian and for Gentoo easier to manage + since it is /etc/init.d/shorewall that tends to have + distribution-dependent code. diff --git a/STABLE/shorewall b/STABLE/shorewall index aa39becab..67741839f 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -32,6 +32,8 @@ # # Commands are: # +# shorewall add [:] zone Adds a host or subnet to a zone +# shorewall delete [:] zone Deletes a host or subnet from a zone # shorewall start Starts the firewall # shorewall restart Restarts the firewall # shorewall stop Stops the firewall @@ -108,11 +110,10 @@ showchain() # $1 = name of chain fi } -################################################################################# -# Set the configuration variables from shorewall.conf # -################################################################################# +# +# Set the configuration variables from shorewall.conf +# get_config() { - get_statedir [ -z "$LOGFILE" ] && LOGFILE=/var/log/messages @@ -133,10 +134,10 @@ get_config() { [ -n "$FW" ] || FW=fw } -################################################################################# -# Display IPTABLES rules -- we used to store them in a variable but ash # -# dies when trying to display large sets of rules # -################################################################################# +# +# Display IPTABLES rules -- we used to store them in a variable but ash +# dies when trying to display large sets of rules +# display_chains() { trap "rm -f /tmp/chains-$$; exit 1" 1 2 3 4 5 6 9 @@ -226,10 +227,10 @@ display_chains() } -################################################################################# -# Delay $timeout seconds -- if we're running on a recent bash2 then allow # -# to terminate the delay # -################################################################################# +# +# Delay $timeout seconds -- if we're running on a recent bash2 then allow +# to terminate the delay +# timed_read () { read -t $timeout foo 2> /dev/null @@ -237,9 +238,9 @@ timed_read () test $? -eq 2 && sleep $timeout } -################################################################################# -# Display the last $1 packets logged # -################################################################################# +# +# Display the last $1 packets logged +# packet_log() # $1 = number of messages { local options @@ -253,9 +254,9 @@ packet_log() # $1 = number of messages tail $options } -################################################################################# -# Show traffic control information # -################################################################################# +# +# Show traffic control information +# show_tc() { show_one_tc() { @@ -283,9 +284,9 @@ show_tc() { } -################################################################################# -# Monitor the Firewall # -################################################################################# +# +# Monitor the Firewall +# monitor_firewall() # $1 = timeout -- if negative, prompt each time that # an 'interesting' packet count changes { @@ -359,9 +360,9 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that done } -################################################################################# -# Watch the Firewall Log # -################################################################################# +# +# Watch the Firewall Log +# logwatch() # $1 = timeout -- if negative, prompt each time that # an 'interesting' packet count changes { @@ -409,13 +410,15 @@ logwatch() # $1 = timeout -- if negative, prompt each time that done } -################################################################################# -# Give Usage Information # -################################################################################# +# +# Give Usage Information +# usage() # $1 = exit status { echo "Usage: `basename $0` [debug] [nolock] [-c ] " echo "where is one of:" + echo " add [:] " + echo " delete [:] " echo " show [|connections|log|nat|tc|tos]" echo " start" echo " stop" @@ -437,17 +440,17 @@ usage() # $1 = exit status exit $1 } -################################################################################# -# Display the time that the counters were last reset # -################################################################################# +# +# Display the time that the counters were last reset +# show_reset() { [ -f $STATEDIR/restarted ] && \ echo -e "Counters reset `cat $STATEDIR/restarted`\\n" } -################################################################################# -# Execution begins here # -################################################################################# +# +# Execution begins here +# debugging= if [ $# -gt 0 ] && [ "$1" = "debug" ]; then @@ -532,11 +535,17 @@ fi banner="Shorewall-$version Status at $HOSTNAME -" +get_statedir + case "$1" in start|stop|restart|reset|clear|refresh|check) [ $# -ne 1 ] && usage 1 exec $firewall $debugging $nolock $1 ;; + add|delete) + [ $# -ne 3 ] && usage 1 + exec $firewall $debugging $nolock $1 $2 $3 + ;; show) [ $# -gt 2 ] && usage 1 case "$2" in @@ -550,7 +559,6 @@ case "$1" in iptables -t nat -L -n -v ;; tos|mangle) - get_config echo -e "Shorewall-$version TOS at $HOSTNAME - `date`\\n" show_reset iptables -t mangle -L -n -v @@ -567,7 +575,6 @@ case "$1" in show_tc ;; *) - get_config echo -e "Shorewall-$version Chain $2 at $HOSTNAME - `date`\\n" show_reset iptables -L $2 -n -v @@ -710,6 +717,8 @@ case "$1" in [ $# -ne 1 ] && usage 1 mutex_on if qt iptables -L shorewall -n; then + [ -d /var/lib/shorewall ] || mkdir /var/lib/shorewall + if iptables -L dynamic -n > /var/lib/shorewall/save; then echo "Dynamic Rules Saved" else diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index 8bb4fb236..ba0fdb069 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -8,6 +8,12 @@ # # (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) ############################################################################## +# +# PATH - Change this if you want to change the order in which Shorewall +# searches directories for executable files. +# +PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin + # # NAME OF THE FIREWALL ZONE # @@ -154,7 +160,8 @@ ADD_IP_ALIASES=Yes # # If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses # for each SNAT external address that you give in /etc/shorewall/masq. If you say -# "No" or "no", you must add these aliases youself. +# "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" unless +# you are sure that you need it -- most people don't!!! # ADD_SNAT_ALIASES=No @@ -376,4 +383,25 @@ FORWARDPING=Yes NEWNOTSYN=No +# +# MAC List Disposition +# +# This variable determines the disposition of connection requests arriving +# on interfaces that have the 'maclist' option and that are from a device +# that is not listed for that interface in /etc/shorewall/maclist. Valid +# values are ACCEPT, DROP and REJECT. If not specified or specified as +# empty (MACLIST_DISPOSITION="") then REJECT is assumed + +MACLIST_DISPOSITION=REJECT + +# +# MAC List Log Level +# +# Specifies the logging level for connection requests that fail MAC +# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then +# such connection requests will not be logged. +# + +MACLIST_LOG_LEVEL=info + #LAST LINE -- DO NOT REMOVE diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index e5744bbf2..99f57ff1d 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.9b +%define version 1.3.10 %define release 1 %define prefix /usr @@ -85,6 +85,7 @@ fi %attr(0600,root,root) %config(noreplace) /etc/shorewall/params %attr(0600,root,root) %config(noreplace) /etc/shorewall/proxyarp %attr(0600,root,root) %config(noreplace) /etc/shorewall/routestopped +%attr(0600,root,root) %config(noreplace) /etc/shorewall/maclist %attr(0600,root,root) %config(noreplace) /etc/shorewall/masq %attr(0600,root,root) %config(noreplace) /etc/shorewall/modules %attr(0600,root,root) %config(noreplace) /etc/shorewall/tcrules @@ -95,11 +96,20 @@ fi %attr(0600,root,root) %config(noreplace) /etc/shorewall/rfc1918 %attr(0544,root,root) /sbin/shorewall %attr(0444,root,root) /usr/lib/shorewall/functions -/usr/lib/shorewall/firewall +%attr(0544,root,root) /usr/lib/shorewall/firewall %doc documentation %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Sat Nov 09 2002 Tom Eastep +- Changes version to 1.3.10 +* Wed Oct 23 2002 Tom Eastep +- Changes version to 1.3.10b1 +* Tue Oct 22 2002 Tom Eastep +- Added maclist file +* Tue Oct 15 2002 Tom Eastep +- Changed version to 1.3.10 +- Replaced symlink with real file * Wed Oct 09 2002 Tom Eastep - Changed version to 1.3.9b * Mon Sep 30 2002 Tom Eastep diff --git a/STABLE/tunnels b/STABLE/tunnels index 1e841e814..5e961d6fd 100644 --- a/STABLE/tunnels +++ b/STABLE/tunnels @@ -9,7 +9,8 @@ # # The columns are: # -# TYPE -- must start in column 1 and be "ipsec", "ip" or "gre" +# TYPE -- must start in column 1 and be "ipsec", "ipsecnat","ip" +# "gre","pptpclient" or "pptpserver" # # ZONE -- The zone of the physical interface through which # tunnel traffic passes. This is normally your internet @@ -19,10 +20,10 @@ # remote getway has no fixed address (Road Warrior) # then specify the gateway as 0.0.0.0/0. # -# GATEWAY ZONE-- Optional. If the gateway system specified in the third +# GATEWAY ZONES -- Optional. If the gateway system specified in the third # column is a standalone host then this column should -# contain the name of the zone that the host is in. This -# column only applies to IPSEC tunnels. +# contain a comma-separated list of the names of the zones that +# the host might be in. This column only applies to IPSEC tunnels. # # Example 1: # @@ -47,5 +48,28 @@ # # ipsec net 4.33.99.124 gw # -# TYPE ZONE GATEWAY GATEWAY ZONE +# Example 4: +# +# Road Warriors that may belong to zones vpn1, vpn2 or +# vpn3. The FreeS/Wan _updown script will add the +# host to the appropriate zone using the "shorewall add" +# command on connect and will remove the host from the +# zone at disconnect time. +# +# ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 +# +# Example 5: +# +# You run the Linux PPTP client on your firewall and +# connect to server 192.0.2.221. +# +# pptpclient net 192.0.2.221 +# +# Example 6: +# +# You run a PPTP server on your firewall. +# +# pptpserver net +# +# TYPE ZONE GATEWAY GATEWAY ZONE #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index 7bb0837a0..d77a4249a 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.3.9b +VERSION=1.3.10 usage() # $1 = exit status { @@ -61,7 +61,7 @@ remove_file() # $1 = file to restore } if [ -f /usr/lib/shorewall/version ]; then - INSTALLED_VERSION="`cat /var/lib/shorewall/version`" + INSTALLED_VERSION="`cat /usr/lib/shorewall/version`" if [ "$INSTALLED_VERSION" != "$VERSION" ]; then echo "WARNING: Shorewall Version $INSTALLED_VERSION is installed" echo " and this is the $VERSION uninstaller." @@ -82,6 +82,8 @@ if [ -L /usr/lib/shorewall/firewall ]; then FIREWALL=`ls -l /usr/lib/shorewall/firewall | sed 's/^.*> //'` elif [ -L /var/lib/shorewall/firewall ]; then FIREWALL=`ls -l /var/lib/shorewall/firewall | sed 's/^.*> //'` +elif [ -L /usr/lib/shorewall/init ]; then + FIREWALL=`ls -l /usr/lib/shorewall/init | sed 's/^.*> //'` else FIREWALL= fi @@ -94,6 +96,7 @@ if [ -n "$FIREWALL" ]; then fi remove_file $FIREWALL + rm -f ${FIREWALL}-*.bkout fi remove_file /sbin/shorewall diff --git a/STABLE/zones b/STABLE/zones index 6d5add70c..45f103b73 100644 --- a/STABLE/zones +++ b/STABLE/zones @@ -3,7 +3,7 @@ # # This file determines your network zones. Columns are: # -# ZONE Short name of the zone +# ZONE Short name of the zone # DISPLAY Display name of the zone # COMMENTS Comments about the zone #