How do captive portals work?
It's an everyday scenario: you go to a hotel or Wi-Fi hotspot and find a wireless or wired connection, but instead of getting your homepage when you bring up your browser, you get a custom page from the service provider asking you to pay for the service. You've hit a captive portal, and it's how the service provider makes sure that they get paid for what they are offering.
The technology is relatively simple because you are, by definition, using their network. They configure their systems to accept your initial network traffic (in this case, your request for Web content from your homepage's server) but instead of passing that request along, they redirect you to their sign-in page. This redirection can be done in a number of ways, but the basic functionality is built into the HTTP standard (the status codes in the 300-range describe the various options). Any non-web traffic, such as SMTP for email, or FTP, is typically blocked using a firewall of some type, but may be caught and redirected by a particularly sophisticated captive portal.
Once you sign in and pay up, the captive portal stops interfering with your traffic, and reverts to the usual 'pass through' mode. The next time you try to connect, it checks your identity (usually by looking at your machine's relevant MAC address) and silently let you through if you are still in the time-window of service. Otherwise, it's back to square one.
So, to summarise, the captive portal provider needs: a redirection mechanism for Web traffic, a traffic-blocking mechanism of some sort (firewall, 802.1x, etc) to constrain you, a sign-in facility, a payments gateway of some sort, and some form of identity repository for keeping track of who is a paid-up known customer and who is not. None of these components are particularly obscure or difficult to find, but if you are looking to build a captive portal you probably shouldn't try to reinvent the wheel. You can find complete packaged hardware-and-software solutions from the usual suspects (Cisco, Juniper, etc), as well as smaller-scale software solutions from multiple vendors. If you want to use free and open-source software, you'll easily be able to find many solutions on-line.
Tim Cranny is Chief Architect at Senforce Technologies. He is also an editorial board member of the Wireless Vulnerabilities and Exploits project.