Hi Tom You have been extremely helpful to me setting up my rather niche firewall setup (and to everyone else who posts to the shorewall list!) - thankyou. Would you be amenable to a (paid for) feature request to support "Dynamic Providers"? The basic idea is that at present if a provider is likely to be missing at startup then we mark the interface as "optional", and some external scripts then need to run "shorewall restart" if we detect providers coming up/down. For my situation, I don''t want to restart the entire firewall when a provider becomes available, rather I just want to adjust the routing, as scripted by Shorewall/Providers.pm (it doesn''t seem a stretch that others might not want to bounce the firewall when a network cable is toggled, so I don''t think this is too niche?) I would seek your advice on the best way to support this, but my proposal would be: - If a provider is effectively optional, then a variation of the current "is the provider up", ie Shorewall/Providers.pm:start_provider(), is emitted to it''s own function "providerN_start_stop()", rather than being inline to setup_routing_and_traffic_shaping() - Additional commandline options to /var/lib/shorewall/firewall allow starting/stopping just an individual provider I don''t see that this should have any functionality changes or performance implications for current users. It would be strictly an advanced option available for those who can use it carefully. In conjunction with an appropriate monitoring daemon this would allow for providers to appear/disappear without necessarily affecting connections on the firewall (this seems useful?) Grateful for your consideration? Thanks Ed W ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
On Mon, 2011-08-22 at 14:56 +0100, Ed W wrote:> Hi Tom > > You have been extremely helpful to me setting up my rather niche > firewall setup (and to everyone else who posts to the shorewall list!) - > thankyou. Would you be amenable to a (paid for) feature request to > support "Dynamic Providers"? > > The basic idea is that at present if a provider is likely to be missing > at startup then we mark the interface as "optional", and some external > scripts then need to run "shorewall restart" if we detect providers > coming up/down. For my situation, I don''t want to restart the entire > firewall when a provider becomes available, rather I just want to adjust > the routing, as scripted by Shorewall/Providers.pm (it doesn''t seem a > stretch that others might not want to bounce the firewall when a network > cable is toggled, so I don''t think this is too niche?) > > I would seek your advice on the best way to support this, but my > proposal would be: > > - If a provider is effectively optional, then a variation of the current > "is the provider up", ie Shorewall/Providers.pm:start_provider(), is > emitted to it''s own function "providerN_start_stop()", rather than being > inline to setup_routing_and_traffic_shaping() > > - Additional commandline options to /var/lib/shorewall/firewall allow > starting/stopping just an individual provider > > > I don''t see that this should have any functionality changes or > performance implications for current users. It would be strictly an > advanced option available for those who can use it carefully. > > In conjunction with an appropriate monitoring daemon this would allow > for providers to appear/disappear without necessarily affecting > connections on the firewall (this seems useful?) > > Grateful for your consideration?Ed, Everything that you have asked for already exists except that the firewall is reloaded. - The ''optional'' option in /etc/shorewall/providers applies to providers that use the interface. - The preferred monitoring daemon is LSM which is prominently mentioned on the Shorewall Multi-ISP page. - Shorewall-init will also trigger ''shorewall restart'' if an optional interface is brought up or taken down. - The compiled script provides ''up'' and ''down'' commands which are used by Shorewall-init to handle up/down events. What is your objection to doing a ''shorewall restart''. Packet/Byte counter reset? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
On Mon, 2011-08-22 at 07:14 -0700, Tom Eastep wrote:> > What is your objection to doing a ''shorewall restart''. Packet/Byte > counter reset? >A couple of more things. When LSM or Shorewall-init triggers a restart, it is not a full restart that re-compiles the configuration. It is rather just a reloading of the currently-compiled configuration. One reason that I dislike the notion of modifying the running configuration in place is that it substantially increases the testing complexity. Plus, implementing your suggesting is not as straightforward as it might seem. - An interface can be either hard down (e.g., ifdown ethx) or soft down (the interface is in the UP state but the link isn''t functional). The steps needed to bring the interface back up from these two different ''down'' states are quite different (think about traffic shaping, for example). - Shorewall supports a ''compile'' command that replaces /var/lib/shorewall/firewall. Changes in the configuration could cause up/down processing to fail or to do the wrong thing if the running configuration isn''t compatible with the new one. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
On 22/08/2011 17:42, Tom Eastep wrote:> On Mon, 2011-08-22 at 07:14 -0700, Tom Eastep wrote: > >> >> What is your objection to doing a ''shorewall restart''. Packet/Byte >> counter reset?Actually, for my scenario there are two main problems, arguably these aren''t as important for other users, but they are to me...: 1) Time - the router is an Alix board (500mhz geode) and a fast restart takes 2-5 seconds. One of the network connections we are building the router for is an Iridium satellite link, this is priced at around $1.50/min and billed in 20 second increments. PPP takes approx the first 10 seconds to connect, and then if we are fairly efficient we can get some data transferred and the link hung up before we incur the second 20 second increment. Unfortunately 2-3 seconds becomes a large fraction of the 10 seconds we have to hit that target. Adding extra 20 second increments is roughly 50c a go and if we do some rough numbers at 3 dialups per day, 200 days, then we are hitting say $300/year extra data per box (hopefully hundreds/thousands of boxes...). It''s worth pinching the extra seconds here 2) Accurate byte counts. The other type of connection we will support is a 3G style satellite connection where you pay by the byte. We will be using a captive portal (simple iptables + ipsets) to allocate usage per device (and implicitly per user). It would appear that we can "leak" during the restart of iptables? As far as possible I want to target having packet accurate usage counts (the more accurate you can get saves arguments later) 2.5) I''m trying to get very rigid control over the routing tables, so users have to agree to use each connection one by one. I''m worried that inflight data is going to risk routing peculiarly during the restart and given subsequent "track" and the like, it may cause some complex (and unintended) routing to persist after the restart? Just for background - the appliance is going to be given to non technical end users who will only have a web interface to interact with. I want to offer them flexibility to plug in additional hardware, but I''m proposing up front to set some bounds on what we support. Roughly, the box will be preconfigured to support: - eth0-4 - wlan0-1 - ppp0-4 (dialup) - ppp5-9 (3G/PPPoE) To a very large extent I can preconfigure each of these options statically right now, and if say wlan1 is added/removed, all we need do is add the additional routing tables, the rest of the firewall can be pre-configured (approximately all internet connections will be considered the same). Same too for the PPP connections, as udev notices new real hardware, our daemon applies appropriate logic to wire up a free PPP slot and apart from the routing we are good to go. The main thing I am missing here is that as my device manager (not NetworkManager) notices cables being pulled, wlan connections going down and 3g hardware going out of cellular range, then I need to adjust the routing tables appropriately> One reason that I dislike the notion of modifying the running > configuration in place is that it substantially increases the testing > complexity.Understood. Please bear in mind that my proposal was largely not to change the code /var/lib/shorewall/firewall (well more than very slightly). The proposal was to re-organise it into additional functions so that a user with more complex requirements (me) can go outside of the normal use case. I think my proposal doesn''t change the actual script which is run for normal users?> Plus, implementing your suggesting is not as straightforward as it might > seem. > > - An interface can be either hard down (e.g., ifdown ethx) or soft down > (the interface is in the UP state but the link isn''t functional). The > steps needed to bring the interface back up from these two different > ''down'' states are quite different (think about traffic shaping, for > example).I''m not currently using traffic shaping, so I hadn''t considered some of the complexities there. Note that my proposal is that shorewall is "normally" used the same as it is today. The main change is simply exposing the routing up/down code so that it can be used independently. I''m hampered by my stupid mail client being stuck in plain text, must fix that. However, basically my ./firewall script says something like: if [ -n "$SW_PPP0_IS_USABLE" ]; then # # Add Provider pppp0 (11) # .... code here to bring up ppp0 .... else error_message "WARNING: Interface ppp0 is not usable -- Provider pppp0 (11) not Added" fi I''m hoping that you will move that ".... code here ..." into a separate function in the script (and allow me to access it)> - Shorewall supports a ''compile'' command that > replaces /var/lib/shorewall/firewall. Changes in the configuration could > cause up/down processing to fail or to do the wrong thing if the running > configuration isn''t compatible with the new one.I agree that this is outside of the scope of shorewall as it stands today. What I am proposing is strictly for use by a smarter link monitor - the person implementing that link monitor will need to understand these limitations. I don''t see it (at least not unless it matures significantly) as being a "user" type feature - it''s purely a hook to allow integration with another system Note that in my case at least, the configuration will never/rarely change, link state changes are far more frequent I risk mis-explaining things here... What you are supposed to read here is that this should look like a reasonably small code change, which is intended to allow third party stuff to "hook in. Thanks Ed W ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev