I'm using shorewall[-lite] 4.0.5 on an OpenWRT Kamikaze(ish) platform. As you all probably already know, I have multiple ISP uplinks. One is DHCP based and the other PPP[oE] based. I also use track and balance on both interfaces and do some tc based routing.
I'm finding an interesting phenomena with this set up. If the PPPoE
connection ever drops, my weighted default route(s) go away. To
illustrate, before a PPP line drop I have:
default
nexthop via 67.193.44.1 dev eth0.1 weight 1
nexthop via 192.168.200.1 dev ppp0 weight 1
Which is about right for a track and balanced MultiISP Shorewall
configuration.
However, if I go pull the phone plug on the PPPoE interface the result
is that I have no default route at all. I suspected that somewhere some
script was doing a "route delete default ..." because of the PPPoE
interface down event but I've been through the whole process of scripts
that get called on this event and there is no such event. Additionally,
OpenWRT has a config switch one can use to prevent default route
updating and I have that selected and for good measure I added
"nodefaultroute" to the /etc/ppp/options file.
Most of the above is really an aside to a real problem and could
probably be worked around by simply executing
an /etc/init.d/shorewall-lite restart on an interface down event.
Except... and here is the real bug...
Now that the (weighted) default route(s) entry is gone, shorewall-lite
can't figure out how to restore them (when the providers table specifies
"detect" for GATEWAY) because it (apparently) consults the routing table
to find the default route for DHCP (or more accurately, broadcast
network) interfaces.
Two (well, only one really workable) solutions come to mind. The first
is only a solution if the default gateway has been set up already once,
before the main table is copied to the providers tables. If this is
true, then the provider table can be consulted for the default route.
Even with no (weighted or otherwise) default routes in my main table, my
provider table still shows:
default via 67.193.44.1 dev eth0.1
This seems to me like it will not always work -- i.e. if the provider
table is not set up yet, etc.
The second solution seems to be to allow a specification other than
"detect" for the gateway that somehow still results in shorewall[-lite]
figuring it out. Perhaps a (i.e. shell) code fragment can be used
instead of "detect" that results in the gateway's IP address.
On OpenWRT (Kamikaze) for example I can do:
# uci get "/var/state/network.wan0.gateway"
67.193.44.1
To get the gateway's address.
Thots?
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
