I know that Tom has expressed before his reluctance for Shorewall to get deeper into the routing management game, but the reality is that complex routing (i.e. shaping, etc.) and firewalling go hand-in-hand, hence the routing control that is already in Shorewall. I wonder how well the possibility of Shorewall supplying a HA routing monitor would be received. I don''t know of any other packages out there supplying such a thing and it''s almost too small a task to support a whole project for. For the record by routing monitor I mean the basic "ping the other end of the link and adjust routing when it''s not there" type of thing that helps keep dead connections out of the (default) routing decisions puts the connections back when it comes back. It''s not a terribly difficult thing to do, an a small script can do it, indeed, but it would just be so much nicer to have such a thing packaged as a part of a project rather than having everyone cobble up their own, and Shorewall already has the MultiISP (i.e. providers) plumbing to support a generic dead-gateway-detection monitor. Thots? b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:> > It''s not a terribly difficult thing to do, an a small script can do it, > indeed, but it would just be so much nicer to have such a thing packaged > as a part of a project rather than having everyone cobble up their own, > and Shorewall already has the MultiISP (i.e. providers) plumbing to > support a generic dead-gateway-detection monitor. > > Thots?So long as I am running the Shorewall project, there will be no such monitor included in the product. Any piece of software that monitors state and reacts to changes brings with it support issues that I just don''t want to deal with in Shorewall. I get way too much of that in my real job. I''ll be happy to link to anyone''s site that hosts such a monitor project, provided that the project does it''s own support. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Sun, Mar 23, 2008 at 06:09:58PM -0400, Brian J. Murrell wrote:> I wonder how well the possibility of Shorewall supplying a HA routing > monitor would be received. I don''t know of any other packages out there > supplying such a thing and it''s almost too small a task to support a > whole project for. > > For the record by routing monitor I mean the basic "ping the other end > of the link and adjust routing when it''s not there" type of thing that > helps keep dead connections out of the (default) routing decisions puts > the connections back when it comes back.Do it as a heartbeat resource script. That''ll be pretty near transparent to shorewall, and farm all the hard work out to heartbeat. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 2008-03-24 at 00:55 +0000, Andrew Suffield wrote:> > Do it as a heartbeat resource script. That''ll be pretty near > transparent to shorewall, and farm all the hard work out to heartbeat.Hrm. Maybe my use of HA was misleading. I meant HA of multiple Internet connections, not multiple Shorewall systems in an HA configuration. Did you understand my use of HA to mean the latter? If you did mean using heartbeat to achieve the former, how do you propose that would work? I''m marginally familiar with heartbeat and cannot see how it could be achieved to modify routing rules on a single node to deal with Internet connections going up and down. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Sun, 2008-03-23 at 15:42 -0700, Tom Eastep wrote:> > So long as I am running the Shorewall project, there will be no such > monitor included in the product.Heh. That''s about the level of reception I was expecting. :-)> Any piece of software that monitors > state and reacts to changes brings with it support issues that I just > don''t want to deal with in Shorewall.Fair enough.> I get way too much of that in my > real job.Heh.> I''ll be happy to link to anyone''s site that hosts such a monitor > project, provided that the project does it''s own support.That''s fair, and perhaps a workable solution. Perhaps such a project could leverage on the code of Shorewall. Thanx! b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:> On Sun, 2008-03-23 at 15:42 -0700, Tom Eastep wrote: > >> I''ll be happy to link to anyone''s site that hosts such a monitor >> project, provided that the project does it''s own support. > > That''s fair, and perhaps a workable solution. Perhaps such a project > could leverage on the code of Shorewall.Sure. Feel free. I would like eventually to get Shorewall entirely out of the routing business because I really think that routing should be controlled separately from the firewall. There is no earthly reason why restarting the firewall should have to rebuild the policy routing configuration (although that can be avoided by using the ''-r'' option of restart). Similarly, there should be no need to reload the Netfilter ruleset to change the policy routing configuration (although the ''refresh'' command under Shorewall-perl does that to a large extent). I have similar feelings about traffic shaping, especially now that Shorewall 4.1 supports u32 classifiers that are totally independent of Netfilter. From an HA (as you use the term) perspective though, both traffic shaping and routing need to be rebuilt after a network interface comes up. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[ Not sure my CC to -devel will actually propagate but I will give it a go ] On Mon, 2008-03-24 at 07:50 -0700, Tom Eastep wrote:> > Sure. Feel free.OK.> I would like eventually to get Shorewall entirely out of the routing > business because I really think that routing should be controlled > separately from the firewall. There is no earthly reason why restarting > the firewall should have to rebuild the policy routing configuration > (although that can be avoided by using the ''-r'' option of restart).My 4.0.6 does not show a -r option to restart. But yes, I agree that policy routing and general firewalling are only very loosely related if at all and only by nature of the firewalling rules marking packets for policy routing. In that latter case, it just makes it easier to build the policy routes from the same configuration source that is marking the packets rather than having to keep two completely unrelated and separate software packages in sync (i.e. wrt to routing policy marks). Perhaps your feeling is that Shorewall should not even be touching the mangle chains and that some policy routing package should be doing that.> Similarly, there should be no need to reload the Netfilter ruleset to > change the policy routing configurationIndeed!> (although the ''refresh'' command > under Shorewall-perl does that to a large extent).Oh? Does it? Now that would be nice. Ahhh. But you said Shorewall-perl. I suppose there is no parallel operation for shorewall-lite?> I have similar feelings about traffic shaping, especially now that > Shorewall 4.1 supports u32 classifiers that are totally independent of > Netfilter.Sounds like 4.1 (er, 4.2 I guess) is going to be an "interesting" release.> From an HA (as you use the term) perspective though, both traffic > shaping and routing need to be rebuilt after a network interface comes up.Indeed. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, Mar 24, 2008 at 10:24:16AM -0400, Brian J. Murrell wrote:> On Mon, 2008-03-24 at 00:55 +0000, Andrew Suffield wrote: > > > > Do it as a heartbeat resource script. That''ll be pretty near > > transparent to shorewall, and farm all the hard work out to heartbeat. > > Hrm. Maybe my use of HA was misleading. I meant HA of multiple > Internet connections, not multiple Shorewall systems in an HA > configuration. > > Did you understand my use of HA to mean the latter?Oh, yes, I habitually assume that you can''t possibly do HA in one box (because you can''t really, I get dead motherboards about as frequently as I get dead internet connections). I''m used to doing things vaguely like this: http://linuxman.wikispaces.com/Shorewall+basic+failover+with+heartbeat No idea if it makes any sense with one box (insofar as that makes any sense at all) - I''d never try, a second box is the cheapest element of the setup. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, Mar 24, 2008 at 11:09:55AM -0400, Brian J. Murrell wrote:> But yes, I agree that > policy routing and general firewalling are only very loosely related if > at all and only by nature of the firewalling rules marking packets for > policy routing.The underlying problem is that shorewall''s basic design is that of a more or less optimal way to configure netfilter, and that''s completely different from what a roughly optimal routing configuration package would look like. Trying to build either of them on top of the other is doomed to failure; you need two systems that sit side by side and don''t interfere with each other. It would be nice if somebody were to make something like shorewall for routing. I''m almost as tired of writing routing tables by hand as I was of writing iptables scripts. (And while you''re at it, linux''s routing system could use some love, it appears to have been written by somebody who thought that IOS was a good example). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 2008-03-24 at 15:13 +0000, Andrew Suffield wrote:> > Oh, yes, I habitually assume that you can''t possibly do HA in one box > (because you can''t really, I get dead motherboards about as frequently > as I get dead internet connections).Ahhh. Your experience is different than mine. I find Internet connections go up and down a lot more than the hardware that''s connecting them to the local network and it''s just dealing with the routing changes of those connections going up and down I want to deal with.> I''m used to doing things vaguely > like this: > > http://linuxman.wikispaces.com/Shorewall+basic+failover+with+heartbeatHeh. Nice. A bit overkill for my home situation though. :-)> No idea if it makes any sense with one box (insofar as that makes any > sense at all) - I''d never try, a second box is the cheapest element of > the setup.But you first have to solve my basic problem: adjusting to Internet connections going up and down on a single box before you can start to roll that out to multiple boxes -- to deal with hardware failures. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:>> I would like eventually to get Shorewall entirely out of the routing >> business because I really think that routing should be controlled >> separately from the firewall. There is no earthly reason why restarting >> the firewall should have to rebuild the policy routing configuration >> (although that can be avoided by using the ''-r'' option of restart). > > My 4.0.6 does not show a -r option to restart.Sorry -- I meant ''-n''.> But yes, I agree that > policy routing and general firewalling are only very loosely related if > at all and only by nature of the firewalling rules marking packets for > policy routing. > > In that latter case, it just makes it easier to build the policy routes > from the same configuration source that is marking the packets rather > than having to keep two completely unrelated and separate software > packages in sync (i.e. wrt to routing policy marks). > > Perhaps your feeling is that Shorewall should not even be touching the > mangle chains and that some policy routing package should be doing that.It may need to be cooperative where Shorewall creates the overall infrastructure and the policy routing package fills in the appropriate chains (it can do that with iptables-restore without wiping out the entire table).> >> Similarly, there should be no need to reload the Netfilter ruleset to >> change the policy routing configuration > > Indeed! > >> (although the ''refresh'' command >> under Shorewall-perl does that to a large extent). > > Oh? Does it? Now that would be nice. Ahhh. But you said > Shorewall-perl. I suppose there is no parallel operation for > shorewall-lite?Not really. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, Mar 24, 2008 at 09:06:53AM -0700, Tom Eastep wrote:>> Perhaps your feeling is that Shorewall should not even be touching the >> mangle chains and that some policy routing package should be doing that. > > It may need to be cooperative where Shorewall creates the overall > infrastructure and the policy routing package fills in the appropriate > chains (it can do that with iptables-restore without wiping out the > entire table).Or you could toss a SHELL directive in somewhere, letting the routing package feed rules into shorewall directly. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, Mar 24, 2008 at 11:39:28AM -0400, Brian J. Murrell wrote:> > No idea if it makes any sense with one box (insofar as that makes any > > sense at all) - I''d never try, a second box is the cheapest element of > > the setup. > > But you first have to solve my basic problem: adjusting to Internet > connections going up and down on a single box before you can start to > roll that out to multiple boxes -- to deal with hardware failures.In a full heartbeat-managed system you can just use pingd or something similar, and treat the internet connections like extra resources to be monitored, like you would any network-attached storage device. Then it''s just a matter of setting up rules to kick shorewall at the appropriate moments. (I don''t actually do it that way, my systems are rigged to feed link state into quagga and run OSPF, which is a whole different beast. Heartbeat probably isn''t suitable for a single host setup either) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 2008-03-24 at 09:06 -0700, Tom Eastep wrote:> > Sorry -- I meant ''-n''.Hrm. 4.0.6 doesn''t document a "-n" option either. But it''s moot for my purposes given the comment at the bottom.> It may need to be cooperative where Shorewall creates the overall > infrastructure and the policy routing package fills in the appropriate > chains (it can do that with iptables-restore without wiping out the > entire table).If you remove policy routing from Shorewall, does Shorewall need the mangle table for anything else? Is policy routing handled anywhere else in netfilter other than the mangle table? I''m trying to judge the feasibility of actually achieving the goal. I think trying to create a wholly separate project for policy routing that depends on some work that Shorewall does in preparation for it makes the idea of separate project that much more difficult. If each can stand on their own and solve their particular problems, it gets easier to separate them.> > Oh? Does it? Now that would be nice. Ahhh. But you said > > Shorewall-perl. I suppose there is no parallel operation for > > shorewall-lite? > > Not really.Indeed. :-( Which is why I simply use "restart" on my shorewall-lite system. Certainly it''s not overly slow to do so with Shorewall 4, but I''m a miser and endeavour to avoid waste wherever I can and I if could avoid the need to reload the whole policy on my -lite system when all I want to do is adjust routing I would. :-) But as I live with a restart now and it appears to do the job (the "default route{r,s}" thread aside) it''s not a terrible imposition for me currently. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:> On Mon, 2008-03-24 at 09:06 -0700, Tom Eastep wrote: >> Sorry -- I meant ''-n''. > > Hrm. 4.0.6 doesn''t document a "-n" option either.shorewall-lite help (the man page doesn''t document it :-( ) -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:> > If you remove policy routing from Shorewall, does Shorewall need the > mangle table for anything else? Is policy routing handled anywhere else > in netfilter other than the mangle table? I''m trying to judge the > feasibility of actually achieving the goal.Shorewall also needs it for traffic shaping. There are some things that you can do with iptables that you cannot do with u32 filters.> > I think trying to create a wholly separate project for policy routing > that depends on some work that Shorewall does in preparation for it > makes the idea of separate project that much more difficult. > > If each can stand on their own and solve their particular problems, it > gets easier to separate them.So long as packet/connection marks are the "Linux Networking Kludge of Last Resort", it is impossible to separate functions that use marks from Netfilter/iptables (which means Shorewall for those of us who use it). -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 2008-03-24 at 09:36 -0700, Tom Eastep wrote:> > Shorewall also needs it for traffic shaping. There are some things that > you can do with iptables that you cannot do with u32 filters.Right. But you were to draw a line between Shorewall and "Routing and Shaping", does Shorewall need the mangle table?> So long as packet/connection marks are the "Linux Networking Kludge of > Last Resort", it is impossible to separate functions that use marks from > Netfilter/iptables (which means Shorewall for those of us who use it).Indeed. But if you can separate the tables needed for Shorewall and a "Shaping and Routing" package, that helps a routing/shaping package stand on it''s own independent from Shorewall and gain some critical mass. Cooperation between the two packages would not be bad, to be sure, but shouldn''t be necessary. Requiring Shorewall would be a barrier to acceptance of a Routing and Shaping management interface. If a Routing and Shaping package were to be created to release Shorewall of it''s responsibilities there, I''d like to see it usable by those not wanting Shorewall. Just my $0.02. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Brian J. Murrell wrote:> On Mon, 2008-03-24 at 09:36 -0700, Tom Eastep wrote: >> Shorewall also needs it for traffic shaping. There are some things that >> you can do with iptables that you cannot do with u32 filters. > > Right. But you were to draw a line between Shorewall and "Routing and > Shaping", does Shorewall need the mangle table?No.> >> So long as packet/connection marks are the "Linux Networking Kludge of >> Last Resort", it is impossible to separate functions that use marks from >> Netfilter/iptables (which means Shorewall for those of us who use it). > > Indeed. But if you can separate the tables needed for Shorewall and a > "Shaping and Routing" package, that helps a routing/shaping package > stand on it''s own independent from Shorewall and gain some critical > mass.True. Although having to combine Routing and Shaping into the same package is unfortunate.> > Cooperation between the two packages would not be bad, to be sure, but > shouldn''t be necessary. Requiring Shorewall would be a barrier to > acceptance of a Routing and Shaping management interface. If a Routing > and Shaping package were to be created to release Shorewall of it''s > responsibilities there, I''d like to see it usable by those not wanting > Shorewall.Fair enough. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, Mar 24, 2008 at 10:09:32AM -0700, Tom Eastep wrote:>> Indeed. But if you can separate the tables needed for Shorewall and a >> "Shaping and Routing" package, that helps a routing/shaping package >> stand on it''s own independent from Shorewall and gain some critical >> mass. > > True. Although having to combine Routing and Shaping into the same > package is unfortunate.And a bad idea, for all the same reasons that trying to combine netfilter and routing into the same package is a bad idea. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Mon, 2008-03-24 at 10:09 -0700, Tom Eastep wrote:> > No.So that seems to be an interesting delineation point that meets with your desires for Shorewall. If a Routing and Shapping package were to use the mangle table exclusively then it should be able to co-exist with Shorewall without one or the other stepping on the other''s toes.> True. Although having to combine Routing and Shaping into the same > package is unfortunate.Indeed. They are probably more tightly related than routing/shaping and Shorewall though. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/