Hotspot Integration

A hotspot is a physical location where people can access the Internet, typically using Wi-Fi, via a wireless local area network (WLAN) with a router connected to an Internet service provider.

Subscriber Management supports various flexibility in configuration. However, it's not up to the Radius Server or overall Subscriber Management platform to implement walled gardens or captive portals.

Some software solutions for Radius AAA attempt to build too much management logic and operation flow into its software. It can work in rare cases or initially but only cater to some possible scenarios. We leave the control in the operators hands.

In short, the Subscriber Management platform manages the life cycle of connected sessions and the configuration of subscribers. However, that said, the configuration only works well when the vendor supports and implements the features required to deliver them.

The Subscriber Management platform tracks the state of a subscriber enabled/disabled or expired and available data, and then only informs the vendor equipment, such as the BNG, to redirect the customer to a captive portal page via specific attributes only supported by that vendor.

When deploying a hotspot or captive portal solution, it's essential to understand that your network equipment, such as the BNG/NAS/WIFI router, fully supports the intended workflow.

Known issues

None of the issues described below relating HOTSPOT is related to Radius protocol or its implementation or the subscriber management platform. These are known issues based on various technologies used by customers and simply just how IP, the internet works.

Payment Gateways

When building a captive portal, a common issue is that when customers use a payment gateway for card transactions, they could fail due to limitations on most vendor equipment for walled gardens and captive portals. This is not an issue related to Subscriber Management or Radius functionality.

Two-factor authentication (2FA) provides an additional layer of security by requiring customers to take an extra step during the e-commerce checkout process, typically by entering a password or text code provided to the cardholder by their card-issuing bank.

Visa and Mastercard have implemented 3DSecure, two-factor authentication (2FA) for credit card transactions at any online store. If a customer uses 3DSecure, you can't get a chargeback for fraud. However, most banks force this functionality on their customers.

The payment gateway you utilise will redirect the user to a popup page on a 3DSecure server located anywhere on the Internet. The IP address and domains are not always the same or known. Due to the user being suspended and only having access to the portal, he will not be able to view this page to enter his verification code or advise him to check an authorised device to permit this payment, such as a banking application on his phone.

Voucher systems will, of course, work, and other payment methods may not require 2FA. However, be warned that this is a known issue and cannot be resolved by any Radius or Subscriber Management platform.

A networking team can, however, implement a DPI that would do the redirection instead and have the intelligence to inspect the user's traffic and allow permitted authorisation pages like 3DSecure, etc. However, this does require additional network equipment and complexity in design network wise.

Another option is to allow trial access, which is problematic, abused and difficult to manage. The main issue with trial access is permitting the user access to sign up and providing temporary internet while he goes and makes the payment. It's open to abuse, especially in public hotspot areas, and there is no solid way to block it effectively without creating other support/administration issues.

User state

When a user registers or the captive portal/orchestration platform makes an API call to our platform to activate the user, we will send COA or POD packets for subscribers sessions. This means either changing his level of access or disconnecting him so he reconnects with the Internet. It all depends on what your vendors equipment supports.

In some cases, if you have upstream network issues, we will not be able to communicate with your vendor device and the user will remain restricted to the captive portal / walled garden. This is a scarce issue. However, the user can reconnect to the WIFI or reset his device, and he will be permitted access.

Service providers should ensure that their network connectivity is stable.

Browser

In most cases, some devices' browser hotspot connection window has some restrictions. It may not support cookies, local storage and more. Developers of captive portal pages should keep this part of their web application as simple as possible.

Redirection

It is impossible to redirect secure websites (HTTPS) to the captive portal by router equipment. Most pages, such as Google, are HTTPS today. The Google redirection from HTTP to its secure page is typically cached by browsers, meaning the browser will automatically visit the secure page without attempting first to do so via the network. Therefore, the router will not be able to redirect it.

In the event, users should be provided with a website (URL/location) for the captive portal when they do not get redirected and need to top up or create a subscription.

