Beta 1 is now availablew for testing.
Problems Corrected:
1) Previously, the Shorewall and Shorewall6 install.sh scripts did two
things wrong with respect to the /etc/shorewall[6]/routes file:
- The existing file was unconditionally removed.
- A skeleton file was not installed when SPARSE was not set in
the shorewallrc file.
Additionally, the installer would remove /etc/shorewall[6]/tcstart.
2) The Shorewall-init install.sh script previously refused to replace
/sbin/ifup-local and /sbin/ifdown-local when those files has been
installed by an earlier version of Shorewall-init.
New Features:
1) Prior to this release, Shorewall has only supported blackhole null
routing in the /etc/shorewall[6]/routes file and in the
NULL_ROUTE_RFC1918 option.
Beginning with this release, Shorewall also supports
''unreachable''
and ''prohibit'' routes.
In /etc/shorewall/routes, the GATEWAY column may contain
''blackhole'', ''unreachable'' or
''prohibit''.
NULL_ROUTE_RFC1918 can also assume those values, in addition to
''Yes'' and ''No'' (case-insensitive).
''Yes'' is equivalent to
''blackhole'' for backward compatibility.
Please see http://www.shorewall.net/MultiISP.html#null_routing for
details. That section was provided by Mr Dash Four.
2) The ''ifupdown'' script installed by Shorewall-init is now
distribution-specific. Previously, the script determined the
distribution at run-time.
Thank you for testing,
-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 \________________________________________________
------------------------------------------------------------------------------
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
> New Features: > > 1) Prior to this release, Shorewall has only supported blackhole null > routing in the /etc/shorewall[6]/routes file and in the > NULL_ROUTE_RFC1918 option. > > Beginning with this release, Shorewall also supports ''unreachable'' > and ''prohibit'' routes. > > In /etc/shorewall/routes, the GATEWAY column may contain > ''blackhole'', ''unreachable'' or ''prohibit''. > > NULL_ROUTE_RFC1918 can also assume those values, in addition to > ''Yes'' and ''No'' (case-insensitive). ''Yes'' is equivalent to > ''blackhole'' for backward compatibility. >A few "editorial" changes and further suggestions: -Generally speaking there are 3 different types of Null routing +Generally speaking, there are 3 different types of Null routing -an ICMP unreachable is generated (icmp code 3) +an ICMP unreachable is generated (icmp type 3) -"Prohibit" type routes are also indicated by a dash in the "Iface" column as indicated above. +"Prohibit" type routes are also indicated by a dash in the "Iface" column as shown above. -packet matching a route with the route type blackhole is discarded. +packet matching a route with the route type blackhole is simply discarded (DROPped). -Blackhole routes are usually indicated with a start ("*") in the "Iface" column: +Blackhole routes are usually indicated with a star ("*") in the "Iface" column: -(ROUTE_FILTER=Yes or routefilter in shorewall-interfaces(5)), +(ROUTE_FILTER=Yes or routefilter in [LINK_TO_MAN_PAGE]shorewall-interfaces[/LINK_TO_MAN_PAGE]), "IMPORTANT: When NULL_ROUTE_RFC1918=Yes is used, Shorewall creates a shell script file in ${VARDIR}/undo_rfc1918_routing to undo the null routing" I see that in Beta1, you add ${VARDIR}/undo_main_routing, as well as ${VARDIR}/undo_default_routing and ${VARDIR}/undo_<provider>_routing, which is very good, so I think this text above should also be amended to reflect this. I am also not sure whether ${VARDIR}/default_route existed before - I certainly did not see any man page describing its purpose. -(in addition to RFC1918 type networks) to be defined. +(in addition to RFC1918 type networks) to be added. -That way, when the network device goes back up, +That way, when the network device goes back up again, -A more elegant solution to this particular problem is, +A more elegant solution is, Also (from the published MultiISP page, taking into account Beta1 as well): "It is worth noting that blackhole routes created in such a way cannot be "undone" automatically and have to be deleted manually using the "ip route del" command." Well, that''s no longer true, since you include such a feature in Beta1, so this needs to be expanded upon. "Example of use (|/etc/shorewall/routes|):" [...] The above generates the following 3 statements for execution upon Shorewall startup: ip route replace blackhole 10.0.0.0/8 table main ip route replace blackhole 82.32.0.0/12 table dmz ip route replace blackhole 192.168.14.0/26 table dmz Well, that''s not true either. The statements generated are "ip route add", not "ip route replace". That''s also valid for the example given in point 2 of the "Beginning with Shorewall 4.5.15" section. See also the bug I found below. Lets take the following example: We need to null-route all addresses from the 10.0.0.0/8 range, *except* 10.1.0.0/24. In such a case we need to define two routes in our "routes" file (assuming the default "main" routing table is used and also assuming that 10.1.0.0/24 is routed via the default gateway on eth0). "*except*" needs to be turned to [bold]except[/bold]. "assuming the default "main" routing table is used and also assuming that 10.1.0.0/24 is routed via the default gateway on eth0" needs to change to "assuming the default "main" routing table is used and also assuming that 10.1.0.0/24 is routed via the default gateway on eth0 and we need to use ''blackhole'' type null routing". "The above will generate 2 statements for execution when Shorewall starts: ip route replace blackhole 10.0.0.0/8 table main ip route replace 10.1.0.0/24 table main " "replace" in the example above should be changed to "add". "that has absolutely NO effect on the null routes defined (as already indicated, these are "static" and can only be removed by executing "ip route del")." "NO" should be changed to [bold]no[/bold] (lowercase and bold) and "an only be removed by executing "ip route del"" should be changed to "an only be removed by executing "ip route del" or by executing the relevant ${VARDIR}/undo_*_routing shell script)." "then ALL routes defined or attached" "ALL" should be changed to [bold]all[/bold] (lowercase and bold). "When shorewall-init is used, all configuration settings (routes, interface options etc) are kept in one place and do not have to be defined separately" I see that you have already included a link to the MultiISP page from the NULL_ROUTE_RFC1918 man page (shorewall.conf). Can you do the same for "routes" as well, since the majority of the features described in that section are implemented with this file? Now, the bug I found: routes ~~~~ main 10.0.0.0/8 blackhole main 10.0.0.0/8 prohibit generates: run_ip route add blackhole 10.0.0.0/8 table 254 run_ip route add prohibit 10.0.0.0/8 table 254 That is not going to work (ip will complain that the route already exists). A much cleaner solution to this would be if shorewall could spot the overlap during compile time (don''t know how doable that would be), or, if that is not possible, to change "add" with replace, in which case the latest route added will take precedence. In this respect, if I also have NULL_ROUTE_RFC1918=Yes|unreachable|prohibit|blackhole, then the generated statements are with "ip route replace", which will overlap/replace the one I defined in "routes" using my example above, so if this can be detected, at least a warning by shorewall should be issued. Same goes for the ${VARDIR}/undo_*_routing files: they contain various "ip route del" statements, but if the route has already been deleted (given the above example, say I first execute ${VARDIR}/undo_main_routing, followed by ${VARDIR}/undo_rfc1918_routing), then an error will be given. The appropriate thing to do would be either to swallow the error ( redirect to /dev/null) or check whether that route exists prior to issuing "ip route del". I favour the latter approach as it is much cleaner. There won''t be any such issue with executing ${VARDIR}/undo_<provider>_routing, since you use "ip route flush table <provier_num>" and that will clear everything up. Another suggestion: for all table IDs shorewall uses provider numbers. Can you change that to provider names instead? It would help debugging and it is more clearer. When I see "ip route del blackhole 10.0.0.0/8 table 7" for example, I have to start digging in order to decipher what that number translates to. It will be much easier if I had "ip route del blackhole 10.0.0.0/8 table dmz" instead since that is the name I have used in routes.> 2) The ''ifupdown'' script installed by Shorewall-init is now > distribution-specific. Previously, the script determined the > distribution at run-time. >I''ve got a question about this: ifupdown executes "${VARLIB}/$PRODUCT/firewall -V0 $COMMAND $INTERFACE". Is "${VARLIB}/$PRODUCT/firewall" not the equivalent of "${VARDIR}/firewall"? If so, for consistency, I''d suggest that you use VARDIR instead. What does ${VARDIR}/firewall <up|down> <iface> does exactly? I am particularly interested to know whether any of the rules or traffic-shaping rules are (re-)defined or reset? As it stands, /usr/libexec/shorewall-init/ifupdown (from Fedora''s perspective) is copied to /sbin/ifup-local as well as /sbin/ifdown-local. Wouldn''t it be better to create a symlink to /usr/libexec/shorewall-init/ifupdown instead (/usr/libexec/* can be executed, so I don''t think there would be any SELinux alerts in that respect)? ------------------------------------------------------------------------------ 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
> As it stands, /usr/libexec/shorewall-init/ifupdown (from Fedora''s > perspective) is copied to /sbin/ifup-local as well as > /sbin/ifdown-local. Wouldn''t it be better to create a symlink to > /usr/libexec/shorewall-init/ifupdown instead (/usr/libexec/* can be > executed, so I don''t think there would be any SELinux alerts in that > respect)?Further to this: what is the reason for not creating these two files as part of the shorewall-init package instead? It would be much easier for rpm to track the file changes that way (during install/upgrade/delete) instead of mucking about with %post and %postun scripts, don''t you think? ------------------------------------------------------------------------------ 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
On 03/16/2013 06:21 PM, Mr Dash Four wrote:> -(ROUTE_FILTER=Yes or routefilter in shorewall-interfaces(5)), > +(ROUTE_FILTER=Yes or routefilter in > [LINK_TO_MAN_PAGE]shorewall-interfaces[/LINK_TO_MAN_PAGE]), > > "IMPORTANT: When NULL_ROUTE_RFC1918=Yes is used, Shorewall creates a > shell script file in ${VARDIR}/undo_rfc1918_routing to undo the null > routing" > > I see that in Beta1, you add ${VARDIR}/undo_main_routing, as well as > ${VARDIR}/undo_default_routing and ${VARDIR}/undo_<provider>_routing, > which is very good, so I think this text above should also be amended to > reflect this.The undo_<table>_routing files are not new; they are an integral part of the Multi-ISP implementation and allow ''stop'' and ''restart'' to work correctly.> > Same goes for the ${VARDIR}/undo_*_routing files: they contain various > "ip route del" statements, but if the route has already been deleted > (given the above example, say I first execute > ${VARDIR}/undo_main_routing, followed by > ${VARDIR}/undo_rfc1918_routing), then an error will be given. The > appropriate thing to do would be either to swallow the error ( redirect > to /dev/null) or check whether that route exists prior to issuing "ip > route del". I favour the latter approach as it is much cleaner.Why run ''ip'' twice when in the normal case, the existing command succeeds?> > There won''t be any such issue with executing > ${VARDIR}/undo_<provider>_routing, since you use "ip route flush table > <provier_num>" and that will clear everything up.Because these files are an integral part of the Multi-ISP feature, they are normally run by the generated script. Look at one of these files closely: qt /sbin/ip -4 route del unreachable 10.0.0.0/8 qt /sbin/ip -4 route del unreachable 172.16.0.0/12 qt /sbin/ip -4 route del unreachable 192.168.0.0/16 The ''qt'' function is as follows: # # Suppress all output for a command # qt() { "$@" >/dev/null 2>&1 } The attached patch deletes the leading ''qt '' and adds '' >/dev/null 2>&1'' to the end of each command. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/16/2013 06:21 PM, Mr Dash Four wrote:> Now, the bug I found: > > routes > ~~~~ > main 10.0.0.0/8 blackhole > main 10.0.0.0/8 prohibit > > generates: > > run_ip route add blackhole 10.0.0.0/8 table 254 > run_ip route add prohibit 10.0.0.0/8 table 254 > > That is not going to work (ip will complain that the route already > exists). A much cleaner solution to this would be if shorewall could > spot the overlap during compile time (don''t know how doable that would > be), or, if that is not possible, to change "add" with replace, in which > case the latest route added will take precedence.The attached patch replaces ''add'' with ''replace''. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/16/2013 06:21 PM, Mr Dash Four wrote:> > Another suggestion: for all table IDs shorewall uses provider numbers. > Can you change that to provider names instead?That would break if KEEP_RT_TABLES=Yes were set.> > It would help debugging and it is more clearer. When I see "ip route del > blackhole 10.0.0.0/8 table 7" for example, I have to start digging in > order to decipher what that number translates to. It will be much easier > if I had "ip route del blackhole 10.0.0.0/8 table dmz" instead since > that is the name I have used in routes. > >> 2) The ''ifupdown'' script installed by Shorewall-init is now >> distribution-specific. Previously, the script determined the >> distribution at run-time. >> > I''ve got a question about this: ifupdown executes > "${VARLIB}/$PRODUCT/firewall -V0 $COMMAND $INTERFACE". > > Is "${VARLIB}/$PRODUCT/firewall" not the equivalent of > "${VARDIR}/firewall"? If so, for consistency, I''d suggest that you use > VARDIR instead.PRODUCT is the loop variable, so that substitution doesn''t work.> > What does ${VARDIR}/firewall <up|down> <iface> do exactly? I am > particularly interested to know whether any of the rules or > traffic-shaping rules are (re-)defined or reset?It depends; see the tables in http://www.shorewall.net/Shorewall-init.html. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/16/2013 06:37 PM, Mr Dash Four wrote:> >> As it stands, /usr/libexec/shorewall-init/ifupdown (from Fedora''s >> perspective) is copied to /sbin/ifup-local as well as >> /sbin/ifdown-local. Wouldn''t it be better to create a symlink to >> /usr/libexec/shorewall-init/ifupdown instead (/usr/libexec/* can be >> executed, so I don''t think there would be any SELinux alerts in that >> respect)? > Further to this: what is the reason for not creating these two files as > part of the shorewall-init package instead? > > It would be much easier for rpm to track the file changes that way > (during install/upgrade/delete) instead of mucking about with %post and > %postun scripts, don''t you think?The Shorewall-init RPM is installable on both RedHat-based and SusE-based systems, and the two have very different requirements. I would expect that distribution-specific .spec files would do as you suggest (and also create symbolic links if appropriate). -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/22/2013 02:05 PM, Tom Eastep wrote:>> >> What does ${VARDIR}/firewall <up|down> <iface> do exactly? I am >> particularly interested to know whether any of the rules or >> traffic-shaping rules are (re-)defined or reset? > > It depends; see the tables in http://www.shorewall.net/Shorewall-init.html.I just noticed that I had not uploaded the latest version of that page; latest is available at http://www1.shorewall.net/Shorewall-init.html -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/16/2013 06:21 PM, Mr Dash Four wrote:> Now, the bug I found: > > routes > ~~~~ > main 10.0.0.0/8 blackhole > main 10.0.0.0/8 prohibit > > generates: > > run_ip route add blackhole 10.0.0.0/8 table 254 > run_ip route add prohibit 10.0.0.0/8 table 254 > > That is not going to work (ip will complain that the route already > exists). A much cleaner solution to this would be if shorewall could > spot the overlap during compile time (don''t know how doable that would > be), or, if that is not possible, to change "add" with replace, in which > case the latest route added will take precedence. > > In this respect, if I also have > NULL_ROUTE_RFC1918=Yes|unreachable|prohibit|blackhole, then the > generated statements are with "ip route replace", which will > overlap/replace the one I defined in "routes" using my example above, so > if this can be detected, at least a warning by shorewall should be issued. >The attached patch detects duplicate route destinations. A duplicate is fatal in the routes file. If a routes entry matches an RFC1918 network and NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the duplicate route is suppressed. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 3/16/13 6:21 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:>A few "editorial" changes and further suggestions:I''ve updated the MultiISP page -- please have a look. Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ 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
> I would expect that distribution-specific .spec files would do as you > suggest (and also create symbolic links if appropriate). >Yeah, that''s what I ended up doing - modified the .spec file, job done. ------------------------------------------------------------------------------ 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
>> routes >> ~~~~ >> main 10.0.0.0/8 blackhole >> main 10.0.0.0/8 prohibit >> >> generates: >> >> run_ip route add blackhole 10.0.0.0/8 table 254 >> run_ip route add prohibit 10.0.0.0/8 table 254 >> >> That is not going to work (ip will complain that the route already >> exists). A much cleaner solution to this would be if shorewall could >> spot the overlap during compile time (don''t know how doable that would >> be), or, if that is not possible, to change "add" with replace, in which >> case the latest route added will take precedence. >> > > The attached patch replaces ''add'' with ''replace''. >I don''t like this very much, if I am being honest. Debugging ip tables rules is hard enough, but tracing routing is even harder. Even though I suggested the ''replace'' solution, I was hoping that shorewall would be able to get this checked at source, if possible. To me it doesn''t require anything sophisticated - an exact match (i.e. a string comparison of sort) is only required. If a ''replace'' instead of shorewall error-checking is adopted, then identical routes will be swallowed silently and to then find what went wrong (if it does) will be much harder. ------------------------------------------------------------------------------ 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
>> Another suggestion: for all table IDs shorewall uses provider numbers. >> Can you change that to provider names instead? >> > > That would break if KEEP_RT_TABLES=Yes were set. >Could you adopt a more flexible approach then and use names when KEEP_RT_TABLES=No and define numbers when that option is Yes?>> What does ${VARDIR}/firewall <up|down> <iface> do exactly? I am >> particularly interested to know whether any of the rules or >> traffic-shaping rules are (re-)defined or reset? >> > > It depends; see the tables in http://www.shorewall.net/Shorewall-init.html. >That doesn''t really tell me much. If my interface goes down, then the routes disappear and I also assume the traffic shaping policies associated with that interface do the same. I am not 100% certain about the rules though. So, when shorewall-init executes filrewall up <iface> is this redefined to the state it was before the firewall started? ------------------------------------------------------------------------------ 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
> The undo_<table>_routing files are not new; they are an integral part of > the Multi-ISP implementation and allow ''stop'' and ''restart'' to work > correctly. >First time I noticed this...>> Same goes for the ${VARDIR}/undo_*_routing files: they contain various >> "ip route del" statements, but if the route has already been deleted >> (given the above example, say I first execute >> ${VARDIR}/undo_main_routing, followed by >> ${VARDIR}/undo_rfc1918_routing), then an error will be given. The >> appropriate thing to do would be either to swallow the error ( redirect >> to /dev/null) or check whether that route exists prior to issuing "ip >> route del". I favour the latter approach as it is much cleaner. >> > > Why run ''ip'' twice when in the normal case, the existing command succeeds? >You''ve lost me here. The undo command deletes routes. If a particular route has already been deleted (say by undo_main_routing), when undo_rfc1918_routing tries to delete the same route (due to the current state of shorewall when it doesn''t check whether same routes were defined, particularly if the ''replace'' solution is adopted), then ip will moan. That is what I meant by the above.>> There won''t be any such issue with executing >> ${VARDIR}/undo_<provider>_routing, since you use "ip route flush table >> <provier_num>" and that will clear everything up. >> > > Because these files are an integral part of the Multi-ISP feature, they > are normally run by the generated script. Look at one of these files > closely: > > qt /sbin/ip -4 route del unreachable 10.0.0.0/8 > qt /sbin/ip -4 route del unreachable 172.16.0.0/12 > qt /sbin/ip -4 route del unreachable 192.168.0.0/16 > > The ''qt'' function is as follows: > > # > # Suppress all output for a command > # > qt() > { > "$@" >/dev/null 2>&1 > } > > The attached patch deletes the leading ''qt '' and adds '' >/dev/null 2>&1'' > to the end of each command. >Again, you''ve lost me. There was absolutely nothing wrong with undo_provider_routing - I really like it and simply pointed out that the undo_provider_routing can''t have the issues of the other undo_*_ files. OK, I didn''t know what ''qt'' does, but I don''t see a reason why it needs to be modified - it does a good job, so why remove it? ------------------------------------------------------------------------------ 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
> I''ve updated the MultiISP page -- please have a look. >Thanks Tom. "simply discarded (DROPed." misses a right bracket. "then ALL routes defined or attached" "ALL" should be changed to [bold]all[/bold] (lowercase and bold) - You''ve missed that bit. Finally, the "post-up ip route add 10.1." bit (Debian) seems to be right-aligned which I am sure is not what you want. Everything else is OK, though as I already pointed out, I am not sure adding routes with ''replace'' is such a good idea. ------------------------------------------------------------------------------ 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
On 03/23/2013 05:53 PM, Mr Dash Four wrote:> >>> routes >>> ~~~~ >>> main 10.0.0.0/8 blackhole >>> main 10.0.0.0/8 prohibit >>> >>> generates: >>> >>> run_ip route add blackhole 10.0.0.0/8 table 254 >>> run_ip route add prohibit 10.0.0.0/8 table 254 >>> >>> That is not going to work (ip will complain that the route already >>> exists). A much cleaner solution to this would be if shorewall could >>> spot the overlap during compile time (don''t know how doable that would >>> be), or, if that is not possible, to change "add" with replace, in which >>> case the latest route added will take precedence. >>> >> >> The attached patch replaces ''add'' with ''replace''. >> > I don''t like this very much, if I am being honest. Debugging ip tables > rules is hard enough, but tracing routing is even harder. Even though I > suggested the ''replace'' solution, I was hoping that shorewall would be > able to get this checked at source, if possible. To me it doesn''t > require anything sophisticated - an exact match (i.e. a string > comparison of sort) is only required. > > If a ''replace'' instead of shorewall error-checking is adopted, then > identical routes will be swallowed silently and to then find what went > wrong (if it does) will be much harder.Please see my later post which included a patch that implements duplicate destination detection. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/23/2013 05:54 PM, Mr Dash Four wrote:>>> What does ${VARDIR}/firewall <up|down> <iface> do exactly? I am >>> particularly interested to know whether any of the rules or >>> traffic-shaping rules are (re-)defined or reset? >>> >> >> It depends; see the tables in http://www.shorewall.net/Shorewall-init.html. >> > That doesn''t really tell me much. If my interface goes down, then the > routes disappear and I also assume the traffic shaping policies > associated with that interface do the same. I am not 100% certain about > the rules though. So, when shorewall-init executes filrewall up <iface> > is this redefined to the state it was before the firewall started?As shown in the table, an ''enable'' operation is performed on the interface. From shorewall(8): enable ... The command sets /proc entries for the interface, adds any route specified in shorewall-routes(5) and installs the interface''s traffic shaping configuration, if any. For each provider, the compiler generates a ''start'' function. That function is called during ''shorewall start'' and during ''shorewall enable''. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/23/2013 05:54 PM, Mr Dash Four wrote:> >> I''ve updated the MultiISP page -- please have a look. >> > Thanks Tom. > > "simply discarded (DROPed." misses a right bracket. > > "then ALL routes defined or attached" > > "ALL" should be changed to [bold]all[/bold] (lowercase and bold) - > You''ve missed that bit.Thanks.> > Finally, the "post-up ip route add 10.1." bit (Debian) seems to be > right-aligned which I am sure is not what you want. Everything else is > OK, though as I already pointed out, I am not sure adding routes with > ''replace'' is such a good idea.I don''t see any particular harm in ''replace'' now that we have duplicate destination detection. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/23/2013 05:54 PM, Mr Dash Four wrote:> >>> Another suggestion: for all table IDs shorewall uses provider numbers. >>> Can you change that to provider names instead? >>> >> >> That would break if KEEP_RT_TABLES=Yes were set. >> > Could you adopt a more flexible approach then and use names when > KEEP_RT_TABLES=No and define numbers when that option is Yes? >I''m not too keen on that idea. Using numbers is foolproof; it doesn''t rely on /etc/iproute2/rt_tables at all. Plus, to avoid having to recover the original /etc/iproute2/rt_tables file in the event of a startup failure, the generated script writes that file *after* it has started all providers. I would consider a new option, however: USE_RT_NAMES=[Yes|No] When set to ''Yes'', the emitted script will use routing table (provider) names rather than numbers in the generated shell script. When set to ''No'', the default, table numbers will be used. Setting this option to ''Yes'' requires that KEEP_RT_TABLES=Yes. That means that you are responsible for ensuring that all necessary entries are present in /etc/iproute2/rt_tables. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/24/2013 07:48 AM, Tom Eastep wrote:> On 03/23/2013 05:54 PM, Mr Dash Four wrote: >> >>>> Another suggestion: for all table IDs shorewall uses provider numbers. >>>> Can you change that to provider names instead? >>>> >>> >>> That would break if KEEP_RT_TABLES=Yes were set. >>> >> Could you adopt a more flexible approach then and use names when >> KEEP_RT_TABLES=No and define numbers when that option is Yes? >> > > I''m not too keen on that idea. Using numbers is foolproof; it doesn''t > rely on /etc/iproute2/rt_tables at all. Plus, to avoid having to > recover the original /etc/iproute2/rt_tables file in the event of > a startup failure, the generated script writes that file *after* it has > started all providers.Hmmm -- I just noticed that the original file is *never* restored anyway. So I can implement your suggestion rather easily. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/24/2013 07:59 AM, Tom Eastep wrote:> On 03/24/2013 07:48 AM, Tom Eastep wrote: >> On 03/23/2013 05:54 PM, Mr Dash Four wrote: >>> >>>>> Another suggestion: for all table IDs shorewall uses provider numbers. >>>>> Can you change that to provider names instead? >>>>> >>>> >>>> That would break if KEEP_RT_TABLES=Yes were set. >>>> >>> Could you adopt a more flexible approach then and use names when >>> KEEP_RT_TABLES=No and define numbers when that option is Yes? >>> >> >> I''m not too keen on that idea. Using numbers is foolproof; it doesn''t >> rely on /etc/iproute2/rt_tables at all. Plus, to avoid having to >> recover the original /etc/iproute2/rt_tables file in the event of >> a startup failure, the generated script writes that file *after* it has >> started all providers. > > Hmmm -- I just noticed that the original file is *never* restored > anyway. So I can implement your suggestion rather easily. >Here is the (rather large) patch. I think that I will still implement USE_RT_NAMES without the restriction on KEEP_RT_TABLES. I''ll include that in Beta 3. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 03/24/2013 09:10 AM, Tom Eastep wrote:> On 03/24/2013 07:59 AM, Tom Eastep wrote: >> On 03/24/2013 07:48 AM, Tom Eastep wrote: >>> On 03/23/2013 05:54 PM, Mr Dash Four wrote: >>>> >>>>>> Another suggestion: for all table IDs shorewall uses provider numbers. >>>>>> Can you change that to provider names instead? >>>>>> >>>>> >>>>> That would break if KEEP_RT_TABLES=Yes were set. >>>>> >>>> Could you adopt a more flexible approach then and use names when >>>> KEEP_RT_TABLES=No and define numbers when that option is Yes? >>>> >>> >>> I''m not too keen on that idea. Using numbers is foolproof; it doesn''t >>> rely on /etc/iproute2/rt_tables at all. Plus, to avoid having to >>> recover the original /etc/iproute2/rt_tables file in the event of >>> a startup failure, the generated script writes that file *after* it has >>> started all providers. >> >> Hmmm -- I just noticed that the original file is *never* restored >> anyway. So I can implement your suggestion rather easily. >> > > Here is the (rather large) patch. > > I think that I will still implement USE_RT_NAMES without the restriction > on KEEP_RT_TABLES. I''ll include that in Beta 3.There''s a bug in the last patch. Please wait until Beta 3 before testing. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> Please see my later post which included a patch that implements > duplicate destination detection. >Oops, I''ve missed that, sorry. It tells me of a warning emitted and the duplicate route suppressed, but I am not sure what that means - to me the processing should stop (with an error) if such duplicate route is detected - shorewall has no way of knowing what the user meant - whether to keep the original route or the newly-discovered one. That is why I think shorewall should issue an error an bail out. ------------------------------------------------------------------------------ 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
> I don''t see any particular harm in ''replace'' now that we have duplicate > destination detection. >It is another line of defence. It ensures that duplicate routes will *never* me allowed to be created. If shorewall duplicate-route detection is not perfect and fails (let''s face it, no software is ever perfect), then "ip route add" will stop this from happening, while "ip route replace" won''t. That is why I personally favour the ''add'' approach. ------------------------------------------------------------------------------ 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