Shorewall 4.5.17 Beta 2 is now available for testing.
Problems corrected since Beta 1:
1) More issues with Shorewall-init have been corrected.
2) An optimizer defect that could leave unreferenced chains in the
configuration has been corrected.
3) Unreferenced chains in the IPV6 nat table are not omitted.
New Features:
4) Two new interface options have been added.
destonly
Causes the compiler to omit rules to handle traffic arriving on
the interface.
local
Causes the compiler to only include rules to/from the firewall
itself for this interface.
Thank you for testing,
-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:> Shorewall 4.5.17 Beta 2 is now available for testing. > > Problems corrected since Beta 1: > > 1) More issues with Shorewall-init have been corrected. >I am liking the new look of shorewall-init init.d script for Fedora, though I found a couple of "loose ends" - see patch attached.> 2) An optimizer defect that could leave unreferenced chains in the > configuration has been corrected. > > 3) Unreferenced chains in the IPV6 nat table are not omitted. > > New Features: > > 4) Two new interface options have been added. > > destonly > > Causes the compiler to omit rules to handle traffic arriving on > the interface. >I''ll test this option more thoroughly tomorrow.> local > > Causes the compiler to only include rules to/from the firewall > itself for this interface. >This now seems to work, though I have a question: Suppose I have 2 interfaces in my net zone: eth0 and eth1. What shorewall seems to produce is the following: -A FORWARD -i eth0 -j net_frwd -A FORWARD -i eth1 -j net_frwd [...] -A net_frwd -o eth0 -j net2net -A net_frwd -o eth1 -j net2net From the look of things, eth0/eth1 can''t be both incoming and outgoing interface at the same time, right? In other words, a packet arriving on eth0 can''t get out of eth0, can it? Same goes for eth1. If so, then the above group of statements needs to be optimised. ------------------------------------------------------------------------------ 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
Dash Four wrote:> Suppose I have 2 interfaces in my net zone: eth0 and eth1. What > shorewall seems to produce is the following: > > -A FORWARD -i eth0 -j net_frwd > -A FORWARD -i eth1 -j net_frwd > [...] > -A net_frwd -o eth0 -j net2net > -A net_frwd -o eth1 -j net2net > > From the look of things, eth0/eth1 can''t be both incoming and outgoing > interface at the same time, right? In other words, a packet arriving > on eth0 can''t get out of eth0, can it? Same goes for eth1. If so, then > the above group of statements needs to be optimised.Please ignore the above - I wasn''t thinking 4th dimensionally. Even though there is one extra rule to traverse per interface (which will never produce a match, like -i eth0 -o eth0 in the above example), this approach is better because it uses a single <zone>_frwd chain for all interfaces in the same zone, as oppose to creating separate chains for each interface. Having said all that, net2net has a default policy of ACCEPT (ignoring what I already specified in "policy"), which needs to be corrected, but you already know that. ------------------------------------------------------------------------------ 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/13/2013 04:59 AM, Dash Four wrote:> > > Dash Four wrote: >> Suppose I have 2 interfaces in my net zone: eth0 and eth1. What >> shorewall seems to produce is the following: >> >> -A FORWARD -i eth0 -j net_frwd >> -A FORWARD -i eth1 -j net_frwd >> [...] >> -A net_frwd -o eth0 -j net2net >> -A net_frwd -o eth1 -j net2net >> >> From the look of things, eth0/eth1 can''t be both incoming and outgoing >> interface at the same time, right? In other words, a packet arriving >> on eth0 can''t get out of eth0, can it? Same goes for eth1. If so, then >> the above group of statements needs to be optimised. > Please ignore the above - I wasn''t thinking 4th dimensionally. > > Even though there is one extra rule to traverse per interface (which > will never produce a match, like -i eth0 -o eth0 in the above example), > this approach is better because it uses a single <zone>_frwd chain for > all interfaces in the same zone, as oppose to creating separate chains > for each interface. Having said all that, net2net has a default policy > of ACCEPT (ignoring what I already specified in "policy"), which needs > to be corrected, but you already know that.I assume that you have not specified an explicit net->net policy? -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/13/2013 04:59 AM, Dash Four wrote: > >> Dash Four wrote: >> >>> Suppose I have 2 interfaces in my net zone: eth0 and eth1. What >>> shorewall seems to produce is the following: >>> >>> -A FORWARD -i eth0 -j net_frwd >>> -A FORWARD -i eth1 -j net_frwd >>> [...] >>> -A net_frwd -o eth0 -j net2net >>> -A net_frwd -o eth1 -j net2net >>> >>> From the look of things, eth0/eth1 can''t be both incoming and outgoing >>> interface at the same time, right? In other words, a packet arriving >>> on eth0 can''t get out of eth0, can it? Same goes for eth1. If so, then >>> the above group of statements needs to be optimised. >>> >> Please ignore the above - I wasn''t thinking 4th dimensionally. >> >> Even though there is one extra rule to traverse per interface (which >> will never produce a match, like -i eth0 -o eth0 in the above example), >> this approach is better because it uses a single <zone>_frwd chain for >> all interfaces in the same zone, as oppose to creating separate chains >> for each interface. Having said all that, net2net has a default policy >> of ACCEPT (ignoring what I already specified in "policy"), which needs >> to be corrected, but you already know that. >> > > I assume that you have not specified an explicit net->net policy? >Correct, but I do have "all all DROP" (I can''t add "all+ all+ DROP" in policy yet, can I?). ------------------------------------------------------------------------------ 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/13/2013 07:22 AM, Dash Four wrote:> > > Tom Eastep wrote: >> On 05/13/2013 04:59 AM, Dash Four wrote: >> >>> Dash Four wrote: >>> >>>> Suppose I have 2 interfaces in my net zone: eth0 and eth1. What >>>> shorewall seems to produce is the following: >>>> >>>> -A FORWARD -i eth0 -j net_frwd >>>> -A FORWARD -i eth1 -j net_frwd >>>> [...] >>>> -A net_frwd -o eth0 -j net2net >>>> -A net_frwd -o eth1 -j net2net >>>> >>>> From the look of things, eth0/eth1 can''t be both incoming and outgoing >>>> interface at the same time, right? In other words, a packet arriving >>>> on eth0 can''t get out of eth0, can it? Same goes for eth1. If so, then >>>> the above group of statements needs to be optimised. >>>> >>> Please ignore the above - I wasn''t thinking 4th dimensionally. >>> >>> Even though there is one extra rule to traverse per interface (which >>> will never produce a match, like -i eth0 -o eth0 in the above example), >>> this approach is better because it uses a single <zone>_frwd chain for >>> all interfaces in the same zone, as oppose to creating separate chains >>> for each interface. Having said all that, net2net has a default policy >>> of ACCEPT (ignoring what I already specified in "policy"), which needs >>> to be corrected, but you already know that. >>> >> >> I assume that you have not specified an explicit net->net policy? >> > Correct, but I do have "all all DROP" (I can''t add "all+ all+ DROP" in > policy yet, can I?).No -- not yet. -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/13/2013 07:24 AM, Tom Eastep wrote:> On 05/13/2013 07:22 AM, Dash Four wrote:>> Correct, but I do have "all all DROP" (I can''t add "all+ all+ DROP" in >> policy yet, can I?). > > No -- not yet.Here is a lightly-tested patch. -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 5/12/13 6:43 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> Shorewall 4.5.17 Beta 2 is now available for testing. >> >> Problems corrected since Beta 1: >> >> 1) More issues with Shorewall-init have been corrected. >> >I am liking the new look of shorewall-init init.d script for Fedora, >though I found a couple of "loose ends" - see patch attached.Applied. Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
Dash Four wrote:>> 2) An optimizer defect that could leave unreferenced chains in the >> configuration has been corrected. >> >> 3) Unreferenced chains in the IPV6 nat table are not omitted. >> >> New Features: >> >> 4) Two new interface options have been added. >> >> destonly >> >> Causes the compiler to omit rules to handle traffic arriving on >> the interface. >> > I''ll test this option more thoroughly tomorrow.Either I don''t fully understand what this option does, or something is wrong. When I have "destonly" in my interfaces for eth0 (eth0 is part of the "local" zone), I get the following: -A OUTPUT -o eth0 -j fw2local [...] -A fw2local -m conntrack --ctstate ESTABLISHED -j ACCEPT -A fw2local -m conntrack --ctstate RELATED -j +fw2local -A fw2local -m conntrack --ctstate INVALID,UNTRACKED -j DROP -A fw2local -j ACCEPT [...] -A net2local -m conntrack --ctstate ESTABLISHED -j ACCEPT -A net2local -m conntrack --ctstate RELATED -j +net2local -A net2local -m conntrack --ctstate INVALID,UNTRACKED -j DROP -A net2local -j DROP Is this option for tracking traffic coming *into* that zone? If that is the case, then when I enter something like "ACCEPT local $FW tcp 8080" this is silently accepted, though no rule is generated. The correct course of action is to at least show a warning. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
Tom Eastep wrote:>>> Correct, but I do have "all all DROP" (I can''t add "all+ all+ DROP" in >>> policy yet, can I?). >>> >> No -- not yet. >> > > Here is a lightly-tested patch. >It seems to do the trick. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 5/13/13 4:40 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Dash Four wrote: >>> 2) An optimizer defect that could leave unreferenced chains in the >>> configuration has been corrected. >>> >>> 3) Unreferenced chains in the IPV6 nat table are not omitted. >>> >>> New Features: >>> >>> 4) Two new interface options have been added. >>> >>> destonly >>> >>> Causes the compiler to omit rules to handle traffic arriving on >>> the interface. >>> >> I''ll test this option more thoroughly tomorrow. >Either I don''t fully understand what this option does, or something is >wrong. When I have "destonly" in my interfaces for eth0 (eth0 is part of >the "local" zone), I get the following: > >-A OUTPUT -o eth0 -j fw2local >[...] >-A fw2local -m conntrack --ctstate ESTABLISHED -j ACCEPT >-A fw2local -m conntrack --ctstate RELATED -j +fw2local >-A fw2local -m conntrack --ctstate INVALID,UNTRACKED -j DROP >-A fw2local -j ACCEPT >[...] >-A net2local -m conntrack --ctstate ESTABLISHED -j ACCEPT >-A net2local -m conntrack --ctstate RELATED -j +net2local >-A net2local -m conntrack --ctstate INVALID,UNTRACKED -j DROP >-A net2local -j DROP > >Is this option for tracking traffic coming *into* that zone? If that is >the case, then when I enter something like "ACCEPT local $FW tcp 8080" >this is silently accepted, though no rule is generated. The correct >course of action is to at least show a warning.Actually, the rule is generated but then optimized away. So the warning will need to be issued when the ''local2fw'' chain contains rules but, we don''t generate any jumps to it. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 5/13/13 4:40 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >>>> Correct, but I do have "all all DROP" (I can''t add "all+ all+ DROP" >>>>in >>>> policy yet, can I?). >>>> >>> No -- not yet. >>> >> >> Here is a lightly-tested patch. >> >It seems to do the trick.Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 05/13/2013 04:49 PM, Tom Eastep wrote:> > Actually, the rule is generated but then optimized away. So the warning > will need to be issued when the ''local2fw'' chain contains rules but, we > don''t generate any jumps to it. >The attached patch predicts when a rule will be optimized away because of ''destonly'' and issues a warning when the rule is processed. -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 \________________________________________________ ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 05/14/2013 09:29 AM, Tom Eastep wrote:> On 05/13/2013 04:49 PM, Tom Eastep wrote: > >> >> Actually, the rule is generated but then optimized away. So the warning >> will need to be issued when the ''local2fw'' chain contains rules but, we >> don''t generate any jumps to it. >> > > The attached patch predicts when a rule will be optimized away because > of ''destonly'' and issues a warning when the rule is processed.This patchlet restores the INPUT ACCEPT rule for the loopback interface when a local zone has 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 \________________________________________________ ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
Tom Eastep wrote:> On 05/14/2013 09:29 AM, Tom Eastep wrote: > >> On 05/13/2013 04:49 PM, Tom Eastep wrote: >> >> >>> Actually, the rule is generated but then optimized away. So the warning >>> will need to be issued when the ''local2fw'' chain contains rules but, we >>> don''t generate any jumps to it. >>> >>> >> The attached patch predicts when a rule will be optimized away because >> of ''destonly'' and issues a warning when the rule is processed. >> > > This patchlet restores the INPUT ACCEPT rule for the loopback interface > when a local zone has the ''destonly'' option. >Yep, that seems to work now. Similarly, when I have "local" and then proceed to create something like "ACCEPT net local tcp 8080" I don''t get a warning there either. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
Tom Eastep wrote:> Thank you for testing, >Some real nasties I found in this beta: 1. shorewall-init/shorewall compile issue: during bootup, my "firewall" file is compiled by shorewall-init (no interfaces are up/running at this point) and then the OS starts bringing up my network interfaces one by one, thus, executing ifup-local, which uses the newly-compiled "firewall". After that is complete, shorewall, as a service, does not start as it "sees" that it has already started and running. So far, so good. The problem with this is that I cannot route *any* traffic between interfaces - I can pass traffic only on the interfaces which are directly connected to each other. For example, if I have one interface connected to my "green" subnet, I can send and receive traffic through this net via the firewall - no problem, but when I try to reach a different subnet, which is on another interface on the firewall, I can''t until I manually run "shorewall reload", at which point everything appears normal. I checked the packet counts for the relevant FORWARD chain - nada, nothing passes through. I checked the routing - again, there doesn''t seem to be a problem as the routing entries are *exactly* the same before and after I run "shorewall reload". I also check the ARP entries and there doesn''t seem to be a problem there either. My gut feeling tells me that when shorewall is bringing up my firewall interface by interface, it misses parts of the firewall script, which would normally run when I execute "shorewall start/reload" and these parts appear to be vital for the routing between interfaces. 2. -V0 vs -v0. There appears to be a conflict between the two options in shorewall-init. The shorewall-init init.d script takes the OPTIONS variable from /etc/sysconfig/shorewall-init and uses it to run "shorewall compile -c". On the other hand, ifupdown also uses the same OPTIONS variable, but for both "shorewall compile" and "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS parameter, that gets the OK from "/var/lib/shorewall/firewall", but fails when it comes to "shorewall compile" and everything is screwed up! I''ve managed to get one ugly hack to prevent this - I renamed all references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" (I also added this variable in "/etc/sysconfig/shorewall-init") in my shorewall-init startup script, as well as ifupdown, but I think a better solution can be found. 3. When "providers" is empty, "routes" is completely ignored by shorewall. For example, if I only have "main" entries in "routes", which is completely legitimate, these are ignored by shorewall on startup. 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" interface no less - that should not happen. 5. I started getting these annoying group of "xt_CT: helper XXX not found" crap messages appearing again in this beta! And no, I already have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf before anyone asks. 6. "shorewall update -D" does not check all files in /etc/shorewall: Compiling /etc/shorewall/interfaces... WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) -bash-4.1# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved "interfaces" is not changed (I had to do that manually). ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 05/16/2013 06:08 AM, Dash Four wrote:> > Tom Eastep wrote: >> Thank you for testing, >> > Some real nasties I found in this beta: > > 1. shorewall-init/shorewall compile issue: during bootup, my "firewall" > file is compiled by shorewall-init (no interfaces are up/running at this > point) and then the OS starts bringing up my network interfaces one by > one, thus, executing ifup-local, which uses the newly-compiled > "firewall". After that is complete, shorewall, as a service, does not > start as it "sees" that it has already started and running. So far, so > good. > > The problem with this is that I cannot route *any* traffic between > interfaces - I can pass traffic only on the interfaces which are > directly connected to each other. For example, if I have one interface > connected to my "green" subnet, I can send and receive traffic through > this net via the firewall - no problem, but when I try to reach a > different subnet, which is on another interface on the firewall, I can''t > until I manually run "shorewall reload", at which point everything > appears normal. > > I checked the packet counts for the relevant FORWARD chain - nada, > nothing passes through. I checked the routing - again, there doesn''t > seem to be a problem as the routing entries are *exactly* the same > before and after I run "shorewall reload". I also check the ARP entries > and there doesn''t seem to be a problem there either. > > My gut feeling tells me that when shorewall is bringing up my firewall > interface by interface, it misses parts of the firewall script, which > would normally run when I execute "shorewall start/reload" and these > parts appear to be vital for the routing between interfaces.I''ll need to see ''shorewall dump'' output before and after the ''reload''. Note that ''shorewall-lite restart'' on the firewall itself is more efficient than ''shorewall reload'' on the admin system.> > 2. -V0 vs -v0. There appears to be a conflict between the two options in > shorewall-init. The shorewall-init init.d script takes the OPTIONS > variable from /etc/sysconfig/shorewall-init and uses it to run > "shorewall compile -c". On the other hand, ifupdown also uses the same > OPTIONS variable, but for both "shorewall compile" and > "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS > parameter, that gets the OK from "/var/lib/shorewall/firewall", but > fails when it comes to "shorewall compile" and everything is screwed up! > > I''ve managed to get one ugly hack to prevent this - I renamed all > references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" (I > also added this variable in "/etc/sysconfig/shorewall-init") in my > shorewall-init startup script, as well as ifupdown, but I think a better > solution can be found.I believe that the attached v_vs_V.patch is a better solution.> > 3. When "providers" is empty, "routes" is completely ignored by > shorewall. For example, if I only have "main" entries in "routes", which > is completely legitimate, these are ignored by shorewall on startup.Patch STANDARDROUTES.patch attached.> > 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" > interface no less - that should not happen.Why should the firewall zone be different from any other zone? If you don''t want that behavior, add this policy before the one you quote: $FW $FW ACCEPT> > 5. I started getting these annoying group of "xt_CT: helper XXX not > found" crap messages appearing again in this beta! And no, I already > have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf before > anyone asks.There were no changes to the module-handling code in Beta 2. Note that the xt_CT: messages will appear when a ''show capabilities'' or ''dump'' command is executed.> > 6. "shorewall update -D" does not check all files in /etc/shorewall: > > Compiling /etc/shorewall/interfaces... > WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider > running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) > > -bash-4.1# shorewall update -D > Updating... > Processing /etc/shorewall/params ... > Processing /etc/shorewall/shorewall.conf... > No update required to configuration file /etc/shorewall/shorewall.conf; > /etc/shorewall/shorewall.conf.bak not saved > > "interfaces" is not changed (I had to do that manually).Works for me. root@gateway:~# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved Loading Modules... Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... File /etc/shorewall/interfaces updated - old file renamed /etc/shorewall/interfaces.bak Running /etc/shorewall/compile... Checking /etc/shorewall/zones... Checking /etc/shorewall/interfaces... -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 \________________________________________________ ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
Tom Eastep wrote:> I''ll need to see ''shorewall dump'' output before and after the ''reload''. > Note that ''shorewall-lite restart'' on the firewall itself is more > efficient than ''shorewall reload'' on the admin system. >I don''t have shorewall-lite - just shorewall and shorewall-init. I''ll see what I can do with shorewall dump.>> 2. -V0 vs -v0. There appears to be a conflict between the two options in >> shorewall-init. The shorewall-init init.d script takes the OPTIONS >> variable from /etc/sysconfig/shorewall-init and uses it to run >> "shorewall compile -c". On the other hand, ifupdown also uses the same >> OPTIONS variable, but for both "shorewall compile" and >> "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS >> parameter, that gets the OK from "/var/lib/shorewall/firewall", but >> fails when it comes to "shorewall compile" and everything is screwed up! >> >> I''ve managed to get one ugly hack to prevent this - I renamed all >> references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" (I >> also added this variable in "/etc/sysconfig/shorewall-init") in my >> shorewall-init startup script, as well as ifupdown, but I think a better >> solution can be found. >> > > I believe that the attached v_vs_V.patch is a better solution. >I don''t understand this. The point was that "shorewall" does not accept -V0 and it fails - does your patch address this?>> 3. When "providers" is empty, "routes" is completely ignored by >> shorewall. For example, if I only have "main" entries in "routes", which >> is completely legitimate, these are ignored by shorewall on startup. >> > > Patch STANDARDROUTES.patch attached. >Thanks, will try to find some time tomorrow to test this.>> 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" >> interface no less - that should not happen. >> > > Why should the firewall zone be different from any other zone? If you > don''t want that behavior, add this policy before the one you quote: > > $FW $FW ACCEPT >I was under the impression that the "fw" zone isn''t attached to any interface. I already have a zone with that interface in it and it is called "local".>> 5. I started getting these annoying group of "xt_CT: helper XXX not >> found" crap messages appearing again in this beta! And no, I already >> have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf before >> anyone asks. >> > > There were no changes to the module-handling code in Beta 2. Note that > the xt_CT: messages will appear when a ''show capabilities'' or ''dump'' > command is executed. >The messages were shown during either shorewall-init or when shorewall is executed to bring up my interfaces - don''t know which as this was during boot up and I''ve got these in my logs.>> 6. "shorewall update -D" does not check all files in /etc/shorewall: >> >> Compiling /etc/shorewall/interfaces... >> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >> >> -bash-4.1# shorewall update -D >> Updating... >> Processing /etc/shorewall/params ... >> Processing /etc/shorewall/shorewall.conf... >> No update required to configuration file /etc/shorewall/shorewall.conf; >> /etc/shorewall/shorewall.conf.bak not saved >> >> "interfaces" is not changed (I had to do that manually). >> > > Works for me. > > root@gateway:~# shorewall update -D > Updating... > Processing /etc/shorewall/params ... > Processing /etc/shorewall/shorewall.conf... > No update required to configuration file /etc/shorewall/shorewall.conf; > /etc/shorewall/shorewall.conf.bak not saved > Loading Modules... > Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... > File /etc/shorewall/interfaces updated - old file renamed > /etc/shorewall/interfaces.bak > Running /etc/shorewall/compile... > Checking /etc/shorewall/zones... > Checking /etc/shorewall/interfaces... >Well, it doesn''t work here. In addition to what I''ve already posted, I found another gem: accounting ~~~~~~~~~~ NFACCT(acc1,acc2) net2fw +test1 !+test2[src] produces -A net2fw -m set --match-set test1 src -m nfacct --nfacct-name acc1 -m nfacct --nfacct-name acc2 -m set ! --match-set test2 src which is wrong. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
> accounting > ~~~~~~~~~~ > NFACCT(acc1,acc2) net2fw +test1 !+test2[src] > > produces > > -A net2fw -m set --match-set test1 src -m nfacct --nfacct-name acc1 -m > nfacct --nfacct-name acc2 -m set ! --match-set test2 src > > which is wrong.The alternative syntax of "NFACCT(acc1,acc2) net2fw +[test1,!test2]", which should be the same as the above statement, works and produces what is expected. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 5/17/13 4:01 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> I''ll need to see ''shorewall dump'' output before and after the ''reload''. >> Note that ''shorewall-lite restart'' on the firewall itself is more >> efficient than ''shorewall reload'' on the admin system. >> >I don''t have shorewall-lite - just shorewall and shorewall-init. I''ll >see what I can do with shorewall dump.Thanks.> >>> 2. -V0 vs -v0. There appears to be a conflict between the two options >>>in >>> shorewall-init. The shorewall-init init.d script takes the OPTIONS >>> variable from /etc/sysconfig/shorewall-init and uses it to run >>> "shorewall compile -c". On the other hand, ifupdown also uses the same >>> OPTIONS variable, but for both "shorewall compile" and >>> "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS >>> parameter, that gets the OK from "/var/lib/shorewall/firewall", but >>> fails when it comes to "shorewall compile" and everything is screwed >>>up! >>> >>> I''ve managed to get one ugly hack to prevent this - I renamed all >>> references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" >>>(I >>> also added this variable in "/etc/sysconfig/shorewall-init") in my >>> shorewall-init startup script, as well as ifupdown, but I think a >>>better >>> solution can be found. >>> >> >> I believe that the attached v_vs_V.patch is a better solution. >> >I don''t understand this. The point was that "shorewall" does not accept >-V0 and it fails - does your patch address this?Yes.> >>> 3. When "providers" is empty, "routes" is completely ignored by >>> shorewall. For example, if I only have "main" entries in "routes", >>>which >>> is completely legitimate, these are ignored by shorewall on startup. >>> >> >> Patch STANDARDROUTES.patch attached. >> >Thanks, will try to find some time tomorrow to test this.Thanks.> >>> 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" >>> interface no less - that should not happen. >>> >> >> Why should the firewall zone be different from any other zone? If you >> don''t want that behavior, add this policy before the one you quote: >> >> $FW $FW ACCEPT >> >I was under the impression that the "fw" zone isn''t attached to any >interface. I already have a zone with that interface in it and it is >called "local".Yes -- We invented ''local'' zones for you. But every other user of Shorewall assumes that the zone at the other end of ''lo'' is $FW because all intra-system IP communication must go through ''lo''. That is a fundamental assumption of the Shorewall design. When you define a fw->fw policy or fw->fw rules, they are enforced from the OUTPUT chain via a chain named ''fw2fw'' or ''fw-fw'' (assuming that $FW eq ''fw''.> >>> 5. I started getting these annoying group of "xt_CT: helper XXX not >>> found" crap messages appearing again in this beta! And no, I already >>> have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf >>>before >>> anyone asks. >>> >> >> There were no changes to the module-handling code in Beta 2. Note that >> the xt_CT: messages will appear when a ''show capabilities'' or ''dump'' >> command is executed. >> >The messages were shown during either shorewall-init or when shorewall >is executed to bring up my interfaces - don''t know which as this was >during boot up and I''ve got these in my logs.Was a ruleset compilation involved?> >>> 6. "shorewall update -D" does not check all files in /etc/shorewall: >>> >>> Compiling /etc/shorewall/interfaces... >>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>> >>> -bash-4.1# shorewall update -D >>> Updating... >>> Processing /etc/shorewall/params ... >>> Processing /etc/shorewall/shorewall.conf... >>> No update required to configuration file >>>/etc/shorewall/shorewall.conf; >>> /etc/shorewall/shorewall.conf.bak not saved >>> >>> "interfaces" is not changed (I had to do that manually). >>> >> >> Works for me. >> >> root@gateway:~# shorewall update -D >> Updating... >> Processing /etc/shorewall/params ... >> Processing /etc/shorewall/shorewall.conf... >> No update required to configuration file /etc/shorewall/shorewall.conf; >> /etc/shorewall/shorewall.conf.bak not saved >> Loading Modules... >> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >> File /etc/shorewall/interfaces updated - old file renamed >> /etc/shorewall/interfaces.bak >> Running /etc/shorewall/compile... >> Checking /etc/shorewall/zones... >> Checking /etc/shorewall/interfaces... >> >Well, it doesn''t work here.I suspect that it is something about the file itself -- did you save a copy?>In addition to what I''ve already posted, I >found another gem: > >accounting >~~~~~~~~~~ >NFACCT(acc1,acc2) net2fw +test1 !+test2[src] > >produces > >-A net2fw -m set --match-set test1 src -m nfacct --nfacct-name acc1 -m >nfacct --nfacct-name acc2 -m set ! --match-set test2 src > >which is wrong.I will look at it as time permits, as I see that you found a workaround. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 05/17/2013 04:01 PM, Dash Four wrote:>>> Compiling /etc/shorewall/interfaces... >>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>> >>> -bash-4.1# shorewall update -D >>> Updating... >>> Processing /etc/shorewall/params ... >>> Processing /etc/shorewall/shorewall.conf... >>> No update required to configuration file /etc/shorewall/shorewall.conf; >>> /etc/shorewall/shorewall.conf.bak not saved >>> >>> "interfaces" is not changed (I had to do that manually). >>>Note that ''FORMAT'' and ''COMMENT'' lines are converted in a later step; they are not handled at the same time as shorewall[6].conf.>> >> Works for me. >> >> root@gateway:~# shorewall update -D >> Updating... >> Processing /etc/shorewall/params ... >> Processing /etc/shorewall/shorewall.conf... >> No update required to configuration file /etc/shorewall/shorewall.conf; >> /etc/shorewall/shorewall.conf.bak not saved >> Loading Modules... >> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >> File /etc/shorewall/interfaces updated - old file renamed >> /etc/shorewall/interfaces.bak >> Running /etc/shorewall/compile... >> Checking /etc/shorewall/zones... >> Checking /etc/shorewall/interfaces... >> > Well, it doesn''t work here.The only way that I have been able to get this to fail is to run as non-root and secure a file needing update against write access. -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 \________________________________________________ ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
On 05/17/2013 04:28 PM, Dash Four wrote:> >> accounting >> ~~~~~~~~~~ >> NFACCT(acc1,acc2) net2fw +test1 !+test2[src] >> >> produces >> >> -A net2fw -m set --match-set test1 src -m nfacct --nfacct-name acc1 -m >> nfacct --nfacct-name acc2 -m set ! --match-set test2 src >> >> which is wrong. > The alternative syntax of "NFACCT(acc1,acc2) net2fw +[test1,!test2]", > which should be the same as the above statement, works and produces what > is expected.Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 05/22/2013 07:34 AM, Tom Eastep wrote:> On 05/17/2013 04:28 PM, Dash Four wrote: >> >>> accounting >>> ~~~~~~~~~~ >>> NFACCT(acc1,acc2) net2fw +test1 !+test2[src] >>> >>> produces >>> >>> -A net2fw -m set --match-set test1 src -m nfacct --nfacct-name acc1 -m >>> nfacct --nfacct-name acc2 -m set ! --match-set test2 src >>> >>> which is wrong. >> The alternative syntax of "NFACCT(acc1,acc2) net2fw +[test1,!test2]", >> which should be the same as the above statement, works and produces what >> is expected. > > Patch attached.And here is a second patch to apply on top of the first. It insures that the source and dest matches are in the proper order. -- 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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 05/17/2013 05:29 PM, Tom Eastep wrote:> On 5/17/13 4:01 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:>>>> 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" >>>> interface no less - that should not happen. >>>> >>> >>> Why should the firewall zone be different from any other zone? If you >>> don''t want that behavior, add this policy before the one you quote: >>> >>> $FW $FW ACCEPT >>> >> I was under the impression that the "fw" zone isn''t attached to any >> interface. I already have a zone with that interface in it and it is >> called "local". > > Yes -- We invented ''local'' zones for you. But every other user of > Shorewall assumes that the zone at the > other end of ''lo'' is $FW because all intra-system IP communication must go > through ''lo''. That is a fundamental assumption of the Shorewall design. > When you define a fw->fw policy or fw->fw rules, they are enforced from > the OUTPUT chain via a chain named ''fw2fw'' or ''fw-fw'' (assuming that $FW > eq ''fw''.The attached simple patch eliminates the extraneous chains/rules when there is a local zone. -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/17/13 4:01 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >> Tom Eastep wrote: >> >>> I''ll need to see ''shorewall dump'' output before and after the ''reload''. >>> Note that ''shorewall-lite restart'' on the firewall itself is more >>> efficient than ''shorewall reload'' on the admin system. >>> >>> >> I don''t have shorewall-lite - just shorewall and shorewall-init. I''ll >> see what I can do with shorewall dump. >> > > Thanks. >I was right! It looks as though not all parts of the firewall file are executed when ifupdown-local gets started, as opposed to a direct "firewall start". Here is the diff produced before and after "shorewall reload" (I''ve omitted the counter differences and other such "noise"): --- shorewall-b4-dump.log +++ shorewall-after-dump.log @@ -1474,7 +1474,7 @@ /proc /proc/version = Linux version 3.9.4-207.fc19.atom (mockbuild@dmz7.my.network) (gcc version 4.8.0 20130517 (Red Hat 4.8.0-17) (GCC) ) #1 Sun May 19 06:55:38 BST 2013 - /proc/sys/net/ipv4/ip_forward = 0 + /proc/sys/net/ipv4/ip_forward = 1 /proc/sys/net/ipv4/icmp_echo_ignore_all = 0 /proc/sys/net/ipv4/conf/all/proxy_arp = 0 /proc/sys/net/ipv4/conf/all/arp_filter = 0 @@ -1547,6 +1547,7 @@ xt_dscp 12525 0 xt_DSCP 12549 0 xt_hashlimit 13191 0 +xt_helper 12519 0 xt_IPMARK 12513 0 xt_ipp2p 17231 0 xt_length 12480 0 As evident, IP forwarding is disabled when ifupdown-local brings up my network interfaces one by one and I also don''t have this "xt_helper" (ahem!!) module loaded, so something is definitely amiss.>>>> 2. -V0 vs -v0. There appears to be a conflict between the two options >>>> in >>>> shorewall-init. The shorewall-init init.d script takes the OPTIONS >>>> variable from /etc/sysconfig/shorewall-init and uses it to run >>>> "shorewall compile -c". On the other hand, ifupdown also uses the same >>>> OPTIONS variable, but for both "shorewall compile" and >>>> "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS >>>> parameter, that gets the OK from "/var/lib/shorewall/firewall", but >>>> fails when it comes to "shorewall compile" and everything is screwed >>>> up! >>>> >>>> I''ve managed to get one ugly hack to prevent this - I renamed all >>>> references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" >>>> (I >>>> also added this variable in "/etc/sysconfig/shorewall-init") in my >>>> shorewall-init startup script, as well as ifupdown, but I think a >>>> better >>>> solution can be found. >>>> >>>> >>> I believe that the attached v_vs_V.patch is a better solution. >>> >>> >> I don''t understand this. The point was that "shorewall" does not accept >> -V0 and it fails - does your patch address this? >> > > Yes. >What happens when I specify -V0 with "shorewall" (say "shorewall -V0 compile -c")?>>>> 3. When "providers" is empty, "routes" is completely ignored by >>>> shorewall. For example, if I only have "main" entries in "routes", >>>> which >>>> is completely legitimate, these are ignored by shorewall on startup. >>>> >>>> >>> Patch STANDARDROUTES.patch attached. >>> >>> >> Thanks, will try to find some time tomorrow to test this. >> > > Thanks. >That now works.>>>> 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" >>>> interface no less - that should not happen. >>>> >>>> >>> Why should the firewall zone be different from any other zone? If you >>> don''t want that behavior, add this policy before the one you quote: >>> >>> $FW $FW ACCEPT >>> >>> >> I was under the impression that the "fw" zone isn''t attached to any >> interface. I already have a zone with that interface in it and it is >> called "local". >> > > Yes -- We invented ''local'' zones for you. But every other user of > Shorewall assumes that the zone at the > other end of ''lo'' is $FW because all intra-system IP communication must go > through ''lo''. That is a fundamental assumption of the Shorewall design. > When you define a fw->fw policy or fw->fw rules, they are enforced from > the OUTPUT chain via a chain named ''fw2fw'' or ''fw-fw'' (assuming that $FW > eq ''fw''. >Well, this isn''t working - even though fw2fw is now gone, I get an error: interfaces ~~~~~~~~~~ local usb1 tcpflags,local,logmartians,nosmurfs,optional gives me: Compiling /etc/shorewall/interfaces... ERROR: Invalid Interface option (local) /etc/shorewall/interfaces (line 17) ''local'' is/was a legitimate option in Beta2/3.>>>> 5. I started getting these annoying group of "xt_CT: helper XXX not >>>> found" crap messages appearing again in this beta! And no, I already >>>> have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf >>>> before >>>> anyone asks. >>>> >>>> >>> There were no changes to the module-handling code in Beta 2. Note that >>> the xt_CT: messages will appear when a ''show capabilities'' or ''dump'' >>> command is executed. >>> >>> >> The messages were shown during either shorewall-init or when shorewall >> is executed to bring up my interfaces - don''t know which as this was >> during boot up and I''ve got these in my logs. >> > > Was a ruleset compilation involved? >Don''t know, probably. This is what I have: syslog ~~~~~~ May 25 17:06:12 test1 kernel: [ 55.770494] xt_time: kernel timezone is +0100 May 25 17:06:12 test1 kernel: [ 58.168024] xt_CT: No such helper "sane" May 25 17:06:12 test1 kernel: [ 58.226149] xt_CT: No such helper "sane-0" May 25 17:06:12 test1 kernel: [ 58.286290] xt_CT: No such helper "tftp" May 25 17:06:12 test1 kernel: [ 58.350940] xt_CT: No such helper "tftp-0" May 25 17:06:12 test1 kernel: [ 58.409208] xt_CT: No such helper "pptp" May 25 17:06:12 test1 kernel: [ 58.474760] xt_CT: No such helper "sip" May 25 17:06:12 test1 kernel: [ 58.533706] xt_CT: No such helper "sip-0" May 25 17:06:12 test1 kernel: [ 58.597862] xt_CT: No such helper "snmp" May 25 17:06:12 test1 kernel: [ 58.657024] xt_CT: No such helper "netbios-ns" May 25 17:06:12 test1 kernel: [ 58.720569] xt_CT: No such helper "ftp" May 25 17:06:12 test1 kernel: [ 58.778310] xt_CT: No such helper "ftp-0" May 25 17:06:12 test1 kernel: [ 58.842895] xt_CT: No such helper "irc" May 25 17:06:12 test1 kernel: [ 58.900682] xt_CT: No such helper "irc-0" May 25 17:06:12 test1 kernel: [ 58.959876] xt_CT: No such helper "amanda" May 25 17:06:12 test1 kernel: [ 71.430988] xt_CT: No such helper "sane" May 25 17:06:12 test1 kernel: [ 71.494018] xt_CT: No such helper "sane-0" May 25 17:06:12 test1 kernel: [ 71.552918] xt_CT: No such helper "tftp" May 25 17:06:12 test1 kernel: [ 71.617196] xt_CT: No such helper "tftp-0" May 25 17:06:12 test1 kernel: [ 71.675524] xt_CT: No such helper "pptp" May 25 17:06:12 test1 kernel: [ 71.741260] xt_CT: No such helper "sip" May 25 17:06:12 test1 kernel: [ 71.799948] xt_CT: No such helper "sip-0" May 25 17:06:12 test1 kernel: [ 71.864108] xt_CT: No such helper "snmp" May 25 17:06:12 test1 kernel: [ 71.923338] xt_CT: No such helper "netbios-ns" May 25 17:06:12 test1 kernel: [ 71.986341] xt_CT: No such helper "ftp" May 25 17:06:12 test1 kernel: [ 72.045616] xt_CT: No such helper "ftp-0" May 25 17:06:12 test1 kernel: [ 72.107604] xt_CT: No such helper "irc" May 25 17:06:12 test1 kernel: [ 72.166677] xt_CT: No such helper "irc-0" May 25 17:06:12 test1 kernel: [ 72.225710] xt_CT: No such helper "amanda" May 25 17:06:12 test1 kernel: [ 84.754447] xt_CT: No such helper "sane" May 25 17:06:12 test1 kernel: [ 84.813396] xt_CT: No such helper "sane-0" May 25 17:06:12 test1 kernel: [ 84.877570] xt_CT: No such helper "tftp" May 25 17:06:12 test1 kernel: [ 84.936298] xt_CT: No such helper "tftp-0" May 25 17:06:12 test1 kernel: [ 84.998476] xt_CT: No such helper "pptp" May 25 17:06:12 test1 kernel: [ 85.058853] xt_CT: No such helper "sip" May 25 17:06:12 test1 kernel: [ 85.117682] xt_CT: No such helper "sip-0" May 25 17:06:12 test1 kernel: [ 85.183173] xt_CT: No such helper "snmp" May 25 17:06:12 test1 kernel: [ 85.247593] xt_CT: No such helper "netbios-ns" May 25 17:06:12 test1 kernel: [ 85.305983] xt_CT: No such helper "ftp" May 25 17:06:12 test1 kernel: [ 85.369152] xt_CT: No such helper "ftp-0" May 25 17:06:12 test1 kernel: [ 85.426916] xt_CT: No such helper "irc" May 25 17:06:12 test1 kernel: [ 85.491393] xt_CT: No such helper "irc-0" May 25 17:06:12 test1 kernel: [ 85.550423] xt_CT: No such helper "amanda" /var/log/shorewall.log (shorewall startup log) ~~~~~~~~~~~~~~~~~~~~~~ May 25 17:06:09 Processing /etc/shorewall/start ... May 25 17:06:10 Processing /etc/shorewall/started ... /var/log/shorewall-ifupdown.log (shorewall-init log) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] May 25 17:05:54 /sbin/ifup-local: Executing /var/lib//shorewall/firewall -V0 up eth0 *** Note the times - it looks as though it happens at the very beginning (my guess is during shorewall compilation).>>>> 6. "shorewall update -D" does not check all files in /etc/shorewall: >>>> >>>> Compiling /etc/shorewall/interfaces... >>>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>>> >>>> -bash-4.1# shorewall update -D >>>> Updating... >>>> Processing /etc/shorewall/params ... >>>> Processing /etc/shorewall/shorewall.conf... >>>> No update required to configuration file >>>> /etc/shorewall/shorewall.conf; >>>> /etc/shorewall/shorewall.conf.bak not saved >>>> >>>> "interfaces" is not changed (I had to do that manually). >>>> >>>> >>> Works for me. >>> >>> root@gateway:~# shorewall update -D >>> Updating... >>> Processing /etc/shorewall/params ... >>> Processing /etc/shorewall/shorewall.conf... >>> No update required to configuration file /etc/shorewall/shorewall.conf; >>> /etc/shorewall/shorewall.conf.bak not saved >>> Loading Modules... >>> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >>> File /etc/shorewall/interfaces updated - old file renamed >>> /etc/shorewall/interfaces.bak >>> Running /etc/shorewall/compile... >>> Checking /etc/shorewall/zones... >>> Checking /etc/shorewall/interfaces... >>> >>> >> Well, it doesn''t work here. >> > > I suspect that it is something about the file itself -- did you save a > copy? >-bash-4.1# ls -las /etc/shorewall 8 drwx------. 3 root root 4096 May 25 16:50 . [...] 8 -rw-------. 1 root root 1135 May 15 19:13 interfaces All files in /etc/shorewall have their permissions set at 600 (rw only on owner). In addition, the whole /etc/ partition has "noexec" attribute set in my fstab to prevent code being executed on that partition. -bash-4.1# cat /etc/shorewall/interfaces # # Shorewall version 4 - Interfaces File # # For information about entries in this file, type "man shorewall-interfaces" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-interfaces.html # ############################################################################### FORMAT 2 ############################################################################### #ZONE INTERFACE OPTIONS [...] So, on the face of it, nothing special apart from maybe the file permissions. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 10:59 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> On 5/17/13 4:01 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >>> Tom Eastep wrote: >>> >>>> I''ll need to see ''shorewall dump'' output before and after the >>>>''reload''. >>>> Note that ''shorewall-lite restart'' on the firewall itself is more >>>> efficient than ''shorewall reload'' on the admin system. >>>> >>>> >>> I don''t have shorewall-lite - just shorewall and shorewall-init. I''ll >>> see what I can do with shorewall dump. >>> >> >> Thanks. >> >I was right! It looks as though not all parts of the firewall file are >executed when ifupdown-local gets started, as opposed to a direct >"firewall start". Here is the diff produced before and after "shorewall >reload" (I''ve omitted the counter differences and other such "noise"): > >--- shorewall-b4-dump.log >+++ shorewall-after-dump.log >@@ -1474,7 +1474,7 @@ > /proc > > /proc/version = Linux version 3.9.4-207.fc19.atom >(mockbuild@dmz7.my.network) (gcc version 4.8.0 20130517 (Red Hat >4.8.0-17) (GCC) ) #1 Sun May 19 06:55:38 BST 2013 >- /proc/sys/net/ipv4/ip_forward = 0 >+ /proc/sys/net/ipv4/ip_forward = 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all = 0 > /proc/sys/net/ipv4/conf/all/proxy_arp = 0 > /proc/sys/net/ipv4/conf/all/arp_filter = 0 >@@ -1547,6 +1547,7 @@ > xt_dscp 12525 0 > xt_DSCP 12549 0 > xt_hashlimit 13191 0 >+xt_helper 12519 0 > xt_IPMARK 12513 0 > xt_ipp2p 17231 0 > xt_length 12480 0 > >As evident, IP forwarding is disabled when ifupdown-local brings up my >network interfaces one by one and I also don''t have this "xt_helper" >(ahem!!) module loaded, so something is definitely amiss.Please forward the ''firewall'' script that is showing this behavior.> >>>>> 2. -V0 vs -v0. There appears to be a conflict between the two options >>>>> in >>>>> shorewall-init. The shorewall-init init.d script takes the OPTIONS >>>>> variable from /etc/sysconfig/shorewall-init and uses it to run >>>>> "shorewall compile -c". On the other hand, ifupdown also uses the >>>>>same >>>>> OPTIONS variable, but for both "shorewall compile" and >>>>> "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS >>>>> parameter, that gets the OK from "/var/lib/shorewall/firewall", but >>>>> fails when it comes to "shorewall compile" and everything is screwed >>>>> up! >>>>> >>>>> I''ve managed to get one ugly hack to prevent this - I renamed all >>>>> references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" >>>>> (I >>>>> also added this variable in "/etc/sysconfig/shorewall-init") in my >>>>> shorewall-init startup script, as well as ifupdown, but I think a >>>>> better >>>>> solution can be found. >>>>> >>>>> >>>> I believe that the attached v_vs_V.patch is a better solution. >>>> >>>> >>> I don''t understand this. The point was that "shorewall" does not accept >>> -V0 and it fails - does your patch address this? >>> >> >> Yes. >> >What happens when I specify -V0 with "shorewall" (say "shorewall -V0 >compile -c")?-V0 is a synonym for -v0> >>>>> 3. When "providers" is empty, "routes" is completely ignored by >>>>> shorewall. For example, if I only have "main" entries in "routes", >>>>> which >>>>> is completely legitimate, these are ignored by shorewall on startup. >>>>> >>>>> >>>> Patch STANDARDROUTES.patch attached. >>>> >>>> >>> Thanks, will try to find some time tomorrow to test this. >>> >> >> Thanks. >> >That now works. > >>>>> 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" >>>>> interface no less - that should not happen. >>>>> >>>>> >>>> Why should the firewall zone be different from any other zone? If you >>>> don''t want that behavior, add this policy before the one you quote: >>>> >>>> $FW $FW ACCEPT >>>> >>>> >>> I was under the impression that the "fw" zone isn''t attached to any >>> interface. I already have a zone with that interface in it and it is >>> called "local". >>> >> >> Yes -- We invented ''local'' zones for you. But every other user of >> Shorewall assumes that the zone at the >> other end of ''lo'' is $FW because all intra-system IP communication must >>go >> through ''lo''. That is a fundamental assumption of the Shorewall design. >> When you define a fw->fw policy or fw->fw rules, they are enforced from >> the OUTPUT chain via a chain named ''fw2fw'' or ''fw-fw'' (assuming that $FW >> eq ''fw''. >> >Well, this isn''t working - even though fw2fw is now gone, I get an error: > >interfaces >~~~~~~~~~~ >local usb1 tcpflags,local,logmartians,nosmurfs,optional > >gives me: > >Compiling /etc/shorewall/interfaces... > ERROR: Invalid Interface option (local) /etc/shorewall/interfaces >(line 17) > >''local'' is/was a legitimate option in Beta2/3.Not it Beta 3. Again, ''local'' is a zone type.> >>>>> 5. I started getting these annoying group of "xt_CT: helper XXX not >>>>> found" crap messages appearing again in this beta! And no, I already >>>>> have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf >>>>> before >>>>> anyone asks. >>>>> >>>>> >>>> There were no changes to the module-handling code in Beta 2. Note that >>>> the xt_CT: messages will appear when a ''show capabilities'' or ''dump'' >>>> command is executed. >>>> >>>> >>> The messages were shown during either shorewall-init or when shorewall >>> is executed to bring up my interfaces - don''t know which as this was >>> during boot up and I''ve got these in my logs. >>> >> >> Was a ruleset compilation involved? >> >Don''t know, probably. This is what I have: > >syslog >~~~~~~ >May 25 17:06:12 test1 kernel: [ 55.770494] xt_time: kernel timezone is >+0100 >May 25 17:06:12 test1 kernel: [ 58.168024] xt_CT: No such helper "sane" >May 25 17:06:12 test1 kernel: [ 58.226149] xt_CT: No such helper >"sane-0" >May 25 17:06:12 test1 kernel: [ 58.286290] xt_CT: No such helper "tftp" >May 25 17:06:12 test1 kernel: [ 58.350940] xt_CT: No such helper >"tftp-0" >May 25 17:06:12 test1 kernel: [ 58.409208] xt_CT: No such helper "pptp" >May 25 17:06:12 test1 kernel: [ 58.474760] xt_CT: No such helper "sip" >May 25 17:06:12 test1 kernel: [ 58.533706] xt_CT: No such helper "sip-0" >May 25 17:06:12 test1 kernel: [ 58.597862] xt_CT: No such helper "snmp" >May 25 17:06:12 test1 kernel: [ 58.657024] xt_CT: No such helper >"netbios-ns" >May 25 17:06:12 test1 kernel: [ 58.720569] xt_CT: No such helper "ftp" >May 25 17:06:12 test1 kernel: [ 58.778310] xt_CT: No such helper "ftp-0" >May 25 17:06:12 test1 kernel: [ 58.842895] xt_CT: No such helper "irc" >May 25 17:06:12 test1 kernel: [ 58.900682] xt_CT: No such helper "irc-0" >May 25 17:06:12 test1 kernel: [ 58.959876] xt_CT: No such helper >"amanda" >May 25 17:06:12 test1 kernel: [ 71.430988] xt_CT: No such helper "sane" >May 25 17:06:12 test1 kernel: [ 71.494018] xt_CT: No such helper >"sane-0" >May 25 17:06:12 test1 kernel: [ 71.552918] xt_CT: No such helper "tftp" >May 25 17:06:12 test1 kernel: [ 71.617196] xt_CT: No such helper >"tftp-0" >May 25 17:06:12 test1 kernel: [ 71.675524] xt_CT: No such helper "pptp" >May 25 17:06:12 test1 kernel: [ 71.741260] xt_CT: No such helper "sip" >May 25 17:06:12 test1 kernel: [ 71.799948] xt_CT: No such helper "sip-0" >May 25 17:06:12 test1 kernel: [ 71.864108] xt_CT: No such helper "snmp" >May 25 17:06:12 test1 kernel: [ 71.923338] xt_CT: No such helper >"netbios-ns" >May 25 17:06:12 test1 kernel: [ 71.986341] xt_CT: No such helper "ftp" >May 25 17:06:12 test1 kernel: [ 72.045616] xt_CT: No such helper "ftp-0" >May 25 17:06:12 test1 kernel: [ 72.107604] xt_CT: No such helper "irc" >May 25 17:06:12 test1 kernel: [ 72.166677] xt_CT: No such helper "irc-0" >May 25 17:06:12 test1 kernel: [ 72.225710] xt_CT: No such helper >"amanda" >May 25 17:06:12 test1 kernel: [ 84.754447] xt_CT: No such helper "sane" >May 25 17:06:12 test1 kernel: [ 84.813396] xt_CT: No such helper >"sane-0" >May 25 17:06:12 test1 kernel: [ 84.877570] xt_CT: No such helper "tftp" >May 25 17:06:12 test1 kernel: [ 84.936298] xt_CT: No such helper >"tftp-0" >May 25 17:06:12 test1 kernel: [ 84.998476] xt_CT: No such helper "pptp" >May 25 17:06:12 test1 kernel: [ 85.058853] xt_CT: No such helper "sip" >May 25 17:06:12 test1 kernel: [ 85.117682] xt_CT: No such helper "sip-0" >May 25 17:06:12 test1 kernel: [ 85.183173] xt_CT: No such helper "snmp" >May 25 17:06:12 test1 kernel: [ 85.247593] xt_CT: No such helper >"netbios-ns" >May 25 17:06:12 test1 kernel: [ 85.305983] xt_CT: No such helper "ftp" >May 25 17:06:12 test1 kernel: [ 85.369152] xt_CT: No such helper "ftp-0" >May 25 17:06:12 test1 kernel: [ 85.426916] xt_CT: No such helper "irc" >May 25 17:06:12 test1 kernel: [ 85.491393] xt_CT: No such helper "irc-0" >May 25 17:06:12 test1 kernel: [ 85.550423] xt_CT: No such helper >"amanda" > >/var/log/shorewall.log (shorewall startup log) >~~~~~~~~~~~~~~~~~~~~~~ >May 25 17:06:09 Processing /etc/shorewall/start ... >May 25 17:06:10 Processing /etc/shorewall/started ... > >/var/log/shorewall-ifupdown.log (shorewall-init log) >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >[...] >May 25 17:05:54 /sbin/ifup-local: Executing /var/lib//shorewall/firewall >-V0 up eth0 > >*** Note the times - it looks as though it happens at the very beginning >(my guess is during shorewall compilation).The ''start'' and ''started scripts are run at the very end of the firewall script''s execution. Again, I want to look at the ''firewall'' script.> >>>>> 6. "shorewall update -D" does not check all files in /etc/shorewall: >>>>> >>>>> Compiling /etc/shorewall/interfaces... >>>>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>>>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>>>> >>>>> -bash-4.1# shorewall update -D >>>>> Updating... >>>>> Processing /etc/shorewall/params ... >>>>> Processing /etc/shorewall/shorewall.conf... >>>>> No update required to configuration file >>>>> /etc/shorewall/shorewall.conf; >>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>> >>>>> "interfaces" is not changed (I had to do that manually). >>>>> >>>>> >>>> Works for me. >>>> >>>> root@gateway:~# shorewall update -D >>>> Updating... >>>> Processing /etc/shorewall/params ... >>>> Processing /etc/shorewall/shorewall.conf... >>>> No update required to configuration file >>>>/etc/shorewall/shorewall.conf; >>>> /etc/shorewall/shorewall.conf.bak not saved >>>> Loading Modules... >>>> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >>>> File /etc/shorewall/interfaces updated - old file renamed >>>> /etc/shorewall/interfaces.bak >>>> Running /etc/shorewall/compile... >>>> Checking /etc/shorewall/zones... >>>> Checking /etc/shorewall/interfaces... >>>> >>>> >>> Well, it doesn''t work here. >>> >> >> I suspect that it is something about the file itself -- did you save a >> copy? >> >-bash-4.1# ls -las /etc/shorewall >8 drwx------. 3 root root 4096 May 25 16:50 . >[...] >8 -rw-------. 1 root root 1135 May 15 19:13 interfaces > >All files in /etc/shorewall have their permissions set at 600 (rw only >on owner). In addition, the whole /etc/ partition has "noexec" attribute >set in my fstab to prevent code being executed on that partition. > >-bash-4.1# cat /etc/shorewall/interfaces ># ># Shorewall version 4 - Interfaces File ># ># For information about entries in this file, type "man >shorewall-interfaces" ># ># The manpage is also online at ># http://www.shorewall.net/manpages/shorewall-interfaces.html ># >########################################################################## >##### >FORMAT 2 >########################################################################## >##### >#ZONE INTERFACE OPTIONS >[...] > > >So, on the face of it, nothing special apart from maybe the file >permissions.Please apply the attached debugging patch and post the output produced by ''update -D''. Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:>> I was right! It looks as though not all parts of the firewall file are >> executed when ifupdown-local gets started, as opposed to a direct >> "firewall start". Here is the diff produced before and after "shorewall >> reload" (I''ve omitted the counter differences and other such "noise"): >>Well, maybe not... I think I figured it out. I *do* have net.ipv4.ip_forward=0 in my /etc/sysctl.conf. Now, what I think is happening is that when the system brings all my devices up, "firewall" sets /proc/net.../ip_forward to 1, but then the sysctl.conf variable kicks in at the end of my system configuration/start up, reverting what shorewall have previously set up during the time when the network devices were brought up. Is that scenario feasible?>> ''local'' is/was a legitimate option in Beta2/3. >> > > Not it Beta 3. Again, ''local'' is a zone type. >Do I specify this in "OPTIONS", "IN OPTIONS" or "OUT OPTIONS"?>> May 25 17:06:12 test1 kernel: [ 85.305983] xt_CT: No such helper "ftp" >> May 25 17:06:12 test1 kernel: [ 85.369152] xt_CT: No such helper "ftp-0" >> May 25 17:06:12 test1 kernel: [ 85.426916] xt_CT: No such helper "irc" >> May 25 17:06:12 test1 kernel: [ 85.491393] xt_CT: No such helper "irc-0" >> May 25 17:06:12 test1 kernel: [ 85.550423] xt_CT: No such helper >> "amanda" >> >> /var/log/shorewall.log (shorewall startup log) >> ~~~~~~~~~~~~~~~~~~~~~~ >> May 25 17:06:09 Processing /etc/shorewall/start ... >> May 25 17:06:10 Processing /etc/shorewall/started ... >> >> /var/log/shorewall-ifupdown.log (shorewall-init log) >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> [...] >> May 25 17:05:54 /sbin/ifup-local: Executing /var/lib//shorewall/firewall >> -V0 up eth0 >> >> *** Note the times - it looks as though it happens at the very beginning >> (my guess is during shorewall compilation). >> > > The ''start'' and ''started scripts are run at the very end of the firewall > script''s execution. Again, I want to look at the ''firewall'' script. >I am assuming a similar thing is happening here. Although I do not have "net.netfilter.nf_conntrack_helper" set in my sysctl.conf (maybe I should explicitly disable it and set it to 0), I presume the "default" value if nothing specified is 1 (enabled). Shorewall has two places where it manipulates this variable: at start where it does "echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper", and then again, when the firewall is at stopped state it does the opposite - "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper". I notice that there isn''t a diagnostic message displayed when this operation is done - maybe it is a good idea for you to add one. If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all of the above messages (or if the system''s default value of "nf_conntrack_helper" is 1), then by simply adding "net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should eliminate these obnoxious messages appearing, correct?>>>>>> 6. "shorewall update -D" does not check all files in /etc/shorewall: >>>>>> >>>>>> Compiling /etc/shorewall/interfaces... >>>>>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>>>>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>>>>> >>>>>> -bash-4.1# shorewall update -D >>>>>> Updating... >>>>>> Processing /etc/shorewall/params ... >>>>>> Processing /etc/shorewall/shorewall.conf... >>>>>> No update required to configuration file >>>>>> /etc/shorewall/shorewall.conf; >>>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>>> >>>>>> "interfaces" is not changed (I had to do that manually). >>>>>> >>>>>> >>>>>> >>>>> Works for me. >>>>> >>>>> root@gateway:~# shorewall update -D >>>>> Updating... >>>>> Processing /etc/shorewall/params ... >>>>> Processing /etc/shorewall/shorewall.conf... >>>>> No update required to configuration file >>>>> /etc/shorewall/shorewall.conf; >>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>> Loading Modules... >>>>> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >>>>> File /etc/shorewall/interfaces updated - old file renamed >>>>> /etc/shorewall/interfaces.bak >>>>> Running /etc/shorewall/compile... >>>>> Checking /etc/shorewall/zones... >>>>> Checking /etc/shorewall/interfaces... >>>>> >>>>> >>>>> >>>> Well, it doesn''t work here. >>>> >>>> >>> I suspect that it is something about the file itself -- did you save a >>> copy? >>> >>> >> -bash-4.1# ls -las /etc/shorewall >> 8 drwx------. 3 root root 4096 May 25 16:50 . >> [...] >> 8 -rw-------. 1 root root 1135 May 15 19:13 interfaces >> >> All files in /etc/shorewall have their permissions set at 600 (rw only >> on owner). In addition, the whole /etc/ partition has "noexec" attribute >> set in my fstab to prevent code being executed on that partition. >> >> -bash-4.1# cat /etc/shorewall/interfaces >> # >> # Shorewall version 4 - Interfaces File >> # >> # For information about entries in this file, type "man >> shorewall-interfaces" >> # >> # The manpage is also online at >> # http://www.shorewall.net/manpages/shorewall-interfaces.html >> # >> ########################################################################## >> ##### >> FORMAT 2 >> ########################################################################## >> ##### >> #ZONE INTERFACE OPTIONS >> [...] >> >> >> So, on the face of it, nothing special apart from maybe the file >> permissions. >> > > Please apply the attached debugging patch and post the output produced by > ''update -D''. >Nada! Same result as before - with or without this patch. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> >> The ''start'' and ''started scripts are run at the very end of the firewall >> script''s execution. Again, I want to look at the ''firewall'' script. >> > I am assuming a similar thing is happening here. Although I do not > have "net.netfilter.nf_conntrack_helper" set in my sysctl.conf (maybe > I should explicitly disable it and set it to 0), I presume the > "default" value if nothing specified is 1 (enabled). Shorewall has two > places where it manipulates this variable: at start where it does > "echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper", and then > again, when the firewall is at stopped state it does the opposite - > "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper". I notice that > there isn''t a diagnostic message displayed when this operation is done > - maybe it is a good idea for you to add one. > > If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all > of the above messages (or if the system''s default value of > "nf_conntrack_helper" is 1), then by simply adding > "net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should > eliminate these obnoxious messages appearing, correct?I think this error comes from shorewall-init. When the system boots up, shorewall-init is first started before any of the interfaces or shorewall are brought up/started. shorewall-init compiles "firewall" *and* stops the firewall, triggering "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper". Since the "nf_conntrack_helper" is now in enabled state, when the interfaces are then brought up one by one by the system, this causes all of the messages to appear. This is self-evident from the repeated helper messages I enclosed previously - they repeat 3 times, which is exactly the number of devices I asked the OS to bring up at startup. Even if I explicitly disable the helpers in my sysctl.conf file, that won''t do me any good since the compiled "firewall" script explicitly enables my helpers when the firewall is stopped, which is wrong and should be corrected. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 2:37 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >>> I was right! It looks as though not all parts of the firewall file are >>> executed when ifupdown-local gets started, as opposed to a direct >>> "firewall start". Here is the diff produced before and after "shorewall >>> reload" (I''ve omitted the counter differences and other such "noise"): >>> >Well, maybe not... I think I figured it out. I *do* have >net.ipv4.ip_forward=0 in my /etc/sysctl.conf. Now, what I think is >happening is that when the system brings all my devices up, "firewall" >sets /proc/net.../ip_forward to 1, but then the sysctl.conf variable >kicks in at the end of my system configuration/start up, reverting what >shorewall have previously set up during the time when the network >devices were brought up. Is that scenario feasible?Yes.> >>> ''local'' is/was a legitimate option in Beta2/3. >>> >> >> Not it Beta 3. Again, ''local'' is a zone type. >> >Do I specify this in "OPTIONS", "IN OPTIONS" or "OUT OPTIONS"?It is a zone TYPE.> >>> May 25 17:06:12 test1 kernel: [ 85.305983] xt_CT: No such helper >>>"ftp" >>> May 25 17:06:12 test1 kernel: [ 85.369152] xt_CT: No such helper >>>"ftp-0" >>> May 25 17:06:12 test1 kernel: [ 85.426916] xt_CT: No such helper >>>"irc" >>> May 25 17:06:12 test1 kernel: [ 85.491393] xt_CT: No such helper >>>"irc-0" >>> May 25 17:06:12 test1 kernel: [ 85.550423] xt_CT: No such helper >>> "amanda" >>> >>> /var/log/shorewall.log (shorewall startup log) >>> ~~~~~~~~~~~~~~~~~~~~~~ >>> May 25 17:06:09 Processing /etc/shorewall/start ... >>> May 25 17:06:10 Processing /etc/shorewall/started ... >>> >>> /var/log/shorewall-ifupdown.log (shorewall-init log) >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> [...] >>> May 25 17:05:54 /sbin/ifup-local: Executing >>>/var/lib//shorewall/firewall >>> -V0 up eth0 >>> >>> *** Note the times - it looks as though it happens at the very >>>beginning >>> (my guess is during shorewall compilation). >>> >> >> The ''start'' and ''started scripts are run at the very end of the firewall >> script''s execution. Again, I want to look at the ''firewall'' script. >> >I am assuming a similar thing is happening here. Although I do not have >"net.netfilter.nf_conntrack_helper" set in my sysctl.conf (maybe I >should explicitly disable it and set it to 0), I presume the "default" >value if nothing specified is 1 (enabled).Yes.>Shorewall has two places >where it manipulates this variable: at start where it does "echo 0 > >/proc/sys/net/netfilter/nf_conntrack_helper", and then again, when the >firewall is at stopped state it does the opposite - "echo 1 > >/proc/sys/net/netfilter/nf_conntrack_helper". I notice that there isn''t >a diagnostic message displayed when this operation is done - maybe it is >a good idea for you to add one. > >If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all >of the above messages (or if the system''s default value of >"nf_conntrack_helper" is 1), then by simply adding >"net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should >eliminate these obnoxious messages appearing, correct?I frankly don''t know -- I suggest trying it and see.> >>>>>>> 6. "shorewall update -D" does not check all files in >>>>>>>/etc/shorewall: >>>>>>> >>>>>>> Compiling /etc/shorewall/interfaces... >>>>>>> WARNING: ''FORMAT'' is deprecated in favor of ''?FORMAT'' - consider >>>>>>> running ''shorewall update -D'' /etc/shorewall/interfaces (line 17) >>>>>>> >>>>>>> -bash-4.1# shorewall update -D >>>>>>> Updating... >>>>>>> Processing /etc/shorewall/params ... >>>>>>> Processing /etc/shorewall/shorewall.conf... >>>>>>> No update required to configuration file >>>>>>> /etc/shorewall/shorewall.conf; >>>>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>>>> >>>>>>> "interfaces" is not changed (I had to do that manually). >>>>>>> >>>>>>> >>>>>>> >>>>>> Works for me. >>>>>> >>>>>> root@gateway:~# shorewall update -D >>>>>> Updating... >>>>>> Processing /etc/shorewall/params ... >>>>>> Processing /etc/shorewall/shorewall.conf... >>>>>> No update required to configuration file >>>>>> /etc/shorewall/shorewall.conf; >>>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>>> Loading Modules... >>>>>> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >>>>>> File /etc/shorewall/interfaces updated - old file renamed >>>>>> /etc/shorewall/interfaces.bak >>>>>> Running /etc/shorewall/compile... >>>>>> Checking /etc/shorewall/zones... >>>>>> Checking /etc/shorewall/interfaces... >>>>>> >>>>>> >>>>>> >>>>> Well, it doesn''t work here. >>>>> >>>>> >>>> I suspect that it is something about the file itself -- did you save a >>>> copy? >>>> >>>> >>> -bash-4.1# ls -las /etc/shorewall >>> 8 drwx------. 3 root root 4096 May 25 16:50 . >>> [...] >>> 8 -rw-------. 1 root root 1135 May 15 19:13 interfaces >>> >>> All files in /etc/shorewall have their permissions set at 600 (rw only >>> on owner). In addition, the whole /etc/ partition has "noexec" >>>attribute >>> set in my fstab to prevent code being executed on that partition. >>> >>> -bash-4.1# cat /etc/shorewall/interfaces >>> # >>> # Shorewall version 4 - Interfaces File >>> # >>> # For information about entries in this file, type "man >>> shorewall-interfaces" >>> # >>> # The manpage is also online at >>> # http://www.shorewall.net/manpages/shorewall-interfaces.html >>> # >>> >>>######################################################################## >>>## >>> ##### >>> FORMAT 2 >>> >>>######################################################################## >>>## >>> ##### >>> #ZONE INTERFACE OPTIONS >>> [...] >>> >>> >>> So, on the face of it, nothing special apart from maybe the file >>> permissions. >>> >> >> Please apply the attached debugging patch and post the output produced >>by >> ''update -D''. >> >Nada! Same result as before - with or without this patch.What output did it produce? The patch adds diagnostic messages and warnings; it doesn''t change the logic. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:>> Well, maybe not... I think I figured it out. I *do* have >> net.ipv4.ip_forward=0 in my /etc/sysctl.conf. Now, what I think is >> happening is that when the system brings all my devices up, "firewall" >> sets /proc/net.../ip_forward to 1, but then the sysctl.conf variable >> kicks in at the end of my system configuration/start up, reverting what >> shorewall have previously set up during the time when the network >> devices were brought up. Is that scenario feasible? >> > > Yes. >I suppose the only way out of this is to explicitly enable ip forwarding via sysctl.conf. I''ll do that and see what happens.>>>> ''local'' is/was a legitimate option in Beta2/3. >>>> >>>> >>> Not it Beta 3. Again, ''local'' is a zone type. >>> >>> >> Do I specify this in "OPTIONS", "IN OPTIONS" or "OUT OPTIONS"? >> > > It is a zone TYPE. >Got it, thanks! So, instead of "ipv4" I need to specify "local" is that it? What happens if this zone is ipv6 (or does shorewall cares?)? I still need shorewall to "handle" this zone though - I don''t want it completely ignored.>> Shorewall has two places >> where it manipulates this variable: at start where it does "echo 0 > >> /proc/sys/net/netfilter/nf_conntrack_helper", and then again, when the >> firewall is at stopped state it does the opposite - "echo 1 > >> /proc/sys/net/netfilter/nf_conntrack_helper". I notice that there isn''t >> a diagnostic message displayed when this operation is done - maybe it is >> a good idea for you to add one. >> >> If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all >> of the above messages (or if the system''s default value of >> "nf_conntrack_helper" is 1), then by simply adding >> "net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should >> eliminate these obnoxious messages appearing, correct? >> > > I frankly don''t know -- I suggest trying it and see. >See what I already posted - I think it is to do with the fact that shorewall "assumes" that I have this enabled by default and sets it up when the firewall is in stopped state, which is wrong.> What output did it produce? The patch adds diagnostic messages and > warnings; it doesn''t change the logic. >Same as before: -bash-4.1# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved I did check that the patch was applied properly, before you ask (and no, /etc/shorewall/interfaces is *not* updated). ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 3:14 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> >>> The ''start'' and ''started scripts are run at the very end of the >>>firewall >>> script''s execution. Again, I want to look at the ''firewall'' script. >>> >> I am assuming a similar thing is happening here. Although I do not >> have "net.netfilter.nf_conntrack_helper" set in my sysctl.conf (maybe >> I should explicitly disable it and set it to 0), I presume the >> "default" value if nothing specified is 1 (enabled). Shorewall has two >> places where it manipulates this variable: at start where it does >> "echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper", and then >> again, when the firewall is at stopped state it does the opposite - >> "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper". I notice that >> there isn''t a diagnostic message displayed when this operation is done >> - maybe it is a good idea for you to add one. >> >> If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all >> of the above messages (or if the system''s default value of >> "nf_conntrack_helper" is 1), then by simply adding >> "net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should >> eliminate these obnoxious messages appearing, correct? >I think this error comes from shorewall-init. > >When the system boots up, shorewall-init is first started before any of >the interfaces or shorewall are brought up/started. shorewall-init >compiles "firewall" *and* stops the firewall, triggering "echo 1 > >/proc/sys/net/netfilter/nf_conntrack_helper". Since the >"nf_conntrack_helper" is now in enabled state, when the interfaces are >then brought up one by one by the system, this causes all of the >messages to appear. This is self-evident from the repeated helper >messages I enclosed previously - they repeat 3 times, which is exactly >the number of devices I asked the OS to bring up at startup. > >Even if I explicitly disable the helpers in my sysctl.conf file, that >won''t do me any good since the compiled "firewall" script explicitly >enables my helpers when the firewall is stopped, which is wrong and >should be corrected.Patch attached. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 3:45 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >>> Well, maybe not... I think I figured it out. I *do* have >>> net.ipv4.ip_forward=0 in my /etc/sysctl.conf. Now, what I think is >>> happening is that when the system brings all my devices up, "firewall" >>> sets /proc/net.../ip_forward to 1, but then the sysctl.conf variable >>> kicks in at the end of my system configuration/start up, reverting what >>> shorewall have previously set up during the time when the network >>> devices were brought up. Is that scenario feasible? >>> >> >> Yes. >> >I suppose the only way out of this is to explicitly enable ip forwarding >via sysctl.conf. I''ll do that and see what happens.Good plan.> >>>>> ''local'' is/was a legitimate option in Beta2/3. >>>>> >>>>> >>>> Not it Beta 3. Again, ''local'' is a zone type. >>>> >>>> >>> Do I specify this in "OPTIONS", "IN OPTIONS" or "OUT OPTIONS"? >>> >> >> It is a zone TYPE. >> >Got it, thanks! So, instead of "ipv4" I need to specify "local" is that >it? What happens if this zone is ipv6 (or does shorewall cares?)? I >still need shorewall to "handle" this zone though - I don''t want it >completely ignored.Shorewall doesn''t restrict IPv6 at all, provided that you have DISABLE_IPV6=No in shorewall.conf. (that is Shorewall6''s job).> >>> Shorewall has two places >>> where it manipulates this variable: at start where it does "echo 0 > >>> /proc/sys/net/netfilter/nf_conntrack_helper", and then again, when the >>> firewall is at stopped state it does the opposite - "echo 1 > >>> /proc/sys/net/netfilter/nf_conntrack_helper". I notice that there isn''t >>> a diagnostic message displayed when this operation is done - maybe it >>>is >>> a good idea for you to add one. >>> >>> If "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper" triggers all >>> of the above messages (or if the system''s default value of >>> "nf_conntrack_helper" is 1), then by simply adding >>> "net.netfilter.nf_conntrack_helper=0" to my sysctl.conf file should >>> eliminate these obnoxious messages appearing, correct? >>> >> >> I frankly don''t know -- I suggest trying it and see. >> >See what I already posted - I think it is to do with the fact that >shorewall "assumes" that I have this enabled by default and sets it up >when the firewall is in stopped state, which is wrong. > >> What output did it produce? The patch adds diagnostic messages and >> warnings; it doesn''t change the logic. >> >Same as before: > >-bash-4.1# shorewall update -D >Updating... >Processing /etc/shorewall/params ... >Processing /etc/shorewall/shorewall.conf... >No update required to configuration file /etc/shorewall/shorewall.conf; >/etc/shorewall/shorewall.conf.bak not saved > >I did check that the patch was applied properly, before you ask (and no, >/etc/shorewall/interfaces is *not* updated).Please post *all* of the output of ''shorewall update -D''. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:>>> What output did it produce? The patch adds diagnostic messages and >>> warnings; it doesn''t change the logic. >>> >>> >> Same as before: >> >> -bash-4.1# shorewall update -D >> Updating... >> Processing /etc/shorewall/params ... >> Processing /etc/shorewall/shorewall.conf... >> No update required to configuration file /etc/shorewall/shorewall.conf; >> /etc/shorewall/shorewall.conf.bak not saved >> >> I did check that the patch was applied properly, before you ask (and no, >> /etc/shorewall/interfaces is *not* updated). >> > > Please post *all* of the output of ''shorewall update -D''. >I''ve already posted *all* of the output I do get when executing "shorewall update -D" - see above, I am not making stuff up! ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 3:55 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >>>> What output did it produce? The patch adds diagnostic messages and >>>> warnings; it doesn''t change the logic. >>>> >>>> >>> Same as before: >>> >>> -bash-4.1# shorewall update -D >>> Updating... >>> Processing /etc/shorewall/params ... >>> Processing /etc/shorewall/shorewall.conf... >>> No update required to configuration file /etc/shorewall/shorewall.conf; >>> /etc/shorewall/shorewall.conf.bak not saved >>> >>> I did check that the patch was applied properly, before you ask (and >>>no, >>> /etc/shorewall/interfaces is *not* updated). >>> >> >> Please post *all* of the output of ''shorewall update -D''. >> >I''ve already posted *all* of the output I do get when executing >"shorewall update -D" - see above, I am not making stuff up! >You don''t see a line like this further down in the output? Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/25/13 3:55 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >> Tom Eastep wrote: >> >>>>> What output did it produce? The patch adds diagnostic messages and >>>>> warnings; it doesn''t change the logic. >>>>> >>>>> >>>>> >>>> Same as before: >>>> >>>> -bash-4.1# shorewall update -D >>>> Updating... >>>> Processing /etc/shorewall/params ... >>>> Processing /etc/shorewall/shorewall.conf... >>>> No update required to configuration file /etc/shorewall/shorewall.conf; >>>> /etc/shorewall/shorewall.conf.bak not saved >>>> >>>> I did check that the patch was applied properly, before you ask (and >>>> no, >>>> /etc/shorewall/interfaces is *not* updated). >>>> >>>> >>> Please post *all* of the output of ''shorewall update -D''. >>> >>> >> I''ve already posted *all* of the output I do get when executing >> "shorewall update -D" - see above, I am not making stuff up! >> >> > > You don''t see a line like this further down in the output? > > Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >-bash-4.1# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved -bash-4.1# ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 4:03 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 5/25/13 3:55 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>> Tom Eastep wrote: >>> >>>>>> What output did it produce? The patch adds diagnostic messages and >>>>>> warnings; it doesn''t change the logic. >>>>>> >>>>>> >>>>>> >>>>> Same as before: >>>>> >>>>> -bash-4.1# shorewall update -D >>>>> Updating... >>>>> Processing /etc/shorewall/params ... >>>>> Processing /etc/shorewall/shorewall.conf... >>>>> No update required to configuration file >>>>>/etc/shorewall/shorewall.conf; >>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>> >>>>> I did check that the patch was applied properly, before you ask (and >>>>> no, >>>>> /etc/shorewall/interfaces is *not* updated). >>>>> >>>>> >>>> Please post *all* of the output of ''shorewall update -D''. >>>> >>>> >>> I''ve already posted *all* of the output I do get when executing >>> "shorewall update -D" - see above, I am not making stuff up! >>> >>> >> >> You don''t see a line like this further down in the output? >> >> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >> >-bash-4.1# shorewall update -D >Updating... >Processing /etc/shorewall/params ... >Processing /etc/shorewall/shorewall.conf... >No update required to configuration file /etc/shorewall/shorewall.conf; >/etc/shorewall/shorewall.conf.bak not saved >-bash-4.1#Please install the attached Config.pm; it should solve the issue. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/25/13 4:03 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >> Tom Eastep wrote: >> >>> On 5/25/13 3:55 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>> >>> >>>> Tom Eastep wrote: >>>> >>>> >>>>>>> What output did it produce? The patch adds diagnostic messages and >>>>>>> warnings; it doesn''t change the logic. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Same as before: >>>>>> >>>>>> -bash-4.1# shorewall update -D >>>>>> Updating... >>>>>> Processing /etc/shorewall/params ... >>>>>> Processing /etc/shorewall/shorewall.conf... >>>>>> No update required to configuration file >>>>>> /etc/shorewall/shorewall.conf; >>>>>> /etc/shorewall/shorewall.conf.bak not saved >>>>>> >>>>>> I did check that the patch was applied properly, before you ask (and >>>>>> no, >>>>>> /etc/shorewall/interfaces is *not* updated). >>>>>> >>>>>> >>>>>> >>>>> Please post *all* of the output of ''shorewall update -D''. >>>>> >>>>> >>>>> >>>> I''ve already posted *all* of the output I do get when executing >>>> "shorewall update -D" - see above, I am not making stuff up! >>>> >>>> >>>> >>> You don''t see a line like this further down in the output? >>> >>> Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... >>> >>> >> -bash-4.1# shorewall update -D >> Updating... >> Processing /etc/shorewall/params ... >> Processing /etc/shorewall/shorewall.conf... >> No update required to configuration file /etc/shorewall/shorewall.conf; >> /etc/shorewall/shorewall.conf.bak not saved >> -bash-4.1# >> > > Please install the attached Config.pm; it should solve the issue. >Much better: -bash-4.1# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved Loading Modules... Converting ''FORMAT'' and ''COMMENT'' lines to compiler directives... File /etc/shorewall/interfaces updated - old file renamed /etc/shorewall/interfaces.bak [...] Shorewall configuration verified and my "interfaces" is now updated. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may