Why manage NAT'd APs from your rXg

Many deployments have access points sitting behind gateways that perform NAT, so the rXg cannot reach them directly. Managing those APs from the rXg keeps a single source of truth for WLANs, per-site profiles, and certificates, on the rXg, and integrated with all of its other functionalities. Because the APs initiate an outbound WSS connection to the rXg, no inbound port forwarding or VPN is required at the remote site. The rXg also acts as the EST server, so each AP is enrolled with a certificate from your own Certificate Authority and only trusted devices join the fleet. The result is centralized RADIUS, captive portal, and policy enforcement for sites you do not own the routing for.

Reference

For the most up to date information about the OpenWiFi-WSS integration, please see: The RG Nets' OpenWiFi Manual

Topologies

Two deployment models are supported. In both, the APs initiate every connection: the WSS control channel and EST enrollment are outbound from the AP toward the rXg, so the NAT gateways at each site need no inbound rules.

Management over the Internet (rXg has a public IP)

The rXg WAN holds a globally routable address. Each site's gateway NATs the APs' private addresses to the site's public address, and management traffic crosses the public Internet to the rXg.

 Site A (192.168.1.0/24)              Site B (10.20.0.0/24)
 +-------+  +-------+                 +-------+  +-------+
 |  AP   |  |  AP   |                 |  AP   |  |  AP   |
 +---+---+  +---+---+                 +---+---+  +---+---+
     |          |                         |          |
   +-+----------+-+                     +-+----------+-+
   | NAT gateway  |                     | NAT gateway  |
   | (DHCP opt224)|                     | (DHCP opt224)|
   +------+-------+                     +------+-------+
          | public IP                          | public IP
          |                                    |
          |    WSS (tcp/443) + EST, outbound   |
          v                                    v
      +--------------------------------------------+
      |                  Internet                  |
      +---------------------+----------------------+
                            |
                            v  public IP, e.g. 203.0.113.10
                     +--------------+
                     |     rXg      |
                     |  WSS Ctrl +  |
                     |  EST Server  |
                     +--------------+

Management inside a private cloud (rXg has an RFC 6598 IP)

Management traffic never touches the Internet. The rXg WAN sits in the carrier-grade NAT range 100.64.0.0/10, and each site reaches it across the operator's private transport such as MPLS, a metro fiber ring, or a wireless backhaul. Site gateways NAT the APs to an address in the same 100.64.0.0/10 space, so the rXg WAN Targets cover the private transport rather than the Internet.

 Site A (192.168.1.0/24)              Site B (10.20.0.0/24)
 +-------+  +-------+                 +-------+  +-------+
 |  AP   |  |  AP   |                 |  AP   |  |  AP   |
 +---+---+  +---+---+                 +---+---+  +---+---+
     |          |                         |          |
   +-+----------+-+                     +-+----------+-+
   | NAT gateway  |                     | NAT gateway  |
   | (DHCP opt224)|                     | (DHCP opt224)|
   +------+-------+                     +------+-------+
          | 100.64.10.1                         | 100.64.20.1
          |                                    |
          |    WSS (tcp/443) + EST, outbound   |
          v                                    v
      +--------------------------------------------+
      |   Operator private transport               |
      |   (MPLS / metro fiber / wireless backhaul)  |
      |   100.64.0.0/10  -  no Internet path        |
      +---------------------+----------------------+
                            |
                            v  RFC 6598 IP, e.g. 100.64.0.10
                     +--------------+
                     |     rXg      |
                     |  WSS Ctrl +  |
                     |  EST Server  |
                     +--------------+

Setup

1. Deploy rXg. A globally routable, non-RFC 1918 IP on the WAN of this rXg is required if management traffic is expected to traverse the internet. If management traffic is not expected to traverse the internet, a CG NAT Safe Space IP (100.64.0.0/10 RFC6598) can be used.
2. Standard rXg setup. License your rXg. Register its DNS domain. Configure your Admins. Acquire your Certificate. Configure ACL(s).
3. Apply Template 7. ONLY necessary modifications are to your Certificate Authority
4. Enable appropriate WAN Target(s) for your WSS WLAN Controller & EST Server (Services -> Servers). The WAN Targets MUST encapsulate those gateways that you expect to have serve your NAT'ed OpenWiFi APs. The rXg sees each AP as the address its site gateway NATs it to, so the WAN Targets must cover the gateways' outside addresses, whichever topology you chose above:
   • In the Internet topology, the WAN Target(s) cover the gateways' public IPs (the two public IP links in the first diagram).
   • In the private cloud topology, the WAN Target(s) cover the gateways' RFC 6598 IPs (100.64.10.1 and 100.64.20.1 in the second diagram).
   • Either way, the WAN Target(s) are built from the gateways' addresses.
5. Setup Per-Site Profiles and WLANs.
6. The rXg managing the devices via WSS MUST NOT be reverse-proxied behind a vHOST, eg it MUST NOT be proxied behind an rXg's HTTPS vHOST.

Onboarding APs

Firmware

1. Each AP must be on RG Nets' firmware. There is an OpenWiFi Firmware Menu in the Device Firmware scaffold of the rXg. In there, you can choose firmware version, device, and click on acquire.
2. 4.2.4-0.011 is the current stable release, recommended for all supported models, though a later release may be available later on.
3. A standard OpenWrt sysupgrade is all that is necessary. You can get the URL for the firmware by right clicking the file column of the scaffold in the rXg, and choosing 'Copy Link'. Then you can use that link to upgrade the firmware of your AP, eg sysupgrade <Copied URL>.

rXg Discovery

1. The local DHCP service for the APs is required to serve in option 224 in DHCP

A note on SDAN

GRE/VXLAN encapsulation may be used to offload client traffic centrally via the rXg's uplinks, or traffic can be locally offloaded. Either way, RG Nets' internally developed SDAN kernel module is used to handle client dataplanes on the APs.