I am testing Shorewall-perl-4.0.4 with Shorewall-lite-4.0.4 to replace my large and very slow to start Shorewall-2.0.7 configuration. Compilation succeeds marvelously quickly, but running "shorewall-lite start" gives a failure of iptables-restore, on the final COMMIT line of the .iptables-restore-input file. I have attached the output of "shorewall-lite trace start", and on a hunch the capabilities file, and I am sending the compiled firewall script to the support address. -- John K. Hohm <jhohm@acm.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> I am testing Shorewall-perl-4.0.4 with Shorewall-lite-4.0.4 to replace my > large and very slow to start Shorewall-2.0.7 configuration. Compilation > succeeds marvelously quickly, but running "shorewall-lite start" gives a > failure of iptables-restore, on the final COMMIT line of > the .iptables-restore-input file. > > I have attached the output of "shorewall-lite trace start", and on a hunch the > capabilities file, and I am sending the compiled firewall script to the > support address.Does this also fail if you compile with the Shorewall-shell compiler? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> I am testing Shorewall-perl-4.0.4 with Shorewall-lite-4.0.4 to replace my > large and very slow to start Shorewall-2.0.7 configuration. Compilation > succeeds marvelously quickly, but running "shorewall-lite start" gives a > failure of iptables-restore, on the final COMMIT line of > the .iptables-restore-input file. > > I have attached the output of "shorewall-lite trace start", and on a hunch the > capabilities file, and I am sending the compiled firewall script to the > support address. > >John, You can disregard my private-mail request for the failing .iptables_restore_input file. I was able to hack up the firewall script so that it would run here (replaced ''cir0'' by ''eth0'' as an argument to find_first_interface_address() and ran the script with the -n option so that it wouldn''t try to install your providers into the routing configuration). And it _did_ run to completion. So: a) Shorewall-perl appears to be generating a valid Netfilter ruleset. b) There is apparently something different about your Netfilter installation and mine. I tested on Ubuntu Feisty Fawn and on OpenSuSE 10.2. Kernel versions are 2.6.20 on Ubuntu and 2.6.18 on OpenSuSE. Both run iptables 1.3.8. I had asked you by private mail if Shorewall-shell 4.0.4 also fails; if so, that would give us a clue as to what the problem is. I''ve not heard back from you. If Shorewall-shell does not fail, then please let us know and I''ll put together a script that will convert the .iptables_restore_input file into individual iptables commands and we can see if that fails. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> On Friday 05 October 2007 09:13:44 you wrote: >> John, >> >> Please send me the .iptables-restore-input file that is causing this >> problem. > > Here you go, Tom. Thanks for looking into this. >Thanks John, This confirms my test using your firewall script (see my message on the Users list). Here are the differences between your .iptables_restore_input file and mine: --- iptables-restore-input 2007-10-05 09:20:26.000000000 -0700 +++ iptables-restore-input2 2007-10-05 09:21:58.000000000 -0700 @@ -4851,7 +4851,8 @@ -A dmz2wls -p icmp --icmp-type 8 -s 172.16.2.210 -j ACCEPT -A dmz2wls -p 17 --dport 161:162 -s 172.16.2.210 -j ACCEPT -A dmz2wls -p 6 --dport 161 -s 172.16.2.210 -j ACCEPT --A dropBcast -d 10.0.2.255 -j DROP +-A dropBcast -d 169.254.255.255 -j DROP +-A dropBcast -d 192.168.1.255 -j DROP -A dropBcast -d 255.255.255.255 -j DROP -A dropBcast -d 224.0.0.0/4 -j DROP -A dropInvalid -m state --state INVALID -j DROP @@ -7193,7 +7194,8 @@ -A pp2vw -p 6 --dport 25 -s 192.168.25.5 -j ACCEPT -A pp2vwf -p 6 --dport 25 -s 192.168.25.5 -j ACCEPT -A pp2wls -p 6 --dport 25 -s 192.168.25.5 -j ACCEPT --A reject -d 10.0.2.255 -j DROP +-A reject -d 169.254.255.255 -j DROP +-A reject -d 192.168.1.255 -j DROP -A reject -d 255.255.255.255 -j DROP -A reject -s 224.0.0.0/4 -j DROP -A reject -p tcp -j REJECT --reject-with tcp-reset @@ -7891,8 +7893,10 @@ -A rp2vhra -p 6 --dport 110 -d 10.1.1.100 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT -A rp2vhra -p 6 --dport 3389 -d 10.1.1.100 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT -A rp2vhra -p 6 --dport 25 -d 10.1.1.100 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT --A smurfs -s 10.0.2.255 -j LOG --log-level 6 --log-prefix "Shorewall:smurfs:DROP:" --A smurfs -s 10.0.2.255 -j DROP +-A smurfs -s 169.254.255.255 -j LOG --log-level 6 --log-prefix "Shorewall:smurfs:DROP:" +-A smurfs -s 169.254.255.255 -j DROP +-A smurfs -s 192.168.1.255 -j LOG --log-level 6 --log-prefix "Shorewall:smurfs:DROP:" +-A smurfs -s 192.168.1.255 -j DROP -A smurfs -s 255.255.255.255 -j LOG --log-level 6 --log-prefix "Shorewall:smurfs:DROP:" -A smurfs -s 255.255.255.255 -j DROP -A smurfs -s 224.0.0.0/4 -j LOG --log-level 6 --log-prefix "Shorewall:smurfs:DROP:" teastep@wookie:~/Hohm$ As you can see, the only differences are in the Broadcast addresses. Please see my message to the list for additional information. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm
2007-Oct-05 18:39 UTC
Re: shorewall-lite start gives iptables-restore failure
On Fri, 05 Oct 2007 08:13:46 -0700 Tom Eastep <teastep@shorewall.net> wrote:> b) There is apparently something different about your Netfilter > installation and mine. I tested on Ubuntu Feisty Fawn and on OpenSuSE > 10.2. Kernel versions are 2.6.20 on Ubuntu and 2.6.18 on OpenSuSE. > Both run iptables 1.3.8.I''m using LEAF Bering-uClibc 3.0.2, kernel 2.4.33, iptables v1.3.5.> I had asked you by private mail if Shorewall-shell 4.0.4 also fails; > if so, that would give us a clue as to what the problem is. I''ve not > heard back from you. If Shorewall-shell does not fail, then please > let us know and I''ll put together a script that will convert > the .iptables_restore_input file into individual iptables commands > and we can see if that fails.It did fail, and I will send a full compressed trace privately, but the interesting part I suppose is the last 23 lines, attached. -- John K. Hohm <jhohm@acm.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield
2007-Oct-05 19:04 UTC
Re: shorewall-lite start gives iptables-restore failure
On Fri, Oct 05, 2007 at 01:39:26PM -0500, John K. Hohm wrote:> + /sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT > iptables: Unknown error -1That''s a double fault message - the real error was eaten inside iptables. I believe that''s netfilter bug #460, fixed in iptables 1.3.6. The cause is most likely that the kernel itself rejected this rule, for some reason. Check dmesg for errors, although there may not be any. You may be looking at a set of arguments that are accepted by your (recent-ish) iptables version, but rejected by your (old) kernel netfilter version. Alternatively, there could be something wrong with those arguments that I''m just not seeing (like a bogus IP address - those are both host addresses from your system''s perspective, right?). ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Fri, Oct 05, 2007 at 01:39:26PM -0500, John K. Hohm wrote: >> + /sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT >> iptables: Unknown error -1 > > That''s a double fault message - the real error was eaten inside > iptables. I believe that''s netfilter bug #460, fixed in iptables > 1.3.6. > > The cause is most likely that the kernel itself rejected this rule, > for some reason. Check dmesg for errors, although there may not be > any. You may be looking at a set of arguments that are accepted by > your (recent-ish) iptables version, but rejected by your (old) kernel > netfilter version. Alternatively, there could be something wrong with > those arguments that I''m just not seeing (like a bogus IP address - > those are both host addresses from your system''s perspective, right?). >It''s a perfectly valid iptables command which both my Ubuntu and OpenSuSE systems are happy with. I too recommend looking at the system log for clues. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> + run_iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT > + [ -n ] > + /sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT > iptables: Unknown error -1 > + [ 1 -ne 0 ] > + error_message ERROR: Command "/sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT" Failed > + echo ERROR: Command "/sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT" Failed > ERROR: Command "/sbin/iptables -A net2vhra -p tcp -d 10.1.1.100 --dport 80 -m conntrack --ctorigdst 216.132.159.100 -j ACCEPT" Failed > + stop_firewall > + set +x > TerminatedIf you don''t find anything helpful in your log, you might try changing CONNTRACK_MATCH=Yes to CONNTRACK_MATCH in your capabilities file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> On Fri, 05 Oct 2007 08:13:46 -0700 > Tom Eastep <teastep@shorewall.net> wrote: >> b) There is apparently something different about your Netfilter >> installation and mine. I tested on Ubuntu Feisty Fawn and on OpenSuSE >> 10.2. Kernel versions are 2.6.20 on Ubuntu and 2.6.18 on OpenSuSE. >> Both run iptables 1.3.8. > > I''m using LEAF Bering-uClibc 3.0.2, kernel 2.4.33, iptables v1.3.5. > >> I had asked you by private mail if Shorewall-shell 4.0.4 also fails; >> if so, that would give us a clue as to what the problem is. I''ve not >> heard back from you. If Shorewall-shell does not fail, then please >> let us know and I''ll put together a script that will convert >> the .iptables_restore_input file into individual iptables commands >> and we can see if that fails. > > It did fail, and I will send a full compressed trace privately, but the > interesting part I suppose is the last 23 lines, attached. >As a result of this and similar failures, the following change will be in Shorewall 4.0.5. ------------------------------------------------------------------------- 6) There have been several cases where iptables-restore has failed while executing a COMMIT command in the .iptables_restore_input file. This gives neither the user nor Shorewall support much to go on when analyzing the problem. As a new debugging aid, the meaning of ''trace'' and ''debug'' have been changed. Traditionally, /sbin/shorewall and /sbin/shorewall-lite have allowed either ''trace'' or ''debug'' as the first run-line parameter. Prior to 4.0.5, the two words produced the same effect. Beginning with Shorewall 4.0.5, the two words have different effects when Shorewall-perl is used. trace - Like the previous behavior. In the Shorewall-perl compiler, generate a stack trace on WARNING and ERROR messages. In the generated script, set the shell''s -x option to trace execution of the script. debug - Ignored by the Shorewall-perl compiler. In the generated script, causes the commands in .iptables_restore_input to be executed as descrete iptables commands. The failing command can thus be identified and a diagnosis of the cause can be made. Users of Shorewall-shell will see no change in behavior. ------------------------------------------------------------------------- -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> John K. Hohm wrote: >> On Fri, 05 Oct 2007 08:13:46 -0700 >> Tom Eastep <teastep@shorewall.net> wrote: >>> b) There is apparently something different about your Netfilter >>> installation and mine. I tested on Ubuntu Feisty Fawn and on OpenSuSE >>> 10.2. Kernel versions are 2.6.20 on Ubuntu and 2.6.18 on OpenSuSE. >>> Both run iptables 1.3.8. >> I''m using LEAF Bering-uClibc 3.0.2, kernel 2.4.33, iptables v1.3.5. >> >>> I had asked you by private mail if Shorewall-shell 4.0.4 also fails; >>> if so, that would give us a clue as to what the problem is. I''ve not >>> heard back from you. If Shorewall-shell does not fail, then please >>> let us know and I''ll put together a script that will convert >>> the .iptables_restore_input file into individual iptables commands >>> and we can see if that fails. >> It did fail, and I will send a full compressed trace privately, but the >> interesting part I suppose is the last 23 lines, attached. >> > > As a result of this and similar failures, the following change will be in > Shorewall 4.0.5. > ------------------------------------------------------------------------- > 6) There have been several cases where iptables-restore has failed > while executing a COMMIT command in the .iptables_restore_input > file. This gives neither the user nor Shorewall support much to go > on when analyzing the problem. As a new debugging aid, the meaning > of ''trace'' and ''debug'' have been changed. > > Traditionally, /sbin/shorewall and /sbin/shorewall-lite have > allowed either ''trace'' or ''debug'' as the first run-line > parameter. Prior to 4.0.5, the two words produced the same effect. > > Beginning with Shorewall 4.0.5, the two words have different > effects when Shorewall-perl is used. > > trace - Like the previous behavior. > > In the Shorewall-perl compiler, generate a stack trace > on WARNING and ERROR messages. > > In the generated script, set the shell''s -x option to trace > execution of the script. > > debug - Ignored by the Shorewall-perl compiler. > > In the generated script, causes the commands in > .iptables_restore_input to be executed as descrete iptablesGroan -- descrete should be discrete. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm
2007-Oct-05 20:40 UTC
Re: shorewall-lite start gives iptables-restore failure
On Fri, 05 Oct 2007 12:44:23 -0700 Tom Eastep <teastep@shorewall.net> wrote:> If you don''t find anything helpful in your log, you might try changing > > CONNTRACK_MATCH=Yes > > to > > CONNTRACK_MATCH> > in your capabilities file.I found nothing in my logs or in dmesg output, but unsetting CONNTRACK_MATCH in capabilities and recompiling indeed makes shorewall-lite start work. This is good since it even works with shorewall-perl, which is *very* much faster, both in compiling and in starting the resulting script. Thanks, that''s wonderful. I am curious, though, why it doesn''t work with CONNTRACK_MATCH=Yes, since that was detected as being available (as I would expect it to be with ipt_conntrack loaded). -- John K. Hohm <jhohm@acm.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield
2007-Oct-05 20:45 UTC
Re: shorewall-lite start gives iptables-restore failure
On Fri, Oct 05, 2007 at 03:40:40PM -0500, John K. Hohm wrote:> On Fri, 05 Oct 2007 12:44:23 -0700 > Tom Eastep <teastep@shorewall.net> wrote: > > > If you don''t find anything helpful in your log, you might try changing > > > > CONNTRACK_MATCH=Yes > > > > to > > > > CONNTRACK_MATCH> > > > in your capabilities file. > > I found nothing in my logs or in dmesg output, but unsetting > CONNTRACK_MATCH in capabilities and recompiling indeed makes > shorewall-lite start work. This is good since it even works with > shorewall-perl, which is *very* much faster, both in compiling and in > starting the resulting script. > > Thanks, that''s wonderful. I am curious, though, why it doesn''t work > with CONNTRACK_MATCH=Yes, since that was detected as being available (as > I would expect it to be with ipt_conntrack loaded).Another theory: your iptables and kernel versions were compiled against different versions of ipt_conntrack.h, and they are unable to communicate successfully with each other about the conntrack match. The solution here would be to rebuild iptables against your current kernel. If both came from your vendor than it''s their problem; if you rebuilt one but not the other, that''ll be the cause. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm wrote:> On Fri, 05 Oct 2007 12:44:23 -0700 > Tom Eastep <teastep@shorewall.net> wrote: > >> If you don''t find anything helpful in your log, you might try changing >> >> CONNTRACK_MATCH=Yes >> >> to >> >> CONNTRACK_MATCH>> >> in your capabilities file. > > I found nothing in my logs or in dmesg output, but unsetting > CONNTRACK_MATCH in capabilities and recompiling indeed makes > shorewall-lite start work. This is good since it even works with > shorewall-perl, which is *very* much faster, both in compiling and in > starting the resulting script. > > Thanks, that''s wonderful. I am curious, though, why it doesn''t work > with CONNTRACK_MATCH=Yes, since that was detected as being available (as > I would expect it to be with ipt_conntrack loaded). >Don''t know -- the command that Shorewall issues to detect the capability is very similar to the one which failed: $IPTABLES -A fooX1234 -m conntrack --ctorigdst 192.168.1.1 -j ACCEPT Don''t know if upgrading to the latest uClibc-Bering release will fix this or not. But, IMHO, running a 2.4 kernel with Netfilter is likely to get worse from now on rather than better. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John K. Hohm
2007-Oct-08 15:40 UTC
Re: shorewall-lite start gives iptables-restore failure
On Fri, 05 Oct 2007 13:47:41 -0700 Tom Eastep <teastep@shorewall.net> wrote:> Don''t know if upgrading to the latest uClibc-Bering release will fix > this or not.Bering-uClibc 3.0.2 *is* the latest stable release, which I was using to test the latest Shorewall. I copied our working firewall setup, running a tweaked Bering-uClibc 2.2 (c. 2004) with kernel 2.4.26 and iptables v1.2.11, to a test environment where I tried the same shorewall-4.0.4 configuration. The "shorewall-lite start" succeeds there, even on a shorewall-perl compiled script with CONNTRACK_MATCH=Yes. Apparently this indicates a regression in Bering-uClibc which I should report to the fine LEAF folks.> But, IMHO, running a 2.4 kernel with Netfilter is likely to get worse > from now on rather than better.Fair enough. I think I better start a new thread to ask advice on getting away from the 2.4 kernel. -- John K. Hohm <jhohm@acm.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/