Fix 'routeback' with bridge ports

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3744 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-03-28 18:14:40 +00:00
parent 6f31bdc769
commit b2d401a3ca
3 changed files with 60 additions and 61 deletions

View File

@ -1,3 +1,7 @@
Changes in 3.2.0 Beta 4
1) Fix 'routeback' with bridge ports.
Changes in 3.2.0 Beta 3
1) Correct handling of verbosity in the 'try' command.

View File

@ -1332,7 +1332,7 @@ __EOF__
# Validate the zone names and options in the hosts file
#
validate_hosts_file() {
local z hosts options r interface host option port ports
local z hosts options r interface host option port
check_bridge_port()
{
@ -1362,12 +1362,11 @@ validate_hosts_file() {
;;
esac
ports=\$${iface}
eval zports=\$${z}_ports
for host in $(separate_list $hosts); do
if [ -n "$BRIDGING" ]; then
case $host in
if [ -n "$BRIDGING" ]; then
case $host in
*:*)
known_interface ${host%:*} && \
fatal_error "Bridged interfaces may not be defined in /etc/shorewall/interfaces: $host"
@ -1386,7 +1385,7 @@ validate_hosts_file() {
esac
else
case $host in
+*)
*+)
eval ${z}_is_complex=Yes
;;
esac
@ -1397,15 +1396,14 @@ validate_hosts_file() {
norfc1918|blacklist|maclist|tcpflags|nosmurfs|-)
;;
ipsec)
[ -n "$POLICY_MATCH" ] || \
fatal_error "Your kernel and/or iptables does not support policy match: ipsec"
eval ${z}_ipsec_hosts=\"\$${z}_ipsec_hosts $interface:$host\"
eval ${z}_is_complex=Yes
;;
[ -n "$POLICY_MATCH" ] || \
fatal_error "Your kernel and/or iptables does not support policy match: ipsec"
eval ${z}_ipsec_hosts=\"\$${z}_ipsec_hosts $interface:$host\"
eval ${z}_is_complex=Yes
;;
routeback)
[ -z "$ports" ] && \
eval ${z}_routeback=\"$interface:$host \$${z}_routeback\"
;;
eval ${z}_routeback=\"$interface:$host \$${z}_routeback\"
;;
*)
error_message "WARNING: Invalid option ($option) in record \"$r\""
;;
@ -1413,7 +1411,7 @@ validate_hosts_file() {
done
done
[ -n "$ports" ] && eval ${z}_ports=\"$zports\"
[ -n "$zports" ] && eval ${z}_ports=\"$zports\"
done < $TMP_DIR/hosts

View File

@ -1,4 +1,4 @@
Shorewall 3.2.0 Beta 3.
Shorewall 3.2.0 Beta 4.
Note to users upgrading from Shorewall 2.x or 3.0
@ -27,58 +27,18 @@ 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 3
Problems Corrected in 3.2.0 Beta 4
1) The 'try' command with an effective verbosity of zero resulted in an
error message and the command failed.
2) /etc/shorwall/Makefile was incorrectly described as %config(noreplace)
in the RPM .spec file. This prevented updated versions of the file
from being installed properly.
3) If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq
and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall
start" will fail with the error 'Error: an inet prefix is expected rather
than "SAME".'.
Other changes in 3.2.0 Beta 2
2) A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
this option is set to "Yes", it causes subzones to be treated differently
with respect to policies.
Subzones are defined by following their name with ":" and a list of parent
zones (in /etc/shorewall/zones). Normally, you want to have a set of
special rules for the subzone and if a connection doesn't match any of
those subzone-specific rules then you want the parent zone rules to be
applied. With IMPLICIT_CONTINUE=Yes, that happens automatically.
If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
subzones are not subject to this special treatment.
With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
by including an explicit policy (one that does not specify "all" in either
the SOURCE or the DEST columns).
1) Previously, the 'routeback' option was ignored in the /etc/shorewall/hosts file
which referred to a (set of) bridge port(s).
Example:
/etc/shorewall/zones:
dmz xenbr0:vif+ routeback
par ipv4
chld:par ipv4
Other changes in 3.2.0 Beta 4
Traffic to/from the 'chld' zone will first pass through the applicable
'chld' rules and if none of those rules match then it will be passed through
the appropriate 'par' rules. If the connection request does not match
any of the 'par' rules then the relevant 'par' policy is applied.
If you want the fw->chld policy to be ACCEPT, simply add this entry to
/etc/shorewall/policy:
$FW chld ACCEPT
Traffic from all other zones to 'chld' will be subject to the implicit
CONTINUE policy.
None.
Migration Considerations:
@ -437,3 +397,40 @@ New Features:
last "shorewall [re]start"; otherwise, they are logged at the 'info'
log level.
9) A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
this option is set to "Yes", it causes subzones to be treated differently
with respect to policies.
Subzones are defined by following their name with ":" and a list of parent
zones (in /etc/shorewall/zones). Normally, you want to have a set of
special rules for the subzone and if a connection doesn't match any of
those subzone-specific rules then you want the parent zone rules to be
applied. With IMPLICIT_CONTINUE=Yes, that happens automatically.
If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
subzones are not subject to this special treatment.
With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
by including an explicit policy (one that does not specify "all" in either
the SOURCE or the DEST columns).
Example:
/etc/shorewall/zones:
par ipv4
chld:par ipv4
Traffic to/from the 'chld' zone will first pass through the applicable
'chld' rules and if none of those rules match then it will be passed through
the appropriate 'par' rules. If the connection request does not match
any of the 'par' rules then the relevant 'par' policy is applied.
If you want the fw->chld policy to be ACCEPT, simply add this entry to
/etc/shorewall/policy:
$FW chld ACCEPT
Traffic from all other zones to 'chld' will be subject to the implicit
CONTINUE policy.