On Sat, 2008-03-22 at 19:31 +0000, Andrew Suffield wrote: > > The kernel deletes routes that have become invalid because the > interface has gone away, and ppp interfaces disappear when the link is > lost. As a rule, if it wouldn't let you add the route at this point, > it won't let you keep it either - I haven't checked that this still > applies to nexthop routes, but I expect it does. Since default/nexthop > rules are just one rule, and this one references the now-deceased > ppp0, it should get removed.
Yeah, I had wondered if this is what was going on.
> A variation on this theme would eliminate the failure when one
> interface goes away. If the last three entries in the routing table
> are these:
>
> default
> nexthop via 67.193.44.1 dev eth0.1 weight 1
> nexthop via 192.168.200.1 dev ppp0 weight 1
> default via 67.193.44.1 dev eth0.1
> default via 192.168.200.1 dev ppp0
Ahhh. Very interesting solution. I wonder what says Tom about
implementing this one.
> You still need to add them all back when the interface returns, so the
> problem you describe still exists.
Right, but a "shorewall restart" (or restore probably) will do that.
I'm OK with having to do a rest{art|ore} on interface up/down events.
It's that currently even that does not work when the ppp0 interface goes
down that is my current [b]itch.
> You can do that with the params file or with a SHELL directive.
Ahh. IIUC, the params file is configured and it's contents evaluated on
the shorewall ("proper" as opposed to the -lite) node, yes? The reality
is that I don't really need to figure out the value of the gateway on
the compile node. Deferring it's evaluation to the execution of
"firewall" script on the -lite node at policy installation time is
sufficient (and preferred). Can I do that with params? When/where is
params evaluated in a -lite context?
How does this SHELL directive work in a -lite context? The only
information I could find about it is in
http://www.shorewall.net/News.htm and the referenced URL in there
(http://www.shorewall.net/configuration_file_basics.html#Embedded)
doesn't seem to point to anything about embedding shell (or perl) in
config files.
On a more generic level, I wonder if this situation is worth flagging to
an unsuspecting user. That is, if:
* using multiple providers and
* one of the providers is a broadcast based network and
* the gateway for that provider is configured "detect" and
* (probably some other conditions I'm just not thinking of)
Warn the user that if any of the providers "goes AWOL", they will lose
default routing through the firewall machine. Perhaps even error out.
I personally consider this condition a configuration error. Without a
default route, my shorewall box is completely unusable.
b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
