On 5/25/13 10:59 AM, "Dash Four" <[email protected]> wrote:

>
>Tom Eastep wrote:
>> 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.
>>   
>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
>([email protected]) (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.



Attachment: DEBUGUPDATE.patch
Description: Binary data

------------------------------------------------------------------------------
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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel

Reply via email to