[isf-wifidog] Re: [wirelesstoronto-discuss] Opening the firewall if the auth servers are all unreachable

[Alexandre Carmel-Veilleux]

I went for a much less drastic solution.

There's a hook to mark that all auth server are down, the hook is in
src/util.c I believe and there's a corresponding hook for "any auth
server is up". So my solution uses both of these hooks plus a config
file directive.

If the config file directive (AuthServerFailOpen) is set to On and the
auth server down hook is called, drop the firewall open.

When the auth server up hook is called, if AuthServerFailOpen is On
and the auth server status is down, re-enable the redirect and other
blocking firewall rules that exist prior to a user being logged in.

This would be 100% transparent to the user.

Alex

On 3/2/06, Patrick Dinnen <pdinnen at gmail.com> wrote:
> Rob
> I don't have the knowledge to follow your proposal in detail, as far as
> I'm concerned if it works it's great.
>
> One possible problem though. I assume that if a user is surfing the web
> un-authenticated because the auth server was down and it comes back up
> then the very next page they see is the auth server login page. This
> could be pretty frustrating if you were doing some transaction as the
> auth server came back up.
>
> For example, say the user wrote a long blog post unauthenticated and in
> the meantime auth comes back up, then when the user hits post they get
> redirected to login and lose it all.
>
> I suspect this might be technically impossible to avoid. Maybe it would
> be possible to give the user some warning though, a HTML page served
> from the router perhaps? 'you're surfing unauthenticated right now, be
> careful with your long blog posts', or something else, whatever makes
> sense technically, or maybe it's just not likely to be a big enough
> problem to worry about.
>
> Patrick
>
> Rob Janes wrote:
> > Here's my strategy, Benoit, Phillip, maybe you could comment ...  I've
> > made the code changes and now would like to try it out.
> >
> > David, this is my answer to the Linuxcaffe needs a new dog thread.  I've
> > resolved the wifidog building issues that Seneca had the other night by
> > fixing the makefiles.
> >
> > Add a new chain, TABLE_WIFIDOG_AUTH_IS_DOWN, on the mangle, nat and filter.
> >
> > On the PREROUTING mangle, the chain is there, at the very end, but
> > normally empty.  When the heartbeat monitor thread finds the auth
> > servers are unreachable it adds a line to mark unmarked packets with a
> > new mark, FW_MARK_AUTHISDOWN (253).
> >
> > When the heartbeat monitor thread finds the auth servers are responding
> > again it clears the above mangle chain.
> >
> > Similarily, in the nat PREROUTING chains, add a check for mark
> > FW_MARK_AUTHISDOWN just before the redirect of port 80.  If that mark is
> > set, accept the packet.  This bypasses the redirect.
> >
> > In the filter FORWARD chain, add a check for the FW_MARK_AUTHISDOWN just
> > before the jump to the TABLE_WIFIDOG_UNKNOWN chain.  If the mark is set,
> > jump to the filter chain TABLE_WIFIDOG_AUTH_IS_DOWN.  This chain is
> > loaded at firewall init time from a ruleset, 'auth-is-down'.
> >
> > If you leave the 'auth-is-down' ruleset empty, everything stays the way
> > it is now.
> >
> > But, if you do
> >
> > FirewallRuleSet auth-is-down {
> >   FirewallRule allow to 0/0
> > }
> >
> > all customers will be allowed to surf while the auth server is down.  As
> > soon as the authserver comes back up, they will be redirected to the
> > login splash since the heartbeat monitor will clear the chain that marks
> > their packets as FW_MARK_AUTHISDOWN, and then their packets will no
> > longer be specially marked.
> >
> > That's it!
> >
> > -rob
> >
> > Alexandre Carmel-Veilleux wrote:
> >
> >> On 2/19/06, Alexandre Carmel-Veilleux <acveilleux at gmail.com> wrote:
> >>
> >>
> >>> On 2/9/06, Benoit Grégoire <bock at step.polymtl.ca> wrote:
> >>>
> >>>> On February 8, 2006 03:49 pm, Gabe Sawhney wrote:
> >>>>
> >>>>> The failover => )open( thing is high on my priority list... it might
> >>>>> be the project I'd like to work on at a router geeknight...
> >>>>>
> >>> I've got a quick hack doing this. The actuating code is there and
> >>> proper (along with a config file directive. Right now the actual
> >>> allowing/denying is done by destroying the whole firewall and
> >>> re-creating it when the auth server becomes live.
> >>>
> >>
> >> I'm still waiting for suggestions on how the fail-open should happen
> >> in the firewall... I'm a bit rusty with iptables. Anyone? Benoit,
> >> Phil?
> >>
> >> Alex
> >> _______________________________________________
> >> WiFiDog mailing list
> >> WiFiDog at listes.ilesansfil.org
> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >>
> >>
> >>
> >
> > _______________________________________________
> > wirelesstoronto-discuss mailing list
> > wirelesstoronto-discuss at wirelesstoronto.ca
> > http://wirelesstoronto.ca/lists/listinfo/wirelesstoronto-discuss
> >
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>