I regret to announce that Shorewall bridge/firewall support in its current form (BRIDGING=Yes in shorewall.conf) is going away. I will retain the code in Shorewall for the foreseeable future but users migrating to new kernels coming out next year will find that their current bridge configurations no longer work. Shorewall bridge/firewall users upgrading to more immediate new kernel releases (possibly as early as 2.6.18) will find Netfilter warning messages appearing in their kernel log when Shorewall [re]starts. The reason that this support is going away is that the underlying Netfilter feature that BRIDGING=Yes depends on (physdev match) is being reduced in scope to the point that it will no longer be possible to use that feature for Shorewall zone definition. There is a significant list of pending Netfilter bug reports than cannot be resolved so long as ''physdev match'' works the way that it does today. While ''physdev match'' was a great idea in terms of the function that it provides, it appears impossible to implement that function without breaking other parts of the greater Linux IP stack; in short, ''physdev match'' in its current form should never have been released in the first place. So -- what can current Shorewall bridge/firewall users do? ----------------------------------------------------------------------- a) Configure Shorewall as if you have a simple bridge (http://www.shorewall.net/SimpleBridge.html) and use ebtables to filter traffic in and out of the individual bridge ports. b) Configure Shorewall so that you specifically enumerate the IP addresses of the hosts connected to all but one of the bridge ports. Example where br0 connects to 192.168.1.0/24: /etc/shorewall/shorewall.conf BRIDGING=<doesn''t matter> /etc/shorewall/zones z1 ipv4 z2 ipv4 /etc/shorewall/interfaces - br0 detect routeback /etc/shorewall/hosts: z1 br0:192.168.1.1-192.168.1.15,192.168.1.18,... z2 br0:192.168.1.0/24 In other words, explicitly specify the hosts in the first zone listed in /etc/shorewall/zones (z1 in the above example) then simply specify the entire network for the second zone. If the second zone contains your default gateway, then you would enter 0.0.0.0/0 rather than 192.168.1.0/24. I will expand these instructions into an article on the web site just as soon as I find the time. c) If you have ipset support, you can take the same approach as in b) above but define ''z1'' using one or more ipsets rather than with an explicit lists of network/host IP addresses. That will generally result in a smaller ruleset. ----------------------------------------------------------------------- I realize that the options available to you are more cumbersome to configure and maintain than what you have today but at the moment, I see no alternatives. I will however continue to ponder the problem, and if I come up with something better I will let you know. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Vieri Di Paola
2006-Jul-19 18:06 UTC
Re: IMPORTANT: Changes upcoming for bridge/firewall support
--- Tom Eastep <teastep@shorewall.net> wrote:> I regret to announce that Shorewall bridge/firewall > support in its > current form (BRIDGING=Yes in shorewall.conf) is > going away.Thank you for the warning and the possible alternatives. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Rune Kock
2006-Jul-19 20:31 UTC
Re: [Shorewall-announce] IMPORTANT: Changes upcoming for bridge/firewall support
On 7/19/06, Tom Eastep <teastep@shorewall.net> wrote:> I regret to announce that Shorewall bridge/firewall support in its > current form (BRIDGING=Yes in shorewall.conf) is going away....> The reason that this support is going away is that the underlying > Netfilter feature that BRIDGING=Yes depends on (physdev match) is being > reduced in scope to the point that it will no longer be possible to use > that feature for Shorewall zone definition.I have tried to follow your conversation with Patrick McHardy on Netfilter-devel.>From what I gather, the problem is that Shorewall uses a featurecalled physdev-out to tell on which interface of a bridge, the packet will be leaving. And that feature is going to be removed. If I understand correctly, the opposite feature, checking from which interface a packet came in, is still going to be available. Now, I wonder if it will be possible to keep some of the Shorewall bridge filtering capabilities: still be able to filter depending on input-interface etc, even when filtering based on output-interface is gone? Rune ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep
2006-Jul-19 20:38 UTC
Re: [Shorewall-announce] IMPORTANT: Changes upcoming for bridge/firewall support
On Wed, 2006-07-19 at 22:31 +0200, Rune Kock wrote:> > I have tried to follow your conversation with Patrick McHardy on > Netfilter-devel. > > From what I gather, the problem is that Shorewall uses a feature > called physdev-out to tell on which interface of a bridge, the packet > will be leaving. And that feature is going to be removed.It is going to be disallowed in the FORWARD and OUTPUT chains.> > If I understand correctly, the opposite feature, checking from which > interface a packet came in, is still going to be available.Correct.> > Now, I wonder if it will be possible to keep some of the Shorewall > bridge filtering capabilities: still be able to filter depending on > input-interface etc, even when filtering based on output-interface is > gone?Yes. If you have: /etc/shorewall/shorewall.conf BRIDGING=Yes /etc/shorewall/interfaces loc br0 detect And br0 bridges eth0 and eth1, then in /etc/shorewall/rules, you can still write: ACCEPT loc:eth1 net tcp 22 And Shorewall will generate the correct "--physdev-in eth1" match. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV