Expand your service – Internet is Always  a plus Laptops, tablet PCs or smartphones   are not only offered at ever lower prices but are nearly always equiped with   WLAN today. Whether in hotels, cafés, restaurant or in shopping centers: If you provide   your customers with a public WLAN HotSpot for Internet access, either free of   charge or against payment, this constitutes an attactive service offer for   your customers and gives you a competitive edge. AlwaysOn offers powerful WLAN systems   for this purpose which are equally suitable for large or small HotSpot   environments. The AlwaysOn HotSpot solution allows the operation of public HotSpots for   Internet access via WLAN – it is easy to set up, powerful, provides flexible   configuration options and is compatible with the current legal requirements   regarding data protection and telecommunications data retention. The Internet access at the HotSpot can be offered as free service or operated   with a time- or volume-based ticket system. The solution is   subsidiary-capable, which means that it can be offered on various sites and   administrated centrally. System   principle of the AlwaysOn HotSpot Solution An administration terminal – e.g. the reception desk PC in the hotel – is   used for the administration of the operator account on the server: Logging of   registrations, creation of tickets, statistical evaluation, etc. If guests want to use the HotSpot, they are initially lead to the login page   of the operator. After sucessfully entering the login data of their tickets, they are granted unlimited Internet access for the agreed duration or data   volume. The HotSpot gateway transfers the login data to the HotSpot server via   RADIUS. After successful login, the gateway forwards all Internet requests   directly into the Internet. The duration of the connection is determined via   the session time indicated in the scope of the RADIUS authentication. Moreover, the gateway makes periodical evaluations of the individual users, thus   permitting volume-based session termination. AlwaysOn HotSpot Solution – Features

HotSpot is a way to authorize users to access some network resources, but does not provide traffic encryption. To log in, users may use almost any web browser (either HTTP or HTTPS protocol), so they are not required to install additional software. The gateway is accounting the uptime and amount of traffic each client have used, and also can send this information to a RADIUS server. The HotSpot system may limit each particular user’s bitrate, total amount of traffic, uptime and some other parameters mentioned further in this document.

The HotSpot system is targeted to provide authentication within a local network (for the local network users to access the Internet), but may as well be used to authorize access from outer networks to access local resources (like an authentication gateway for the outside world to access your network). It is possible to allow users to access some web pages without authentication using Walled Garden feature.

Getting an Address

First of all, a client have to get an IP address. It may be set on the client statically, or leased from a DHCP server. The DHCP server may provide ways of binding lent IP addresses to clients MAC addresses, if required. The HotSpot system does not care how client get an address before he/she gets to the HotSpot login page.

Moreover, HotSpot server may automatically and transparently change any IP address (yes, meaning really any IP address) of a client to a valid unused address from the selected IP pool. If a user is able to get his/her Internet connection working at their place, he/she will be able to get his/her connection working in the HotSpot network. This feature gives a possibility to provide a network access (for example, Internet access) to mobile clients that are not willing (or are disallowed, not qualified enough or otherwise unable) to change their networking settings. The users will not notice the translation (i.e., there will not be any changes in the users’ config), but the router itself will see completely different (from what is actually set on each client) source IP addresses on packets sent from the clients (even the firewall mangle table will ‘see’ the translated addresses). This technique is called one-to-one NAT.

One-to-one NAT accepts any incoming address from a connected network interface and performs a network address translation so that data may be routed through standard IP networks. Clients may use any preconfigured addresses. If the one-to-one NAT feature is set to translate a client’s address to a public IP address, then the client may even run a server or any other service that requires a public IP address. This NAT is changing source address of each packet just after it is received by the router (it is like source NAT that is performed early in the packet path, so that even firewall mangle table, which normally ‘sees’ received packets unaltered, can only ‘see’ the translated address).

Before the authentication

When enabling HotSpot on an interface, the system automatically sets up everything needed to show login page for all clients that are not logged in. This is done by adding dynamic destination NAT rules, which you can observe on a working HotSpot system. These rules are needed to redirect all HTTP and HTTPS requests from unauthorized users to the HotSpot authentication proxy. Other rules that are also inserted, will be described later in a special section of this manual.

In most common setup, opening any HTTP page will bring up the HotSpot servlet login page (which can be customized extensively, as described later on). As normal user behavior is to open web pages by their DNS names, a valid DNS configuration should be set up on the HotSpot gateway itself (it is possible to reconfigure the gateway so that it will not require local DNS configuration, but such a configuration is impractical and thus not recommended).

Walled Garden

You may wish not to require authorization for some services (for example to let clients access the web server of your company without registration), or even to require authorization only to a number of services (for example, for users to be allowed to access an internal file server or another restricted area). This can be done by setting up Walled Garden system.

When a not logged-in user requests a service allowed in the Walled Garden configuration, the HotSpot gateway does not intercept it, or in case of HTTP, simply redirects the request to the original destination. Other requests are redirected to the HotSpot servlet (login page infrastructure). When a user is logged in, there is no effect of this table on him/her.

Walled Garden for HTTP requests is using the embedded proxy server . This means that all the configured parameters of that proy server will also be effective for the WalledGarden clients (as well as for all clients that have transparent proxy enabled)

Authentication

There are currently 6 different authentication methods. You can use one or more of them simultaneously:

