HotSpot Gateway
General Information
The MikroTik HotSpot Gateway enables providing of public network access
for clients using wireless or wired network connections.
HotSpot Gateway
features:
Universal Client feature may be used with HotSpot enabled-address method
to provide IP network services regardless of client computers' IP network
settings
Packages required: hotspot, dhcp(optional)
License required: Level1 (Limited to 1
active user) , Level3
(Limited to 1 active user) , Level4 (Limited to 200 active users) ,
Level5 (Limited to 500 active users) , Level6
Submenu level: /ip hotspot
Standards and Technologies: ICMP, DHCP
Hardware usage: Not significant
Related Documents
MikroTik HotSpot Gateway should have at least two network interfaces:
The diagram below shows a sample HotSpot setup.
The HotSpot interface should have an IP address assigned to it. To use dhcp-pool method, there should be two IP
addresses: one as the gateway for the temporary IP address pool used prior to
authentication, and second as the gateway for the permanent IP address pool
used by authenticated clients. Note, that you have to provide routing for these address pools, unless you
plan to use masquerading (source NAT). Physical network connection has to be
established between the HotSpot user's computer and the gateway. It can be
wireless (the wireless card should be registered to AP), or wired (the NIC card
should be connected to a hub or a switch).
In dhcp-pool
case, the arp mode of the HotSpot interface should be set to reply-only to prevent network
access using static IP addresses (the DHCP server should add static ARP entries
for each DHCP client). Note also that Universal Client feature can not be used with dhcp-pool method.
HotSpot is a way to authorize users to access some network resources. It
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 of its clients 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, but may as well be used to authorize access from outer networks to
local networks. Configuring firewall rules, it is possible to exclude some IP
networks and protocols from authentication and/or accounting. The walled garden
feature allows users to access some web pages without the need of prior
authentication.
HotSpot system is rather simple by itself, but it must be used in
conjunction with other features of RouterOS. Using many RouterOS features
together it is possible to make a Plug-and-Play access system.
There are two login methods for HotSpot users - dhcp-pool and enabled-address. The enabled-address is the preferred one in most cases, but if you want to bind together
usernames and IP addresses (i.e. if you want a user to get the same IP address
no matter which computer is he/she using), then the dhcp-pool method is the only possibility.
First, a client gets an IP address. It may be set statically or be given
out by a DHCP server. If the client tries to access network resources using a
web browser, the destination NAT rule redirects that TCP connection request to
the HotSpot servlet (TCP port 8088 for HTTP by default; HTTPS may also be used
on its default TCP port 443). This brings up the HotSpot Welcome/Login page
where the user should input his/her username and password (the page may be
customized as described later on).
It is very important to understand that login method for a particular
user is determined only after the user is authenticated and no assumptions are
made by the router before.
It is possilbe to specify a number of domains which can be accessed
without prior registration. This feature is called Walled Garden. When a not logged-in
user sends a HTTP request to an allowed web page, the HotSpot gateway redirects
the request to the original destination (or to a specified parent proxy). When
a user is logged in, there is no effect of this table for him/her.
To implement the Walled Garden feature an embedded web proxy server has
been designed, so all the requests from not authorized users are really going
through this proxy. Note that the embedded proxy server does not have caching function yet. Also
note that this embedded proxy server is in the hotspot software package and does not require web-proxy package.
In case of HTTP protocol, HotSpot servlet generates an MD5 hash
challenge to be used together with the user's password for computing the string
which will be sent to the HotSpot gateway. The hash result 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), it will not be able to
authenticate users. It is possible to allow unencrypted passwords to be
accepted, but it is not recommended to use this feature.
If HTTPS protocol is used, HotSpot user just send his/her password
without additional hashing. In either case, HTTP POST method (if not possible,
then - HTTP GET method) is used to send data to the HotSpot gateway.
HotSpot can authenticate users using local user database or a RADIUS
server (local database is consulted first, then - a RADIUS server). If
authentication is done locally, profile corresponding to that user is used,
otherwise (in case of RADIUS) 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.
If authentication by HTTP cookie is enabled, then after each successful
login cookie is sent to web browser and the same cookie is added to active HTTP
cookie list. Next time a user will try to log in, web browser will send http
cookie. This cookie will be compared to the one stored on the HotSpot gateway
and only if there is the same source MAC address and the same randomly
generated ID, user will be automatically logged in. Otherwise, the user will be
prompted to log in, and in the case authentication was successfull, 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.
RADIUS authentication is CHAP by defalt, but it is possible to force the
HotSpot gateway to use PAP. To do this, you should enable unencrypted
passwords, and remove the possibility for the servlet to hash the passwords
(see Customizing HotSpot servlet chapter on how to do it).
One of the two login methods is to be used for each client individually
(you may choose one or allow it to be done automatically in user profile
configuration). The enabled-address method is the preferred one, so if it is configured correctly and the
client has a proper IP address (that matches the one set in the user database),
this method will be used. If the enabled-address method is not enabled or the client's IP address should be changed, the
HotSpot Gateway tries to use dhcp-pool method. In that case, MikroTik HotSpot Gateway's DHCP server tries to
change the DHCP address lease the client might have received before the
authentication. It is possible to specify what IP addresses each particular
user will receive after he/she logs in (that way a user will always get the
same IP no matter what computer he/she has logged in from)
Address assignment with dhcp-pool login method
To create a HotSpot infrastructure with dhcp-pool method, DHCP server should be configured to lease IP addresses from a
temporary IP address pool for a very short period of time (lease time at about
14 seconds; lesser values may cause problems with some DHCP clients). This
temporary subnet should have some restrictions, so that the users received a
temporary IP address could only access the HotSpot login page.
Once a user is authenticated, the HotSpot gateway changes the lease
assigned to the user so that he/she will receive an IP address from a different
IP address pool when the lease time of the current temporary lease will be over
(it is not possible to recall DHCP lease, so the address will only change when
the temporary lease expires).
The HotSpot system makes user accounting through firewall rules. You
should create a hotspot firewall chain, and the system will put there two dynamic rules for
each active user (one for upload, and one for download). You shold make all the
traffic you need accounting for to pass through this firewall table.
Command name: /ip hotspot setup
Questions
address pool of hotspot network (name)
- IP address pool for the HotSpot network
address pool of temporary network (name)
- IP address pool the for temporary HotSpot network
another port for service (integer;
default: 4430)
- if there is already a service on the 443 TCP port, setup will move that
service on an another port, so that HotSpot secure authentication page would be
on standard port for SSL
another port for service (integer;
default: 8081)
- another port for www service (so that hotspot service could be put on port
80)
dns name (text)
- DNS domain name of the HotSpot gateway
dns servers (IP addressIP address) - DNS servers for HotSpot clients
enable universal client (yes | no; default: no) - whether to enable Universal Client on the HotSpot interface
hotspot interface (name)
- interface to run HotSpot on
import and setup certificate (yes | no; default: yes) - if the setup should try to import and set up a certificate
interface already configured (yes | no; default: no) - whether to add hotspot authentication for the existing interface
setup or otherwise interface setup should be configured from the scratch
ip address of smtp server (IP address;
default: 0.0.0.0)
- IP address of the SMTP server to redirect SMTP requests (TCP port 25) to
· 0.0.0.0 - no redirect
local address of hotspot network (IP address;
default: 10.5.50.1/24)
- HotSpot address for the interface
local address of temporary network (IP address;
default: 192.168.0.1/24)
- temporary HotSpot address for the interface (for dhcp-pool method)
login method (dhcp-pool | enabled-address | smart; default: enabled-address) - login method to
use
masquerade hotspot network (yes | no; default: yes) - whether to masquerade the HotSpot network
masquerade temporary network (yes | no; default: yes) - whether to masquerade the temporary network
name of local hotspot user (text;
default: admin)
- username of one automatically created user
passphrase (text)
- the passphrase
of the certificate
password for the user (text)
- password for the automatically created user
select certificate (name)
- which certificate to use
use local dns cache (yes | no) - whether to redirect all DNS requests (UDP port 53) to the
local DNS cache
use ssl (yes | no; default: no) - whether to use secure SSL authentication
use transparent web proxy (yes | no; default: no) - whether to use transparent web proxy for hotspot clients
Depending on current settings and answers
to the previous questions, default values of following questions may be
different. Some questions may disappear if they become redundant (for example,
there is no use of setting up temporary network when login method is enabled-address)
If Universal Client is enabled, and DNS
cache is not used, DNS requests are redirected to the first DNS server
configured.
To configure HotSpot on ether1 interface (which is already configured),
enabling transparent web proxy and adding user admin with password rubbish:
[admin@MikroTik] ip hotspot> setup
Select interface to run HotSpot on
hotspot interface: ether1
Use SSL authentication?
use ssl: no
Add hotspot authentication for existing interface setup?
interface already configured: yes
Create local hotspot user
name of local hotspot user: admin
password for the user: rubbish
Use transparent web proxy for hotspot clients?
use transparent web proxy: yes
[admin@MikroTik] ip hotspot>
Property Description
allow-unencrypted-passwords (yes | no; default: no) - whether to authenticate user if plain-text password is received
auth-http-cookie (yes | no; default: no) - defines whether HTTP authentication by cookie is enabled
auth-mac (yes | no; default: no) - defines whether authentication by Ethernet MAC address is enabled
auth-mac-password (yes | no; default: no) - use MAC address as a password if MAC authorization is enabled
auth-requires-mac (yes | no; default: yes) - whether to require client's IP address to resolve to MAC address
(i.e. whether to require that all the clients are in the same Ethernet-like
network (as opposed to IP network, Ethernet-like network is bounded by routers)
as the HotSpot gateway)
dns-name (text)
- DNS name of the HotSpot server
hotspot-address (IP address;
default: 0.0.0.0)
- IP address for HotSpot service (used for www access)
http-cookie-lifetime (time;
default: 1d)
- validity time of HTTP cookies
login-mac-universal (yes | no; default: no) - whether to log in every host of Universal client instantly in case
it has its MAC address listed in HotSpot user list
parent-proxy (IP address;
default: 0.0.0.0)
- the address of the proxy server the HotSpot service will use as a parent
proxy
split-user-domain (yes | no; default: no) - whether to split username from domain name when the username is
given in "user@domain" or in "domain\user" format
status-autorefresh (time;
default: 1m)
- WWW status page autorefresh time
universal-proxy (yes | no; default: no) - whether to intercept the requests to HTTP proxy servers
use-ssl (yes | no; default: no) - whether the servlet allows only HTTPS:
yes
- the registration may only occur using the Secure HTTP (HTTPS) protocol
no
- the registration may be accomplished using both HTTP and HTTPS protocols
reset-html - overwrite the existing HotSpot servlet with the original HTML files.
It is used if you have changed the servlet and it is not working after that.
If dns-name property is not specified, hotspot-address is used instead. If hotspot-address is also absent, then both are to be detected automatically.
If auth-mac
is enabled, then a client is not prompted for username and password if the MAC
address of this computer is in the HotSpot user database (either local or on
RADIUS). Nevertheless this method does not excuse clients from the common login
procedure, just from filling out the registration form (i.e. regardless of
whether MAC authorization is applicable for a client, he/she should open the
Login page in order to get registered). The only exception is the users of
Universal Client - if login-mac-universal property is enabled, they will not even have to open a web browser if
their MAC addresses are listed in the user database.
The universal-proxy feature automatically creates DST-NAT rules to redirect requests of
each particular user to a proxy server he/she is using (it may be set in
his/her settings to use an unknown to us proxy server) to the local embedded
proxy server. This feature may be used in combination with Universal Client
feature to provide Internet access for users regardless of their network
settings.
allow-unencrypted-passwords property makes it possible to authenticate with the browsers not
supporting JavaScript (for example, Internet Explorer 2.0 or some PDA
browsers). It is also possible to log in using telnet connection, just requesting
the page /login?user=username&password=password. An another use of this property is the possibility of hard-coded
authentication information in the servlet's login page simply creating the
appropriate link.
To enable PAP RADIUS authentication, you
should set in the hotspot configuration allow-unencrypted-password=yes and you should remove %main% variable from the login.html file.
auth-requires-mac property makes it possible to make a 'reverse HotSpot' - to
authenticate users accessing the local network from the Internet.
To enable cookie support:
[admin@MikroTik] ip hotspot> set auth-http-cookie=yes
[admin@MikroTik] ip hotspot> print
use-ssl:
no
hotspot-address:
0.0.0.0
dns-name:
""
status-autorefresh: 1m
universal-proxy:
no
parent-proxy:
0.0.0.0:0
auth-requires-mac:
yes
auth-mac:
no
auth-mac-password:
no
auth-http-cookie: yes
http-cookie-lifetime:
1d
allow-unencrypted-passwords:
no
login-mac-universal:
no
split-user-domain:
no
[admin@MikroTik] ip hotspot>
Submenu level: /ip hotspot profile
Description
HotSpot User profiles are used for common user settings. Profiles are
like user groups, they are grouping users with the same limits.
idle-timeout (time;
default: 0s)
- idle timeout (maximal period of inactivity) for client
0
- no timeout
incoming-filter (name)
- name of the firewall chain applied to incoming packets
keepalive-timeout (time;
default: 2m)
- keepalive timeout for client
0
- no timeout
login-method - the login method user will be using
dhcp-pool
- login by changing IP address via DHCP server
enabled-address - login by enabling access for client's existing IP address
smart
- choose best login method for each case
mark-flow (name)
- traffic from authorized users will be marked by firewall mangle with this
flow name
name
(name)
- profile reference name
outgoing-filter (name)
- name of the firewall chain applied to outgoing packets
rx-bit-rate (integer;
default: 0)
- receive bitrate (for users it is upload bitrate)
0
- no limitation
session-timeout (time;
default: 0s)
- session timeout (maximal session time) for client
0
- no timeout
shared-users (integer;
default: 1)
- maximal number of simultaneously logged in users with the same username
tx-bit-rate (integer;
default: 0)
- transmit bitrate (for users it is download bitrate)
0
- no limitation
To use enabled-address method, mark-flow should be set. To use dhcp-pool method, dhcp
software package must be installed
idle-timeout is used to detect, that client is not using outer networks (e.g.
Internet), i.e., there is NO TRAFFIC coming from that client and going through
the router. keepalive-timeout is used to detect, that the computer of the client is still alive and
reachable. If check will fail during this period, client will be logged out. session-timeout is an unconditional
uptime limit
To choose the login method to be used if smart method is set as the value of login-method property, the
following algorithm is used:
To use enabled-address method that uses logged-in mark and logs a client off if he disappears for more then a minute:
[admin@MikroTik] ip hotspot profile> set default
login-method=enabled-address \
\... mark-flow=logged-in keepalive-timeout=1m
[admin@MikroTik] ip hotspot profile> print
Flags: * - default
0 * name="default"
session-timeout=0s idle-timeout=0s only-one=yes
tx-bit-rate=0 rx-bit-rate=0
incoming-filter="" outgoing-filter=""
mark-flow="logged-in" login-method=enabled-address
keepalive-timeout=1m
[admin@MikroTik] ip hotspot profile>
To define an additional profile that will also limit download speed to
64 kilobyte/s and upload data rate to 32 kilobyte/s, and call it limited:
[admin@MikroTik] ip hotspot profile> add copy-from=default
tx-bit-rate=65536 \
\... rx-bit-rate=32768 name=limited
[admin@MikroTik] ip hotspot profile> print
Flags: * - default
0 * name="default"
session-timeout=0s idle-timeout=0s only-one=yes
tx-bit-rate=0 rx-bit-rate=0
incoming-filter="" outgoing-filter=""
mark-flow="logged-in" login-method=enabled-address
keepalive-timeout=1m
1 name="limited" session-timeout=0s
idle-timeout=0s only-one=yes
tx-bit-rate=65536
rx-bit-rate=32768 incoming-filter=""
outgoing-filter=""
mark-flow="logged-in" login-method=enabled-address
keepalive-timeout=1m
[admin@MikroTik] ip hotspot profile>
Submenu level: /ip hotspot user
Property Description
address (IP address;
default: 0.0.0.0)
- static IP address. If not 0.0.0.0, client will always get the same IP address. It implies, that only one
simultaneous login for that user is allowed
bytes-in (read-only: integer) - total amount of bytes received from user
bytes-out (read-only: integer) - total amount of bytes sent to user
limit-bytes-in (integer;
default: 0)
- maximum amount of bytes user can transmit
0
- no limit
limit-bytes-out (integer;
default: 0)
- maximum amount of bytes user can receive
0
- no limit
limit-uptime (time;
default: 0s)
- total uptime limit for user (pre-paid time)
0s
- no limit
mac-address (MAC address;
default: 00:00:00:00:00:00) - static MAC address. If not 00:00:00:00:00:00, client is allowed to login only from that MAC address
name
(name)
- user name
packets-in (read-only: integer) - total amount of packets received from user
packets-out (read-only: integer) - total amount of packets sent to user
password (text)
- user password
profile (name;
default: default)
- user profile
routes
(text)
- routes that are to be registered on the HotSpot gateway when the client is
connected. The route format is: "dst-address gateway metric" (for
example, "10.1.0.0/24 10.0.0.1 1"). Several routes may be specified
separated with commas
uptime
(read-only: time) - total time user has been logged in
If auth-mac property is enabled, clients' MAC addresses (written with CAPITAL
letters) can be used as usernames. If auth-mac-password is set to no, there should be no password for that users. Otherwise, the password
should be equal to the username. When a client is connecting, his/her MAC
address is checked first. If there is a user with that MAC address, the client
is authenticated as this user. If there is no match, client is asked for
username and password.
The address property is used only for dhcp-pool login method to tell it DHCP server. If a user already has a permanent
IP address (as it is happening when enabled-address method is used), this property will just be ignored.
The byte limits are total limits for each
user (not for each session as at /ip hotspot
active). So, if a user has already downloaded
something, then session limit will show the total limit - (minus) already
downloaded. For example, if download limit for a user is 100MB and the user has
already downloaded 30MB, then session download limit after login at /ip hotspot active will be 100MB - 30MB
= 70MB.
Should a user reach his/her limits
(bytes-in >= limit-bytes-in or bytes-out >= limit-bytes-out), he/she will
not be able to log in anymore.
The statistics is updated if a user is
authenticated via local user database each time he/she logs out. It means, that
if a user is currently logged in, then the statistics will not show current
total values. Use /ip hotspot active submenu to view the statistics on the current user sessions.
To add user Ex with password Ex that is allowed to log in only with
01:23:45:67:89:AB MAC address and is limited to 1 hour of work:
[admin@MikroTik] ip hotspot user> add name=Ex password=Ex \
\... mac-address=01:23:45:67:89:AB limit-uptime=1h
[admin@MikroTik] ip hotspot user> print
Flags: X - disabled
# NAME
ADDRESS MAC-ADDRESS PROFILE
UPTIME
0 Ex 0.0.0.0 01:23:45:67:89:AB default 0s
[admin@MikroTik]
ip hotspot user> print detail
Flags: X - disabled
0 name="Ex" password="Ex"
address=0.0.0.0 mac-address=01:23:45:67:89:AB
profile=default routes=""
limit-uptime=1h limit-bytes-in=0
limit-bytes-out=0 uptime=0s
bytes-in=0 bytes-out=0 packets-in=0
packets-out=0
[admin@MikroTik] ip hotspot user>
Submenu level: /ip hotspot active
Description
The active user list shows the list of currently logged in users.
Nothing can be changed here, except user can be logged out with the remove command
address (read-only: IP address) - IP address of the user
bytes-in (read-only: integer) - how many bytes did the router receive from the client
bytes-out (read-only: integer) - how many bytes did the router send to the client
domain
(read-only: text) - domain of the user (if split from username)
idle-timeout (read-only: time) - how much idle time it is left for the user until he/she will be
automatically logged out
keepalive-lost (read-only: time) - how much time past since last packed from the client has been
received
packets-in (read-only: integer) - how many packets did the router receive from the client
packets-out (read-only: integer) - how many packets did the router send to the client
session-timeout (read-only: time) - how much time is left for the user until he/she will be
automatically logged out
uptime
(read-only: time) - current session time (logged in time) of the user
user
(read-only: name) - name of the user
To get the list of active users:
[admin@MikroTik] ip hotspot active> print
Flags: R - radius, H - DHCP
# USER
ADDRESS UPTIME SESSION-TIMEOUT IDLE-TIMEOUT
0 Ex
10.0.0.144 4m17s 55m43s
[admin@MikroTik] ip hotspot active>
Submenu level: /ip hotspot aaa
Property Description
accounting (yes | no; default: yes) - whether RADIUS accounting should be used (have no effect if RADIUS
is not used)
interim-update (time;
default: 0s)
- Interim-Update time interval
0s
- do not send accounting updates
use-radius (yes | no; default: no) - whether user database in a RADIUS server should be consulted
RADIUS user database is consulted only if
the required username is not found in local user database
The value set in interim-update is overridden by the
value sent by a RADIUS server (if any)
To enable RADIUS AAA:
[admin@MikroTik] ip hotspot aaa> set use-radius=yes
[admin@MikroTik] ip hotspot aaa> print
use-radius: yes
accounting: yes
interim-update: 0s
[admin@MikroTik] ip hotspot aaa>
Submenu level: /ip hotspot server
Description
HotSpot Server configuration is used to modify DHCP leases for logged-in
users in order them to get non-temporary addresses. When a user has
successfully authenticated, the HotSpot Server communicates with the DHCP
server to change the lease information the user will receive next time he/she
will request the DHCP lease (that is why the lease of temporary address should
be as short as possible). The new lease should not be for a long time either
for users to be able to switch fast on one machine as well as to reuse the IP addresses
of this pool (users are logged out just as they click the log out button, but
their addresses stay allocated to the machines they have been using, making it
impossible for another users to log in from these machines)
address-pool (name)
- IP pool name, from which a HotSpot client will get an IP address if it is not
given a static IP address
dhcp-server (name)
- DHCP server with which to use this profile
lease-time (time;
default: 1m)
- DHCP lease time for logged in user
login-delay (time;
default: 10s)
- Time required to log user in. The after-login page is displayed for this
time. This time should be approximately the same as the lease-time for the
temporary address lease
name
(name)
- server profile name
This configuration is ignored by enabled-address method.
There can be added one HotSpot Server for
each DHCP server. Which server profile to apply will depend on DHCP server
which gave DHCP lease to that client. Actually it means that if user will log
in from different interfaces, then different server profiles will be used. It
allows assigning different IP addresses on different Ethernet interfaces.
Network mask, gateway and some other
setting are set up in /ip dhcp network submenu
To add a HotSpot server named dhcp1 to the DHCP server hotspot-dhcp giving IP addresses from the hotspot address pool:
[admin@MikroTik] ip hotspot server> add name=dhcp1
dhcp-server=hotspot-dhcp \
\... address-pool=hotspot
[admin@MikroTik] ip hotspot server> print
# NAME DHCP-SERVER ADDRESS-POOL LOGIN-DELAY LEASE-TIME
0 dhcp1 hotspot-dhcp hotspot
10s 1m
[admin@MikroTik] ip hotspot server>
Submenu level: /ip hotspot cookie
Description
Cookies can be used for authentication in the Hotspot service
domain
(read-only: text) - domain name (if split from username)
expires-in (read-only: time) - how long the cookie is valid
mac-address (read-only: MAC address) - user's MAC address
user
(read-only: name) - username
There can be multiple cookies with the
same MAC address. For example, there will be a separate cookie for each web
browser on the same computer.
Cookies can expire - that's the way how it is supposed to be. Default
validity time for cookies is 1 day (24 hours), but it can be changed:
/ip hotspot set http-cookie-lifetime=3d
To get the list of valid cookies:
[admin@MikroTik] ip hotspot cookie> print
# USER DOMAIN MAC-ADDRESS EXPIRES-IN
0 Ex
01:23:45:67:89:AB 23h54m16s
[admin@MikroTik] ip hotspot cookie>
Submenu level: /ip hotspot walled-garden
Description
Walled garden is a system which allows unauthorized use of some
resources, but requires authorization to access other resources. This is
useful, for example, to give access to some general information about HotSpot
service provider or billing options.
action
(allow | deny; default: allow) - action to undertake if a packet matches the rule:
allow
- allow the access to the page without prior authorization
deny
- the authorization is required to access this page
dst-host (text;
default: "")
- domain name of the destination web server (this is regular expression)
dst-port (integer;
default: "")
- the TCP port a client has send the request to
path
(text;
default: "")
- the path of the request (this is regular expression)
Currently you can not place HTTPS servers
inside the Walled Garden. However, there is a workaround on this. You can add a
mangle rule that allows you to pass traffic to an IP address of secure web
server, exempli gratia:
/ip firewall mangle add dst-address=159.148.108.1/32 mark-flow=hs-auth
To allow unauthorized requests to the www.example.com domain's /paynow.html page:
[admin@MikroTik] ip hotspot walled-garden> add
path="^/paynow\\.html$" \
\... dst-host="^www\\.example\\.com$"
[admin@MikroTik] ip hotspot walled-garden> print
Flags: X - disabled
# DST-HOST DST-PORT PATH ACTION
0 ^www\.example\.com$ ^/paynow\.html$ allow
[admin@MikroTik] ip hotspot walled-garden>
Notes:
The HotSpot servlet recognizes 5 different request types:
Note that if it is not possible to
meet a request using the pages stored on the router's FTP server, the default
pages are used.
There are many possibilities to customize what the HotSpot
authentication pages look like:
To insert variable in some place in HTML file, variable name surrounded
by % symbols is used. This construction may be used in any HotSpot HTML file
accessed as '/', '/login', '/status' or '/logout'. For example, to show a link
to the login page, following construction can be used:
<a href="%link-login%">login</a>
All of the Servlet HTML pages use variables to show user specific
values. Variable names appear only in the source - they are automatically
replaced with the respective values by the HotSpot Servlet. For each variable
there is an example included in brackets.
To insert % symbol as a text (not as a
part of variable construction), "%%" has to be used (if there is only
one % symbol on a page or string between it and next % symbol is not a valid
variable name, % may be used with the same result).
In most cases it is required login page to
use main
variable. And it is strongly suggested to place it BEFORE form-input input form. Otherwise
situation can happen, that user already has entered his username/password, but
MD5 encryption JavaScript is not yet loaded. It may result in password being
sent over network in plain text. And of course, that login will fail in this
case, too (if allow-unencrypted-password property is not set to yes).
The resulting password to be sent to the
HotSpot gateway is formed MD5-hashing the concatenation of the following:
chap-id, the password of the user and chap-challenge (in the given order)
The gateway uses CHAP authentication in
case client's browser is hashing his/her pasword (in other words, if the main variable has been initialized
successfully before the form is being submitted). In case plain-text password
has been sent, PAP authentication algorithm is used. So if you want to force
PAP-only authentication, you must remove the main variable from the servlet (of course, you must also allow the gateway
to accept unencrypted passwords, or otherwise no one would be able to login at
all).
In case if variables are to be used in
link directly, then they must be escaped accordingly. For example, in login
page??<a
href="https://login.example.com/login?mac=%mac%&user=%user%">link</a>
will not work as intended, if username will be "123&456=1 2". In
this case instead of %user%, its escaped version must be used: %user-esc%:
<a
href="https://login.server.serv/login?mac=%mac-esc%&user=%user-esc%">link</a>.
Now the same username will be converted to "123%26456%3D1+2", which
is the valid representation of "123&456=1 2" in URL. This trick
may be used with any variables, not only with %user%.
With basic HTML language knowledge and the examples below it should be
easy to implement the ideas described above.
<input type="text" %input-user%>
to this line:
<input type="hidden" name="user"
value="hsuser">
(where hsuser is the username you are providing)
<input type="password" %input-password%>
to this line:
<input type="hidden" name="password"
value="hspass">
(where hspass is the password you are providing)
https://www.server.serv/register.html?mac=XX:XX:XX:XX:XX:XX
change the Login button link in login.html
to:
https://www.server.serv/register.html?mac=%mac%
(you should correct the link to point to
your server)
if ('%popup%' == 'true') newWindow();
add the following line:
open('http://your.web.server/your-banner-page.html',
'my-banner-name','');
(you should correct the link to point to
the page you want to show)
<input type="hidden" name="dst"
value="%link-orig%">
to this line:
<input type="hidden" name="dst"
value="http://your.web.server">
(you should correct the link to point to
your server)
location.href = '%link-redirect%';
with this line:
location.href = 'http://your.web.server';
and replace this line:
<td align="center" valign="bottom"
height="50px">If still nothing happens, press <a
href="%link-redirect%">here</a></td>
with this:
<td align="center" valign="bottom"
height="50px">If still nothing happens, press <a
href="http://your.web.server">here</a></td>
An another example is making HotSpot to authenticate on a remote server
(which may, for example, perform creditcard charging):
Here is an example of such a login page to
put on the HotSpot router (it is redirecting to
https://auth.example.com/login.php, replace with the actual address of an
external authentication server):
<html>
<title>...</title>
<body>
<form name="redirect"
action="https://auth.example.com/login.php"
method="post">
<input type="hidden" name="mac"
value="%mac%">
<input type="hidden" name="ip"
value="%ip%">
<input type="hidden" name="user"
value="%user%">
<input type="hidden" name="link-login"
value="%link-login%">
<input type="hidden" name="link-orig"
value="%link-orig%">
<input type="hidden" name="error"
value="%error%">
</form>
<script
language="JavaScript">
<!--
document.redirect.submit();
//-->
</script>
</body>
</html>
Here is an example of such a page (it is
redirecting to https://hotspot.example.com/login, replace with the actual
address of a HotSpot router; also, it is displaying www.mikrotik.com after
successful login, replace with what needed):
<html>
<title>Hotspot login page</title>
<body>
<form name="login"
action="https://hotspot.example.com/login"
method="post">
<input type="text" name="user"
value="demo">
<input type="password" name="password"
value="none">
<input type="hidden" name="domain"
value="">
<input type="hidden" name="dst"
value="http://www.mikrotik.com/">
<input type="submit" name="login" value="log
in">
</form>
</body>
</html>
There are two kinds of errors: fatal non-fatal. Fatal errors are shown
on a separate HTML page called error.html. Non-fatal errors are basically
indicating incorrect user actions and are shown on the login form.
General non-fatal
errors:
General fatal errors:
Local HotSpot user
database non-fatal errors:
RADIUS client non-fatal errors:
RADIUS client fatal
errors:
HotSpot Step-by-Step User Guide for dhcp-pool Method
Let us consider following example HotSpot setup:
There will be 2 HotSpot IP address ranges used for clients on prism1 interface. You are free to choose
the address ranges, just make sure you use masquerading for not routed ones. In this example, we
are using:
For HotSpot client accounting, HotSpot will add dynamic firewall rules
in firewall HotSpot chain. This chain has to be created manually. And all
network packets (to/from HotSpot clients) have to pass this chain.
4.
/interface
prism set prism1 arp=reply-only
6.
/ip
address add address=192.168.0.1/24 interface=prism1 \
7. comment="hotspot
temporary network"
8.
/ip
address add address=10.5.50.1/24 interface=prism1 \
9. comment="hotspot real
network"
11.
/ip
pool add name=hs-pool-temp ranges=192.168.0.2-192.168.0.254
12.
/ip
pool add name=hs-pool-real ranges=10.5.50.2-10.5.50.254
14.
/ip
firewall src-nat add src-address=192.168.0.0/24 action=masquerade \
15.
comment="masquerade hotspot temporary
network"
Make sure you have routing for
authenticated address space. Try to ping 10.5.50.1 from your Internet gateway
10.5.6.1, for example. See the Basic Setup Guide on how to set up routing.
17.
/ip
dhcp-server add name="hs-dhcp-server" interface=prism1 lease-time=14s
\
18.
address-pool=hs-pool-temp add-arp=yes disabled=no
19.
/ip
dhcp-server network add address=192.168.0.0/24 gateway=192.168.0.1 \
20. dns-server=159.148.60.2,159.148.108.1
domain="example.com"
22. /ip
hotspot server add name=hs-server dhcp-server=hs-dhcp-server \
23. address-pool=hs-pool-real
24.
/ip
dhcp-server network add address=10.5.50.0/24 gateway=10.5.50.1 \
25. dns-server=159.148.60.2,159.148.108.1
domain="example.com"
27. /ip
hotspot user add name=Ex password=Ex
29.
/ip
service set www port=8081
30. /ip
service set hotspot port=80
Note!
Changing www service to other port than 80 requires that you specify the new
port when connecting to MikroTik router using WinBox, e.g., use 10.5.50.1:8081
in this case.
32. /ip
firewall dst-nat add src-address=192.168.0.0/24 dst-port=443 protocol=tcp \
33. action=redirect to-dst-port=443\
34. comment="redirect unauthorized hotspot
clients to hotspot service"
35. /ip
firewall dst-nat add src-address=192.168.0.0/24 protocol=tcp \
36. action=redirect to-dst-port=80 \
37. comment="redirect unauthorized hotspot
clients to hotspot service"
39. /ip
firewall add name=hotspot-temp comment="limit unauthorized hotspot
clients"
40.
41. /ip
firewall rule forward add src-address=192.168.0.0/24 action=jump \
42. jump-target=hotspot-temp
comment="limit access for unauthorized hotspot clients"
43.
44. /ip
firewall rule input add src-address=192.168.0.0/24 dst-port=80 \
45. protocol=tcp
action=accept comment="accept requests for hotspot servlet"
46. /ip
firewall rule input add src-address=192.168.0.0/24 dst-port=443 \
47. protocol=tcp
action=accept comment="accept request for hotspot servlet"
48. /ip
firewall rule input add src-address=192.168.0.0/24 dst-port=67 \
49. protocol=udp
action=accept comment="accept requests for local DHCP server"
50. /ip
firewall rule input add src-address=192.168.0.0/24 action=jump \
51. jump-target=hotspot-temp
comment="limit access for unauthorized hotspot clients"
52.
53. /ip
firewall rule hotspot-temp add protocol=icmp action=return \
54. comment="allow ping requests"
55. /ip
firewall rule hotspot-temp add protocol=udp dst-port=53 action=return \
56. comment="allow dns requests"
57. /ip
firewall rule hotspot-temp add action=reject \
58. comment="reject access for
unauthorized hotspot clients"
60. /ip
firewall add name=hotspot comment="account authorized hotspot
clients"
62. /ip
firewall rule forward add action=jump jump-target=hotspot \
63. comment="account traffic for
authorized hotspot clients"
Note that in order to use
SSL authentication, you should install an SSL certificate. This topic is not
covered by this manual section. Please see the respective manual section on how
to install certificates in MikroTik RouterOS
HotSpot Step-by-Step User Guide for
enabled-address Method
Let us consider
following example HotSpot setup:
There are clients at prism1 interface, which are
able to use Internet already. You want all these clients to authenticate before
they are able to use Internet.
For hotspot client
accounting, hotspot will add dynamic firewall rules in firewall hotspot chain.
This chain has to be created manually. And all network packets (to/from hotspot
clients) have to pass this chain.
2. /ip
service set www port=8081
3. /ip
service set hotspot port=80
Note! Changing www service to other port than 80 requires that you
specify the new port when connecting to MikroTik router using WinBox, e.g., use
10.5.50.1:8081 in this case.
5. /ip
hotspot profile set default mark-flow="hs-auth"
login-method=enabled-address
7. /ip
hotspot user add name=Ex password=Ex
9. /ip
firewall dst-nat add in-interface="prism1" flow="!hs-auth"
protocol=tcp \
10. dst-port=443 action=redirect
to-dst-port=443 \
11. comment="redirect unauthorized hotspot
clients to hotspot service"
12. /ip
firewall dst-nat add in-interface="prism1" flow="!hs-auth"
protocol=tcp \
13. action=redirect to-dst-port=80 \
14. comment="redirect unauthorized clients
to hotspot service"
16. /ip
firewall add name=hotspot-temp comment="limit unauthorized hotspot
clients"
17.
18. /ip
firewall rule forward add in-interface=prism1 action=jump \
19. jump-target=hotspot-temp
comment="limit access for unauthorized hotspot clients"
20.
21. /ip
firewall rule input add in-interface=prism1 dst-port=80 protocol=tcp \
22. action=accept
comment="accept requests for hotspot servlet"
23. /ip
firewall rule input add in-interface=prism1 dst-port=443 protocol=tcp \
24. action=accept
comment="accept request for hotspot servlet"
25. /ip
firewall rule input add in-interface=prism1 dst-port=67 protocol=udp \
26. protocol=udp
action=accept comment="accept requests for local DHCP server"
27. /ip
firewall rule input add in-interface=prism1 action=jump \
28. jump-target=hotspot-temp
comment="limit access for unauthorized hotspot clients"
29.
30. /ip
firewall rule hotspot-temp add flow="hs-auth" action=return \
31. comment="return if connection is
authorized"
32. /ip
firewall rule hotspot-temp add protocol=icmp action=return \
33. comment="allow ping requests"
34. /ip
firewall rule hotspot-temp add protocol=udp dst-port=53 action=return \
35. comment="allow dns requests"
36. /ip
firewall rule hotspot-temp add action=reject \
37. comment="reject access for
unauthorized clients"
39. /ip
firewall add name=hotspot comment="account authorized hotspot
clients"
41. /ip
firewall rule forward add action=jump jump-target=hotspot \
42. comment="account traffic for
authorized hotspot clients"
Note that in order to use
SSL authentication, you should install an SSL certificate. This topic is not
covered by this manual section. Please see the respective manual section on how
to install certificates in MikroTik RouterOS
As we see from
example, only hotspot interface is used - we don't care what IP addresses are
there.
It is possible to add
hotspot authentication for one more interface (prism2) by adding only 4
additional firewall rules:
·
/ip firewall dst-nat add in-interface="prism2"
flow="!hs-auth" protocol=tcp \
·
dst-potr=443 action=redirect
to-dst-port=443 \
·
comment="redirect unauthorized prism2
clients to hotspot service"
·
/ip firewall dst-nat add
in-interface="prism2" flow="!hs-auth" protocol=tcp \
·
action=redirect to-dst-port=80 \
·
comment="redirect unauthorized prism2
clients to hotspot service"
·
/ip firewall rule forward add
in-interface=prism2 action=jump \
·
jump-target=hotspot-temp
comment="limit access for unauthorized prism2 clients"
·
/ip firewall rule input add
in-interface=prism2 action=jump \
·
jump-target=hotspot-temp
comment="limit access for unauthorized prism2 clients"
·
/ip firewall dst-nat add
src-address=10.5.50.0/24 dst-port=25 protocol=tcp \
·
to-dst-address=10.5.6.100 action=nat \
·
comment="Translate SMTP TCP 25 port to
our mail server"
·
[admin@MikroTik] ip hotspot
walled-garden> add \
·
\...
dst-host="^hotspot\\.example\\.com$"
·
[admin@MikroTik] ip hotspot
walled-garden> print
·
Flags: X - disabled
·
#
DST-HOST
DST-PORT PATH
ACTION
·
0
^hotspot\.example\.com$
allow
·
[admin@MikroTik] ip hotspot
walled-garden>
4.
/ip hotspot set
hotspot-address=10.5.50.1
6.
/ip web-proxy set enabled=yes
src-address=10.5.50.1:3128 transparent-proxy=yes
8.
/ip hotspot set
parent-proxy=10.5.50.1:3128
10.
/ip firewall dst-nat add
in-interface=prism1 dst-address=!10.5.50.1/32 \
11.
dst-port=80 protocol=tcp action=redirect
12.
to-dst-port=8088 comment="transparent
proxy"
to enable accounting for the HotSpot user
traffic to/from transparent web-proxy, additional firewall rules should be
added:
/ip firewall rule input add in-interface=prism1 dst-port=3128 \
protocol=tcp action=jump
jump-target=hotspot \
comment="account
traffic from hotspot client to local web-proxy"
/ip firewall rule output add
src-port=3128 protocol=tcp \
out-interface=prism1 action=jump
jump-target=hotspot \
comment="account traffic from local
web-proxy to hotspot client"
·
/ip hotspot profile set
default shared-users=10
·
/ip dns set
primary-dns=159.148.60.2
·
/ip dns set
allow-remote-requests=yes
·
/ip firewall dst-nat add
protocol=udp dst-port=53 action=redirect \
·
comment="intercept all
DNS requests"