I'd be most interested to discuss the subject of captive portal solutions on OpenWRT, and more specifically how they compare with other low-cost solutions e.g. Mikrotik and UBNT.

In the past few years I've installed/tested over a dozen FOSS captive portal solutions (just about every FOSS router/firewall distro includes one, from m0n0wall to ZeroShell). Additionally all commercial Wifi vendors from Cisco / Meraki to Ruckus and Aruba also include a CP solution.

I noticed there are several CP packages for OpenWRT (e.g. coova, wifidog, nodogsplash, nocatsplash, luci-splash), but most haven't been updated in years and I'm not quite sure how well these packages would actually work in a actual Wifi hotspot deployment with more than a handful users, since in recent years most OSes (notably mobile devices) have been changing their behavior when connecting to Wifi hotspots, breaking previous conventions.

TIA.

Following the philosophy of "If it aint broke, don't f*** with it" I don't understand the incessant need for all software to be constantly updated. Other than to perhaps justify having a job for the developer.

I haven't seen any real changes on mobile OSs of how they behave when connecting to Wifi hotspots and the changes I have seen make them work better with previous conventions.

And frankly some of the open source ones work better than the fudgey mess that is the Cisco captive portal...

(Last edited by qasdfdsaq on 3 Jun 2014, 16:49)

Would be very much interested to in that matter.

Last one i tried was wifidog/authpuppy combo.

Too much flaws with outaged Symphony php framework and no proper docs.

I did even plan to let someone rewrite and document it properly ( code & user ) but until now would have been too expensive investment for me.

Myself haven't got the time and php knowledge for a project like that.

Some years ago coova with external AAA was nice but AFAIK not possible any more.

Still look around for some decent FOSS system for 10-100 users

regards
3zl

Well, if you go check forums for IT professionals at educational institutions which deploy larger Wifi hotspots for BYOD (e.g. educause or edugeek), you'll find many discussions about how new mobile OSes brought in by users were incompatible with their existing hotspot solutions (by Cisco, Aruba etc) necessitating updates, so your statement above is demonstrably not true ...

(Last edited by kpv on 3 Jun 2014, 19:17)

Why, what happened to Coova(Chilli) ? It's been 3 years since I last used it.

I noticed there are a couple of patches for the OpenWRT coova package, which were submitted by Coova developer, which don't seem to be included in the coova-chilli_1.3.0-5 package.

Right, there are decent solutions for larger hotspots, but for small/medium-sized hotspots up to 100 users I'm still looking / testing ...

(Last edited by kpv on 3 Jun 2014, 19:01)

Except I am an IT professional at an educational institution who runs around 2500 wifi access points with over 12,000 daily users.

Windows 8 caused more problems than mobile devices. We've had next to zero complaints from mobile users (service desk stats) and the few we've had were mostly down to faulty devices. Our Cisco WiSMs had to be updated for Vista, then Windows 7, then a few years later for Windows 8, and then again for 8.1 compatibility but never for any mobile platform. I've heard similar stories from other institutions running Juniper kit but not so much Aruba. Then again I find Cisco's level 3 TAC demonstrably more useful than some odd randomers on forums but hey, who am I to tell.

I'm not sure what "new mobile OSs" you're referring to but there have been nada issues caused by recent updates to Android, Crackberry works just fine on enterprise deployments as always and iOS is dealt with by someone else so I wouldn't know. Windows phone we have too few clients running to make any real judgements.

There's also far more problems caused by changes to web services, e.g. Google, Facebook, Youtube but those are nothing to do with the mobile OSs people access them from, the same problems occur on a Windows PC.

(Last edited by qasdfdsaq on 3 Jun 2014, 20:30)

Nice to see two experts with alot of experience but please dont fight!

Everybody has his field of expertise, so we'd better get it together and learn something from it.

I just had a look at "Authpuppy" again and made a call at freelancers to revise and transport the code to Symfony 2.5, together with a decent structure/program/user dokumentation.

I will see how much they charge and keep you posted if there is any interest.

Any recommendations where to put a project like this ( besides github ? )

regards
3zl

(Last edited by 3zl on 5 Jun 2014, 14:25)

