The content of this document is divided into the following sections:
- Managing accounting
- Accounting Classes
- RADIUS accounting for the Captive Portal
- RADIUS accounting for wireless WPA/WPA2 Enterprise connections
The RADIUS protocol as well as play the role of authentication and authorization service for remote access of network devices, it allows to manage the accounting of the connections. In other words, this is a AAA system (triple A means Authentication, Authorization and Accounting) and with the support for the Accounting provides accounting of the duration and of traffic in download and upload generated of the connections. The purpose of this paper is the description of the implementation of the RADIUS accounting in Zeroshell obtained by the FreeRADIUS server available on it.
Zeroshell can receive accounting requests from any network device that communicates this information using the RADIUS protocol. Examples of such devices are:
- Wireless Access Point
- VPN Router
- Ethernet switch set Port-Based access via 802.1x
- Captive Portal Router
Specifically Zeroshell manages the following attributes from RADIUS requests:
- User-Name (username also with the suffix @domain)
- Calling-Station-Id (Client’s MAC address)
- Framed-Ip-Address (The IP address assigned to the client)
- NAS-Identifier (the IP or the hostname of the Network Access Server such as a Wi-Fi Access Point)
- Acct-Input-Octets (number of bytes transmitted from the client and incoming to the NAS)
- Acct-Input-Gigawords (64-bit extension of the previous field)
- Acct-Input-Packets (number of packets transmitted by the client)
- Acct-Output-Octets (number of bytes leaving from the NAS and received by the client)
- Acct-Output-Gigawords (64-bit extension of the previous field)
- Acct-Output-Packets (number of packets received from the client)
- Acct-Session-Time (Length of the connection)
Zeroshell manages, in addition to start and stop requests of the connections, also the so-called Interim-Update requests, with which certain more advanced Network Access Points communicate intermediate accounting information. For these devices the data is updated in real time without waiting for the end of the connection. The captive portal of Zeroshell also trasmit Interim-Update packets to update traffic, time and cost of the connection in real-time.
Note that as well as the authentication can be forwarded to an external RADIUS server authoritative for a given domain, in the same way the accounting is forwarded to the correct proxy server. The list of proxy servers for RADIUS Accounting is the same as that for authentication, but for accounting you have to explicitly enable the forwarding for each domain.
You can create different classes of accounting in order to give users different accounting treatment on the connections to the Internet. Unless otherwise specified when creating or changing accounts, users belong to the class named DEFAULT accounting whose costs are equal to zero and without limits traffic and connection time. Connection costs to be defined in a class and then be assigned to users who belong to it, can be applied to the Megabytes of network traffic (RX+TX) and for hourly rate.
For each class of accounting is possible to define an upper limit in Megabytes for the traffic generated and the maximum number of hours or fractions of hours for which the user can remain connected. When the user exceeds at least one of the two limits is automatically disconnected and no longer allowed to connect until the counters are not reset. Note that the bandwidth limit in Megabytes per second has not yet been implemented in the current version of Zeroshell (1.0.beta16).
The method of payment can be set to one of two values: Post-Paid and Pre-Paid. In the case of postpaid rates, connection charges are applied to the achievement of any connection limits. In the case of prepaid method, instead, the user must have an initial credit, out of which it is disconnected and no longer authorized until the other credit is loaded.
The Captive Portal of Zeroshell, as already mentioned, communicates information about the connections using the RADIUS protocol. Obviously, the integrated FreeRADIUS server manages the information and, if necessary, forwards them to a remote RADIUS proxy, however, keeping a local copy of accounting. Any proxy may be either an external Zeroshell RADIUS server with the accounting service enabled or other RADIUS different from Zeroshell. In the latter case, there may be difficulties in the management of traffic and time limits and management of prepaid rates, while for what concerns the calculation of costs there are not any problem.
As you can see from the figure, the accounting information is available in real time to the user through the Network Access window, which is opened immediately after the authentication and that must remain open to provide access to the network through the renewal of the authorization. It should be noted, that the captive portal does not transmit the accounting synchronously, but the requests are queued in a buffer. A daemon process takes care then to actually transmit this information to the RADIUS server. This decoupling ensures, in case of network problems that prevent communication between the captive portal and the remote RADIUS server, there are no data loss or delays in the use of the captive portal.
Nowadays almost all the Wireless Access Points, even the cheapest ones, allow the configuration of a RADIUS server to which accounting requests should be sent. Because of this, if you choose to allow access Wi-Fi via WPA/WPA2 Enterprise (that is, through 802.1x), Zeroshell may also account for the traffic coming from these devices directly, without the need of activation of a captive portal. Note, that in order for the WiFi Access Point can communicate accounting information to the RADIUS server you must add the IP address together with the its shared secret to the list of RADIUS clients.