WIFI Hotspot

Some vendor equipment has the ability to redirect the user to a captive portal when authentication fails and he can register on the portal for Internet. The portal would create his subscriber via API calls to our platform and once he's ready to browse redirect him to a page on the Wi-Fi device to inform it re-authenticate the user and connect him. This is one of the most common applications.

Mikrotik HOTSPOT

Mikrotik uses the above WIFI method; however, we have a test login portal and URL to re-authenticate the user. This means the external captive portal will not redirect the user to the device directly but to our URL on our cloud platform.

The URL will first authenticate the user locally, with the credentials posted from the external captive portal, to ensure his functionality and then redirect him to the WIFI device to re-authenticate and connect him.

It seems like unnecessary middleware. However, we can introduce more features on the system to fault find, log, and manage the WIFI Access Points (AP) or devices when doing so.

Mikrotik requirements

This is only the minimal required setup, and you are welcome to change and enhance or even bypass our hotspot authentication URL.

Mikrotik Requirements:

  • Level 4 MikroTik license and up loaded on device.

  • Latest firmware and software packages is recommended.

  • Device should have Internet Connection.

Authentication Flow

  1. Subscriber connects to WIFI hotspot router.

  2. The router performs DHCP and assigns an IP address to the Subscriber.

  3. MAC-Cookie Authentication: The Router checks if the MAC address is bound to the username and password stored in memory with expiration time from the previous authentication. The router validates the authentication details against Radius and if the successful subscriber is connected.

  4. If enabled, The router performs MAC authentication against Radius, using the username as MAC-ADDRESS and preferably the predefined password. If successful, the subscriber is connected.

  5. The router redirects subscribers to the captive portal login page on the router.

  6. The captive portal login page HTML is modified on the router to redirect the subscriber to the customer-customized external web application / captive portal. This is typically an orchestrator platform where users can sign up, load vouchers, etc.

  7. The captive portal makes an API call to NebularStack Subscriber Management and creates/enables the subscriber account via HTTP REST with JSON. (Please refer to our API documentation under Subscriber Management)

  8. The subscriber must still be connected and authenticated to connect. The external captive portal should direct the subscriber's browser to the NebularStack external page to authenticate the user using a post method with the user credentials included.

  9. NebularStack authenticates the subscriber and directs him to the Mikrotik login page.

  10. The Mikrotik login page received his authentication details and performed Radius authentication against the Radius servers configured.

  11. Subscriber is successfully connected.

Radius Configuration

Typically you would have a single Virtual Server with 3 instances provided by our team. Each of these instances comes with its own IP Address and is not placed on the same physical hardware, it's in a totally separate high availability zone.

Ensure the secret and src-address match exactly what is configured on NebularStack or provided by our team. It is recommended to set a high timeout of 1500ms on Mikrotik even though in general authentication requests for example are much faster. Latency and Jitter over a network and the Internet can affect your authentication requests if they time out too early.

When we refer to Mikrotik loopback IP it should be an IP address bound to a bridge/virtual interface that never goes offline. Therefore when your device uses multiple interfaces securely to reach the Radius it will always come from the trusted IP address configured.

Mikrotik example configuration:

/radius
add address=<$instance1-ip> secret=testing123 service=ppp,hotspot,wireless src-address=\
    <$mikrotik-loopback-ip> timeout=1s500ms
add address=<$instance2-ip> secret=testing123 service=ppp,hotspot,wireless src-address=\
    <$mikrotik-loopback-ip> timeout=1s500ms
add address=<$instance3-ip> secret=testing123 service=ppp,hotspot,wireless src-address=\
    <$mikrotik-loopback-ip> timeout=1s500ms
/radius incoming
set accept=yes
set port=3799

Hotspot Configuration

DNS-Name is the name of your hotspot, and it requires no external domain or DNS configuration. This is the address of the hotspot captive portal on the Mikrotik router. Our platform supports and is tested using MAC, HTTP-PAP and MAC-COOKIE authentication, and it's recommended to set the radius-interim-update to precisely 10 minutes. Setting it higher is fine but is not recommended.

