On 5/17/13 4:01 PM, "Dash Four" <[email protected]> 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 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
