What I have as part of my configuration on one of the servers is a local
zone defined for the loopback interface, which has 5 ip addresses
(127.0.0.1-127.0.0.5). I see that shorewall has generated local2*
sub-chains in my local_frwd chain, as well as *2local for all other
zones, but these will *never* match any traffic.
Is there a way this could be optimised away, perhaps with using a new
option for the interface (''local'' maybe), indicating that this
zone is
local and instruct shorewall not to attempt to generate all these
non-sensical sub-chains?
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O''Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:>What I have as part of my configuration on one of the servers is a local >zone defined for the loopback interface, which has 5 ip addresses >(127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >sub-chains in my local_frwd chain, as well as *2local for all other >zones, but these will *never* match any traffic. > >Is there a way this could be optimised away, perhaps with using a new >option for the interface (''local'' maybe), indicating that this zone is >local and instruct shorewall not to attempt to generate all these >non-sensical sub-chains?You can make them ''server'' zones. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >>What I have as part of my configuration on one of the servers is a local >>zone defined for the loopback interface, which has 5 ip addresses >>(127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>sub-chains in my local_frwd chain, as well as *2local for all other >>zones, but these will *never* match any traffic. >> >>Is there a way this could be optimised away, perhaps with using a new >>option for the interface (''local'' maybe), indicating that this zone is >>local and instruct shorewall not to attempt to generate all these >>non-sensical sub-chains? > >You can make them ''server'' zones.''vserver'' -- those are sub-zones of $FW -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: > >>On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >>>What I have as part of my configuration on one of the servers is a local >>>zone defined for the loopback interface, which has 5 ip addresses >>>(127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>sub-chains in my local_frwd chain, as well as *2local for all other >>>zones, but these will *never* match any traffic. >>> >>>Is there a way this could be optimised away, perhaps with using a new >>>option for the interface (''local'' maybe), indicating that this zone is >>>local and instruct shorewall not to attempt to generate all these >>>non-sensical sub-chains? >> >>You can make them ''server'' zones. > >''vserver'' -- those are sub-zones of $FWOr, you can use NONE policies to suppress the chains that make no sense. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:> On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote: > > >> On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >> >> >>> On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>> >>>> What I have as part of my configuration on one of the servers is a local >>>> zone defined for the loopback interface, which has 5 ip addresses >>>> (127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>> sub-chains in my local_frwd chain, as well as *2local for all other >>>> zones, but these will *never* match any traffic. >>>> >>>> Is there a way this could be optimised away, perhaps with using a new >>>> option for the interface (''local'' maybe), indicating that this zone is >>>> local and instruct shorewall not to attempt to generate all these >>>> non-sensical sub-chains? >>>> >>> You can make them ''server'' zones. >>> >> ''vserver'' -- those are sub-zones of $FW >> > > Or, you can use NONE policies to suppress the chains that make no sense. >How do I make a ''server'' zone then? As for ''vserver'', the man page tells me that "The zone contents must be defined in ''hosts''". Using NONE in "policy" isn''t any good either, because "NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or ''all''". So, according to this, my intention to use something like "local all NONE" and "all local NONE" isn''t possible. Defining a NONE policy for every conceivable combination of local2* and *2local simply isn''t practical. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/11/2013 06:38 PM, Dash Four wrote:> > Tom Eastep wrote: >> On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >> >> >>> On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>> >>> >>>> On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>> >>>> >>>>> What I have as part of my configuration on one of the servers is a local >>>>> zone defined for the loopback interface, which has 5 ip addresses >>>>> (127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>>> sub-chains in my local_frwd chain, as well as *2local for all other >>>>> zones, but these will *never* match any traffic. >>>>> >>>>> Is there a way this could be optimised away, perhaps with using a new >>>>> option for the interface (''local'' maybe), indicating that this zone is >>>>> local and instruct shorewall not to attempt to generate all these >>>>> non-sensical sub-chains? >>>>> >>>> You can make them ''server'' zones. >>>> >>> ''vserver'' -- those are sub-zones of $FW >>> >> >> Or, you can use NONE policies to suppress the chains that make no sense. >> > How do I make a ''server'' zone then? > > As for ''vserver'', the man page tells me that "The zone contents must be > defined in ''hosts''". > > Using NONE in "policy" isn''t any good either, because "NONE may not be > used if the SOURCE or DEST columns contain the firewall zone ($FW) or > ''all''". So, according to this, my intention to use something like "local > all NONE" and "all local NONE" isn''t possible. Defining a NONE policy > for every conceivable combination of local2* and *2local simply isn''t > practical.Another option then is to define ''local'' using the hosts file and specify the ''destonly'' option. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 07:14 AM, Tom Eastep wrote:> On 05/11/2013 06:38 PM, Dash Four wrote: >> >> Tom Eastep wrote: >>> On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>> >>> >>>> On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>>> >>>> >>>>> On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>>> >>>>> >>>>>> What I have as part of my configuration on one of the servers is a local >>>>>> zone defined for the loopback interface, which has 5 ip addresses >>>>>> (127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>>>> sub-chains in my local_frwd chain, as well as *2local for all other >>>>>> zones, but these will *never* match any traffic. >>>>>> >>>>>> Is there a way this could be optimised away, perhaps with using a new >>>>>> option for the interface (''local'' maybe), indicating that this zone is >>>>>> local and instruct shorewall not to attempt to generate all these >>>>>> non-sensical sub-chains? >>>>>> >>>>> You can make them ''server'' zones. >>>>> >>>> ''vserver'' -- those are sub-zones of $FW >>>> >>> >>> Or, you can use NONE policies to suppress the chains that make no sense. >>> >> How do I make a ''server'' zone then? >> >> As for ''vserver'', the man page tells me that "The zone contents must be >> defined in ''hosts''". >> >> Using NONE in "policy" isn''t any good either, because "NONE may not be >> used if the SOURCE or DEST columns contain the firewall zone ($FW) or >> ''all''". So, according to this, my intention to use something like "local >> all NONE" and "all local NONE" isn''t possible. Defining a NONE policy >> for every conceivable combination of local2* and *2local simply isn''t >> practical. > > > Another option then is to define ''local'' using the hosts file and > specify the ''destonly'' option.Please disregard -- just tried that and it doesn''t work. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 07:33 AM, Tom Eastep wrote:> On 05/12/2013 07:14 AM, Tom Eastep wrote: >> On 05/11/2013 06:38 PM, Dash Four wrote: >>> >>> Tom Eastep wrote: >>>> On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>>> >>>> >>>>> On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>>>> >>>>> >>>>>> On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>>>> >>>>>> >>>>>>> What I have as part of my configuration on one of the servers is a local >>>>>>> zone defined for the loopback interface, which has 5 ip addresses >>>>>>> (127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>>>>> sub-chains in my local_frwd chain, as well as *2local for all other >>>>>>> zones, but these will *never* match any traffic. >>>>>>> >>>>>>> Is there a way this could be optimised away, perhaps with using a new >>>>>>> option for the interface (''local'' maybe), indicating that this zone is >>>>>>> local and instruct shorewall not to attempt to generate all these >>>>>>> non-sensical sub-chains? >>>>>>> >>>>>> You can make them ''server'' zones. >>>>>> >>>>> ''vserver'' -- those are sub-zones of $FW >>>>> >>>> >>>> Or, you can use NONE policies to suppress the chains that make no sense. >>>> >>> How do I make a ''server'' zone then? >>> >>> As for ''vserver'', the man page tells me that "The zone contents must be >>> defined in ''hosts''". >>> >>> Using NONE in "policy" isn''t any good either, because "NONE may not be >>> used if the SOURCE or DEST columns contain the firewall zone ($FW) or >>> ''all''". So, according to this, my intention to use something like "local >>> all NONE" and "all local NONE" isn''t possible. Defining a NONE policy >>> for every conceivable combination of local2* and *2local simply isn''t >>> practical. >> >> >> Another option then is to define ''local'' using the hosts file and >> specify the ''destonly'' option. > > Please disregard -- just tried that and it doesn''t work. >It does work in the sense that there aren''t rules that never match. It fails in that there are a lot of unreferenced extra chains created. I''ll see what I can do about that (and I''ll add the destonly option to the interfaces file while I''m at it). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:> On 05/12/2013 07:33 AM, Tom Eastep wrote: > >> On 05/12/2013 07:14 AM, Tom Eastep wrote: >> >>> On 05/11/2013 06:38 PM, Dash Four wrote: >>> >>>> Tom Eastep wrote: >>>> >>>>> On 5/11/13 6:11 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>>>> >>>>> >>>>> >>>>>> On 5/11/13 5:51 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 5/11/13 4:25 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> What I have as part of my configuration on one of the servers is a local >>>>>>>> zone defined for the loopback interface, which has 5 ip addresses >>>>>>>> (127.0.0.1-127.0.0.5). I see that shorewall has generated local2* >>>>>>>> sub-chains in my local_frwd chain, as well as *2local for all other >>>>>>>> zones, but these will *never* match any traffic. >>>>>>>> >>>>>>>> Is there a way this could be optimised away, perhaps with using a new >>>>>>>> option for the interface (''local'' maybe), indicating that this zone is >>>>>>>> local and instruct shorewall not to attempt to generate all these >>>>>>>> non-sensical sub-chains? >>>>>>>> >>>>>>>> >>>>>>> You can make them ''server'' zones. >>>>>>> >>>>>>> >>>>>> ''vserver'' -- those are sub-zones of $FW >>>>>> >>>>>> >>>>> Or, you can use NONE policies to suppress the chains that make no sense. >>>>> >>>>> >>>> How do I make a ''server'' zone then? >>>> >>>> As for ''vserver'', the man page tells me that "The zone contents must be >>>> defined in ''hosts''". >>>> >>>> Using NONE in "policy" isn''t any good either, because "NONE may not be >>>> used if the SOURCE or DEST columns contain the firewall zone ($FW) or >>>> ''all''". So, according to this, my intention to use something like "local >>>> all NONE" and "all local NONE" isn''t possible. Defining a NONE policy >>>> for every conceivable combination of local2* and *2local simply isn''t >>>> practical. >>>> >>> Another option then is to define ''local'' using the hosts file and >>> specify the ''destonly'' option. >>> >> Please disregard -- just tried that and it doesn''t work. >> >> > > It does work in the sense that there aren''t rules that never match. It > fails in that there are a lot of unreferenced extra chains created. I''ll > see what I can do about that (and I''ll add the destonly option to the > interfaces file while I''m at it). >As I suggested earlier, the easiest way to implement this is to add an option to the interface (or zone?) definition which asks shorewall not to involve this interface (or zone) in any inter-chain rules (i.e. keep it local-only). That way all I have to do is add this option and forget messing about with "hosts" and stuff like that. The ''local'' interface/zone can''t possibly have any matching rules from/to other interfaces/zones, so to me it makes a perfect sense to use that option. Is this doable? ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 07:58 AM, Dash Four wrote:>> > As I suggested earlier, the easiest way to implement this is to add an > option to the interface (or zone?) definition which asks shorewall not > to involve this interface (or zone) in any inter-chain rules (i.e. keep > it local-only). That way all I have to do is add this option and forget > messing about with "hosts" and stuff like that. > > The ''local'' interface/zone can''t possibly have any matching rules > from/to other interfaces/zones, so to me it makes a perfect sense to use > that option. Is this doable?Patch attached. It has uncovered an optimizer bug that is leaving a few unreferenced chains behind; I''ll chase that today. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:> On 05/12/2013 07:58 AM, Dash Four wrote: > >> As I suggested earlier, the easiest way to implement this is to add an >> option to the interface (or zone?) definition which asks shorewall not >> to involve this interface (or zone) in any inter-chain rules (i.e. keep >> it local-only). That way all I have to do is add this option and forget >> messing about with "hosts" and stuff like that. >> >> The ''local'' interface/zone can''t possibly have any matching rules >> from/to other interfaces/zones, so to me it makes a perfect sense to use >> that option. Is this doable? >> > > Patch attached. It has uncovered an optimizer bug that is leaving a few > unreferenced chains behind; I''ll chase that today. >Thanks, I''ll test this later when I have the chance and will let you know. Is this option for the zone or the interface? ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 5/12/13 9:04 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> On 05/12/2013 07:58 AM, Dash Four wrote: >> >>> As I suggested earlier, the easiest way to implement this is to add an >>> option to the interface (or zone?) definition which asks shorewall not >>> to involve this interface (or zone) in any inter-chain rules (i.e. >>>keep >>> it local-only). That way all I have to do is add this option and >>>forget >>> messing about with "hosts" and stuff like that. >>> >>> The ''local'' interface/zone can''t possibly have any matching rules >>> from/to other interfaces/zones, so to me it makes a perfect sense to >>>use >>> that option. Is this doable? >>> >> >> Patch attached. It has uncovered an optimizer bug that is leaving a few >> unreferenced chains behind; I''ll chase that today. >> >Thanks, I''ll test this later when I have the chance and will let you >know. Is this option for the zone or the interface?Interface. It is specifically targeted at the loopback device. Note that Shorewall automatically generates an ACCEPT rule in the INPUT flow for that device, so all filtering occurs in the OUTPUT chain. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 08:52 AM, Tom Eastep wrote:> Patch attached. It has uncovered an optimizer bug that is leaving a few > unreferenced chains behind; I''ll chase that today.This patch seems to correct the optimizer. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:> Interface. It is specifically targeted at the loopback device. Note that > Shorewall automatically generates an ACCEPT rule in the INPUT flow for > that device, so all filtering occurs in the OUTPUT chain. >This was my next question. Currently I have this sequence of rules regarding ''lo'' (INPUT chain): -A INPUT -i lo -j local2fw [...] -A INPUT -i lo -j ACCEPT The latter will never execute. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:> On 05/12/2013 08:52 AM, Tom Eastep wrote: > >> Patch attached. It has uncovered an optimizer bug that is leaving a few >> unreferenced chains behind; I''ll chase that today. >> > > This patch seems to correct the optimizer. >Is that for the extra ACCEPT rule for ''lo'' or something else? ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 09:18 AM, Dash Four wrote:> > Tom Eastep wrote: >> On 05/12/2013 08:52 AM, Tom Eastep wrote: >> >>> Patch attached. It has uncovered an optimizer bug that is leaving a few >>> unreferenced chains behind; I''ll chase that today. >>> >> >> This patch seems to correct the optimizer. >> > Is that for the extra ACCEPT rule for ''lo'' or something else?It is for extra chains left behind. No traffic can come from the loopback device that hasn''t already been sent out of it. As a consequence, filtering in the INPUT chain is superfluous and any ''local -> fw'' rules will be optimized away with the patch I sent earlier. All that will be left is the ACCEPT rule. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tom Eastep wrote:>> Is that for the extra ACCEPT rule for ''lo'' or something else? >> > > It is for extra chains left behind. > > No traffic can come from the loopback device that hasn''t already been > sent out of it. As a consequence, filtering in the INPUT chain is > superfluous and any ''local -> fw'' rules will be optimized away with the > patch I sent earlier. All that will be left is the ACCEPT rule. >Hang on! I need to have local->fw and fw->local rules - they make perfect sense and I use them to restrict/log/report traffic. I just don''t want to have inter-chain rules connecting to or coming out of local (or ''lo''), like net2local, local2net and so on. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
On 05/12/2013 09:32 AM, Dash Four wrote:> > Tom Eastep wrote: >>> Is that for the extra ACCEPT rule for ''lo'' or something else? >>> >> >> It is for extra chains left behind. >> >> No traffic can come from the loopback device that hasn''t already been >> sent out of it. As a consequence, filtering in the INPUT chain is >> superfluous and any ''local -> fw'' rules will be optimized away with the >> patch I sent earlier. All that will be left is the ACCEPT rule. >> > Hang on! I need to have local->fw and fw->local rules - they make > perfect sense and I use them to restrict/log/report traffic. I just > don''t want to have inter-chain rules connecting to or coming out of > local (or ''lo''), like net2local, local2net and so on.Patch attached. You will have to live with the superfluous ACCEPT rule until I can find the time to suppress it. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O''Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may