I just stumped on the following project: http://selab.edu.ms/twiki/bin/view/Networking/RoutesKeeperProject From the page:> Free as in GPL: Yes, it''s very important, we all love Mr. Richard > Stallman • Load balancing: Use unlimited number of internet > connections simultaneously • Fail over: You still get persistent > internet access although some of your connections stop working • > Type Of Service based routing: Important services (such as VoIP?) use > expensive bandwidth to get the best performance while bulk download > use cheap bandwidth • Flexible XML configuration: No nightmares of > traditional .conf files • Event triggered scripts: Launch > predefined or custom scripts when network events occur (such as a > connection stops working). Thus you are always get informed about the > condition of your network • Integrated IP Accounting: Every packets > get counted, IP accounting can trigger scripts too • Built-in > Quality of Service: Get total control of your traffic, both download > and upload. Bosses will no longer complain about speed when someone > runs BitTorrent? • And much more features can''t be counted here >This looks very interesting for me, as many clients would benefit from having a pair of cheap broadband connections, one cable and one DSL. I need to fully grok it to understand how it may affect exiting iptables rules such as those generated by Shorewall. Has anyone thought about this, or better yet, used it? Thanks, A.
Adam Sherman wrote:> I need to fully grok it to understand how it may affect exiting iptables > rules such as those generated by Shorewall. Has anyone thought about > this, or better yet, used it?I asked the author if he thought it would work under another firewall configurator, here is his reply:> Compatibility with other iptables rules is perfect since rk creates > sub chains (named rk_<something>)) and only manipulates its rules > there. I never tested but I bet that it''ll cooperate with shorewall > happily.Sounds too good to be true. Cheers, A.
Adam Sherman wrote:> Adam Sherman wrote: > >> I need to fully grok it to understand how it may affect exiting >> iptables rules such as those generated by Shorewall. Has anyone >> thought about this, or better yet, used it? > > > I asked the author if he thought it would work under another firewall > configurator, here is his reply: > >> Compatibility with other iptables rules is perfect since rk creates >> sub chains (named rk_<something>)) and only manipulates its rules >> there. I never tested but I bet that it''ll cooperate with shorewall >> happily. > > > Sounds too good to be true. >Yes. - "shorewall [re]start" will wipe out all of the rules added by "RoutesKeeper" (RK). - "shorewall save" will save any rules added by "RK" - "shorewall restore" will restore the RK rules that were present at the time of the "shorewall save" even if they don''t match the current RK configuration. -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
Tom Eastep wrote:>>>Compatibility with other iptables rules is perfect since rk creates >>>sub chains (named rk_<something>)) and only manipulates its rules >>>there. I never tested but I bet that it''ll cooperate with shorewall >>>happily. >> >>Sounds too good to be true. > > Yes. > > - "shorewall [re]start" will wipe out all of the rules added by > "RoutesKeeper" (RK). > - "shorewall save" will save any rules added by "RK" > - "shorewall restore" will restore the RK rules that were present at the > time of the "shorewall save" even if they don''t match the current RK > configuration.The last two issues could be avoided, I guess. If the RK daemon was started after shorewall, would the rules function? Also, is there a more shorewall-friendly way of achieving what RK accomplishes? Thanks, A.
Adam Sherman wrote:> Tom Eastep wrote: > >>>> Compatibility with other iptables rules is perfect since rk creates >>>> sub chains (named rk_<something>)) and only manipulates its rules >>>> there. I never tested but I bet that it''ll cooperate with shorewall >>>> happily. >>> >>> >>> Sounds too good to be true. >> >> >> Yes. >> >> - "shorewall [re]start" will wipe out all of the rules added by >> "RoutesKeeper" (RK). >> - "shorewall save" will save any rules added by "RK" >> - "shorewall restore" will restore the RK rules that were present at the >> time of the "shorewall save" even if they don''t match the current RK >> configuration. > > > The last two issues could be avoided, I guess. If the RK daemon was > started after shorewall, would the rules function?Possibly.> > Also, is there a more shorewall-friendly way of achieving what RK > accomplishes? >I''m not aware of any other available package. -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
Further looking at the way RoutesKeeper and Shorewall would interact, the only issue I can see that would really stop me is DNAT. RoutesKeeper seems to use CONNMARK to track incoming DNATs so they go back out the correct link. I think CONNMARK requires a patch too, which is aggravating. The author mentions:> Unfortunately, shorewall can''t help you doing DNAT with multiple > internet connections. You have to use DNAT feature of rk because a > special technique is required for DNAT to work properly. It''s to mark > incoming connection (by CONNMARK) and later, use that mark to send > responding packets via the correct link.This doesn''t make sense to me, as the multipath section of the Shorewall documentation doesn''t mention this at all. Is this something I should be worried about? Thanks, A.
Adam Sherman wrote:> Further looking at the way RoutesKeeper and Shorewall would interact, > the only issue I can see that would really stop me is DNAT. RoutesKeeper > seems to use CONNMARK to track incoming DNATs so they go back out the > correct link. I think CONNMARK requires a patch too, which is aggravating. > > The author mentions: > >> Unfortunately, shorewall can''t help you doing DNAT with multiple >> internet connections. You have to use DNAT feature of rk because a >> special technique is required for DNAT to work properly. It''s to mark >> incoming connection (by CONNMARK) and later, use that mark to send >> responding packets via the correct link. > > > This doesn''t make sense to me, as the multipath section of the Shorewall > documentation doesn''t mention this at all. Is this something I should > be worried about?Sigh -- Adam; MY DOCUMENTATION DOESN''T COVER MULTI-ISP DNAT CONFIGURATION so the fact that it doesn''t mention this point is irrelevant. You either have to mark packets as the RoutesKeeper author describes (although as of 2.2.0, Shorewall can perform such marking) or you need to configure your servers with two IP addresses as one of the articles linked from FAQ 32 suggests. CONNMARK is included in the kernel.org releases as of 2.6.10. -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
Tom Eastep wrote:>> Further looking at the way RoutesKeeper and Shorewall would >> interact, the only issue I can see that would really stop me is >> DNAT. RoutesKeeper seems to use CONNMARK to track incoming DNATs so >> they go back out the correct link. I think CONNMARK requires a >> patch too, which is aggravating. >> >> The author mentions: >> >>> Unfortunately, shorewall can''t help you doing DNAT with multiple >>> internet connections. You have to use DNAT feature of rk because >>> a special technique is required for DNAT to work properly. It''s >>> to mark incoming connection (by CONNMARK) and later, use that >>> mark to send responding packets via the correct link. >> >> This doesn''t make sense to me, as the multipath section of the >> Shorewall documentation doesn''t mention this at all. Is this >> something I should be worried about?> You either have to mark packets as the RoutesKeeper author describes > (although as of 2.2.0, Shorewall can perform such marking) or you > need to configure your servers with two IP addresses as one of the > articles linked from FAQ 32 suggests.If you mean:> For the use of multiple inbound connections to the same internal > server (public IP A from ISP A and public IP B from ISP B both get > redirected to the same internal server), the ideal solution involves > using two private IP addresses on the internal server. This leads to > an end-to-end uniqueness of public IP to private IP and can be > easily accomplished by following the directions here:Then this works perfectly for me. Thank you! My apologies for missing this in the documentation; sometimes reading the docs through and through does help, and having something pointed out in context clears things up immensely. Again, thanks. A.