Difference between revisions of "CoovaChilli"

From SME Server
Jump to navigationJump to search
(42 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Contrib]]
+
{{Languages}}
 +
 
 +
 
 +
===Maintainer===
 +
[mailto:daniel@firewall-services.com[[User:VIP-ire|Daniel B.]]] from [http://www.firewall-services.com Firewall Services]
  
=Coova Chilli Captive Portal for SME 7.x=
+
=== Version ===
  
==Maintainer==
+
{{ #smeversion: smeserver-coova-chilli }}
[[User:VIP-ire|Daniel B.]]<br/>
+
{{ #smeversion: coova-chilli }}
[http://www.firewall-services.com Firewall Services]<br>
 
mailto:daniel AT firewall-services DOT com
 
  
== Introduction ==
+
=== Description ===
  
 
[http://www.coova.org 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.
 
[http://www.coova.org 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).
+
Once authenticated, clients will have only web access (http/https). Of course, you can customize firewall rules to allow more access, but 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. (a guest account can be enabled/disabled with a key in the db)
 
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. (a guest account can be enabled/disabled with a key in the db)
Line 17: Line 19:
 
You can also control the bandwidth used.
 
You can also control the bandwidth used.
  
'''smeserver-coova-chilli''' integrates coova-chilli on your server. There's no panel for the configuration for now, but the it's quite easy with some db commands.
+
smeserver-coova-chilli integrates coova-chilli on your server. There's no panel for the configuration for now, but the it's quite easy with some db commands.
 
 
== Release Notes ==
 
 
*  Author: Tuesday, April 8, 2008, by Daniel
 
*  Version: 0.2-2
 
*Tested on: SME 7.3 > current
 
  
* Note: Install on SME in '''server-gateway mode only.'''
+
=== Requirements ===
 
+
*Server in server&gateway mode
*'''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.'''
+
*a 3rd network interface
 
 
*[http://forums.contribs.org/index.php?topic=40667.0;all SME Forum Link]
 
 
 
 
 
=== Add a network card ===
 
*Step 1: Add a network card
 
  
 
The first step is to add a third network card on your server.
 
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).
+
{{Warning box|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).
 +
}}
 +
=== Installation ===
  
=== Get and install the rpms ===
+
*install the rpms
*Step 2: Get and install the rpms:
 
  
 
  yum --enablerepo=smecontribs install smeserver-coova-chilli
 
  yum --enablerepo=smecontribs install smeserver-coova-chilli
  
(For now, you may also have to enable the repo smetest as smeserver-coova-chilli requires e-smith-radiusd => 1.0.0-18 which is in smetest repo)
+
*Enable the service
  
=== 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 enable 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
 
  db configuration setprop chilli status enabled
 
  signal-event chilli-update
 
  signal-event chilli-update
  
*Check that the demon is running
+
*Check that the daemon is running
  
 
  ps aux | grep chilli
 
  ps aux | grep chilli
Line 62: Line 50:
 
  root 10726 0.7 0.1 5884 2152? Ss Apr07 6:50 /usr/sbin/chilli
 
  root 10726 0.7 0.1 5884 2152? Ss Apr07 6:50 /usr/sbin/chilli
  
=== Create a group ===
+
*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).
 
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 ===
+
*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:
+
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 make it work if these conditions are met:
  
 
**Dhcp is disabled on the router
 
**Dhcp is disabled on the router
Line 78: Line 64:
 
You can also connect a switch to eth2, and add as many AP you want.
 
You can also connect a switch to eth2, and add as many AP you want.
  
=== Login ===
+
*Login
Step 6: Connect a client, and try to open a web page, you should fall on a page like this:
+
Connect a client, and try to open a web page, you should be redirected on a page like this one:
  
 
[[Image:ChilliLogin-noguest.jpg]]
 
[[Image:ChilliLogin-noguest.jpg]]
Line 88: Line 74:
 
[[Image:Login-with-guest.jpg]]
 
[[Image:Login-with-guest.jpg]]
  
== List of db parameters ==
+
=== 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.
  
*TCPPort: a port where chilli daemon is listening, normally you do not need to change it
+
*'''defidletimeout''': the defined period of inactivity of a client (no traffic) before disconnect (in seconds).
  
*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.
+
*'''defsessiontimeout''': maximum duration of a session. After this time (in seconds, as defidletimeout), the client must reconnect
  
*defidletimeout: the defined period of inactivity of a client (no traffic) before disconnect (in seconds).
+
*'''dhcpif''': the physical interface to use, in most cases, it will be eth2
  
*defsessiontimeout: maximum duration of a session. After this time (in seconds, as defidletimeout), the client must reconnect
+
*'''dhcpstart''': where to start assigning IPs (DHCP range)
  
*dhcpif: the physical interface to use, in most cases, it will be eth2
+
*'''dhcpend''': where to stop assigning IPs
  
*dns1 and dns2: gives clients the dns servers to use. Here I have placed two public DNS servers.
+
*'''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
 
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.
+
*'''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 clients with addresses in this range.
  
*radiussecret: the secret shared between the radius server and chilli daemon. For each installation, a random secret is generated, so you shouldn't have to change it.
+
*'''status''': there's no trap, this key defines the state of service, and whether it should be started when the server boots up.
  
*status: there's no trap that defined the state of service, and whether it should be started when the server boots up.
+
*'''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.
  
*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).
+
*'''uamhomepage''': URL of homepage to redirect unauthenticated users to. If not specified this defaults to the login page
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
+
*'''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
 +
eg:
 +
db configuration setprop chilli uamallowed tcp:contribs.org:80,udp:12.13.14.15:1194
  
*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.
+
*'''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.
  
*AllowedServices: a list of services which will be accessible for chilli clients (see What authenticated users have access to ?)
+
*'''AllowedServices''': a list of services which will be accessible for chilli clients (see What authenticated users have access to ?)
  
*AllowedOutgoing: a list of allowed proto/host/port for the client (see What authenticated users have access to ?)
+
*'''AllowedOutgoing''': a list of allowed proto/host/port for the client (see What authenticated users have access to ?)
  
*RedirectToChilli: a list of IP address which will be redirected to your server. By default, InternalIP and ExternalIP are already redirected to your server. But in some situation (like if your Public IP isn't the same as ExternalIP), this setting can be usefull
+
*'''RedirectToChilli''': a list of IP address which will be redirected to your server. By default, InternalIP and ExternalIP are already redirected to your server. But in some situation (like if your Public IP isn't the same as ExternalIP), this setting can be usefull
 
  db configuration setprop chilli RedirectToChilli 1.2.3.4,5.6.7.8
 
  db configuration setprop chilli RedirectToChilli 1.2.3.4,5.6.7.8
  
*guestAccess: enabled/disabled. If enabled, a radius user will be added with name = guest, password = guest, and a button will be displayed on the login page so guests only have to click on it to get logged in.
+
*'''WebRequests''': direct/squid. Clients will get web access directly or through squid. The default is direct. You can set it to squid if you want to log request, to save some bandwidth, or to filter pages (with squidguard or dansguardian).
 +
 
 +
*'''guestAccess''': enabled/disabled. If enabled, a radius user will be added with name = guest, password = guest, and a button will be displayed on the login page so guests only have to click on it to get logged in.
  
*guestDownLink: if guestAccess is enabled, this will limit the downlink bandwidth for the guest (in kbps)
+
*'''guestDownLink''': if guestAccess is enabled, this will limit the downlink bandwidth for guest user (in kbps)
  
*guestUpLink: if guestAccess is enabled, this will limit the uplink bandwidth for the guest (in kbps)
+
*'''guestUpLink''': if guestAccess is enabled, this will limit the uplink bandwidth for guest user (in kbps)
 +
 
 +
*'''noc2c''': can be enabled or disabled (default is enabled). If enabled, clients will get a /32 netmask, and a special route will be added so they can contact the gateway. This prevent direct client to client communication. Note that it's a layer 3 isolation, a better way to prevent client to client is a layer 2 isolation, some AP and switch provides this.
 +
 
 +
*'''macallowed''': A comma separated list of MAC addresses which won't need to authenticate
  
 
After you've changed the configuration, just run the command  
 
After you've changed the configuration, just run the command  
Line 134: Line 132:
 
it'll re-generate the necessary files and restart needed services.
 
it'll re-generate the necessary files and restart needed services.
  
== The login page ==
+
=== The login page ===
  
 
The login page is a mix of the CGI provided with chillispot and some modifications of other login pages.
 
The login page is a mix of the CGI provided with chillispot and some modifications of other login pages.
Line 149: Line 147:
 
*/opt/chilli/css/sme.css    : This CSS file is used to choose the background color, font class, logo etc... It can be customized, it won't be overriden on upgrades
 
*/opt/chilli/css/sme.css    : This CSS file is used to choose the background color, font class, logo etc... It can be customized, it won't be overriden on upgrades
  
== The authorized group(s) ==
+
=== The authorized group(s) ===
  
 
By default, only members of the group "chilli" have access to the portal. You can change this behavior
 
By default, only members of the group "chilli" have access to the portal. You can change this behavior
Line 155: Line 153:
 
several groups, restrict the bandwidth up and down ... etc)
 
several groups, restrict the bandwidth up and down ... etc)
  
To do so, follow the procedure:
+
To do so, follow the procedure:
 
   
 
   
*Create a folder in-custom templates:
+
*Create a folder in templates-custom:
  
  mkdir -p /etc/e-smith/custom-templates/etc/raddb/users
+
  mkdir -p /etc/e-smith/templates-custom/etc/raddb/users
  
 
*and copy the original template
 
*and copy the original template
  
  cp -a /etc/e-smith/templates/etc/raddb/users/40chilli /etc/e-smith/custom-templates/etc/raddb/users
+
  cp -a /etc/e-smith/templates/etc/raddb/users/40chilli /etc/e-smith/templates-custom/etc/raddb/users
  
 
*Now, you can edit it. By default it looks like this:
 
*Now, you can edit it. By default it looks like this:
Line 175: Line 173:
 
         $uplink = $uplink * 1000;
 
         $uplink = $uplink * 1000;
 
         $OUT =<<END;
 
         $OUT =<<END;
  guest NAS-Identify == "chilli", Auth-Type: = Local User-Password == 'guest'
+
  guest NAS-Identify == "localhost", Auth-Type: = Local User-Password == 'guest'
 
       WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
 
       WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
 
  END
 
  END
 
  if (($chilli{'status'} || 'disabled') eq' enabled ') {
 
  if (($chilli{'status'} || 'disabled') eq' enabled ') {
 
     $OUT = <<END;
 
     $OUT = <<END;
  DEFAULT Group == "chilli", NAS-Identify == "chilli", Auth-Type: = unix
+
  DEFAULT Group == "chilli", NAS-Identify == "localhost", Auth-Type: = unix
 
  # WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
 
  # WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
 
   
 
   
  DEFAULT Group! = "chilli", NAS-Identify == "chilli", Auth-Type: Reject =
+
  DEFAULT Group! = "chilli", NAS-Identify == "localhost", Auth-Type: Reject =
 
         Reply Message = "Your are not allowed member of the group"
 
         Reply Message = "Your are not allowed member of the group"
 
  END
 
  END
Line 199: Line 197:
 
         $uplink = $uplink * 1000;
 
         $uplink = $uplink * 1000;
 
         $OUT =<<END;
 
         $OUT =<<END;
  guest NAS-Identify == "chilli", Auth-Type: = Local User-Password == 'guest'
+
  guest NAS-Identify == "localhost", Auth-Type: = Local User-Password == 'guest'
 
       WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
 
       WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
 
  END
 
  END
 
  if (($chilli{'status'} || 'disabled') eq' enabled ') {
 
  if (($chilli{'status'} || 'disabled') eq' enabled ') {
 
     $OUT = <<END;
 
     $OUT = <<END;
  DEFAULT Group == "'''wifi'''", NAS-Identify == "chilli", Auth-Type: = unix
+
  DEFAULT Group == "'''wifi'''", NAS-Identify == "localhost", Auth-Type: = unix
 
  # WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
 
  # WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
  DEFAULT Group! = "'''wifi'''", NAS-Identify == "chilli", Auth-Type: Reject =
+
  DEFAULT Group! = "'''wifi'''", NAS-Identify == "localhost", Auth-Type: Reject =
 
         Reply Message = "Your are not allowed member of the group"
 
         Reply Message = "Your are not allowed member of the group"
 
  END
 
  END
Line 212: Line 210:
 
  }
 
  }
  
 
+
=== What authenticated users have access to ? ===
== What authenticated users have access to ? ==
 
  
 
By default, not much.
 
By default, not much.
Line 219: Line 216:
 
Basically once authenticated, users have access to
 
Basically once authenticated, users have access to
  
*DNS outside (udp port 53)
+
*DNS outside (udp port 53)
*Http outwards through squid (if squid is enabled), http to your server
+
*Http outwards (through squid if squid is enabled and WebRequests set to squid), http to your server
*Https outwards and https to your SME
+
*Https outwards and https to your SME
*Ping outwards and your server
+
*Ping outwards and your server
  
 
There are two key in the db to customize this:
 
There are two key in the db to customize this:
Line 229: Line 226:
 
Services names need to correspond to those defined in the configuration db
 
Services names need to correspond to those defined in the configuration db
  
'''Note''': This will just open the corresponding port(s), you need to make sure the service listen on the correct interface.
+
{{Note box|This will just open the corresponding port(s), you need to make sure the service listen on the correct interface.}}
  
*AllowedOutgoing will allow more outgoing traffic. It's list of proto/host/port clients will be able to contact on the internet (These rules only apply to forwarded traffic, nothing will be allowed to the private network). Wildcard '*' (or keyword any) can replace host or port. Eg:
+
*AllowedOutgoing will allow more outgoing traffic. It's a list of proto/host/port clients will be able to contact on the internet (These rules only apply to forwarded traffic, nothing will be allowed to the private network). Wildcard '*' (or keyword 'any') can replace host or port. Eg:
  db configuration setprop AllowedOutgoing tcp:56.23.41.1:25,udp:*:1194,tcp:4.5.6.7:any,tcp:any:123
+
  db configuration setprop chilli AllowedOutgoing tcp:56.23.41.1:25,udp:*:1194,tcp:4.5.6.7:any,tcp:any:123
  
 
This will allow:
 
This will allow:
Line 240: Line 237:
 
*Any host will be accessible on port 123 with tcp
 
*Any host will be accessible on port 123 with tcp
  
'''Note''': proto can be tcp or udp only for now, there's now way to add icmp rules with db commands for now.
+
{{ Note box|proto can be tcp or udp only for now, there's now way to add icmp rules with db commands.}}
  
== Troubleshoot ==
+
=== Troubleshoot ===
  
 
If the contrib doesn't work, check in the order:
 
If the contrib doesn't work, check in the order:
Line 257: Line 254:
 
If you get an error, check the log /var/log/messages
 
If you get an error, check the log /var/log/messages
 
*Check tun0 (or what you have configured as tundev) is up, with a valid ip
 
*Check tun0 (or what you have configured as tundev) is up, with a valid ip
  ifconfig
+
  ifconfig tun0
 
*Check the client gets a ip in the range 10.1.0.0/24 (or what ever you have configured as net)
 
*Check the client gets a ip in the range 10.1.0.0/24 (or what ever you have configured as net)
 
If it's not the case, check that the AP is working properly (tcpdump on tun0 to check that your server sees dhcp requests). You can try to connect your client directly to eth2 with a crossed cable to eliminate an AP or wifi-level issue
 
If it's not the case, check that the AP is working properly (tcpdump on tun0 to check that your server sees dhcp requests). You can try to connect your client directly to eth2 with a crossed cable to eliminate an AP or wifi-level issue
 
*Check your client can use DNS. If you get a timeout when you try to open a web page from the client, it's possible that the problem comes from some DNS issue. Try to enter an ip in your browser, even a fake on (http://11.12.13.4/ for example), if you see the login page, then, you should try to configure the DNS of your ISP in the db
 
*Check your client can use DNS. If you get a timeout when you try to open a web page from the client, it's possible that the problem comes from some DNS issue. Try to enter an ip in your browser, even a fake on (http://11.12.13.4/ for example), if you see the login page, then, you should try to configure the DNS of your ISP in the db
 
  db configuration setprop chilli dns1 <ip> dns2 <ip>
 
  db configuration setprop chilli dns1 <ip> dns2 <ip>
 +
 +
=== Uninstall ===
 +
yum remove smeserver-coova-chilli coova-chilli
 +
 +
=== Bugs ===
 +
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]
 +
and select the smeserver-coova-chilli component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-coova-chilli|title=this link}}
 +
 +
----
 +
[[Category:Contrib]]
 +
[[Category:Administration:Remote Access]]

Revision as of 09:43, 7 March 2012



Maintainer

Daniel B. from Firewall Services

Version

Alpha 10:
Contrib 9:
smeserver-coova-chilli
The latest version of smeserver-coova-chilli is available in the SME repository, click on the version number(s) for more information.


Alpha 10:
Contrib 9:
coova-chilli
The latest version of coova-chilli is available in the SME repository, click on the version number(s) for more information.


Description

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). Of course, you can customize firewall rules to allow more access, but 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. (a guest account can be enabled/disabled with a key in the db)

You can also control the bandwidth used.

smeserver-coova-chilli integrates coova-chilli on your server. There's no panel for the configuration for now, but the it's quite easy with some db commands.

Requirements

  • Server in server&gateway mode
  • a 3rd network interface

The first step is to add a third network card on your server.


Warning.png 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).


Installation

  • install the rpms
yum --enablerepo=smecontribs install smeserver-coova-chilli
  • Enable the service

By default, the service is turned off, but the rest of the config should be fine for most installations. To enable the service:

db configuration setprop chilli status enabled
signal-event chilli-update
  • Check that the daemon 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

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

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 make it work if these conditions are met:

    • Dhcp is disabled on the router
    • Lan ports and wireless 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

Connect a client, and try to open a web page, you should be redirected on a page like this one:

ChilliLogin-noguest.jpg


Or like this if guest access is enabled

Login-with-guest.jpg

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.
  • defidletimeout: the defined period of inactivity of a client (no traffic) before disconnect (in seconds).
  • 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
  • dhcpstart: where to start assigning IPs (DHCP range)
  • dhcpend: where to stop assigning IPs
  • 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 clients with addresses in this range.
  • status: there's no trap, this key defines the state of service, and whether it should be started when the server boots up.
  • 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.

  • uamhomepage: URL of homepage to redirect unauthenticated users to. If not specified this defaults to the login page
  • 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

eg:

db configuration setprop chilli uamallowed tcp:contribs.org:80,udp:12.13.14.15:1194
  • 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.
  • AllowedServices: a list of services which will be accessible for chilli clients (see What authenticated users have access to ?)
  • AllowedOutgoing: a list of allowed proto/host/port for the client (see What authenticated users have access to ?)
  • RedirectToChilli: a list of IP address which will be redirected to your server. By default, InternalIP and ExternalIP are already redirected to your server. But in some situation (like if your Public IP isn't the same as ExternalIP), this setting can be usefull
db configuration setprop chilli RedirectToChilli 1.2.3.4,5.6.7.8
  • WebRequests: direct/squid. Clients will get web access directly or through squid. The default is direct. You can set it to squid if you want to log request, to save some bandwidth, or to filter pages (with squidguard or dansguardian).
  • guestAccess: enabled/disabled. If enabled, a radius user will be added with name = guest, password = guest, and a button will be displayed on the login page so guests only have to click on it to get logged in.
  • guestDownLink: if guestAccess is enabled, this will limit the downlink bandwidth for guest user (in kbps)
  • guestUpLink: if guestAccess is enabled, this will limit the uplink bandwidth for guest user (in kbps)
  • noc2c: can be enabled or disabled (default is enabled). If enabled, clients will get a /32 netmask, and a special route will be added so they can contact the gateway. This prevent direct client to client communication. Note that it's a layer 3 isolation, a better way to prevent client to client is a layer 2 isolation, some AP and switch provides this.
  • macallowed: A comma separated list of MAC addresses which won't need to authenticate

After you've changed the configuration, just run the command

signal-event chilli-update

it'll re-generate the necessary files and restart needed services.

The login page

The login page is a mix of the CGI provided with chillispot and some modifications of other login pages. You can customize it.

  • /etc/e-smith/templates/etc/httpd/conf/httpd.conf/98chilli : This file is the template for apache, you can create a custom-template if you want to modify it (add php support, etc...)
  • /opt/chilli/cgi-bin/hotspot-login.cgi : This is the main CGI, you can customize it, it won't be overriden on upgrades.
  • /opt/chilli/hotspotlogin-conf.pl : This file contains some configuration for the hotspot (domain name, contact info, uamsecret, guestaccess). This file is templetized, so if you need to make some change, you should create a custom-template for /etc/e-smith/templates-custom/opt/chilli/hotspotlogin-conf.pl
  • /opt/chilli/lang : This directory contains language files. English and French are provided, but you can add other if you want (contact me if you make a new translation, I'll integrate it in the package). You can edit all the language file, they won't be overriden on upgrades.
  • /opt/chilli/css/sme.css : This CSS file is used to choose the background color, font class, logo etc... It can be customized, it won't be overriden on upgrades

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 templates-custom:
mkdir -p /etc/e-smith/templates-custom/etc/raddb/users
  • and copy the original template
cp -a /etc/e-smith/templates/etc/raddb/users/40chilli /etc/e-smith/templates-custom/etc/raddb/users
  • Now, you can edit it. By default it looks like this:
{
if ((($chilli{'status'} || 'disabled) eq 'enabled') &&
       ($chilli{'guestAccess'} || disabled) eq 'enabled'){
       my $downlink = $chilli{'guestDownLink'} || '400';
       my $uplink = $chilli{'guestUpLink'} || '64';
       $downlink = $downlink * 1000;
       $uplink = $uplink * 1000;
       $OUT =<<END;
guest NAS-Identify == "localhost", Auth-Type: = Local User-Password == 'guest'
      WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
END
if (($chilli{'status'} || 'disabled') eq' enabled ') {
   $OUT = <<END;
DEFAULT Group == "chilli", NAS-Identify == "localhost", Auth-Type: = unix
# WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000

DEFAULT Group! = "chilli", NAS-Identify == "localhost", 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 ((($chilli{'status'} || 'disabled) eq 'enabled') &&
       ($chilli{'guestAccess'} || disabled) eq 'enabled'){
       my $downlink = $chilli{'guestDownLink'} || '400';
       my $uplink = $chilli{'guestUpLink'} || '64';
       $downlink = $downlink * 1000;
       $uplink = $uplink * 1000;
       $OUT =<<END;
guest NAS-Identify == "localhost", Auth-Type: = Local User-Password == 'guest'
      WISPr-Bandwidth-Max-Down = $downlink, WISPr-Bandwidth-Max-Up = $uplink
END
if (($chilli{'status'} || 'disabled') eq' enabled ') {
   $OUT = <<END;
DEFAULT Group == "wifi", NAS-Identify == "localhost", Auth-Type: = unix
# WISPr-Bandwidth-Max-Down = 512000, WISPr-Bandwidth-Max-Up = 128000
DEFAULT Group! = "wifi", NAS-Identify == "localhost", Auth-Type: Reject =
       Reply Message = "Your are not allowed member of the group"
END
}
}

What authenticated users have access to ?

By default, not much.

Basically once authenticated, users have access to

  • DNS outside (udp port 53)
  • Http outwards (through squid if squid is enabled and WebRequests set to squid), http to your server
  • Https outwards and https to your SME
  • Ping outwards and your server

There are two key in the db to customize this:

  • AllowedServices will allow some services of your server to be acessible to chilli clients. For exemple, you want to make ssh and openvpn-bridge accessible:
db configuration setprop chilli AllowedServices sshd,openvpn-bridge

Services names need to correspond to those defined in the configuration db


Important.png Note:
This will just open the corresponding port(s), you need to make sure the service listen on the correct interface.


  • AllowedOutgoing will allow more outgoing traffic. It's a list of proto/host/port clients will be able to contact on the internet (These rules only apply to forwarded traffic, nothing will be allowed to the private network). Wildcard '*' (or keyword 'any') can replace host or port. Eg:
db configuration setprop chilli AllowedOutgoing tcp:56.23.41.1:25,udp:*:1194,tcp:4.5.6.7:any,tcp:any:123

This will allow:

  • host 56.23.41.1 on port 25 to be accessible with TCP
  • Any host will be accessible on port 1194 with udp
  • All the port of host 4.5.6.7 will be accessible with tcp
  • Any host will be accessible on port 123 with tcp


Important.png Note:
proto can be tcp or udp only for now, there's now way to add icmp rules with db commands.


Troubleshoot

If the contrib doesn't work, check in the order:

  • Be sure eth2 is detected
ifconfig -a

If eth2 is not shown, you may need to load the appropriate module

  • Check if chilli daemon is running
ps aux | grep chilli

If chilli daemon is not running, try

signal-event chilli-update

If still nothing

/etc/init.d/chilli start

If you get an error, check the log /var/log/messages

  • Check tun0 (or what you have configured as tundev) is up, with a valid ip
ifconfig tun0
  • Check the client gets a ip in the range 10.1.0.0/24 (or what ever you have configured as net)

If it's not the case, check that the AP is working properly (tcpdump on tun0 to check that your server sees dhcp requests). You can try to connect your client directly to eth2 with a crossed cable to eliminate an AP or wifi-level issue

  • Check your client can use DNS. If you get a timeout when you try to open a web page from the client, it's possible that the problem comes from some DNS issue. Try to enter an ip in your browser, even a fake on (http://11.12.13.4/ for example), if you see the login page, then, you should try to configure the DNS of your ISP in the db
db configuration setprop chilli dns1 <ip> dns2 <ip>

Uninstall

yum remove smeserver-coova-chilli coova-chilli

Bugs

Please raise bugs under the SME-Contribs section in bugzilla and select the smeserver-coova-chilli component or use this link