Wiki Information

Imagine a non-technical kid that gets a new iPhone for Christmas, takes it to school, then starts up the web browser and accesses the web. With a "transparent-intercepting" configuration, web access is likely to work, and even if it doesn't at least a message can be displayed easily. But with a plain old "explicit-proxy" configuration, the web browser may be totally unresponsive, and the kid will have no idea why or what to do about it.

It's very important to avoid reaching a “dead end” like this.
This one seeming advantage of “transparent-intercepting” configurations is so significant it sometimes outweighs all other considerations put together.

If it was just possible to eliminate this one disadvantage of an “explicit-proxy” configuration… Well, it is possible to make a display that a new/unexpected/naive device will always see no matter what. All that's needed is a “network billboard” that will display a message to even new/unexpected/naive devices (such as the example iPhone). This document describes how to set up such a thing.

In outline, to make a “network billboard” work, we grab all the network packets that go through port 80 on the gateway and send them all into our web server (regardless of where they were originally destined). Then our web server always returns our same document –no matter what path or file was requested.

To do this we need a web server (here we assume Apache) and the IPtables feature of the OS. A more convenient front end to IPtables such as Shorewall is also suggested, but not required.

Most importantly, new/unexpected/naive computers should be usable after they join the network. They should already be able to reach your internal web servers and other internal servers. They will most likely use DHCP, and DHCP should give them at least

a usable IP address

the IP address of the gateway they should use

the IP addresses of the couple of DNS servers your network uses

We want to add a network billboard to an already functioning system. If new/unexpected/naive computers can't yet usefully join the network, fix that first; don't even try to set up a network billboard until network joining works for you. This document is just about setting up a network billboard; it assumes new/unexpected/naive computers can already usefully join the network. If you proceed to try to set up a network billboard even though joining doesn't yet work, you'll just make a bad situation into a horrid situation; it will be very difficult to figure out what's wrong and fix it. Do one thing at a time.

Tweak the web server so it always serves up the same document no matter what the browser requests. Hide well (preferably just delete) all web documents other than “index.html”. Be sure your web server listens only on your internal/LAN interface (the default of listening on all interfaces will open your web service to the general public, which is not what you want). Then in the configuration of the web server (here we assume Apache), find the definition for the main web directory, which is probably a couple screens long and looks something like this:

<Directory "/var/www/html">
.
...
.
.
...
.
</Directory>

(Often the start and end of this section will be on different screens. That's okay, don't try to “fix” it; all you need to do is find it.) Next insert one new line so it now looks something like this:

Use IPtables to cause all web request packets to go to the local web server. (If you've used an IPtables command to prevent users from skipping around your filter, this command should replace it. With this command users still won't be able to skip around the filter, and in addition you'll now have a network billboard.)

If you use the Shorewall front end, insert one additional line in the “rules” file something like this:

REDIRECT loc 80 tcp 80

If you use the command line interface to IPtables, the command will look something like this:

(This command may appear to be very silly, just intercepting packets for port 80 and changing the port to 80 …which it already was. What's really going on is this command changes the destination IP address from whatever it was to the address of the network interface it just arrived on. Thus all traffic –no matter what its original destination– is shunted into the local webserver.)

That's it. Now test it. Bring a new/unexpected/naive computer (such as an iPhone) onto your network. Start its browser and request any old webpage. You should see the “network billboard” you just set up. Follow the directions for accessing the web (what they actually say, not what you “know is right”). Request any old webpage again. This time you should see what you requested.