On 13/03/13 15:24, Tom Eastep wrote: > 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 > > > > > ------------------------------------------------------------------------------ > 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 I think our mails must have crossed in a que somewhere as your comment there seems to confirm my suspicion that shorewall disable and a later shorewall enable would have the same effect was looking for a solution other than the given example with the data duplication issue.
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
