diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 6330272b5..e7bd8925f 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,44 +1,17 @@ -Changes since 1.3.9 +Changes since 1.3.10 -1. Fix dumb bug in 1.3.9 Tunnel Handling. +1. Added TCP flags checking. -2. First implementaiton of dynamic zones. +2. Accomodate bash clones like dash and ash -3. Corrections to Dynamic Zones. +3. Added some comments in the policy chain creation/population logic. -4. More fixes for Dynamic Zones. +4. Check for fw->fw rules. -5. Correct a typo in an error message. +5. Allow 'all' in rules. -6. Fix rule insertion algorithms for Dynamic Zones. +6. Add reverse GRE rules for PPTP server and clients. -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. Add warning to tcrules file. +8. Add warning to policy file that fw->fw policies aren't allowed. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 5bc38e28f..82de396d7 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,333 +1,345 @@ - + - + - + 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:

- - + +

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. - -
  2. A subnet in CIDR notation - (example - eth2:192.168.2.0/24)
    3. - - -
- - -

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

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

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.
-
- maclist - Added in version 1.3.10. If specified, connection requests -from the hosts specified in this entry are subject to 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.
-

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

+ 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. - -
  2. DEST - The name of a destination - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
    3. - -
  3. POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION zone.
    4. - -
  4. 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.
    5. - -
  5. 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.
    6. - - -
- - -

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. + +
  2. DEST - The name of a +destination zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all"). +Shorewall automatically allows all traffic from the firewall to itself so +the name of the firewall zone cannot appear in both the +SOURCE and DEST columns.
    3. + +
  3. POLICY - The default +policy for connection requests from the SOURCE zone to the DESTINATION +zone.
    4. + +
  4. 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.
    5. + +
  5. 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.
    6. + + +
+ + +

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:

+ +
+ - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + +
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 @@ -1135,298 +1164,313 @@ rules as follows:

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

+

Shorewall automatically enables firewall->firewall traffic over the +loopback interface (lo) -- that traffic cannot be regulated using rules and +any rule that tries to regulate such traffic will generate a warning and +will be ignored.
+

- +

Entries in the file have the following columns:

