Cyberoam client-server protocol

  1. Introduction

    This document describes the communication protocol between the Cyberoam/24online client and server as observed by the author. Cyberoam is an employee internet management system for corporate networks. 24online is a subscriber management system for broadband ISPs.

  2. Disclaimer

    This document is based on observations by the author and is provided in the hope that it will be useful. This is NOT an official statement by the creators of Cyberoam / 24online. The author makes NO CLAIM on OWNERSHIP, AUTHENTICITY or USABILITY of the information within this document. YOU HAVE BEEN WARNED.

  3. Why Cyberoam/24online?

    The Cyberoam/24online system addresses the need to control internet access in LAN environments. Most corporates need their employees to have internet access but need to control it in order to prevent bandwidth hogging or other kinds of abuse. Also a number of broadband ISPs provide connectivity using LANs spread over a locality. In this case, authentication, authorization and accounting (AAA) needs to be handled. In the case of dial-up ISPs, the authentication is inherent to the communication protocol (i.e. to serial communication and PPP). However, there is no connection phase involved on broadcast networks and so external schemes for AAA have to be devised. Cyberoam/24online are one such scheme.

  4. Overall system operation

    The system handles AAA in the following way:
    An authentication server is installed at the ISP's NOC (or wherever). Clients are distributed to all subscribers. The authentication server is capable of controlling access on a per IP address basis (possibly by using RADIUS with the LAN's router, the author does not know). Any time a subscriber wishes to connect to the Internet, he has to log in to the authentication server using the client program. Only after doing so, will packets originating from his IP address be forwarded by the gateway. Whenever the user wishes to disconnect, he can log off from the server using the client program. In order to handle subscriber-side failures, the server will assume a client to be logged off if no message is received within a certain period. To keep the login session active, the client periodically sends keepalive messages to the server. Since there is a connection establishment phase imposed by the system, AAA can be done by the authentication server.

  5. Protocol basics

    The Cyberoam client and server communicate over UDP. The server usually listens on port 6060. The client uses ephemeral ports locally. Messages are passed between the client and server in the UDP payload. A client-server transaction is defined by a pair of messages; one from the client to the server and the other in the opposite direction. The transactions observed by the author are:

    1. The login transaction
    2. The logout transaction
    3. The keepalive transaction

  6. Protocol versions

    [To be done]

  7. The message format

    Cyberoam messages are carried within UDP datagrams. The message consists of a fixed length header followed by a variable length payload. The first byte of the header contains the type of message to follow. The next four bytes contain the length of the message represented as a null terminated ASCII string ( e.g. "112\0", "64\0\0" ). The remain bytes are the payload.

    Fig. 1 - The message format

  8. Message types

    [To be done]

SourceForge Logo