How our DHCP registration portal redirections work

September 25, 2009

Like other places, we have an automatic DHCP registration portal (to use the term I've heard). In the abstract, you plug your new laptop into our laptop network, try to visit some website, and instead wind up on a registration web page. You supply your local login and password, the machine you're using is registered as yours, and then you can go on to get Internet access.

(Some registration portals will automatically send you on to whatever website you were trying to visit. Ours was a quick hack, so we don't try to support that.)

There's a slightly complicated dance of redirections involved in the web server portion of this process, so here's how it works. First, there's three IP addresses involved; let's call them Inside-1, Inside-2, and Outside. The two Inside addresses are on our laptop network and the Outside IP is a public IP on our normal network. Conceptually, separate web servers run on each IP (practically, it is one Apache instance with three IP-based virtual hosts).

Then:

  • on Inside-1, there is a http server that gives temporary redirects to the public name of our registration portal. Some magic arranges for unregistered DHCP clients to be told that this name's IP address is Inside-2.

  • on Inside-2 there is a http and a https server. The https server has the registration portal; the http server redirects to the https server.

  • on Outside, there is both a http and an https web server that redirect visitors to our non-portal DHCP registration system. The public name of our registration portal points here.

We need two inside IPs because we need people's attempts to talk to random https URLs to fail outright. If someone asks for https://somesite/ and we actually give them something to talk to, there is no way to avoid them getting a scary certificate mismatch warning; this is either unnecessarily alarming or bad training for our users or both. Thus, it's better that their browsing fail with a 'website not responding' browser error, and the only fully reliable way to get that is to have an IP address that has no https server on it at all.

In theory one could shim in the initial portal web page by just having Outside-1 reply to all requests with it. There's two reasons not to do this; first, we need to redirect to an https page at some point anyways, and second, I expect that there's client software that doesn't like it when it requests some URL that it expects to be in some specific format and instead gets an HTML page. A feed reader that polls feeds on startup (or when a network connection appears) might get quite upset, for example. Such software may still malfunction when given a temporary HTTP redirection, but at least we've tried to do the proper thing.

(I suppose there's a third reason: if you do it by shimming in a page, you're training your users to expect internal administrative web pages to appear on random external URLs. This sounds like a gift to phishers to me.)

Theoretically we don't need a webserver on Outside, but I was concerned that people would turn 'go to this website name to get registered' into local folklore and then try to apply it even when they were outside the laptop network. Since the machine needed an outside IP address anyways, it seemed friendlier to run a webserver there.

Written on 25 September 2009.
« SSL certificates require proper domain names
How our 'plug in and go' laptop network DHCP portal works »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 25 00:03:10 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.