> 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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
