mirror of
https://gitlab.com/shorewall/code.git
synced 2025-01-10 23:58:14 +01:00
Fix compilation failure on LEAF Bearing -- second pass; correct awkward wording in shorewall.conf comments
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3781 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
8aad8dbfee
commit
503aeea7df
@ -1,3 +1,7 @@
|
||||
Changes in 3.2.0 Beta 5
|
||||
|
||||
1) Fix compilation problem on LEAF Bering.
|
||||
|
||||
Changes in 3.2.0 Beta 4
|
||||
|
||||
1) Fix 'routeback' with bridge ports.
|
||||
|
||||
@ -8558,6 +8558,10 @@ compile_firewall() # $1 = File Name
|
||||
# END OVERLOADED FUNCTIONS
|
||||
#
|
||||
|
||||
#
|
||||
# So that mktempdir doesn't have to jump through hoops when there isn't a working 'mktemp',
|
||||
# we create the compiler's temporary directory in TMP_DIR
|
||||
#
|
||||
STATEDIR=$TMP_DIR/compiler_state/
|
||||
|
||||
mkdir $STATEDIR || fatal_error "Cannot create temporary directory in $TMP_DIR"
|
||||
@ -8972,7 +8976,6 @@ __EOF__
|
||||
fi
|
||||
|
||||
rm -rf $TMP_DIR
|
||||
rm -rf $STATEDIR
|
||||
|
||||
}
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Shorewall 3.2.0 Beta 4.
|
||||
Shorewall 3.2.0 Beta 5
|
||||
|
||||
Note to users upgrading from Shorewall 2.x or 3.0
|
||||
|
||||
@ -27,97 +27,20 @@ Note to users upgrading from Shorewall 2.x or 3.0
|
||||
Please see the "Migration Considerations" below for additional upgrade
|
||||
information.
|
||||
|
||||
Problems Corrected in 3.2.0 Beta 4
|
||||
Problems Corrected in 3.2.0 Beta 5
|
||||
|
||||
1) Previously, the 'routeback' option was ignored in an entry in the
|
||||
/etc/shorewall/hosts file that referred to a (set of) bridge port(s).
|
||||
1) On systems such as LEAF Bering that either don't have the 'mktemp' utility
|
||||
or whose 'mktemp' cannot create a temporary directory, firewall compilation
|
||||
failed with the message:
|
||||
|
||||
Example:
|
||||
ERROR: No Interfaces Defined
|
||||
|
||||
dmz xenbr0:vif+ routeback
|
||||
after a shell error message indicating that the stripped interfaces
|
||||
file in /tmp/shorewall-NNNN/ couldn't be opened.
|
||||
|
||||
2) Previously, if 'mktemp' was not installed on the firewall system and if
|
||||
a directory or file with the name /tmp/shorewall-<pid> existed (where <pid>
|
||||
is the pid of the shell attempting to compile the Shorewall configuration),
|
||||
then the current command would fail with error messages such as:
|
||||
Other changes in 3.2.0 Beta 5
|
||||
|
||||
/usr/share/shorewall/compiler: 1: cannot create /tmp/shorewall-20000
|
||||
ERROR: Cannot create temporary file in /tmp
|
||||
|
||||
Other changes in 3.2.0 Beta 4
|
||||
|
||||
1) Shorewall now includes support for explicit routing rules when the
|
||||
/etc/shorewall/providers file is used. A new file, /etc/shorewall/rtrules
|
||||
can be used to add routing rules based on packet source and/or
|
||||
destination.
|
||||
|
||||
The file has the following columns:
|
||||
|
||||
SOURCE(optonal) An ip address (network or host) that
|
||||
matches the source IP address in a packet.
|
||||
May also be specified as an interface
|
||||
name optionally followed by ":" and an
|
||||
address. If the define 'lo' is specified,
|
||||
the packet must originate from the firewall
|
||||
itself.
|
||||
|
||||
DEST(optional) An ip address (network or host) that
|
||||
matches the destination IP address in a packet.
|
||||
|
||||
If you choose to omit either SOURCE or DEST,
|
||||
place "-" in the column. Note that you
|
||||
may not omit both SOURCE and DEST.
|
||||
|
||||
PROVIDER The provider to route the traffic through.
|
||||
May be expressed either as the provider name
|
||||
or the provider number.
|
||||
|
||||
PRIORITY
|
||||
The rule's priority which determines the order
|
||||
in which the rules are processed.
|
||||
|
||||
1000-1999 Before Shorewall-generated
|
||||
'MARK' rules
|
||||
|
||||
11000- 11999 After 'MARK' rules but before
|
||||
Shorewall-generated rules for
|
||||
provider interfaces.
|
||||
|
||||
26000-26999 After provider interface rules but
|
||||
before 'default' rule.
|
||||
|
||||
Rules with equal priority are applied in
|
||||
the order in which they appear in the file.
|
||||
|
||||
Example: You want all traffic coming in on eth1 to be routed to the ISP1
|
||||
provider:
|
||||
|
||||
#PROVIDER PRIORITY SOURCE DEST
|
||||
ISP1 1000 eth1
|
||||
|
||||
2) Prior to now, it has not been possible to use connection marking in
|
||||
/etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
|
||||
'track' option.
|
||||
|
||||
Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
|
||||
shorewall.conf to effectively divide the packet mark and connection mark
|
||||
into two 8-byte mark fields.
|
||||
|
||||
When you do this:
|
||||
|
||||
a) The MARK field in the providers file must have a value that is
|
||||
less than 65536 and that is a multiple of 256 (using hex
|
||||
representation, the values are 0x0100-0xFF00 with the low-order
|
||||
8 bits being zero).
|
||||
|
||||
b) You may only set those mark values in the PREROUTING chain.
|
||||
|
||||
c) Marks used for traffic shaping must still be in the range of 1-255
|
||||
and may still not be set in the PREROUTING chain.
|
||||
|
||||
d) When you SAVE or RESTORE in tcrules, only the TC mark value is
|
||||
saved or restored. Shorewall handles saving and restoring the
|
||||
routing (provider) marks.
|
||||
None.
|
||||
|
||||
Migration Considerations:
|
||||
|
||||
@ -513,3 +436,75 @@ New Features:
|
||||
Traffic from all other zones to 'chld' will be subject to the implicit
|
||||
CONTINUE policy.
|
||||
|
||||
10) Shorewall now includes support for explicit routing rules when the
|
||||
/etc/shorewall/providers file is used. A new file, /etc/shorewall/rtrules
|
||||
can be used to add routing rules based on packet source and/or
|
||||
destination.
|
||||
|
||||
The file has the following columns:
|
||||
|
||||
SOURCE(optonal) An ip address (network or host) that
|
||||
matches the source IP address in a packet.
|
||||
May also be specified as an interface
|
||||
name optionally followed by ":" and an
|
||||
address. If the define 'lo' is specified,
|
||||
the packet must originate from the firewall
|
||||
itself.
|
||||
|
||||
DEST(optional) An ip address (network or host) that
|
||||
matches the destination IP address in a packet.
|
||||
|
||||
If you choose to omit either SOURCE or DEST,
|
||||
place "-" in the column. Note that you
|
||||
may not omit both SOURCE and DEST.
|
||||
|
||||
PROVIDER The provider to route the traffic through.
|
||||
May be expressed either as the provider name
|
||||
or the provider number.
|
||||
|
||||
PRIORITY
|
||||
The rule's priority which determines the order
|
||||
in which the rules are processed.
|
||||
|
||||
1000-1999 Before Shorewall-generated
|
||||
'MARK' rules
|
||||
|
||||
11000- 11999 After 'MARK' rules but before
|
||||
Shorewall-generated rules for
|
||||
provider interfaces.
|
||||
|
||||
26000-26999 After provider interface rules but
|
||||
before 'default' rule.
|
||||
|
||||
Rules with equal priority are applied in
|
||||
the order in which they appear in the file.
|
||||
|
||||
Example: You want all traffic coming in on eth1 to be routed to the ISP1
|
||||
provider:
|
||||
|
||||
#PROVIDER PRIORITY SOURCE DEST
|
||||
ISP1 1000 eth1
|
||||
|
||||
11) Prior to now, it has not been possible to use connection marking in
|
||||
/etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
|
||||
'track' option.
|
||||
|
||||
Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
|
||||
shorewall.conf to effectively divide the packet mark and connection mark
|
||||
into two 8-byte mark fields.
|
||||
|
||||
When you do this:
|
||||
|
||||
a) The MARK field in the providers file must have a value that is
|
||||
less than 65536 and that is a multiple of 256 (using hex
|
||||
representation, the values are 0x0100-0xFF00 with the low-order
|
||||
8 bits being zero).
|
||||
|
||||
b) You may only set those mark values in the PREROUTING chain.
|
||||
|
||||
c) Marks used for traffic shaping must still be in the range of 1-255
|
||||
and may still not be set in the PREROUTING chain.
|
||||
|
||||
d) When you SAVE or RESTORE in tcrules, only the TC mark value is
|
||||
saved or restored. Shorewall handles saving and restoring the
|
||||
routing (provider) marks.
|
||||
|
||||
@ -831,10 +831,10 @@ MAPOLDACTIONS=No
|
||||
#
|
||||
# Fast ESTABLISHED/RELATED handling
|
||||
#
|
||||
# Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets
|
||||
# reach the chain in which the original connection was accepted. So for packets
|
||||
# going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are
|
||||
# ACCEPTED in the 'loc2net' chain.
|
||||
# Normally, Shorewall delays accepting ESTABLISHED/RELATED packets until these
|
||||
# packets reach the chain in which the original connection was accepted. So
|
||||
# for packets going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED
|
||||
# packets are ACCEPTED in the 'loc2net' chain.
|
||||
#
|
||||
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are accepted
|
||||
# early in the INPUT, FORWARD and OUTPUT chains. If you set
|
||||
@ -856,18 +856,20 @@ FASTACCEPT=No
|
||||
# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
|
||||
#
|
||||
# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
|
||||
# CONTINUE policy for connections by adding an explicit policy (one that
|
||||
# does not contain "all" in either the SOURCE or DEST columns).
|
||||
# CONTINUE policy by adding an explicit policy (one that does not contain
|
||||
# "all" in either the SOURCE or DEST columns).
|
||||
|
||||
IMPLICIT_CONTINUE=Yes
|
||||
|
||||
#
|
||||
# Use high mark values for policy routing
|
||||
#
|
||||
# Normally, Shorewall restricts the set of mark values to 1-255. If this
|
||||
# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of mark values
|
||||
# to 0x0100 to 0XFF00 to allow connection marks to be shared between traffic
|
||||
# shaping and policy routing (traffic shaping is always restricted to 1-255).
|
||||
# Normally, Shorewall restricts the set of mark values to 1-255. If you set
|
||||
# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
|
||||
# mark values (those specified in the /etc/shorewall/providers file) to
|
||||
# 0x0100 to 0XFF00 (with the low-order byte being zero). This allows
|
||||
# connection marks to be shared between traffic shaping and policy routing
|
||||
# (traffic shaping marks are always restricted to 1-255).
|
||||
#
|
||||
# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
|
||||
# both the extended CONNMARK target and the extended connmark match
|
||||
|
||||
Loading…
Reference in New Issue
Block a user