Filter
Top Products
224 AT-WR4500 Series - IEEE 802.11abgh Outdoor Wireless Routers
RouterOS v3 Configuration and User Guide
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 servlet (i.e., the authentication procedure, e.g.,
the login page). Other rules that are also inserted, we will describe 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 will be 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 (/ip proxy). 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. Note that passwords are not being encrypted when
transferred over the network. 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 to be 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) to use that feature.
HTTPS - the same as HTTP PAP, but using SSL protocol for encrypting transmissions. HotSpot user just
send 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 match 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