How our 'plug in and go' laptop network DHCP portal works

September 26, 2009

As I mentioned in the last entry, we have an internal subnet for laptops and other generic user machines. For various reasons, we require machines on this subnet to be registered so that we can identify who is (theoretically) responsible for them. One of the ways that people can do this is with a 'plug in and go' registration portal; you plug in, try to go somewhere, and you wind up on a simple registration web page instead.

Behind the scenes, it works like this:

  • our DHCP server gives unregistered machines IP addresses from a special subnet. Our internal firewall doesn't allow these IP addresses access to the outside world.

  • as part of the DHCP information, the unregistered machines are pointed at a special DNS server that is essentially a fake DNS server. The DNS server simply has a zone file for ., the root zone, with only two entries; one entry for our registration portal's public name that points to one internal IP, and a wildcard ('*') A record that claims everything else has another internal IP address.

    (In the terms of the last entry, these IP addresses are Inside-2 and Inside-1 respectively.)

  • the two IP addresses that the DNS server tells people about run some web servers, including the registration CGI.

  • the registration CGI gets and validates the user's credentials, picks the Ethernet address of their machine out of the web server's ARP cache, and pokes the DHCP server to get the new machine registered (using a method beyond the scope of this entry).

    (In practice, not having to ask users for their machine's Ethernet address is a big win for all parties.)

  • once registered, users have to renew their DHCP lease (which will cause their machine to get an IP address that can talk to the network, along with a gateway and our proper DNS servers) and flush any cached DNS information they picked up from our fake DNS server. We tell users that the easiest way to do this is to reboot their machine.

In terms of servers, the special fake DNS server and all of the web stuff run on one machine, while the DHCP stuff runs on another (and the firewall is a third machine). This is mostly a historical accident, in that we already had the DHCP server running in production before we started building this registration portal system.

Redirecting people's connections with DNS instead of with firewall magic is much simpler but has some side effects, especially since the machine that responds to the wildcard A record's IP address does have an ssh server. We should probably do some work to make the wildcard record's IP address block access to at least the ssh server.


Comments on this page:

From 159.212.48.139 at 2009-09-29 13:55:01:

Why require them to reboot? We do something similar except for we're using pf on the box that dishes out the dhcp. When a user attempts to access the internet, all of the rules are based on whether or not a ip address is registered in a pf table. If they are not registered they are redirected to a registration page. The page asks for the information, stores it in a database, and then adds the user's ip into the pf table. From there on out, the rules in pf, will cross check the pf table for valid ip's and allow them access. In this case, no reboot or lease renewal is required, and you can configure it to flush the pf table on some sort of time period, for us we flush it at midnight.

This does the same thing without the need for a reboot, and all it requires is the addition of pf, and then use your rules to pass traffic out to your normal firewall.

By cks at 2009-09-29 19:36:55:

The short answer is that we prefer to keep our firewalls as simple as possible. Every mechanism that uses the firewall to intercept traffic requires more complexity and more software on the firewall. We also don't like to change the firewall (since it works and it is very important), and taking this approach avoided having to do anything to it.

I should note that registering a machine is a permanent thing that people only have to do once; it is not something that expires.

Written on 26 September 2009.
« How our DHCP registration portal redirections work
Why you can no longer have an 'invite-your-friends' feature »

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

Last modified: Sat Sep 26 16:08:21 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.