[isf-wifidog] Gateway development

Lun 14 Nov 16:52:14 EST 2011

I can confirm that the use of DNS works in iptables. For example:
iptables -t nat -I WalledGarden -m state --state
NEW,ESTABLISHED,RELATED,INVALID -d "www.google.com" -j ACCEPT --p tcp
-dport 80

Allows everything on tcp port 80 to www.google.com which is more than
1 ip address.

This is a hack that I used before implementing a full blown proxy
server and moving the wifidog gateway to a central box. I had a script
run via cron that used wget to get a list of iptables rules for the
walled garden and then applied them to the wifidog gateway. It was a
fragile process at best but did work.

I agree that it should be the service providers who decide to enable
mac white listing, if you were very concerned about security a hotspot
controller of any type would not be what you rely on for access
control. 802.1x would be what you would use. The reason why
browserless (tokenless) logins are appealing is we are seeing more and
more mobile devices that use wifi. Our users like to complain that it
is a big pain to have to open up a web browser on their [phone,
tablet, nook, kindle] to get internet access. I do see their point
everybody is expecting always connected wifi everywhere around campus.
I think this problem is only going to worsen into the future so it
might be wise to address it now.

Thanks,
 _
/-\ ndrew

On Mon, Nov 14, 2011 at 1:21 PM, acv <acv at miniguru.ca> wrote:
> On Mon, Nov 14, 2011 at 12:17:31PM -0700, Andrew Niemantsverdriet wrote:
>>
>> Yes, you can kinda have a walled garden working. However it is a huge
>> pain in the butt to do, since it is done in the conf file that means
>> each AP has to be touched. Also the conf file does not play nice with
>> domain names (even though iptables can) so for example allowing a
>> walled garden entry of google.com would involve adding 20 IP's that
>> change depending geographic location and loads on each server. This is
>> not practical at all.  What I am proposing is a mechanism to allow the
>> server to keep a central central list of URL's that is used by the
>> gateway to determine if a URL should be allowed or not.
>
>        That should be addressable in two parts. One for downloading some
> of the config from the auth server and the other to make sure use of DNS
> in iptables works. At the moment, I'm keeping this out of my scope for the
> "1.5" protocol but that's in the plan for the next step. Remotely managed
> configuration is one of the desired "2.0" feature.
>
>> For browser-less authentication there has been some talk about it here:
>>
>> http://dev.wifidog.org/wiki/doc/developer/SupportingDevicesWithNoWebBrowser
>>
>> At the bottom it mentions v2 of the protocol. What I want to see is a
>> way for the Wifidog server be able to maintain a whitelist of MAC's
>> that are allowed to connect. That along with the walled garden
>> approach above would eliminate many of the problems I am seeing with
>> things like xbox's and nintendo's trying to connect up wireless and
>> being unable to.
>
>        What I don't like about most of these is the reliance on a MAC address
> whitelist. Or worse, a "white range". But that's for the service provider (i.e.:
> you) to decide if that's an acceptable security stance. What would be needed to
> get on-demand MAC based auth going would be to use DHCP to drive a login event
> and forgo the token altogether. So yeah, "2.0" feasible although it would be
> significant which dhcpd is used and how it's configured.
>
> Alex
>
>>
>> Thanks,
>>  _
>> /-\ ndrew
>>
>> On Mon, Nov 14, 2011 at 11:38 AM, acv <acv at miniguru.ca> wrote:
>> > On Mon, Nov 14, 2011 at 11:16:09AM -0700, Andrew Niemantsverdriet wrote:
>> >>
>> >> I have looked over the new protocol and am liking what I see. Some
>> >> things that I would like to see implemented is walled gardens and a
>> >> sane way to handle clients that don't have a browser.
>> >
>> > The lack of browser I am not sure... This falls a bit out of the bound of your
>> > typical captive portal. I might need help to see a scenario where the gateway
>> > can do /anything/.
>> >
>> > For the walled garden, can you flesh out the ideal use case for me? There is
>> > already some support for that in terms of the different user classes and the
>> > configurable firewall rules. The protocol is already able to handle that case
>> > although admittedly this might not be properly configurable. With a better
>> > use case I'd be able to better see what gateway side improvement might be
>> > needed.
>> >
>> > Alex
>> >
>> >> I can offer my network for testing. It is not huge but big enough... I
>> >> have 27 access points and max out at 200 on at one time. The average
>> >> is lower but I don't know what that is since I don't have any metrics
>> >> for that. Contact me off list if you are interested.
>> >>
>> >> Thanks,
>> >>  _
>> >> /-\ ndrew
>> >>
>> >> On Thu, Nov 10, 2011 at 7:45 PM, acv <acv at miniguru.ca> wrote:
>> >> > Hi All,
>> >> >
>> >> > I have been spending a bit more time working on the gateway and I have drafted a
>> >> > proposal for a protocol to replace the current ad-hoc protocol. This first proposal
>> >> > is more of an interim protocol to pave the way for new features since it doesn't
>> >> > implement any truly "new" functionalities but it is readily extensible.
>> >> >
>> >> > Specifications can be found here:
>> >> >
>> >> > https://bitbucket.org/acv/wifidog-ng/wiki/ProtocolV1.5
>> >> >
>> >> > I believe anyone should be able to edit this wiki page (may need a free bitbucket
>> >> > account).
>> >> >
>> >> > I figure I could have this implemented by Christmas or so given my current spare time.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Alexandre
>> >> >
>> >> > _______________________________________________
>> >> > WiFiDog mailing list
>> >> > WiFiDog at listes.ilesansfil.org
>> >> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>> >> >
>> >> _______________________________________________
>> >> WiFiDog mailing list
>> >> WiFiDog at listes.ilesansfil.org
>> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>> >
>> > _______________________________________________
>> > WiFiDog mailing list
>> > WiFiDog at listes.ilesansfil.org
>> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>> >
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>