CoovaChilli
Coova Chilli Captive Portal for SME 7.x
Maintainer
Daniel B.
mailto:daniel AT firewall-services DOT com
Introduction
CoovaChilli is a (GNU GPL) captive portal based on chillispot. It will allow your SME in server and gateway mode to have a third interface. On this new interface, you can plug AP(s) or switchs, and chilli daemon will act as a dhcp server. Every clients connected on this new "lan" will have to authenticate themeself before coova-chilli allows traffic to pass. Once authenticated, clients will have only web access (http/https). You can customize it. (I recommend the use of a VPN for full Internet access).
The default is to use SME accounts for the authentication, but you can easily add users at the radius level which will only have web access. You can also control the bandwidth used.
smeserver-coova-chilli integrates coova-chilli on your server. There's no panel to configuration it for now, but the configuration is quite easy with some db commands.
Release Notes
- Author: Tuesday, April 8, 2008, by Daniel
- Version: 0.1-1 (beta)
- Tested on: SME 7.3 > current
- Note: Install on SME in server-gateway mode only.
- Warning: This contrib should not be installed on production machines. It is currently (2008-08-23) under development and beta testing. Use at your own risk.
Add a network card
- Step 1: Add a network card
The first step is to add a third network card on your server.
!!! Warning !!! When rebooting, if you have several identical NICs, it is possible that the server has swapped two of them, so you may have to reconfigure your Internal/External interface (login as admin, then configure this server). Once that's finished, you should have a new 'eth2' card not configured (it's ok, you do not need to configure it).
Get and install the rpms
- Step 2: Get and install the rpms:
yum --enablerepo=smecontribs install smeserver-coova-chilli
Set up and activate the service
Step 3: Set up and activate the service
By default, the service is turned off, but the rest of the config should be fine for most installations. To activate the service
db configuration setprop chilli status enabled signal-event chilli-update
- Check that the demon is running
ps aux | grep chilli
which should return something like this:
root 10726 0.7 0.1 5884 2152? Ss Apr07 6:50 /usr/sbin/chilli
Create a group
- Step 4: Create a group "chilli"
In the server-manager, create a group called "chilli", and place in this group all users of the system that you want to give access to the wifi network (or anything you've pluged on eth2).
Attach an AP
- Step 5: Attach an AP on the map eth2
The final step is to connect an AP on the NIC. I'm talking about a AP and not a router. If you have a WiFi router, it is possible to work if these conditions are met:
- Dhcp is disabled on the router
- Lan ports and wlan interface are bridged
- Connect a lan port to eth2
You can also connect a switch to eth2, and add as many AP you want.
Login
Step 6: Connect a client, and try to open a web page, you should fall on a page like this:
List of db parameters
- TCPPort: a port where chilli daemon is listening, normally you do not need to change it
- access: Please, let this private. Setting public, which wouldn't be usefull at all, will open chilli daemon on the WAN port, which can be dangerous.
to not serve anything could jeopardize your server, so please let private.
- defidletimeout: the defined period of inactivity of a client (no traffic) before disconnect.
- defsessiontimeout: maximum duration of a session. After this time (in seconds, as defidletimeout), the client must reconnect
- dhcpif: the physical interface to use, in most cases, it will be eth2
- dns1 and dns2: gives clients the dns servers to use. Here I have placed two public DNS servers.
They should work for everyone, but you can replace them by example by your ISP's DNS
- net: the network range to use. The server uses the first IP available from the network (and thus default 10.1.0.1) and provide customers with addresses in this range.
- radiussecret: the secret shared between the radius server and chilli daemon. For each installation, a radom secret is generated, so you shouldn't have to change it.
- status: there's no trap that defined the state of service, and whether it should be started when the server boots.
- tundev: defines the tun interface to use (chilli mask the real interface eth2 and the system sees the traffic as comming from a tun interface).
By default, tun0, you can change if tun0 is already used for a VPN for example.
- uamallowed: A list of host that will be accessible before authentication. It can be a simple list of host, or a list of the form host: port, or protocol: host, or protocol: Host: port
- uamsecret: a shared secret between the login page and chilli daemon (to encrypt the password). As for radiussecret, the secret is randomly generated for each installation.
After you've changed the configuration, just run the command signal-event chilli-update, it'll re-generate the necessary files and restart the service.
The login page
For the login page, I used part of the project daloradius because it is the easiest to change that I have found. The rpm installs the defaults pages in /opt/chilli.rpmnew. If the directory /opt/chilli doesn't exist, default pages will be copied here also. This way, you can customize pages, and your changes won't be lost on upgrades.
(This will change in futur release, I'll try to make a CGI like the login page of the server-manager)
The authorized group(s)
By default, only members of the group "chilli" have access to the portal. You can change this behavior (rename the authorized group, add WiFi account without SME account, allow only some users, allow several groups, restrict the bandwidth up and down ... etc)
To do so, follow the procedure:
- Create a folder in-custom templates:
mkdir -p /etc/e-smith/custom-templates/etc/raddb/users
- and copy the original template
cp -a /etc/e-smith/templates/etc/raddb/users/40chilli /etc/e-smith/custom-templates/etc/raddb/users
- Now, you can edit it. By default it looks like this:
(
if ($ chilli ( 'status') eq' enabled ') (
OUT = $ <<END;
DEFAULT Group == "chilli", NAS-Identify == "chilli", Auth-Type: = unix
# WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
DEFAULT Group! = "Chilli", NAS-Identify == "chilli", Auth-Type: Reject =
Reply Message = "Your are not allowed member of the group"
END
)
)
- If you want to replace the group "chilli" with "wifi" you only have to change Group == "chilli" by Group == "wifi". Same for Group! = "Chilli"
- If you want to add a guest account without account SME:
(
if ($ chilli ( 'status') eq' enabled ') (
$ OUT = <<END;
guest NAS-Identify == "chilli", Auth-Type: = Local User-Password == 'guest'
WISPr-Bandwidth-Max-Down = 400000, WISPr-Bandwidth-Max-Up = 64000
DEFAULT Group == "chilli", NAS-Identify == "chilli", Auth-Type: = unix
# WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
DEFAULT Group! = "Chilli", NAS-Identify == "chilli", Auth-Type: Reject =
Reply Message = "Your are not allowed member of the group"
END
)
)
This will add a user "guest" , with password "guest" and bandwidth will be restricted to 400kbps (downlink) and 64kbps (uplink)
What authenticated users have access to ?
By default, not much.
Basically once autenticated, users have access to
*DNS outside (udp port 53) *Http outwards through squid (if squid is enabled), http to your server *Https outwards and https to your SME *Ping outwards and your server
- If you want to customize these rules, modify options in the chilli template /etc/e-smith/templates/etc/rc.d/init.d/masq/60ChilliRules
- You can copy it in custom-templates and customize it. I think the rules are fairly simple to understand.
(This will change in futur release, firewall customizations for chilli will be done through db commands)
