In helping a user on IRC today, I was dismayed to find that a bug that was supposedly fixed in Shorewall 3.4.4 was not fixed. Furthermore, I found that the bug is present as far back as 3.2.6 (I didn''t look back further since 3.2.6 was the release where the user (re-) discovered the bug. If HIGH_ROUTE_MARKS=No, then PREROUTING and OUTPUT marking rules are behaving as if TC_EXPERT=Yes was specified in shorewall.conf. In other words, these rules are being applied even if the connection has been marked as being associated with a particular ISP. The symptoms in this users case were that requests through ISP1 that were port-forwarded to an SMTP server were being replied through ISP2. The reason was that there was a tcrule which selected ISP2 for all connections from the SMTP server. I''ve prepared errata patches as follows: http://www1.shorewall.net/pub/shorewall/3.2/shorewall-3.2.10/errata/patches/Shorewall/patch-3.2.10-2.diff http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.6/errata/patches/Shorewall/patch-3.4.6-1.diff http://www1.shorewall.net/pub/shorewall/4.0/shorewall-4.0.2/errata/patches/Shorewall-shell/patch-shell-4.0.2-2.diff The 3.2.10 patch applies to all 3.2 releases from at least 3.2.6 onward and to 3.4 releases 3.4.0-3.4.3 (with offset). The 3.4.6 patch will also work on 3.4.4 and 3.4.5 (again, with possible offset). It is also possible to work around the problem by adding these two rules at the beginning of your tcrules file: CONTINUE:P 0.0.0.0/0 0.0.0.0/0 - - - - !0 CONTINUE $FW 0.0.0.0/0 - - - - !0 -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/
On Wed, 22 Aug 2007 08:24:49 am Tom Eastep wrote:> In helping a user on IRC today, I was dismayed to find that a bug that > was supposedly fixed in Shorewall 3.4.4 was not fixed. Furthermore, I > found that the bug is present as far back as 3.2.6 (I didn''t look back > further since 3.2.6 was the release where the user (re-) discovered the > bug. > > If HIGH_ROUTE_MARKS=No, then PREROUTING and OUTPUT marking rules are > behaving as if TC_EXPERT=Yes was specified in shorewall.conf. In other > words, these rules are being applied even if the connection has been > marked as being associated with a particular ISP.Thanks for the patches Tom. Are you releasing a new 3.4? Just curious as it would make my version-management easier than rolling my own (patched) RPM. Furthermore, the behaviour described seems to reflect the battles I''ve had over the last few days with my multi-ISP setup with HIGH_ROUTE_MARKS=No. Problem disappeared when I started using high route marks in PREROUTING. Cheers, James -- Anyone stupid enough to be caught by the police is probably guilty. ------------------------------------------------------------------------- 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/
James Gray wrote:> On Wed, 22 Aug 2007 08:24:49 am Tom Eastep wrote: >> In helping a user on IRC today, I was dismayed to find that a bug that >> was supposedly fixed in Shorewall 3.4.4 was not fixed. Furthermore, I >> found that the bug is present as far back as 3.2.6 (I didn''t look back >> further since 3.2.6 was the release where the user (re-) discovered the >> bug. >> >> If HIGH_ROUTE_MARKS=No, then PREROUTING and OUTPUT marking rules are >> behaving as if TC_EXPERT=Yes was specified in shorewall.conf. In other >> words, these rules are being applied even if the connection has been >> marked as being associated with a particular ISP. > > Thanks for the patches Tom. Are you releasing a new 3.4?Not for several weeks. -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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Gray wrote:> Thanks for the patches Tom. Are you releasing a new 3.4? Just curious as it > would make my version-management easier than rolling my own (patched) RPM. > Furthermore, the behaviour described seems to reflect the battles I''ve had > over the last few days with my multi-ISP setup with HIGH_ROUTE_MARKS=No. > Problem disappeared when I started using high route marks in PREROUTING.I see no reason to stick with 3.4 series when shorewall-shell-4.0.2 is nearly 100% identical with latest 3.4 series release. I''d make supporting 3.4 versions questionable because only real changes to shorewall-shell-4 and shorewall-common-4 are packaging related. - -- Tuomo Soini <tis@foobar.fi> Linux and network services +358 40 5240030 Foobar Oy <http://foobar.fi/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGzWpwTlrZKzwul1ERAtbfAJ9illgOI7Rb63/t4p7Opa5v2TqhdQCglWTq +BzA8FtI91JEE9cVRoiXlEQ=KNHn -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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/
Tuomo Soini wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > James Gray wrote: > >> Thanks for the patches Tom. Are you releasing a new 3.4? Just curious as it >> would make my version-management easier than rolling my own (patched) RPM. >> Furthermore, the behaviour described seems to reflect the battles I''ve had >> over the last few days with my multi-ISP setup with HIGH_ROUTE_MARKS=No. >> Problem disappeared when I started using high route marks in PREROUTING. > > I see no reason to stick with 3.4 series when shorewall-shell-4.0.2 is > nearly 100% identical with latest 3.4 series release."Nearly 100%"...yes. Try up-selling that to management who wont even give me 15 minutes of downtime on a weekend :P -- James ------------------------------------------------------------------------- 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/
On Fri, 2007-08-24 at 12:20 +1000, James Gray wrote:> > > "Nearly 100%"...yes. Try up-selling that to management who wont even > give me 15 minutes of downtime on a weekend :P >If your management demands that level of up-time then they surely must provide you with one or more test firewalls where you can verify new software releases in a semi-live environment. And even if the misers don''t do that for you, you are running Shorewall 3.4; so you can: shorewall compile <configuration> <firewall-a> #under shorewall 3.4 and shorewall compile <configuration> <firewall-b> #under shorewall 4.0 then: diff -au <firewall-a> <firewall-b> This firewall stuff really isn''t as complicated as brain surgery.... -Tom (who has worked in the ultra high-availability market sector since 1980). -- 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/
On Thu, Aug 23, 2007 at 07:36:14PM -0700, Tom Eastep wrote:> On Fri, 2007-08-24 at 12:20 +1000, James Gray wrote: > > > > > > > "Nearly 100%"...yes. Try up-selling that to management who wont even > > give me 15 minutes of downtime on a weekend :P > > > > If your management demands that level of up-time then they surely must > provide you with one or more test firewalls where you can verify new > software releases in a semi-live environment. > > And even if the misers don''t do that for you, you are running Shorewall > 3.4; so you can: > > shorewall compile <configuration> <firewall-a> #under shorewall 3.4 > > and > > shorewall compile <configuration> <firewall-b> #under shorewall 4.0 > > then: > > diff -au <firewall-a> <firewall-b> > > This firewall stuff really isn''t as complicated as brain surgery.... > > -Tom (who has worked in the ultra high-availability market sector since > 1980).Besides, hardware is cheap. Have them get you a box on which you can install Xen, then setup some domUs in a configuration that you can test your firewall. Identify some "critical" tasks or functions and make sure that those work. If your management has a problem spending money on that, figure out how much an hour or a day of downtime costs them and then have them compare that to the price of a single machine. Besides, a machine that can run Xen for the testing you need can easily be had for under US$3000. If they still don''t budge, then I recommend you send your story to the folks over at http://worsethanfailure.com :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- 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/
On Thu, Aug 23, 2007 at 10:51:52PM -0400, Roberto C. S?nchez wrote:> On Thu, Aug 23, 2007 at 07:36:14PM -0700, Tom Eastep wrote: > > On Fri, 2007-08-24 at 12:20 +1000, James Gray wrote: > > > "Nearly 100%"...yes. Try up-selling that to management who wont even > > > give me 15 minutes of downtime on a weekend :P > > > > > > > If your management demands that level of up-time then they surely must > > provide you with one or more test firewalls where you can verify new > > software releases in a semi-live environment. > > Besides, hardware is cheap. Have them get you a box on which you can > install Xen, then setup some domUs in a configuration that you can test > your firewall. Identify some "critical" tasks or functions and make > sure that those work. If your management has a problem spending money > on that, figure out how much an hour or a day of downtime costs them and > then have them compare that to the price of a single machine. Besides, > a machine that can run Xen for the testing you need can easily be had > for under US$3000.And for yet another option, with a managed (vlan-capable) switch and a second box you can easily create a failover firewall (which is necessary for that kind of uptime anyway - all hardware dies sooner or later), and by switching them around you get more or less no downtime while upgrading, along with an easy way to move back to the old version if it''s wrong. ------------------------------------------------------------------------- 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:> On Fri, 2007-08-24 at 12:20 +1000, James Gray wrote: > >> >> "Nearly 100%"...yes. Try up-selling that to management who wont even >> give me 15 minutes of downtime on a weekend :P >> > > If your management demands that level of up-time then they surely must > provide you with one or more test firewalls where you can verify new > software releases in a semi-live environment.It''s not so much that the firewall is uber-critical, it''s a cultural thing. Upgrades take a while as the paranoia of "down time" is high. ;)> And even if the misers don''t do that for you, you are running Shorewall > 3.4; so you can: > > shorewall compile <configuration> <firewall-a> #under shorewall 3.4 > > and > > shorewall compile <configuration> <firewall-b> #under shorewall 4.0 > > then: > > diff -au <firewall-a> <firewall-b>Good idea - I haven''t even thought that far through it yet, but that looks like it will save some time. Thanks.> This firewall stuff really isn''t as complicated as brain surgery.... > > -Tom (who has worked in the ultra high-availability market sector since > 1980).You beat me by about a decade :D -- James ------------------------------------------------------------------------- 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 Thu, Aug 23, 2007 at 10:51:52PM -0400, Roberto C. S?nchez wrote: >> On Thu, Aug 23, 2007 at 07:36:14PM -0700, Tom Eastep wrote: >>> On Fri, 2007-08-24 at 12:20 +1000, James Gray wrote: >>>> "Nearly 100%"...yes. Try up-selling that to management who wont even >>>> give me 15 minutes of downtime on a weekend :P >>>> >>> If your management demands that level of up-time then they surely must >>> provide you with one or more test firewalls where you can verify new >>> software releases in a semi-live environment. >> Besides, hardware is cheap. Have them get you a box on which you can >> install Xen, then setup some domUs in a configuration that you can test >> your firewall. Identify some "critical" tasks or functions and make >> sure that those work. If your management has a problem spending money >> on that, figure out how much an hour or a day of downtime costs them and >> then have them compare that to the price of a single machine. Besides, >> a machine that can run Xen for the testing you need can easily be had >> for under US$3000. > > And for yet another option, with a managed (vlan-capable) switch and a > second box you can easily create a failover firewall (which is > necessary for that kind of uptime anyway - all hardware dies sooner or > later), and by switching them around you get more or less no downtime > while upgrading, along with an easy way to move back to the old > version if it''s wrong.Yep - agree 100% with everything you just said :) I''ve just returned from a hellish 32 hour round-trip to a co-lo 400km from our main office to attempt the impossible on ancient hardware that died suddenly (and not necessarily "expectantly" either). The technology isn''t necessarily the problem where I work - it''s the culture, and *that* takes a lot more effort and time to fix ;) Cheers, James ------------------------------------------------------------------------- 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/
James Gray wrote:> not necessarily "expectantly" either). The technology isn''t necessarilyI meant "UNexpectantly" of course. (It''s been a long day). -- James ------------------------------------------------------------------------- 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/