diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index ae1b7ebfe..608264580 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -1,269 +1,276 @@ - + - + - + Shorewall 1.4 Documentation - + - + - + - + - - - + + - - - + + + +
+
+

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

- + - +

/etc/shorewall/params

- +

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

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

+

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

- + within the Shorewall programs

+

Example:

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

Example (/etc/shorewall/interfaces record):

- + 
	net $NET_IF $NET_BCAST $NET_OPTIONS
- +

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

- + 
	net eth0 130.252.100.255 blacklist,norfc1918
- +

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

- + files.

+

/etc/shorewall/zones

- +

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

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

+ - -

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

- - - - - - - - - - - - - - - - - - - - - - - +
  • DISPLAY - The name of + the zone as displayed during Shorewall startup.
    • +
  • COMMENTS - Any comments + that you want to make about the zone. Shorewall ignores + these comments.
    • - + + +

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

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

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

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

    +

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

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

    +

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

    - + significant in some cases.

    +

    /etc/shorewall/interfaces

    - +

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

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

    + - +

    My recommendations concerning options:
    -

    - +

    + - +

    - +

    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 -check all packets entering from the internet against the black list. Your /etc/shorewall/interfaces file - would be as follows:

    - -
    + would be as follows:

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

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

    - -
    - - + - - - - - - - - - - - - - -
    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
    -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918,blacklist
    loceth1detect
    +
    - + +

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

    + +
    + + + + + + + + + + + + + + + + +
    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: The only times that you need entries in /etc/shorewall/hosts are:
    -

    - -
      -
    1. You have more than one zone connecting through a single interface; -or
      2. -
    2. You have a zone that has multiple subnetworks that connect through -a single interface and you want the Shorewall box to route traffic between -those subnetworks.
      -
      3. - -
    - IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH THIS FILE!! -

    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.

    -
    - - - -
    -

    maclist - Added in version 1.3.10. If specified, connection - requests from the hosts specified in this entry are subject -to MAC Verification. This option is -only valid for ethernet interfaces.
    -

    -
    - -

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

    - -

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

    +

    -

    Example 1:

    - -

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

    - - - -

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

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1192.168.1.127,192.168.1.255
    -
    -
    -
    - -

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

    Example 2:

    - -

    Your local interface is eth1 and you have two groups of local hosts that -you want to consider as one zone and you want Shorewall to route between them:

    - - - -

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

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    loc
    -     		eth1192.168.1.127,192.168.1.255
    -
    -
    -
    - -

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

    - -
    - - - - - - - - - - - - - - - - - - - - -
    ZONE HOST(S) OPTIONS
    loceth1:192.168.1.0/25
    -
    loceth1:192.168.1.128/25
    -
    -
    - -

    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 You have more than one zone connecting through a single interface; + or
      3. +
    3. You have a zone that has multiple subnetworks that connect through + a single interface and you want the Shorewall box to route traffic between + those subnetworks.
      +
      4. + +
    + IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH THIS +FILE!! +

    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.

    +
    + + + +
    +

    routeback (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets sent by this host group back back +to the same group.
    +
    + maclist -     Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to + MAC Verification. This option is only + valid for ethernet interfaces.
    +

    +
    + +

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

    + +

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

    + +

    Example 1:

    + +

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

    + + + +

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

    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1192.168.1.127,192.168.1.255
    +
    +
    +
    + +

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

    Example 2:

    + +

    Your local interface is eth1 and you have two groups of local hosts that + you want to consider as one zone and you want Shorewall to route between +them:

    + + + +

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

    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    loc
    +     		eth1192.168.1.127,192.168.1.255
    +
    +
    +
    + +

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

    + +
    + + + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    loceth1:192.168.1.0/25
    +
    loceth1:192.168.1.128/25
    +
    +
    + +

    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 +POLICY - The default policy for connection requests from +the SOURCE zone to the DESTINATION zone.
      5. +
    5. +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.
      6. -
    6. 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 +
    7. 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.
      8. - +
    - +

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

    - + zones.

    +

    The policy file installed by default is as follows:

    - +
    - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    +

    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.

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

    +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    -
    -
    netallDROPinfo
    -
    loclocREJECTinfo
    -
    -
    - -

    IntraZone Traffic

    - Shorewall allows a zone to be associated with more than one interface or -with multiple networks that interface through a single interface. Beginning -with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from a zone to itself -provided that there is no explicit policy governing traffic from that zone -to itself (an explicit policy does not specify "all" in either the SOURCE -or DEST column) and that there are no rules concerning connections from that -zone to itself. If there is an explicit policy or if there are one or more -rules, then traffic within the zone is handled just like traffic between zones -is.
    - -

    Any time that you have multiple interfaces associated with a single zone, -you should ask yourself if you really want traffic routed between those interfaces. -Cases where you might not want that behavior are:
    -

    - -
      -
    1. Multiple 'net' interfaces to different ISPs. You don't want to route -traffic from one ISP to the other through your firewall.
      2. -
    2. Multiple VPN clients. You don't necessarily want them to all be able -to communicate between themselves using your gateway/router.
      -
      3. - -
    - -

    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 DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    +
    +
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    -
    - -

    /etc/shorewall/interfaces:

    - -
    +
    + +

    IntraZone Traffic

    + Shorewall allows a zone to be associated with more than one interface +or with multiple networks that interface through a single interface. Beginning + with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from a zone to itself + provided that there is no explicit policy governing traffic from that zone + to itself (an explicit policy does not specify "all" in either the SOURCE + or DEST column) and that there are no rules concerning connections from that + zone to itself. If there is an explicit policy or if there are one or more + rules, then traffic within the zone is handled just like traffic between +zones is.
    + +

    Any time that you have multiple interfaces associated with a single zone, + you should ask yourself if you really want traffic routed between those interfaces. + Cases where you might not want that behavior are:
    +

    + +
      +
    1. Multiple 'net' interfaces to different ISPs. You don't want to route + traffic from one ISP to the other through your firewall.
      2. +
    2. Multiple VPN clients. You don't necessarily want them to all be +able to communicate between themselves using your gateway/router.
      +
      3. + +
    + +

    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 INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detect
    -
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    -
    - -

    /etc/shorewall/hosts:

    - -
    +
    + +

    /etc/shorewall/interfaces:

    + +
    - + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    neteth0:0.0.0.0/0
    -
    sameth0:206.191.149.197
    -
    ZONE INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detect
    +
    -
    - + + +

    /etc/shorewall/hosts:

    + +
    + + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    neteth0:0.0.0.0/0
    +
    sameth0:206.191.149.197
    +
    +
    +

    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.

    - + and the net + zone and as described above , that means + that sam must be listed before net in /etc/shorewall/zones.

    +

    /etc/shorewall/policy:

    - +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    -
    samallCONTINUE
    -
    netallDROPinfo
    allallREJECTinfo
    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 + 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:

    - +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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-
    -
    ...
    -
    -
    -
    -
    -
    -
    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 net zone -with the exception of those in the 'sam' zone -should have their 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 + with the exception of those in the 'sam' zone + should have their 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.

    - +

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

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

    - + - +

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

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

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

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

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

    - +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTnetdmz:155.186.235.222tcpwww-
    -
    ACCEPTlocdmz:155.186.235.222tcpwww
    -
    -
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTnetdmz:155.186.235.222tcpwww-
    +
    ACCEPTlocdmz:155.186.235.222tcpwww
    +
    +
    -
    - + +

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

    - + .

    +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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 with MAC address 02:00:08:E3:FA:55.

    - +
    + face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    -
    -
    -
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    +
    +
    +
    -
    + -Example 6. You wish to allow access to the SMTP server -in your DMZ from all zones.
    - -
    + Example 6. You wish to allow access to the SMTP server + in your DMZ from all zones.
    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		SOURCE
    - PORT(S)
    -     		ORIGINAL
    - DEST
    -
    ACCEPT
    -     		all
    -     		dmz
    -     		tcp
    -     		25
    -
    -
    -
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(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.
    -
    - Example 7 (For advanced users running Shorewall version - 1.3.13 or later). From the internet, you with to forward tcp -port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 -in your DMZ. You also want to allow access from the internet directly -to tcp port 25 on 192.0.2.177.
    - -
    +
    + 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.
    +
    + Example 7 (For advanced users running Shorewall +version 1.3.13 or later). From the internet, you with to forward +tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 + in your DMZ. You also want to allow access from the internet directly + to tcp port 25 on 192.0.2.177.
    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		SOURCE
    - PORT(S)
    -     		ORIGINAL
    - DEST
    -
    DNAT-
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -     		0
    -     		192.0.2.178
    -
    DNAT-
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -     		0
    -     		192.0.2.179
    -
    ACCEPT
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -
    -
    -
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		SOURCE
    + PORT(S)
    +     		ORIGINAL
    + DEST
    +
    DNAT-
    +     		net
    +     		dmz:192.0.2.177
    +     		tcp
    +     		25
    +     		0
    +     		192.0.2.178
    +
    DNAT-
    +     		net
    +     		dmz:192.0.2.177
    +     		tcp
    +     		25
    +     		0
    +     		192.0.2.179
    +
    ACCEPT
    +     		net
    +     		dmz:192.0.2.177
    +     		tcp
    +     		25
    +
    +
    +
    -
    - Using "DNAT-" rather than "DNAT" avoids two extra copies - of the third rule from being generated.
    - +
    + Using "DNAT-" rather than "DNAT" avoids two extra +copies of the third rule from being generated.
    +

    Look here for information on other services.

    - +

    /etc/shorewall/common

    - +

    Shorewall allows definition of rules that apply between -all zones. By default, these rules - are defined in the file - /etc/shorewall/common.def - but may be modified to - suit individual - requirements. Rather than modify /etc/shorewall/common.def, - you should copy that + all zones. By default, these rules + are defined in the file + /etc/shorewall/common.def + but may be modified to + suit individual + requirements. Rather than modify /etc/shorewall/common.def, + you should copy that file to /etc/shorewall/common and modify that file.

    - +

    The /etc/shorewall/common - file is expected to contain iptables + 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.

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

    - +

    Columns are:

    - + - +

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

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

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

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

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

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

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

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

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

    Example 4: Same as example 3 except that -you wish to exclude 192.168.10.44 -and 192.168.10.45 from - the SNAT rule.

    - -
    + you wish to exclude 192.168.10.44 + and 192.168.10.45 from + 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
    -
    - Example 5 (Shorewall version >= 1.3.14): You have a second - IP address (206.124.146.177) assigned to you and wish to use it for SNAT - of the subnet 192.168.12.0/24. You want to give that address the name - eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
    - -
    +
    + Example 5 (Shorewall version >= 1.3.14): You have a +second IP address (206.124.146.177) assigned to you and wish to use +it for SNAT of the subnet 192.168.12.0/24. You want to give that address +the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
    + +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0:0192.168.12.0/24206.124.146.177
    INTERFACE SUBNETADDRESS
    eth0:0192.168.12.0/24206.124.146.177
    -
    - +
    +

    /etc/shorewall/proxyarp

    - +

    If you want to use proxy ARP on an entire sub-network, - I suggest that you look -at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide to use the technique - described in that + 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 + 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. -

    - + 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 @@ -2033,468 +2048,472 @@ small set of systems since you need one entry in this file for each system using proxy ARP. Columns -are:

    - + are:

    + - +

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

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

    +

    ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may take a long while to time out. I personally have had to contact my ISP and ask them 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:

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

    +

    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.

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

    - + 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 all you want to do - is forward ports to -servers behind your firewall, you - do NOT want to use - static NAT. Port - forwarding can be + is forward ports to + servers behind your firewall, you + do NOT want to use + static NAT. Port + forwarding can be accomplished - with simple entries in + with simple entries in the rules -file. Also, in most - cases - Proxy ARP - provides a - superior solution -to static NAT because -the internal systems - are accessed - using the same IP address internally + file. Also, in most + cases + Proxy ARP + provides a + superior solution + to static NAT because + the internal systems + are accessed + using the same IP address internally and externally.

    - +

    Columns in an entry are:

    - + - +

    Look here for additional information and an example. -

    - +

    +

    /etc/shorewall/tunnels

    - +

    The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, - OpenVPN and PPTP - tunnels with end-points on your firewall. To use ipsec, you must - install version 1.9, 1.91 or the current OpenVPN 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, instructions + for IPIP and GRE tunnels are here, instructions for OpenVPN tunnels are here, and - instructions for PPTP tunnels are here.

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

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

    -
    - + <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 - modules and execute the following command:

    - -
    + modules and execute the following command:

    + +

    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 .

    - +

    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 + or subnet address. Example:

    - + 
          130.252.100.69
          206.124.146.0/24
    - +

    Packets from hosts listed @@ -2782,128 +2801,132 @@ file.

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

    - + and BLACKLIST_LOGLEVEL variables in + /etc/shorewall/shorewall.conf. + Only + packets arriving + on interfaces + that + have the + 'blacklist' + option in + /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).

    - +

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

    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    INTERFACEHOST(S)
    eth2192.168.1.0/24
    eth1-
    INTERFACEHOST(S)
    eth2192.168.1.0/24
    eth1-
    -
    - +
    +

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

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

    /etc/shorewall/ecn (Added in Version 1.4.0)

    - This file is described in the ECN Control Documentation.
    -
    - -

    Updated 4/11/2003 - Tom Eastep -

    - +
    + +

    Updated 5/9/2003 - Tom Eastep +

    +

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

    +

    +
    +



    diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index 42b172409..a23d7a211 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -1,1238 +1,1255 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
    +

    Shorewall FAQs

    -
    - +

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

    + +

    PORT FORWARDING
    -

    - + +

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

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

    +

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

    - + but it doesn't work.
    +

    +

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

    - + port forwarding

    +

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

    - +

    +

    DNS and PORT FORWARDING/NAT
    -

    - + +

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

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

    +

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

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

    +

    NETMEETING/MSN
    -

    - + +

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

    - + or MSN Instant Messenger with Shorewall. + What do I do?

    +

    OPEN PORTS
    -

    - + +

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

    - + to check my firewall and it shows some ports + as 'closed' rather than 'blocked'. Why?

    +

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

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

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

    CONNECTION PROBLEMS

    - +

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

    - + I can't ping through the firewall
    +
    + 15.     My local systems can't see out + to the net

    +

    LOGGING
    -

    - + +

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

    - + written and how do I change the destination?

    +

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

    - + that work with Shorewall?

    +

    6b. DROP messages on port 10619 are flooding the logs with their connect - requests. Can i exclude these error messages for this port temporarily - from logging in Shorewall?
    -

    - + requests. Can i exclude these error messages for this port temporarily + from logging in Shorewall?
    +

    +

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

    - + of these DROP messages from port 53 to some high numbered + port. They get dropped, but what the heck are they?
    +

    +

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

    - + in Shorewall log messages so long? I thought MAC addresses + were only 6 bytes in length.
    +

    +

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

    - 17. -How do I find out why this traffic is -getting logged?
    -
    - 21.     I see these strange log entries - occasionally; what are they?
    - + all over my console making it unusable!
    +

    + 17. + How do I find out why this traffic is + getting logged?
    +
    + 21.     I see these strange log entries + occasionally; what are they?
    +

    STARTING AND STOPPING
    -

    - + +

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

    - +

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

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

    +

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

    - + on RedHat I get a message referring me to FAQ #8
    +

    +

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

    - 22. I have -some iptables commands that I want to run when Shorewall - starts. Which file do I put them in?
    - + my interfaces properly at startup?

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

    ABOUT SHOREWALL
    -

    - + +

    10. What distributions does - it work with?

    - + it work with?

    +

    11. What features does it support?

    - +

    12. Is there a GUI?

    - +

    13. Why do you call it "Shorewall"?

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

    RFC 1918
    -

    - + +

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

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

    +

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

    - +

    ALIAS IP ADDRESSES/VIRTUAL INTERFACES
    -

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

    MISCELLANEOUS
    -

    - 19. I have added entries to /etc/shorewall/tcrules - but they don't seem to do anything. Why?
    -
    - 20. I have - just set up a server. Do I have to change Shorewall to -allow access to my server from the internet?
    -
    - 24. How can I allow -conections to let's say the ssh port only from specific -IP Addresses on the internet?
    -
    -
    -
    - -
    + + 19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?
    +
    + 20. I +have just set up a server. Do I have to change Shorewall +to allow access to my server from the internet?
    +
    + 24. How can I allow + conections to let's say the ssh port only from specific + IP Addresses on the internet?
    +
    +
    +
    + +

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

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

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

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

    + +
    - - - - - - - - - - - - - - - - - - - - - + id="AutoNumber1" cellspacing="1"> + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:<local - IP address>[:<local port>]<protocol><port - #>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
    DNATnetloc:<local + IP address>[:<local port>]<protocol><port + #>
    +
    +
    -
    - +
    +

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

    - -
    + the rule is:

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

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

    - + but it doesn't work +

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

    - + things:

    + - +

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

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

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

    - -
    -
    + to connect to port 1022 on my firewall and have the firewall forward the + connection to port 22 on local system 192.168.1.3. How do I do that? + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnet
    -     		loc:192.168.1.3:22tcp1022
    -
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
    DNATnet
    +     		loc:192.168.1.3:22tcp1022
    +
    +
    +
    -
    -
    - +
    +
    +

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

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

    Answer: I have two objections to this setup.

    - + - +

    If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that - 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.
    -

    - + rather than a DNS solution, then assuming that + your external interface is eth0 and your internal + interface is eth1 and that eth1 has IP address 192.168.1.254 + with subnet 192.168.1.0/24.
    +

    +

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

    - + suitable for those releases.
    +

    +

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

    - + upgrade to Shorewall 1.4.2 or later.
    +

    +

    Otherwise:
    -

    - +

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

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

    -
    - -
    + IP address. If you have a dynamic IP address +and are running Shorewall 1.3.4 or later then include +this in /etc/shorewall/init:

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

    and make your DNAT rule:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
    DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
    -
    -
    - -
    + +
    + +

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

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

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

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

    - + static NAT to Proxy ARP. That way, the hosts in + Z have non-RFC1918 addresses and can be accessed externally + and internally using the same address.

    +

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

    - +

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

    - + b) Masquerade Z +to itself.
    +
    + Example:

    +

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

    - + Interface: eth2
    + Subnet: 192.168.2.0/24

    +

    In /etc/shorewall/interfaces:

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

    In /etc/shorewall/policy:

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

    In /etc/shorewall/masq:

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

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

    - + Messenger with Shorewall. What do I do? +

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

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

    +

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

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

    - +

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

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

    +

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

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

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

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

    + +

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

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

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

    - + can't ping through the firewall +

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

    - + for "ping",

    +

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

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

    + +

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

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

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

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

    - + and how do I change the destination? +

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

    - +

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

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

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

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

    - + with Shorewall? +

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

    - -
    +

    + +

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

    -
    - I personnaly use Logwatch. It emails -me a report each day from my various systems with each report -summarizing the logged activity on the corresponding system. - + http://www.logwatch.org
    + http://gege.org/iptables
    +

    +
    + I personnaly use Logwatch. It emails + me a report each day from my various systems with each report + summarizing the logged activity on the corresponding system. +

    6b. DROP messages on port 10619 - are flooding the logs with their connect requests. Can i - exclude these error messages for this port temporarily from logging - in Shorewall?

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

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

    - + of these DROP messages from port 53 to some high numbered port. + They get dropped, but what the heck are they? + 
    Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                            SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                            TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
    - Answer: There are two possibilities:
    - + Answer: There are two possibilities:
    +
      -
    1. They are late-arriving replies to DNS queries.
      2. -
    2. They are corrupted reply packets.
      3. - +
    3. They are late-arriving replies to DNS queries.
      4. +
    4. They are corrupted reply packets.
      5. +
    - You can distinguish the difference by setting the -logunclean option (logunclean option (/etc/shorewall/interfaces) on your external interface (eth0 in the above example). If they get - logged twice, they are corrupted. I solve this problem by using an -/etc/shorewall/common file like this:
    - -
    + logged twice, they are corrupted. I solve this problem by using +an /etc/shorewall/common file like this:
    + +
    #
    # Include the standard common.def file
    #
    . /etc/shorewall/common.def
    #
    # The following rule is non-standard and compensates for tardy
    # DNS replies
    #
    run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
    -
    - The above file is also include in all of my sample -configurations available in the + The above file is also include in all of my sample + configurations available in the Quick Start Guides and in -the common.def file in Shorewall 1.4.0 and later.
    - + the common.def file in Shorewall 1.4.0 and later.
    +

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

    - What is labeled as the MAC address in a Shorewall log message - is actually the Ethernet frame header. IT contains:
    - + Shorewall log messages so long? I thought MAC addresses were only + 6 bytes in length. + What is labeled as the MAC address in a Shorewall log message + is actually the Ethernet frame header. IT contains:
    + - Example:
    -
    - MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
    - + Example:
    +
    + MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
    + - +

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

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

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

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

    +

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

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

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

    - + this:

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

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

    - -
    +

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

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

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

    +

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

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

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

    - + properly at startup? +

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

    - -
    + I see the following:

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

    Why can't Shorewall detect my interfaces properly?

    -
    - -
    +
    + +

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

    -
    - +
    +

    10. What Distributions does it work with?

    - +

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

    - + the proper prerequisites.

    +

    11. What Features does it have?

    - +

    Answer: See the Shorewall - Feature List.

    - + Feature List.

    +

    12. Is there a GUI?

    - +

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

    - + 1.060 and later versions. See http://www.webmin.com +

    +

    13. Why do you call it "Shorewall"?

    - +

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

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

    +

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

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

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

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

    +

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

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

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

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

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

    - +

    +

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

    - -
    +

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

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

    -
    - -
    +
    + +

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

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

    + +

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

    - + the net +

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

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

    +
      -
    1. - +
    2. +

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

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

      +
      4. +
    4. +

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

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

      +
      6. +
    6. +

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

      -
      7. - + +
    - +

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

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

    - + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent to + the console is specified in /etc/sysconfig/init in the + LOGLEVEL variable.
    +

    +

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

    - Answer: Logging -occurs out of a number of chains (as indicated in the -log message) in Shorewall:
    - + logged? + Answer: Logging + occurs out of a number of chains (as indicated in +the log message) in Shorewall:
    +
      -
    1. man1918 - 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 +
    5. <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.
      6. -
    6. <interface>_mac - - The packet is being logged under the maclist - interface option.
      -
      7. -
    7. logpkt - The - packet is being logged under the logunclean - interface option.
      8. -
    8. badpkt - The - packet is being logged under the dropunclean - interface option as -specified in the LOGUNCLEAN setting in rule that includes + a log level.
      9. +
    9. <interface>_mac + - The packet is being logged under the maclist + interface option.
      +
      10. +
    10. logpkt - +The packet is being logged under the logunclean + interface option.
      11. +
    11. badpkt - +The packet is being logged under the dropunclean + interface option +as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      12. -
    12. blacklst - -The packet is being logged because the source IP is -blacklisted in the /etc/shorewall/blacklist - file.
      13. -
    13. 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 +
    14. blacklst +- The packet is being logged because the source IP +is blacklisted in the /etc/shorewall/blacklist + file.
      15. +
    15. newnotsyn - + The packet is being logged because it is a TCP packet + that is not part of any current connection yet it is not a syn packet. Options affecting the logging of such packets include - NEWNOTSYN and LOGNEWNOTSYN in - /etc/shorewall/shorewall.conf.
      16. -
    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. -
    17. logflags - The packet - is being logged because it failed the checks implemented - by the tcpflags NEWNOTSYN and LOGNEWNOTSYN in + /etc/shorewall/shorewall.conf.
      18. +
    18. 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.
      19. +
    19. logflags - The packet + is being logged because it failed the checks implemented + by the tcpflags interface option.
      -
      20. - + +
    - +

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

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

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

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

    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
    + + Yes. Consult the     QuickStart guide that you used during your initial setup for information about how to set up rules for your server.
    - +

    21. I see these strange log entries occasionally; - what are they?
    -

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

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

    - You can place these commands in one - of the Shorewall Extension + I want to run when Shorewall starts. Which file do +I put them in? + You can place these commands in +one of the Shorewall Extension Scripts. Be sure that you look at the contents of the chain(s) that you will be modifying with your commands to be sure that the commands will do what they are intended. Many iptables commands @@ -1241,39 +1258,41 @@ command which adds the rules to the end of the chain. Most chains that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT rule and any rules that you add after that will be ignored. Check "man iptables" and look at the -I (--insert) command.
    - +

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

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

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

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

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

    - At the shell prompt, type:
    -
    - /sbin/shorewall version
    -
    - Last updated 4/8/2003 - Tom Eastep + I am running?
    + + At the shell prompt, type:
    +
    + /sbin/shorewall version
    +
    + Last updated 4/14/2003 - Tom Eastep

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

    +

    +
    +

    diff --git a/Shorewall-docs/IPSEC.htm b/Shorewall-docs/IPSEC.htm index 99cbf4add..842fe9168 100644 --- a/Shorewall-docs/IPSEC.htm +++ b/Shorewall-docs/IPSEC.htm @@ -1,367 +1,421 @@ - + Shorewall IPSec Tunneling - + - + - + - - - + + - - - + + + +
    +

    IPSEC Tunnels

    -
    - +

    Configuring FreeS/Wan

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

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

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

    +

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

    - + (I haven't tried it):

    +

    In /etc/shorewall/init, include:

    - +

         qt service ipsec stop

    - +

    In /etc/shorewall/start, include:

    - +

        qt service ipsec start

    - +

    IPSec Gateway on the Firewall System

    - +

    Suppose that we have the following sutuation:

    - +

    -

    -     +

    +

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

    - + to communicate with systems in the 10.0.0.0/8 network.

    +

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

    - +

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

    - + (allow the ESP and AH protocols and UDP Port 500).

    +

    b) Allow traffic through the tunnel.

    - +

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

    - + by adding an entry to the /etc/shorewall/tunnels file.

    +

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

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

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

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

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

    -

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

    - -
    - - - - - - - - - - - - - - + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    vpnVPNRemote Subnet
    TYPE ZONE GATEWAY GATEWAY ZONE
    ipsecnet134.28.54.2 
    - -

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

    - -
    + +

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

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

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

    - -
    - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVEL
    locvpnACCEPT 
    vpnlocACCEPT 
    TYPE ZONE GATEWAY GATEWAY ZONE
    ipsecnet206.161.148.9 
    - + +

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

    + +

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

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

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

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

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

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

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

    - +

    Mobile System (Road -Warrior)

    - + Warrior) +

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

    - +

    -

    - +

    +

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

    - -
    + your local zone. In this example, we'll assume that you have created + a zone called "vpn" to represent the remote host.

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

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

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

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

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

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

    - -

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

    - + to peer subnetworks. This indicates that the gateway system itself comprises + the peer subnetwork; in other words, the remote gateway is a standalone +system.

    + +

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

    +

    Dynamic RoadWarrior Zones

    - Beginning with Shorewall release 1.3.10, you can define multiple VPN zones -and add and delete remote endpoints dynamically using /sbin/shorewall. In -/etc/shorewall/zones:
    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE
    -     		DISPLAY
    -     		COMMENTS
    -
    vpn1
    -     		VPN-1
    -     		First VPN Zone
    -
    vpn2
    -     		VPN-2
    -     		Second VPN Zone
    -
    vpn3
    -     		VPN-3
    -     		Third VPN Zone
    -
    + Beginning with Shorewall release 1.3.10, you can define multiple VPN zones + and add and delete remote endpoints dynamically using /sbin/shorewall. In + /etc/shorewall/zones:

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

    Limitations of Dynamic Zones

    +If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added +hosts are not excluded from the rule.
    +
    +Example with dyn=dynamic zone:
    +
    +
    + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT(S)
    +     		CLIENT
    +PORT(S)
    +     		ORIGINAL
    +DESTINATION
    +
    DNAT
    +     		z:dyn
    +     		loc:192.168.1.3
    +     		tcp
    +     		80
    +
    +
    +
    +
    +Dynamic changes to the zone dyn will have no effect on the above rule. + +

    Last updated 5/3//2003 - Tom Eastep

    + +

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

    +

    -
    - When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall -will issue warnings to that effect. These warnings may be safely ignored. -FreeS/Wan may now be configured to have three different Road Warrior connections -with the choice of connection being based on X-509 certificates or some other -means. Each of these connectioins will utilize a different updown script that -adds the remote station to the appropriate zone when the connection comes -up and that deletes the remote station when the connection comes down. For -example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of the -script will issue the command":
    -
    - -
    /sbin/shorewall add ipsec0:134.28.54.2 vpn2
    -
    - and the 'down' part will:
    - -
    /sbin/shorewall delete ipsec0:134.28.54.2 vpn
    - -

    Last updated 10/23/2002 - - Tom Eastep

    - -

    - Copyright © 2001, 2002 Thomas M. Eastep.

    -
    +

    diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index d16b314e5..67444dce3 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -13,2867 +13,3042 @@ - + - + - + - - - + + - + + - - + +
    +
    - +

    Shorewall News Archive

    -
    - -

    4/9/2003 - Shorewall 1.4.2
    -

    - -

        Problems Corrected:

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

        New Features:

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

      5/10/2003 - Shorewall Mirror in Asia
      +

      -
    +

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

    -

    3/24/2003 - Shorewall 1.4.1

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

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

    - -
      -
    1. When Shorewall 1.4.0 is run under the ash shell (such as on Bering/LEAF), - it can attempt to add ECN disabling rules even if the /etc/shorewall/ecn -file is empty. That problem has been corrected so that ECN disabling rules -are only added if there are entries in /etc/shorewall/ecn.
      2. +

      5/8/2003 - Shorewall Mirror in Chile

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

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

      -
    - New Features:
    - -
    Note: In the list that follows, the term group refers to -a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a -host address) accessed through a particular interface. Examples:
    - -
    eth0:0.0.0.0/0
    - eth2:192.168.1.0/24
    - eth3:192.0.2.123
    -
    - You can use the "shorewall check" command to see the groups associated -with each of your zones.
    -
    - -
      -
    1. Beginning with Shorewall 1.4.1, if a zone Z comprises more than one - group then if there is no explicit Z to Z policy and there are no -rules governing traffic from Z to Z then Shorewall will permit all traffic -between the groups in the zone.
      2. -
    2. Beginning with Shorewall 1.4.1, Shorewall will never create rules -to handle traffic from a group to itself.
      3. -
    3. A NONE policy is introduced in 1.4.1. When a policy of NONE is specified - from Z1 to Z2:
      4. +

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

      -
    - -
      -
    • There may be no rules created that govern connections from Z1 to -Z2.
      • -
    • Shorewall will not create any infrastructure to handle traffic from - Z1 to Z2.
      • - -
    - See the upgrade issues for a discussion - of how these changes may affect your configuration. -

    3/17/2003 - Shorewall 1.4.0

    - Shorewall 1.4 represents - the next step in the evolution of Shorewall. The main thrust of the -initial release is simply to remove the cruft that has accumulated in -Shorewall over time.
    -
    - IMPORTANT: Shorewall 1.4.0 requires the iproute package - ('ip' utility).
    -
    - Function from 1.3 that has been omitted from this version include:
    - -
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer - supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will generate - an error at startup if specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is -no longer accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      7. -
    7. The icmp.def file has been removed.
      -
      8. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely - reorganized into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script and version file are now installed in - /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in the - common chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall - 1.4 no longer unconditionally accepts outbound ICMP packets. So if you - want to 'ping' from the firewall, you will need the appropriate rule or - policy.
      -
      -
      6. -
    6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      7. -
    7. 802.11b devices with names of the form wlan<n> now support - the 'maclist' option.
      -
      -
      8. -
    8. Explicit Congestion Notification (ECN - RFC 3168) may now be turned - off on a host or network basis using the new /etc/shorewall/ecn file. To - use this facility:
      -
      -    a) You must be running kernel 2.4.20
      -    b) You must have applied the patch in
      -    http://www.shorewall/net/pub/shorewall/ecn/patch.
      -    c) You must have iptables 1.2.7a installed.
      -
      -
      9. -
    9. The /etc/shorewall/params file is now processed first so that -variables may be used in the /etc/shorewall/shorewall.conf file.
      -
      -
      10. -
    10. Shorewall now gives a more helpful diagnostic when - the 'ipchains' compatibility kernel module is loaded and a 'shorewall start' - command is issued.
      -
      -
      11. -
    11. The SHARED_DIR variable has been removed from shorewall.conf. - This variable was for use by package maintainers and was not documented -for general use.
      -
      -
      12. -
    12. Shorewall now ignores 'default' routes when detecting masq'd -networks.
      13. - -
    - -

    3/10/2003 - Shoreall 1.3.14a

    - -

    A roleup of the following bug fixes and other updates:

    - -
      -
    • There is an updated rfc1918 file that reflects the resent allocation - of 222.0.0.0/8 and 223.0.0.0/8.
      • - -
    +

    4/9/2003 - Shorewall 1.4.2
    +

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

    2/8/2003 - Shoreawall 1.3.14

    - -

    New features include

    +

        Problems Corrected:

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

        New Features:

      -
    1. An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been - (see http://www.shorewall.net/ping.html).
      -
      - When OLD_PING_HANDLING=No, icmp echo (ping) is handled - via rules and policies just like any other connection request. -The FORWARDPING=Yes option in shorewall.conf and the 'noping' and -'filterping' options in /etc/shorewall/interfaces will all generate -an error.
      -
      -
      2. -
    2. It is now possible to direct Shorewall to create a "label" - such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      3. -
    3. Support for OpenVPN Tunnels.
      +
    4. Where an entry in the/etc/shorewall/hosts file specifies a particular + host or network, Shorewall now creates an intermediate chain for handling + input from the related zone. This can substantially reduce the number of + rules traversed by connections requests from such zones.
      +
      +
      5. +
    5. Any file may include an INCLUDE directive. An INCLUDE directive +consists of the word INCLUDE followed by a file name and causes the contents +of the named file to be logically included into the file containing the INCLUDE. + File names given in an INCLUDE directive are assumed to reside in /etc/shorewall + or in an alternate configuration directory if one has been specified for + the command.
      +  
      +    Examples:
      +    shorewall/params.mgmt:
      +    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
      +    TIME_SERVERS=4.4.4.4
      +    BACKUP_SERVERS=5.5.5.5
      +    ----- end params.mgmt -----
      +  
      +  
      +    shorewall/params:
      +    # Shorewall 1.3 /etc/shorewall/params
      +    [..]
      +    #######################################
      +  
      +    INCLUDE params.mgmt   
      +  
      +    # params unique to this host here
      +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
      +    ----- end params -----
      +  
      +  
      +    shorewall/rules.mgmt:
      +    ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
      +    ACCEPT $FW          net:$TIME_SERVERS    udp    123
      +    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
      +    ----- end rules.mgmt -----
      +  
      +    shorewall/rules:
      +    # Shorewall version 1.3 - Rules File
      +    [..]
      +    #######################################
      +  
      +    INCLUDE rules.mgmt    
      +  
      +    # rules unique to this host here
      +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
      +    ----- end rules -----
      +  
      + INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives + are ignored with a warning message.
      +
      +
      6. +
    6. Routing traffic from an interface back out that interface continues + to be a problem. While I firmly believe that this should never happen, +people continue to want to do it. To limit the damage that such nonsense +produces, I have added a new 'routeback' option in /etc/shorewall/interfaces +and /etc/shorewall/hosts. When used in /etc/shorewall/interfaces, the 'ZONE' + column may not contain '-'; in other words, 'routeback' can't be used +as an option for a multi-zone interface. The 'routeback' option CAN be +specified however on individual group entries in /etc/shorewall/hosts.
      +  
      + The 'routeback' option is similar to the old 'multi' option with two + exceptions:
      +  
      +    a) The option pertains to a particular zone,interface,address tuple.
      +  
      +    b) The option only created infrastructure to pass traffic from (zone,interface,address) + tuples back to themselves (the 'multi' option affected all (zone,interface,address) + tuples associated with the given 'interface').
      +  
      + See the 'Upgrade Issues' for information + about how this new option may affect your configuration.
      +
      7. + +
    + +

    3/24/2003 - Shorewall 1.4.1

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

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

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

    3/17/2003 - Shorewall 1.4.0

    + Shorewall 1.4 represents + the next step in the evolution of Shorewall. The main thrust of the +initial release is simply to remove the cruft that has accumulated in +Shorewall over time.
    +
    + IMPORTANT: Shorewall 1.4.0 requires the iproute package + ('ip' utility).
    +
    + Function from 1.3 that has been omitted from this version +include:
    + +
      +
    1. The MERGE_HOSTS variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.

      2. -
    2. Support for VLAN devices with names of the form $DEV.$VID - (e.g., eth0.0)
      +
    3. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      4. +
    4. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
      +
      +
      5. +
    5. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified.
      +
      +
      6. +
    6. The Shorewall 1.2 syntax for DNAT and REDIRECT rules +is no longer accepted.
      +
      +
      7. +
    7. The ALLOWRELATED variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.

      8. -
    8. In /etc/shorewall/tcrules, the MARK value may be optionally - followed by ":" and either 'F' or 'P' to designate that the marking -will occur in the FORWARD or PREROUTING chains respectively. If this -additional specification is omitted, the chain used to mark packets -will be determined by the setting of the MARK_IN_FORWARD_CHAIN option -in shorewall.conf.
      +
    9. The icmp.def file has been removed.
      +
      10. + +
    + Changes for 1.4 include:
    + +
      +
    1. The /etc/shorewall/shorewall.conf file has been completely + reorganized into logical sections.

      2. -
    2. When an interface name is entered in the SUBNET column - of the /etc/shorewall/masq file, Shorewall previously masqueraded - traffic from only the first subnet defined on that interface. It did - not masquerade traffic from:
      -  
      -    a) The subnets associated with other addresses on -the interface.
      -    b) Subnets accessed through local routers.
      -  
      - Beginning with Shorewall 1.3.14, if you enter an interface - name in the SUBNET column, shorewall will use the firewall's routing - table to construct the masquerading/SNAT rules.
      -  
      - Example 1 -- This is how it works in 1.3.14.
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      - - - 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      -  
      - When upgrading to Shorewall 1.3.14, if you have multiple - local subnets connected to an interface that is specified in the - SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq - file will need changing. In most cases, you will simply be able to remove - redundant entries. In some cases though, you might want to change from - using the interface name to listing specific subnetworks if the change -described above will cause masquerading to occur on subnetworks that you -don't wish to masquerade.
      -  
      - Example 2 -- Suppose that your current config is as follows:
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq - is no longer required.
      -  
      - Example 3 -- What if your current configuration is like - this?
      -  
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change the entry in  - /etc/shorewall/masq to:
      - - - 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      +
    3. LOG is now a valid action for a rule (/etc/shorewall/rules).
      +
      4. - +
    4. The firewall script and version file are now installed + in /usr/share/shorewall.
      +
      +
      5. +
    5. Late arriving DNS replies are now silently dropped in +the common chain by default.
      +
      +
      6. +
    6. In addition to behaving like OLD_PING_HANDLING=No, Shorewall + 1.4 no longer unconditionally accepts outbound ICMP packets. So if +you want to 'ping' from the firewall, you will need the appropriate +rule or policy.
      +
      +
      7. +
    7. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      8. +
    8. 802.11b devices with names of the form wlan<n> now support + the 'maclist' option.
      +
      +
      9. +
    9. Explicit Congestion Notification (ECN - RFC 3168) may now be + turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
      +
      +    a) You must be running kernel 2.4.20
      +    b) You must have applied the patch in
      +    http://www.shorewall/net/pub/shorewall/ecn/patch.
      +    c) You must have iptables 1.2.7a installed.
      +
      +
      10. +
    10. The /etc/shorewall/params file is now processed first so that + variables may be used in the /etc/shorewall/shorewall.conf file.
      +
      +
      11. +
    11. Shorewall now gives a more helpful diagnostic when + the 'ipchains' compatibility kernel module is loaded and a 'shorewall +start' command is issued.
      +
      +
      12. +
    12. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented + for general use.
      +
      +
      13. +
    13. Shorewall now ignores 'default' routes when detecting masq'd + networks.
      14. +
    - -


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

    - -

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

    - -

    Includes the Beta 2 content plus support for OpenVPN tunnels.

    - -

    1/28/2003 - Shorewall 1.3.14-Beta2

    - -

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

    - -

    1/25/2003 - Shorewall 1.3.14-Beta1
    -

    - -

    The Beta includes the following changes:
    -

    - + +

    3/10/2003 - Shoreall 1.3.14a

    + +

    A roleup of the following bug fixes and other updates:

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

    2/8/2003 - Shoreawall 1.3.14

    + +

    New features include

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


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

    + +

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

    +

    Includes the Beta 2 content plus support for OpenVPN tunnels.

    + +

    1/28/2003 - Shorewall 1.3.14-Beta2

    + +

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

    + +

    1/25/2003 - Shorewall 1.3.14-Beta1
    +

    + +

    The Beta includes the following changes:
    +

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

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

    - -

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

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

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

    1/17/2003 - shorewall.net has MOVED 

    - +

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

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

    +

    1/13/2003 - Shorewall 1.3.13
    -

    - +

    +

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

    - -
      -
    1. A new 'DNAT-' action has been added for entries - in the /etc/shorewall/rules file. DNAT- is intended for advanced - users who wish to minimize the number of rules that connection requests - must traverse.
      -
      - A Shorewall DNAT rule actually generates two iptables - rules: a header rewriting rule in the 'nat' table and an ACCEPT -rule in the 'filter' table. A DNAT- rule only generates the first -of these rules. This is handy when you have several DNAT rules that -would generate the same ACCEPT rule.
      -
      -    Here are three rules from my previous rules file:
      -
      -         DNAT   net  dmz:206.124.146.177 tcp smtp -- 206.124.146.178
      -         DNAT   net  dmz:206.124.146.177 tcp smtp -- 206.124.146.179
      -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
      -
      -    These three rules ended up generating _three_ -copies of
      -
      -          ACCEPT net  dmz:206.124.146.177 tcp smtp
      -
      -    By writing the rules this way, I end up with only - one copy of the ACCEPT rule.
      -
      -         DNAT-  net  dmz:206.124.146.177 tcp smtp --  206.124.146.178
      -         DNAT-  net  dmz:206.124.146.177 tcp smtp --  206.124.146.179
      -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
      -
      -
      2. -
    2. The 'shorewall check' command now prints out - the applicable policy between each pair of zones.
      -
      -
      3. -
    3. A new CLEAR_TC option has been added to shorewall.conf. - If this option is set to 'No' then Shorewall won't clear the current - traffic control rules during [re]start. This setting is intended -for use by people that prefer to configure traffic shaping when the network - interfaces come up rather than when the firewall is started. If that - is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not - supply an /etc/shorewall/tcstart file. That way, your traffic shaping - rules can still use the 'fwmark' classifier based on packet marking defined - in /etc/shorewall/tcrules.
      -
      -
      4. -
    4. A new SHARED_DIR variable has been added that - allows distribution packagers to easily move the shared directory - (default /usr/lib/shorewall). Users should never have a need to -change the value of this shorewall.conf setting.
      -
      5. - -
    - -

    1/6/2003 - BURNOUT -

    - -

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

    - -

    -Tom Eastep
    -

    - -

    12/30/2002 - Shorewall Documentation in PDF Format

    - - -

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

    - - -

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

    - - -

    12/27/2002 - Shorewall 1.3.12 Released

    - -

    Features include:
    -

    +

      -
    1. "shorewall refresh" now reloads the traffic - shaping rules (tcrules and tcstart).
      2. -
    2. "shorewall debug [re]start" now turns off - debugging after an error occurs. This places the point of the - failure near the end of the trace rather than up in the middle -of it.
      3. -
    3. "shorewall [re]start" has been speeded up - by more than 40% with my configuration. Your milage may vary.
      4. -
    4. A "shorewall show classifiers" command has - been added which shows the current packet classification filters. - The output from this command is also added as a separate page - in "shorewall monitor"
      5. -
    5. ULOG (must be all caps) is now accepted -as a valid syslog level and causes the subject packets to be -logged using the ULOG target rather than the LOG target. This -allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages to a separate log file.
      6. -
    6. If you are running a kernel that has a FORWARD - chain in the mangle table ("shorewall show mangle" will show - you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes - in shorewall.conf. This allows - for marking input packets based on their destination even when - you are using Masquerading or SNAT.
      7. -
    7. I have cluttered up the /etc/shorewall directory - with empty 'init', 'start', 'stop' and 'stopped' files. If -you already have a file with one of these names, don't worry -- -the upgrade process won't overwrite your file.
      8. -
    8. I have added a new RFC1918_LOG_LEVEL variable - to shorewall.conf. This variable - specifies the syslog level at which packets are logged as a -result of entries in the /etc/shorewall/rfc1918 file. Previously, -these packets were always logged at the 'info' level.
      +
    9. A new 'DNAT-' action has been added for +entries in the /etc/shorewall/rules file. DNAT- is intended +for advanced users who wish to minimize the number of rules that +connection requests must traverse.
      +
      + A Shorewall DNAT rule actually generates two iptables + rules: a header rewriting rule in the 'nat' table and an ACCEPT + rule in the 'filter' table. A DNAT- rule only generates the first + of these rules. This is handy when you have several DNAT rules +that would generate the same ACCEPT rule.
      +
      +    Here are three rules from my previous rules +file:
      +
      +         DNAT   net  dmz:206.124.146.177 tcp smtp + - 206.124.146.178
      +         DNAT   net  dmz:206.124.146.177 tcp smtp + - 206.124.146.179
      +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
      +
      +    These three rules ended up generating _three_ + copies of
      +
      +          ACCEPT net  dmz:206.124.146.177 tcp smtp
      +
      +    By writing the rules this way, I end up with + only one copy of the ACCEPT rule.
      +
      +         DNAT-  net  dmz:206.124.146.177 tcp smtp + -  206.124.146.178
      +         DNAT-  net  dmz:206.124.146.177 tcp smtp + -  206.124.146.179
      +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
      +
      +
      10. +
    10. The 'shorewall check' command now prints +out the applicable policy between each pair of zones.
      +
      +
      11. +
    11. A new CLEAR_TC option has been added to +shorewall.conf. If this option is set to 'No' then Shorewall +won't clear the current traffic control rules during [re]start. +This setting is intended for use by people that prefer to configure +traffic shaping when the network interfaces come up rather than when +the firewall is started. If that is what you want to do, set TC_ENABLED=Yes + and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. +That way, your traffic shaping rules can still use the 'fwmark' classifier + based on packet marking defined in /etc/shorewall/tcrules.
      +
      +
      12. +
    12. A new SHARED_DIR variable has been added +that allows distribution packagers to easily move the shared directory + (default /usr/lib/shorewall). Users should never have a need +to change the value of this shorewall.conf setting.
    -

    12/20/2002 - Shorewall 1.3.12 Beta 3
    -

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

    12/20/2002 - Shorewall 1.3.12 Beta 2

    - -

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

    - Features include:
    - +

    1/6/2003 - BURNOUT +

    + +

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

    + +

    -Tom Eastep
    +

    + +

    12/30/2002 - Shorewall Documentation in PDF Format

    + + +

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

    + + +

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

    + + +

    12/27/2002 - Shorewall 1.3.12 Released

    + +

    Features include:
    +

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

    12/20/2002 - Shorewall 1.3.12 Beta 3
    +

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

    12/20/2002 - Shorewall 1.3.12 Beta 2

    + +

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

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

    12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux -

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

    12/7/2002 - Shorewall Support for Mandrake 9.0

    - -

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

    - -

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

    +

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

    12/7/2002 - Shorewall Support for Mandrake 9.0

    + + +

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

    + + +

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

    + +

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

    - +

    12/3/2002 - Shorewall 1.3.11a

    - -

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

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

    - +

    11/24/2002 - Shorewall 1.3.11

    - +

    In this version:

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

    11/14/2002 - Shorewall Documentation in PDF Format

    - -

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

    + +

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

    - +

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

    +

    - -

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

    + +

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

    - +

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

    +

    - +

    11/09/2002 - Shorewall 1.3.10

    - +

    In this version:

    - + - +

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

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

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

    10/23/2002 - Shorewall 1.3.10 Beta 1

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

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

    + + +

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

    -

    10/23/2002 - Shorewall 1.3.10 Beta 1

    - In this version:
    +

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

    - - -
      -
    • DNS Names are -now allowed in Shorewall config files (although I recommend against - using them).
      • -
    • The connection -SOURCE may now be qualified by both interface and +
    • DNS Names are + now allowed in Shorewall config files (although I recommend against + using them).
      • +
    • The connection + SOURCE may now be qualified by both interface and IP address in a Shorewall rule.
      • -
    • Shorewall startup - is now disabled after initial installation until the - file /etc/shorewall/startup_disabled is removed. This avoids - nasty surprises during reboot for users who install Shorewall - but don't configure it.
      • -
    • The 'functions' and - 'version' files and the 'firewall' symbolic link have - been moved from /var/lib/shorewall to /usr/lib/shorewall - to appease the LFS police at Debian.
      -
      • +
    • Shorewall startup + is now disabled after initial installation until + the file /etc/shorewall/startup_disabled is removed. This +avoids nasty surprises during reboot for users who install +Shorewall but don't configure it.
      • +
    • The 'functions' +and 'version' files and the 'firewall' symbolic link + have been moved from /var/lib/shorewall to /usr/lib/shorewall + to appease the LFS police at Debian.
      +
      • - +
    - -

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

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

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

    +

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

    9/11/2002 - Debian 1.3.7c Packages Available

    +

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

    +

    9/2/2002 - Shorewall 1.3.7c

    -

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

    + +

    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 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 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 released8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author + -- Shorewall 1.3.7a released -

    +

    -

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

    + +

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

    +

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

    +

    Features in this release include:

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

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

    + +

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

    +

    8/13/2002 - Documentation in the CVS Repository

    -

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

    + +

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

    +

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

    -

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

    + +

    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

    + +

    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.

    + +

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

    +

    8/7/2002 - Shorewall 1.3.6

    +

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

    + - +

    7/30/2002 - Shorewall 1.3.5b Released

    +

    This interim release:

    + - +

    7/29/2002 - New Shorewall Setup Guide Available

    +

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

    +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    -

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

    +

    7/27/2002 - Shorewall 1.3.5a Released

    +

    This interim release restores correct handling of REDIRECT rules.

    +

    7/26/2002 - Shorewall 1.3.5 Released

    -

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

    + +

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

    +

     In this version:

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

    7/16/2002 - New Mirror in Argentina

    -

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

    + +

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

    +

    7/16/2002 - Shorewall 1.3.4 Released

    +

    In this version:

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

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    +

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

    +

    7/6/2002 - Shorewall 1.3.3 Released

    +

    In this version:

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

    6/25/2002 - Samples Updated for 1.3.2

    -

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

    + +

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

    +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    +

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

    +

    6/19/2002 - Documentation Available in PDF Format

    -

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

    + +

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

    +

    6/16/2002 - Shorewall 1.3.2 Released

    +

    In this version:

    + - +

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

    -

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

    + +

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

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

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

    + +

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

    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 The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These problems + have been corrected in the 1.3.1 samples.

    +

    6/1/2002 - Shorewall 1.3.1 Released

    +

    Hot on the heels of 1.3.0, this release:

    + - +

    5/29/2002 - Shorewall 1.3.0 Released

    -

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

    + +

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

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    -

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

    + +

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

    + +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    -

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

    + +

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

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

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    -

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

    + +

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

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

    5/4/2002 - Shorewall 1.2.13 is Available

    +

    In this version:

    + - +

    4/30/2002 - Shorewall Debian News

    -

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

    + +

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

    +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    +

    Lorenzo Marignoni reports that:

    + - +

    Thanks, Lorenzo!

    +

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

    -

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

    + +

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

    +

    4/13/2002 - Shorewall 1.2.11 Available

    +

    In this version:

    + +

    4/13/2002 - Hamburg Mirror now has FTP

    +

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

    + href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.  + Thanks Stefan!

    +

    4/12/2002 - New Mirror in Hamburg

    -

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

    + +

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

    +

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

    -

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

    + +

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

    +

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

    -

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

    + +

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

    +

    4/8/2002 - Parameterized Samples Withdrawn

    +

    Although the parameterized - samples have allowed people to get a firewall - up and running quickly, they have unfortunately -set the wrong level of expectation among those who have -used them. I am therefore withdrawing support for the samples - and I am recommending that they not be used in new Shorewall - installations.

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

    +

    4/2/2002 - Updated Log Parser

    -

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

    + +

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

    +

    3/30/2002 - Shorewall Website Search Improvements

    -

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

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

    + href="http://lists.shorewall.net/mailing_list.htm">mailing list information + page.

    +

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

    + - +

    3/25/2002 - Log Parser Available

    +

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

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

    +

    3/20/2002 - Shorewall 1.2.10 Released

    +

    In this version:

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

    3/11/2002 - Shorewall 1.2.9 Released

    +

    In this version:

    + + + + +

    3/1/2002 - 1.2.8 Debian Package is Available

    + + + +

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

    + + + +

    2/25/2002 - New Two-interface Sample

    + + +

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

    + + +

    2/23/2002 - Shorewall 1.2.8 Released

    + + + +

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

    + + + +

    2/22/2002 - Shorewall 1.2.7 Released

    + + + +

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    + + + +

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

    + + + +

    2/8/2002 - Shorewall 1.2.6 Released

    + + + +

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    + + + +

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

    + + + +

    2/1/2002 - Shorewall 1.2.5 Released

    + + + +

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

    + + + +

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    + + + +

    1/20/2002 - Corrected firewall script available 

    + + + +

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

    + + + +

    1/19/2002 - Shorewall 1.2.3 Released

    + + + +

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

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

    The following problems were corrected:

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

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

    + + + +

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

    + + + +

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

    + + + +

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

    + + + +

    1/8/2002 - Shorewall 1.2.2 Released

    + + + +

    In version 1.2.2

    + + + +
      +
    • Support +for IP blacklisting has been added
        -
      • Filtering - rules (/etc/shorewall/rules)
        • -
      • Traffic -Control Classification Rules (/etc/shorewall/tcrules)
        • -
      • TOS Rules - (/etc/shorewall/tos)
        • -
      • Blacklist - (/etc/shorewall/blacklist)
        • +
      • You specify + whether you want packets from blacklisted hosts +dropped or rejected using the BLACKLIST_DISPOSITION + setting in /etc/shorewall/shorewall.conf
        • +
      • You specify + whether you want packets from blacklisted hosts +logged and at what syslog level using the BLACKLIST_LOGLEVEL +setting in /etc/shorewall/shorewall.conf
        • +
      • You list + the IP addresses/subnets that you wish to blacklist + in /etc/shorewall/blacklist
        • +
      • You specify + the interfaces you want checked against the blacklist + using the new "blacklist" option + in /etc/shorewall/interfaces.
        • +
      • The black + list is refreshed from /etc/shorewall/blacklist by + the "shorewall refresh" command.
        • + +
      +
      • +
    • Use of +TCP RST replies has been expanded  + + + + +
        +
      • TCP connection + requests rejected because of a REJECT policy are + now replied with a TCP RST packet.
        • +
      • TCP connection + requests rejected because of a protocol=all rule + in /etc/shorewall/rules are now replied with a TCP + RST packet.
        • + + + + + +
      +
      • +
    • A LOGFILE specification + has been added to /etc/shorewall/shorewall.conf. LOGFILE is +used to tell the /sbin/shorewall program where to look for +Shorewall messages.
      • + + +
    + - - -
  • Several bugs - have been fixed
    • -
  • The 1.2.9 -Debian Package is also available at http://security.dsi.unimi.it/~lorenzo/debian.html.
    • - - - - - -

    3/1/2002 - 1.2.8 Debian Package is Available

    - - -

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

    - - -

    2/25/2002 - New Two-interface Sample

    - - -

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

    - - -

    2/23/2002 - Shorewall 1.2.8 Released

    - - -

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

    - - -

    2/22/2002 - Shorewall 1.2.7 Released

    - - -

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    - - -

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

    - - -

    2/8/2002 - Shorewall 1.2.6 Released

    - - -

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - - -

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

    - - -

    2/1/2002 - Shorewall 1.2.5 Released

    - - -

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

    - - -

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    - - -

    1/20/2002 - Corrected firewall script available 

    - - -

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

    - - -

    1/19/2002 - Shorewall 1.2.3 Released

    - - -

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

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

    The following problems were corrected:

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

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

    - - -

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

    - - -

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

    - - -

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

    - - -

    1/8/2002 - Shorewall 1.2.2 Released

    - - -

    In version 1.2.2

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

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

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

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

    See the README file for upgrade instructions.

    - +

    1/1/2002 - Shorewall Mailing List Moving

    -

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

    +

    12/31/2001 - Shorewall 1.2.1 Released

    +

    In version 1.2.1:

    - -
      -
    • Logging of Mangled/Invalid - Packets is added. 
      • -
    • The tunnel script has been corrected.
      • -
    • 'shorewall -show tc' now correctly handles tunnels.
      • - + + - -

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

      + +

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

      +

      Version 1.2 contains the following new features:

      - -
        -
      • Support for - Traffic Control/Shaping
        • -
      • Support for - Filtering of Mangled/Invalid - Packets
        • -
      • Support for - GRE Tunnels
        • - + + - -

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

        + +

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

        - -

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

        + +

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

        - -
        + +
        - +

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

        -
        +
        - -

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

        - +

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

        + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample +Configurations has been released. In this version:

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

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

        +

        In this version:

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

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

          -

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

          + +

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

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

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

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

          - -

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

          + +

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

          - +

          In this version:

          - -
            -
          • The handling - of ADD_IP_ALIASES - has been corrected. 
            • - + - -

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

            + +

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

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

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

            + +

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

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

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

            + +

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

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

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

            + +

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

            - +
              -
            • Shell variables - can now be used to parameterize Shorewall rules.
              • -
            • The second -column in the hosts file may now contain a comma-separated - list.
              -
              - Example:
              -     sea    - eth0:130.252.100.0/24,206.191.149.0/24
              • -
            • Handling of - multi-zone interfaces has been improved. See the - documentation for the -/etc/shorewall/interfaces file.
              • +
            • Shell variables + can now be used to parameterize Shorewall rules.
              • +
            • The second + column in the hosts file may now contain a comma-separated + list.
              +
              + Example:
              +     sea    + eth0:130.252.100.0/24,206.191.149.0/24
              • +
            • Handling + of multi-zone interfaces has been improved. See the + documentation for the + /etc/shorewall/interfaces file.
              • - +
            - -

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

            + +

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

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

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

            + +

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

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

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

            + +

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

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

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

            + +

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

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

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

            + +

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

            - + - +

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

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

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

            + +

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

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

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

            + +

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

            - + - -

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

            + +

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

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

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

            + +

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

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

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

            + +

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

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

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

            +

            - +

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

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

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

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

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

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

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

            + +

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

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

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

            + +

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

            - -

            Updated 4/7/2003 - Tom Eastep -

            + +

            Updated 5/10/2003 - Tom Eastep +

            - +

            Copyright © 2001, 2002 Thomas M. Eastep.
            -

            -
            -
            -
            +


            diff --git a/Shorewall-docs/PPTP.htm b/Shorewall-docs/PPTP.htm index cb654149b..6b464faba 100644 --- a/Shorewall-docs/PPTP.htm +++ b/Shorewall-docs/PPTP.htm @@ -1,899 +1,927 @@ - + - + - + - + Shorewall PPTP - + - - - + + - - - + + + +
            +

            PPTP

            -
            - + +

            NOTE: I am no longer attempting to maintain MPPE patches for current +Linux kernel's and pppd. I recommend that you refer to the following URLs +for information about installing MPPE into your kernel and pppd.

            +

            The Linux PPTP client project +has a nice GUI for configuring and managing VPN connections where your +Linux system is the PPTP client. This is what I currently use. I am no longer +running PoPToP but rather I use the PPTP Server included with XP Professional +(see PPTP Server running behind your Firewall +below).

            +    http://pptpclient.sourceforge.net +(Everything you need to run a PPTP client).
            +    http://www.poptop.org (The 'kernelmod' +package can be used to quickly install MPPE into your kernel without rebooting).
            +

            I am leaving the instructions for building MPPE-enabled kernels and pppd +in the text below for those who may wish to obtain the relevant current patches +and "roll their own".
            +

            +

            Shorewall easily supports PPTP in a number of configurations:

            - + - -

            1. PPTP Server Running on your Firewall

            - -

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

            - + +

            1. PPTP Server Running on your +Firewall

            + +

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

            +

            The steps involved are:

            - +
              -
            1. Patching and building pppd
              2. -
            2. Patching and building your Kernel
              3. -
            3. Configuring Samba
              4. -
            4. Configuring pppd
              5. -
            5. Configuring pptpd
              6. -
            6. Configuring Shorewall
              7. - +
            7. Patching and building pppd
              8. +
            8. Patching and building your Kernel
              9. +
            9. Configuring Samba
              10. +
            10. Configuring pppd
              11. +
            11. Configuring pptpd
              12. +
            12. Configuring Shorewall
              13. +
            - +

            Patching and Building pppd

            - -

            To run pppd on a 2.4 kernel, you need the pppd 2.4.1 or later. The primary + +

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

            - +

            You will need the following patches:

            - + - -

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

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

            - + - -

            Un-tar the pppd source and uncompress the patches into one directory (the + +

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

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

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

            - + +

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

            +

            Patching and Building your Kernel

            - +

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

            - + - -

            Uncompress the patch into the same directory where your top-level kernel + +

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

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

            Now configure your kernel. Here is my ppp configuration:

            - -
            + +

            -

            -
            - +

            +
            +

            Configuring Samba

            - -

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

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

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

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

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

            Configuring pppd

            - +

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

            - -
            + +

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

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

            +
            +

            Notes:

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

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

            - -
            + +

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

            -
            - -

            I am the only user who connects to the server but I may connect either -with or without a domain being specified. The system I connect from is my -laptop so I give it the same IP address when tunneled in at it has when I + # client        server    secret    IP addresses
            + CPQTDM\\TEastep *         <shhhhhh> 192.168.1.7
            + TEastep         *         <shhhhhh> 192.168.1.7

            +
            + +

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

            - +

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

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

            Configuring pptpd

            - +

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

            - +

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

            - -
            + +

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

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

            +
            +

            Notes:

            - +
              -
            • I specify the /etc/ppp/options.poptop file as my ppp options file +
            • I specify the /etc/ppp/options.poptop file as my ppp options file (I have several).
              • -
            • The local IP is the same as my internal interface's (192.168.1.254).
              • -
            • I have assigned a remote IP range that overlaps my local network. -This, together with 'proxyarp' in my /etc/ppp/options.poptop file make +
            • The local IP is the same as my internal interface's (192.168.1.254).
              • +
            • I have assigned a remote IP range that overlaps my local network. +This, together with 'proxyarp' in my /etc/ppp/options.poptop file make the remote hosts look like they are part of the local subnetwork.
              • - +
            - +

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

            - -
            + +

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

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

            +
            +

            Configuring Shorewall

            - -

            I consider hosts connected to my PPTP server to be just like local systems. + +

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

            - +

            /etc/shorewall/zones:

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

            /etc/shorewall/interfaces:

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

            /etc/shorewall/hosts:

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

            /etc/shorewall/policy:

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

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

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

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

            -
            +
            + +

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

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


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

            - -

            /etc/shorewall/interfaces:

            - -
            - - + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
            ZONEINTERFACEBROADCASTOPTIONS
            neteth0206.124.146.255noping,norfc1918
            loceth2192.168.1.255 
            locppp0  
            TYPE
            +             		ZONE
            +             		GATEWAY
            +             		GATEWAY ZONE
            +
            pptpserver
            +             		net
            +             		0.0.0.0/0
            +
            +
            -
            - -

            and no entries in /etc/shorewall/hosts.

            - -

            2. PPTP Server Running Behind -your Firewall

            - -

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

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

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

            - -

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

            - -

            3. PPTP Clients Running Behind -your Firewall

            - -

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

            - -
            -

            loadmodule ip_conntrack_pptp
            - loadmodule ip_nat_pptp

            - -

            4. PPTP Client Running on your Firewall.

            - + +


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

            + +

            /etc/shorewall/interfaces:

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

            and no entries in /etc/shorewall/hosts.

            + +

            2. PPTP Server Running Behind +your Firewall

            + +

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

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

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

            + +

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

            + +

            3. PPTP Clients Running Behind +your Firewall

            + +

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

            + +
            +

            loadmodule ip_conntrack_pptp
            + loadmodule ip_nat_pptp

            +
            + +

            4. PPTP Client Running on your +Firewall.

            +

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

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

            +

            The key elements of this setup are as follows:

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

            Here are examples from my setup:

            - +

            /etc/shorewall/zones

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

            /etc/shorewall/interfaces

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

            /etc/shorewall/hosts

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

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

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

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

            -
            +

            + +
            - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
            TYPE
            -             		ZONE
            -             		GATEWAY
            -             		GATEWAY ZONE
            -
            pptpclient
            -             		net
            -             		0.0.0.0/0
            -
            -
            TYPE
            +             		ZONE
            +             		GATEWAY
            +             		GATEWAY ZONE
            +
            pptpclient
            +             		net
            +             		0.0.0.0/0
            +
            +
            -
            -
            -

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

            - -

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

            - -
            +
            +
            + +

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

            + +

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

            + +

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

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

            +
            +

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

            - -
            + +

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

            -
            - -

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

            +
            + +

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

            - -
            + +

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

            -
            - -

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

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

            +
            + +

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

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

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

                 echo "Attempting to restart PPTP"

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

            Here's a script + +

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

            - -

            Last modified 10/23/2002 - Tom Eastep

            - -

            Copyright -© 2001, 2002 Thomas M. Eastep.

            -
            + +

            Last modified 5/15/2003 - Tom Eastep

            + +

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

            +
            +

            diff --git a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html index 25f87fa95..e5f576ad1 100644 --- a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html +++ b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html @@ -2,196 +2,165 @@ Shorewall and Aliased Interfaces - + - + - + - - - + + - - - + + + +
            +

            Shorewall and Aliased Interfaces

            -
            -
            - -

            Background

            - The traditional net-tools contain a program called ifconfig which - is used to configure network devices. ifconfig introduced the concept of - aliased or virtial interfaces. These virtual interfaces have - names of the form interface:integer (e.g., eth0:0) and ifconfig - treats them more or less like real interfaces.
            -
            - Example:
            - -
            [root@gateway root]# ifconfig eth0:0
            eth0:0    Link encap:Ethernet  HWaddr 02:00:08:3:FA:55
                      inet addr:206.124.146.178  Bcast:206.124.146.255  Mask:255.255.255.0
                      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                      Interrupt:11 Base address:0x2000
            [root@gateway root]#
            - The ifconfig utility is being gradually phased out in favor of the ip - utility which is part of the iproute package. The ip utility does - not use the concept of aliases or virtual interfaces but rather treats additional - addresses on an interface as objects. The ip utility does provide for interaction - with ifconfig in that it allows addresses to be labeled and labels -may take the form of ipconfig virtual interfaces.
            -
            - Example:
            -
            - -
            [root@gateway root]# ip addr show dev eth0
            2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
                link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
                inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
                inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
            [root@gateway root]#
            - Note that one cannot type "ip addr show dev eth0:0" because "eth0:0" -is a label for a particular address rather than a device name.
            - -
            [root@gateway root]# ip addr show dev eth0:0
            Device "eth0:0" does not exist.
            [root@gateway root]#
            - The iptables program doesn't support virtual interfaces in either it's - "-i" or "-o" command options; as a consequence, Shorewall does not allow - them to be used in the /etc/shorewall/interfaces file.
            -
            - -

            So how do I handle more than one address on an interface?

            - The answer depends on what you are trying to do with the interfaces. -In the sub-sections that follow, we'll take a look at common scenarios.
            - -

            Separate Rules

            - If you need to make a rule for traffic to/from the firewall itself that -only applies to a particular IP address, simply qualify the $FW zone with -the IP address.
            -
            - Example (allow SSH from net to eth0:0 above):
            -
            - -
            - - - - - - - - - - - - - - - - - - - - - - -
            ACTION
            -             		SOURCE
            -             		DESTINATION
            -             		PROTOCOL
            -             		PORT(S)
            -             		SOURCE PORT(S)
            -             		ORIGINAL DESTINATION
            -
            ACCEPT
            -             		net
            -             		fw:206.124.146.178
            -             		tcp
            -             		22
            -
            -
            -

            -
            - -

            DNAT

            - Suppose that I had set up eth0:0 as above and I wanted to port forward - from that virtual interface to a web server running in my local zone at -192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules -file:
            + +

            Background

            + The traditional net-tools contain a program called ifconfig +which is used to configure network devices. ifconfig introduced the concept +of aliased or virtial interfaces. These virtual interfaces +have names of the form interface:integer (e.g., eth0:0) and +ifconfig treats them more or less like real interfaces.
            +
            + Example:
            + +
            [root@gateway root]# ifconfig eth0:0
            eth0:0    Link encap:Ethernet  HWaddr 02:00:08:3:FA:55
                      inet addr:206.124.146.178  Bcast:206.124.146.255  Mask:255.255.255.0
                      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                      Interrupt:11 Base address:0x2000
            [root@gateway root]#
            + The ifconfig utility is being gradually phased out in favor of the ip + utility which is part of the iproute package. The ip utility does + not use the concept of aliases or virtual interfaces but rather treats +additional addresses on an interface as objects. The ip utility does provide +for interaction with ifconfig in that it allows addresses to be labeled +and labels may take the form of ipconfig virtual interfaces.
            +
            + Example:
            +
            + +
            [root@gateway root]# ip addr show dev eth0
            2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
                link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
                inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
                inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
            [root@gateway root]#
            + Note that one cannot type "ip addr show dev eth0:0" because +"eth0:0" is a label for a particular address rather than a device name.
            + +
            [root@gateway root]# ip addr show dev eth0:0
            Device "eth0:0" does not exist.
            [root@gateway root]#
            + The iptables program doesn't support virtual interfaces in either it's + "-i" or "-o" command options; as a consequence, Shorewall does not allow + them to be used in the /etc/shorewall/interfaces file.
            +
            + +

            So how do I handle more than one address on an interface?

            + The answer depends on what you are trying to do with the interfaces. + In the sub-sections that follow, we'll take a look at common scenarios.
            + +

            Separate Rules

            + If you need to make a rule for traffic to/from the firewall itself that + only applies to a particular IP address, simply qualify the $FW zone with + the IP address.

            - -
            + Example (allow SSH from net to eth0:0 above):
            +
            + +
            - - - - - - - - - - - - + + + + + + + + + + + + + + + + - - - - - - - - - + + +
            ACTION
            -             		SOURCE
            -             		DESTINATION
            -             		PROTOCOL
            -             		PORT(S)
            -             		SOURCE PORT(S)
            -             		ORIGINAL DESTINATION
            -
            DNAT
            +
            ACTION
            +             		SOURCE
            +             		DESTINATION
            +             		PROTOCOL
            +             		PORT(S)
            +             		SOURCE PORT(S)
            +             		ORIGINAL DESTINATION
            +
            ACCEPT
            +             		net
            +             		fw:206.124.146.178
            +             		tcp
            +             		22
            +
            		net
            +
            		loc:192.168.1.3
            -             		tcp
            -             		80
            -             		-
            -             		206.124.146.178
            -

            - + +

            DNAT

            + Suppose that I had set up eth0:0 as above and I wanted to port forward + from that virtual interface to a web server running in my local zone at + 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules + file:
            +
            + +
            + + + + + + + + + + + + + + + + + + + + + + +
            ACTION
            +             		SOURCE
            +             		DESTINATION
            +             		PROTOCOL
            +             		PORT(S)
            +             		SOURCE PORT(S)
            +             		ORIGINAL DESTINATION
            +
            DNAT
            +             		net
            +             		loc:192.168.1.3
            +             		tcp
            +             		80
            +             		-
            +             		206.124.146.178
            +
            +
            +
            +

            SNAT

            - If you wanted to use eth0:0 as the IP address for outbound connections - from your local zone (eth1), then in /etc/shorewall/masq:
            -
            - -
            - - - - - - - - - - - - - - -
            INTERFACE
            -             		SUBNET
            -             		ADDRESS
            -
            eth0
            -             		eth1
            -             		206.124.146.178
            -
            -
            -
            - Shorewall can create the alias (additional address) for you if you set - ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall - 1.3.14, Shorewall can actually create the "label" (virtual interface) so - that you can see the created address using ifconfig. In addition to setting - ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE - column as follows:
            - -
            + If you wanted to use eth0:0 as the IP address for outbound connections + from your local zone (eth1), then in /etc/shorewall/masq:
            +
            + +
            @@ -203,65 +172,56 @@ file:
            - - - + +
            eth0:0
            +             		eth0
            		 eth1
            		 206.124.146.178

            - -

            STATIC NAT

            - If you wanted to use static NAT to link eth0:0 with local address 192.168.1.3, - you would have the following in /etc/shorewall/nat:
            -
            - -
            + Shorewall can create the alias (additional address) for you if you +set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with +Shorewall 1.3.14, Shorewall can actually create the "label" (virtual interface) +so that you can see the created address using ifconfig. In addition to +setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in +the INTERFACE column as follows:
            + +
            - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
            EXTERNAL
            -             		INTERFACE
            -             		INTERNAL
            -             		ALL INTERFACES
            -             		LOCAL
            -
            206.124.146.178
            -             		eth0
            -             		192.168.1.3
            -             		no
            -             		no
            -
            INTERFACE
            +             		SUBNET
            +             		ADDRESS
            +
            eth0:0
            +             		eth1
            +             		206.124.146.178
            +
            -
            -
            - Shorewall can create the alias (additional address) for you if you set - ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall - 1.3.14, Shorewall can actually create the "label" (virtual interface) so - that you can see the created address using ifconfig. In addition to setting - ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE - column as follows:
            -
            - -
            +
            +
            + +

            STATIC NAT

            + If you wanted to use static NAT to link eth0:0 with local address 192.168.1.3, + you would have the following in /etc/shorewall/nat:
            +
            + +
            @@ -279,7 +239,7 @@ file:
            - @@ -288,259 +248,119 @@ file:
            - - + +
            206.124.146.178
            		eth0:0
            +             		eth0
            		 192.168.1.3
            		 no

            -
            - In either case, to create rules that pertain only to this NAT pair, you - simply qualify the local zone with the internal IP address.
            -
            - Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. -192.168.1.3.
            -
            - -
            - - - - - - - - - - - - - - - - - - - - - - -
            ACTION
            -             		SOURCE
            -             		DESTINATION
            -             		PROTOCOL
            -             		PORT(S)
            -             		SOURCE PORT(S)
            -             		ORIGINAL DESTINATION
            -
            ACCEPT
            -             		net
            -             		loc:192.168.1.3
            -             		tcp
            -             		22
            -
            -
            -
            +
            + Shorewall can create the alias (additional address) for you if you +set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with +Shorewall 1.3.14, Shorewall can actually create the "label" (virtual interface) +so that you can see the created address using ifconfig. In addition to +setting ADD_IP_ALIASES=Yes, you specify the virtual interface name in +the INTERFACE column as follows:

            -
            - + +
            + + + + + + + + + + + + + + + + + + +
            EXTERNAL
            +             		INTERFACE
            +             		INTERNAL
            +             		ALL INTERFACES
            +             		LOCAL
            +
            206.124.146.178
            +             		eth0:0
            +             		192.168.1.3
            +             		no
            +             		no
            +
            +
            +
            + In either case, to create rules that pertain only to this NAT pair, +you simply qualify the local zone with the internal IP address.
            +
            + Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. + 192.168.1.3.
            +
            + +
            + + + + + + + + + + + + + + + + + + + + + + +
            ACTION
            +             		SOURCE
            +             		DESTINATION
            +             		PROTOCOL
            +             		PORT(S)
            +             		SOURCE PORT(S)
            +             		ORIGINAL DESTINATION
            +
            ACCEPT
            +             		net
            +             		loc:192.168.1.3
            +             		tcp
            +             		22
            +
            +
            +
            +
            +
            +

            MULTIPLE SUBNETS

            - Sometimes multiple IP addresses are used because there are multiple -subnetworks configured on a LAN segment. This technique does not provide -for any security between the subnetworks if the users of the systems have -administrative privileges because in that case, the users can simply manipulate -their system's routing table to bypass your firewall/router. Nevertheless, -there are cases where you simply want to consider the LAN segment itself + Sometimes multiple IP addresses are used because there are multiple +subnetworks configured on a LAN segment. This technique does not provide +for any security between the subnetworks if the users of the systems have +administrative privileges because in that case, the users can simply manipulate +their system's routing table to bypass your firewall/router. Nevertheless, +there are cases where you simply want to consider the LAN segment itself as a zone and allow your firewall/router to route between the two subnetworks.
            -
            - Example 1:  Local interface eth1 interfaces to 192.168.1.0/24 and - 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0 - is 192.168.20.254. You want to simply route all requests between the two - subnetworks.
            - +
            + Example 1:  Local interface eth1 interfaces to 192.168.1.0/24 +and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and +eth1:0 is 192.168.20.254. You want to simply route all requests between +the two subnetworks.
            +

            If you are running Shorewall 1.4.1 or Later

            - In /etc/shorewall/interfaces:
            - -
            + In /etc/shorewall/interfaces:
            + +
            - - - - - - - - - - - - - - - -
            ZONE
            -             		INTERFACE
            -             		BROADCAST
            -             		OPTIONS
            -
            -
            -             		eth1
            -             		192.168.1.255,192.168.20.255
            -
            -
            -
            -
            - In /etc/shorewall/hosts:
            - -
            - - - - - - - - - - - - - - - - - - - -
            ZONE
            -             		HOSTS
            -             		OPTIONS
            -
            loc
            -             		eth0:192.168.1.0/24
            -
            -
            loc
            -             		eth0:192.168.20.0/24
            -
            -
            -
            -
            - Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall -1.4.1 and later releases default to allowing intra-zone traffic.
            - -

            If you are running Shorewall 1.4.0 or earlier
            -

            - In /etc/shorewall/interfaces:
            -
            - -
            - - - - - - - - - - - - - - - - -
            ZONE
            -             		INTERFACE
            -             		BROADCAST
            -             		OPTIONS
            -
            loc
            -             		eth1
            -             		192.168.1.255,192.168.20.255
            -             		Note 1:
            -
            -
            -
            - Note 1: If you are running Shorewall 1.3.10 or earlier then you must -specify the multi option.
            -
            - In /etc/shorewall/policy:
            -
            - -
            - - - - - - - - - - - - - - - - - - -
            SOURCE
            -             		DESTINATION
            -             		POLICY
            -             		LOG LEVEL
            -             		BURST:LIMIT
            -
            loc
            -             		loc
            -             		ACCEPT
            -
            -
            -
            -
            -
            - Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24. - The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254. - You want to make these subnetworks into separate zones and control the -access between them (the users of the systems do not have administrative -privileges).
            -
            - In /etc/shorewall/zones:
            -
            - -
            - - - - - - - - - - - - - - - - - - - -
            ZONE
            -             		DISPLAY
            -             		DESCRIPTION
            -
            loc
            -             		Local
            -             		Local Zone 1
            -
            loc2
            -             		Local2
            -             		Local Zone 2
            -
            -
            -
            - In /etc/shorewall/interfaces:
            -
            - -
            - - + @@ -558,26 +378,65 @@ privileges).
            - - - + +
            ZONE
            		 192.168.1.255,192.168.20.255
            		Note 1:
            +
            +
            +
            + In /etc/shorewall/hosts:
            + +
            + + + + + + + + + + + + + + + + + + + +
            ZONE
            +             		HOSTS
            +             		OPTIONS
            +
            loc
            +             		eth1:192.168.1.0/24
            +
            +
            loc
            +             		eth1:192.168.20.0/24
            +
            +
            +
            +
            + Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall + 1.4.1 and later releases default to allowing intra-zone traffic.
            + +

            If you are running Shorewall 1.4.0 or earlier
            +

            + In /etc/shorewall/interfaces:

            -
            - Note 1: If you are running Shorewall 1.3.10 or earlier then you must -specify the multi option.
            -
            - In /etc/shorewall/hosts:
            - -
            + +
            - + @@ -585,37 +444,179 @@ specify the multi option.
            - + + + + + +
            ZONE
            		HOSTS
            +             		INTERFACE
            +             		BROADCAST
            		 OPTIONS
            loc
            		eth0:192.168.1.0/24
            +             		eth1
            +             		192.168.1.255,192.168.20.255
            +             		Note 1:
            +
            +
            +
            + Note 1: If you are running Shorewall 1.3.10 or earlier then you must + specify the multi option.
            +
            + In /etc/shorewall/policy:
            +
            + +
            + + + + + + + + + + + + + + + + + +
            SOURCE
            +             		DESTINATION
            +             		POLICY
            +             		LOG LEVEL
            +             		BURST:LIMIT
            +
            loc
            +             		loc
            +             		ACCEPT

            +
            +
            +
            + Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24. + The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254. + You want to make these subnetworks into separate zones and control the +access between them (the users of the systems do not have administrative +privileges).
            +
            + In /etc/shorewall/zones:
            +
            + +
            + + + + + + + + + + + - - - - + +
            ZONE
            +             		DISPLAY
            +             		DESCRIPTION
            +
            loc
            +             		Local
            +             		Local Zone 1
            +
            loc2
            		eth0:192.168.20.0/24
            +             		Local2

            +             		Local Zone 2
            -
            -
            - In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic -that you want to permit.
            -
            - -

            Last Updated 3/27/2003 A - Tom Eastep

            - -

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


            -
            +
            + In /etc/shorewall/interfaces:
            +
            + +
            + + + + + + + + + + + + + + + + +
            ZONE
            +             		INTERFACE
            +             		BROADCAST
            +             		OPTIONS
            +
            -
            +             		eth1
            +             		192.168.1.255,192.168.20.255
            +             		Note 1:
            +
            +
            +
            + Note 1: If you are running Shorewall 1.3.10 or earlier then you must + specify the multi option.
            +
            + In /etc/shorewall/hosts:
            + +
            + + + + + + + + + + + + + + + + + + + +
            ZONE
            +             		HOSTS
            +             		OPTIONS
            +
            loc
            +             		eth1:192.168.1.0/24
            +
            +
            loc2
            +             		eth1:192.168.20.0/24
            +
            +
            +
            +
            + In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic + that you want to permit.
            +
            + +

            Last Updated 5/8/2003 A - Tom Eastep

            + +

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

            +
            +
            +


            diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm index ab62c2261..560b3148e 100644 --- a/Shorewall-docs/Shorewall_index_frame.htm +++ b/Shorewall-docs/Shorewall_index_frame.htm @@ -1,127 +1,122 @@ - + - + - + - + Shorewall Index - + - + - - - + + - - - + + + - - - + + + +
            - +

            Shorewall

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

            Quick Search
            - - -

            -
            - -

            Extended Search

            - +

            Copyright © 2001-2003 Thomas M. Eastep.

            -
            + size="2">2001-2003 Thomas M. Eastep.
            +

            diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm index 03747ca37..11de0abe7 100644 --- a/Shorewall-docs/Shorewall_sfindex_frame.htm +++ b/Shorewall-docs/Shorewall_sfindex_frame.htm @@ -1,125 +1,124 @@ - + - + - + - + Shorewall Index - + + - + - - - + + - - - + + + - - - + + + +
            - +

            Shorewall

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

            Quick Search
            -

            -
            - -

            Extended Search

            - +

            Copyright © 2001-2003 Thomas M. Eastep.
            -

            + size="2">2001-2003 Thomas M. Eastep.

            +
            +
            +

            diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm index cf1ae3431..f9f0bf69e 100644 --- a/Shorewall-docs/configuration_file_basics.htm +++ b/Shorewall-docs/configuration_file_basics.htm @@ -1,346 +1,402 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
            - - +

            Configuration Files

            -
            - -

            Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must - run them through dos2unix + +

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

            - +

            Files

            - +

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

            - +
              -
            • /etc/shorewall/shorewall.conf - used to set +
            • /etc/shorewall/shorewall.conf - used to set several firewall parameters.
              • -
            • /etc/shorewall/params - use this file to set +
            • /etc/shorewall/params - use this file to set shell variables that you will expand in other files.
              • -
            • /etc/shorewall/zones - partition the firewall's +
            • /etc/shorewall/zones - partition the firewall's view of the world into zones.
              • -
            • /etc/shorewall/policy - establishes firewall +
            • /etc/shorewall/policy - establishes firewall high-level policy.
              • -
            • /etc/shorewall/interfaces - describes the interfaces - on the firewall system.
              • -
            • /etc/shorewall/hosts - allows defining zones +
            • /etc/shorewall/interfaces - describes the +interfaces on the firewall system.
              • +
            • /etc/shorewall/hosts - allows defining zones in terms of individual hosts and subnetworks.
              • -
            • /etc/shorewall/masq - directs the firewall -where to use many-to-one (dynamic) Network Address Translation -(a.k.a. Masquerading) and Source Network Address Translation +
            • /etc/shorewall/masq - directs the firewall +where to use many-to-one (dynamic) Network Address Translation +(a.k.a. Masquerading) and Source Network Address Translation (SNAT).
              • -
            • /etc/shorewall/modules - directs the firewall +
            • /etc/shorewall/modules - directs the firewall to load kernel modules.
              • -
            • /etc/shorewall/rules - defines rules that are - exceptions to the overall policies established in /etc/shorewall/policy.
              • -
            • /etc/shorewall/nat - defines static NAT rules.
              • -
            • /etc/shorewall/proxyarp - defines use of Proxy +
            • /etc/shorewall/rules - defines rules that +are exceptions to the overall policies established in /etc/shorewall/policy.
              • +
            • /etc/shorewall/nat - defines static NAT rules.
              • +
            • /etc/shorewall/proxyarp - defines use of Proxy ARP.
              • -
            • /etc/shorewall/routestopped (Shorewall 1.3.4 +
            • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines hosts accessible when Shorewall is stopped.
              • -
            • /etc/shorewall/tcrules - defines marking of +
            • /etc/shorewall/tcrules - defines marking of packets for later use by traffic control/shaping or policy routing.
              • -
            • /etc/shorewall/tos - defines rules for setting +
            • /etc/shorewall/tos - defines rules for setting the TOS field in packet headers.
              • -
            • /etc/shorewall/tunnels - defines IPSEC, GRE +
            • /etc/shorewall/tunnels - defines IPSEC, GRE and IPIP tunnels with end-points on the firewall system.
              • -
            • /etc/shorewall/blacklist - lists blacklisted +
            • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
              • -
            • /etc/shorewall/init - commands that you wish to execute at the +
            • /etc/shorewall/init - commands that you wish to execute at the beginning of a "shorewall start" or "shorewall restart".
              • -
            • /etc/shorewall/start - commands that you wish to execute at the +
            • /etc/shorewall/start - commands that you wish to execute at the completion of a "shorewall start" or "shorewall restart"
              • -
            • /etc/shorewall/stop - commands that you wish to execute at the +
            • /etc/shorewall/stop - commands that you wish to execute at the beginning of a "shorewall stop".
              • -
            • /etc/shorewall/stopped - commands that you wish to execute at +
            • /etc/shorewall/stopped - commands that you wish to execute at the completion of a "shorewall stop".
              • -
            • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN +
            • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN - RFC 3168) to remote hosts or networks.
              -
              • - + +
            - +

            Comments

            - -

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

            - + +

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

            +

            Examples:

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

            Line Continuation

            - -

            You may continue lines in the configuration files using the usual backslash + +

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

            - +

            Example:

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

            INCLUDE Directive

            + Beginning with Shorewall version 1.4.2, any file may contain INCLUDE directives. +An INCLUDE directive consists of the word INCLUDE followed by a file name +and causes the contents of the named file to be logically included into +the file containing the INCLUDE. File names given in an INCLUDE directive +are assumed to reside in /etc/shorewall or in an alternate configuration +directory if one has been specified for the command.
            +
            +INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives + are ignored with a warning message.
            +
            +             Examples:
            + +
               shorewall/params.mgmt:
            + +
               MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
            +    TIME_SERVERS=4.4.4.4
            +    BACKUP_SERVERS=5.5.5.5
            +
            +    ----- end params.mgmt -----
            +
            + +
               shorewall/params:
            +
            + +
            +
               # Shorewall 1.3 /etc/shorewall/params
            +    [..]
            +    #######################################
            +  
            +    INCLUDE params.mgmt   
            +  
            +    # params unique to this host here
            +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
            +
            +
            + +
               ----- end params -----
            +
            + +
               shorewall/rules.mgmt:
            +
            + +
            +
               ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
            +    ACCEPT $FW          net:$TIME_SERVERS    udp    123
            +    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
            +
            +
            + +
               ----- end rules.mgmt -----
            +
            + +
               shorewall/rules:
            +
            + +
            +
               # Shorewall version 1.3 - Rules File
            +    [..]
            +    #######################################
            +  
            +    INCLUDE rules.mgmt    
            +  
            +    # rules unique to this host here
            +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
            +
            +
            + +
               ----- end rules -----
            +

            Using DNS Names

            - +

            - -

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

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

            - +

            +

                -Tom
            -

            - -

            Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified as either IP addresses or DNS +

            + +

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

            - +

            If your firewall rules include DNS names then:

            - +
              -
            • If your /etc/resolv.conf is wrong then your firewall +
            • If your /etc/resolv.conf is wrong then your firewall won't start.
              • -
            • If your /etc/nsswitch.conf is wrong then your firewall +
            • If your /etc/nsswitch.conf is wrong then your firewall won't start.
              • -
            • If your Name Server(s) is(are) down then your firewall +
            • If your Name Server(s) is(are) down then your firewall won't start.
              • -
            • If your startup scripts try to start your firewall +
            • If your startup scripts try to start your firewall before starting your DNS server then your firewall won't start.
              -
              • -
            • Factors totally outside your control (your ISP's router - is down for example), can prevent your firewall from starting.
              • -
            • You must bring up your network interfaces prior to +
              • +
            • Factors totally outside your control (your ISP's +router is down for example), can prevent your firewall from starting.
              • +
            • You must bring up your network interfaces prior to starting your firewall.
              -
              • - + +
            - -

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

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

            +
              -
            • mail.shorewall.net
              • -
            • shorewall.net. (note the trailing period).
              • - +
            • mail.shorewall.net
              • +
            • shorewall.net. (note the trailing period).
              • +
            - Examples of invalid DNS names:
            - + Examples of invalid DNS names:
            +
              -
            • mail (not fully qualified)
              • -
            • shorewall.net (only one period)
              • - +
            • mail (not fully qualified)
              • +
            • shorewall.net (only one period)
              • +
            - DNS names may not be used as:
            - + DNS names may not be used as:
            +
              -
            • The server address in a DNAT rule (/etc/shorewall/rules +
            • The server address in a DNAT rule (/etc/shorewall/rules file)
              • -
            • In the ADDRESS column of an entry in /etc/shorewall/masq.
              • -
            • In the /etc/shorewall/nat file.
              • - +
            • In the ADDRESS column of an entry in /etc/shorewall/masq.
              • +
            • In the /etc/shorewall/nat file.
              • +
            - These restrictions are not imposed by Shorewall simply + These restrictions are not imposed by Shorewall simply for your inconvenience but are rather limitations of iptables.
            - +

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

            - + +

            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:

            - + +

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

            +
              -
            • Must not have any embedded white space.
              - Valid: routefilter,dhcp,norfc1918
              - Invalid: routefilter,     dhcp,     norfc1818
              • -
            • If you use line continuation to break a comma-separated - list, the continuation line(s) must begin in column 1 (or +
            • Must not have any embedded white space.
              + Valid: routefilter,dhcp,norfc1918
              + Invalid: routefilter,     dhcp,     norfc1818
              • +
            • If you use line continuation to break a comma-separated + list, the continuation line(s) must begin in column 1 (or there would be embedded white space)
              • -
            • Entries in a comma-separated list may appear +
            • Entries in a comma-separated list may appear in any order.
              • - +
            - +

            Port Numbers/Service Names

            - -

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

            - + +

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

            +

            Port Ranges

            - -

            If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to + +

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

            - +

            + 
                 DNAT	net	loc:192.168.1.3	tcp	4000:4100
            - If you omit the low port number, a value of zero is assumed; if you omit + If you omit the low port number, a value of zero is assumed; if you omit the high port number, a value of 65535 is assumed.
            - +

            Using Shell Variables

            - -

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

            - + +

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

            +

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

            - +

            Example:

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


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

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

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

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

            - - -
            - + +
            net eth0 130.252.100.255 routefilter,norfc1918
            -
            -             - - -

            Variables may be used anywhere in the other configuration +

            +             +

            Variables may be used anywhere in the other configuration files.

            - +

            Using MAC Addresses

            - -

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

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

            - -

            MAC addresses are 48 bits wide and each Ethernet Controller has a - unique MAC address.
            -
            - In GNU/Linux, MAC addresses are usually written as - a series of 6 hex numbers separated by colons. Example:
            -
            -      [root@gateway root]# ifconfig eth0
            -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
            -      inet addr:206.124.146.176 Bcast:206.124.146.255 - Mask:255.255.255.0
            -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
            -      RX packets:2398102 errors:0 dropped:0 overruns:0 - frame:0
            -      TX packets:3044698 errors:0 dropped:0 overruns:0 - carrier:0
            -      collisions:30394 txqueuelen:100
            -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + +

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

            - -

            Note: It is not necessary to use the special Shorewall notation +

            + +

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

            - +

            +

            Shorewall Configurations

            - -

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

            - -

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

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

            + +

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

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

            Updated 2/24/2003 - Tom Eastep + +

            Updated 4/18/2003 - Tom Eastep

            - - - -

            Copyright + +

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

            +

            +



            diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm index 3fcff27da..c988c73ff 100644 --- a/Shorewall-docs/download.htm +++ b/Shorewall-docs/download.htm @@ -1,185 +1,198 @@ - + - + - + - + Download - + - - - + + - - - + + + +
            +

            Shorewall Download

            -
            - +

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

            - + href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide + for the configuration that most closely matches your own.
            +

            +

            The entire set of Shorewall documentation is available in PDF format at:

            - +

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

            - -

            The documentation in HTML format is included in the .rpm and in the -.tgz packages below.

            - -

            Once you've printed the appropriate QuickStart Guide, download - one of the modules:

            - + +

            The documentation in HTML format is included in the .rpm and in the .tgz +packages below.

            + +

            Once you've printed the appropriate QuickStart Guide, download + one of the modules:

            + - -

            The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.  The - .rpm will install the documentation in your default document directory -which can be obtained using the following command:
            -

            - -
            + +

            The documentation in HTML format is included in the .tgz and .rpm files + and there is an documentation .deb that also contains the documentation.  The + .rpm will install the documentation in your default document directory which + can be obtained using the following command:
            +

            + +

            rpm --eval '%{defaultdocdir}'

            -
            - -

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

            - -

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

            - +
            + +

            Please check the errata + to see if there are updates that apply to the version +that you have downloaded.

            + +

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

            +

            - +

            Download Sites:

            - -
            + +
            - - - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            SERVER LOCATIONDOMAINHTTPFTP
            SourceForge
            -             		sf.net +
            SERVER LOCATIONDOMAINHTTPFTP
            SourceForge
            +             		sf.netBrowseN/A
            Slovak RepublicShorewall.netBrowse Browse
            Texas, USAInfohiiway.comBrowseBrowse
            Hamburg, GermanyShorewall.netBrowseBrowse
            Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
            FranceShorewall.netBrowse Browse
            N/A
            Washington State, USAShorewall.netBrowseBrowseSlovak RepublicShorewall.netBrowse Browse
            Texas, USAInfohiiway.comBrowseBrowse
            Hamburg, GermanyShorewall.netBrowseBrowse
            Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
            FranceShorewall.netBrowse Browse
            Taiwan
            +             		Greshko.com
            +             		Browse
            +             		Browse
            +
            Washington State, USAShorewall.netBrowseBrowse
            -
            - +
            +

            CVS:

            - -
            + +

            The CVS repository - at cvs.shorewall.net contains the latest snapshots of the each - Shorewall component. There's no guarantee that what you find there + href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository + at cvs.shorewall.net contains the latest snapshots of the each + Shorewall component. There's no guarantee that what you find there will work at all.
            -

            -
            - +

            +
            +

            Last Updated 3/24/2003 - Tom Eastep

            - +

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

            +

            +


            diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm index 4ff432746..dcabb59d5 100644 --- a/Shorewall-docs/errata.htm +++ b/Shorewall-docs/errata.htm @@ -1,256 +1,274 @@ - + Shorewall 1.4 Errata - + - + - + - + - + - - - + + - - - + + + +
            +
            +

            Shorewall Errata/Upgrade Issues

            -
            - +

            IMPORTANT

            - +
              -
            1. +

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

              -
              3. -
            3. + it to your Linux system.

              +
              4. +

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

              -
              5. -
            5. + with the one you downloaded below, and then run install.sh.

              +
              6. +

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

              -
              7. -
            7. + firewall script in /usr/share/shorewall/firewall, you +may rename the existing file before copying in the new file.

              +
              8. +

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

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

              + +
            - + - -
            + +

            Problems in Version 1.4

            - +

            - -

            1.4.1a, 1.4.1 and 1.4.0

            -
              -
            • Some TCP requests are rejected in the 'common' chain with an ICMP port-unreachable -response rather than the more appropriate TCP RST response. This problem -is corrected in this updated common.def file which may be installed in /etc/shorewall/common.def.
              -
              • -
            -

            1.4.1

            + +

            1.4.2

              -
            • When a "shorewall check" command is executed, each "rule" produces -the harmless additional message:
              -
              -      /usr/share/shorewall/firewall: line 2174: [: =: unary operator expected
              -
              - You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall -as described above.
              +
            • When an 'add' or 'delete' command is executed, a temporary directory +created in /tmp is not being removed. This problem may be corrected by installing + this firewall script in /usr/share/shorewall/firewall as +described ablve.
            -

            1.4.0

            +

            1.4.1a, 1.4.1 and 1.4.0

              -
            • When running under certain shells Shorewall will attempt to create - ECN rules even when /etc/shorewall/ecn is empty. You may either just remove - /etc/shorewall/ecn or you can install this - correct script in /usr/share/shorewall/firewall as described above.
              +
            • Some TCP requests are rejected in the 'common' chain with an ICMP +port-unreachable response rather than the more appropriate TCP RST response. +This problem is corrected in this updated common.def file which may be installed in +/etc/shorewall/common.def.
            -
            -

            Upgrade Issues

            - -

            The upgrade issues have moved to a separate page.

            - -
            -

            Problem with - iptables version 1.2.3

            - -
            -

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

            - -

            I have built a - corrected 1.2.3 rpm which you can download here  and I have - also built an - iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

            - -

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

            - -

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

            - -

            To install one of the above patches:

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

            Problems with kernels >= 2.4.18 and -RedHat iptables

            - -
            -

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

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

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

            -
            - -

            Problems installing/upgrading - RPM on SuSE

            - -

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

            - -

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

            - -

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

            - -

            Problems with iptables version 1.2.7 and -MULTIPORT=Yes

            - -

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

            +

            1.4.1

              -
            • set MULTIPORT=No - in /etc/shorewall/shorewall.conf; or +
            • When a "shorewall check" command is executed, each "rule" produces + the harmless additional message:
              +
              +      /usr/share/shorewall/firewall: line 2174: [: =: unary operator expected
              +
              + You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall + as described above.
              +
              • + +
            + +

            1.4.0

            + +
              +
            • When running under certain shells Shorewall will attempt to create + ECN rules even when /etc/shorewall/ecn is empty. You may either just remove + /etc/shorewall/ecn or you can install this + correct script in /usr/share/shorewall/firewall as described above.
              +
              • + +
            + +
            +

            Upgrade Issues

            + +

            The upgrade issues have moved to a separate page.

            + +
            +

            Problem with + iptables version 1.2.3

            + +
            +

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

            + +

            I have built a + corrected 1.2.3 rpm which you can download here  and I +have also built an + iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

            + +

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

            + +

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

            + +

            To install one of the above patches:

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

            Problems with kernels >= 2.4.18 and +RedHat iptables

            + +
            +

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

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

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

            +
            + +

            Problems installing/upgrading + RPM on SuSE

            + +

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

            + +

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

            + +

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

            + +

            Problems with iptables version 1.2.7 and + MULTIPORT=Yes

            + +

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

            + + - +

            Problems with RH Kernel 2.4.18-10 and NAT
            -

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

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

            Last updated 3/25/2003 - Tom Eastep + +

            Last updated 5/11/2003 - Tom Eastep

            - +

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

            -
            -
            -
            +


            diff --git a/Shorewall-docs/images/network.png b/Shorewall-docs/images/network.png index fab0fcace..8e07ed5c8 100644 Binary files a/Shorewall-docs/images/network.png and b/Shorewall-docs/images/network.png differ diff --git a/Shorewall-docs/images/network.vsd b/Shorewall-docs/images/network.vsd index 008277007..5af01843c 100644 Binary files a/Shorewall-docs/images/network.vsd and b/Shorewall-docs/images/network.vsd differ diff --git a/Shorewall-docs/mailing_list.htm b/Shorewall-docs/mailing_list.htm index f4769e5cd..2464ee0c2 100644 --- a/Shorewall-docs/mailing_list.htm +++ b/Shorewall-docs/mailing_list.htm @@ -1,140 +1,140 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - - - - +
            +    
            + + + + +
            - +

            Vexira Logo -

            - + - +

             

            -             		+ +

            Shorewall Mailing Lists

            -             		+ (Postfix Logo) -
            - + src="images/postfix-white.gif" align="right" border="0" width="124" + height="66" alt="(Postfix Logo)"> +
            + -
            - + +
            +

            -
            - Powered by Postfix    
            -
            -
            - +

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

            - + read the Shorewall Support + Guide.
            + +

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

            - + let me know

            +

            Not able to Post Mail to shorewall.net?

            - +

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

            - -

            A Word about SPAM Filters A Word about the SPAM Filters at Shorewall.net 

            - -

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

            - + +

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

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

            Please post in plain text

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

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

            - +

            +

            Other Mail Delivery Problems

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

            Mailing Lists Archive Search

            - +
            - -

            Match: + +

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

            - - + Search:

            + +

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

            - +
            +

            Shorewall CA Certificate

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

            Shorewall Users Mailing List

            - +

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

            - + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also posted + to this list.

            +

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

            - + the problem reporting + guidelines.

            +

            To subscribe to the mailing list:
            -

            - +

            + - +

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

            - +

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

            - +

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

            - +

            Shorewall Announce Mailing List

            - +

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

            - + Shorewall community. To subscribe:
            +

            +

            - + - +


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

            - +

            Shorewall Development Mailing List

            - +

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

            - + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

            +

            To subscribe to the mailing list:
            -

            - +

            + - +

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

            - +

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

            - +

            How to Unsubscribe from one of - the Mailing Lists

            - + the Mailing Lists +

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

            - + from Mailman-managed lists although Mailman 2.1 has attempted + to make this less confusing. To unsubscribe:

            +
              -
            • +

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

              -
              • -
            • + to the list.

              +
              • +

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

              -
              • -
            • + " To unsubscribe from <list name>, get a + password reminder, or change your subscription options enter + your subscription email address:". Enter your email address + in the box and click on the "Unsubscribe or edit options" button.

              +
              • +

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

              -
              • - + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.

              + +
            - -
            + +

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

            - +

            Check out these instructions

            - +

            Last updated 3/24/2003 - Tom Eastep

            - +

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

            -
            -
            +



            diff --git a/Shorewall-docs/myfiles.htm b/Shorewall-docs/myfiles.htm index e268df93e..8ccc6e696 100644 --- a/Shorewall-docs/myfiles.htm +++ b/Shorewall-docs/myfiles.htm @@ -1,232 +1,220 @@ - + My Shorewall Configuration - - + - + - + - + - - - + + - - - + + + +
            - +

            About My Network

            -
            - +
            - +

            My Current Network

            - -
            -

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

            -

            Warning 2: My + +

            +

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

            + +

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

            - -

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

            + +

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

            - +

            I use:
            -

            - +

            +
              -
            • Static NAT for Ursa (my XP System) - Internal address +
            • Static NAT for Ursa (my XP System) - Internal address 192.168.1.5 and external address 206.124.146.178.
              • -
            • Static NAT for Wookie (my Linux System). Internal address +
            • Static NAT for Wookie (my Linux System). Internal address 192.168.1.3 and external address 206.124.146.179.
              • -
            • SNAT through the primary gateway address (206.124.146.176) - for  my Wife's system (Tarry) and the laptop when connected through the -Wireless Access Point (wap)
              • - +
            • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (Tarry) and our  laptop (Tipper) which connects +through the Wireless Access Point (wap)
              • +
            - +

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

            - -

            Wookie runs Samba and acts as the a WINS server.  Wookie is in its + +

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

            - -

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

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

            - -

            The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP - server (Pure-ftpd). The system also runs fetchmail to fetch our email + +

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

            - -

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

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

            - -

            All administration and publishing is done using ssh/scp. I have X installed - on both the firewall and the server but no X server or desktop is installed. + +

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

            - +

            I run an SNMP server on my firewall to serve MRTG running + href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG running in the DMZ.

            - +

            -

            - +

            +

             

            - -

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

            - -

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

            - -

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

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

            + +

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

            + +

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

            - +

            +

            -
            - +
            +

            Shorewall.conf

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

            - -

            Params File (Edited):

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

            Zones File

            - + +

            + +

            Params File (Edited):

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

            Zones File

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

            Interfaces File:

            - -
            - -

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

            -
            - -
            + +
            +

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

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

            Hosts File:

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

            Routestopped File:

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

            Policy File:

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

            Masq File:

            - -
            - -

            Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with + +

            +

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

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

            NAT File:

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

            Proxy ARP File:

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

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

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

            Common File:

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

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

            - -
            +
            + +

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

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

            Tom Eastep

            - Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
            -
            -
            -
            -
            -
            + Copyright +© 2001, 2002, 2003 Thomas M. Eastep.
            diff --git a/Shorewall-docs/ping.html b/Shorewall-docs/ping.html index 5bdccb829..47e4a6e2c 100644 --- a/Shorewall-docs/ping.html +++ b/Shorewall-docs/ping.html @@ -2,182 +2,187 @@ ICMP Echo-request (Ping) - + - + - + - - - + + - - - + + + +
            +

            ICMP Echo-request (Ping)

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

            Shorewall Versions >= 1.4.0

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

            Shorewall Versions >= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf

            - In 1.3.14, Ping handling was put under control of the rules and policies - just like any other connection request. In order to accept ping requests -from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need -a rule in /etc/shoreall/rules of the form:
            - -
            ACCEPT    z1    z2    +
            + +

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

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

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

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

            Ping Requests Addressed to the Firewall Itself

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

            Ping Requests Forwarded by the Firewall

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

            Rules Evaluation

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

            Policy Evaluation

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

            Updated 2/14/2003 - Tom Eastep + +

            Updated 5/4/2003 - Tom Eastep

            - +

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

            +



            diff --git a/Shorewall-docs/ports.htm b/Shorewall-docs/ports.htm index d8824ecde..8b23480e1 100644 --- a/Shorewall-docs/ports.htm +++ b/Shorewall-docs/ports.htm @@ -1,204 +1,237 @@ - + Shorewall Port Information - + - + - + - - - - - - + + + + + +
            -

            Ports required for Various - Services/Applications

            -
            +

            Ports required for Various + Services/Applications

            +
            - +

            In addition to those applications described in the /etc/shorewall/rules documentation, here - are some other services/applications that you may need to configure your - firewall to accommodate.

            - + href="Documentation.htm">the /etc/shorewall/rules documentation, here + are some other services/applications that you may need to configure your + firewall to accommodate.

            +

            NTP (Network Time Protocol)

            - -
            + +

            UDP Port 123

            -
            - +
            +

            rdate

            - -
            + +

            TCP Port 37

            -
            - +
            +

            UseNet (NNTP)

            - -
            + +

            TCP Port 119

            -
            - +
            +

            DNS

            - -
            -

            UDP Port 53. If you are configuring a DNS client, you will probably -want to open TCP Port 53 as well.
            - If you are configuring a server, only open TCP Port 53 if you will -return long replies to queries or if you need to enable ZONE transfers. In -the latter case, be sure that your server is properly configured.

            -
            - + +
            +

            UDP Port 53. If you are configuring a DNS client, you will probably want +to open TCP Port 53 as well.
            + If you are configuring a server, only open TCP Port 53 if you will + return long replies to queries or if you need to enable ZONE transfers. In + the latter case, be sure that your server is properly configured.

            +
            +

            ICQ   

            - -
            -

            UDP Port 4000. You will also need to open a range of TCP ports which - you can specify to your ICQ client. By default, clients use 4000-4100.

            -
            - + +
            +

            UDP Port 4000. You will also need to open a range of TCP ports which + you can specify to your ICQ client. By default, clients use 4000-4100.

            +
            +

            PPTP

            - -
            + +

            Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more information here).

            -
            - +
            +

            IPSEC

            - -
            -

            Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port - 500. These should be opened in both directions (Lots more information - here and here).

            -
            - + +
            +

            Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port + 500. These should be opened in both directions (Lots more information + here and here).

            +
            +

            SMTP

            - -
            + +

             TCP Port 25.

            -
            - +
            + +

            RealPlayer
            +

            +
            +

            UDP Port 6790 inbound
            +

            +

            POP3

            - -
            + +

            TCP Port 110.

            -
            - +
            +

            TELNET

            - -
            + +

            TCP Port 23.

            -
            - +
            +

            SSH

            - -
            + +

            TCP Port 22.

            -
            - +
            +

            Auth (identd)

            - -
            + +

            TCP Port 113

            -
            - +
            +

            Web Access

            - -
            + +

            TCP Ports 80 and 443.

            -
            - +
            +

            FTP

            - -
            + +

            Server configuration is covered on in the /etc/shorewall/rules documentation,

            - -

            For a client, you must open outbound TCP port 21 and be sure that your - kernel is compiled to support FTP connection tracking. If you build this - support as a module, Shorewall will automatically load the module from - /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
            -

            - -

            If you run an FTP server on a nonstandard port or you need to access - such a server, then you must specify that port in /etc/shorewall/modules. - For example, if you run an FTP server that listens on port 49 then you would - have:
            -

            - -
            + +

            For a client, you must open outbound TCP port 21 and be sure that your + kernel is compiled to support FTP connection tracking. If you build this + support as a module, Shorewall will automatically load the module from + /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
            +

            + +

            If you run an FTP server on a nonstandard port or you need to access + such a server, then you must specify that port in /etc/shorewall/modules. + For example, if you run an FTP server that listens on port 49 then you would + have:
            +

            + +

            loadmodule ip_conntrack_ftp ports=21,49
            - loadmodule ip_nat_ftp ports=21,49
            -

            -
            - -

            Note that you MUST include port 21 in the ports list or you may - have problems accessing regular FTP servers.

            - -

            If there is a possibility that these modules might be loaded before -Shorewall starts, then you should include the port list in /etc/modules.conf:
            -

            - -
            + loadmodule ip_nat_ftp ports=21,49
            +

            +
            + +

            Note that you MUST include port 21 in the ports list or you may + have problems accessing regular FTP servers.

            + +

            If there is a possibility that these modules might be loaded before Shorewall +starts, then you should include the port list in /etc/modules.conf:
            +

            + +

            options ip_conntrack_ftp ports=21,49
            - options ip_nat_ftp ports=21,49
            -

            -
            + options ip_nat_ftp ports=21,49
            +

            - + +

            IMPORTANT: Once you have made these changes to /etc/shorewall/modules + and/or /etc/modules.conf, you must either:
            +

            + +
              +
            1. Unload the modules and restart shorewall: (rmmod ip_nat_ftp; rmmod ip_conntrack_ftp; shorewall restart); + or
              2. +
            2. Reboot
              +
              3. + +
            + +

            +
            + +
            +

            SMB/NMB (Samba/Windows Browsing/File Sharing)

            - +
            - -
            + +

            TCP Ports 137, 139 and 445.
            - UDP Ports 137-139.
            -
            - Also, see this page.

            -
            - + UDP Ports 137-139.
            +
            + Also, see this page.

            +
            +

            Traceroute

            - -
            + +

            UDP ports 33434 through 33434+<max number of hops>-1

            -
            - +
            +

            NFS
            -

            - -
            -

            I personally use the following rules for opening access from zone z1 -to a server with IP address a.b.c.d in zone z2:
            -

            - +

            + +
            +

            I personally use the following rules for opening access from zone z1 + to a server with IP address a.b.c.d in zone z2:
            +

            + 
            ACCEPT	z1	z2:a.b.c.d	udp	111
            ACCEPT	z1	z2:a.b.c.d	tcp	111
            ACCEPT	z1	z2:a.b.c.d	udp	2049
            ACCEPT	z1	z2:a.b.c.d	udp	32700:
            -
            - -
            -

            Note that my rules only cover NFS using UDP (the normal case). There -is lots of additional information at  + +

            +

            Note that my rules only cover NFS using UDP (the normal case). There + is lots of additional information at  http://nfs.sourceforge.net/nfs-howto/security.html

            -
            - -

            Didn't find what you are looking for -- have you looked in your own -/etc/services file?

            - +
            + +

            VNC
            +

            + +
            +

            TCP port 5900 + <display number>

            +
            + +

            Didn't find what you are looking for -- have you looked in your own /etc/services + file?

            +

            Still looking? Try http://www.networkice.com/advice/Exploits/Ports

            - -

            Last updated 2/25/2003 - Last updated 5/5/2003 - Tom Eastep

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



            diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index 07c9aedb5..ef4105bdf 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -1,268 +1,373 @@ - + + Shoreline Firewall (Shorewall) 1.4 - + + - + - - - + + + - - - + + + +
            - +
            + +

            Shorwall Logo - (Shorewall Logo) -

            - + - -
            -

                         Shorewall 1.4 + + +

            Shorewall 1.4 "iptables made easy"
            - Shorewall 1.3 Site is here
            - Shorewall 1.2 Site is here
            +
            + + +

            +

            + - - -

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

            What is it?

            - + + +

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

            - + + +

            This program is free software; you can redistribute it and/or modify - it under -the terms of Version 2 of the GNU General Public License as published by the Free Software Foundation.
            -
            - This program - is distributed in the hope that it will - be useful, but WITHOUT ANY WARRANTY; without - even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details.
            -
            - You should have - received a copy of the GNU General Public - License along with this program; if - not, write to the Free Software Foundation, - Inc., 675 Mass Ave, Cambridge, MA 02139, USA

            - +
            + This + program is distributed in the hope that + it will be useful, but WITHOUT ANY WARRANTY; + without even the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. See +the GNU General Public License for more details.
            +
            + You +should have received a copy of the GNU General + Public License along with this program; + if not, write to the Free Software Foundation, + Inc., 675 Mass Ave, Cambridge, MA 02139, + USA

            + + +

            Copyright 2001, 2002, 2003 Thomas M. Eastep

            - -

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

            - -

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

            - -

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

            - + + + + + + + +


            +Getting Started with Shorewall

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

            News

            - -

            4/12/2002 - Greater Seattle Linux Users Group Presentation 5/10/2003 - Shorewall Mirror in Asia (New) +
            +

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

            5/8/2003 - Shorewall Mirror in Chile (New) +  

            + +

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

            + +

            4/26/2003 - lists.shorewall.net Downtime (New) -

            +

            + +

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

            + +

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

            + +

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

            + + +

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

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

            4/9/2003 - Shorewall 1.4.2 (New) -
            -

            - -

                Problems Corrected:

            - -
            +
            +

            + + +

            Problems Corrected:

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

                New Features:

            - -
            +
            + + +

            New Features:

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

            - +
            + + + +

            More News

            - + + +

            (Leaf Logo) + Jacques + Nilo and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that +features Shorewall-1.3.14 and Kernel-2.4.20. + You can find their work at: http://leaf.sourceforge.net/devel/jnilo
            + +

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

            Donations

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

            Quick Search
            +

            +
            + +

            Extended Search

            +
            +
            -
            -
            - +
            +
            + - - - + + - - - + to + Starlight +Children's Foundation. Thanks!

            + + + + +
            - +
            + +

            -

            - +

            + + +

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

            -
            - -

            Updated 4/12/2003 - Tom Eastep -
            -

            -
            -
            -
            -
            + +

            Updated 5/12/2003 - Tom Eastep +
            +

            diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm index c6c6905b6..48b7e9a8e 100644 --- a/Shorewall-docs/shoreline.htm +++ b/Shorewall-docs/shoreline.htm @@ -1,128 +1,141 @@ - + About the Shorewall Author - - + - + - + - + - - - + + - - - + + + +
            - +
            +

            Tom Eastep

            -
            - +

            Tom on the PCT - 1991 -

            - +

            +

            Tarry & Tom -- August 2002
            -
            -

            - +
            +

            + - -

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

            - + +

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

            +

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

            - + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known + as Seattle Firewall. + Expanding on what I learned from Seattle Firewall, I then designed + and wrote Shorewall.

            +

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

            - +

            Our current home network consists of:

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

            For more about our network see my Shorewall Configuration.

            - +

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

            - +

            - - - - Powered by Mandrake - Protected by Shorewall -

            - -

            Last updated 3/17/2003 - Protected by Shorewall + (Opera Logo) +   +

            + +

            Last updated 5/8/2003 - Tom Eastep

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



            diff --git a/Shorewall-docs/shorewall_mirrors.htm b/Shorewall-docs/shorewall_mirrors.htm index a7e022b62..4ec6a248f 100644 --- a/Shorewall-docs/shorewall_mirrors.htm +++ b/Shorewall-docs/shorewall_mirrors.htm @@ -1,86 +1,91 @@ - + - + - + - + Shorewall Mirrors - + - - - + + - - - + + + +
            +

            Shorewall Mirrors

            -
            - -

            Remember that updates to the mirrors are often delayed - for 6-12 hours after an update to the primary rsync site. For HTML content, -the main web site (http://shorewall.sf.net) + +

            Remember that updates to the mirrors are often delayed + for 6-12 hours after an update to the primary rsync site. For HTML content, +the main web site (http://shorewall.sf.net) is updated at the same time as the rsync site.

            - +

            The main Shorewall Web Site is http://shorewall.sf.net + href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net and is located in California, USA. It is mirrored at:

            - + - +

            The rsync site is mirrored via FTP at:

            - + - Search results and the mailing list archives are always fetched from the + Search results and the mailing list archives are always fetched from the site in Washington State.
            - -

            Last Updated 3/7/2003 - Last Updated 5/8/2003 - Tom Eastep

            - +

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

            -
            +
            +



            diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm index 5b59ae3d1..480b4ce68 100644 --- a/Shorewall-docs/shorewall_quickstart_guide.htm +++ b/Shorewall-docs/shorewall_quickstart_guide.htm @@ -1,288 +1,297 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - - - - + + + + + +
            -

            Shorewall QuickStart Guides - (HOWTO's)
            - Version 4.0

            -
            + +

            Shorewall QuickStart Guides + (HOWTO's)
            + Version 4.0

            +
            - -

            With thanks to Richard who reminded me once again that we -must all first walk before we can run.
            - The French Translations are courtesy of Patrice Vetsel
            -

            - + +

            With thanks to Richard who reminded me once again that +we must all first walk before we can run.
            + The French Translations are courtesy of Patrice Vetsel
            +

            +

            The Guides

            - -

            These guides provide step-by-step instructions for configuring Shorewall - in common firewall setups.

            - + +

            These guides provide step-by-step instructions for configuring Shorewall + in common firewall setups.

            +

            The following guides are for users who have a single public IP address:

            - + - -

            The above guides are designed to get your first firewall up and running - quickly in the three most common Shorewall configurations.

            - -

            The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple - public IP addresses involved or if you want to learn more about - Shorewall than is explained in the single-address guides above.

            - + +

            The above guides are designed to get your first firewall up and running + quickly in the three most common Shorewall configurations.

            + +

            The Shorewall Setup Guide (See + Index Below) outlines the steps necessary to set up a firewall + where there are multiple public IP addresses involved or +if you want to learn more about Shorewall than is explained in +the single-address guides above.

            + - +

            Documentation Index

            - -

            The following documentation covers a variety of topics and supplements - the QuickStart Guides - described above. Please review the appropriate guide before -trying to use this documentation directly.

            - + +

            The following documentation covers a variety of topics and supplements + the QuickStart Guides + described above. Please review the appropriate guide before + trying to use this documentation directly.

            + - +

            If you use one of these guides and have a suggestion for improvement please let me know.

            - -

            Last modified 4/112003 - Tom Eastep

            - -

            Copyright 2002, 2003 Thomas M. - Eastep
            -

            + +

            Last modified 5/03/2003 - Tom Eastep

            + +

            Copyright 2002, 2003 Thomas M. + Eastep
            +

            +
            +


            diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index 1b79a0265..a4e291505 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -1,2531 +1,2535 @@ - + - + - + - + Shorewall Setup Guide - + - +

            Shorewall Setup Guide

            - +

            1.0 Introduction
            - 2.0 Shorewall Concepts
            - 3.0 Network Interfaces
            - 4.0 Addressing, Subnets and Routing

            - -
            + 2.0 Shorewall Concepts
            + 3.0 Network Interfaces
            + 4.0 Addressing, Subnets and Routing

            + +

            4.1 IP Addresses
            - 4.2 Subnets
            - 4.3 Routing
            - 4.4 Address Resolution Protocol
            - 4.5 RFC 1918

            -
            - + 4.2 Subnets
            + 4.3 Routing
            + 4.4 Address Resolution Protocol (ARP)
            + 4.5 RFC 1918

            +
            +

            5.0 Setting up your Network

            - -
            + +

            5.1 Routed
            - 5.2 Non-routed

            - -
            + 5.2 Non-routed

            + +

            5.2.1 SNAT
            - 5.2.2 DNAT
            - 5.2.3 Proxy ARP
            - 5.2.4 Static NAT

            -
            - + 5.2.2 DNAT
            + 5.2.3 Proxy ARP
            + 5.2.4 Static NAT

            +
            +

            5.3 Rules
            - 5.4 Odds and Ends

            -
            - + 5.4 Odds and Ends

            +
            +

            6.0 DNS
            - 7.0 Starting and Stopping the Firewall

            - + 7.0 Starting and Stopping the Firewall

            +

            1.0 Introduction

            - -

            This guide is intended for users who are setting up Shorewall in an environment - where a set of public IP addresses must be managed or who want to know + +

            This guide is intended for users who are setting up Shorewall in an environment + where a set of public IP addresses must be managed or who want to know more about Shorewall than is contained in the single-address guides. Because - the range of possible applications is so broad, the Guide will give you - general guidelines and will point you to other resources as necessary.

            - + href="shorewall_quickstart_guide.htm">single-address guides. Because + the range of possible applications is so broad, the Guide will give +you general guidelines and will point you to other resources as necessary.

            +

            -     If you run LEAF Bering, your Shorewall configuration is NOT -what I release -- I suggest that you consider installing a stock Shorewall +     If you run LEAF Bering, your Shorewall configuration is NOT +what I release -- I suggest that you consider installing a stock Shorewall lrp from the shorewall.net site before you proceed.

            - -

            Shorewall requires that the iproute/iproute2 package be installed (on - RedHat, the package is called iproute). You can tell if - this package is installed by the presence of an ip program on your - firewall system. As root, you can use the 'which' command to check for + +

            Shorewall requires that the iproute/iproute2 package be installed (on + RedHat, the package is called iproute). You can tell if +this package is installed by the presence of an ip program on your + firewall system. As root, you can use the 'which' command to check for this program:

            - + 
                 [root@gateway root]# which ip
                 /sbin/ip
                 [root@gateway root]#
            - -

            I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are flagged + +

            I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged with - .

            - + .

            +

            -     If you edit your configuration files on a Windows system, you - must save them as Unix files if your editor supports that option or you - must run them through dos2unix before trying to use them with Shorewall. - Similarly, if you copy a configuration file from your Windows hard drive - to a floppy disk, you must run dos2unix against the copy before using +     If you edit your configuration files on a Windows system, +you must save them as Unix files if your editor supports that option +or you must run them through dos2unix before trying to use them with Shorewall. + Similarly, if you copy a configuration file from your Windows hard drive + to a floppy disk, you must run dos2unix against the copy before using it with Shorewall.

            - + - +

            2.0 Shorewall Concepts

            - -

            The configuration files for Shorewall are contained in the directory -/etc/shorewall -- for most setups, you will only need to deal with a few -of these as described in this guide. Skeleton files are created during the -Shorewall Installation Process.

            - -

            As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions + +

            The configuration files for Shorewall are contained in the directory /etc/shorewall +-- for most setups, you will only need to deal with a few of these as described +in this guide. Skeleton files are created during the Shorewall Installation Process.

            + +

            As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions and some contain default entries.

            - -

            Shorewall views the network where it is running as being composed of a - set of zones. In the default installation, the following zone + +

            Shorewall views the network where it is running as being composed of a + set of zones. In the default installation, the following zone names are used:

            - + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
            NameDescription
            NameDescription
            netThe Internet
            locYour Local Network
            dmzDemilitarized Zone
            netThe Internet
            locYour Local Network
            dmzDemilitarized Zone
            - -

            Zones are defined in the /etc/shorewall/zones + +

            Zones are defined in the /etc/shorewall/zones file.

            - -

            Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed in -the /etc/shorewall/shorewall.conf + +

            Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw but that may be changed in +the /etc/shorewall/shorewall.conf file. In this guide, the default name (fw) will be used.

            - -

            With the exception of fw, Shorewall attaches absolutely no meaning - to zone names. Zones are entirely what YOU make of them. That means that - you should not expect Shorewall to do something special "because this - is the internet zone" or "because that is the DMZ".

            - + +

            With the exception of fw, Shorewall attaches absolutely no meaning + to zone names. Zones are entirely what YOU make of them. That means +that you should not expect Shorewall to do something special "because +this is the internet zone" or "because that is the DMZ".

            +

            -     Edit the /etc/shorewall/zones file and make any changes necessary.

            - -

            Rules about what traffic to allow and what traffic to deny are expressed +     Edit the /etc/shorewall/zones file and make any changes necessary.

            + +

            Rules about what traffic to allow and what traffic to deny are expressed in terms of zones.

            - + - -

            Shorewall is built on top of the Netfilter + +

            Shorewall is built on top of the Netfilter kernel facility. Netfilter implements a connection - tracking function that allows what is often referred to as stateful - inspection of packets. This stateful property allows firewall rules - to be defined in terms of connections rather than in terms of + href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html">connection + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms of packets. With Shorewall, you:

            - +
              -
            1. Identify the source zone.
              2. -
            2. Identify the destination zone.
              3. -
            3. If the POLICY from the client's zone to the server's - zone is what you want for this client/server pair, you need do -nothing further.
              4. -
            4. If the POLICY is not what you want, then you must -add a rule. That rule is expressed in terms of the client's zone +
            5. Identify the source zone.
              6. +
            6. Identify the destination zone.
              7. +
            7. If the POLICY from the client's zone to the server's + zone is what you want for this client/server pair, you need do nothing + further.
              8. +
            8. If the POLICY is not what you want, then you must +add a rule. That rule is expressed in terms of the client's zone and the server's zone.
              9. - +
            - -

            Just because connections of a particular type are allowed from zone A -to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed - from zone A to zone B. It rather means that you can -have a proxy running on the firewall that accepts a connection from zone -A and then establishes its own separate connection from the firewall to -zone B.

            - -

            For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  + +

            Just because connections of a particular type are allowed from zone +A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed + from zone A to zone B. It rather means that you can +have a proxy running on the firewall that accepts a connection from +zone A and then establishes its own separate connection from the firewall +to zone B.

            + +

            For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  the request is first checked against the rules in /etc/shorewall/common.def.

            - +

            The default /etc/shorewall/policy file has the following policies:

            - -
            + +
            - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
            Source ZoneDestination ZonePolicyLog LevelLimit:Burst
            Source ZoneDestination ZonePolicyLog LevelLimit:Burst
            locnetACCEPT  
            netallDROPinfo 
            allallREJECTinfo 
            locnetACCEPT  
            netallDROPinfo 
            allallREJECTinfo 
            -
            - +
            +

            The above policy will:

            - +
              -
            1. allow all connection requests from your local network to +
            2. allow all connection requests from your local network to the internet
              3. -
            3. drop (ignore) all connection requests from the internet to - your firewall or local network and log a message at the info - level (here is a description of log +
            4. drop (ignore) all connection requests from the internet +to your firewall or local network and log a message at the info + level (here is a description of log levels).
              5. -
            5. reject all other connection requests and log a message at -the info level. When a request is rejected, the firewall -will return an RST (if the protocol is TCP) or an ICMP port-unreachable +
            6. reject all other connection requests and log a message at +the info level. When a request is rejected, the firewall +will return an RST (if the protocol is TCP) or an ICMP port-unreachable packet for other protocols.
              7. - +
            - +

            -     At this point, edit your /etc/shorewall/policy and make any +     At this point, edit your /etc/shorewall/policy and make any changes that you wish.

            - +

            3.0 Network Interfaces

            - -

            For the remainder of this guide, we'll refer to the following - diagram. While it may not look like your own network, it can be used + +

            For the remainder of this guide, we'll refer to the following + diagram. While it may not look like your own network, it can be used to illustrate the important aspects of Shorewall configuration.

            - +

            In this diagram:

            - +
              -
            • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is - used to isolate your internet-accessible servers from your local systems - so that if one of those servers is compromised, you still have the firewall - between the compromised system and your local systems.
              • -
            • The Local Zone consists of systems Local 1, Local 2 and Local - 3.
              • -
            • All systems from the ISP outward comprise the Internet Zone. +
            • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ +is used to isolate your internet-accessible servers from your local +systems so that if one of those servers is compromised, you still have +the firewall between the compromised system and your local systems.
              • +
            • The Local Zone consists of systems Local 1, Local 2 and +Local 3.
              • +
            • All systems from the ISP outward comprise the Internet Zone.
              • - +
            - +

            -

            - -

            The simplest way to define zones is to simply associate the - zone name (previously defined in /etc/shorewall/zones) with a network +

            + +

            The simplest way to define zones is to simply associate the + zone name (previously defined in /etc/shorewall/zones) with a network interface. This is done in the /etc/shorewall/interfaces file.

            - -

            The firewall illustrated above has three network interfaces. - Where Internet connectivity is through a cable or DSL "Modem", the External - Interface will be the Ethernet adapter that is connected to that -"Modem" (e.g., eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect -via a regular modem, your External Interface will also be ppp0. + +

            The firewall illustrated above has three network interfaces. + Where Internet connectivity is through a cable or DSL "Modem", the External + Interface will be the Ethernet adapter that is connected to that +"Modem" (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect +via a regular modem, your External Interface will also be ppp0. If you connect using ISDN, you external interface will be ippp0.

            - +

            -     If your external interface is ppp0 or ippp0 then +     If your external interface is ppp0 or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

            - -

            Your Local Interface will be an Ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local computers - will be connected to the same switch (note: If you have only a single - local system, you can connect the firewall directly to the computer using + +

            Your Local Interface will be an Ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local computers + will be connected to the same switch (note: If you have only a single + local system, you can connect the firewall directly to the computer using a cross-over cable).

            - -

            Your DMZ Interface will also be an Ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ - computers will be connected to the same switch (note: If you have only - a single DMZ system, you can connect the firewall directly to the computer - using a cross-over cable).

            - + +

            Your DMZ Interface will also be an Ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your +DMZ computers will be connected to the same switch (note: If you have +only a single DMZ system, you can connect the firewall directly to the +computer using a cross-over cable).

            +

            - Do not connect more than one interface to the same hub -or switch (even for testing). It won't work the way that you expect -it to and you will end up confused and believing that Linux networking -doesn't work at all.

            - +             Do not connect more than one interface to the same hub +or switch (even for testing). It won't work the way that you expect it +to and you will end up confused and believing that Linux networking doesn't + work at all.

            +

            For the remainder of this Guide, we will assume that:

            - +
              -
            • +

            • The external interface is eth0.

              -
              • -
            • +
              • +

            • The Local interface is eth1.

              -
              • -
            • +
              • +

            • The DMZ interface is eth2.

              -
              • - + +
            - -

            The Shorewall default configuration does not define the contents - of any zone. To define the above configuration using the /etc/shorewall/interfaces + +

            The Shorewall default configuration does not define the contents + of any zone. To define the above configuration using the /etc/shorewall/interfaces file, that file would might contain:

            - -
            + +
            - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
            ZoneInterfaceBroadcastOptions
            ZoneInterfaceBroadcastOptions
            neteth0detectnorfc1918
            loceth1detect 
            dmzeth2detect 
            neteth0detectnorfc1918
            loceth1detect 
            dmzeth2detect 
            -
            - +
            +

            -     Edit the /etc/shorewall/interfaces file and define the network - interfaces on your firewall and associate each interface with a zone. - If you have a zone that is interfaced through more than one interface, -simply include one entry for each interface and repeat the zone name as +     Edit the /etc/shorewall/interfaces file and define the network + interfaces on your firewall and associate each interface with a zone. + If you have a zone that is interfaced through more than one interface, +simply include one entry for each interface and repeat the zone name as many times as necessary.

            - +

            Example:

            - -
            + +
            - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
            ZoneInterfaceBroadcastOptions
            ZoneInterfaceBroadcastOptions
            neteth0detectnorfc1918
            loceth1detect 
            loceth2detectdhcp
            neteth0detectnorfc1918
            loceth1detect 
            loceth2detectdhcp
            -
            - -
            -

            When you have more than one interface to a zone, you will +

            + +
            +

            When you have more than one interface to a zone, you will usually want a policy that permits intra-zone traffic:

            -
            - -
            -
            +
            + +
            +
            - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
            Source ZoneDestination ZonePolicyLog LevelLimit:Burst
            loclocACCEPT  
            Source ZoneDestination ZonePolicyLog LevelLimit:Burst
            loclocACCEPT  
            -
            -
            - +
            + +

            -     You may define more complicated zones using the /etc/shorewall/hosts file but in most +     You may define more complicated zones using the /etc/shorewall/hosts file but in most cases, that isn't necessary.

            - +

            4.0 Addressing, Subnets and Routing

            - -

            Normally, your ISP will assign you a set of Public - IP addresses. You will configure your firewall's external interface to - use one of those addresses permanently and you will then have to decide - how you are going to use the rest of your addresses. Before we tackle that - question though, some background is in order.

            - -

            If you are thoroughly familiar with IP addressing and routing, + +

            Normally, your ISP will assign you a set of Public + IP addresses. You will configure your firewall's external interface to + use one of those addresses permanently and you will then have to decide + how you are going to use the rest of your addresses. Before we tackle +that question though, some background is in order.

            + +

            If you are thoroughly familiar with IP addressing and routing, you may go to the next section.

            - -

            The following discussion barely scratches the surface of addressing -and routing. If you are interested in learning more about this subject, -I highly recommend "IP Fundamentals: What Everyone Needs to Know about -Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN -0-13-975483-0.

            - + +

            The following discussion barely scratches the surface of +addressing and routing. If you are interested in learning more about this +subject, I highly recommend "IP Fundamentals: What Everyone Needs to +Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, + 1999, ISBN 0-13-975483-0.

            +

            4.1 IP Addresses

            - -

            IP version 4 (IPv4) addresses are 32-bit numbers. - The notation w.x.y.z refers to an address where the high-order byte has - value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + +

            IP version 4 (IPv4) addresses are 32-bit numbers. + The notation w.x.y.z refers to an address where the high-order byte has + value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 and express it in hexadecimal, we get:

            - -
            + +

            C0.00.02.0E

            -
            - +
            +

            or looking at it as a 32-bit integer

            - -
            + +

            C000020E

            -
            - +
            +

            4.2 Subnets

            - -

            You will still hear the terms "Class A network", "Class B - network" and "Class C network". In the early days of IP, networks only - came in three sizes (there were also Class D networks but they were used + +

            You will still hear the terms "Class A network", "Class B + network" and "Class C network". In the early days of IP, networks only + came in three sizes (there were also Class D networks but they were used differently):

            - -
            + +

            Class A - netmask 255.0.0.0, size = 2 ** 24

            - +

            Class B - netmask 255.255.0.0, size = 2 ** 16

            - +

            Class C - netmask 255.255.255.0, size = 256

            -
            - -

            The class of a network was uniquely determined by the value - of the high order byte of its address so you could look at an IP address - and immediately determine the associated netmask. The netmask -is a number that when logically ANDed with an address isolates the network - number; the remainder of the address is the host number. For - example, in the Class C address 192.0.2.14, the network number is hex -C00002 and the host number is hex 0E.

            - -

            As the internet grew, it became clear that such a gross -partitioning of the 32-bit address space was going to be very limiting (early - on, large corporations and universities were assigned their own class A - network!). After some false starts, the current technique of subnetting - these networks into smaller subnetworks evolved; that technique is -referred to as Classless InterDomain Routing (CIDR). Today, any system -that you are likely to work with will understand CIDR and Class-based networking +

            + +

            The class of a network was uniquely determined by the value + of the high order byte of its address so you could look at an IP address + and immediately determine the associated netmask. The netmask +is a number that when logically ANDed with an address isolates the network + number; the remainder of the address is the host number. +For example, in the Class C address 192.0.2.14, the network number is +hex C00002 and the host number is hex 0E.

            + +

            As the internet grew, it became clear that such a gross partitioning +of the 32-bit address space was going to be very limiting (early on, large +corporations and universities were assigned their own class A network!). +After some false starts, the current technique of subnetting these +networks into smaller subnetworks evolved; that technique is referred +to as Classless InterDomain Routing (CIDR). Today, any system that + you are likely to work with will understand CIDR and Class-based networking is largely a thing of the past.

            - -

            A subnetwork (often referred to as a subnet) is + +

            A subnetwork (often referred to as a subnet) is a contiguous set of IP addresses such that:

            - +
              -
            1. +

            2. The number of addresses in the set is a power of 2; and

              -
              3. -
            3. -

              The first address in the set is a multiple of the set +

              4. +
            4. +

              The first address in the set is a multiple of the set size.

              -
              5. -
            5. -

              The first address in the subnet is reserved and is referred +

              6. +
            6. +

              The first address in the subnet is reserved and is referred to as the subnet address.

              -
              7. -
            7. -

              The last address in the subnet is reserved as the subnet's +

              8. +
            8. +

              The last address in the subnet is reserved as the subnet's broadcast address.

              -
              9. - + +
            - -

            As you can see by this definition, in each subnet of size - n there are (n - 2) usable addresses (addresses that -can be assigned to hosts). The first and last address in the subnet -are used for the subnet address and subnet broadcast address respectively. - Consequently, small subnetworks are more wasteful of IP addresses than + +

            As you can see by this definition, in each subnet of size + n there are (n - 2) usable addresses (addresses that +can be assigned to hosts). The first and last address in the subnet +are used for the subnet address and subnet broadcast address respectively. + Consequently, small subnetworks are more wasteful of IP addresses than are large ones.

            - -

            Since n is a power of two, we can easily calculate - the Natural Logarithm (log2) of n. For the more - common subnet sizes, the size and its natural logarithm are given in the + +

            Since n is a power of two, we can easily calculate + the Natural Logarithm (log2) of n. For the more + common subnet sizes, the size and its natural logarithm are given in the following table:

            - -
            + +
            - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            nlog2 n(32 - log2 n)
            nlog2 n(32 - log2 n)
            8329
            16428
            32527
            64626
            128725
            256824
            512923
            10241022
            20481121
            40961220
            81921319
            163841418
            327681517
            655361616
            8329
            16428
            32527
            64626
            128725
            256824
            512923
            10241022
            20481121
            40961220
            81921319
            163841418
            327681517
            655361616
            -
            - -

            You will notice that the above table also contains a column - for (32 - log2 n). That number is the Variable Length Subnet - Mask for a network of size n. From the above table, we can - derive the following one which is a little easier to use.

            - -
            +
            + +

            You will notice that the above table also contains a column + for (32 - log2 n). That number is the Variable Length Subnet + Mask for a network of size n. From the above table, we +can derive the following one which is a little easier to use.

            + +
            - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            Size of SubnetVLSMSubnet Mask
            Size of SubnetVLSMSubnet Mask
            8/29255.255.255.248
            16/28255.255.255.240
            32/27255.255.255.224
            64/26255.255.255.192
            128/25255.255.255.128
            256/24255.255.255.0
            512/23255.255.254.0
            1024/22255.255.252.0
            2048/21255.255.248.0
            4096/20255.255.240.0
            8192/19255.255.224.0
            16384/18255.255.192.0
            32768/17255.255.128.0
            65536/16255.255.0.0
            2 ** 24/8255.0.0.0
            8/29255.255.255.248
            16/28255.255.255.240
            32/27255.255.255.224
            64/26255.255.255.192
            128/25255.255.255.128
            256/24255.255.255.0
            512/23255.255.254.0
            1024/22255.255.252.0
            2048/21255.255.248.0
            4096/20255.255.240.0
            8192/19255.255.224.0
            16384/18255.255.192.0
            32768/17255.255.128.0
            65536/16255.255.0.0
            2 ** 24/8255.0.0.0
            -
            - -

            Notice that the VLSM is written with a slash ("/") -- you - will often hear a subnet of size 64 referred to as a "slash 26" subnet +

            + +

            Notice that the VLSM is written with a slash ("/") -- you + will often hear a subnet of size 64 referred to as a "slash 26" subnet and one of size 8 referred to as a "slash 29".

            - -

            The subnet's mask (also referred to as its netmask) is - simply a 32-bit number with the first "VLSM" bits set to one and the - remaining bits set to zero. For example, for a subnet of size 64, the + +

            The subnet's mask (also referred to as its netmask) is + simply a 32-bit number with the first "VLSM" bits set to one and the + remaining bits set to zero. For example, for a subnet of size 64, the subnet mask has 26 leading one bits:

            - -
            -

            11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 + +

            +

            11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192

            -
            - -

            The subnet mask has the property that if you logically AND - the subnet mask with an address in the subnet, the result is the subnet - address. Just as important, if you logically AND the subnet mask with - an address outside the subnet, the result is NOT the subnet address. - As we will see below, this property of subnet masks is very useful in +

            + +

            The subnet mask has the property that if you logically AND + the subnet mask with an address in the subnet, the result is the subnet + address. Just as important, if you logically AND the subnet mask with + an address outside the subnet, the result is NOT the subnet address. + As we will see below, this property of subnet masks is very useful in routing.

            - -

            For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork + +

            For a subnetwork whose address is a.b.c.d and whose + Variable Length Subnet Mask is /v, we denote the subnetwork as "a.b.c.d/v" using CIDR Notation. 

            - +

            Example:

            - -
            + +
            - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
            Subnet:10.10.10.0 - 10.10.10.127
            Subnet Size:128
            Subnet Address:10.10.10.0
            Broadcast Address:10.10.10.127
            CIDR Notation:10.10.10.0/25
            Subnet:10.10.10.0 - 10.10.10.127
            Subnet Size:128
            Subnet Address:10.10.10.0
            Broadcast Address:10.10.10.127
            CIDR Notation:10.10.10.0/25
            -
            - -

            There are two degenerate subnets that need mentioning; namely, +

            + +

            There are two degenerate subnets that need mentioning; namely, the subnet with one member and the subnet with 2 ** 32 members.

            - -
            + +
            - + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
            Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
            Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
            132255.255.255.255a.b.c.d/32
            2 ** 3200.0.0.00.0.0.0/0
            132255.255.255.255a.b.c.d/32
            2 ** 3200.0.0.00.0.0.0/0
            -
            - -

            So any address a.b.c.d may also be written a.b.c.d/32 +

            + +

            So any address a.b.c.d may also be written a.b.c.d/32 and the set of all possible IP addresses is written 0.0.0.0/0.

            - -

            Later in this guide, you will see the notation a.b.c.d/v - used to describe the ip configuration of a network interface (the 'ip' - utility also uses this syntax). This simply means that the interface is - configured with ip address a.b.c.d and with the netmask that corresponds - to VLSM /v.

            - + +

            Later in this guide, you will see the notation a.b.c.d/v + used to describe the ip configuration of a network interface (the 'ip' + utility also uses this syntax). This simply means that the interface +is configured with ip address a.b.c.d and with the netmask that +corresponds to VLSM /v.

            +

            Example: 192.0.2.65/29

            - -

                The interface is configured with IP address 192.0.2.65 + +

                The interface is configured with IP address 192.0.2.65 and netmask 255.255.255.248.

            - +

            4.3 Routing

            - -

            One of the purposes of subnetting is that it forms the basis + +

            One of the purposes of subnetting is that it forms the basis for routing. Here's the routing table on my firewall:

            - -
            -
            + +
            +
            [root@gateway root]# netstat -nr
            Kernel IP routing table
            Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
            192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
            206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
            206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
            192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
            192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
            192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
            206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
            192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
            127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
            0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
            [root@gateway root]#
            -
            -
            - -

            The device texas is a GRE tunnel to a peer site in +

            +
            + +

            The device texas is a GRE tunnel to a peer site in the Dallas, Texas area.
            -
            - The first three routes are host routes since they indicate - how to get to a single host. In the 'netstat' output this can be seen - by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the -Flags column. The remainder are 'net' routes since they tell the kernel -how to route packets to a subnetwork. The last route is the default -route and the gateway mentioned in that route is called the default - gateway.

            - -

            When the kernel is trying to send a packet to IP address A, - it starts at the top of the routing table and:

            - +
            + The first three routes are host routes since they indicate + how to get to a single host. In the 'netstat' output this can be seen + by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the +Flags column. The remainder are 'net' routes since they tell the kernel +how to route packets to a subnetwork. The last route is the default route +and the gateway mentioned in that route is called the default gateway.

            + +

            When the kernel is trying to send a packet to IP address +A, it starts at the top of the routing table and:

            +
              -
            • -

              A is logically ANDed with the 'Genmask' value in -the table entry.

              -
              • -
            • -

              The result is compared with the 'Destination' value in +

            • +

              A is logically ANDed with the 'Genmask' value +in the table entry.

              +
              • +
            • +

              The result is compared with the 'Destination' value in the table entry.

              -
              • -
            • -

              If the result and the 'Destination' value are the same, +

              • +
            • +

              If the result and the 'Destination' value are the same, then:

              - +
                -
              • - -

                If the 'Gateway' column is non-zero, the packet is +

              • +

                If the 'Gateway' column is non-zero, the packet is sent to the gateway over the interface named in the 'Iface' column.

                -
                • -
              • - -

                Otherwise, the packet is sent directly to A over +

                • +
              • +

                Otherwise, the packet is sent directly to A over the interface named in the 'iface' column.

                -
                • - + +
              -
              • -
            • -

              Otherwise, the above steps are repeated on the next entry +

              • +
            • +

              Otherwise, the above steps are repeated on the next entry in the table.

              -
              • - + +
            - -

            Since the default route matches any IP address (A land - 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table - entries are sent to the default gateway which is usually a router -at your ISP.

            - -

            Lets take an example. Suppose that we want to route a packet - to 192.168.1.5. That address clearly doesn't match any of the host routes - in the table but if we logically and that address with 255.255.255.0, + +

            Since the default route matches any IP address (A +land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing +table entries are sent to the default gateway which is usually a +router at your ISP.

            + +

            Lets take an example. Suppose that we want to route a packet + to 192.168.1.5. That address clearly doesn't match any of the host routes + in the table but if we logically and that address with 255.255.255.0, the result is 192.168.1.0 which matches this routing table entry:

            - -
            -
            + +
            +
            192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
            -
            - -

            So to route a packet to 192.168.1.5, the packet is sent directly over eth2.

            -
            - -

            One more thing needs to be emphasized -- all outgoing packet - are sent using the routing table and reply packets are not a special -case. There seems to be a common mis-conception whereby people think that -request packets are like salmon and contain a genetic code that is magically -transferred to reply packets so that the replies follow the reverse route -taken by the request. That isn't the case; the replies may take a totally -different route back to the client than was taken by the requests -- they -are totally independent.

            - -

            4.4 Address Resolution Protocol

            - -

            When sending packets over Ethernet, IP addresses aren't used. - Rather Ethernet addressing is based on Media Access Control (MAC) - addresses. Each Ethernet device has it's own unique  MAC address which - is burned into a PROM on the device during manufacture. You can obtain +

            + +

            So to route a packet to 192.168.1.5, the packet is sent directly over +eth2.

            +
            + +

            One more thing needs to be emphasized -- all outgoing packet + are sent using the routing table and reply packets are not a special +case. There seems to be a common mis-conception whereby people think +that request packets are like salmon and contain a genetic code that +is magically transferred to reply packets so that the replies follow +the reverse route taken by the request. That isn't the case; the replies +may take a totally different route back to the client than was taken by +the requests -- they are totally independent.

            + +

            4.4 Address Resolution Protocol (ARP)

            + +

            When sending packets over Ethernet, IP addresses aren't used. + Rather Ethernet addressing is based on Media Access Control (MAC) + addresses. Each Ethernet device has it's own unique  MAC address which + is burned into a PROM on the device during manufacture. You can obtain the MAC of an Ethernet device using the 'ip' utility:

            - -
            -
            + +
            + 
            [root@gateway root]# ip addr show eth0
            2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
            link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
            inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
            inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
            inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
            [root@gateway root]#
            -
            -
            - -
            -

            As you can see from the above output, the MAC is 6 bytes (48 - bits) wide. A card's MAC is usually also printed on a label attached to -the card itself.

            -
            - -
            -

            Because IP uses IP addresses and Ethernet uses MAC addresses, - a mechanism is required to translate an IP address into a MAC address; - that is the purpose of the Address Resolution Protocol (ARP). +

            +
            + +
            +

            As you can see from the above output, the MAC is 6 bytes +(48 bits) wide. A card's MAC is usually also printed on a label attached +to the card itself.

            +
            + +
            +

            Because IP uses IP addresses and Ethernet uses MAC addresses, + a mechanism is required to translate an IP address into a MAC address; + that is the purpose of the Address Resolution Protocol (ARP). Here is ARP in action:

            -
            - -
            -
            -
            +
            + +
            +
            + 
            [root@gateway root]# tcpdump -nei eth2 arp
            tcpdump: listening on eth2
            09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
            09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

            2 packets received by filter
            0 packets dropped by kernel
            [root@gateway root]#
            -
            -
            -
            - -

            In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants - to know the MAC of the device with IP address 192.168.1.19. The system - having that IP address is responding that the MAC address of the device +

            +
            + + +

            In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants + to know the MAC of the device with IP address 192.168.1.19. The system + having that IP address is responding that the MAC address of the device with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

            - -

            In order to avoid having to exchange ARP information each - time that an IP packet is to be sent, systems maintain an ARP cache - of IP<->MAC correspondences. You can see the ARP cache on your + +

            In order to avoid having to exchange ARP information each + time that an IP packet is to be sent, systems maintain an ARP cache + of IP<->MAC correspondences. You can see the ARP cache on your system (including your Windows system) using the 'arp' command:

            - -
            -
            + +
            + 
            [root@gateway root]# arp -na
            ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
            ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
            ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
            ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
            ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
            -
            -
            - -

            The leading question marks are a result of my having specified - the 'n' option (Windows 'arp' doesn't allow that option) which causes - the 'arp' program to forego IP->DNS name translation. Had I not given - that option, the question marks would have been replaced with the FQDN - corresponding to each IP address. Notice that the last entry in the table +

            +
            + +

            The leading question marks are a result of my having specified + the 'n' option (Windows 'arp' doesn't allow that option) which causes + the 'arp' program to forego IP->DNS name translation. Had I not given + that option, the question marks would have been replaced with the FQDN + corresponding to each IP address. Notice that the last entry in the table records the information we saw using tcpdump above.

            - +

            4.5 RFC 1918

            - +

            IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet - Registries (RIRs). For example, allocation for the Americas and for + href="http://www.iana.org">Internet Assigned Number Authority (IANA) + who delegates allocations on a geographic basis to Regional Internet + Registries (RIRs). For example, allocation for the Americas and for sub-Sahara Africa is delegated to the American Registry for Internet Numbers -(ARIN). These RIRs may in turn delegate to national registries. Most -of us don't deal with these registrars but rather get our IP addresses + href="http://www.arin.net">American Registry for Internet Numbers +(ARIN). These RIRs may in turn delegate to national registries. Most +of us don't deal with these registrars but rather get our IP addresses from our ISP.

            - -

            It's a fact of life that most of us can't afford as many Public - IP addresses as we have devices to assign them to so we end up making use -of Private IP addresses. RFC 1918 reserves several IP address ranges -for this purpose:

            - -
            + +

            It's a fact of life that most of us can't afford as many +Public IP addresses as we have devices to assign them to so we end up making +use of Private IP addresses. RFC 1918 reserves several IP address +ranges for this purpose:

            + +
                 10.0.0.0    - 10.255.255.255
                 172.16.0.0  - 172.31.255.255
                 192.168.0.0 - 192.168.255.255
            +
            + +
            +

            The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. This is +understandable given that anyone can select any of these addresses +for their private use.

            - -
            -

            The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. This is -understandable given that anyone can select any of these addresses for -their private use.

            -
            - -
            -

            When selecting addresses from these ranges, there's a couple + +

            +

            When selecting addresses from these ranges, there's a couple of things to keep in mind:

            -
            - -
            +
            + +
              -
            • -

              As the IPv4 address space becomes depleted, more and more - organizations (including ISPs) are beginning to use RFC 1918 addresses +

            • +

              As the IPv4 address space becomes depleted, more and +more organizations (including ISPs) are beginning to use RFC 1918 addresses in their infrastructure.

              -
              • -
            • -

              You don't want to use addresses that are being used by - your ISP or by another organization with whom you want to establish +

              • +
            • +

              You don't want to use addresses that are being used by + your ISP or by another organization with whom you want to establish a VPN relationship.

              -
              • - + +
            -
            - -
            -

            So it's a good idea to check with your ISP to see if they - are using (or are planning to use) private addresses before you decide +

            + +
            +

            So it's a good idea to check with your ISP to see if they + are using (or are planning to use) private addresses before you decide the addresses that you are going to use.

            -
            - -
            +
            + +

            5.0 Setting up your Network

            +
            + +
            +

            The choice of how to set up your network depends primarily + on how many Public IP addresses you have vs. how many addressable +entities you have in your network. Regardless of how many addresses +you have, your ISP will handle that set of addresses in one of two +ways:

            - -
            -

            The choice of how to set up your network depends primarily - on how many Public IP addresses you have vs. how many addressable entities - you have in your network. Regardless of how many addresses you have, - your ISP will handle that set of addresses in one of two ways:

            -
            - -
            + +
              -
            1. -

              Routed - Traffic to any of your addresses will - be routed through a single gateway address. This will generally - only be done if your ISP has assigned you a complete subnet (/29 or - larger). In this case, you will assign the gateway address as the IP +

            2. +

              Routed - Traffic to any of your addresses will + be routed through a single gateway address. This will generally + only be done if your ISP has assigned you a complete subnet (/29 or + larger). In this case, you will assign the gateway address as the IP address of your firewall/router's external interface.

              -
              3. -
            3. -

              Non-routed - Your ISP will send traffic to each +

              4. +
            4. +

              Non-routed - Your ISP will send traffic to each of your addresses directly.

              -
              5. - + +
            -
            - -
            -

            In the subsections that follow, we'll look at each of these +

            + +
            +

            In the subsections that follow, we'll look at each of these separately.
            -

            - +

            +

            Before we begin, there is one thing for you to check:

            - +

            -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, change them appropriately:
            -

            - +

            +
              -
            • NAT_ENABLED=Yes
              • -
            • IP_FORWARDING=On
              -
              • - +
            • NAT_ENABLED=Yes
              • +
            • IP_FORWARDING=On
              +
              • +
            -
            - -
            -

            5.1 Routed

            - -
            -

            Let's assume that your ISP has assigned you the subnet -192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses - 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address - is 192.0.2.65. Your ISP has also told you that you should use a netmask - of 255.255.255.0 (so your /28 is part of a larger /24). With this many - IP addresses, you are able to subnet your /28 into two /29's and set - up your network as shown in the following diagram.

            -
            - -
            + +
            +

            5.1 Routed

            +
            + +
            +

            Let's assume that your ISP has assigned you the subnet 192.0.2.64/28 +routed through 192.0.2.65. That means that you have IP addresses 192.0.2.64 +- 192.0.2.79 and that your firewall's external IP address is 192.0.2.65. +Your ISP has also told you that you should use a netmask of 255.255.255.0 +(so your /28 is part of a larger /24). With this many IP addresses, +you are able to subnet your /28 into two /29's and set up your network +as shown in the following diagram.

            +
            + +

            -

            -
            - -
            -

            Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local - network is 192.0.2.72/29. The default gateway for hosts in the DMZ would -be configured to 192.0.2.66 and the default gateway for hosts in the local - network would be 192.0.2.73.

            -
            - -
            -

            Notice that this arrangement is rather wasteful of public - IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet - addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses -and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. - Nevertheless, it shows how subnetting can work and if we were dealing - with a /24 rather than a /28 network, the use of 6 IP addresses out +

            +
            + +
            +

            Here, the DMZ comprises the subnet 192.0.2.64/29 and the +Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ +would be configured to 192.0.2.66 and the default gateway for hosts in +the local network would be 192.0.2.73.

            +
            + +
            +

            Notice that this arrangement is rather wasteful of public + IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet + addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses +and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. + Nevertheless, it shows how subnetting can work and if we were dealing + with a /24 rather than a /28 network, the use of 6 IP addresses out of 256 would be justified because of the simplicity of the setup.

            -
            - -
            -

            The astute reader may have noticed that the Firewall/Router's - external interface is actually part of the DMZ subnet (192.0.2.64/29). - What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The +

            + +
            +

            The astute reader may have noticed that the Firewall/Router's + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The routing table on DMZ 1 will look like this:

            -
            - -
            -
            +
            + +
            +
            Kernel IP routing table
            Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
            192.0.2.64 	0.0.0.0 	255.255.255.248 U     40  0         0 eth0
            0.0.0.0 	192.0.2.66	0.0.0.0 	UG    40  0         0 eth0
            -
            -
            - -
            -

            This means that DMZ 1 will send an ARP "who-has 192.0.2.65" - request and no device on the DMZ Ethernet segment has that IP address. - Oddly enough, the firewall will respond to the request with the MAC - address of its DMZ Interface!! DMZ 1 can then send Ethernet frames - addressed to that MAC address and the frames will be received (correctly) +

            + + +
            +

            This means that DMZ 1 will send an ARP "who-has 192.0.2.65" + request and no device on the DMZ Ethernet segment has that IP address. + Oddly enough, the firewall will respond to the request with the MAC + address of its DMZ Interface!! DMZ 1 can then send Ethernet frames + addressed to that MAC address and the frames will be received (correctly) by the firewall/router.

            -
            - -
            -

            It is this rather unexpected ARP behavior on the part of the - Linux Kernel that prompts the warning earlier in this guide regarding the - connecting of multiple firewall/router interfaces to the same hub or switch. - When an ARP request for one of the firewall/router's IP addresses is sent -by another system connected to the hub/switch, all of the firewall's - interfaces that connect to the hub/switch can respond! It is then a - race as to which "here-is" response reaches the sender first.

            -
            - -
            +
            + +
            +

            It is this rather unexpected ARP behavior on the part of +the Linux Kernel that prompts the warning earlier in this guide regarding +the connecting of multiple firewall/router interfaces to the same hub +or switch. When an ARP request for one of the firewall/router's IP addresses +is sent by another system connected to the hub/switch, all of the firewall's + interfaces that connect to the hub/switch can respond! It is then +a race as to which "here-is" response reaches the sender first.

            +
            + +

            5.2 Non-routed

            +
            + +
            +

            If you have the above situation but it is non-routed, +you can configure your network exactly as described above with one additional + twist; simply specify the "proxyarp" option on all three firewall +interfaces in the /etc/shorewall/interfaces file.

            - -
            -

            If you have the above situation but it is non-routed, you -can configure your network exactly as described above with one additional - twist; simply specify the "proxyarp" option on all three firewall interfaces - in the /etc/shorewall/interfaces file.

            -
            - -
            -

            Most of us don't have the luxury of having enough public IP - addresses to set up our networks as shown in the preceding example (even -if the setup is routed).

            -
            - -
            -

            For the remainder of this section, assume that your ISP - has assigned you IP addresses 192.0.2.176-180 and has told you to use - netmask 255.255.255.0 and default gateway 192.0.2.254.

            -
            - -
            -

            Clearly, that set of addresses doesn't comprise a subnetwork - and there aren't enough addresses for all of the network interfaces. - There are four different techniques that can be used to work around + +

            +

            Most of us don't have the luxury of having enough public +IP addresses to set up our networks as shown in the preceding example +(even if the setup is routed).

            +
            + +
            +

            For the remainder of this section, assume that your ISP + has assigned you IP addresses 192.0.2.176-180 and has told you to +use netmask 255.255.255.0 and default gateway 192.0.2.254.

            +
            + +
            +

            Clearly, that set of addresses doesn't comprise a subnetwork + and there aren't enough addresses for all of the network interfaces. + There are four different techniques that can be used to work around this problem.

            -
            - -
            +
            + +
              -
            • -

              Source Network Address Translation (SNAT). -

              -
              • -
            • -

              Destination Network Address Translation (DNAT) +

            • +

              Source Network Address Translation (SNAT). +

              +
              • +
            • +

              Destination Network Address Translation (DNAT) also known as Port Forwarding.

              -
              • -
            • +
              • +

            • Proxy ARP.

              -
              • -
            • -

              Network Address Translation (NAT) also referred +

              • +
            • +

              Network Address Translation (NAT) also referred to as Static NAT.

              -
              • - + +
            +
            + +
            +

            Often a combination of these techniques is used. Each of +these will be discussed in the sections that follow.

            - -
            -

            Often a combination of these techniques is used. Each of these - will be discussed in the sections that follow.

            -
            - -
            + +

             5.2.1 SNAT

            +
            + +
            +

            With SNAT, an internal LAN segment is configured using RFC + 1918 addresses. When a host A on this internal segment initiates + a connection to host B on the internet, the firewall/router +rewrites the IP header in the request to use one of your public IP +addresses as the source address. When B responds and the response +is received by the firewall, the firewall changes the destination address +back to the RFC 1918 address of A and forwards the response back +to A.

            - -
            -

            With SNAT, an internal LAN segment is configured using RFC - 1918 addresses. When a host A on this internal segment initiates - a connection to host B on the internet, the firewall/router -rewrites the IP header in the request to use one of your public IP addresses -as the source address. When B responds and the response is received - by the firewall, the firewall changes the destination address back -to the RFC 1918 address of A and forwards the response back to -A.

            -
            - -
            -

            Let's suppose that you decide to use SNAT on your local zone - and use public address 192.0.2.176 as both your firewall's external - IP address and the source IP address of internet requests sent from + +

            +

            Let's suppose that you decide to use SNAT on your local zone + and use public address 192.0.2.176 as both your firewall's external + IP address and the source IP address of internet requests sent from that zone.

            -
            - -
            +
            + +

            -

            -
            - -
            The local zone has been subnetted as 192.168.201.0/29 + +
            + +
            The local zone has been subnetted as 192.168.201.0/29 (netmask 255.255.255.248).
            - +
             
            - +
            -     The systems in the local zone would be configured with a -default gateway of 192.168.201.1 (the IP address of the firewall's +     The systems in the local zone would be configured with a +default gateway of 192.168.201.1 (the IP address of the firewall's local interface).
            - +
             
            - +
            -     SNAT is configured in Shorewall using the /etc/shorewall/masq file.
            - -
            -
            + +
            +
            - - - - - - + - - - - - - + + + + + + + + + + +
            INTERFACESUBNETADDRESS
            eth0192.168.201.0/29192.0.2.176
            INTERFACESUBNETADDRESS
            eth0192.168.201.0/29192.0.2.176
            -
            +
            +
            + +
            +

            This example used the normal technique of assigning the same + public IP address for the firewall external interface and for SNAT. + If you wanted to use a different IP address, you would either have +to use your distributions network configuration tools to add that IP +address to the external interface or you could set ADD_SNAT_ALIASES=Yes +in /etc/shorewall/shorewall.conf and Shorewall will add the address for +you.

            - -
            -

            This example used the normal technique of assigning the same - public IP address for the firewall external interface and for SNAT. - If you wanted to use a different IP address, you would either have to - use your distributions network configuration tools to add that IP address - to the external interface or you could set ADD_SNAT_ALIASES=Yes in - /etc/shorewall/shorewall.conf and Shorewall will add the address for you.

            -
            - -
            + +

            5.2.2 DNAT

            -
            - -
            -

            When SNAT is used, it is impossible for hosts on the internet - to initiate a connection to one of the internal systems since those - systems do not have a public IP address. DNAT provides a way to allow +

            + +
            +

            When SNAT is used, it is impossible for hosts on the internet + to initiate a connection to one of the internal systems since those + systems do not have a public IP address. DNAT provides a way to allow selected connections from the internet.

            -
            - -
            +
            + +

            -      Suppose that your daughter wants to run a web server on -her system "Local 3". You could allow connections to the internet -to her server by adding the following entry in /etc/shorewall/rules:

            -
            - -
            -
            +
            + +
            +
            - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
            ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
            DNATnetloc:192.168.201.4tcpwww-192.0.2.176
            ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
            DNATnetloc:192.168.201.4tcpwww-192.0.2.176
            -
            -
            - -
            -

            If one of your daughter's friends at address A wants +

            + + +
            +

            If one of your daughter's friends at address A wants to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external - IP address) and the firewall will rewrite the destination IP address - to 192.168.201.4 (your daughter's system) and forward the request. When - your daughter's server responds, the firewall will rewrite the source - address back to 192.0.2.176 and send the response back to A.

            -
            - -
            -

            This example used the firewall's external IP address for DNAT. - You can use another of your public IP addresses but Shorewall will not -add that address to the firewall's external interface for you.

            -
            - -
            + href="http://192.0.2.176"> http://192.0.2.176 (the firewall's external + IP address) and the firewall will rewrite the destination IP address + to 192.168.201.4 (your daughter's system) and forward the request. +When your daughter's server responds, the firewall will rewrite the +source address back to 192.0.2.176 and send the response back to A.

            +
            + +
            +

            This example used the firewall's external IP address for +DNAT. You can use another of your public IP addresses but Shorewall will +not add that address to the firewall's external interface for you.

            +
            + +

            5.2.3 Proxy ARP

            -
            - -
            +
            + +

            The idea behind proxy ARP is that:

            -
            - -
            -
              -
            • -

              A host H behind your firewall is assigned one of -your public IP addresses (A) and is assigned the same netmask - (M) as the firewall's external interface.

              -
              • -
            • -

              The firewall responds to ARP "who has" requests for A. -

              -
              • -
            • -

              When H issues an ARP "who has" request for an address - in the subnetwork defined by A and M, the firewall will -respond (with the MAC if the firewall interface to H).

              -
              • - -
            - -
            -

            Let suppose that we decide to use Proxy ARP on the DMZ in + +

            +
              +
            • +

              A host H behind your firewall is assigned one +of your public IP addresses (A) and is assigned the same netmask + (M) as the firewall's external interface.

              +
              • +
            • +

              The firewall responds to ARP "who has" requests for A. +

              +
              • +
            • +

              When H issues an ARP "who has" request for an +address in the subnetwork defined by A and M, the firewall +will respond (with the MAC if the firewall interface to H).

              +
              • + +
            +
            + +
            +

            Let suppose that we decide to use Proxy ARP on the DMZ in our example network.

            -
            - -
            +
            + +

            -

            -
            - -
            Here, we've assigned the IP addresses 192.0.2.177 to - system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned - an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface - on the firewall. That address and netmask isn't relevant - just be sure - it doesn't overlap another subnet that you've defined.
            - +

            +
            + +
            Here, we've assigned the IP addresses 192.0.2.177 to + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just be +sure it doesn't overlap another subnet that you've defined.
            +
             
            - +
            -     The Shorewall configuration of Proxy ARP is done using the +     The Shorewall configuration of Proxy ARP is done using the /etc/shorewall/proxyarp file.
            - -
            -
            + +
            +
            - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
            ADDRESSINTERFACEEXTERNALHAVE ROUTE
            192.0.2.177eth2eth0No
            192.0.2.178eth2eth0No
            ADDRESSINTERFACEEXTERNALHAVE ROUTE
            192.0.2.177eth2eth0No
            192.0.2.178eth2eth0No
            -
            -
            - -
            -

            Because the HAVE ROUTE column contains No, Shorewall will +

            +
            + +
            +

            Because the HAVE ROUTE column contains No, Shorewall will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
            -

            - -

            The ethernet interfaces on DMZ 1 and DMZ 2 should be configured - to have the IP addresses shown but should have the same default gateway -as the firewall itself -- namely 192.0.2.254. In other words, they should -be configured just like they would be if they were parallel to the firewall +

            + +

            The ethernet interfaces on DMZ 1 and DMZ 2 should be configured + to have the IP addresses shown but should have the same default gateway +as the firewall itself -- namely 192.0.2.254. In other words, they should +be configured just like they would be if they were parallel to the firewall rather than behind it.
            -

            - -

            NOTE: Do not add the Proxy ARP'ed address(es) -(192.0.2.177 and 192.0.2.178 in the above example)  to the external interface +

            + +

            NOTE: Do not add the Proxy ARP'ed address(es) +(192.0.2.177 and 192.0.2.178 in the above example)  to the external interface (eth0 in this example) of the firewall.
            -

            +

            +
            -
            - -
            +
            + +

            -
            - -
            -
            -

            A word of warning is in order here. ISPs typically configure - their routers with a long ARP cache timeout. If you move a system from - parallel to your firewall to behind your firewall with Proxy ARP, it - will probably be HOURS before that system can communicate with the internet. +

            + +
            +
            +

            A word of warning is in order here. ISPs typically configure + their routers with a long ARP cache timeout. If you move a system from + parallel to your firewall to behind your firewall with Proxy ARP, it + will probably be HOURS before that system can communicate with the internet. There are a couple of things that you can try:
            -

            - +

            +
              -
            1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP +
            2. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, Vol 1 reveals that a
              -
              - "gratuitous" ARP packet should cause the ISP's router to refresh their - ARP cache (section 4.7). A gratuitous ARP is simply a host requesting -the MAC address for its own IP; in addition to ensuring that the IP address +
              + "gratuitous" ARP packet should cause the ISP's router to refresh their + ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the + MAC address for its own IP; in addition to ensuring that the IP address isn't a duplicate,...
              -
              - "if the host sending the gratuitous ARP has just changed its hardware - address..., this packet causes any other host...that has an entry in its +
              + "if the host sending the gratuitous ARP has just changed its hardware + address..., this packet causes any other host...that has an entry in its cache for the old hardware address to update its ARP cache entry accordingly."
              -
              - Which is, of course, exactly what you want to do when you switch a -host from being exposed to the Internet to behind Shorewall using proxy -ARP (or static NAT for that matter). Happily enough, recent versions of +
              + Which is, of course, exactly what you want to do when you switch +a host from being exposed to the Internet to behind Shorewall using proxy +ARP (or static NAT for that matter). Happily enough, recent versions of Redhat's iputils package include "arping", whose "-U" flag does just that:
              -
              -     arping -U -I <net if> <newly +
              +     arping -U -I <net if> <newly proxied IP>
              -     arping -U -I eth0 66.58.99.83 # for example
              -
              - Stevens goes on to mention that not all systems respond correctly -to gratuitous ARPs, but googling for "arping -U" seems to support the -idea that it works most of the time.
              -
              -
              3. -
            3. You can call your ISP and ask them to purge the stale ARP +     arping -U -I eth0 66.58.99.83 # for +example
              +
              + Stevens goes on to mention that not all systems respond correctly +to gratuitous ARPs, but googling for "arping -U" seems to support the idea + that it works most of the time.
              +
              +
              4. +
            4. You can call your ISP and ask them to purge the stale ARP cache entry but many either can't or won't purge individual entries.
              5. - +
            - You can determine if your ISP's gateway ARP cache is stale using - ping and tcpdump. Suppose that we suspect that the gateway router has - a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump + You can determine if your ISP's gateway ARP cache is stale using + ping and tcpdump. Suppose that we suspect that the gateway router has + a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:
            - -
            + +
            	tcpdump -nei eth0 icmp
            -
            - -
            -

            Now from 130.252.100.19, ping the ISP's gateway (which we +

            + +
            +

            Now from 130.252.100.19, ping the ISP's gateway (which we will assume is 130.252.100.254):

            -
            - -
            -
            	ping 130.252.100.254
            -
            - -
            + +
            +
            	ping 130.252.100.254
            +
            +
            + +

            We can now observe the tcpdump output:

            -
            - -
            +
            + +
            	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
            	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
            +
            + +
            +

            Notice that the source MAC address in the echo request is + different from the destination MAC address in the echo reply!! In +this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while +0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the +gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ +1 rather than with the firewall's eth0.

            - -
            -

            Notice that the source MAC address in the echo request is - different from the destination MAC address in the echo reply!! In this - case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 - was the MAC address of DMZ 1. In other words, the gateway's ARP cache - still associates 192.0.2.177 with the NIC in DMZ 1 rather than with -the firewall's eth0.

            -
            - -
            + +

            5.2.4 Static NAT

            +
            + +
            +

            With static NAT, you assign local systems RFC 1918 addresses + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT (Source Network Address + Translation) occurs and on incoming connections DNAT (Destination Network + Address Translation) occurs. Let's go back to our earlier example involving + your daughter's web server running on system Local 3.

            - -
            -

            With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public - IP addresses. For outgoing connections SNAT (Source Network Address - Translation) occurs and on incoming connections DNAT (Destination -Network Address Translation) occurs. Let's go back to our earlier example -involving your daughter's web server running on system Local 3.

            -
            - -
            + +

            -

            -
            - -
            -

            Recall that in this setup, the local network is using SNAT - and is sharing the firewall external IP (192.0.2.176) for outbound +

            +
            + +
            +

            Recall that in this setup, the local network is using SNAT + and is sharing the firewall external IP (192.0.2.176) for outbound connections. This is done with the following entry in /etc/shorewall/masq:

            -
            - -
            -
            +
            + +
            +
            - - - - - - + - - - - - - + + + + + + + + + + +
            INTERFACESUBNETADDRESS
            eth0192.168.201.0/29192.0.2.176
            INTERFACESUBNETADDRESS
            eth0192.168.201.0/29192.0.2.176
            -
            -
            - -
            +
            + + +

            -     Suppose now that you have decided to give your daughter her - own IP address (192.0.2.179) for both inbound and outbound connections. +     Suppose now that you have decided to give your daughter +her own IP address (192.0.2.179) for both inbound and outbound connections. You would do that by adding an entry in /etc/shorewall/nat.

            -
            - -
            -
            +
            + +
            +
            - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
            EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
            192.0.2.179eth0192.168.201.4NoNo
            EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
            192.0.2.179eth0192.168.201.4NoNo
            -
            -
            - -
            -

            With this entry in place, you daughter has her own IP address +

    + + +
    +

    With this entry in place, you daughter has her own IP address and the other two local systems share the firewall's IP address.

    -
    - -
    +
    + +

    -     Once the relationship between 192.0.2.179 and 192.168.201.4 - is established by the nat file entry above, it is no longer appropriate - to use a DNAT rule for you daughter's web server -- you would rather +     Once the relationship between 192.0.2.179 and 192.168.201.4 + is established by the nat file entry above, it is no longer appropriate + to use a DNAT rule for you daughter's web server -- you would rather just use an ACCEPT rule:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    -
    -
    - -
    +
    + + +

    5.3 Rules

    -
    - -
    +
    + +

    -     With the default policies, your local systems (Local 1-3) -can access any servers on the internet and the DMZ can't access any +     With the default policies, your local systems (Local 1-3) +can access any servers on the internet and the DMZ can't access any other host (including the firewall). With the exception of DNAT rules which cause address translation and allow - the translated connection request to pass through the firewall, the -way to allow connection requests through your firewall is to use ACCEPT + href="#DNAT">DNAT rules which cause address translation and allow + the translated connection request to pass through the firewall, the +way to allow connection requests through your firewall is to use ACCEPT rules.

    -
    - -
    -

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't +

    + +
    +

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't used in this section, they won't be shown

    -
    - -
    +
    + +

    You probably want to allow ping between your zones:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    -
    -
    - -
    -

    Let's suppose that you run mail and pop3 servers on DMZ 2 + +

    + +
    +

    Let's suppose that you run mail and pop3 servers on DMZ 2 and a Web Server on DMZ 1. The rules that you would need are:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    -
    + +
    + +
    +

    If you run a public DNS server on 192.0.2.177, you would +need to add the following rules:

    - -
    -

    If you run a public DNS server on 192.0.2.177, you would need - to add the following rules:

    -
    - -
    -
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    -
    -
    - -
    -

    You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through +

    +
    + +
    +

    You probably want some way to communicate with your firewall + and DMZ systems from the local network -- I recommend SSH which through its scp utility can also do publishing and software update distribution.

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    5.4 Odds and Ends

    +
    + +
    +

    The above discussion reflects my personal preference for +using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. +I prefer to use NAT only in cases where a system that is part of an RFC +1918 subnet needs to have it's own public IP. 

    - -
    -

    The above discussion reflects my personal preference for using - Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I -prefer to use NAT only in cases where a system that is part of an RFC 1918 -subnet needs to have it's own public IP. 

    -
    - -
    + +

    -     If you haven't already, it would be a good idea to browse -through /etc/shorewall/shorewall.conf -just to see if there is anything there that might be of interest. You -might also want to look at the other configuration files that you -haven't touched yet just to get a feel for the other things that Shorewall -can do.

    -
    - -
    -

    In case you haven't been keeping score, here's the final set - of configuration files for our sample network. Only those that were modified - from the original installation are shown.

    -
    - -
    -

    /etc/shorewall/interfaces (The "options" will be very site-specific).

    -
    - -
    -
    +     If you haven't already, it would be a good idea to browse +through /etc/shorewall/shorewall.conf +just to see if there is anything there that might be of interest. +You might also want to look at the other configuration files that +you haven't touched yet just to get a feel for the other things that +Shorewall can do.

    +
    + +
    +

    In case you haven't been keeping score, here's the final +set of configuration files for our sample network. Only those that were +modified from the original installation are shown.

    +
    + +
    +

    /etc/shorewall/interfaces (The "options" will be very +site-specific).

    +
    + +
    +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    -
    -
    - -
    -

    The setup described here requires that your network interfaces - be brought up before Shorewall can start. This opens a short window - during which you have no firewall protection. If you replace 'detect' - with the actual broadcast addresses in the entries above, you can bring + +

    + +
    +

    The setup described here requires that your network interfaces + be brought up before Shorewall can start. This opens a short window + during which you have no firewall protection. If you replace 'detect' + with the actual broadcast addresses in the entries above, you can bring up Shorewall before you bring up your network interfaces.

    -
    - -
    -
    +
    + +
    +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    -
    -
    - -
    + +
    + +

    /etc/shorewall/masq - Local subnet

    -
    - -
    -
    +
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    /etc/shorewall/proxyarp - DMZ

    -
    - -
    -
    +
    + +
    +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    + +
    + +

    /etc/shorewall/nat- Daughter's System

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    + +
    + +

    /etc/shorewall/rules

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    6.0 DNS

    -
    - -
    -

    Given the collection of RFC 1918 and public addresses in this - setup, it only makes sense to have separate internal and external DNS -servers. You can combine the two into a single BIND 9 server using Views. - If you are not interested in Bind 9 views, you can + +

    - -
    -

    Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want the - three local systems named "winken.foobar.net, blinken.foobar.net and - nod.foobar.net. You want your firewall to be known as firewall.foobar.net - externally and it's interface to the local network to be know as gateway.foobar.net - and its interface to the dmz as dmz.foobar.net. Let's have the DNS server - on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    -
    - -
    +
    + +
    +

    Suppose that your domain is foobar.net and you want the two + DMZ systems named www.foobar.net and mail.foobar.net and you want +the three local systems named "winken.foobar.net, blinken.foobar.net +and nod.foobar.net. You want your firewall to be known as firewall.foobar.net + externally and it's interface to the local network to be know as gateway.foobar.net + and its interface to the dmz as dmz.foobar.net. Let's have the DNS +server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    +
    + +

    The /etc/named.conf file would look like this:

    -
    - -
    -
    -
    +
    + +
    +
    + 
    options {
    	directory "/var/named";
    	listen-on { 127.0.0.1 ; 192.0.2.177; };
    };

    logging {
    	channel xfer-log {
    		file "/var/log/named/bind-xfer.log";
    		print-category yes;
    		print-severity yes;
    		print-time yes;
    		severity info;
    	};
    	category xfer-in { xfer-log; };
    	category xfer-out { xfer-log; };
    	category notify { xfer-log; };
    };
    -
    - -
    +
    + + 
    #
    # This is the view presented to our internal systems
    #

    view "internal" {
    	#
    	# These are the clients that see this view
    	#
    	match-clients { 192.168.201.0/29;
    			192.168.202.0/29;
    			127.0.0/24;
    			192.0.2.176/32; 
    			192.0.2.178/32;
    			192.0.2.179/32;
    			192.0.2.180/32; };
    	#
    	# If this server can't complete the request, it should use outside
    	# servers to do so
    	#
    	recursion yes;

    	zone "." in {
    		type hint;
    		file "int/root.cache";
    	};

    	zone "foobar.net" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.foobar";
    	};

    	zone "0.0.127.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.127.0.0";	
    	};

    	zone "201.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.201";
    	};

    	zone "202.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.202";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.176";
    	};
     (or status NAT for that matter)
    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.206.124.146.179";
    	};

    };
    #
    # This is the view that we present to the outside world
    #
    view "external" {
    	match-clients { any; };
    	#
    	# If we can't answer the query, we tell the client so
    	#
    	recursion no;

    	zone "foobar.net" in {
    		type master;
    		notify yes;
    		allow-update {none; };
    		allow-transfer { <secondary NS IP>; };
    		file "ext/db.foobar";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
     		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.176";
    	};

    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.179";
    	};
    };
    -
    -
    -
    - -
    -

    Here are the files in /var/named (those not shown are usually +

    +
    +
    + +
    +

    Here are the files in /var/named (those not shown are usually included in your bind disbribution).

    - -

    db.192.0.2.176 - This is the reverse zone for the firewall's + +

    db.192.0.2.176 - This is the reverse zone for the firewall's external interface

    - -
    + +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
    ; Filename: db.192.0.2.176
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
    -
    -
    - -
    -
    db.192.0.2.177 - This is the reverse zone for the www/DNS - server -
    +
    +
    + +
    +
    db.192.0.2.177 - This is the reverse zone for the www/DNS + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
    ; Filename: db.192.0.2.177
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.178 - This is the reverse zone for the mail - server -
    +
    +
    +
    + +
    +
    db.192.0.2.178 - This is the reverse zone for the mail + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
    ; Filename: db.192.0.2.178
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.179 - This is the reverse zone for daughter's - web server's public IP -
    +
    +
    +
    + +
    +
    db.192.0.2.179 - This is the reverse zone for daughter's + web server's public IP +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
    ; Filename: db.192.0.2.179
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
    -
    -
    -
    - -
    + +
    +
    + +

    int/db.127.0.0 - The reverse zone for localhost

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
    ; Filename: db.127.0.0
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    				2001092901 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR	localhost.foobar.net.
    -
    -
    - -
    -

    int/db.192.168.201 - Reverse zone for the local net. This + +

    + +
    +

    int/db.192.168.201 - Reverse zone for the local net. This is only shown to internal clients

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
    ; Filename: db.192.168.201
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR 	gateway.foobar.net.
    2	86400		IN PTR	winken.foobar.net.
    3	86400		IN PTR	blinken.foobar.net.
    4	86400		IN PTR	nod.foobar.net.
    -
    + +
    + +
    +

    int/db.192.168.202 - Reverse zone for the firewall's DMZ + interface

    - -
    -

    int/db.192.168.202 - Reverse zone for the firewall's DMZ - interface

    -
    - -
    -
    -
    + +
    +
    + 
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
    ; Filename: db.192.168.202
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @		604800	IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1 		86400 IN PTR	dmz.foobar.net.
    -
    -
    -
    - -
    +
    +
    +
    + +

    int/db.foobar - Forward zone for use by internal clients.

    -
    - -
    -
    +
    + +
    +
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002071501 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; foobar.net Nameserver Records (NS)
    ;############################################################
    @ 		604800	IN NS	ns1.foobar.net.

    ;############################################################
    ; Foobar.net Office Records (ADDRESS)
    ;############################################################
    localhost	86400 	IN A 	127.0.0.1

    firewall	86400	IN A	192.0.2.176
    www		86400	IN A	192.0.2.177
    ns1 		86400	IN A 	192.0.2.177
    www		86400	IN A	192.0.2.177

    gateway		86400	IN A 	192.168.201.1
    winken		86400	IN A 	192.168.201.2
    blinken		86400	IN A	192.168.201.3
    nod		86400	IN A	192.168.201.4
    -
    -
    - -
    + +
    + +

    ext/db.foobar - Forward zone for external clients

    -
    - -
    -
    -
    +
    + +
    +
    + 
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002052901 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; Foobar.net Nameserver Records (NS)
    ;############################################################
    @		86400	IN NS	ns1.foobar.net.
    @		86400	IN NS	<secondary NS>.
    ;############################################################
    ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
    ;############################################################
    localhost	86400	IN A	127.0.0.1
    ;
    ; The firewall itself
    ;
    firewall	86400	IN A	192.0.2.176
    ;
    ; The DMZ
    ;
    ns1		86400	IN A	192.0.2.177
    www		86400	IN A	192.0.2.177
    mail		86400	IN A	192.0.2.178
    ;
    ; The Local Network
    ;
    nod		86400	IN A	192.0.2.179

    ;############################################################
    ; Current Aliases for foobar.net (CNAME)
    ;############################################################

    ;############################################################
    ; foobar.net MX Records (MAIL EXCHANGER)
    ;############################################################
    foobar.net.	86400	IN A	192.0.2.177
    		86400 	IN MX 0 mail.foobar.net.
    		86400	IN MX 1 <backup MX>.
    -
    -
    -
    - -
    -

    7.0 Starting and Stopping +

    +
    +
    + +
    +

    7.0 Starting and Stopping Your Firewall

    -
    - -
    -

    The installation procedure configures +

    + +
    +

    The installation procedure configures your system to start Shorewall at system boot.

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter +

    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, +routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter configuration, use "shorewall clear".

    -
    - -
    +
    + +

    -     Edit the /etc/shorewall/routestopped file and configure those - systems that you want to be able to access the firewall when it is -stopped.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall +     Edit the /etc/shorewall/routestopped file and configure +those systems that you want to be able to access the firewall when +it is stopped.

    +
    + + - -

    Last updated 3/21/2003 - + +

    Last updated 5/3/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep

    -
    +
    +



    diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index c9685641f..bb1b38554 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -1,281 +1,376 @@ - + + Shoreline Firewall (Shorewall) 1.3 - + + - + - - - + + + - - - + + + + +
    - +
    + +

    Shorwall Logo - Shorewall 1.4 - "iptables made easy"
    - - Shorewall 1.3 Site here
    - Shorewall -1.2 Site here
    -     +
    +     -

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

    What is it?

    - -

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

    - + +

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

    + + +

    This program is free software; you can redistribute it and/or modify - it under - the terms of Version 2 of the GNU General Public License as published by the Free Software Foundation.
    -
    - This program - is distributed in the hope that it will - be useful, but WITHOUT ANY WARRANTY; without - even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details.
    -
    - You should - have received a copy of the GNU General - Public License along with this program; - if not, write to the Free Software Foundation, - Inc., 675 Mass Ave, Cambridge, MA 02139, - USA

    - - + +
    + This + program is distributed in the hope that + it will be useful, but WITHOUT ANY WARRANTY; + without even the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. +See the GNU General Public License for more details.
    + +
    + You + should have received a copy of the GNU + General Public License along with + this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, + MA 02139, USA

    + + +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    - - -

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

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

    Getting Started with Shorewall

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

    News

    - - + + + +

    5/10/2003 - Shorewall Mirror in Asia (New) +
    +

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

    5/8/2003 - Shorewall Mirror in Chile (New) +  

    + +

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

    + +

    4/26/2003 - lists.shorewall.net Downtime (New) +  

    + +

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

    + +

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

    + +

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

    +

    4/12/2002 - Greater Seattle Linux Users Group Presentation (New) -

    - +

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

    4/9/2003 - Shorewall 1.4.2 (New) -
    -

    - +
    +

    + +

        Problems Corrected:

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

        New Features:

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

    - - -

    More News

    - - -

    - + + +

    More News

    + + + +

    + + + +

    (Leaf Logo) + Jacques + Nilo and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that + features Shorewall-1.3.14 and Kernel-2.4.20. + You can find their work at: http://leaf.sourceforge.net/devel/jnilo

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

    SourceForge Logo -

    - - + + + +

    - - + + +

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

    - - + + +

    Donations

    -
    -
    + +
    + +


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

    + +

    Quick Search
    + +

    + +
    + +

    Extended Search

    + +
    +
    -
    -
    - +
    +
    + - - - + - - - + to + Starlight +Children's Foundation. Thanks!

    + + + + +
    +
    - + +

    -

    +

    - + +

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

    -
    - -

    Updated 4/12/2003 - Tom Eastep -
    -

    -
    -
    + +

    Updated 5/10/2003 - Tom Eastep +
    +



    diff --git a/Shorewall-docs/standalone.htm b/Shorewall-docs/standalone.htm index 39f503727..8e1a8dc14 100644 --- a/Shorewall-docs/standalone.htm +++ b/Shorewall-docs/standalone.htm @@ -1,425 +1,427 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
    +

    Standalone Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up Shorewall on a standalone Linux system is very - easy if you understand the basics and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its most common configurations:

    - + +

    Setting up Shorewall on a standalone Linux system is very + easy if you understand the basics and follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its most common configurations:

    +
      -
    • Linux system
      • -
    • Single external IP address
      • -
    • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
      • - +
    • Linux system
      • +
    • Single external IP address
      • +
    • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
      • +
    - -

    Shorewall requires that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program on - your firewall system. As root, you can use the 'which' command to check - for this program:

    - + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program +on your firewall system. As root, you can use the 'which' command to +check for this program:

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you read through the guide first to familiarize yourself - with what's involved then go back through it again making your configuration - changes.  Points at which configuration changes are recommended are flagged - with - .

    - + +

    I recommend that you read through the guide first to familiarize yourself + with what's involved then go back through it again making your configuration + changes.  Points at which configuration changes are recommended are +flagged with + .

    +

    -     If you edit your configuration files on a Windows system, you -must save them as Unix files if your editor supports that option or you -must run them through dos2unix before trying to use them. Similarly, if -you copy a configuration file from your Windows hard drive to a floppy disk, -you must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, you + must save them as Unix files if your editor supports that option or you + must run them through dos2unix before trying to use them. Similarly, if + you copy a configuration file from your Windows hard drive to a floppy +disk, you must run dos2unix against the copy before using it with Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed Shorewall, download the one-interface -sample, un-tar it (tar -zxvf one-interface.tgz) and and copy the files -to /etc/shorewall (they will replace files with the same names that were -placed in /etc/shorewall during Shorewall installation).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the one-interface sample configuration, only one - zone is defined:

    - + href="http://www1.shorewall.net/pub/shorewall/Samples/">one-interface sample, + un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall + during Shorewall installation)    .

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only +one zone is defined:

    + - + + + + + - - - - - - - - - + + + + +
    NameDescription
    NameDescription
    netThe Internet
    netThe Internet
    - +

    Shorewall zones are defined in /etc/shorewall/zones.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    + - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  - the request is first checked against the rules in /etc/shorewall/common -(the samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the one-interface sample has -the following policies:

    - -
    + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the one-interface sample +has the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT  
    netall
    -     		DROPinfo 
    allallREJECTinfo 
    fwnetACCEPT  
    netall
    +     		DROPinfo 
    allallREJECTinfo 
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from the firewall to the internet
      2. -
    2. drop (ignore) all connection requests from the internet to +
    3. allow all connection requests from the firewall to the internet
      4. +
    4. drop (ignore) all connection requests from the internet to your firewall
      5. -
    5. reject all other connection requests (Shorewall requires this - catchall policy).
      6. - +
    6. reject all other connection requests (Shorewall requires this + catchall policy).
      7. +
    - -

    At this point, edit your /etc/shorewall/policy and make any changes that - you wish.

    - + +

    At this point, edit your /etc/shorewall/policy and make any changes that + you wish.

    +

    External Interface

    - -

    The firewall has a single network interface. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter (eth0) that is connected to that "Modem"  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be - a ppp0. If you connect via a regular modem, your External Interface - will also be ppp0. If you connect using ISDN, your external interface - will be ippp0.

    - + +

    The firewall has a single network interface. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter (eth0) that is connected to that +"Modem"  unless you connect via Point-to-Point +Protocol over Ethernet (PPPoE) or Point-to-Point +Tunneling Protocol (PPTP) in which case the External +Interface will be a ppp0. If you connect via a regular modem, your +External Interface will also be ppp0. If you connect using ISDN, +your external interface will be ippp0.

    +

    -     The Shorewall one-interface sample configuration assumes that the - external interface is eth0. If your configuration is different, - you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interface. Some hints:

    - +     The Shorewall one-interface sample configuration assumes that +the external interface is eth0. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that +are specified for the interface. Some hints:

    +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

      -
      • - +
    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the +option list.

      +
      • +
    - -
    + +

    IP Addresses

    -
    - -
    -

    RFC 1918 reserves several Private IP address ranges - for use in private networks:

    - -
    +
    + +
    +

    RFC 1918 reserves several Private IP address ranges + for use in private networks:

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -

    These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation - to rewrite packet headers when forwarding to/from the internet.

    - +
    + +

    These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, +ISPs are assigning these addresses then using Network Address Translation + to rewrite packet headers when forwarding to/from the internet.

    +

    -      Before starting Shorewall, you should look at the IP address - of your external interface and if it is one of the above ranges, you -should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

    -
    - -
    -

    Enabling other Connections

    +      Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you + should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

    - -
    -

    If you wish to enable connections from the internet to your - firewall, the general format is:

    -
    - -
    -
    + +
    +

    Enabling other Connections

    +
    + +
    +

    If you wish to enable connections from the internet to your + firewall, the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a Web Server and a POP3 Server +on your firewall system:

    - -
    -

    Example - You want to run a Web Server and a POP3 Server on -your firewall system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80  
    ACCEPTnetfwtcp110  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80  
    ACCEPTnetfwtcp110  
    -
    -
    - -
    -

    If you don't know what port and protocol a particular application +

    +
    + +
    +

    If you don't know what port and protocol a particular application uses, see here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want - shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you +want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    -     At this point, edit /etc/shorewall/rules to add other connections - as desired.

    -
    - -
    -

    Starting and Stopping Your Firewall

    +     At this point, edit /etc/shorewall/rules to add other connections + as desired.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Users of the .deb - package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. -Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the + +

    IMPORTANT: Users of the .deb + package must edit /etc/default/shorewall and set 'startup=1'.
    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, +routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

    +
    + +
    +

    WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have + added an entry for the IP address that you are connected from to +/etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

    -
    - +
    +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 -Thomas M. Eastep

    -
    + +

    Copyright 2002, 2003 + Thomas M. Eastep

    +
    +



    diff --git a/Shorewall-docs/standalone_fr.html b/Shorewall-docs/standalone_fr.html index c759eae76..2adbb753d 100755 --- a/Shorewall-docs/standalone_fr.html +++ b/Shorewall-docs/standalone_fr.html @@ -1,469 +1,469 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
    +

    Standalone Firewall

    -
    - +

    Version 2.0.1 Française

    - +

    Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail n'est -pas des plus précis (loin de là...). Je ne me suis pas attaché à une traduction -exacte du texte, mais plutôt à en faire une version française intelligible -par tous (et par moi). Les termes techniques sont la plupart du temps conservés -sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver -dans le reste des documentations ainsi que dans les fichiers de configuration. -N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM pour -sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour son -formidable outil et sa disponibilité)    .

    - -

    Mettre en place un système Linux en tant que firewall (écluse) -pour un petit réseau est une chose assez simple, si vous comprenez les bases + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail +n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à une +traduction exacte du texte, mais plutôt à en faire une version française +intelligible par tous (et par moi). Les termes techniques sont la plupart +du temps conservés sous leur forme originale et mis entre parenthèses car +vous pouvez les retrouver dans le reste des documentations ainsi que dans +les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer +ce document VETSEL Patrice +(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à +Tom EASTEP pour son formidable outil et sa disponibilité).

    + +

    Mettre en place un système Linux en tant que firewall (écluse) +pour un petit réseau est une chose assez simple, si vous comprenez les bases et suivez la documentation.

    - -

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il -se focalise sur ce qui est nécessaire pour configurer Shorewall, dans son -utilisation la plus courante :

    - + +

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il se +focalise sur ce qui est nécessaire pour configurer Shorewall, dans son utilisation +la plus courante :

    +
      -
    • Un système Linux
      • -
    • Une seule adresse IP externe
      • -
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay, +
    • Un système Linux
      • +
    • Une seule adresse IP externe
      • +
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay, rtc...
      • - +
    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. -Vous pouvez voir si le paquet est installé en vérifiant la présence du programme -ip sur votre système de firewall. Sous root, utilisez la commande 'which' + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous +pouvez voir si le paquet est installé en vérifiant la présence du programme +ip sur votre système de firewall. Sous root, utilisez la commande 'which' pour rechercher le programme :

    - + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    Je vous recommande dans un premier temps de parcourir tout le guide pour -vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant -le changements dans votre configuration. Les points, où les changements dans + +

    Je vous recommande dans un premier temps de parcourir tout le guide pour +vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant +le changements dans votre configuration. Les points, où les changements dans la configuration sont recommandées, sont signalés par une - .

    - + .

    +

    - Si vous éditez vos fichiers de configuration sur un système Windows, vous -devez les sauver comme des fichiers Unix si votre éditeur supporte cette option -sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser. -De la même manière, si vous copiez un fichier de configuration depuis votre -disque dur Windows vers une disquette, vous devez lancer dos2unix sur la -copie avant de l'utiliser avec Shorewall.

    - + Si vous éditez vos fichiers de configuration sur un système Windows, vous + devez les sauver comme des fichiers Unix si votre éditeur supporte cette +option sinon vous devez les faire passer par dos2unix avant d'essayer de +les utiliser. De la même manière, si vous copiez un fichier de configuration +depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix +sur la copie avant de l'utiliser avec Shorewall.

    + - +

    Les Concepts de Shorewall

    - +

    - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec + Les fichiers de configuration pour Shorewall sont situés dans le répertoire + /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez le one-interface -sample, un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers -vers /etc/shorewall (Ils remplaceront les fichiers de même nom déjà existant -dans /etc/shorewall installés lors de l'installation de Shorewall).

    - -

    Parallèlement à la description, je vous suggère de jeter un oeil à ceux -physiquement présents sur votre système -- chacun des fichiers contient des + href="http://www1.shorewall.net/pub/shorewall/Samples/">one-interface sample, +un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers vers /etc/shorewall + (Ils remplaceront les fichiers de même nom déjà existant dans /etc/shorewall +installés lors de l'installation de Shorewall).

    + +

    Parallèlement à la description, je vous suggère de jeter un oeil à ceux +physiquement présents sur votre système -- chacun des fichiers contient des instructions de configuration détaillées et des entrées par défaut.

    - -

    Shorewall voit le réseau où il tourne comme composé par un ensemble de -zones. Dans les fichiers de configuration fournis pour une unique -interface, une seule zone est définie :

    - + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de +zones. Dans les fichiers de configuration fournis pour une unique interface, +une seule zone est définie :

    + - - - - - - - - - - - + + + + + + + + + + +
    NameDescription
    netThe Internet
    NameDescription
    netThe Internet
    - +

    Les zones de Shorewall sont définies dans /etc/shorewall/zones.

    - -

    Shorewall reconnaît aussi le système de firewall comme sa propre zone -- par défaut, le firewall lui-même est connu en tant que fw.

    - -

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone - +par défaut, le firewall lui-même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées en utilisant les termes de zones.

    - + - -

    Pour chacune des demandes de connexion entrantes dans le firewall, les -demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. -Si aucune des règles dans ce fichier ne correspondent, alors la première -politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette -politique est REJECT ou DROP la requête est alors comparée par rapport aux -règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit -ce fichier).

    - -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les +demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. +Si aucune des règles dans ce fichier ne correspondent, alors la première politique +dans /etc/shorewall/policy qui y correspond est appliquée. Si cette politique +est REJECT ou DROP la requête est alors comparée par rapport aux règles contenues +dans /etc/shorewall/common (l'archive d'exemple vous fournit ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface a les politiques suivantes :

    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    -
    -
    netall
    -     		DROPinfo
    -
    allallREJECTinfo
    -
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    +
    +
    netall
    +     		DROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    +
    - Ces politiques vont : + Ces politiques vont :
      -
    1. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers -votre firewall
      3. -
    3. rejeter toutes les autres requêtes de connexion (Shorewall à besoin +
    4. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      5. +
    5. drop (ignorer) toutes les demandes de connexion depuis l'Internet +vers votre firewall
      6. +
    6. rejeter toutes les autres requêtes de connexion (Shorewall à besoin de cette politique).
      7. - +
    - -

    A ce point, éditez votre /etc/shorewall/policy et faites y les changements + +

    A ce point, éditez votre /etc/shorewall/policy et faites y les changements que vous désirez.

    - +

    Interface Externe

    - -

    Le firewall possède une seule interface réseau. Lorsque la -connexion Internet passe par un modem câble ou par un routeur ADSL (pas un -simple modem), l'External Interface (interface externe) sera l'adaptateur -ethernet (eth0) qui y est connecté à moins que vous vous connectiez -par Point-to-Point Protocol over Ethernet -(PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) -dans ce cas l'interface externe sera ppp0. Si vous vous connectez -par un simple modem (RTC), votre interface externe sera aussi ppp0. -Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe + +

    Le firewall possède une seule interface réseau. Lorsque la +connexion Internet passe par un modem câble ou par un routeur ADSL (pas un +simple modem), l'External Interface (interface externe) sera l'adaptateur +ethernet (eth0) qui y est connecté à moins que vous vous connectiez +par Point-to-Point Protocol over Ethernet +(PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) + dans ce cas l'interface externe sera ppp0. Si vous vous connectez +par un simple modem (RTC), votre interface externe sera aussi ppp0. + Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe sera ippp0.

    - +

    - L'exemple de configuration de Shorewall pour une interface suppose que votre -interface externe est eth0. Si votre configuration est différente, -vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. - Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont + L'exemple de configuration de Shorewall pour une interface suppose que +votre interface externe est eth0. Si votre configuration est différente, +vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. + Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont spécifiées pour l'interface. Quelques astuces :

    - +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, -vous pouvez remplacer le "detect" dans la seconde colonne par un "-". +

    • +

      Si votre interface externe est ppp0 ou ippp0, + vous pouvez remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 -ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" +

      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 + ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la liste d'option.

      -
      • - + +
    - -
    + +

    Adresse IP

    -
    - -
    -

    La RFC 1918 définie plusieurs plage d'adresses IP privée -(PrivateIP) pour l'utilisation dans des réseaux privés :

    - -
    +
    + +
    +

    La RFC 1918 définie plusieurs plage d'adresses IP privée (PrivateIP) +pour l'utilisation dans des réseaux privés :

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -

    Ces adresses sont parfois désignées comme étant non-routables -car les routeurs sur les backbones Internet ne font pas passer les paquets -dont les adresses de destinations sont définies dans la RFC 1918. Dans certains -cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent -le Network Address Translation afin de récrire les entêtes des paquets +

    + +

    Ces adresses sont parfois désignées comme étant non-routables + car les routeurs sur les backbones Internet ne font pas passer les paquets +dont les adresses de destinations sont définies dans la RFC 1918. Dans certains +cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent +le Network Address Translation afin de récrire les entêtes des paquets lorsqu'ils les font circuler depuis ou vers l'Internet.

    - +

    - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface -externe et si elle est comprise dans une des plages précédentes, vous devriez + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface +externe et si elle est comprise dans une des plages précédentes, vous devriez enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    -
    - -
    +
    + +

    Permettre d'autres connexions

    -
    - -
    -

    Si vous désirez autoriser d'autres connexions depuis l'Internet +

    + +
    +

    Si vous désirez autoriser d'autres connexions depuis l'Internet vers votre firewall, le format général est :

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    +
    +
    -
    -
    - -
    -

    Exemple - Vous voulez faire tourner un serveur Web et un -serveur POP3 sur votre système de firewall :

    -
    - -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur Web et un serveur +POP3 sur votre système de firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    -
    -
    ACCEPTnetfwtcp110
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    +
    +
    ACCEPTnetfwtcp110
    +
    +
    -
    -
    - -
    -

    Si vous ne savez pas quel port ou protocole une application + +

    + +
    +

    Si vous ne savez pas quel port ou protocole une application particulière utilise, regardez ici.

    -
    - -
    -

    Important: Je ne vous recommande pas d'autoriser le -telnet depuis ou vers l'Internet car il utilise du texte en clair (même pour -le login et le mot de passe !). Si vous voulez avoir un accès au shell de +

    + +
    +

    Important: Je ne vous recommande pas d'autoriser le +telnet depuis ou vers l'Internet car il utilise du texte en clair (même pour +le login et le mot de passe !). Si vous voulez avoir un accès au shell de votre firewall depuis Internet, utilisez SSH :

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    - -
    + +
    + +
         ACCEPT	net	fw	tcp	22
    -
    - -
    +
    + +

    - A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions + A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions désirées.

    -
    - -
    +
    + +

    Lancer et Arrêter son Firewall

    -
    - -
    +
    + +

    Arrow - La procédure d'installation configure votre système -pour lancer Shorewall au boot du système, mais au début avec la version 1.3.9 -de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall -avec que la configuration soit finie. Une fois que vous en aurez fini avec -la configuration du firewall, vous pouvez permettre le lancement de Shorewall + La procédure d'installation configure votre +système pour lancer Shorewall au boot du système, mais au début avec la version +1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall +avec que la configuration soit finie. Une fois que vous en aurez fini avec +la configuration du firewall, vous pouvez permettre le lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Les utilisateurs -des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    - -
    -

    Le firewall est activé en utilisant la commande "shorewall -start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le +

    + +

    IMPORTANT: Les utilisateurs des +paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall +start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un -firewall qui tourne peut être relancé en utilisant la commande "shorewall -restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. Un +firewall qui tourne peut être relancé en utilisant la commande "shorewall +restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration de Netfilter, utilisez "shorewall clear".

    -
    - -
    -

    ATTENTION: Si vous êtes connecté à votre firewall -depuis Internet, n'essayez pas une commande "shorewall stop" tant que vous -n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle -vous êtes connectée) dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; +

    + +
    +

    ATTENTION: Si vous êtes connecté à votre firewall depuis +Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez +pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous +êtes connectée) dans /etc/shorewall/routestopped. + De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; il est plus intéressant de créer une configuration alternative -et de la tester en utilisant la commande configuration alternative + et de la tester en utilisant la commande "shorewall try".

    -
    - +
    +

    Last updated 12/9/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas + +

    Copyright 2002 Thomas M. Eastep

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

    diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 2a3f8e80e..a646d340e 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,75 +1,79 @@ - + - + Shorewall Support Guide - + - - - + + - - - + + + + +
    +
    +

    Shorewall Support Guide -

    -
    - +

    Before Reporting a Problem or Asking a Question
    -

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

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + - Format: + Format: - Sort by: + Sort by: - Include Mailing - List Archives: + Include Mailing List Archives: + -
    - Search:
    -
    -
    - +
    + Search:
    + +
    +

    Problem Reporting Guidelines
    -

    - + +
      -
    • Please remember we only know what is posted - in your message. Do not leave out any information that appears - to be correct, or was mentioned in a previous post. There have - been countless posts by people who were sure that some part of -their configuration was correct when it actually contained a small -error. We tend to be skeptics where detail is lacking.
      -
      -
      • -
    • Please keep in mind that you're asking -for free technical support. Any help we -offer is an act of generosity, not an obligation. Try to make it -easy for us to help you. Follow good, courteous practices in writing -and formatting your e-mail. Provide details that we need if you expect -good answers. Exact quoting of error messages, log entries, - command output, and other output is better than a paraphrase or summary.
      -
      -
      • -
    • Please - don't describe your environment and then ask us to send -you custom configuration files. We're here to answer - your questions but we can't do your job for you.
      -
      -
      • -
    • When reporting a problem, ALWAYS - include this information:
      • - +
    • Please remember we only know what + is posted in your message. Do not leave out any information + that appears to be correct, or was mentioned in a previous +post. There have been countless posts by people who were sure + that some part of their configuration was correct when it actually + contained a small error. We tend to be skeptics where detail + is lacking.
      +
      +
      • +
    • Please keep in mind that you're +asking for free technical support. +Any help we offer is an act of generosity, not an obligation. + Try to make it easy for us to help you. Follow good, courteous +practices in writing and formatting your e-mail. Provide details that + we need if you expect good answers. Exact quoting of +error messages, log entries, command output, and other output is better + than a paraphrase or summary.
      +
      +
      • +
    • + Please don't describe your environment and then ask us + to send you custom configuration files. We're here + to answer your questions but we can't do your + job for you.
      +
      +
      • +
    • When reporting a problem, ALWAYS + include this information:
      • +
    - +
      - +
        -
      • the exact version of Shorewall you are - running.
        -
        - shorewall version
        -
        -
        • - +
      • the exact version of Shorewall +you are running.
        +
        + shorewall + version
        +
        +
        • +
      - +
        -
      • the exact kernel version you are running
        -
        - uname -a
        -
        -
        • - +
      • the exact kernel version you are + running
        +
        + uname -a
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip addr show
        -
        -
        • - +
      • the complete, exact output of
        +
        + ip addr +show
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip route show
        -
        -
        • - +
      • the complete, exact output of
        +
        + ip route + show
        +
        +
        • +
      - +
        -
      • If your kernel is modularized, the exact - output from
        -
        - lsmod
        -
        • - +
      • If your kernel is modularized, +the exact output from
        +
        + lsmod
        +
        • +
      - +
    - +
      - +
        -
      • If you are having connection - problems of any kind then:
        -
        - 1. /sbin/shorewall/reset
        -
        - 2. Try the connection that is failing.
        -
        - 3. /sbin/shorewall status > -/tmp/status.txt
        -
        - 4. Post the /tmp/status.txt file as an attachment.
        -
        -
        • -
      • the exact wording of any If you are having connection + problems of any kind then:
        +
        + 1. /sbin/shorewall/reset
        +
        + 2. Try the connection that is failing.
        +
        + 3. /sbin/shorewall status + > /tmp/status.txt
        +
        + 4. Post the /tmp/status.txt file as an attachment.
        +
        +
        • +
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart Guides, - please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using the Mandrake - installation of Shorewall, please say so.
        -
        -
        • - +
        + +
      • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
        +
        +
        • +
      • If you are running Shorewall under Mandrake using the + Mandrake installation of Shorewall, please say so.
        +
        +
        • +
      -
    • As a -general matter, please do not edit the diagnostic information - in an attempt to conceal your IP address, netmask, nameserver - addresses, domain name, etc. These aren't secrets, and concealing -them often misleads us (and 80% of the time, a hacker could derive them - anyway from information contained in the SMTP headers of your post).
      -
      -
      • -
    • Do you see any "Shorewall" messages ("As + a general matter, please do not edit the diagnostic + information in an attempt to conceal your IP address, + netmask, nameserver addresses, domain name, etc. These aren't +secrets, and concealing them often misleads us (and 80% of the time, +a hacker could derive them anyway from information contained in +the SMTP headers of your post).
      +
      +
      • +
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when - you exercise the function that is giving you problems? If so, include - the message(s) in your post along with a copy of your /etc/shorewall/interfaces - file.
      -
      -
      • -
    • Please include any of the Shorewall configuration files - (especially the /etc/shorewall/hosts file if you have - modified that file) that you think are relevant. If - you include /etc/shorewall/rules, please include /etc/shorewall/policy - as well (rules are meaningless unless one also knows the policies).
      -
      -
      • -
    • If an error occurs when you try to " +
      +
      • +
    • Please include any of the Shorewall configuration + files (especially the /etc/shorewall/hosts file if +you have modified that file) that you think are relevant. + If you include /etc/shorewall/rules, please include /etc/shorewall/policy + as well (rules are meaningless unless one also knows the policies).
      +
      +
      • +
    • If an error occurs when you try to "shorewall start", include a trace - (See the Troubleshooting section for - instructions).
      -
      -
      • -
    • The list server limits posts to 120kb so don't post - GIFs of your network layout, etc. to the Mailing - List -- your post will be rejected.
      • - + (See the Troubleshooting + section for instructions).
      +
      + +
    • The list server limits posts to 120kb so don't + post GIFs of your network layout, etc. to +the Mailing List -- your post will be rejected.
      • +
    - +
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray - Olszewski found at Ray + Olszewski found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    -
    - + +

    When using the mailing list, please post in plain text

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

    Where to Send your Problem Report or to Ask for Help

    - -
    + +
    If you have a quick question about +capabilities or where to find something, you may use the Shorewall Support + Forum. DO NOT POST THE OUTPUT OF "shorewall status" TO THE FORUM; + I WON'T LOOK AT IT. If you need to supply "shorewall status" +output, use the appropriate mailing list below.
    +

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

    - If you run Shorewall under MandrakeSoft - Multi Network Firewall (MNF) and you have not purchased an MNF - license from MandrakeSoft then you can post non MNF-specific Shorewall - questions to the LEAF Users mailing + list. + If you run Shorewall under MandrakeSoft + Multi Network Firewall (MNF) and you have not purchased an + MNF license from MandrakeSoft then you can post non MNF-specific + Shorewall questions to the Shorewall users mailing - list or the Shorewall Support -Forum. Do not expect to get free MNF support on the list or forum.
    - + list. Do not expect to get free MNF support on the list.
    +

    Otherwise, please post your question or problem to the Shorewall users mailing - list or to the Shorewall Support -Forum.
    - To Subscribe to the mailing list go to .

    + +

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

    -
    - + .
    +

    +
    +

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

    - -

    Last Updated 4/10/2003 - Tom Eastep

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

    + +

    Last Updated 5/12/2003 - Tom Eastep

    +

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

    -
    -
    -
    -
    -
    -
    -
    +
    +

    diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm index 404f0e789..f5a621fb7 100644 --- a/Shorewall-docs/three-interface.htm +++ b/Shorewall-docs/three-interface.htm @@ -1,1195 +1,1198 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the -basics and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its more popular configurations:

    - + +

    Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the + basics and follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its more popular configurations:

    +
      -
    • Linux system used as a firewall/router for a small +
    • Linux system used as a firewall/router for a small local network.
      • -
    • Single public IP address.
      • -
    • DMZ connected to a separate ethernet interface.
      • -
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, - dial-up, ...
      • - +
    • Single public IP address.
      • +
    • DMZ connected to a separate ethernet interface.
      • +
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, + dial-up, ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

    Shorewall requires that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can -tell if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command to - check for this program:

    - -
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are - flagged with - . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo)

    - + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can + tell if this package is installed by the presence of an ip +program on your firewall system. As root, you can use the 'which' +command to check for this program:

    + +
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    + +

    I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are + flagged with + . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo) +

    +

    -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, + you must save them as Unix files if your editor supports that option + or you must run them through dos2unix before trying to use them. Similarly, + if you copy a configuration file from your Windows hard drive to a +floppy disk, you must run dos2unix against the copy before using it with +Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only need to deal with a - few of these as described in this guide. After you have installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy - the files to /etc/shorewall (the files will replace files with the same - names that were placed in /etc/shorewall when Shorewall was installed).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, -the following zone names are used:

    - + href="http://www.shorewall.net/pub/shorewall/Samples/">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the +same names that were placed in /etc/shorewall when Shorewall was installed)    .

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration +instructions and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, + the following zone names are used:

    + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    - -

    Zone names are defined in /etc/shorewall/zones.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - - - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that -file matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or -DROP  the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -
    -

    In the three-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

    +

    Zone names are defined in /etc/shorewall/zones.

    + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    + + + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that + file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or + DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - +
    + +
    +

    In the three-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

    + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network - to the internet
      2. -
    2. drop (ignore) all connection requests from the internet - to your firewall or local network
      3. -
    3. optionally accept all connection requests from the +
    4. allow all connection requests from your local network + to the internet
      5. +
    5. drop (ignore) all connection requests from the internet + to your firewall or local network
      6. +
    6. optionally accept all connection requests from the firewall to the internet (if you uncomment the additional policy)
      7. -
    7. reject all other connection requests.
      8. - +
    8. reject all other connection requests.
      9. +
    - +

    -     At this point, edit your /etc/shorewall/policy file and - make any changes that you wish.

    - +     At this point, edit your /etc/shorewall/policy file +and make any changes that you wish.

    +

    Network Interfaces

    - +

    -

    - -

    The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., - eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect -via a regular modem, your External Interface will also be ppp0. -If you connect using ISDN, you external interface will be ippp0.

    - +

    + +

    The firewall has three network interfaces. Where Internet + connectivity is through a cable or DSL "Modem", the External +Interface will be the ethernet adapter that is connected to +that "Modem" (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect + via a regular modem, your External Interface will also be ppp0. + If you connect using ISDN, you external interface will be ippp0.

    +

    -     If your external interface is ppp0 or ippp0 -then you will want to set CLAMPMSS=yes in ppp0 or ippp0 + then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    - -

    Your Local Interface will be an ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local - computers will be connected to the same switch (note: If you have only - a single local system, you can connect the firewall directly to the -computer using a cross-over cable).

    - -

    Your DMZ Interface will also be an ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your - DMZ computers will be connected to the same switch (note: If you have - only a single DMZ system, you can connect the firewall directly to the - computer using a cross-over cable).

    - + +

    Your Local Interface will be an ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local + computers will be connected to the same switch (note: If you have +only a single local system, you can connect the firewall directly to +the computer using a cross-over cable).

    + +

    Your DMZ Interface will also be an ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your + DMZ computers will be connected to the same switch (note: If you have + only a single DMZ system, you can connect the firewall directly to +the computer using a cross-over cable).

    +

    - Do not connect more than one interface to the same -hub or switch (even for testing). It won't work the way that you expect - it to and you will end up confused and believing that Shorewall doesn't - work at all.

    - +     Do not connect more than one interface to the same + hub or switch (even for testing). It won't work the way that you +expect it to and you will end up confused and believing that Shorewall +doesn't work at all.

    +

    -     The Shorewall three-interface sample configuration assumes - that the external interface is eth0, the local interface is -eth1 and the DMZ interface is eth2. If your configuration -is different, you will have to modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the list - of options that are specified for the interfaces. Some hints:

    - +     The Shorewall three-interface sample configuration assumes + that the external interface is eth0, the local interface is + eth1 and the DMZ interface is eth2. If your configuration + is different, you will have to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the +list of options that are specified for the interfaces. Some hints:

    +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the - option list.

      -
      • - +
    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from +the option list.

      +
      • +
    - +

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via -the Dynamic Host Configuration Protocol (DHCP) or as part of establishing - your connection when you dial in (standard modem) or establish your PPP - connection. In rare cases, your ISP may assign you a static IP -address; that means that you configure your firewall's external interface - to use that address permanently. Regardless of how the address -is assigned, it will be shared by all of your systems when you access the -Internet. You will have to assign your own addresses for your internal network -(the local and DMZ Interfaces on your firewall plus your other computers). + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via + the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. Regardless of how the address + is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses for your internal +network (the local and DMZ Interfaces on your firewall plus your other computers). RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    +
    + +

    -     Before starting Shorewall, you should look at the IP -address of your external interface and if it is one of the above -ranges, you should remove the 'norfc1918' option from the external -interface's entry in /etc/shorewall/interfaces.

    -
    - -
    -

    You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another - subnet. For our purposes, we can consider a subnet to consists of -a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a -Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved -as the Subnet Address and x.y.z.255 is reserved as the Subnet -Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive "1" bits from - the left of the subnet mask.

    -
    - -
    +     Before starting Shorewall, you should look at the +IP address of your external interface and if it is one of the above + ranges, you should remove the 'norfc1918' option from the external + interface's entry in /etc/shorewall/interfaces.

    +
    + +
    +

    You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another + subnet. For our purposes, we can consider a subnet to consists of + a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have +a Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved +as the Subnet Address and x.y.z.255 is reserved as the Subnet + Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits +from the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    + +
    + +
    +

    It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above + example) or the last usable address (10.10.10.254).

    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).

    -
    - -
    -

    One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

    -
    - -
    + +
    +

    One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

    +
    + +

    -     Your local computers (Local Computers 1 & 2) should - be configured with their default gateway set to the IP address - of the firewall's internal interface and your DMZ computers ( DMZ - Computers 1 & 2) should be configured with their default gateway - set to the IP address of the firewall's DMZ interface.  

    -
    - -

    The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    The remainder of this quide will assume that you have configured - your network as shown here:

    - +     Your local computers (Local Computers 1 & 2) +should be configured with their default gateway set to the +IP address of the firewall's internal interface and your DMZ computers +( DMZ Computers 1 & 2) should be configured with their default +gateway set to the IP address of the firewall's DMZ interface.  

    +
    + +

    The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", +Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    The remainder of this quide will assume that you have configured + your network as shown here:

    +

    -

    - -

    The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.
    -

    - -

    -     WARNING: Your ISP  might assign - your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 - subnet then you will need to select a DIFFERENT RFC 1918 subnet for your - local network and if it is in the 10.10.11.0/24 subnet then you will need - to select a different RFC 1918 subnet for your DMZ.
    +

    + +

    The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.

    - -

    IP Masquerading (SNAT)

    - -

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume local computer 1) sends a connection - request to an internet host, the firewall must perform Network Address - Translation (NAT). The firewall rewrites the source address in the - packet to be the address of the firewall's external interface; in other - words, the firewall makes it look as if the firewall itself is initiating - the connection.  This is necessary so that the destination host will -be able to route return packets back to the firewall (remember that -packets whose destination address is reserved by RFC 1918 can't be routed -accross the internet). When the firewall receives a return packet, it - rewrites the destination address back to 10.10.10.1 and forwards the -packet on to local computer 1.

    - -

    On Linux systems, the above process is often referred to as - IP Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

    - -
      -
    • -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - -
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

    - -

    -     If your external firewall interface is eth0, your - local interface eth1 and your DMZ interface is eth2 then - you do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change it to match your configuration.

    - -

    -     If your external IP is static, you can enter it in the -third column in the /etc/shorewall/masq entry if you like although -your firewall will work fine if you leave that column empty. Entering -your static IP in column 3 makes
    - processing outgoing packets a little more efficient.
    -

    - +

    -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
    -

    - +     WARNING: Your ISP  might assign + your external interface an RFC 1918 address. If that address is in the +10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 +subnet for your local network and if it is in the 10.10.11.0/24 subnet then +you will need to select a different RFC 1918 subnet for your DMZ.
    +

    + +

    IP Masquerading (SNAT)

    + +

    The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When +one of your local systems (let's assume local computer 1) sends a +connection request to an internet host, the firewall must perform +Network Address Translation (NAT). The firewall rewrites the +source address in the packet to be the address of the firewall's external +interface; in other words, the firewall makes it look as if the firewall + itself is initiating the connection.  This is necessary so that the + destination host will be able to route return packets back to the firewall + (remember that packets whose destination address is reserved by RFC +1918 can't be routed accross the internet). When the firewall receives +a return packet, it rewrites the destination address back to 10.10.10.1 + and forwards the packet on to local computer 1.

    + +

    On Linux systems, the above process is often referred to +as IP Masquerading and you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - +
    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      +
      • +
    - + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

    + +

    +     If your external firewall interface is eth0, your + local interface eth1 and your DMZ interface is eth2 +then you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change it to match your configuration.

    + +

    +     If your external IP is static, you can enter it in the + third column in the /etc/shorewall/masq entry if you like although + your firewall will work fine if you leave that column empty. Entering + your static IP in column 3 makes
    + processing outgoing packets a little more efficient.
    +

    + +

    +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
    +

    + +
      +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • + +
    +

    Port Forwarding (DNAT)

    - -

    One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it -is not possible for clients on the internet to connect directly to them. - It is rather necessary for those clients to address their connection - requests to your firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When your - server responds, the firewall automatically performs SNAT to rewrite - the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure + +

    One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it + is not possible for clients on the internet to connect directly to +them. It is rather necessary for those clients to address their connection + requests to your firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When +your server responds, the firewall automatically performs SNAT to +rewrite the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

    - -
    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>  
    DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>  
    -
    - -

    If you don't specify the <server port>, it is assumed to be -the same as <port>.

    - -

    Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

    - -
    +
    + +

    If you don't specify the <server port>, it is assumed to +be the same as <port>.

    + +

    Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    -
    - +
    +

    A couple of important points to keep in mind:

    - +
      -
    • When you are connecting to your server from your local - systems, you must use the server's internal IP address (10.10.11.2).
      • -
    • Many ISPs block incoming connection requests to port -80. If you have problems connecting to your web server, try the +
    • When you are connecting to your server from your local + systems, you must use the server's internal IP address (10.10.11.2).
      • +
    • Many ISPs block incoming connection requests to port + 80. If you have problems connecting to your web server, try the following rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
      • - + href="http://w.x.y.z:5000"> http://w.x.y.z:5000 where w.x.y.z is your + external IP). +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    DNATnetdmz:10.10.11.2:80tcp5000  
    -
    - -

    If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can - replace the loc->dmz rule above with:

    - -
    +
    + +

    If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you +can replace the loc->dmz rule above with:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    - -

    If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows - (assume that your external interface is eth0):

    - +
    + +

    If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows + (assume that your external interface is eth0):

    +
      -
    1. Include the following in /etc/shorewall/params:
      -
      - ETH0_IP=`find_interface_address eth0`
      -  
      2. -
    2. Make your loc->dmz rule:
      3. - +
    3. Include the following in /etc/shorewall/params:
      +
      + ETH0_IP=`find_interface_address eth0`
      +  
      4. +
    4. Make your loc->dmz rule:
      5. +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    - -

    If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

    - +
    + +

    If you want to access your server from the DMZ using your external IP + address, see FAQ 2a.

    +

    -     At this point, add the DNAT and ACCEPT rules for your -servers.

    - +     At this point, add the DNAT and ACCEPT rules for your + servers.

    +

    Domain Name Server (DNS)

    - -

    Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file will - be written). Alternatively, your ISP may have given you the IP address - of a pair of DNS name servers for you to manually configure as - your primary and secondary name servers. It is your responsibility - to configure the resolver in your internal systems. You can take one - of two approaches:

    - + +

    Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file +will be written). Alternatively, your ISP may have given you the IP +address of a pair of DNS name servers for you to manually configure +as your primary and secondary name servers. It is your responsibility + to configure the resolver in your internal systems. You can take one + of two approaches:

    +
      -
    • -

      You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers - or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information - isn't available, look in /etc/resolv.conf on your firewall system --- the name servers are given in "nameserver" records in that file. -

      -
      • -
    • +
    • +

      You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system + -- the name servers are given in "nameserver" records in that file. +

      +
      • +

    • -     You can configure a Caching Name Server on your - firewall or in your DMZ. Red Hat has an RPM for a caching name - server (which also requires the 'bind' RPM) and for Bering users, - there is dnscache.lrp. If you take this approach, you configure your - internal systems to use the caching name server as their primary (and - only) name server. You use the internal IP address of the firewall (10.10.10.254 - in the example above) for the name server address if you choose to - run the name server on your firewall. To allow your local systems to -talk to your caching name server, you must open port 53 (both UDP -and TCP) from the local network to the server; you do that by adding -the rules in /etc/shorewall/rules.

      -
      • - -
    - -
    -

    If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    -

    Run name server on DMZ computer 1

    +     You can configure a Caching Name Server on your + firewall or in your DMZ. Red Hat has an RPM for a caching +name server (which also requires the 'bind' RPM) and for Bering +users, there is dnscache.lrp. If you take this approach, you configure +your internal systems to use the caching name server as their primary +(and only) name server. You use the internal IP address of the firewall +(10.10.10.254 in the example above) for the name server address if +you choose to run the name server on your firewall. To allow your local +systems to talk to your caching name server, you must open port 53 +(both UDP and TCP) from the local network to the server; you do that +by adding the rules in /etc/shorewall/rules.

    + + + +
    +

    If you run the name server on the firewall: - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    +

    + + +
    +
    +

    Run name server on DMZ computer 1

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    +
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The three-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy +allowing all connections from the firewall to the internet.

    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

    -
    - -
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    -
    + +
    + +
    +

    That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers + from your local systems.

    - -
    -

    That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers - from your local systems.

    -
    - -
    -

    If you wish to enable other connections between your systems, - the general format is:

    -
    - -
    -
    + +
    +

    If you wish to enable other connections between your systems, + the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a publicly-available DNS server + on your firewall system:

    - -
    -

    Example - You want to run a publicly-available DNS server - on your firewall system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    -
    +
    +
    + +
    +

    Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

    - -
    -

    Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

    -
    - -
    -

    If you don't know what port and protocol a particular application + +

    +

    If you don't know what port and protocol a particular application uses, look here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If +you want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    - +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible -with Jacques's Shorewall configuration.
    -

    - -
    -
    +     Bering users will want to add the following two rules to be compatible + with Jacques's Shorewall configuration.
    +

    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -
    ACCEPTlocfwtcp80#Allow weblet to work
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    -
    -
    - +
    +
    +

    -     Now modify /etc/shorewall/rules to add or remove other - connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    +     Now modify /etc/shorewall/rules to add or remove other + connections as required.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure -configures your system to start Shorewall at system boot  but beginning -with Shorewall version 1.3.9 startup is disabled so that your system -won't try to start Shorewall before configuration is complete. Once you -have completed configuration of your firewall, you can enable Shorewall +     The installation procedure + configures your system to start Shorewall at system boot  but beginning +with Shorewall version 1.3.9 startup is disabled so that your system +won't try to start Shorewall before configuration is complete. Once you +have completed configuration of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
    -

    - +

    +

    IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
    -

    + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall + and set 'startup=1'.
    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from + your Netfilter configuration, use "shorewall clear".

    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from -your Netfilter configuration, use "shorewall clear".

    -
    - -
    + +

    -     The three-interface sample assumes that you want to enable - routing to/from eth1 (your local network) and eth2 (DMZ) - when Shorewall is stopped. If these two interfaces don't connect -to your local network and DMZ or if you want to enable a different -set of hosts, modify /etc/shorewall/routestopped accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect + to your local network and DMZ or if you want to enable a different + set of hosts, modify /etc/shorewall/routestopped accordingly.

    +
    + + - +
    +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Eastep

    -
    + +

    Copyright 2002, 2003 + Thomas M. Eastep

    +
    +



    diff --git a/Shorewall-docs/three-interface_fr.html b/Shorewall-docs/three-interface_fr.html index 009f9c4f9..76d9e92d4 100755 --- a/Shorewall-docs/three-interface_fr.html +++ b/Shorewall-docs/three-interface_fr.html @@ -1,1204 +1,1212 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1 Française

    - +

    Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail -n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une -traduction exacte du texte, mais plutôt à en faire une version française -intelligible par tous (et par moi). Les termes techniques sont la plupart -du temps conservés sous leur forme originale et mis entre parenthèses car -vous pouvez les retrouver dans le reste des documentations ainsi que dans -les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer -ce document VETSEL Patrice -(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à -Tom EASTEP pour son formidable outil et sa disponibilité).

    - + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail +n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une +traduction exacte du texte, mais plutôt à en faire une version française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps conservés +sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver +dans le reste des documentations ainsi que dans les fichiers de configuration. +N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM +pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour +son formidable outil et sa disponibilité).

    +


    - Mettre en place un système linux en tant que firewall pour un petit réseau -contenant une DMZ est une chose assez simple à réaliser si vous comprenez -les bases et suivez cette documentation.

    - -

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités -de Shorewall. Il se focalise sur les besoins pour configurer Shorewall dans -une de ses utilisations les plus populaire :

    - + Mettre en place un système linux en tant que firewall pour un petit réseau + contenant une DMZ est une chose assez simple à réaliser si vous comprenez + les bases et suivez cette documentation.

    + +

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités + de Shorewall. Il se focalise sur les besoins pour configurer Shorewall dans + une de ses utilisations les plus populaire :

    +
      -
    • Un système Linux utilisé en tant que firewall/routeur pour un petit -réseau local.
      • -
    • Une seule adresse IP publique.
      • -
    • Une DMZ connectée sur une interface Ethernet séparée.
      • -
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame Relay, -RTC, ...
      • - +
    • Un système Linux utilisé en tant que firewall/routeur pour un petit + réseau local.
      • +
    • Une seule adresse IP publique.
      • +
    • Une DMZ connectée sur une interface Ethernet séparée.
      • +
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame Relay, + RTC, ...
      • +
    - +

    Voici le schéma d'une installation typique.

    - +

    -

    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous -pouvez voir si le paquet est installé en vérifiant la présence du programme -ip sur votre système de firewall. Sous root, utilisez la commande 'which' -pour rechercher le programme :

    - +

    + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du programme + ip sur votre système de firewall. Sous root, utilisez la commande 'which' + pour rechercher le programme :

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    Je vous recommande dans un premier temps de parcourir tout le guide pour -vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant -le changements dans votre configuration. Les points où, les changements dans -la configuration sont recommandées, sont signalés par une Je vous recommande dans un premier temps de parcourir tout le guide pour + vous familiariser avec ce qu'il va se passer, et de revenir au début en +effectuant le changements dans votre configuration. Les points où, les changements +dans la configuration sont recommandées, sont signalés par une -

    - +

    +

    - Si vous éditez vos fichiers de configuration sur un système Windows, vous -devez les sauver comme des fichiers Unix si votre éditeur offre cette option -sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser. -De la même manière, si vous copiez un fichier de configuration depuis votre -disque dur Windows vers une disquette, vous devez lancer dos2unix sur la copie -avant de l'utiliser avec Shorewall.

    - + Si vous éditez vos fichiers de configuration sur un système Windows, vous + devez les sauver comme des fichiers Unix si votre éditeur offre cette option + sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser. + De la même manière, si vous copiez un fichier de configuration depuis votre + disque dur Windows vers une disquette, vous devez lancer dos2unix sur la +copie avant de l'utiliser avec Shorewall.

    + - +

    Les Concepts de Shorewall

    - +

    - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec -quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration -d'exemple three-interface -sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez -les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même nom -déjà existant dans /etc/shorewall installés lors de l'installation de Shorewall).

    - -

    En même temps que chacun des fichiers est présenté, je vous suggère de -jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun -des fichiers contient des instructions de configuration détaillées et des -entrées par défaut.

    - -

    Shorewall voit le réseau où il tourne comme composé par un ensemble de -zones. Dans les fichiers de configuration fournis pour trois interfaces, -trois zones sont définies :

    - + Les fichiers de configuration pour Shorewall sont situés dans le répertoire + /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec + quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration + d'exemple three-interface + sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez + les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même +nom déjà existant dans /etc/shorewall installés lors de l'installation de +Shorewall).

    + +

    En même temps que chacun des fichiers est présenté, je vous suggère de + jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun + des fichiers contient des instructions de configuration détaillées et des + entrées par défaut.

    + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de + zones. Dans les fichiers de configuration fournis pour trois interfaces, + trois zones sont définies :

    + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    - -

    Les noms de zone sont définis dans /etc/shorewall/zones.

    - -

    Shorewall reconnaît aussi le système de firewall comme sa propre zone - -par défaut, le firewall lui même est connu en tant que fw.

    - -

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées -en utilisant les termes de zones.

    - -
      -
    • Vous exprimez les politiques par défaut pour les connexions d'une -zone à une autre dans le fichier /etc/shorewall/policy - .
      • -
    • Vous définissez les exceptions à ces règles de politiques par défaut -dans le fichier /etc/shorewall/rules.
      • - -
    - -

    Pour chacune des demandes de connexion entrantes dans le firewall, les -demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. -Si aucune des règles dans ce fichier ne correspondent, alors la première politique -dans /etc/shorewall/policy qui y correspond est appliquée. Si cette politique -est REJECT ou DROP la requête est alors comparée par rapport aux règles contenues -dans /etc/shorewall/common (l'archive d'exemple vous fournit ce fichier).

    - -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface -sample a les politiques suivantes :

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    -
    - -
    -

    Dans l'archive three-interface, la ligne suivante est existante mais -elle est commentée. Si vous souhaitez que votre système de firewall puisse -avoir un accès complet aux serveurs sur Internet, décommentez la.

    +

    Les noms de zone sont définis dans /etc/shorewall/zones.

    + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone +- par défaut, le firewall lui même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées + en utilisant les termes de zones.

    + +
      +
    • Vous exprimez les politiques par défaut pour les connexions d'une +zone à une autre dans le fichier /etc/shorewall/policy + .
      • +
    • Vous définissez les exceptions à ces règles de politiques par défaut + dans le fichier /etc/shorewall/rules.
      • + +
    + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les + demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. + Si aucune des règles dans ce fichier ne correspondent, alors la première +politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette +politique est REJECT ou DROP la requête est alors comparée par rapport aux +règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit +ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface + sample a les politiques suivantes :

    + +
    - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    -
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    + +
    +

    Dans l'archive three-interface, la ligne suivante est existante mais + elle est commentée. Si vous souhaitez que votre système de firewall puisse + avoir un accès complet aux serveurs sur Internet, décommentez la.

    + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    +
    +
    +
    +

    Les politiques précédentes vont :

    - +
      -
    1. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet +
    3. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      4. +
    4. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers votre firewall ou vers votre réseau local
      5. -
    5. Facultativement accepter toutes les demandes de connexion depuis +
    6. Facultativement accepter toutes les demandes de connexion depuis votre firewall et vers Internet (si vous decommentez la politique précédente)
      7. -
    7. reject (rejeter) toutes les autres demandes de connexion.
      8. - +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    - +

    - A ce point, éditez votre /etc/shorewall/policy et faites y les changements -que vous désire

    - + A ce point, éditez votre /etc/shorewall/policy et faites y les changements + que vous désire

    +

    Les Interfaces Réseau

    - +

    -

    - -

    Le firewall a trois interfaces de réseau. Lorsque la connexion -Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL (non -USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur -sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous -connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling -Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de -type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre -interface extérieure sera aussi ppp0. Si votre connexion passe par Numéris -(ISDN), votre interface extérieure sera ippp0.

    - +

    + +

    Le firewall a trois interfaces de réseau. Lorsque la connexion + Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL +(non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur + sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous + connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling + Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de + type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), +votre interface extérieure sera aussi ppp0. Si votre connexion passe par +Numéris (ISDN), votre interface extérieure sera ippp0.

    +

    - Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez -CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    - -

    Votre Interface locale sera un adaptateur Ethernet -(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs -locaux seront connectés à ce même switch (note : si vous n'avez qu'un seul -ordinateur en local, vous pouvez le connecter directement au firewall par -un câble croisé).

    - -

    Votre interface DMZ sera aussi un adaptateur Ethernet -(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs -appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez -qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au -firewall par un câble croisé).

    - + Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez + CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    + +

    Votre Interface locale sera un adaptateur Ethernet + (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs + locaux seront connectés à ce même switch (note : si vous n'avez qu'un seul + ordinateur en local, vous pouvez le connecter directement au firewall par + un câble croisé).

    + +

    Votre interface DMZ sera aussi un adaptateur Ethernet + (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs + appartenant à la DMZ seront connectés à ce même switch (note : si vous +n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement +au firewall par un câble croisé).

    +

    - Ne connectez pas l'interface interne et externe sur le même hub -ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que -ce soit shorewall qui ne marche pas.

    - + Ne connectez pas l'interface interne et externe sur le même hub + ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas +que ce soit shorewall qui ne marche pas.

    +

    - L'exemple de configuration de Shorewall pour trois interfaces suppose que -l'interface externe est eth0, l'interface locale est eth1 et -que la DMZ est sur l'interface eth2. Si votre configuration diffère, -vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. -Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont -spécifiées pour les interfaces. Quelques trucs :

    - + L'exemple de configuration de Shorewall pour trois interfaces suppose +que l'interface externe est eth0, l'interface locale est eth1 + et que la DMZ est sur l'interface eth2. Si votre configuration +diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces +en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des +options qui sont spécifiées pour les interfaces. Quelques trucs :

    +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, vous pouvez -remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 ou bien si -vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la liste -d'option.

      -
      • - +
    • +

      Si votre interface externe est ppp0 ou ippp0, vous pouvez + remplacer le "detect" dans la seconde colonne par un "-".

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 ou bien +si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la +liste d'option.

      +
      • +
    - +

    Adresses IP

    - -

    Avant d'aller plus loin, nous devons dire quelques mots au -sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur -Internet (ISP) vous assignera une seule adresse IP (single Public IP address). -Cette adresse peut être assignée par le Dynamic Host Configuration Protocol -(DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez -(modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre -provider peu vous assigner une adresse statique (staticIP address); cela signifie -que vous configurez votre interface externe sur votre firewall afin d'utiliser -cette adresse de manière permanente. Une fois votre adresse externe assignée, -elle va être partagée par tout vos systèmes lors de l'accès à Internet. Vous -devrez assigner vos propres adresses à votre réseau local (votre interface -interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 réserve -plusieurs plages d'IP (Private IP address ranges) à cette fin :

    - -
    + +

    Avant d'aller plus loin, nous devons dire quelques mots au + sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur + Internet (ISP) vous assignera une seule adresse IP (single Public IP address). + Cette adresse peut être assignée par le Dynamic Host Configuration Protocol + (DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez + (modem standard) ou établissez votre connexion PPP. Dans de rares cas , +votre provider peu vous assigner une adresse statique (staticIP address); +cela signifie que vous configurez votre interface externe sur votre firewall +afin d'utiliser cette adresse de manière permanente. Une fois votre adresse +externe assignée, elle va être partagée par tout vos systèmes lors de l'accès +à Internet. Vous devrez assigner vos propres adresses à votre réseau local +(votre interface interne sur le firewall ainsi que les autres ordinateurs). +La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à +cette fin :

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    +
    + +

    - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface -externe et si elle est comprise dans une des plages précédentes, vous devriez -enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    -
    - -
    -

    Vous devrez assigner les adresses locales à un sous-réseau -(sub-network ou subnet) et les adresse pour la DMZ à un autre -sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste -en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera -une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est -réservée comme l'adresse du sous-réseau (Subnet Address) et x.y.z.255 - est réservée en tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast -Address). Sous Shorewall, un sous-réseau est décrit/désigné en utilisant -la notation Classless InterDomain -Routing(CIDR) qui consiste en l'adresse du sous-réseau suivie par -"/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie -gauche du masque de sous-réseau.

    -
    - -
    + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface + externe et si elle est comprise dans une des plages précédentes, vous devriez + enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    + +
    +

    Vous devrez assigner les adresses locales à un sous-réseau + (sub-network ou subnet) et les adresse pour la DMZ à un autre + sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste + en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera + une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est + réservée comme l'adresse du sous-réseau (Subnet Address) et x.y.z.255 + est réservée en tant qu'adresse de broadcast du sous-réseau (Subnet +Broadcast Address). Sous Shorewall, un sous-réseau est décrit/désigné +en utilisant la notation Classless +InterDomain Routing(CIDR) qui consiste en l'adresse du sous-réseau +suivie par "/24". Le "24" se réfère au nombre de bits "1" consécutifs dans +la partie gauche du masque de sous-réseau.

    +
    + +

    Exemple de sous-réseau (subnet) :

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    -

    Il est de convention d'assigner à l'interface interne la première -adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple précédent) - ou la dernière utilisable (10.10.10.254).

    -
    - -
    -

    L'un des buts d'un sous-réseau est de permettre à tous les -ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils -peuvent communiquer directement. Pour communiquer avec des systèmes en dehors -du sous-réseau, les ordinateurs envoient des paquets à travers le gateway -(routeur).

    -
    - -
    + +
    + +
    +

    Il est de convention d'assigner à l'interface interne la +première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple +précédent) ou la dernière utilisable (10.10.10.254).

    +
    + +
    +

    L'un des buts d'un sous-réseau est de permettre à tous les + ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs +ils peuvent communiquer directement. Pour communiquer avec des systèmes +en dehors du sous-réseau, les ordinateurs envoient des paquets à travers +le gateway (routeur).

    +
    + +

    - Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés -avec leur passerelle par défaut (default gateway)pointant sur l'adresse -IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient -être configurés avec leur passerelle par défaut (default gateway) pointant -sur l'adresse IP de l'interface DMZ du firewall.

    -
    - -

    Cette courte description ne fait que survoler les concepts -de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage -IP et le routage, je vous recommande chaudement "IP Fundamentals: What -Everyone Needs to Know about Addressing & Routing", Thomas A. -Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    Pour rappel, ce guide supposera que vous avez configuré votre -réseau comme montrer ci-dessous :

    - + Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés + avec leur passerelle par défaut (default gateway)pointant sur l'adresse + IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient + être configurés avec leur passerelle par défaut (default gateway) +pointant sur l'adresse IP de l'interface DMZ du firewall.

    +
    + +

    Cette courte description ne fait que survoler les concepts + de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur +l'adressage IP et le routage, je vous recommande chaudement "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    Pour rappel, ce guide supposera que vous avez configuré votre + réseau comme montrer ci-dessous :

    +

    -

    - -

    La passerelle par défaut (default gateway) pour les ordinateurs -de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les ordinateurs -en local sera 10.10.10.254.

    - +

    + +

    La passerelle par défaut (default gateway) pour les ordinateurs + de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les ordinateurs + en local sera 10.10.10.254.

    +

    IP Masquerading (SNAT)

    - -

    Les adresses réservées par la RFC 1918 sont parfois désignées -comme non-routables car les routeurs Internet (backbone) ne font pas circuler -les paquets qui ont une adresse de destination appartenant à la RFC-1918. -Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une connexion -à un serveur par Internet, le firewall doit appliquer un NAT (Network Address -Translation). Le firewall ré écrit l'adresse source dans le paquet, et l'a -remplace par l'adresse de l'interface externe du firewall; en d'autres mots, -le firewall fait croire que c'est lui même qui initie la connexion. Ceci -est nécessaire afin que l'hôte de destination soit capable de renvoyer les -paquets au firewall (souvenez vous que les paquets qui ont pour adresse de -destination, une adresse réservée par la RFC 1918 ne pourront pas être routés -à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse à -l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet -l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur -1.

    - -

    Sur les systèmes Linux, ce procédé est souvent appelé de l'IP -Masquerading mais vous verrez aussi le terme de Source Network Address Translation -(SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter :

    - + +

    Les adresses réservées par la RFC 1918 sont parfois désignées + comme non-routables car les routeurs Internet (backbone) ne font pas circuler + les paquets qui ont une adresse de destination appartenant à la RFC-1918. + Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une +connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network +Address Translation). Le firewall ré écrit l'adresse source dans le paquet, +et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres +mots, le firewall fait croire que c'est lui même qui initie la connexion. +Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer +les paquets au firewall (souvenez vous que les paquets qui ont pour adresse +de destination, une adresse réservée par la RFC 1918 ne pourront pas être +routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse +à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet + l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur + 1.

    + +

    Sur les systèmes Linux, ce procédé est souvent appelé de +l'IP Masquerading mais vous verrez aussi le terme de Source Network Address +Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter +:

    +
      -
    • -

      Masquerade désigne le cas ou vous laissez votre firewall -détecter automatiquement l'adresse de l'interface externe.

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez explicitement l'adresse -source des paquets sortant de votre réseau local.

      -
      • - +
    • +

      Masquerade désigne le cas ou vous laissez votre firewall + détecter automatiquement l'adresse de l'interface externe.

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez explicitement l'adresse + source des paquets sortant de votre réseau local.

      +
      • +
    - -

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré -avec des entrés dans le fichier /etc/shorewall/masq.

    - + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré + avec des entrés dans le fichier /etc/shorewall/masq.

    +

    - Si votre interface externe est eth0, votre interface locale eth1 -et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier -le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq - et changez le en conséquence.

    - + Si votre interface externe est eth0, votre interface locale eth1 + et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier + le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq + et changez le en conséquence.

    +

    - Si votre IP externe est statique, vous pouvez la mettre dans la troisième -colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre -firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de -mettre votre IP statique dans la troisième colonne permet un traitement des -paquets sortant un peu plus efficace.
    -

    - + Si votre IP externe est statique, vous pouvez la mettre dans la troisième + colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre + firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de + mettre votre IP statique dans la troisième colonne permet un traitement +des paquets sortant un peu plus efficace.
    +

    +

    - Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration -shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas -faite les changements nécessaires :
    -

    - + Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration + shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas + faite les changements nécessaires :
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    - +

    Port Forwarding (DNAT)

    - -

    Un de nos buts est de, peut être, faire tourner un ou plusieurs -serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse -RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter -directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes -de connexion au firewall qui ré écrit l'adresse de destination de votre serveur, -et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall -applique automatiquement un SNAT pour ré écrire l'adresse source dans la réponse.

    - -

    Ce procédé est appelé Port Forwarding ou Destination Network -Address Translation(DNAT). Vous configurez le port forwarding en utilisant -les règles DNAT dans le fichier /etc/shorewall/rules.

    - -

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules -est :

    - -
    + +

    Un de nos buts est de, peut être, faire tourner un ou plusieurs + serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse + RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter + directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes + de connexion au firewall qui ré écrit l'adresse de destination de votre +serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond, +le firewall applique automatiquement un SNAT pour ré écrire l'adresse source +dans la réponse.

    + +

    Ce procédé est appelé Port Forwarding ou Destination Network + Address Translation(DNAT). Vous configurez le port forwarding en utilisant + les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules + est :

    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server port>]<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server +port>]<protocol><port>
    +
    +
    -
    - -

    Si vous ne spécifiez pas le <server port>, il est supposé -être le même que <port>.

    - -

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous -voulez faire passer les paquets entrant en TCP sur le port 80 à ce système -:

    - -
    +
    + +

    Si vous ne spécifiez pas le <server port>, il est supposé + être le même que <port>.

    + +

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous + voulez faire passer les paquets entrant en TCP sur le port 80 à ce système + :

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    -
    - +
    +

    Deux points importants à garder en mémoire :

    - +
      -
    • Lorsque vous vous connectez à votre serveur à partir de votre réseau -local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • -
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes -de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous -connecter à votre serveur web, essayez la règle suivante et connectez vous -sur le port 5000 (c.a.d., connectez vous à -http://w.x.y.z:5000 où w.x.y.z est votre IP externe).
      • - +
    • Lorsque vous vous connectez à votre serveur à partir de votre réseau + local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • +
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes + de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous + connecter à votre serveur web, essayez la règle suivante et connectez vous + sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre +IP externe).
      • +
    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    +
    +
    -
    - -

    Si vous voulez avoir la possibilité de vous connecter à votre serveur depuis -le réseau local en utilisant votre adresse externe, et si vous avez une adresse -IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz précédente -par :

    - -
    +
    + +

    Si vous voulez avoir la possibilité de vous connecter à votre serveur +depuis le réseau local en utilisant votre adresse externe, et si vous avez +une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz +précédente par :

    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    - -

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre -interface externe est en route avant de lancer Shorewall et vous devez suivre -les étapes suivantes (en supposant que votre interface externe est eth0) -:

    - +
    + +

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre + interface externe est en route avant de lancer Shorewall et vous devez suivre + les étapes suivantes (en supposant que votre interface externe est eth0) + :

    +
      -
    1. Insérez ce qui suit dans /etc/shorewall/params :
      -
      - ETH0_IP=`find_interface_address eth0`
      -
      2. -
    2. Faites votre règle loc->dmz :
      3. - +
    3. Insérez ce qui suit dans /etc/shorewall/params :
      +
      + ETH0_IP=`find_interface_address eth0`
      +
      4. +
    4. Faites votre règle loc->dmz :
      5. +
    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    - -

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre adresse -IP externe, regardez FAQ 2a.

    - +
    + +

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre +adresse IP externe, regardez FAQ 2a.

    +

    - A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    - + A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +

    Domain Name Server (DNS)

    - -

    Normalement, quand vous vous connectez à votre fournisseur -(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le firewall -(Domain Name Service) est configuré automatiquement (c.a.d., le fichier /etc/resolv.conf -a été écrit). Il arrive que votre provider vous donne une paire d'adresse -IP pour les DNS (name servers) afin que vous configuriez manuellement votre -serveur de nom primaire et secondaire. La manière dont le DNS est configuré -sur votre firewall est de votre responsabilité. Vous pouvez procéder d'une -de ses deux façons :

    - + +

    Normalement, quand vous vous connectez à votre fournisseur + (ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le +firewall (Domain Name Service) est configuré automatiquement (c.a.d., le +fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous +donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez +manuellement votre serveur de nom primaire et secondaire. La manière dont +le DNS est configuré sur votre firewall est de votre responsabilité. Vous +pouvez procéder d'une de ses deux façons :

    +
      -
    • -

      Vous pouvez configurer votre système interne pour utiliser -les noms de serveurs de votre provider. Si votre fournisseur vous donne les -adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site -web, vous pouvez configurer votre système interne afin de les utiliser. Si -cette information n'est pas disponible, regardez dans /etc/resolv.conf sur -votre firewall -- les noms des serveurs sont donnés dans l'enregistrement -"nameserver" dans ce fichier.

      -
      • -
    • +
    • +

      Vous pouvez configurer votre système interne pour utiliser + les noms de serveurs de votre provider. Si votre fournisseur vous donne +les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur +site web, vous pouvez configurer votre système interne afin de les utiliser. +Si cette information n'est pas disponible, regardez dans /etc/resolv.conf +sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement + "nameserver" dans ce fichier.

      +
      • +

    • - Vous pouvez installer/configurer un cache dns (Caching Name Server) sur -votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre en cache -un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs -de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez -votre système interne pour utiliser le firewall lui même comme étant le seul -serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall -(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez -de faire tourner le serveur de nom sur votre firewall. Pour permettre à vos -systèmes locaux de discuter avec votre serveur cache de nom, vous devez ouvrir -le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous ferez -ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.

      -
      • - -
    - -
    -

    Si vous faites tourner le serveur de nom sur le firewall -: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    -
    -
    ACCEPTlocfwudp53
    -
    -
    ACCEPTdmzfwtcp53
    -
    -
    ACCEPTdmzfwudp53
    -
    -
    + Vous pouvez installer/configurer un cache dns (Caching Name Server) sur + votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre en cache + un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs + de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez + votre système interne pour utiliser le firewall lui même comme étant le +seul serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne +du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom +si vous décidez de faire tourner le serveur de nom sur votre firewall. Pour +permettre à vos systèmes locaux de discuter avec votre serveur cache de +nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le +réseau local; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.

    -
    - -
    -
    -

    Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

    + + + +
    +

    Si vous faites tourner le serveur de nom sur le firewall + : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    -
    -
    ACCEPTlocdmz:10.10.11.1udp53
    -
    -
    ACCEPTfwdmz:10.10.10.1tcp53
    -
    -
    ACCEPTfwdmz:10.10.10.1udp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    +
    +
    ACCEPTlocfwudp53
    +
    +
    ACCEPTdmzfwtcp53
    +
    +
    ACCEPTdmzfwudp53
    +
    +
    -

    -
    - -
    +

    + + +
    +
    +

    Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    +
    +
    ACCEPTlocdmz:10.10.11.1udp53
    +
    +
    ACCEPTfwdmz:10.10.10.1tcp53
    +
    +
    ACCEPTfwdmz:10.10.10.1udp53
    +
    +
    +
    +
    + +

    Autres Connexions

    -
    - -
    -

    L'exemple pour trois interfaces contient les règles suivantes -:

    -
    - -
    -
    +
    + +
    +

    L'exemple pour trois interfaces contient les règles suivantes + :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    -
    -
    ACCEPTfwnettcp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    +
    +
    ACCEPTfwnettcp53
    +
    +
    -
    -
    - -
    -

    Ces règles permettent l'accès DNS depuis votre firewall et -peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy -autorisant toutes les connexions depuis votre firewall et vers Internet.

    -
    - -
    + +
    + +
    +

    Ces règles permettent l'accès DNS depuis votre firewall et + peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy + autorisant toutes les connexions depuis votre firewall et vers Internet.

    +
    + +

    L'exemple contient aussi :

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    -
    -
    ACCEPTlocdmztcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    +
    +
    ACCEPTlocdmztcp22
    +
    +
    -
    -
    - -
    -

    Cette règle permet de faire fonctionner une serveur SSH sur -le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion -à partir de votre réseau local.

    -
    - -
    -

    Si vous désirez permettre d'autres connexions entre vos systèmes, -la forme générale est :

    -
    - -
    -
    +
    +
    + +
    +

    Cette règle permet de faire fonctionner une serveur SSH sur + le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion + à partir de votre réseau local.

    +
    + +
    +

    Si vous désirez permettre d'autres connexions entre vos systèmes, + la forme générale est :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    +
    +
    -
    -
    - -
    -

    Exemple - Vous voulez faire tourner un serveur DNS disponible -pour le publique sur votre firewall :

    -
    - -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur DNS disponible + pour le publique sur votre firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    -
    -
    - -
    -

    Ces deux règles seront, bien sur, ajoutées aux règles décrites -dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) -sur votre firewall ou dans la DMZ".

    -
    - -
    -

    Si vous ne savez pas quel port ou protocole une application -particulière utilise, regardez ici.

    -
    - -
    -

    Important: Je ne vous recommande pas d'autoriser le telnet -depuis ou vers l'Internet car il utilise du texte en clair (même pour le login -et le mot de passe !). Si vous voulez avoir un accès au shell de votre firewall -depuis Internet, utilisez SSH :

    -
    - -
    -
    +
    +
    + +
    +

    Ces deux règles seront, bien sur, ajoutées aux règles décrites + dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) + sur votre firewall ou dans la DMZ".

    +
    + +
    +

    Si vous ne savez pas quel port ou protocole une application + particulière utilise, regardez ici.

    +
    + +
    +

    Important: Je ne vous recommande pas d'autoriser le telnet + depuis ou vers l'Internet car il utilise du texte en clair (même pour le +login et le mot de passe !). Si vous voulez avoir un accès au shell de votre +firewall depuis Internet, utilisez SSH :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    - -
    + +
    + +

    - Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres connexions -désirées.

    -
    - -
    + Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres connexions + désirées.

    +
    + +

    Lancer et Arrêter son Firewall

    -
    - -
    +
    + +

    Arrow - La procédure d'installation configure votre système -pour lancer Shorewall au boot du système, mais au début avec la version 1.3.9 -de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall -avec que la configuration soit finie. Une fois que vous en avez fini avec -la configuration du firewall, vous pouvez permettre le lancement de Shorewall -en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer -/etc/default/shorewall et mettre 'startup=1'.
    -

    -
    - -
    -

    Le firewall est activé en utilisant la commande "shorewall -start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le -routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un -firewall qui tourne peut être relancé en utilisant la commande "shorewall -restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration -de Netfilter, utilisez "shorewall clear".

    -
    - -
    + La procédure d'installation configure votre +système pour lancer Shorewall au boot du système, mais au début avec la +version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de +lancer Shorewall avec que la configuration soit finie. Une fois que vous +en avez fini avec la configuration du firewall, vous pouvez permettre le +lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    + +

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer + /etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall + start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, +le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un + firewall qui tourne peut être relancé en utilisant la commande "shorewall + restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration + de Netfilter, utilisez "shorewall clear".

    +
    + +

    - L'exemple pour trois interfaces suppose que vous voulez permettre le routage -depuis/vers eth1 (votre réseau local) et eth2(DMZ) lorsque -Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées -à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble -d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

    -
    - -
    -

    ATTENTION: Si vous êtes connecté à votre firewall depuis Internet, -n'essayez pas une commande "shorewall stop" tant que vous n'avez pas ajouté -une entrée pour votre adresse IP (celle à partir de laquelle vous êtes connectée) -dans /etc/shorewall/routestopped. -De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; -il est plus intéressant de créer une eth1 (votre réseau local) et eth2(DMZ) lorsque + Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées + à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble + d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

    +
    + +
    +

    ATTENTION: Si vous êtes connecté à votre firewall depuis +Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez +pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous +êtes connectée) dans /etc/shorewall/routestopped. + De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; + il est plus intéressant de créer une configuration alternativeet de la -tester en utilisant la commande alternativeet de la + tester en utilisant la commande "shorewall try".

    -
    - +
    +

    Last updated 12/20/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas -M. Eastep

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

    Copyright 2002 Thomas + M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +


    diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm index 90d9e7bfa..f39e5c545 100644 --- a/Shorewall-docs/troubleshoot.htm +++ b/Shorewall-docs/troubleshoot.htm @@ -1,233 +1,224 @@ - + Shorewall Troubleshooting - + - + - + - - - + + - - - + + + + +
    - +

    Shorewall TroubleshootingBeating head on table -

    -
    - +

    Check the Errata

    - -

    Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version + +

    Check the Shorewall Errata to be + sure that there isn't an update that you are missing for your version of the firewall.

    - +

    Check the FAQs

    - -

    Check the FAQs for solutions to common + +

    Check the FAQs for solutions to common problems.

    - +

    If the firewall fails to start

    - If you receive an error message when starting or restarting - the firewall and you can't determine the cause, then do the following: - + If you receive an error message when starting or restarting + the firewall and you can't determine the cause, then do the following: +
      -
    • Make a note of the error message that you see.
      -
      • -
    • shorewall debug start 2> /tmp/trace
      • -
    • Look at the /tmp/trace file and see if that helps you - determine what the problem is. Be sure you find the place in the log - where the error message you saw is generated -- in 99.9% of the cases, it - will not be near the end of the log because after startup errors, Shorewall - goes through a "shorewall stop" phase which will also be traced.
      • -
    • If you still can't determine what's wrong then see the +
    • Make a note of the error message that you see.
      +
      • +
    • shorewall debug start 2> /tmp/trace
      • +
    • Look at the /tmp/trace file and see if that helps you + determine what the problem is. Be sure you find the place in the log + where the error message you saw is generated -- If you are using Shorewall +1.4.0 or later, you should find the message near the end of the log.
      • +
    • If you still can't determine what's wrong then see the support page.
      • - +
    - Here's an example. During startup, a user sees the following:
    - -
    + Here's an example. During startup, a user sees the following:
    + +
    Adding Common Rules
    iptables: No chain/target/match by that name
    Terminated
    -
    - A search through the trace for "No chain/target/match by that name" turned - up the following:  -
    +
    + A search through the trace for "No chain/target/match by that name" turned + up the following:  +
    + echo 'Adding Common Rules'
    + add_common_rules
    + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
    ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
    ++ sed 's/!/! /g'
    + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
    iptables: No chain/target/match by that name
    -
    - The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with - tcp-reset". In this case, the user had compiled his own kernel and had forgotten - to include REJECT target support (see kernel.htm) - +
    + The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with + tcp-reset". In this case, the user had compiled his own kernel and had forgotten + to include REJECT target support (see kernel.htm) +

    Your network environment

    - -

    Many times when people have problems with Shorewall, the problem is -actually an ill-conceived network setup. Here are several popular snafus: -

    - + +

    Many times when people have problems with Shorewall, the problem is actually +an ill-conceived network setup. Here are several popular snafus:

    +
      -
    • Port Forwarding where client and server are in - the same subnet. See FAQ 2.
      • -
    • Changing the IP address of a local system to be in the -external subnet, thinking that Shorewall will suddenly believe that +
    • Port Forwarding where client and server are +in the same subnet. See FAQ 2.
      • +
    • Changing the IP address of a local system to be in the +external subnet, thinking that Shorewall will suddenly believe that the system is in the 'net' zone.
      • -
    • Multiple interfaces connected to the same HUB or Switch. - Given the way that the Linux kernel respond to ARP "who-has" requests, +
    • Multiple interfaces connected to the same HUB or Switch. + Given the way that the Linux kernel respond to ARP "who-has" requests, this type of setup does NOT work the way that you expect it to.
      • - +
    - +

    If you are having connection problems:

    - -

    If the appropriate policy for the connection that you are - trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING - TO MAKE IT WORK. Such additional rules will NEVER make it work, they -add clutter to your rule set and they represent a big security hole in + +

    If the appropriate policy for the connection that you are + trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING + TO MAKE IT WORK. Such additional rules will NEVER make it work, they +add clutter to your rule set and they represent a big security hole in the event that you forget to remove them later.

    - -

    I also recommend against setting all of your policies to - ACCEPT in an effort to make something work. That robs you of one of - your best diagnostic tools - the "Shorewall" messages that Netfilter - will generate when you try to connect in a way that isn't permitted + +

    I also recommend against setting all of your policies to + ACCEPT in an effort to make something work. That robs you of one of + your best diagnostic tools - the "Shorewall" messages that Netfilter + will generate when you try to connect in a way that isn't permitted by your rule set.

    - -

    Check your log ("/sbin/shorewall show log"). If you don't - see Shorewall messages, then your problem is probably NOT a Shorewall - problem. If you DO see packet messages, it may be an indication that you + +

    Check your log ("/sbin/shorewall show log"). If you don't + see Shorewall messages, then your problem is probably NOT a Shorewall + problem. If you DO see packet messages, it may be an indication that you are missing one or more rules -- see FAQ 17.

    - -

    While you are troubleshooting, it is a good idea to clear + +

    While you are troubleshooting, it is a good idea to clear two variables in /etc/shorewall/shorewall.conf:

    - +

    LOGRATE=""
    - LOGBURST=""

    - -

    This way, you will see all of the log messages being - generated (be sure to restart shorewall after clearing these variables).

    - + LOGBURST=""

    + +

    This way, you will see all of the log messages being generated +(be sure to restart shorewall after clearing these variables).

    +

    Example:

    - - -

    Jun 27 15:37:56 gateway kernel: - Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 - LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 - LEN=47

    -     + +

    Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 + OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 + ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47

    +

    Let's look at the important parts of this message:

    - +
      -
    • all2all:REJECT - This packet was REJECTed out of the all2all - chain -- the packet was rejected under the "all"->"all" REJECT +
    • all2all:REJECT - This packet was REJECTed out of the all2all + chain -- the packet was rejected under the "all"->"all" REJECT policy (see FAQ 17).
      • -
    • IN=eth2 - the packet entered the firewall via eth2
      • -
    • OUT=eth1 - if accepted, the packet would be sent on eth1
      • -
    • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
      • -
    • DST=192.168.1.3 - the packet is destined for 192.168.1.3
      • -
    • PROTO=UDP - UDP Protocol
      • -
    • DPT=53 - DNS
      • - +
    • IN=eth2 - the packet entered the firewall via eth2
      • +
    • OUT=eth1 - if accepted, the packet would be sent on eth1
      • +
    • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
      • +
    • DST=192.168.1.3 - the packet is destined for 192.168.1.3
      • +
    • PROTO=UDP - UDP Protocol
      • +
    • DPT=53 - DNS
      • +
    - -

    In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 + +

    In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 is in the "loc" zone. I was missing the rule:

    - +

    ACCEPT    dmz    loc    udp    53
    -

    - -

    See FAQ 17 for additional information +

    + +

    See FAQ 17 for additional information about how to interpret the chain name appearing in a Shorewall log message.
    -

    - +

    +

    'Ping' Problems?

    - Either can't ping when you think you should be able to or are able to ping - when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
    - +

    Other Gotchas

    - +
      -
    • Seeing rejected/dropped packets logged out of the INPUT -or FORWARD chains? This means that: - +
    • Seeing rejected/dropped packets logged out of the INPUT +or FORWARD chains? This means that:
        -
      1. your zone definitions are screwed up and the host that - is sending the packets or the destination host isn't in any zone - (using an /etc/shorewall/hosts +
      2. your zone definitions are screwed up and the host that + is sending the packets or the destination host isn't in any zone + (using an /etc/shorewall/hosts file are you?); or
        3. -
      3. the source and destination hosts are both connected to - the same interface and you don't have a policy or rule for the -source zone to or from the destination zone.
        4. - +
      4. the source and destination hosts are both connected +to the same interface and you don't have a policy or rule for +the source zone to or from the destination zone.
        5. +
      -
      • -
    • Remember that Shorewall doesn't automatically allow ICMP - type 8 ("ping") requests to be sent between zones. If you want -pings to be allowed between zones, you need a rule of the form:
      -
      -     ACCEPT    <source zone>    <destination zone>    - icmp    echo-request
      -
      - The ramifications of this can be subtle. For example, if you - have the following in /etc/shorewall/nat:
      -
      -     10.1.1.2    eth0    130.252.100.18
      -
      - and you ping 130.252.100.18, unless you have allowed icmp -type 8 between the zone containing the system you are pinging from +
      • +
    • Remember that Shorewall doesn't automatically allow ICMP + type 8 ("ping") requests to be sent between zones. If you want pings + to be allowed between zones, you need a rule of the form:
      +
      +     ACCEPT    <source zone>    <destination +zone>    icmp    echo-request
      +
      + The ramifications of this can be subtle. For example, if +you have the following in /etc/shorewall/nat:
      +
      +     10.1.1.2    eth0    130.252.100.18
      +
      + and you ping 130.252.100.18, unless you have allowed icmp +type 8 between the zone containing the system you are pinging from and the zone containing 10.1.1.2, the ping requests will be dropped. 
      • -
    • If you specify "routefilter" for an interface, that +
    • If you specify "routefilter" for an interface, that interface must be up prior to starting the firewall.
      • -
    • Is your routing correct? For example, internal systems -usually need to be configured with their default gateway set to -the IP address of their nearest firewall interface. One often overlooked -aspect of routing is that in order for two hosts to communicate, the -routing between them must be set up in both directions. So -when setting up routing between A and B, be sure to -verify that the route from B back to A is defined.
      • -
    • Some versions of LRP (EigerStein2Beta for example) have +
    • Is your routing correct? For example, internal systems +usually need to be configured with their default gateway set to the +IP address of their nearest firewall interface. One often overlooked +aspect of routing is that in order for two hosts to communicate, the +routing between them must be set up in both directions. So when +setting up routing between A and B, be sure to verify +that the route from B back to A is defined.
      • +
    • Some versions of LRP (EigerStein2Beta for example) have a shell with broken variable expansion. You can get a corrected + href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected shell from the Shorewall Errata download site.
      • -
    • Do you have your kernel properly configured? Do you have your kernel properly configured? Click here to see my kernel configuration.
      • -
    • Shorewall requires the "ip" program. That program is - generally included in the "iproute" package which should be included - with your distribution (though many distributions don't install iproute +
    • Shorewall requires the "ip" program. That program + is generally included in the "iproute" package which should be included + with your distribution (though many distributions don't install iproute by default). You may also download the latest source tarball from ftp://ftp.inr.ac.ru/ip-routing + href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing .
      • -
    • Problems with NAT? Be sure that you let Shorewall +
    • Problems with NAT? Be sure that you let Shorewall add all external addresses to be use with NAT unless you have set ADD_IP_ALIASES =No in /etc/shorewall/shorewall.conf.
      • - +
    - +

    Still Having Problems?

    - +

    See the support page.
    -

    - - +

    +
    -     -

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright + +

    Last updated 4/29/2003 - Tom Eastep

    + +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    -
    -
    +

    diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm index 0d00756ee..ef6c48ab3 100644 --- a/Shorewall-docs/two-interface.htm +++ b/Shorewall-docs/two-interface.htm @@ -1,1027 +1,1029 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
    +

    Basic Two-Interface Firewall

    -
    - -

    Setting up a Linux system as a firewall for a small network - is a fairly straight-forward task if you understand the basics and - follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in its most common configuration:

    - + +

    Setting up a Linux system as a firewall for a small network + is a fairly straight-forward task if you understand the basics +and follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in its most common configuration:

    +
      -
    • Linux system used as a firewall/router for a small -local network.
      • -
    • Single public IP address.
      • -
    • Internet connection through cable modem, DSL, ISDN, - Frame Relay, dial-up ...
      • - +
    • Linux system used as a firewall/router for a small + local network.
      • +
    • Single public IP address.
      • +
    • Internet connection through cable modem, DSL, ISDN, + Frame Relay, dial-up ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

    If you are running Shorewall under Mandrake 9.0 or later, you can easily - configure the above setup using the Mandrake "Internet Connection Sharing" - applet. From the Mandrake Control Center, select "Network & Internet" - then "Connection Sharing".
    -

    - -

    Note however, that the Shorewall configuration produced by Mandrake -Internet Connection Sharing is strange and is apt to confuse you if you use -the rest of this documentation (it has two local zones; "loc" and "masq" -where "loc" is empty; this conflicts with this documentation which assumes -a single local zone "loc"). We therefore recommend that once you have set -up this sharing that you uninstall the Mandrake Shorewall RPM and install -the one from the download page then follow the +

    + +

    If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing".
    +

    + +

    Note however, that the Shorewall configuration produced by Mandrake + Internet Connection Sharing is strange and is apt to confuse you if you +use the rest of this documentation (it has two local zones; "loc" and "masq" +where "loc" is empty; this conflicts with this documentation which assumes +a single local zone "loc"). We therefore recommend that once you have set +up this sharing that you uninstall the Mandrake Shorewall RPM and install +the one from the download page then follow the instructions in this Guide.
    -

    - -

    Shorewall requires that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can - tell if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command -to check for this program:

    - -
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are - flagged with - . Configuration notes that are unique to LEAF/Bering are -marked with (LEAF Logo)

    - + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can + tell if this package is installed by the presence of an ip +program on your firewall system. As root, you can use the 'which' +command to check for this program:

    + +
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    + +

    I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your +configuration changes. Points at which configuration changes are + recommended are flagged with + . Configuration notes that are unique to LEAF/Bering are + marked with (LEAF Logo) +

    +

    -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a -floppy disk, you must run dos2unix against the copy before using it with -Shorewall.

    - +     If you edit your configuration files on a Windows +system, you must save them as Unix files if your editor supports +that option or you must run them through dos2unix before trying to +use them. Similarly, if you copy a configuration file from your Windows +hard drive to a floppy disk, you must run dos2unix against the copy +before using it with Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the -directory /etc/shorewall -- for simple setups, you will only need to +     The configuration files for Shorewall are contained in the +directory /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, download the two-interface -sample, un-tar it (tar -zxvf two-interfaces.tgz) and and copy -the files to /etc/shorewall (these files will replace files with -the same name).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration -instructions and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the two-interface sample configuration, the - following zone names are used:

    - + href="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface sample, + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to + /etc/shorewall (these files will replace files with the same name).

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration + instructions and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the two-interface sample configuration, +the following zone names are used:

    + - + + + + + - - - - - - - - - - - - - + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    netThe Internet
    locYour Local Network
    - -

    Zones are defined in the /etc/shorewall/zones - file.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - - - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that - file matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or - DROP  the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the two-interface sample has -the following policies:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -
    -

    In the two-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

    +

    Zones are defined in the /etc/shorewall/zones + file.

    + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    + + + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that + file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT +or DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the two-interface sample +has the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - +
    + +
    +

    In the two-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

    + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network - to the internet
      2. -
    2. drop (ignore) all connection requests from the internet - to your firewall or local network
      3. -
    3. optionally accept all connection requests from the -firewall to the internet (if you uncomment the additional policy)
      4. -
    4. reject all other connection requests.
      5. - +
    5. allow all connection requests from your local network + to the internet
      6. +
    6. drop (ignore) all connection requests from the internet + to your firewall or local network
      7. +
    7. optionally accept all connection requests from the + firewall to the internet (if you uncomment the additional policy)
      8. +
    8. reject all other connection requests.
      9. +
    - +

    -     At this point, edit your /etc/shorewall/policy and make - any changes that you wish.

    - +     At this point, edit your /etc/shorewall/policy and +make any changes that you wish.

    +

    Network Interfaces

    - +

    -

    - -

    The firewall has two network interfaces. Where Internet -connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect - via a regular modem, your External Interface will also be ppp0. - If you connect via ISDN, your external interface will be ippp0.

    - +

    + +

    The firewall has two network interfaces. Where Internet connectivity +is through a cable or DSL "Modem", the External Interface will be +the ethernet adapter that is connected to that "Modem" (e.g., eth0)  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect + via a regular modem, your External Interface will also be ppp0. + If you connect via ISDN, your external interface will be ippp0.

    +

    -     If your external interface is ppp0 or ippp0  - then you will want to set CLAMPMSS=yes in ppp0 or ippp0  + then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    - -

    Your Internal Interface will be an ethernet adapter - (eth1 or eth0) and will be connected to a hub or switch. Your other - computers will be connected to the same hub/switch (note: If you have - only a single internal system, you can connect the firewall directly - to the computer using a cross-over cable).

    - + +

    Your Internal Interface will be an ethernet adapter + (eth1 or eth0) and will be connected to a hub or switch. Your other + computers will be connected to the same hub/switch (note: If you +have only a single internal system, you can connect the firewall +directly to the computer using a cross-over cable).

    +

    - Do not connect the internal and external interface - to the same hub or switch (even for testing). It won't work the way - that you think that it will and you will end up confused and believing - that Shorewall doesn't work at all.

    - + Do not connect the internal and external interface + to the same hub or switch (even for testing). It won't work the way + that you think that it will and you will end up confused and believing + that Shorewall doesn't work at all.

    +

    -     The Shorewall two-interface sample configuration assumes - that the external interface is eth0 and the internal interface - is eth1. If your configuration is different, you will have to - modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the +     The Shorewall two-interface sample configuration assumes + that the external interface is eth0 and the internal interface + is eth1. If your configuration is different, you will have +to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list of options that are specified for the interfaces. Some hints:

    - +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-". -

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from -the option list.

      -
      • - +
    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from + the option list.

      +
      • +
    - +

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via - the Dynamic Host Configuration Protocol (DHCP) or as part of -establishing your connection when you dial in (standard modem) or establish -your PPP connection. In rare cases, your ISP may assign you a static -IP address; that means that you configure your firewall's external interface - to use that address permanently. However your external address - is assigned, it will be shared by all of your systems when you access the - Internet. You will have to assign your own addresses in your internal -network (the Internal Interface on your firewall plus your other computers). -RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign +you a single Public IP address. This address may be assigned +via the Dynamic Host Configuration Protocol (DHCP) or as part +of establishing your connection when you dial in (standard modem) or +establish your PPP connection. In rare cases, your ISP may assign you +a static IP address; that means that you configure your firewall's +external interface to use that address permanently. However +your external address is assigned, it will be shared by all of your systems +when you access the Internet. You will have to assign your own addresses +in your internal network (the Internal Interface on your firewall plus +your other computers). RFC 1918 reserves several Private IP address +ranges for this purpose:

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    +
    + +

    -     Before starting Shorewall, you should look at the -IP address of your external interface and if it is one of the above - ranges, you should remove the 'norfc1918' option from the external - interface's entry in /etc/shorewall/interfaces.

    -
    - -
    -

    You will want to assign your addresses from the same -sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a - subnet will have a Subnet Mask of 255.255.255.0. The address - x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is - reserved as the Subnet Broadcast Address. In Shorewall, - a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive leading "1" -bits from the left of the subnet mask.

    -
    - -
    +     Before starting Shorewall, you should look at the + IP address of your external interface and if it is one of the +above ranges, you should remove the 'norfc1918' option from the +external interface's entry in /etc/shorewall/interfaces.

    +
    + +
    +

    You will want to assign your addresses from the same + sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such +a subnet will have a Subnet Mask of 255.255.255.0. The address + x.y.z.0 is reserved as the Subnet Address and x.y.z.255 +is reserved as the Subnet Broadcast Address. In Shorewall, + a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive leading "1" + bits from the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    + +
    + +
    +

    It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above + example) or the last usable address (10.10.10.254).

    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above - example) or the last usable address (10.10.10.254).

    -
    - -
    -

    One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

    -
    - -
    + +
    +

    One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

    +
    + +

    -     Your local computers (computer 1 and computer 2 in -the above diagram) should be configured with their default gateway - to be the IP address of the firewall's internal interface.      -

    -
    - -

    The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", -Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    The remainder of this quide will assume that you have configured - your network as shown here:

    - +     Your local computers (computer 1 and computer 2 +in the above diagram) should be configured with their default +gateway to be the IP address of the firewall's internal interface.      +

    +
    + +

    The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP +Fundamentals: What Everyone Needs to Know about Addressing & +Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    The remainder of this quide will assume that you have configured + your network as shown here:

    +

    -

    - +

    +

    The default gateway for computer's 1 & 2 would be 10.10.10.254.
    -

    - +

    +

    -     WARNING: Your ISP might assign - your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 - subnet then you will need to select a DIFFERENT RFC 1918 subnet for your - local network.
    -

    - +     WARNING: Your ISP might +assign your external interface an RFC 1918 address. If that address is +in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC +1918 subnet for your local network.
    +

    +

    IP Masquerading (SNAT)

    - -

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume computer 1) sends a connection -request to an internet host, the firewall must perform Network Address -Translation (NAT). The firewall rewrites the source address in -the packet to be the address of the firewall's external interface; in -other words, the firewall makes it look as if the firewall itself is -initiating the connection.  This is necessary so that the destination - host will be able to route return packets back to the firewall (remember - that packets whose destination address is reserved by RFC 1918 can't - be routed across the internet so the remote host can't address its response - to computer 1). When the firewall receives a return packet, it rewrites - the destination address back to 10.10.10.1 and forwards the packet on -to computer 1.

    - -

    On Linux systems, the above process is often referred to as - IP Masquerading but you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

    - + +

    The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers +don't forward packets which have an RFC-1918 destination address. +When one of your local systems (let's assume computer 1) sends a connection + request to an internet host, the firewall must perform Network +Address Translation (NAT). The firewall rewrites the source address +in the packet to be the address of the firewall's external interface; +in other words, the firewall makes it look as if the firewall itself +is initiating the connection.  This is necessary so that the destination + host will be able to route return packets back to the firewall (remember + that packets whose destination address is reserved by RFC 1918 can't + be routed across the internet so the remote host can't address its response + to computer 1). When the firewall receives a return packet, it rewrites + the destination address back to 10.10.10.1 and forwards the packet on + to computer 1.

    + +

    On Linux systems, the above process is often referred to +as IP Masquerading but you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

    +
      -
    • -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - +
    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      +
      • +
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading - if your external IP is dynamic and SNAT if the IP is static.

    - + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file. You will normally use +Masquerading if your external IP is dynamic and SNAT if the IP +is static.

    +

    -     If your external firewall interface is eth0, -you do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change the first column to the name -of your external interface and the second column to the name of your +     If your external firewall interface is eth0, +you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change the first column to the name +of your external interface and the second column to the name of your internal interface.

    - +

    -     If your external IP is static, you can enter it in -the third column in the /etc/shorewall/masq entry if you like although - your firewall will work fine if you leave that column empty. Entering - your static IP in column 3 makes processing outgoing packets a little - more efficient.
    -
    - +
    + -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, -change them appropriately:
    -

    - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, + change them appropriately:
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    - +

    Port Forwarding (DNAT)

    - -

    One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, - it is not possible for clients on the internet to connect directly to - them. It is rather necessary for those clients to address their connection - requests to the firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When - your server responds, the firewall automatically performs SNAT to rewrite - the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure -port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

    - -
    + +

    One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, + it is not possible for clients on the internet to connect directly +to them. It is rather necessary for those clients to address their +connection requests to the firewall who rewrites the destination address +to the address of your server and forwards the packet to that server. +When your server responds, the firewall automatically performs SNAT +to rewrite the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure + port forwarding using DNAT rules in the /etc/shorewall/rules file.

    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:<server local ip address> [:<server - port>]<protocol><port>  
    DNATnetloc:<server local ip address> [:<server + port>]<protocol><port>  
    -
    - -

    Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

    - -
    +
    + +

    Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2tcp80  
    DNATnetloc:10.10.10.2tcp80  
    -
    - +
    +

    A couple of important points to keep in mind:

    - +
      -
    • You must test the above rule from a client outside -of your local network (i.e., don't test from a browser running on -computers 1 or 2 or on the firewall). If you want to be able to -access your web server using the IP address of your external interface, +
    • You must test the above rule from a client outside + of your local network (i.e., don't test from a browser running +on computers 1 or 2 or on the firewall). If you want to be able +to access your web server using the IP address of your external interface, see Shorewall FAQ #2.
      • -
    • Many ISPs block incoming connection requests to port - 80. If you have problems connecting to your web server, try the -following rule and try connecting to port 5000.
      • - +
    • Many ISPs block incoming connection requests to +port 80. If you have problems connecting to your web server, try +the following rule and try connecting to port 5000.
      • +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2:80tcp5000  
    DNATnetloc:10.10.10.2:80tcp5000  
    -
    - +
    +

    -     At this point, modify /etc/shorewall/rules to add any - DNAT rules that you require.

    - +     At this point, modify /etc/shorewall/rules to add +any DNAT rules that you require.

    +

    Domain Name Server (DNS)

    - -

    Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file -will be written). Alternatively, your ISP may have given you the IP -address of a pair of DNS name servers for you to manually configure -as your primary and secondary name servers. Regardless of how DNS gets - configured on your firewall, it is your responsibility to configure - the resolver in your internal systems. You can take one of two approaches:

    - + +

    Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) +resolver will be automatically configured (e.g., the /etc/resolv.conf +file will be written). Alternatively, your ISP may have given you +the IP address of a pair of DNS name servers for you to manually +configure as your primary and secondary name servers. Regardless of +how DNS gets configured on your firewall, it is your responsibility +to configure the resolver in your internal systems. You can take one +of two approaches:

    +
      -
    • -

      You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers - or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information - isn't available, look in /etc/resolv.conf on your firewall system - -- the name servers are given in "nameserver" records in that file. -

      -
      • -
    • +
    • +

      You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can +configure your internal systems to use those addresses. If that +information isn't available, look in /etc/resolv.conf on your firewall +system -- the name servers are given in "nameserver" records in that +file.

      +
      • +

    • -     You can configure a Caching Name Server on your - firewall. Red Hat has an RPM for a caching name server - (the RPM also requires the 'bind' RPM) and for Bering users, there - is dnscache.lrp. If you take this approach, you configure your internal - systems to use the firewall itself as their primary (and only) name -server. You use the internal IP address of the firewall (10.10.10.254 -in the example above) for the name server address. To allow your -local systems to talk to your caching name server, you must open port -53 (both UDP and TCP) from the local network to the firewall; you -do that by adding the following rules in /etc/shorewall/rules.

      -
      • - +     You can configure a Caching Name Server on your + firewall. Red Hat has an RPM for a caching name server + (the RPM also requires the 'bind' RPM) and for Bering users, there + is dnscache.lrp. If you take this approach, you configure your internal + systems to use the firewall itself as their primary (and only) name +server. You use the internal IP address of the firewall (10.10.10.254 +in the example above) for the name server address. To allow your local +systems to talk to your caching name server, you must open port 53 +(both UDP and TCP) from the local network to the firewall; you do +that by adding the following rules in /etc/shorewall/rules.

      + +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    -
    - -
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The two-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you uncommented the line in /etc/shorewall/policy +allowing all connections from the firewall to the internet.

    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you uncommented the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

    -
    - -
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    -
    + +
    + +
    +

    That rule allows you to run an SSH server on your firewall + and connect to that server from your local systems.

    - -
    -

    That rule allows you to run an SSH server on your firewall - and connect to that server from your local systems.

    -
    - -
    -

    If you wish to enable other connections between your firewall - and other systems, the general format is:

    -
    - -
    -
    + +
    +

    If you wish to enable other connections between your firewall + and other systems, the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a Web Server on your firewall system:

    - -
    -

    Example - You want to run a Web Server on your firewall -system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80#Allow web accessfrom the internet
    ACCEPTlocfwtcp80#Allow web accessfrom the local network
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80#Allow web accessfrom the internet
    ACCEPTlocfwtcp80#Allow web accessfrom the local network
    -
    +
    +
    + +
    +

    Those two rules would of course be in addition to the rules + listed above under "You can configure a Caching Name Server on + your firewall"

    - -
    -

    Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on -your firewall"

    -
    - -
    -

    If you don't know what port and protocol a particular application + +

    +

    If you don't know what port and protocol a particular application uses, look here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If +you want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible - with Jacques's Shorewall configuration.

    - -
    -
    +     Bering users will want to add the following two rules to be compatible + with Jacques's Shorewall configuration.

    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -
    ACCEPTlocfwtcp80#Allow weblet to work
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    -
    -
    - +
    +
    +


    - -     Now edit your /etc/shorewall/rules file to add or -delete other connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    + +     Now edit your /etc/shorewall/rules file to add or + delete other connections as required.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure - configures your system to start Shorewall at system boot  but beginning - with Shorewall version 1.3.9 startup is disabled so that your system - won't try to start Shorewall before configuration is complete. Once you - have completed configuration of your firewall, you can enable Shorewall - startup by removing the file /etc/shorewall/startup_disabled.
    -

    - +     The installation procedure + configures your system to start Shorewall at system boot  but beginning + with Shorewall version 1.3.9 startup is disabled so that your system + won't try to start Shorewall before configuration is complete. Once +you have completed configuration of your firewall, you can enable Shorewall + startup by removing the file /etc/shorewall/startup_disabled.
    +

    +

    IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
    -

    + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall + and set 'startup=1'.
    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall +from your Netfilter configuration, use "shorewall clear".

    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" - command. If you want to totally remove any trace of Shorewall from - your Netfilter configuration, use "shorewall clear".

    -
    - -
    + +

    -     The two-interface sample assumes that you want to enable - routing to/from eth1 (the local network) when Shorewall is - stopped. If your local network isn't connected to eth1 or if you - wish to enable access to/from other hosts, change /etc/shorewall/routestopped - accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate -configuration and test it using the eth1 (the local network) when Shorewall +is stopped. If your local network isn't connected to eth1 or +if you wish to enable access to/from other hosts, change /etc/shorewall/routestopped + accordingly.

    +
    + + - +
    +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Eastep
    -

    + +

    Copyright 2002, 2003 + Thomas M. Eastep
    +

    +



    diff --git a/Shorewall-docs/two-interface_fr.html b/Shorewall-docs/two-interface_fr.html index 57fd34291..405e6685d 100755 --- a/Shorewall-docs/two-interface_fr.html +++ b/Shorewall-docs/two-interface_fr.html @@ -1,1380 +1,1378 @@ - + Two-Interface Firewall - + - + - + - + - + - + - +


    -

    - +

    + - - - + + - - - + + + +
    +

    Basic Two-Interface Firewall

    -
    - +

    Version 2.0.1 Française

    - +


    - Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon -travail n’est pas des plus précis (loin de là...). Je ne me -suis pas attaché à une traduction exacte du texte, mais plutôt -à en faire une version française intelligible par tous (et -par moi). Les termes techniques sont la plupart du temps conservés -sous leur forme originale et mis entre parenthèses car vous pouvez -les retrouver dans le reste des documentations ainsi que dans les fichiers -de configuration. N’hésitez pas à me contacter afin d’améliorer -ce document VETSEL Patrice -(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi + Notes du traducteur :
    + Je ne prétends pas être un vrai traducteur dans le sens ou +mon travail n’est pas des plus précis (loin de là...). Je ne +me suis pas attaché à une traduction exacte du texte, mais +plutôt à en faire une version française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps conservés +sous leur forme originale et mis entre parenthèses car vous pouvez +les retrouver dans le reste des documentations ainsi que dans les fichiers +de configuration. N’hésitez pas à me contacter afin d’améliorer +ce document VETSEL Patrice + (merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour son formidable outil et sa disponibilité)    .
    -
    -

    - -

    Mettre en place un système Linux en tant que firewall -pour un petit réseau est une chose assez simple, si vous comprenez +
    +

    + +

    Mettre en place un système Linux en tant que firewall +pour un petit réseau est une chose assez simple, si vous comprenez les bases et suivez la documentation.

    - -

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il -se focalise sur ce qui est nécessaire pour configurer Shorewall, dans + +

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il se +focalise sur ce qui est nécessaire pour configurer Shorewall, dans son utilisation la plus courante :

    - +
      -
    • -

      Un système Linux utilisé +

    • +

      Un système Linux utilisé en tant que firewall/routeur pour un petit réseau local.

      -
      • -
    • +
      • +

    • Une seule adresse IP publique.

      -
      • -
    • -

      Une connexion Internet par le biais d'un modem câble, ADSL, +

      • +
    • +

      Une connexion Internet par le biais d'un modem câble, ADSL, ISDN, "Frame Relay", RTC ...

      -
      • - + +
    - +

    Voici un schéma d'une installation typique.

    - +

    -

    - -

    Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent, -vous pouvez facilement réaliser la configuration ci-dessus en utilisant -l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control -Center", sélectionnez "Network & Internet" et "Connection Sharing". -Vous ne devriez pas avoir besoin de vous référer à ce +

    + +

    Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent, +vous pouvez facilement réaliser la configuration ci-dessus en utilisant +l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control +Center", sélectionnez "Network & Internet" et "Connection Sharing". +Vous ne devriez pas avoir besoin de vous référer à ce guide.

    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. -Vous pouvez voir si le paquet est installé en vérifiant -la présence du programme ip sur votre système de firewall. -Sous root, utilisez la commande 'which' pour rechercher le programme :

    - + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant +la présence du programme ip sur votre système de firewall. Sous +root, utilisez la commande 'which' pour rechercher le programme :

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    Je vous recommande dans un premier temps de parcourir tout le guide pour -vous familiariser avec ce qui va se passer, et de revenir au début -en effectuant le changements dans votre configuration. Les points où, -les changements dans la configuration sont recommandées, sont signalés + +

    Je vous recommande dans un premier temps de parcourir tout le guide pour +vous familiariser avec ce qui va se passer, et de revenir au début +en effectuant le changements dans votre configuration. Les points où, +les changements dans la configuration sont recommandées, sont signalés par une -.

    - + .

    +

    -    Si vous éditez vos fichiers de configuration sur -un système Windows, vous devez les sauver comme des fichiers Unix -si votre éditeur offre cette option sinon vous devez les faire passer -par dos2unix avant d'essayer de les utiliser. De la même manière, -si vous copiez un fichier de configuration depuis votre disque dur Windows -vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser +     Si vous éditez vos fichiers de configuration sur +un système Windows, vous devez les sauver comme des fichiers Unix si +votre éditeur offre cette option sinon vous devez les faire passer +par dos2unix avant d'essayer de les utiliser. De la même manière, +si vous copiez un fichier de configuration depuis votre disque dur Windows +vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.

    - + - +

    Les Concepts de Shorewall

    - +

    -    Les fichiers de configuration pour Shorewall sont dans -le répertoire /etc/shorewall -- pour de simples configurations, vous -n'aurez seulement à faire qu'avec quelques fichiers comme décrit -dans ce guide. Après avoir installé Shorewall, -télé chargez le two-interface -sample, un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers -vers /etc/shorewall (ces fichiers remplaceront les fichiers de même -nom).

    - -

    Parallèlement à la présentation de chacun des fichiers, -je vous suggère de regarder le fichier qui se trouve réellement -sur votre système -- tous les fichiers contiennent des instructions -de configuration détaillées et des valeurs par défaut.

    - -

    Shorewall voit le réseau où il tourne, comme un ensemble -de zones. Dans une configuration avec deux interfaces, les noms des -zones suivantes sont utilisés:

    - - - - - - - - - - - - - - - +     Les fichiers de configuration pour Shorewall sont dans +le répertoire /etc/shorewall -- pour de simples configurations, vous +n'aurez seulement à faire qu'avec quelques fichiers comme décrit + dans ce guide. Après avoir installé +Shorewall, télé chargez le two-interface sample, +un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers vers /etc/shorewall +(ces fichiers remplaceront les fichiers de même nom).

    - +

    Parallèlement à la présentation de chacun des fichiers, +je vous suggère de regarder le fichier qui se trouve réellement +sur votre système -- tous les fichiers contiennent des instructions +de configuration détaillées et des valeurs par défaut.

    + +

    Shorewall voit le réseau où il tourne, comme un ensemble +de zones. Dans une configuration avec deux interfaces, les noms des +zones suivantes sont utilisés:

    + +
    -

    Nom

    -     		-

    Description

    -
    -

    net

    -     		-

    Internet

    -
    -

    loc

    -     		-

    Votre réseau local

    -
    + + + + + + + + + + + + + + +
    +

    Nom

    +     		+

    Description

    +
    +

    net

    +     		+

    Internet

    +
    +

    loc

    +     		+

    Votre réseau local

    +
    - +

    Les zones sont définies dans le fichier/etc/shorewall/zones .

    - -

    Shorewall reconnaît aussi le système de firewall comme sa + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone - par défaut, le firewall est connu comme fw.

    - -

    Les règles à propos de quel trafic autoriser, et de quel + +

    Les règles à propos de quel trafic autoriser, et de quel trafic interdire sont exprimées en terme de zones.

    - +
      -
    • -

      Vous exprimez votre politique par défaut +

    • +

      Vous exprimez votre politique par défaut pour les connexions d'une zone vers une autre zone dans le fichier /etc/shorewall/policy .

      -
      • -
    • -

      Vous définissez les exceptions à ces politiques pas -défaut dans le fichier /etc/shorewall/rules - .

      -
      • - + +
    • +

      Vous définissez les exceptions à ces politiques pas +défaut dans le fichier /etc/shorewall/rules + .

      +
      • +
    - -

    Pour chaque connexion demandant à entrer dans le firewall, la requête -est en premier lieu comparée par rapport au fichier /etc/shorewall/rules. -Si aucune règle dans ce fichier ne correspond à la demande -de connexion alors la première politique dans le fichier /etc/shorewall/policy -qui y correspond sera appliquée. Si cette politique est REJECT ou -DROP  la requête est dans un premier temps comparée par -rapport aux règles contenues dans /etc/shorewall/common.

    - -

    Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface) + +

    Pour chaque connexion demandant à entrer dans le firewall, la requête +est en premier lieu comparée par rapport au fichier /etc/shorewall/rules. +Si aucune règle dans ce fichier ne correspond à la demande de +connexion alors la première politique dans le fichier /etc/shorewall/policy +qui y correspond sera appliquée. Si cette politique est REJECT ou DROP  +la requête est dans un premier temps comparée par rapport aux +règles contenues dans /etc/shorewall/common.

    + +

    Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface) a les politiques suivantes:

    - +
    -
    +
    - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + +
    +

    Source Zone

    -     		+

    Destination Zone

    -     		+

    Policy

    -     		+

    Log Level

    -     		+

    Limit:Burst

    -
    +

    loc

    -     		+

    net

    -     		+

    ACCEPT

    -     		+

     

    -     		+

     

    -
    +

    net

    -     		+

    all

    -     		+

    DROP

    -     		+

    info

    -     		+

     

    -
    +

    all

    -     		+

    all

    -     		+

    REJECT

    -     		+

    info

    -     		+

     

    -
    -
    +
    - -
    Dans le fichier d'exemple (two-interface), la ligne suivante -est inclue mais elle est commentée. Si vous voulez que votre firewall -puisse avoir un accès complet aux serveurs sur Internet, décommentez + +
    Dans le fichier d'exemple (two-interface), la ligne suivante est +inclue mais elle est commentée. Si vous voulez que votre firewall puisse +avoir un accès complet aux serveurs sur Internet, décommentez la ligne.
    - +
    -
    +
    - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + +
    +

    Source Zone

    -     		+

    Destination Zone

    -     		+

    Policy

    -     		+

    Log Level

    -     		+

    Limit:Burst

    -
    +

    fw

    -     		+

    net

    -     		+

    ACCEPT

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Ces politiques vont:

    - +
      -
    1. -

      permettre toutes les demandes de connexion +

    2. +

      permettre toutes les demandes de connexion depuis votre réseau local vers l'Internet

      -
      3. -
    3. -

      drop (ou ignorer) toutes les demandes -de connexion depuis l'Internet vers votre firewall ou votre réseau +

      4. +
    4. +

      drop (ou ignorer) toutes les demandes +de connexion depuis l'Internet vers votre firewall ou votre réseau local.

      -
      5. -
    5. -

      Facultativement accepter toutes les - demandes de connexion de votre firewall vers l'Internet (si vous avez dé +

      6. +
    6. +

      Facultativement accepter toutes les + demandes de connexion de votre firewall vers l'Internet (si vous avez dé commenté la politique additionnelle)

      -
      7. -
    7. +
      8. +

    8. reject (rejeter) toutes les autres demandes de connexion.

      -
      9. - + +
    - +

    -    A ce point, éditez votre fichier /etc/shorewall/policy +     A ce point, éditez votre fichier /etc/shorewall/policy et faite les changements que vous désirez.

    - +

    Network Interfaces

    - +

    -

    - -

    Le firewall a deux interfaces de réseau. Lorsque la -connexion Internet passe par le câble ou par un ROUTEUR (pas un simple -modem) ADSL (non USB), l'interface vers l'extérieur (External Interface) -sera l'adaptateur sur lequel est connecté le routeur (e.g., eth0)  -à moins que vous ne vous connectiez par Point-to-PointProtocol -overEthernet (PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), -dans ce cas l'interface extérieure sera une interface de type ppp -(e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre -interface extérieure sera aussi ppp0. Si votre connexion passe +

    + +

    Le firewall a deux interfaces de réseau. Lorsque la +connexion Internet passe par le câble ou par un ROUTEUR (pas un simple +modem) ADSL (non USB), l'interface vers l'extérieur (External Interface) +sera l'adaptateur sur lequel est connecté le routeur (e.g., eth0)  +à moins que vous ne vous connectiez par Point-to-PointProtocol +overEthernet (PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), + dans ce cas l'interface extérieure sera une interface de type ppp +(e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre +interface extérieure sera aussi ppp0. Si votre connexion passe par Numéris (ISDN), votre interface extérieure seraippp0.

    - +

    -    Si votre interface vers l'extérieur estppp0 +     Si votre interface vers l'extérieur estppp0 ou ippp0  alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    - -

    Votre Internal Interface (interface vers votre réseau -local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée -à un hub ou switch (ou un PC avec un câble croisé). Vos + +

    Votre Internal Interface (interface vers votre réseau +local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée +à un hub ou switch (ou un PC avec un câble croisé). Vos autres ordinateurs seront connectés à ce même hub/switch

    - +

    -Ne connectez pas l'interface interne et externe sur le même -hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez + Ne connectez pas l'interface interne et externe sur le même +hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que ce soit shorewall qui ne marche pas.

    - +

    -    Le fichier de configuration d'exemple pour deux interfaces -suppose que votre interface externe est eth0et que l'interne est eth1. -Si votre configuration est différente, vous devrez modifier le fichier -/etc/shorewall/interfaces en conséquence. -Tant que vous y êtes, vous pourriez parcourir la liste des options -qui sont spécifiées pour les interfaces. Quelques trucs:

    - +     Le fichier de configuration d'exemple pour deux interfaces +suppose que votre interface externe est eth0et que l'interne est eth1. + Si votre configuration est différente, vous devrez modifier le fichier +/etc/shorewall/interfaces en conséquence. +Tant que vous y êtes, vous pourriez parcourir la liste des options qui +sont spécifiées pour les interfaces. Quelques trucs:

    +
      -
    • -

      Si votre interface vers l'extérieur est ppp0 -ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne +

    • +

      Si votre interface vers l'extérieur est ppp0 + ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface vers l'extérieur est ppp0 -ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever +

      • +
    • +

      Si votre interface vers l'extérieur est ppp0 +ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever "dhcp" dans la liste des options.

      -
      • - + +
    - +

    Adresses IP

    - -

    Avant d'aller plus loin, nous devons dire quelques mots au -sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur -Internet (ISP) vous assignera une seule adresse IP (single PublicIP -address). Cette adresse peut être assignée par le Dynamic -Host Configuration Protocol(DHCP) ou lors de l'établissement de -votre connexion lorsque vous vous connectez (modem standard) ou établissez -votre connexion PPP. Dans de rares cas , votre provider peut vous assigner -une adresse statique (staticIP address); cela signifie que vous devez -configurer l'interface externe de votre firewall afin d'utiliser cette adresse -de manière permanente. Votre adresse externe assignée, elle -va être partagée par tous vos systèmes lors de l'accès -à Internet. Vous devrez assigner vos propres adresses dans votre réseau -local (votre interface interne sur le firewall  ainsi que les autres -ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (PrivateIP -address ranges) à cette fin :

    - + +

    Avant d'aller plus loin, nous devons dire quelques mots au +sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur +Internet (ISP) vous assignera une seule adresse IP (single PublicIP + address). Cette adresse peut être assignée par le Dynamic + Host Configuration Protocol(DHCP) ou lors de l'établissement +de votre connexion lorsque vous vous connectez (modem standard) ou établissez +votre connexion PPP. Dans de rares cas , votre provider peut vous assigner +une adresse statique (staticIP address); cela signifie que vous devez +configurer l'interface externe de votre firewall afin d'utiliser cette adresse +de manière permanente. Votre adresse externe assignée, elle +va être partagée par tous vos systèmes lors de l'accès + à Internet. Vous devrez assigner vos propres adresses dans votre +réseau local (votre interface interne sur le firewall  ainsi +que les autres ordinateurs). La RFC 1918 réserve plusieurs plages +d'IP (PrivateIP address ranges) à cette fin :

    + 
         10.0.0.0    - 10.255.255.255an
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    - +

    -    Avant de lancer Shorewall, vous devriez regarder l'adresse -IP de votre interface externe, et si elle est dans les plages précédentes, -vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface +     Avant de lancer Shorewall, vous devriez regarder l'adresse +IP de votre interface externe, et si elle est dans les plages précédentes, +vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface externe dans le fichier /etc/shorewall/interfaces.

    - -

    Vous devrez assigner vos adresses depuis le même sous-réseau -(sub-network/subnet). Pour ce faire, nous pouvons considérer -un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque -sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. -L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau -(Subnet Address) et x.y.z.255 est réservée en tant qu'adresse -de broadcast (Subnet Broadcast Address). Dans Shorewall, un -sous-réseau est décrit en utilisant la notation Classless InterDomain -Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie -par "/24". Le "24" se réfère au nombre consécutif de + +

    Vous devrez assigner vos adresses depuis le même sous-réseau +(sub-network/subnet). Pour ce faire, nous pouvons considérer +un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque +sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. L'adresse +x.y.z.0 est réservée comme l'adresse de sous-réseau (Subnet +Address) et x.y.z.255 est réservée en tant qu'adresse de +broadcast (Subnet Broadcast Address). Dans Shorewall, un sous-réseau +est décrit en utilisant la notation Classless InterDomain +Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie +par "/24". Le "24" se réfère au nombre consécutif de bits marquant "1" dans la partie gauche du masque de sous-réseau.

    - +

    Un exemple de sous-réseau (sub-network) :

    - +
    -
    +
    - - - + + - + - - - + + + - + - - - + + + - + - - - + + + - + - - - + + + +
    +

    Plage:

    -     		+

    10.10.10.0 - 10.10.10.255

    -
    +

    Subnet Address:

    -     		+

    10.10.10.0

    -
    +

    Broadcast Address:

    -     		+

    10.10.10.255

    -
    +

    CIDR Notation:

    -     		+

    10.10.10.0/24

    -
    -
    +
    - -

    Il est de mise d'assigner l'interface interne (LAN) à -la première adresse utilisable du sous-réseau (10.10.10.1 dans -l'exemple précédent) ou la dernière adresse utilisable + +

    Il est de mise d'assigner l'interface interne (LAN) à +la première adresse utilisable du sous-réseau (10.10.10.1 dans +l'exemple précédent) ou la dernière adresse utilisable (10.10.10.254).

    - -

    L'un des buts d'un sous-réseau est de permettre à -tous les ordinateurs dans le sous-réseau de savoir avec quels autres -ordinateurs ils peuvent communiquer directement. Pour communiquer avec des -systèmes en dehors du sous-réseau, les ordinateurs envoient + +

    L'un des buts d'un sous-réseau est de permettre à +tous les ordinateurs dans le sous-réseau de savoir avec quels autres +ordinateurs ils peuvent communiquer directement. Pour communiquer avec des +systèmes en dehors du sous-réseau, les ordinateurs envoient des paquets à travers le gateway (routeur).

    - +

    -    Vos ordinateurs en local (ordinateur 1 et ordinateur 2 -dans le diagramme) devraient être configurés avec leur passerelle -par défaut (default gateway) pointant sur l'adresse IP de l'interface -interne du firewall.

    - -

    The foregoing short discussion barely scratches the surface -regarding subnetting and routing. If you are interested in learning more -about IP addressing and routing, I highly recommend "IP Fundamentals: -What Everyone Needs to Know about Addressing & Routing", Thomas A. -Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    Le reste de ce guide assumera que vous avez configuré +     Vos ordinateurs en local (ordinateur 1 et ordinateur +2 dans le diagramme) devraient être configurés avec leur passerelle + par défaut (default gateway) pointant sur l'adresse IP de +l'interface interne du firewall.

    + +

    The foregoing short discussion barely scratches the surface +regarding subnetting and routing. If you are interested in learning more about +IP addressing and routing, I highly recommend "IP Fundamentals: What Everyone +Needs to Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, +1999, ISBN 0-13-975483-0.

    + +

    Le reste de ce guide assumera que vous avez configuré votre réseau comme montré ci-dessous :

    - +

    -

    - -

    La passerelle par défaut pour les ordinateurs 1 et +

    + +

    La passerelle par défaut pour les ordinateurs 1 et 2 devrait être 10.10.10.254.

    - +

    IP Masquerading (SNAT)

    - -

    Les adresses réservées par la RFC 1918 sont -parfois désignées comme non-routables car les routeurs -Internet (backbone) ne font pas circuler les paquets qui ont une adresse -de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes -en local (supposons l'ordinateur1) demande une connexion à un serveur -par Internet, le firewall doit appliquer un NAT (Network Address Translation). -Le firewall ré écrit l'adresse source dans le paquet, et l'a -remplace par l'adresse de l'interface externe du firewall; en d'autres mots, -le firewall fait croire que c'est lui même qui initie la connexion. -Ceci est nécessaire afin que l'hôte de destination soit capable -de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont -pour adresse de destination, une adresse réservée par la RFC -1918 ne pourront pas être routés à travers Internet, -donc l'hôte Internet ne pourra adresser sa réponse à -l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, -il remet l'adresse de destination à 10.10.10.1 et fait passer le paquet -vers l'ordinateur 1.

    - -

    Sur les systèmes Linux, ce procédé est -souvent appelé de l'IP Masquerading mais vous verrez aussi -le terme de Source Network Address Translation (SNAT) utilisé. + +

    Les adresses réservées par la RFC 1918 sont +parfois désignées comme non-routables car les routeurs +Internet (backbone) ne font pas circuler les paquets qui ont une adresse de +destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes +en local (supposons l'ordinateur1) demande une connexion à un serveur +par Internet, le firewall doit appliquer un NAT (Network Address Translation). +Le firewall ré écrit l'adresse source dans le paquet, et l'a +remplace par l'adresse de l'interface externe du firewall; en d'autres mots, +le firewall fait croire que c'est lui même qui initie la connexion. + Ceci est nécessaire afin que l'hôte de destination soit capable +de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont +pour adresse de destination, une adresse réservée par la RFC +1918 ne pourront pas être routés à travers Internet, donc +l'hôte Internet ne pourra adresser sa réponse à l'ordinateur +1). Lorsque le firewall reçoit le paquet de réponse, il remet +l'adresse de destination à 10.10.10.1 et fait passer le paquet vers +l'ordinateur 1.

    + +

    Sur les systèmes Linux, ce procédé est +souvent appelé de l'IP Masquerading mais vous verrez aussi le +terme de Source Network Address Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter:

    - +
      -
    • -

      Masquerade désigne le cas ou vous laissez -votre firewall détecter automatiquement l'adresse de l'interface -externe.

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez -explicitement l'adresse source des paquets sortant de votre réseau +

    • +

      Masquerade désigne le cas ou vous laissez +votre firewall détecter automatiquement l'adresse de l'interface externe. +

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez +explicitement l'adresse source des paquets sortant de votre réseau local.

      -
      • - + +
    - -

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré -avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez -normalement le Masquerading si votre adresse IP externe est dynamique, et + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré +avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez +normalement le Masquerading si votre adresse IP externe est dynamique, et SNAT si elle est statique.

    - +

    -    Si votre interface externe du firewall est eth0, -vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans -le cas contraire, éditez /etc/shorewall/masq et changez la première -colonne par le nom de votre interface externe, et la seconde colonne par -le nom de votre interface interne.

    - +     Si votre interface externe du firewall est eth0, +vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans +le cas contraire, éditez /etc/shorewall/masq et changez la première +colonne par le nom de votre interface externe, et la seconde colonne par le +nom de votre interface interne.

    +

    -    Si votre IP externe est statique, vous pouvez la mettre -dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, -de toutes façons votre firewall fonctionnera bien si vous laissez -cette colonne vide. Le fait de mettre votre IP statique dans la troisième +     Si votre IP externe est statique, vous pouvez la mettre +dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, +de toutes façons votre firewall fonctionnera bien si vous laissez cette +colonne vide. Le fait de mettre votre IP statique dans la troisième colonne permet un traitement des paquets sortant un peu plus efficace.
    -
    - -    Si vous utilisez les paquets Debian, vérifiez que -votre fichier de configuration shorewall.conf contient bien les valeurs suivantes, -si elles n'y sont pas faite les changements nécessaires:

    - +
    + +     Si vous utilisez les paquets Debian, vérifiez +que votre fichier de configuration shorewall.conf contient bien les valeurs +suivantes, si elles n'y sont pas faite les changements nécessaires:

    +
      -
    • +

    • NAT_ENABLED=Yes

      -
      • -
    • +
      • +

    • IP_FORWARDING=On

      -
      • - + +
    - +

    Port Forwarding (DNAT)

    - -

    Un de nos buts est de , peut être, faire tourner un -ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs -on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet -de se connecter directement à eux. Il est nécessaire à -ces clients d'adresser leurs demandes de connexion au firewall qui ré -écrit l'adresse de destination de votre serveur, et fait passer le -paquet à celui-ci. Lorsque votre serveur répond, le firewall -applique automatiquement un SNAT pour ré écrire l'adresse source -dans la réponse.

    - -

    Ce procédé est appelé Port Forwarding -ou Destination Network Address Translation(DNAT). Vous configurez -le port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    - -

    La forme générale d'une simple règle de port forwarding + +

    Un de nos buts est de , peut être, faire tourner un +ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs +on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet +de se connecter directement à eux. Il est nécessaire à +ces clients d'adresser leurs demandes de connexion au firewall qui ré +écrit l'adresse de destination de votre serveur, et fait passer le +paquet à celui-ci. Lorsque votre serveur répond, le firewall +applique automatiquement un SNAT pour ré écrire l'adresse source + dans la réponse.

    + +

    Ce procédé est appelé Port Forwarding +ou Destination Network Address Translation(DNAT). Vous configurez le +port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules est:

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:<server local ip address> [:<server port>]

    -     		+

    <protocol>

    -     		+

    <port>

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous -voulez faire passer les requêtes TCP sur le port 80 à ce système + +

    Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous +voulez faire passer les requêtes TCP sur le port 80 à ce système :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:10.10.10.2

    -     		+

    tcp

    -     		+

    80

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Deux points importants à garder en mémoire :

    - +
      -
    • -

      Vous devez tester la règle précédente -depuis un client à l'extérieur de votre réseau local -(c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 -ou 2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder -à votre serveur web en utilisant l'adresse IP externe de votre firewall, +

    • +

      Vous devez tester la règle précédente +depuis un client à l'extérieur de votre réseau local +(c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 ou +2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder +à votre serveur web en utilisant l'adresse IP externe de votre firewall, regardez Shorewall FAQ #2.

      -
      • -
    • -

      Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes -entrantes de connexion sur le port 80. Si vous avez des problèmes -à vous connecter à votre serveur web, essayez la règle +

      • +
    • +

      Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes +entrantes de connexion sur le port 80. Si vous avez des problèmes +à vous connecter à votre serveur web, essayez la règle suivante et connectez vous sur le port 5000.

      -
      • - + +
    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:10.10.10.2:80

    -     		+

    tcp

    -     		+

    5000

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    -    A ce point, modifiez /etc/shorewall/rules pour ajouter +     A ce point, modifiez /etc/shorewall/rules pour ajouter les règles DNAT dont vous avez besoin.

    - +

    Domain Name Server (DNS)

    - -

    Normalement, quand vous vous connectez à votre fournisseur -(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour -le firewall (Domain Name Service) est configuré automatiquement -(c.a.d.,le fichier /etc/resolv.conf a été écrit). Il -arrive que votre provider vous donne une paire d'adresse IP pour les DNS -(name servers) afin que vous configuriez manuellement votre serveur de -nom primaire et secondaire. La manière dont le DNS est configuré -sur votre firewall est de votre responsabilité. Vous pouvez -procéder d'une de ses deux façons :

    - + +

    Normalement, quand vous vous connectez à votre fournisseur +(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour +le firewall (Domain Name Service) est configuré automatiquement +(c.a.d.,le fichier /etc/resolv.conf a été écrit). Il +arrive que votre provider vous donne une paire d'adresse IP pour les DNS +(name servers) afin que vous configuriez manuellement votre serveur de +nom primaire et secondaire. La manière dont le DNS est configuré +sur votre firewall est de votre responsabilité. Vous pouvez + procéder d'une de ses deux façons :

    +
      -
    • -

      Vous pouvez configurer votre système interne -pour utiliser les noms de serveurs de votre provider. Si votre fournisseur -vous donne les adresses de leurs serveurs ou si ces adresses sont disponibles -sur leur site web, vous pouvez configurer votre système interne afin -de les utiliser. Si cette information n' est pas disponible, regardez dans - /etc/resolv.conf sur votre firewall -- les noms des serveurs sont donnés +

    • +

      Vous pouvez configurer votre système interne pour +utiliser les noms de serveurs de votre provider. Si votre fournisseur vous +donne les adresses de leurs serveurs ou si ces adresses sont disponibles +sur leur site web, vous pouvez configurer votre système interne afin +de les utiliser. Si cette information n' est pas disponible, regardez dans + /etc/resolv.conf sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement "nameserver" dans ce fichier.

      -
      • -
    • +
      • +

    • -     Vous pouvez configurer un cache dns (Caching Name -Server) sur votre firewall. Red Hat a un RPM pour mettre en cache -un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs - de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez -votre système interne pour utiliser le firewall lui même comme -étant le seul serveur de nom primaire. Vous pouvez utiliser l'adresse -IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur -de nom. Pour permettre à vos systèmes locaux de discuter avec -votre serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) -sur le firewall vers le réseau local; vous ferez ceci en ajoutant +     Vous pouvez configurer un cache dns (Caching Name +Server) sur votre firewall. Red Hat a un RPM pour mettre en cache +un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs + de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez +votre système interne pour utiliser le firewall lui même comme +étant le seul serveur de nom primaire. Vous pouvez utiliser l'adresse +IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur +de nom. Pour permettre à vos systèmes locaux de discuter avec +votre serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) + sur le firewall vers le réseau local; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.

      -
      • - + +
    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    udp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Autres Connexions

    - -

    Les fichiers exemples inclus dans l'archive (two-interface) + +

    Les fichiers exemples inclus dans l'archive (two-interface) contiennent les règles suivantes :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    fw

    -     		+

    net

    -     		+

    tcp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    +

    ACCEPT

    -     		+

    fw

    -     		+

    net

    -     		+

    udp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Ces règles autorisent l'accès DNS à -partir de votre firewall et peuvent être enlevées si vous avez -dé commenté la ligne dans /etc/shorewall/policy autorisant -toutes les connexions depuis le firewall vers Internet.

    - + +

    Ces règles autorisent l'accès DNS à partir +de votre firewall et peuvent être enlevées si vous avez dé +commenté la ligne dans /etc/shorewall/policy autorisant toutes les +connexions depuis le firewall vers Internet.

    +

    Les exemples contiennent aussi :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    22

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Cette règle vous autorise à faire tourner un -serveur SSH sur votre firewall et à vous y connecter depuis votre -réseau local.

    - -

    Si vous voulez permettre d'autres connexions entre votre -firewall et d'autres systèmes, la forme générale est -:

    - + +

    Cette règle vous autorise à faire tourner un +serveur SSH sur votre firewall et à vous y connecter depuis votre réseau +local.

    + +

    Si vous voulez permettre d'autres connexions entre votre firewall +et d'autres systèmes, la forme générale est :

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    <source zone>

    -     		+

    <destination zone>

    -     		+

    <protocol>

    -     		+

    <port>

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Exemple - Vous voulez faire tourner un serveur Web sur votre + +

    Exemple - Vous voulez faire tourner un serveur Web sur votre firewall :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    net

    -     		+

    fw

    -     		+

    tcp

    -     		+

    80

    -     		+

    #Permet l'accès Web

    -     		+

    depuis Internet

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    80

    -     		+

    #Permet l'accès Web

    -
    -     		+
    +

    depuis Internet

    -
    -
    +
    - -

    Ces deux règles bien sûr viennent s'ajouter -aux règles décrites précédemment dans "Vous pouvez + +

    Ces deux règles bien sûr viennent s'ajouter aux +règles décrites précédemment dans "Vous pouvez configurer un cache dns (Caching Name Server) sur votre firewall"

    - -

    Si vous ne savez pas quel port et quel protocole une application + +

    Si vous ne savez pas quel port et quel protocole une application particulière utilise, regardez ici.

    - -

    Important: Je ne vous recommande pas de permettre -le telnet depuis ou vers Internet car il utilise du texte en clair (même -pour le login et le mot de passe!). Si vous voulez un accès au shell + +

    Important: Je ne vous recommande pas de permettre le +telnet depuis ou vers Internet car il utilise du texte en clair (même +pour le login et le mot de passe!). Si vous voulez un accès au shell sur votre firewall depuis Internet, utilisez SSH :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    net

    -     		+

    fw

    -     		+

    tcp

    -     		+

    22

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    -    Maintenant éditez votre fichier /etc/shorewall/rules +     Maintenant éditez votre fichier /etc/shorewall/rules pour ajouter ou supprimer les connexions voulues.

    - +

    Lancer et Arrêter votre Firewall

    - +

    Arrow -    La  procédure d'installation -configure votre système pour lancer Shorewall au boot du système, -mais pour les débutants sous Shorewall version 1.3.9, le lancement -est désactivé tant que la configuration n' est pas finie. Une -fois la configuration de votre firewall achevée, vous pouvez permettre +     La  procédure d'installation + configure votre système pour lancer Shorewall au boot du système, +mais pour les débutants sous Shorewall version 1.3.9, le lancement +est désactivé tant que la configuration n' est pas finie. Une +fois la configuration de votre firewall achevée, vous pouvez permettre le lancement de Shorewall en enlevant le fichier /etc/shorewall/startup_disabled.

    - -

    IMPORTANT: Les utilisateurs -des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.

    - -

    Le firewall est lancé en utilisant la commande "shorewall -start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé, + +

    IMPORTANT: Les utilisateurs des +paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.

    + +

    Le firewall est lancé en utilisant la commande "shorewall +start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé, le routage est permis sur les hôtes qui sont dans le fichier/etc/shorewall/routestopped. Un -firewall fonctionnant peut être relancé en utilisant la commande -"shorewall restart". Si vous voulez enlever toutes les traces de Shorewall + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. Un +firewall fonctionnant peut être relancé en utilisant la commande +"shorewall restart". Si vous voulez enlever toutes les traces de Shorewall dans votre configuration de Netfilter, utilisez "shorewall clear".

    - +

    -    Les exemples (two-interface) supposent que vous voulez -permettre le routage depuis ou vers eth1 (le réseau local) -lorsque Shorewall est stoppé. Si votre réseau local n' est -pas connecté à eth1 ou si vous voulez permettre l'accès -depuis ou vers d'autres hôtes, changez /etc/shorewall/routestopped -en conséquence.

    - -

    ATTENTION: Si vous êtes connecté à -votre firewall depuis Internet, n'essayez pas la commande "shorewall stop" -tant que vous n'avez pas ajouté une entrée pour votre adresse +     Les exemples (two-interface) supposent que vous voulez +permettre le routage depuis ou vers eth1 (le réseau local) lorsque +Shorewall est stoppé. Si votre réseau local n' est pas connecté +à eth1 ou si vous voulez permettre l'accès depuis ou +vers d'autres hôtes, changez /etc/shorewall/routestopped en conséquence.

    + +

    ATTENTION: Si vous êtes connecté à +votre firewall depuis Internet, n'essayez pas la commande "shorewall stop" +tant que vous n'avez pas ajouté une entrée pour votre adresse IP depuis laquelle vous êtes connecté dans/etc/shorewall/routestopped. De -plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux -de créer une configuration -alternative et de l'essayer en utilisant la commande/etc/shorewall/routestopped. De +plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux +de créer une configuration + alternative et de l'essayer en utilisant la commande"shorewall try".

    - +

    Last updated 12/20/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas + +

    Copyright 2002 Thomas M. Eastep

    -
    -
    -
    -
    -
    -
    -
    +
    +
    +
    +
    +
    +
    +
    +

    diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm index 2da08107e..b721cc87a 100755 --- a/Shorewall-docs/upgrade_issues.htm +++ b/Shorewall-docs/upgrade_issues.htm @@ -1,437 +1,421 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    +

    Upgrade Issues

    -
    - +

    For upgrade instructions see the Install/Upgrade page.
    -

    - -

    It is important that you read all of the sections on this page where the - version number mentioned in the section title is later than what you are +

    + +

    It is important that you read all of the sections on this page where the + version number mentioned in the section title is later than what you are currently running.
    -

    -

    In the descriptions that follows, the term group refers -to a particular network or subnetwork (which may be 0.0.0.0/0 or it may -be a host address) accessed through a particular interface.
    -

    +

    + +

    In the descriptions that follows, the term group refers +to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be +a host address) accessed through a particular interface.
    +

    +

    Examples:
    -    
    -    eth0:0.0.0.0/0
    -     eth2:192.168.1.0/24
    -     eth3:192.0.2.123
    -

    - +    
    +     eth0:0.0.0.0/0
    +     eth2:192.168.1.0/24
    +     eth3:192.0.2.123
    +

    +

    You can use the "shorewall check" command to see the groups associated +with each of your zones.
    +

    +

    - +

    Version >= 1.4.2

    -There are some cases where you may want to handle traffic from a particular -group to itself. While I personally think that such a setups are ridiculous, + There are some cases where you may want to handle traffic from a particular +group to itself. While I personally think that such a setups are ridiculous, there are two cases covered in this documentation where it can occur:
    +
      -
    1. In FAQ #2.
      2. -
    2. When running Squid as a transparent +
    3. In FAQ #2.
      4. +
    4. When running Squid as a transparent proxy in your local zone.
      5. +
    -If you have either of these cases, you will want to review the current documentation + If you have either of these cases, you will want to review the current documentation and change your configuration accordingly.
    +

    Version >= 1.4.1

    -You can use the "shorewall check" command to see the groups associated with -each of your zones.
    -
    - +
      -
    • Beginning with Version 1.4.1, traffic between groups in the same - zone is accepted by default. Previously, traffic from a zone to itself -was treated just like any other traffic; any matching rules were applied -followed by enforcement of the appropriate policy. With 1.4.1 and later -versions, unless you have explicit rules for traffic from Z to Z or you -have an explicit Z to Z policy (where "Z" is some zone) then traffic between -the groups in zone Z will be accepted. If you do have one or more explicit -rules for Z to Z or if you have an explicit Z to Z policy then the behavior -is as it was in prior versions.
      • - +
    • Beginning with Version 1.4.1, traffic between groups in the same + zone is accepted by default. Previously, traffic from a zone to itself was + treated just like any other traffic; any matching rules were applied followed + by enforcement of the appropriate policy. With 1.4.1 and later versions, + unless you have explicit rules for traffic from Z to Z or you have an explicit + Z to Z policy (where "Z" is some zone) then traffic between the groups +in zone Z will be accepted. If you do have one or more explicit rules for +Z to Z or if you have an explicit Z to Z policy then the behavior is as it +was in prior versions.
      • +
    - -
    + +
      -
    1. If you have a Z Z ACCEPT policy for a zone to allow traffic between - two interfaces to the same zone, that policy can be removed and traffic -between the interfaces will traverse fewer rules than previously.
      2. -
    2. If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z +
    3. If you have a Z Z ACCEPT policy for a zone to allow traffic +between two interfaces to the same zone, that policy can be removed and +traffic between the interfaces will traverse fewer rules than previously.
      4. +
    4. If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z rules then your configuration should not require any change.
      5. -
    5. If you are currently relying on a implicit policy (one that has - "all" in either the SOURCE or DESTINATION column) to prevent traffic between - two interfaces to a zone Z and you have no rules for Z->Z then you should +
    6. If you are currently relying on a implicit policy (one that has + "all" in either the SOURCE or DESTINATION column) to prevent traffic between + two interfaces to a zone Z and you have no rules for Z->Z then you should add an explicit DROP or REJECT policy for Z to Z.
      -
      7. - + +
    -
    - +
    +
      -
    • Beginning with Version 1.4.1, Shorewall will never create rules -to deal with traffic from a given group back to itself. The multi -interface option is no longer available so if you want to route traffic between -two subnetworks on the same interface then either:
      • - +
    • Sometimes, you want two separate zones on one interface but you +don't want Shorewall to set up any infrastructure to handle traffic between +them.
    - -
    -
      -
    1. The subnetworks must be in different zones; or
      2. -
    2. You must use the /etc/shorewall/hosts file to define the subnetworks - as two groups in a single zone.
      3. - -
    +
    Example:
    +
    + 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    +
    + Here, zone z1 is nested in zone z2 and the firewall is not going to be + involved in any traffic between these two zones. Beginning with Shorewall + 1.4.1, you can prevent Shorewall from setting up any infrastructure to handle + traffic between z1 and z2 by using the new NONE policy:
    +
    + 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    - If you use the technique described in FAQ 2 to send local requests addressed -to your firewall's external address back to a local server then you need to -change your configuration to match the new version -of FAQ #2.
    -
    - Example 1 -- Two zones:
    - -
    - 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/policy

    z1	z2	ACCEPT
    z2	z1	ACCEPT

    /etc/shorewall/interfaces

    -	eth1	192.168.1.255,192.168.2.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.0/24
    z2	eth1:192.168.2.0/24
    -
    - Example 2 -- One zone: -
    - 

    /etc/shorewall/zones

    z	Zone	The Zone

    /etc/shorewall/interfaces

    -	eth1	192.168.1.255,192.168.2.255

    /etc/shorewall/hosts

    z	eth1:192.168.1.0/24
    z	eth1:192.168.2.0/24
    -
    - Note that in the second example, we don't need any policy since z->z - traffic is accepted by default. The second technique is preferable if you - want unlimited access between the two subnetworks.
    -
    - Sometimes, you want two separate zones on one interface but you don't -want Shorewall to set up any infrastructure to handle traffic between them. -
    -
    - Example:
    - -
    - 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    -
    - Here, zone z1 is nested in zone z2 and the firewall is not going to be -involved in any traffic between these two zones. Beginning with Shorewall -1.4.1, you can prevent Shorewall from setting up any infrastructure to handle -traffic between z1 and z2 by using the new NONE policy:
    - -
    - 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    -
    - Note that NONE policies are generally used in pairs unless there is asymetric - routing where only the traffic on one direction flows through the firewall - and you are using a NONE polciy in the other direction.  + Note that NONE policies are generally used in pairs unless there is asymetric + routing where only the traffic on one direction flows through the firewall + and you are using a NONE polciy in the other direction. 
    + +

    Version 1.4.1
    +

    +
      +
    • In Version 1.4.1, Shorewall will never create rules to deal +with traffic from a given group back to itself. The multi interface +option is no longer available so if you want to route traffic between two +subnetworks on the same interface then I recommend that you upgrade to Version +1.4.2 and use the 'routeback' interface or host option. 
      • + +
    +

    Version >= 1.4.0

    - IMPORTANT: Shorewall >=1.4.0 requires the iproute + IMPORTANT: Shorewall >=1.4.0 requires the iproute package ('ip' utility).
    -
    - Note: Unfortunately, some distributions call this package iproute2 - which will cause the upgrade of Shorewall to fail with the diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1
    -
    - This may be worked around by using the --nodeps option of rpm (rpm + Note: Unfortunately, some distributions call this package iproute2 + which will cause the upgrade of Shorewall to fail with the diagnostic:
    +
    +      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 +
    +
    + This may be worked around by using the --nodeps option of rpm (rpm -Uvh --nodeps <shorewall rpm>).
    -
    - If you are upgrading from a version < 1.4.0, then:
    - +
    + If you are upgrading from a version < 1.4.0, then:
    +
      -
    • The noping and forwardping interface options - are no longer supported nor is the FORWARDPING option in shorewall.conf. - ICMP echo-request (ping) packets are treated just like any other connection +
    • The noping and forwardping interface options + are no longer supported nor is the FORWARDPING option in shorewall.conf. + ICMP echo-request (ping) packets are treated just like any other connection request and are subject to rules and policies.
      • -
    • Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate a Shorewall error at startup +
    • Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate a Shorewall error at startup (they always have produced warnings in iptables).
      • -
    • The MERGE_HOSTS variable has been removed from shorewall.conf. - Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone -contents are determined by BOTH the interfaces and hosts files when there -are entries for the zone in both files.
      • -
    • The routestopped option in the interfaces and hosts +
    • The MERGE_HOSTS variable has been removed from shorewall.conf. + Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone + contents are determined by BOTH the interfaces and hosts files when there + are entries for the zone in both files.
      • +
    • The routestopped option in the interfaces and hosts file has been eliminated; use entries in the routestopped file instead.
      • -
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is +
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer accepted; you must convert to using the new syntax.
      • -
    • The ALLOWRELATED variable in shorewall.conf is -no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      • -
    • Late-arriving DNS replies are now dropped by default; - there is no need for your own /etc/shorewall/common file simply to avoid - logging these packets.
      • -
    • The 'firewall', 'functions' and 'version' file -have been moved to /usr/share/shorewall.
      • -
    • The icmp.def file has been removed. If you include +
    • The ALLOWRELATED variable in shorewall.conf is + no longer supported. Shorewall 1.4 behavior is the same as 1.3 with +ALLOWRELATED=Yes.
      • +
    • Late-arriving DNS replies are now dropped by +default; there is no need for your own /etc/shorewall/common file simply +to avoid logging these packets.
      • +
    • The 'firewall', 'functions' and 'version' file + have been moved to /usr/share/shorewall.
      • +
    • The icmp.def file has been removed. If you include it from /etc/shorewall/icmpdef, you will need to modify that file.
      • - +
        - +
      -
    • If you followed the advice in FAQ #2 and call find_interface_address +
    • If you followed the advice in FAQ #2 and call find_interface_address in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      -
      • - + +
    - +
      - +
    - +

    Version 1.4.0

    - +
      -
    • The 'multi' interface option is no longer supported. - Shorewall will generate rules for sending packets back out the same -interface that they arrived on in two cases:
      • - +
    • The 'multi' interface option is no longer supported. + Shorewall will generate rules for sending packets back out the same interface +that they arrived on in two cases:
      • +
    - -
    + +
      -
    • There is an explicit policy for the source zone to or -from the destination zone. An explicit policy names both zones and does +
    • There is an explicit policy for the source zone to or +from the destination zone. An explicit policy names both zones and does not use the 'all' reserved word.
      • - +
    - +
      -
    • There are one or more rules for traffic for the source zone to - or from the destination zone including rules that use the 'all' reserved - word. Exception: if the source zone and destination zone are the same -then the rule must be explicit - it must name the zone in both the SOURCE -and DESTINATION columns.
      • - +
    • There are one or more rules for traffic for the source zone +to or from the destination zone including rules that use the 'all' reserved + word. Exception: if the source zone and destination zone are the same then + the rule must be explicit - it must name the zone in both the SOURCE and + DESTINATION columns.
      • +
    -
    - +
    +

    Version >= 1.3.14

    - -      Beginning in version 1.3.14, Shorewall treats entries in -/etc/shorewall/masq differently. The -change involves entries with an interface name in the SUBNET -(second) column:
    - -
      -
    • Prior to 1.3.14, Shorewall would detect the FIRST subnet - on the interface (as shown by "ip addr show interface") and would - masquerade traffic from that subnet. Any other subnets that routed through - eth1 needed their own entry in /etc/shorewall/masq to be masqueraded -or to have SNAT applied.
      • -
    • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's - routing table to determine ALL subnets routed through the named interface. - Traffic originating in ANY of those subnets is masqueraded or has SNAT - applied.
      • - -
    - You will need to make a change to your configuration if:
    - -
      -
    1. You have one or more entries in /etc/shorewall/masq with - an interface name in the SUBNET (second) column; and
      2. -
    2. That interface connects to more than one subnetwork.
      3. - -
    - Two examples:
    -
    -  Example 1 -- Suppose that your current config is as -follows:
    -   
    - -
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    - -
    In this case, the second entry in /etc/shorewall/masq is no longer - required.
    -
    - Example 2-- What if your current configuration is like - this?
    - -
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    - -
    In this case, you would want to change the entry in /etc/shorewall/masq - to:
    -
    - -
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -     Version 1.3.14 also introduced simplified ICMP echo-request - (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf - is used to specify that the old (pre-1.3.14) ping handling is to be -used (If the option is not set in your /etc/shorewall/shorewall.conf -then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the -old handling indefinitely so I urge current users to migrate to using -the new handling as soon as possible. See the 'Ping' -handling documentation for details.
    - -

    Version 1.3.10

    - If you have installed the 1.3.10 Beta 1 RPM and are now upgrading - to version 1.3.10, you will need to use the '--force' option:
    +      Beginning in version 1.3.14, Shorewall treats entries in + /etc/shorewall/masq differently. The + change involves entries with an interface name in the SUBNET + (second) column:
    + +
      +
    • Prior to 1.3.14, Shorewall would detect the FIRST subnet + on the interface (as shown by "ip addr show interface") and would + masquerade traffic from that subnet. Any other subnets that routed through + eth1 needed their own entry in /etc/shorewall/masq to be masqueraded +or to have SNAT applied.
      • +
    • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's + routing table to determine ALL subnets routed through the named interface. + Traffic originating in ANY of those subnets is masqueraded or has SNAT + applied.
      • + +
    + You will need to make a change to your configuration if:
    + +
      +
    1. You have one or more entries in /etc/shorewall/masq with + an interface name in the SUBNET (second) column; and
      2. +
    2. That interface connects to more than one subnetwork.
      3. + +
    + Two examples:

    - -
    - 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +  Example 1 -- Suppose that your current config is as +follows:
    +   
    + +
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    + +
    In this case, the second entry in /etc/shorewall/masq is no longer + required.
    - + Example 2-- What if your current configuration is like + this?
    + +
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    + +
    In this case, you would want to change the entry in /etc/shorewall/masq + to:
    +
    + +
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + +     Version 1.3.14 also introduced simplified ICMP echo-request + (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf + is used to specify that the old (pre-1.3.14) ping handling is to be +used (If the option is not set in your /etc/shorewall/shorewall.conf then +OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the old +handling indefinitely so I urge current users to migrate to using the +new handling as soon as possible. See the 'Ping' handling +documentation for details.
    + +

    Version 1.3.10

    + If you have installed the 1.3.10 Beta 1 RPM and are now upgrading + to version 1.3.10, you will need to use the '--force' option:
    +
    + +
    + 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +
    +

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. - If you have an application that uses functions from that file, your + The 'functions' file has moved to /usr/lib/shorewall/functions. + If you have an application that uses functions from that file, your application will need to be changed to reflect this change of location.
    - +

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - + +

    If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

    +

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following - rules in their /etc/shorewall/icmpdef file (creating this -file if necessary):

    - + +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following + rules in their /etc/shorewall/icmpdef file (creating this file +if necessary):

    + 
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + +

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" command from that file since the icmp.def file is now empty.

    - +

    Upgrading Bering to Shorewall >= 1.3.3

    - +

    To properly upgrade with Shorewall version 1.3.3 and later:

    - +
      -
    1. Be sure you have a -backup -- you will need to transcribe -any Shorewall configuration changes -that you have made to the new configuration.
      2. -
    2. Replace the shorwall.lrp - package provided on the Bering floppy - with the later one. If you did not - obtain the later version from Jacques's site, see additional instructions - below.
      3. -
    3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not forget +
    4. Be sure you have +a backup -- you will need to transcribe + any Shorewall configuration changes + that you have made to the new configuration.
      5. +
    5. Replace the shorwall.lrp + package provided on the Bering floppy + with the later one. If you did not + obtain the later version from Jacques's site, see additional instructions + below.
      6. +
    6. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not forget to backup root.lrp !
      7. - +
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions - for setting up a two-interface firewall plus you also need + +

    The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions + for setting up a two-interface firewall plus you also need to add the following two Bering-specific rules to /etc/shorewall/rules:

    - -
    + +
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - +
    +

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions 1.3.6 - and 1.3.7

    - + +

    If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions +1.3.6 and 1.3.7

    +
      -
    1. -

      Create the file /etc/shorewall/newnotsyn and in it add +

    2. +

      Create the file /etc/shorewall/newnotsyn and in it add the following rule
      -
      - run_iptables -A newnotsyn - -j RETURN # So that the connection tracking table can be +
      + run_iptables -A newnotsyn + -j RETURN # So that the connection tracking table can be rebuilt
      -                                     # from +                                     # from non-SYN packets after takeover.
      -  

      -
      3. -
    3. -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A common --p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks -to rebuild connection
      -                                                                     +  

      +
      4. +
    4. +

      Create /etc/shorewall/common (if you don't already + have that file) and include the following:
      +
      + run_iptables -A common +-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks + to rebuild connection
      +                                                                     #tracking table.
      - . /etc/shorewall/common.def

      -
      5. - + . /etc/shorewall/common.def

      + +
    - +

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no longer -supported.

    - + +

    Some forms of pre-1.3.0 rules file syntax are no longer + supported.

    +

    Example 1:

    - -
    + +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - +
    +

    Must be replaced with:

    - -
    + +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    - -
    +
    + +

    Example 2:

    -
    - -
    +
    + +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    - -
    +
    + +

    Must be replaced with:

    -
    - -
    +
    + +
    	REDIRECT	loc	3128	tcp	80
    -
    - +
    +

    Version >= 1.3.2

    - -

    The functions and versions files together with the 'firewall' -symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

    - -

    Last updated 4/7/2003 - Tom Eastep -

    - -

    Copyright + +

    The functions and versions files together with the 'firewall' + symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

    + +

    Last updated 4/13/2003 - Tom +Eastep

    + +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    -

    +

    +