On Tue, 2008-02-12 at 07:56 -0800, Tom Eastep wrote: > > IIRC, this thread started with the lament that your PPP device was > taking so long to come up that Shorewall was getting started ahead of > it.
Yeah. That is just one of a number of issues with multiple interfaces
and the fact that one could be up and the other not though. Generally
for people with a single interface, if it's not up, who cares what state
shorewall and routing are in.
> If that is the immediate problem that you are trying to solve, there
> is a capability in the Debian init script (init.debian.sh) that you
> should take advantage of in your OpenWRT package. The script defines a
> 'wait_interface' variable which may be set in /etc/default/shorewall and
> contains a space-separated list of interface names. The 'start' command
> waits for 90 seconds for each interface to come up (you can hack the
> script to change the timeout).
OpenWRT != Debian. It handles interfaces in a completely different
manner.
> As to the loftier goal of dynamically reacting to interfaces going up
> and down like yo-yos, I've long resisted producing any Shorewall code
> that dynamically modifies the configuration in reaction to changes in
> the environment. Among the reasons are:
>
> 1) The supportability of the product suffers. A static dump of the
> running configuration is no longer sufficient to analyze problems. The
> original configuration and a detailed log of alterations are also required.
>
> 2) A whole new class of problem is created -- "My firewall worked
> correctly for 27 days and then it suddenly quit working -- what's
> wrong?". Today, we can be sure that such problems are not
> Shorewall-related and I like it that way.
>
> 3) The 'save' and 'restore' commands become nearly impossible to
> implement so that they behave correctly (they work questionably today
> when DYNAMIC_ZONES=Yes).
Those are all valid points which I won't argue with. The only thing I'd
say for the last point is that the process of restore could be:
- restore interface agnostic bits
- for each interface_up; do
restore interface specifics
done
The other major pain with multiple interfaces and Shorewall is the
handling of default routes. When an interface goes down, typically the
O/S support wants to remove a default route. With Shorewall's use of
multiple default routes and routing tables and ip rules, this almost
always never works. Same situation for when the interface comes back
up. Sadly 99% of O/S support assumes that there is only one interface
and "route add default bla bla bla" is all that is needed. One could
opt to not have interface plumbing scripts define default routes (where
that option is even possible) and have Shorewall just do it with the
restore option on every interface change, but again that's a heavier
operation than I'm proposing.
But even the "O/S doesn't plumb default routes and leaves it to
Shorewall restore to do" option does not always work. If a broadcast
type interface (i.e. cable modem) does not plumb a default route when it
comes up, Shorewall has no idea what the default router is and emits a
"I don't know what the default route for interface bla is" type message.
So it's kinda damned if you do, damned if you don't.
Sure, it's possible to find a solution for this wart, probably, but I
guess I was just thinking of the bigger picture.
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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