The hotspot address should be the customers gateway IP Address on the bridge or WIFI interface. You still need to configure the WIFI, Bridges (optional), NAT, etc, yourself and outside the scope here.

Mikrotik example configuration:

/ip hotspot profile
add dns-name=interstellio.hotspot hotspot-address=10.41.41.1 html-directory=\
    flash/hotspot login-by=mac,http-pap,mac-cookie mac-auth-password=testing name=\
    HOTSPOT radius-interim-update=10m use-radius=yes
/ip pool
add name=IPOE-HOTSPOT ranges=10.41.41.2-10.41.41.254
/ip dhcp-server
add address-pool=IPOE-HOTSPOT disabled=no interface="BRIDGE: HOTSPOT" \
    lease-time=1h name=IPOE-HOTSPOT
/ip hotspot
add address-pool=IPOE-HOTSPOT addresses-per-mac=25 disabled=no interface=\
    "BRIDGE: HOTSPOT" keepalive-timeout=2m name=HOTSPOT profile=HOTSPOT
/ip dhcp-server network
add address=10.41.41.0/24 comment="hotspot network" gateway=10.41.41.1
/ip dns
set allow-remote-requests=yes servers=10.41.41.1
/ip hotspot walled-garden
add dst-host=admin.interstellio.io server=HOTSPOT
/ip hotspot walled-garden ip
add action=accept disabled=no dst-address=102.220.62.5 !dst-address-list !dst-port \
    !protocol !src-address !src-address-list

Hotspot login.html

The login.html file should be updated on the HOTSPOT router with the following example, which will send the correct parameters to the captive portal to authenticate and manage the subscriber.

Mikrotik example login.html:

<html>
<title>...</title>
<body>
    <form name="redirect" action="https://admin.interstellio.io/external/hotspot/mikrotik/login" method="post">
        <input type="hidden" name="domain" value="demo">
        <input type="hidden" name="region" value="South Africa">
        <input type="hidden" name="virtual-id" value="11b3bf44-cdba-11ee-a07d-0f953b8c9f32">
        <input type="hidden" name="link-success" value="$(link-orig)">
        <input type="hidden" name="mac" value="$(mac)">
        <input type="hidden" name="ip" value="$(ip)">
        <input type="hidden" name="username" value="$(username)">
        <input type="hidden" name="link-login" value="$(link-login)">
        <input type="hidden" name="error" value="$(error)">
        <input type="hidden" name="plain-passwd" value="$(plain-passwd)">
    </form>
    <script language="JavaScript">
        document.redirect.submit();
    </script>
</body>
</html>

The following must be updated as per your deployment:

  • domain: Should be your NebularStack domain in which the subscribers are located.

  • region: NebularStack Region. (for example, South Africa)

  • virtual-id: Your virtual server unique identifier on Nebularstack.

Other values are simply dynmically applied by the router:

  • link-success: original URL requested ("http://www.example.com/")

  • mac: MAC address of the subscriber device ("01:23:45:67:89:AB")

  • ip: IP address assigned to subscriber device ("10.41.41.100")

  • username: the name of the user ("guy@isp.com")

  • link-login: link to router login page including original URL requested ("http://10.41.41.1/login?dst=http://www.example.com/")

  • error: error message, if something failed ("invalid username or password")

  • plain-passwd: a "yes/no" representation of whether HTTP-PAP login method is allowed.

In most cases, the page will not be directed to the Nebularstack Mikrotik hotspot page but to an external platform, which is the personalised captive portal.

However, the personalised external captive portal must POST all the above values, including username and password for the subscriber account, back to our URL https://admin.interstellio.io/external/hotspot/mikrotik/login which will authenticate the user and, if validated. POST the relevant data via the subscribers browser back to the Mikrotik.

The username and password are the customer's radius login credentials essentially that were created via an API call to the Subscriber Management endpoint.