On 06/19/2017 11:01 PM, Norman Henderson wrote: > We have three internet connections at the moment, one of which is stable > but costly per Gb, and the other two cheaper and uncapped but highly > prone to failures - usually somewhere upstream in their networks. These > can manifest as slowdowns, high lost packet rates, or complete failures. > (Welcome to Africa...) > > We have complex route_rules which prefer the cheaper providers but allow > (some users) access to the costly provider if the normal ones are > disabled in Shorewall. > > 1) Sometimes a particular user (usually me!) needs to use the costly > provider for a while, although other users have to suffer the normal > providers. Since it's a pain to change the route_rules file and restart > Shorewall (with implications for tunnels and other things too), I have > just been deleting the relevant "ip rule" to give myself access to the > costly provider. The trouble is that these rules come back again all by > themselves, after a random delay but sometimes just a few minutes. > > Question: what Shorewall features / behaviors trigger the ip rules to be > reinitialized? Is there something I could do (or stop doing) to prevent > this happening?
> > 2) FOOLSM suffers from the limitation that it will only monitor an > on-net address i.e. if the interface address is 192.168.0.1/24 > <http://192.168.0.1/24>, it will only monitor a remote address in that > same subnet. Question: does anyone know of a different monitoring > solution that will enable and disable providers based on an end-to-end > path (such as to my virtual server in the USA)? FOOLSM does not have such a limitation -- it can monitor any address, provided that you add the appropriate route for that address. In my own configuration, I have this in /etc/network/interfaces: post-up /sbin/ip route add 96.120.100.113/32 via 10.2.10.1 dev eth0 post-up /sbin/ip route add 76.28.230.188/32 via 10.1.10.1 dev eth1 Then, in FOOLSM, I monitor 96.120.100.113 through eth0 and 76.28.230.188 through eth1. This requires the appropriate TTL to be configured for each in FOOLSM and it requires that both providers be specified as 'persistent' in /etc/shorewall/providers > > 3) I have experimented with monitoring scripts of my own but there is a > conundrum: > - if a provider is flaky it needs to be disabled, otherwise it remains > the chosen route for users and they don't get any Internet. > - Meaningful testing of the status of a path require the interface to be > enabled. For example, pings over an interface that is up, but for which > the provider is marked "down" in Shorewall alternately succeed or report > "Operation not permitted". Use 'persistent' in /etc/shorewall/providers. > - therefore, testing the status of a path requires frequent enabling and > disabling (if it is found to still be flaky) which in turn introduces > brief but annoying route changes that mess with users' ability to access > the 'net. > Question: Any ideas for how to disable a provider and the corresponding > route_rules (for users) and yet still allow the firewall itself to > reliably use that interface? At least for pings and maybe for more > complex tests e.g. speedtest.net <http://speedtest.net>. Again, use 'persistent'. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
