[wd-isf] Captive DNS, and auth server bypass
Philippe April
isf_lists at philippeapril.com
Sun Feb 6 16:43:14 EST 2005
First, great work. Now my comments, only regarding the Cons because I
think the ideas are muchos buenos.
> 1. Attempting to resolve anything will point back to the router until
> the user is authenticated. This will definitely interfere with
> pass-through services like teliphone.
>
> Possible solution: "Adaptive" fake DNS where, for certain hostnames, it
> will reply with the real IP instead of the internal IP. This is
> already
> done for the auth server hostname, so it's simple a matter of a config
> file section of "hostnames to be truly resolved" by the captive dns
> server.
That'll take extra effort in findout out if Teliphone does in fact use
DNS (I'd bet it uses hardcoded IPs in the teliphones, but tcpdump could
work) and test. But great easy workaround.
> 2. Once the user receives the IP of the router as the answer to
> www.homepage.com, they then make an http call http://x.x.y.y:80 - this
> call must then be intercepted by captive HTTP system instead of by any
> web server on the router. In other words, a web server that runs on
> router (admin/config/etc) needs to run on a port different than port 80
>
> Solution. I moved the captive HTTP iptables redirect rule higher than
> the "allow all to router" rule. That makes captive http work since
> otherwise the call goes to the normal web server on the router
Wicked!
> Basically, the above boils down to: As long as the router is up, we'll
> be able to interact with the user, independent of whether the internet
> is also up or not.
Much needed feature indeed.
> Now, on to:
>
> Part 2: Auth server bypass
> - --------------------------
>
> Like I mentioned, wifidog now has the capability to detect whether the
> auth server is accessible or not. With minor tuning, it can detect
> whether the internet is up but the auth server is down, or the internet
> is down.
I would like to point out something:
Benoit's IP changed about 3 times this morning. In between two, I
upgraded Utopik to alpha7 which is supposed to figure out automatically
if the IP changed and adapt. After it had alpha7, the IP changed again
and it didn't seem to work. Not sure where the bug is but I'll take a
look and test very soon.
Basically the internal IP table of the authservers was good, but the
IPs in the NAT table were not the same :-|
One thing we could do to help is flush the authserver table every 15
minutes (let's say).
Or find why the internal table doesn't match reality :)
> That means that we now, in combination with captive DNS, have the
> ability to make some cool decisions regarding re-direction to the auth
> server.
>
> This is open for discussion among all volunteers, but I thought it's
> better to pose the question here first:
>
> ~ * * * *
> If the internet is up but the auth server is down, should we offer a
> "disclaimer" screen and let the user access the internet with a
> restrictive firewall set ?
> ~ * * * *
>
> My $0.02 says "let them browse" and that's it.
My $0.02 says that I agree with you for the philosophy although I think
the auth server should NEVER be down, we should work more towards this
goal (redundancy, etc.)
And giving Internet access while it's down would mean extra work in
Wifidog (dynamically add a rule to allow people, then when we're back
remove that rules, etc.)
I think we should do it, but we have more important things to fix/add
to wifidog first :)
> The ideal solution is to, of course, have multiple
> geographically-redundant auth servers so we'd never need this, but
> reality (as we've seen this morning) is not the case. And even if it is
> the case for ISF, it may not be the case for all wifidog adopters.
Right.
Well, very good work, I'll definitely test the new changes soon.
The first thing we should look at though is the bug that happens when
the auth server's IP changes because it really sucks to have to restart
all instances ...
Philippe April
-------------- next part --------------
_______________________________________________
wifidog mailing list
wifidog at listes.ilesansfil.org
http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog-listes.ilesansfil.org
More information about the Wifidog
mailing list