[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