- +
    -
  • ACTION +
  • ACTION
      -
    • ACCEPT, DROP or REJECT. These have the same meaning here as - in the policy file above.
      • -
    • DNAT -- Causes the connection request to be forwarded to the - system specified in the DEST column (port forwarding). "DNAT" stands - for "Destination Network Address Translation"
      • -
    • REDIRECT -- Causes the connection request to be redirected -to a port on the local (firewall) system.
      • - +
    • ACCEPT, DROP or REJECT. These have the same meaning here +as in the policy file above.
      • +
    • DNAT -- Causes the connection request to be forwarded to +the system specified in the DEST column (port forwarding). "DNAT" +stands for "Destination Network Address Translation"
      • +
    • REDIRECT -- Causes the connection request to be redirected + to a port on the local (firewall) system.
      • +
    - +

    The ACTION may optionally be followed by ":" and a syslogd log - level (example: REJECT:info). This causes the packet to be logged at - the specified level prior to being processed according to the specified - ACTION.
    -
    - The use of DNAT or REDIRECT requires that you have +
    + The use of DNAT or REDIRECT requires that you have     NAT enabled.
    -  

    -
    • -
  • SOURCE - Describes the source hosts to which the rule applies.. - The contents of this field must begin with the name of a zone defined - in /etc/shorewall/zones or $FW. If the ACTION is DNAT or REDIRECT, sub-zones - may be excluded from the rule by following the initial zone name with - "!' and a comma-separated list of those sub-zones to be excluded. There - is an example above.
    -
    - The source may be further restricted by adding a colon (":") followed - by a comma-separated list of qualifiers. Qualifiers are may include: - -
      -
    • An interface name - refers to any connection requests arriving - on the specified interface (example loc:eth4). Beginning with -Shorwall 1.3.9, the interface name may optionally be followed by a colon (":") -and an IP address or subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
      • -
    • An IP address - refers to a connection request from the host - with the specified address (example net:155.186.235.151). If the - ACTION is DNAT, this must not be a DNS name.
      • -
    • A MAC Address in Shorewall format.
      • -
    • A subnet - refers to a connection request from any host in -the specified subnet (example net:155.186.235.0/24).
      • - -
    +  

    • -
  • DEST - Describes the destination host(s) to which the -rule applies. May take any of the forms described above for SOURCE -plus the following two additional forms: +
  • SOURCE - Describes the source hosts to which the rule +applies.. The contents of this field must begin with the name of +a zone defined in /etc/shorewall/zones, $FW or "all". If the ACTION +is DNAT or REDIRECT, sub-zones may be excluded from the rule by following +the initial zone name with "!' and a comma-separated list of those +sub-zones to be excluded. There is an example above.
    +
    + If the source is not 'all' then the source may be further restricted +by adding a colon (":") followed by a comma-separated list of qualifiers. +Qualifiers are may include: +
      -
    • An IP address followed by a colon and the port number - that the server is listening on (service names from /etc/services - are not allowed - example loc:192.168.1.3:80). 
      • -
    • A single port number (again, service names are not allowed) - -- this form is only allowed if the ACTION is REDIRECT and refers -to a server running on the firewall itself and listening on the -specified port.
      • - +
    • An interface name - refers to any connection requests arriving + on the specified interface (example loc:eth4). Beginning with + Shorwall 1.3.9, the interface name may optionally be followed by a colon +(":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
      • +
    • An IP address - refers to a connection request from the +host with the specified address (example net:155.186.235.151). +If the ACTION is DNAT, this must not be a DNS name.
      • +
    • A MAC Address in Shorewall format.
      • +
    • A subnet - refers to a connection request from any host +in the specified subnet (example net:155.186.235.0/24).
      • +
    -
    • -
  • PROTO - Protocol. Must be a protocol name from /etc/protocols, - a number, "all" or "related". Specifies the protocol of the connection - request. "related" should be specified only if you have given ALLOWRELATED="no" - in /etc/shorewall/shorewall.conf and you wish to override that setting - for related connections originating with the client(s) and server(s) - specified in this rule. When "related" is given for the protocol, - the remainder of the columns should be left blank.
    • -
  • DEST PORT(S) - Port or port range (<low port>:<high - port>) being connected to. May only be specified if the protocol - is tcp, udp or icmp. For icmp, this column's contents are interpreted - as an icmp type. If you don't want to specify DEST PORT(S) but need - to include information in one of the columns to the right, enter -"-" in this column. You may give a list of ports and/or port ranges separated - by commas. Port numbers may be either integers or service names from -/etc/services.
    • -
  • SOURCE PORTS(S) - May be used to restrict -the rule to a particular client port or port range (a port range is -specified as <low port number>:<high port number>). If +
    • +
  • DEST - Describes the destination host(s) to which the + rule applies. May take any of the forms described above for SOURCE + plus the following two additional forms: + +
      +
    • An IP address followed by a colon and the port number + that the server is listening on (service names from /etc/services + are not allowed - example loc:192.168.1.3:80).
      +
      • +
    • A single port number (again, service names are not allowed) + -- this form is only allowed if the ACTION is REDIRECT and refers + to a server running on the firewall itself and listening on the + specified port.
      +
      • + +
    +
    • +
  • PROTO - Protocol. Must be a protocol name from /etc/protocols, + a number, "all" or "related". Specifies the protocol of the connection + request. "related" should be specified only if you have given ALLOWRELATED="no" + in /etc/shorewall/shorewall.conf and you wish to override that setting + for related connections originating with the client(s) and server(s) + specified in this rule. When "related" is given for the protocol, + the remainder of the columns should be left blank.
    • +
  • DEST PORT(S) - Port or port range (<low port>:<high + port>) being connected to. May only be specified if the protocol + is tcp, udp or icmp. For icmp, this column's contents are interpreted + as an icmp type. If you don't want to specify DEST PORT(S) but need + to include information in one of the columns to the right, enter + "-" in this column. You may give a list of ports and/or port ranges + separated by commas. Port numbers may be either integers or service names + from /etc/services.
    • +
  • SOURCE PORTS(S) - May be used to restrict + the rule to a particular client port or port range (a port range is + specified as <low port number>:<high port number>). If you don't want to restrict client ports but want to specify something in the next column, enter "-" in this column. If you wish to specify a list of port number or ranges, separate the list elements with commas -(with no embedded white space). Port numbers may be either integers + (with no embedded white space). Port numbers may be either integers or service names from /etc/services.
    • -
  • ORIGINAL DEST - This column may only be non-empty if -the ACTION is DNAT or REDIRECT.
    -
    - If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column is - left empty, any connection request arriving at the firewall from the - SOURCE that matches the rule will be forwarded or redirected. This -works fine for connection requests arriving from the internet where -the firewall has only a single external IP address. When the firewall -has multiple external IP addresses or when the SOURCE is other than -the internet, there will usually be a desire for the rule to only apply -to those connection requests directed to a particular IP address (see -Example 2 below for another usage). That IP address (or a comma-separated -list of such addresses) is specified in the ORIGINAL DEST column.
    -
    - The IP address may be optionally followed by ":" and a second - IP address. This latter address, if present, is used as the source -address for packets forwarded to the server (This is called "Source NAT" +
  • ORIGINAL DEST - This column may only be non-empty if + the ACTION is DNAT or REDIRECT.
    +
    + If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column +is left empty, any connection request arriving at the firewall from +the SOURCE that matches the rule will be forwarded or redirected. This + works fine for connection requests arriving from the internet where + the firewall has only a single external IP address. When the firewall + has multiple external IP addresses or when the SOURCE is other than + the internet, there will usually be a desire for the rule to only apply + to those connection requests directed to a particular IP address (see + Example 2 below for another usage). That IP address (or a comma-separated + list of such addresses) is specified in the ORIGINAL DEST column.
    +
    + The IP address may be optionally followed by ":" and a second + IP address. This latter address, if present, is used as the source + address for packets forwarded to the server (This is called "Source NAT" or SNAT).
    -
    - + Note:  When using SNAT, it is a good idea to qualify the source with an IP address or subnet. Otherwise, it is likely that SNAT will occur on connections other than those described in the rule. The reason for this is that SNAT occurs in the Netfilter POSTROUTING hook where it is not possible to restrict the scope of a rule by incoming interface.
    -
    -     Example: DNAT     loc:192.168.1.0/24    loc:192.168.1.3    - tcp    www    -    206.124.146.179:192.168.1.3
    -
    -     If SNAT is not used (no ":" and second IP address), the - original source address is used. If you want any destination address - to match the rule but want to specify SNAT, simply use a colon followed - by the SNAT address.
    • - +
    +     Example: DNAT     loc:192.168.1.0/24    loc:192.168.1.3    + tcp    www    -    206.124.146.179:192.168.1.3
    +
    +     If SNAT is not used (no ":" and second IP address), +the original source address is used. If you want any destination +address to match the rule but want to specify SNAT, simply use a colon +followed by the SNAT address. +
- +

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. 

+
+ - - - - - - - - - - - - - - - - - - - - - - - - - -
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 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
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 + 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 @@ -1447,80 +1491,82 @@ leave it blank in the 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
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 @@ -1528,51 +1574,97 @@ want - +

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

+ Example 6. You wish to +allow access to the SMTP server in your DMZ from all zones.
+
+ + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+PORTS(S)
+ 		SOURCE
+PORT(S)
+ 		ORIGINAL
+DEST
+
ACCEPT
+ 		all
+ 		dmz
+ 		tcp
+ 		25
+
+
+
+
+Note: When 'all' is used as a source or destination, intra-zone traffic is +not affected. In this example, if there were two DMZ interfaces then the +above rule would NOT enable SMTP traffic between hosts on these interfaces.
+

Look here for information on other services. +

- +

/etc/shorewall/common

- +

Shorewall allows definition of rules that apply between all zones. @@ -1582,160 +1674,163 @@ want + 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:

- +
    -
  • INTERFACE - The interface that will masquerade the -subnet; this is normally your internet interface. This interface name -can be optionally qualified by adding ":" and a subnet or host IP. -When this qualification is added, only packets addressed to that host -or subnet will be masqueraded.
    • -
  • SUBNET - The subnet that you want to have masqueraded - through the INTERFACE. This may be expressed as a single IP address, - a subnet or an interface name. In the latter instance, the interface -must be configured and started before Shorewall is started as Shorewall -will determine the subnet based on information obtained from the 'ip' -utility.
    -
    - The subnet may be optionally followed by "!' and a comma-separated - list of addresses and/or subnets that are to be excluded from masquerading.
    • -
  • ADDRESS - The source address to be used for outgoing - packets. This column is optional and if left blank, the current primary - IP address of the interface in the first column is used. If you have - a static IP on that interface, listing it here makes processing of output - packets a little less expensive for the firewall.
    • - +
  • INTERFACE - The interface that will masquerade the + subnet; this is normally your internet interface. This interface +name can be optionally qualified by adding ":" and a subnet or host +IP. When this qualification is added, only packets addressed to that +host or subnet will be masqueraded.
    • +
  • SUBNET - The subnet that you want to have masqueraded + through the INTERFACE. This may be expressed as a single IP address, + a subnet or an interface name. In the latter instance, the interface + must be configured and started before Shorewall is started as Shorewall + will determine the subnet based on information obtained from the 'ip' + utility.
    +
    + The subnet may be optionally followed by "!' and a comma-separated + list of addresses and/or subnets that are to be excluded from masquerading.
    • +
  • ADDRESS - The source address to be used for outgoing + packets. This column is optional and if left blank, the current primary + IP address of the interface in the first column is used. If you have + a static IP on that interface, listing it here makes processing of output + packets a little less expensive for the firewall.
    • +
- +

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 3: You have a DSL line connected on eth0 and a local - network (192.168.10.0/24) - connected to -eth1. You want -all local->net - connections to use - source address - 206.124.146.176.

- -
+

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
eth0192.168.10.0/24206.124.146.176
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 + 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
+
+ +

Example 4: Same as example 3 except that you wish @@ -1745,34 +1840,35 @@ 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, @@ -1781,30 +1877,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 - 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. -

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

- +

The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -1812,47 +1908,47 @@ the proxy_arp flag on a small set of systems since you need one entry - in this file - for each system - using proxy - ARP. Columns are:

- + in this file + for each system + using proxy + ARP. Columns are:

+
    -
  • ADDRESS - address of the system.
    • -
  • INTERFACE - the interface that connects to the system. - If the interface is obvious from the subnetting, you may enter "-" - in this column.
    • -
  • EXTERNAL - the external interface that you want to -honor ARP requests for the ADDRESS specified in the first column.
    • -
  • HAVEROUTE - If - you already have - a route through - INTERFACE to - ADDRESS, this - column should - contain - "Yes" - or - "yes". - If you want - Shorewall to add - the route, the - column should - contain - "No" - or - "no".
    • - +
  • ADDRESS - address of the system.
    • +
  • INTERFACE - the interface that connects to the system. + If the interface is obvious from the subnetting, you may enter "-" + in this column.
    • +
  • EXTERNAL - the external interface that you want +to honor ARP requests for the ADDRESS specified in the first column.
    • +
  • HAVEROUTE - If + you already have + a route through + INTERFACE to + ADDRESS, this + column should + contain + "Yes" + or + "yes". + If you want + Shorewall to add + the route, the + column should + contain + "No" + or + "no".
    • +
- +

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 @@ -1861,94 +1957,95 @@ 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 @@ -1960,9 +2057,9 @@ files.

static NAT. Port forwarding can be accomplished - with simple - entries in - the rules file. Also, in most @@ -1977,366 +2074,379 @@ 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. -

- + +

Look here for additional information and an example. +

+ +

/etc/shorewall/tunnels

- +

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, instructions for IPIP and -GRE tunnels are here  and instructions for -PPTP tunnels are here.

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

+

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

- +

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 @@ -2553,397 +2663,400 @@ 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 - of - according - to - the - value - assigned +disposed + of + according + to + the + value - to - the BLACKLIST_DISPOSITION + assigned + to + the BLACKLIST_DISPOSITION -and BLACKLIST_LOGLEVEL variables - in - /etc/shorewall/shorewall.conf. + and BLACKLIST_LOGLEVEL variables + in - Only - packets - arriving - on - interfaces + /etc/shorewall/shorewall.conf. + Only + packets - that - have - the - 'blacklist' + arriving + on + interfaces + that + have + the - option - in - /etc/shorewall/interfaces - are + 'blacklist' + option + in - checked - against - the - blacklist. The black list is -designed to prevent listed hosts/subnets from accessing services on your - network.
-

- + /etc/shorewall/interfaces + are + checked + against + + the + blacklist. The black list is designed to prevent listed +hosts/subnets from accessing services on your 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:

- + - +

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

+ 1.3.4) - +

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

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

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

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

Updated 10/28/2002 - Tom Eastep -

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

Updated 11/24/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 03ca89fce..6efbda7b5 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,856 +1,896 @@ - + - + - + - + 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.
-

- -

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

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

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?

- + +

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

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

- + +

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?
+
+ 19. I have added entries to /etc/shorewall/tcrules +but they don't seem to do anything. Why?
+
+20. I have just set up a server. +Do I have to change Shorewall to allow access to my server from the internet?
+ +
+

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

+

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format of a port-forwarding + 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:

- + - -

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

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

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.

- + +

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 (No longer required as of Shorewall version 1.3.9).

- -
+ +

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

+ +
+

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:

- +
+ +

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

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

-
+
+ +
+

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.

-

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

-

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 +

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

Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
+

+ +

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

+ +
+ + + + + - - + + + + + + - +
SUBNET
+ 		TARGET
+
192.168.100.1RETURN192.168.100.1
+ 		RETURN
+
192.168.100.2
+ 		RETURN
+
-
-
- -
-

Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-

- -

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

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

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

-
- -
-

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

-
- -

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

- -

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

+ +
+

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

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

    -
    3. -
  3. -

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

    -
    4. - -
- -

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

- -

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

+
  • +

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

    +
    • +
  • + +

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

    +
    • +
  • + +

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

    +
    • + + + +

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

    + +

    Answer: "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:
    - + 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 man1918 - The destination address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      2. -
    2. rfc1918 - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      3. -
    3. all2<zone>, <zone>2all or all2all - - You have a policy that specifies -a log level and this packet is being logged under that policy. If you intend - to ACCEPT this traffic then you need a 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.
      -
      4. -
    4. <zone1>2<zone2> - Either you have a policy for <zone1> to - <zone2> that specifies a log level and this packet is being - logged under that policy or this packet matches a rule that include a log level.
      5. -
    5. logpkt - The packet is being logged under the logunclean - interface option.
      6. -
    6. badpkt - The packet is being logged under the dropunclean - interface option as specified - in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      7. -
    7. blacklst - The packet is being logged because the source - IP is blacklisted in the /etc/shorewall/blacklist - file.
      8. -
    8. 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 +
    9. <zone1>2<zone2> - Either you have a policy for <zone1> to + <zone2> that specifies a log level and this packet is being + logged under that policy or this packet matches a rule that includes a log level.
      10. +
    10. <interface>_mac - The packet is being logged under the + maclist interface option.
      +
      11. +
    11. logpkt - The packet is being logged under the logunclean + interface option.
      12. +
    12. badpkt - The packet is being logged under the dropunclean + interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      13. +
    13. blacklst - The packet is being logged because the source + IP is blacklisted in the /etc/shorewall/blacklist + file.
      14. +
    14. newnotsyn - The packet is being logged because it is + a TCP packet that is not part of any current connection yet it is not +a syn packet. Options affecting the logging of such packets include NEWNOTSYN + and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
      15. -
    15. INPUT or FORWARD - The packet has a source IP address - that isn't in any of your defined zones ("shorewall check" and look at the - printed zone definitions) or the chain is FORWARD and the destination IP - isn't in any of your defined zones.
      16. - +
    16. 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.
      17. +
    - -

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

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

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

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

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

         ACCEPT	net	loc:10.1.1.126	tcp	www
    - + class="moz-txt-citetags">
    + Example 3 (DNAT):
    +     +
         # Forward SMTP on external address 192.0.2.127 to local system 10.1.1.127

         DNAT	net	loc:10.1.1.127	tcp	smtp	-	192.0.2.127
    + +

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

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

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

    +Yes. Consult the QuickStart guide +that you used during your initial setup for information about how to set +up rules for your server.
    +
    +
    - -

    Last updated 11/09/2002 - Tom Eastep

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.
    + Last updated 11/24/2002 - Tom Eastep + +

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

    +
    +

    -


    diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html index 427184e89..19fdb4615 100644 --- a/STABLE/documentation/MAC_Validation.html +++ b/STABLE/documentation/MAC_Validation.html @@ -2,105 +2,104 @@ 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 +
    + 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. -
    2. The maclist option in /etc/shorewall/hosts. - When this option is specified for a subnet, all traffic from that subnet +
    3. The maclist interface option in /etc/shorewall/interfaces. When this +option is specified, all traffic arriving on the interface is subjet to MAC +verification.
      4. +
    4. 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.
      5. -
    5. The /etc/shorewall/maclist file. This file is used to associate MAC - addresses with interfaces and to optionally associate IP addresses with +
    6. The /etc/shorewall/maclist file. This file is used to associate +MAC addresses with interfaces and to optionally associate IP addresses with MAC addresses.
      7. -
    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="") +
    8. 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.
      -
      9. - + +
    - The columns in /etc/shorewall/maclist are:
    - + The columns in /etc/shorewall/maclist are:
    + - +

    Example 1: Here are my files:

    - /etc/shorewall/shorewall.conf:
    -     + /etc/shorewall/shorewall.conf:
    + 
         MACLIST_DISPOSITION=REJECT
         MACLIST_LOG_LEVEL=info
    - /etc/shorewall/interfaces:
    - + /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:
    - + /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 + 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 + 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 -

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

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    -
    +
    +
    +


    diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 6016710da..4bd17b10c 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -1,1452 +1,1512 @@ - + Shorewall News - + - + - + - - - + + - - - + + + +
    - +
    + +

    Shorewall News Archive

    -
    - -

    11/09/2002 - Shorewall 1.3.10

    + +

    11/24/2002 - Shorewall 1.3.11

    In this version:

    +

    11/14/2002 - Shorewall Documentation in PDF Format

    + +

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

    + +

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

    + +

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

    + +

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

    + +

    11/09/2002 - Shorewall 1.3.10

    + +

    In this version:

    + + +

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

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

    + 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:
    + In this version:
    + + + You may download the Beta from:
    + + + +

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

    + +

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

    + +

    10/9/2002 - Shorewall 1.3.9b

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

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

    + Roles up the fix for broken tunnels.
    + +

    9/30/2002 - TUNNELS Broken in 1.3.9!!!

    + There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall.
    + +

    9/28/2002 - Shorewall 1.3.9

    + +

    In this version:
    +

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

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

    - -

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

    - -

    10/9/2002 - Shorewall 1.3.9b

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

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

    - Roles up the fix for broken tunnels.
    - -

    9/30/2002 - TUNNELS Broken in 1.3.9!!!

    - There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
    - -

    9/28/2002 - Shorewall 1.3.9

    - -

    In this version:
    -

    - - - -

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

    - Brown Paper Bag9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
    +

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

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

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

    - +

    + - + - +

    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:

    - + - -

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

    - + - +

    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:

    - + - +

    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:

    - + - +

    6/25/2002 - Samples Updated for 1.3.2

    - -

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

    - + +

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

    +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

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

    - + +

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

    +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + - +

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

    - -

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

    - + +

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

    + - -

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

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

    - -

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

    - + +

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

    +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/2/2002 - Samples Corrected

    - -

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

    - + +

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

    +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    - + +

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

    + - +

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    - + +

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

    + - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

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

    - + +

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

    + - +

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

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

    - + +

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

    + - +

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + - +

    4/30/2002 - Shorewall Debian News

    - -

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

    - -

    4/20/2002 - Shorewall 1.2.12 is Available

    - - - -

    4/17/2002 - Shorewall Debian News

    - -

    Lorenzo Marignoni reports that:

    - - + +

    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:
    +
    + Examples of valid DNS names:
    +

    - DNS names may not be used as:
    +
  • mail.shorewall.net
    • +
  • shorewall.net.
    • - - These are iptables restrictions and are not simply imposed for your + 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:

    - -