Disclaimer: there is nothing fancy/clever in this email, as it is just
a quick recap of a method of using a customized captive portal page. I
performed these steps using Linux, but I guess any other operating
system applies (the certification generation part may differ, though).
As more people are willing to offer (un)authenticated access to their
private internet connection through 802.11x, the "Captive Portal"
functionalities of m0n0wall provide an interesting solution.
Here is a way to display a elaborated webpage (instead of the default
page) to the users who want to connect to the network Since we do not
want to rely on a 3rd party server to host the webpage elements
(because that would force us to allow unauthenticated computers to
access a resource on the network), we will use Paul Taylor's excellent
"element manager" which enables m0n0wall to store any element directly
in the configuration file. I used the images available at
http://inf.imelda.be/downloads/m0n0wall/ since they forbid multiple
simultaneous accesses with the same username/password ("Disabled
Concurrent Logins" option). We also want to prevent username/password
theft (which could lead to a malicious network access), so the
connection between the client browser and the m0n0wall host needs to
1/ Setup the webpage. A typical webpage relies on many elements:
- the HTML file itself
- flash/java elements (eww)
- CSS files
Be careful to link the external elements with a local relative path
(eg: src="img.png", not src="/assets/img.png"), although I haven't
tried the latter solution.
You can use "big" images if you want (after all, since it's local you
have enough bandwidth), but keep in mind that the images will be
stored encoded in the config file, and loaded in RAM, so you should'nt
the HTML file itself, it is generally considered a good practice to
use separate files.
1.a/ As m0n0wall can only host one file for the Captive Portal
authentication page (you cannot use many pages, or a small website
with forms and contact pages), you need to use a bit of CSS +
the user to agree to the "acceptable use policy", you may want to hide
it by default (because it is huge and would render ugly), but the user
should be able to access it easily. You may as well want to remember
experience" (whatever that means). Be aware that no forms (other than
the login form) can be used on the page without relying on an external
server to process the form data.
I designed a static example page of which I can send you an archive if
you wish. Some screenshots of the webpage will be available here (in
a few hours):
2/ List all the external elements needed by the webpage (images, CSS
and so on). Do not forget the images loaded by the CSS code.
3/ Modify the webpage so the "element manager" will detect any
external files needed. To do so, if an external element is *not*
loaded through an <img src="foo" /> tag, add a comment somewhere in
the HTML file. For example if the CSS loads an image called "bg.png",
add this in the <body> section of the HTML file.
<!-- Image needed by the CSS file
<img src="bg.png" />
Do this for any element listed in 2/
4/ Upload the captive portal authentication page through the m0n0wall interface
5/ Upload the external element in the "Element manager" page. Check
that all elements listed in 2/ are detected. If not, go back to 3/
6/ Create and upload SSL Certificates. This will enable the client to
submit encrypted username/password during the authentication phase.
$ openssl genrsa 2048 > captiveportal.key
$ openssl req -config /var/lib/ssl/openssl.cnf -new -key
captiveportal.key > captiveportal.csr
Remarks: Regarding the "openssl.cnf" location, your mileage may vary.
Answer the questions (be careful with the common name (CN): it should
match the captive portal name, eg portal.foo.bar). Do not enter any
$ openssl x509 -req -days 365 -in captiveportal.csr -signkey
captiveportal.key -out captiveportal.crt
This certificate will be valid one year
Paste both "captiveportal.key" and "captiveportal.crt" in the
appropriate field of the m0n0wall captive portal page, activate the
use of SSL (which will be used even if you rely on the local user
7/ Test the captive portal page and enjoy! :-)
You may want to do the same for the error page as well (except for the
SSL generation part of course).
Hope this will help some of you.
Thanks to all the contributors (especially Paul Taylor) for the amazing work.