On 03/13/2013 04:45 AM, Mr Dash Four wrote: > >> 10) 'blackhole' routes are now copied to provider tables when >> USE_DEFAULT_RT=No. Previously, these routes were not copied with >> the result that packets could be routed to blackholed addresses. >> >> [...] >> >> 6) 'blackhole' routes may now be defined in /etc/shorewall[6]/routes. >> Simply place 'blackhole' in the GATEWAY column and leave the DEVICE >> column empty. >> > For anyone (myself included) using this approach, be aware of the following: > > When a network interface goes down, all routes defined for that > interface simply disappear, *except* the blackhole routes! What this > means in reality is when the interface goes back up again, the previous > routes, which were added when shorewall was brought > up/loaded/reloaded/restarted need to be re-defined somehow (see below), > otherwise all subnets defined as "holes" in those blackhole routes will > *not* be reachable! > > I have just fallen, again, into this trap and spent the best part of > this morning clearing up the mess, simply because I forgot to add these. > There are, as far as I know, two approaches for solving this problem: > > 1. In addition to the "standard" shorewall package (shorewall-lite, > shorewall, etc), add shorewall-init to take care of this (Tom, I am > certain that the routes defined in those files will be honoured by > shorewall-init, could you confirm this please?);
Yes. > > 2. Add all network-interface dependent routes (the ones which > "disappear" when the interface goes down) to > /etc/sysconfig/network-scripts/route-X (where "X" is the name of the > interface in question). At least in Fedora's case, these can be taken > care of by using the *new* format (which is the "ip" command format, > i.e. "ip route add ..."). For example - to add a route to 10.1.0.0/24 > via 10.1.1.1 on eth0 using table dmz, the following needs to be added to > /etc/sysconfig/network-scripts/route-eth0: > > 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz Again, shorewall-init will trigger an 'up' command for the interface which reloads all routes for the interface that were originally loaded by start/restart. > > That way, when the eth0 interface goes up, the above route will be > "automatically" defined by the OS. > > Tom, I am not sure whether there is a page on shorewall.net, which > explains all this, but if it isn't I think it is worth adding one as I > can imagine I am not the only one who would fall in the above trap. I am > willing to give it a go for the writing bit, if you prefer - just let me > know. > There is no single place where these points are explained. I also notice that the tables in http://www.shorewall.net/Shorewall-init.html are out of date. For optional interfaces, shorewall-init now triggers 'enable' and 'disable' operations rather than reloading the configuration. I think that article would be a good place to gather all of this information in one spot. If you agree and would like to give it a go, I would be grateful. Thanks, -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
