mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-15 19:01:19 +01:00
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:
parent
6f31bdc769
commit
b2d401a3ca
@ -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.
|
||||
|
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user