I think along with a new version of authpuppy, also a new version of wifidog could be helpful, for example to adapt the use of social networks login and support of white listed domains (insted of fixed ip ranges)

I did see it mentioned in another thread that the current captive portals have issues with social media logins (something that wasn't around when they were designed), and that's possibly one of the few reasons I can think of to update. I'm yet to see any concrete examples of a "change in behaviour" of modern mobile OSs that "breaking previous conventions", but then again I don't deal with iOS since iOS breaks so many conventions that we're close to barring Apple devices from parts of our network completely (deliberately stealing IPs of other devices as a default behaviour?! I mean, come on, seriously?!).

Now to be fair I personally don't trust these social media login extensions most of the time regardless, and would be even less inclined to trust said details to a public hotspot run by some random organisation I have no ties with.

Not knowing the technical details of how these social media login systems work, based on other people complaining they use "4k different IPs" I don't see why current captive portals can't handle them simply with a subnet based whitelist. Assuming thsoe 4k IPs are in distinct subnets, then then setting the rules gets more difficult and obviously since IPTables is, as the name would imply, IP based and not DNS based, you would need some sort of userspace handler for the login stage, which would not be trivial to implement.

The easiest workaround IMO would probably be to have the pre-login traffic all forwarded to a transparent proxy such as Squid or Apache that can filter by either forward or reverse DNS, and also passes SSL traffic properly in order to not break encrypted sessions.

(Last edited by qasdfdsaq on 4 Jun 2014, 12:49)

There is a DNS proxy called "ipset-dns" which populates an ipset with all received A or AAAA records for a resolved domain. This proxy is intended to be used as upstream server for dnsmasq using a directive like "server=/facebook.com/127.0.0.1#53001" in dnsmasq.conf.

The autopopulated ipset can then be used in iptables matches to selectively handle particular domains.
Take a look at http://git.zx2c4.com/ipset-dns/about/

For this to work correctly you must however force all DNS lookups through your local dnsmasq using REDIRECT rules, even if the client tries to use a public DNS server explicitely.

A while ago I did a quick writeup on a "domain based" policy routing, this can be adapted to the op's use case. Instead of setting fwmarks, one could make it an ACCEPT rule or whatever is needed to bypass the captive portal.

https://forum.openwrt.org/viewtopic.php … 97#p207497

Thanks for that tutorial.

It seems to me that the ipset-dns functionality might also be suited for other tasks e.g. one could selectively allow access only to certain cloud apps (e.g. GoogleApps, Outlook365 etc) but block general Internet access, without having to manually maintain IP block ranges (which is possible for GoogleApps that us using Google's own IP ranges, but not possible for other SaaS that use popular CDNs).

(Last edited by kpv on 4 Jun 2014, 18:35)

Does anybody know if the dnsmasq option

--ipset=/<domain>/[domain/]<ipset>[,<ipset>]
    Places the resolved IP addresses of queries for the specified domains in the specified netfilter ip sets. Domains and subdomains are matched in the same way as --address. These ip sets must already exist. See ipset(8) for more details.

is build in the current Openwrt dnsmasq version ?

Any report if it works ?

regards
3zl

Apparently ipset is not built into dnsmasq, according to a quick test:

root@OpenWrt:/etc/config# dnsmasq --version
Dnsmasq version 2.71  Copyright (c) 2000-2014 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC

At the UBNT forums, there are reports about large-scale hotspots using CoovaChilli e.g.

Re: City Wide wifi 500+ UAP's on one network
Virtual Server: 2x CPU 2599MGz
RAM 8 Gb
HDD 80 Gb
OS: Ubuntu 12.04-server LTS.
UniFi-Controller 3.2.1
20 Sites
593 Access Points
590 working in Layer2
Hot-Spot: Coova Chilli

Src:
http://community.ubnt.com/t5/UniFi/City … 88#U883188
http://community.ubnt.com/t5/UniFi-Stor … s-p/847894

Just modifying the FW of  open-mesh.com APs to be used with coova-chilli/Radius.
Looks good for small number of users, as the HW is a bit slow. For higher numbers of clients, I would use pcengines.ch APUs, running full LINX, like voyage, for example.