• HTTP PAP – simplest method, which shows the HotSpot login page      and expect to get the authentication info (i.e. username and password) in      plain text. Another use of this method is the possibility of hard-coded      authentication information in the servlet’s login page simply creating the      appropriate link.
• HTTP CHAP – standard method, which includes CHAP challenge in      the login page. The CHAP MD5 hash challenge is used together with the      user’s password for computing the string which will be sent to the HotSpot      gateway. The hash result (as a password) together with username is sent      over network to HotSpot service (so, password is never sent in plain text      over IP network). On the client side, MD5 algorithm is implemented in      JavaScript applet, so if a browser does not support JavaScript (like, for      example, Internet Explorer 2.0 or some PDA browsers) or it has JavaScipt      disabled, it will not be able to authenticate users. It is possible to      allow unencrypted passwords to be accepted by turning on HTTP PAP      authentication method, but it is not recommended due to security      considerations.
• HTTPS – the same as HTTP PAP, but uses SSL protocol to      encrypt transmissions. HotSpot user just sends his/her password without      additional hashing (note that there is no need to worry about plain-text      password exposure over the network, as the transmission itself is      encrypted). In either case, HTTP POST method (if not possible, then      – HTTP GET method) is used to send data to the HotSpot gateway.
• HTTP cookie – after each successful login, a cookie is sent to the      web browser and the same cookie is added to active HTTP cookie list. Next      time the same user will try to log in, web browser will send the saved      HTTP cookie. This cookie will be compared with the one stored on the      HotSpot gateway and only if source MAC address and randomly generated ID      matches the ones stored on the gateway, user will be automatically logged in      using the login information (username and password pair) was used when the      cookie was first generated. Otherwise, the user will be prompted to log      in, and in the case authentication is successful, old cookie will be      removed from the local HotSpot active cookie list and the new one with      different random ID and expiration time will be added to the list and sent      to the web browser. It is also possible to erase cookie on user manual      logoff (not in the default server pages, but you can modify them to      perform this). This method may only be used together with HTTP PAP, HTTP      CHAP or HTTPS methods as there would be nothing to generate cookies in the      first place otherwise.
• MAC address – try to authenticate clients as soon as they appear      in the hosts list (i.e., as soon as they have sent any packet to the      HotSpot server), using client’s MAC address as username.
• Trial – users may be allowed to use the service free of      charge for some period of time for evaluation, and be required to      authenticate only after this period is over. HotSpot can be configured to      allow some amount of time per MAC address to be freely used with some      limitations imposed by the provided user profile. In case the MAC address      still has some trial time unused, the login page will contain the link for      trial login. The time is automatically reset after the configured amount      of time (so that, for example, any MAC address may use 30 minutes a day      without ever registering). The username of such a user (as seen in the      active user table and in the login link) is      “T-XX:XX:XX:XX:XX:XX” (where XX:XX:XX:XX:XX:XX is his/her MAC      address). The authentication procedure will not ask RADIUS server      permission to authorise such a user.

HotSpot can authenticate users consulting the local user database or a RADIUS server (local database is consulted first, then – a RADIUS server). In case of HTTP cookie authentication via RADIUS server, the router will send the same information to the server as it was used when the cookie was first generated. If authentication is done locally, profile corresponding to that user is used, otherwise (in case RADIUS reply did not contain the group for that user) the default profile is used to set default values for parameters, which are not set in RADIUS access-accept message. For more information on how the interaction with a RADIUS server works, see the respective manual section.

Authorization

After authentication user gets access to the Internet and receives some limitations (which are user profile specific). HotSpot may also perform a one-to-one NAT for the client, so that a particular user would always receive the same IP address regardless of what PC is used.

The system will automatically detect and redirect requests to a proxy server that client is using (if any; it may be set in his/her settings to use an unknown proxy server) to the proxy server embedded in the router.

Authorization may be delegated to a RADIUS server, which delivers similar configuration options as the local database. For any user requiring authorization, a RADIUS server gets queried first, and if no reply received, the local database is examined. RADIUS server may send a Change of Authorization request according to standards to alter the previously accepted parameters.

When MAC cookie feature is enabled (login-by=mac-cookie, add-mac-cookie=yes set in user profile), following actions are taken:

• first successful login: Mac cookie keeps record of username and password for the MAC address if there is only one host with such MAC. Cookie timeout is set to value equal      to mac-cookie-timeout.

• new host appears: Hotspot checks if there is a mac cookie record for      the MAC address and logs in host using recorded username and password. If  there is more than one host with the same MAC address, user will not be logged in and MAC cookie record for this address will be delete

Advertisement

The same proxy used for unauthorized clients to provide Walled-Garden facility, may also be used for authorized users to show them advertisement popups. Transparent proxy for authorized users allows to monitor http requests of the clients and to take some action if required. It enables the possibility to open status page even if client is logged in by mac address, as well as to show advertisements time after time

When the time has come to show an advertisement, the server redirects client’s web browser to the status page. Only requests, which provide html content, are redirected (images and other content will not be affected). The status page displays the advertisement and next advertise-interval is used to schedule next advertisement. If status page is unable to display an advertisement for configured timeout starting from moment, when it is scheduled to be shown, client access is blocked within walled-garden (just as unauthorized clients are). Client is unblocked when the scheduled page is finally shown. Note that if popup windows are blocked in the browser, the link on the status page may be used to open the advertisement manually.

While client is blocked, FTP and other services are not allowed. Thus requiring client to open an advertisement for any Internet activity not especially allowed by the Walled-Garden.

Accounting

The HotSpot system implement accounting internally, you are not required to do anything special for it to work. The accounting information for each user may be sent to a RADIUS server.