Skip to content

Sub natted WISPr Sites

One of the fun things I've gotten the chance to work on are WISPr sites. These are sites where a local device, usually an AP in my experience, but potentially a router or other captive portal system, puts network-joiners into a walled garden in which they can only access an External Portal Server. This server then works with the local infrastructure through some kind of controller intermediary to grant access based on purchases or any other factor it chooses.

Goal

The advantage of a WISPr site is that the local hardware is controlled from infrastructure running on datacenters accessible via the internet or a private network. This makes it most suitable for deployments where simple, low cost and low maintenance / installation costs are desired and customers expect a relatively simple experience of onboaring a single phone or laptop. Since the actual L2 network and uplink are locally managed, stuff like traffic shaping and content filtering will likely depend on local management. Think coffeeshop WiFi experience, not SOHO.

Design

I have two testing WISPr sites running in my lab. One with a TP-LINK Router and a RUCKUS AP, one with a Microtik Router and a TP-LINK AP. I purposefully switched the brands for testing cross-compatibility. In both cases, the Walled Garden is implemented at the AP level, and the WAN port of the router is connected into a LAN access port managed by my home rXg and purposefully designed to be the L2 interface for these sub natted WISPr sites.

  • Layer 2 Interface: Subnatted wispr sites vlan
  • Layer 3 Address: Subnatted wispr sites address

In this scenario the rXg implements the external portal server and its RADIUS / API Integrations. I have worked on two of these integrations so far, one for RUCKUS and one for TP-Link. I plan to go into more detail on these specific integrations in future posts. Usually the rXg works through and manages Layer 2 networks between itself and its clients, but in this scenario, these clients are natted through a local non-rXg gateway.

Sub-natting and DHCP

The gateways at these sites can be expected to be extremely cheap and generic, They only need to do two functions, Network Address Translation (NAT) and Dynamic Host Configuration Protocol (DHCP).

Subnatted wispr sites dhcp pool

NAT

NATting makes it possible for many machines to work together behind one IP address. Whenever any machine wants to make an outbound connection, it connects through a high-number port of the gateway. Any traffic coming into the gateway for that port is forwarded back to the client that initiated the connection.

DHCP

DHCP is the mechanism for giving private -- ie site-local, non globally routable -- IP addresses to network joiners. Typically when a device joins, and IP address is "leased" from the available addresses in an overall "pool" of DHCP addresses. If too many devices have joined the network, combined with a long DHCP lease period and too small of n overall DHCP pool, lack of free DHCP addresses may prevent new devices from joining the network.

PoE+ Injection

PoE is a big part of WiFi deployments because convenient power outlets near WAPs are not always available. Each router uses a midspan PoE+ injector to power its WAP.

Reachability

If RADIUS is proxied to the external portal server through the controller, then it must be reachable through any kind of firewall between it and the external portal server / radius solution. Same if RADIUS travels directly from the AP to the external portal solution.

The HTTP portal of the external portal solution must be reachable by the end users.