mbox has a unique feature to host captive portal contents on mbox itself and deliver the page contents to users locally from mbox storage space, while mbox periodically/nightly syncs with cloud-hosted server for content updates. 

In this approach, the portal contents are still centrally managed, but the user experience are significantly improved as the page contents are locally served to users without going through a public Internet connection. 

There're several advantages to let mbox deliver page contents locally from mbox:

1. faster responses time when login/landing page initiates, as it does not need to request to an Internet-based captive portal server (mbox.ransnet.com). This is particularly useful when mbox is deployed in a foreign country or the mbox local Internet is slow.

2. reducing back-haul utilization. Since the page contents are served off from mbox local storage, there's a significant reduction on back-haul usage, especially if the login page or landing page contents are customized with video and audio contents. With this capability, it's now possible stream large video/music files to large group of users concurrently without worrying about Internet bottlenecks.

This feature is particularly useful for TVC based advertising when mbox is used as a gateway, where users are required to view a short video before mbox allows them full Internet access. The video contents are streamed through local storage without causing congestion to backhaul link. It is also needed for customers requirement payment gateway integration which allows users to purchase WiFi access plans online (in this case HSG functions as a web server).

There're a few major notes on this feature:

1. managing page contents. This is the same as "cloud-hosted" portals", therefore portal contents are still centrally managed.

2. we need to configure mbox to pull page contents from cloud-hosted server for a specific customer, then it will auto sync every 15 minutes for content updates (if you need immediate refresh, just reboot mbox and it will try to sync for updates while booting up, but make sure mbox is online first).

3. we need to configure a loopback interface with an un-used IP address (eg. 2.2.2.2/32), and this IP will be our future portal server IP to deliver page contents. NOTE: don't use 1.1.1.1 as the loopback IP, it's the default for Cisco WLC and it will not route user traffic to HSG.

4. we need to configure DNS re-write to point splash.ransnet.com to the loopback Interface (eg. 2.2.2.2)

5. configure hotspot instance to use splash.ransnet.com as our portal URL, https://splash.ransnet.com/<partnerid>/<customer-id>/login.php

6. under "security hotspot xx", the DNS name-server assigned to client must be hotspot-server IP (in this case, mbox acts as a name-server proxy for internal client users), client-dhcp-dns <hotspot-server ip>

7. Configure firewall-input rules to permit http & https access to mbox for traffic coming from hotspot vlan. Because in this case, HSG function as a webserver to deliver the portal pages. (but this is not needed for cloud-hosted portals)

NOTE: 

1. local-hosted portal does not support social media integration

2. the loopback (eg. 2.2.2.2) has to be an unique IP address that's not used in any other parts of the network.

CONFIGURATION EXAMPLE

NOTE: 

• for cloud-hosted portal, the portal URL is http://mbox.ransnet.com/<partnerid>/<customerid>/login.php

• for local-hosted portal, the portal URL is http://splash.ransnet.com/<partnerid>/<customerid>/index.php

• if you've enabled proxy or ads injection on the same box, please bypass dnat for local loopback ip. refer to proxy configure guide.

Attached is a complete config example:

• demo is the partnerid

• login requires user login

• login-reg requires user login with a self-registration template

• tos doesn't require login, just accept "terms of service" and connect