Fun with captive portals

This is the first time we have ever tried to run any sort of captive portal - which is where normal web access to the Internet is redirected to a page telling you that you can't access the Internet!

The two main ways to do this are DNS poisoning (returning wrong entries for DNS queries directing people to the portal) and IP level mapping. We have chosen not to poison DNS, partly because it is "nasty", and things cache it, and partly because it will not work with DNSSEC.

So we are redirecting IP traffic (IPv4 and IPv6, obviously). The good news is that the LNSs allow putting a line in a separate routing table (sort of VRF) which allows us to set a gateway to a FireBrick that can do the re-writes at an IP level. By using a separate VLAN on a linux box we can even present the source IP to the portal web server cleanly.

We are directing web (TCP port 80), DNS (TCP/UDP port 53) and NTP (TCP/UDP port 123) to the portal, but limiting DNS to avoid tunneling, and also locking down the speed of lines that are redirected to avoid any abuse.

The web server itself is redirecting any requests to a portal URL which it then serves. By preserving the source IP we can work out what line it is and so why they are restricted. We are polling the routers and LNSs (FireBricks) with the IP to find where it is going, which should make this 100% reliable for identification, especially where customers have blocks of IP addresses and IPv6 address space and so on.

Then we are offering customers who are over their quota on the new Home::1 tariff a top-up which invoices and issues a DD collection. We can do auto-topup if people want, and just allow slow access to the Internet if they want.

The LNS is then kicked to do an interim accounting update, and the RADIUS accounting spots that the line is now topped up and removes the restrictions and routing table. Within a fraction of a second the service is back in operation.

The whole process, changing routing tables, clamping speed down, and returning to normal, all happens with no change to IP addressing and no drop of the PPP link, which I think is pretty slick.

This all means we are pretty much ready now for existing customers switching over to the new Home::1 tariff, at last. We have to make sure sales and accounts teams are fully up to speed on this, obviously. We have had a few triallists move over already which has allowed testing of the various tools and scripts involved - thank you to all those that have helped out. Hopefully we can launch for new customers next month in plenty of time for Christmas, but anyone that wants it can contact the trials team in the mean time.

For existing customers moving over we have taken the view that we will be as helpful as possible and allow a retrospective change of tariff - crediting the current month's charges and re-issuing as Home::1. However, usage on Home::1 counts from the start of the month also, and any excess usage at the start of the month is charged (at pre-pay, not top-up, rates) from the old tariff to start the month with a clean slate. I think this is about as fair as I can make it, but it does mean people can switch to the new tariff before Christmas. We are, however, expecting to make Christmas week the "special" Christmas period on the old tariff still anyway.

All good fun making this stuff work - it will be interesting to see how customers find it.