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

[Patrick Dinnen]

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
>