Lars E. D. Jensen wrote: >Concerning the issue with kernel 2.6.20 and above, do you know the >restrictions or is it written somewhere?
From the release notes : http://www.shorewall.net/pub/shorewall/4.0/shorewall-4.0.1/releasenotes.txt c) The old BRIDGING=Yes support has been replaced by new bridge support that uses the reduced 'physdev match' capabilities found in kernel 2.6.20 and later. This new implementation may be used where it is desired to control traffic through a bridge. The new implementation includes the following features: a) A new "Bridge Port" zone type is defined. Specify 'bport' or 'bport4' in the TYPE column of /etc/shorewall/zones. Bridge Port zones should be a sub-zone of a regular ipv4 zone that represents all hosts attached to the bridge. b) A new 'bridge' option is defined for entries in /etc/shorewall/interfaces. Bridges should have this option specified, even if you don't want to filter traffic going through the bridge. c) Bridge ports must now be defined in /etc/shorewall/interfaces. The INTERFACE column contains both the bridge name and the port name separated by a colon (e.g., "br0:eth1"). No OPTIONS are allowed for bridge ports. The bridge must be defined before its ports and must have the 'bridge' option. Bridge Port (BP) zones have a number of limitations: a) Each BP zone may only be associated with ports on a single bridge. b) BP zones may not be associated with interfaces that are not bridge ports. c) You may not have policies or rules where the DEST is a BP zone but the source is not a BP zone. If you need such rules, you must use the BP zone's parent zone as the DEST zone. Given that I think many (most ?) firewalls using bridging probably have policies of "fw net accept" and "fw loc accept" (ie allow all outbound traffic from the firewall) and only need to filter traffic that is inbound or passing through, then these restrictions probably aren't an issue for most people. That last restriction essentially says that (for a simple setup with two bridged ethernet ports and a fw zone) you have an implicit "fw all accept" policy and cannot have any rules that say otherwise. It will affect people who are paranoid and like to block outbound traffic by default as well as inbound. IIRC Tom posted something about it's origins, and I think it was something to do with handling IPSEC traffic correctly - the packet needs to be filtered/handled before the outbound port is known, and the end result is that traffic that originates on the machine (which includes traffic received via an IPSEC tunnel) goes through iptables before the outbound port is known and so no attempt is made to apply physdev rules to this traffic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
