RADIUS Server for WiFi Marketing: Complete Technical Guide

Key Takeaways: RADIUS (Remote Authentication Dial-In User Service) is the protocol backbone that connects WiFi hardware to captive portal platforms. Every captive portal authentication, guest session, and analytics data point flows through RADIUS accounting. Understanding the RADIUS data pipeline separates resellers who can troubleshoot deployment issues from those who call support when a portal stops loading. MyWiFi Networks operates cloud-hosted RADIUS infrastructure that integrates with 20+ hardware vendors, eliminating the need for resellers to manage RADIUS servers directly. This guide explains what happens at the protocol level so you can deploy, debug, and sell with confidence.

RADIUS was designed in 1991 for dial-up modem authentication. Over three decades later, it remains the standard protocol behind virtually every commercial WiFi deployment — from a single-AP coffee shop to a 500-AP airport terminal. According to the Wireless Broadband Alliance's 2025 industry census, 94% of managed WiFi networks use RADIUS for authentication, authorization, and accounting (AAA).

For WiFi marketing, RADIUS is the invisible data layer. Every guest login, session duration measurement, bandwidth consumption record, and device identifier passes through RADIUS before it reaches your analytics dashboard. If you deploy captive portals for clients, you are running a RADIUS-dependent operation whether you manage the server yourself or not.

---

RADIUS fundamentals: AAA

RADIUS performs three functions, collectively known as AAA:

Authentication: "Who is this?"

When a guest connects to WiFi and encounters a captive portal, the access point sends a RADIUS Access-Request to the RADIUS server. This request contains the guest's credentials — which might be a username/password pair, a social login token, a MAC address, or an OTP verification result.

The RADIUS server validates the credentials against its database (or forwards validation to an external system like a captive portal platform). If valid, it returns an Access-Accept message. If not, Access-Reject.

Authorization: "What can they do?"

The Access-Accept message includes RADIUS attributes that define the guest's session parameters: bandwidth limits, session duration, VLAN assignment, and access control lists. These attributes are enforced by the access point for the duration of the session.

For WiFi marketing, authorization controls the guest experience. A free-tier guest might receive 2 Mbps down / 1 Mbps up with a 60-minute session. A paid-tier guest might receive unlimited bandwidth for 24 hours. These parameters are set in the RADIUS response.

Accounting: "What did they do?"

RADIUS accounting is where the marketing intelligence lives. Throughout the guest's session, the access point sends Accounting-Request messages to the RADIUS server at regular intervals (typically every 5 minutes). These messages contain:

• •Session start time (Acct-Status-Type: Start)
• •Interim updates (Acct-Status-Type: Interim-Update) with bytes transferred and session duration
• •Session end (Acct-Status-Type: Stop) with final session data

The accounting data stored in the radacct table is the foundation of every WiFi analytics metric.

---

The RADIUS data pipeline for WiFi marketing

Here is the complete data flow from guest connection to marketing action:

Guest Device → Access Point → RADIUS Server → Captive Portal Platform → Analytics/CRM
     |              |               |                    |                      |
  Connects     Redirects to    Validates auth      Stores profile +        Segments,
  to SSID      captive portal  credentials         session data            campaigns

Step 1: Association and redirection

The guest's device associates with the SSID. The access point detects an unauthenticated client and redirects all HTTP traffic to the captive portal URL. This redirection mechanism varies by hardware vendor — Cisco Meraki uses cloud-based redirection via the Meraki Dashboard, Ubiquiti UniFi uses the controller's guest portal feature, and generic implementations use HTTP 302 redirects.

Step 2: Portal authentication

The guest interacts with the captive portal (email form, social login, WhatsApp OTP, etc.). The portal platform processes the authentication and sends a RADIUS Access-Request to the RADIUS server with the guest's validated credentials. The server responds with Access-Accept plus session parameters.

Step 3: Session tracking

The access point begins sending RADIUS accounting records. The Start record marks the beginning of the session. Interim-Update records (every 300 seconds by default) report cumulative bytes in/out and session time. The Stop record is sent when the guest disconnects or the session times out.

Step 4: Data correlation

The captive portal platform correlates the RADIUS session data (MAC address, AP identifier, session duration) with the portal authentication data (email, name, social profile). This correlation transforms anonymous network session data into identified guest profiles with behavioral data.

Step 5: Analytics and automation

The correlated data feeds analytics dashboards (visit frequency, dwell time, peak hours, zone heatmaps) and marketing automation triggers (welcome email on first visit, re-engagement message after 14 days inactive, birthday offer).

---

Key RADIUS attributes for WiFi marketing

The radacct table stores dozens of RADIUS attributes per session. Eight carry the most marketing intelligence:

MAC address as guest identifier

The Calling-Station-Id (device MAC address) has historically been the primary guest identifier in WiFi analytics. However, MAC address randomization — now default on iOS 14+, Android 10+, and Windows 11 — assigns a random MAC per network. According to Apple's 2025 Platform Security Guide, 100% of iPhones running iOS 14 or later use private MAC addresses by default.

This is why captive portal authentication is essential for WiFi marketing. The authenticated identity (email, phone number, social profile) survives MAC randomization. MyWiFi correlates the randomized MAC with the authenticated profile, maintaining guest identity continuity across visits even when the MAC changes.

AP MAC as zone identifier

The Called-Station-Id identifies which access point served the session. In multi-AP venues, mapping AP MAC addresses to physical zones enables location analytics: which floor, which department, which entrance area the guest occupied. This data powers heatmap visualizations and zone-based marketing (e.g., "Guests who spent time in the shoe department receive shoe promotions").

---

RADIUS server deployment models

Self-hosted RADIUS (FreeRADIUS)

FreeRADIUS is the most widely deployed RADIUS server globally, running on approximately 70% of AAA deployments according to a 2024 NetworkWorld infrastructure survey. It is open-source, highly configurable, and runs on any Linux distribution.

Advantages for resellers:

• •Full control over configuration and data
• •No per-authentication costs
• •Extensive module ecosystem (SQL, LDAP, EAP, REST)
• •Battle-tested at scale (carriers run FreeRADIUS for millions of sessions)

Disadvantages for resellers:

• •Requires Linux administration expertise
• •Security patches and updates are your responsibility
• •High availability requires clustering (keepalived, Galera for MySQL backend)
• •Every hardware vendor integration must be configured manually

Cloud-hosted RADIUS (Platform-managed)

MyWiFi Networks operates cloud-hosted RADIUS infrastructure on AWS. When a reseller connects a client venue's hardware to MyWiFi, the platform automatically configures RADIUS authentication between the AP and MyWiFi's cloud RADIUS servers. No server management required.

Advantages for resellers:

• •Zero server administration
• •Automatic hardware integration via the 2-minute Device Integration Wizard
• •Managed high availability and scaling
• •20+ hardware vendor integrations pre-configured
• •Data correlation with captive portal profiles happens automatically

Disadvantages:

• •Less granular control over RADIUS policy than self-hosted
• •Dependent on platform uptime

Hybrid: Local RADIUS with cloud relay

Some enterprise deployments use a local RADIUS server for authentication (faster response, no WAN dependency) with accounting records replicated to a cloud platform for analytics. This model is common in environments with strict data residency requirements or unreliable WAN connectivity.

---

Integrating RADIUS with captive portal platforms

The integration between RADIUS and a captive portal platform follows a standard pattern across hardware vendors:

Cisco Meraki integration

Meraki uses a cloud-hosted captive portal model. The Meraki dashboard is configured with an External Splash Page URL pointing to the MyWiFi portal. Authentication uses the Meraki Cloud Authentication API — the AP communicates with Meraki Cloud, which communicates with the external RADIUS server.

Meraki's CMX (Connected Mobile Experiences) API adds presence analytics: probe request data from devices that are nearby but not connected to the network.

Ubiquiti UniFi integration

UniFi uses the controller's Guest Portal feature. The RADIUS server is configured in the UniFi controller under Settings → Profiles → RADIUS. The external captive portal URL is set under Settings → Guest Control. UniFi sends standard RADIUS authentication and accounting to MyWiFi's cloud RADIUS server.

Generic RADIUS integration

For hardware vendors without cloud controller APIs (Mikrotik, OpenWrt, some Ruckus models), integration uses standard RADIUS protocol: configure the AP or controller to point to the RADIUS server IP, shared secret, and ports (1812 for authentication, 1813 for accounting).

---

Troubleshooting RADIUS issues in WiFi marketing deployments

Portal not loading

If the captive portal is not displaying when a guest connects, the issue is usually in the redirection layer, not RADIUS:

1. •Check the AP's walled garden / allowed list. The captive portal domain and any CDN assets must be accessible before authentication. If the portal CSS, JavaScript, or images are blocked, the portal appears broken.
2. •Verify the external portal URL is correctly configured in the AP or controller.
3. •Check HTTPS redirect handling. Modern browsers default to HTTPS, and HTTPS pages cannot be intercepted for portal redirection. DNS-based redirection (captive.apple.com, connectivitycheck.gstatic.com) is the reliable mechanism.

Guest authenticates but does not get internet

This indicates RADIUS authentication succeeded (Access-Accept was sent) but the AP did not transition the client to an authorized state:

1. •Verify the shared secret between the AP and RADIUS server matches exactly (case-sensitive).
2. •Check RADIUS attributes in the Access-Accept. Some APs require specific vendor-specific attributes (VSAs) to complete the authorization flow.
3. •Check firewall rules. The AP must be able to reach the RADIUS server on ports 1812 (auth) and 1813 (accounting).

Analytics data missing or incomplete

If the portal works but analytics show no session data:

1. •Verify RADIUS accounting is enabled on the AP. Authentication and accounting are separate configurations — authentication can work while accounting is disabled.
2. •Check the accounting interim interval. If set too high (or disabled), session data only arrives when the guest disconnects.
3. •Verify the accounting port (1813) is open and the AP is configured to send to the correct server.

---

RADIUS security for WiFi marketing

RADIUS was designed before modern security standards. The protocol uses MD5-based authentication, which is cryptographically weak by 2026 standards. Mitigations:

Use strong shared secrets

The shared secret between the AP and RADIUS server is the primary authentication mechanism. Use minimum 16-character random strings. Never use default or weak secrets. According to NIST SP 800-153 (Guidelines for Securing WLANs), RADIUS shared secrets should be at least 22 characters using a full character set.

Encrypt RADIUS traffic

Standard RADIUS uses UDP without encryption. For deployments where RADIUS traffic traverses the internet (cloud-hosted RADIUS), use RadSec (RADIUS over TLS, RFC 6614) or a VPN tunnel between the AP and RADIUS server. MyWiFi's cloud RADIUS implementation uses encrypted transport.

Limit RADIUS server access

Restrict RADIUS server access to known AP IP addresses using firewall rules or the RADIUS client configuration. Never expose a RADIUS server to the open internet without IP-based access controls.

Transition to RADIUS/TLS

The IETF's RADIUSext working group has been developing RADIUS/TLS as a replacement for the legacy UDP transport. As of 2025, RFC 6614 (RadSec) is the most widely implemented secure transport, with support in FreeRADIUS 3.x+ and most enterprise RADIUS servers.

---

RADIUS and the future of WiFi marketing

Three developments are reshaping how RADIUS fits into WiFi marketing:

MAC randomization has made RADIUS accounting data alone insufficient for guest identification. Captive portal authentication is now essential — not optional — for building guest profiles. Resellers who previously relied on passive MAC tracking must transition to active authentication.

Wi-Fi 6E and Wi-Fi 7 introduce new frequency bands and capabilities but maintain RADIUS as the AAA standard. The IEEE 802.11ax/be standards are fully compatible with existing RADIUS infrastructure. According to the Wi-Fi Alliance's 2025 certification data, 100% of Wi-Fi 6E and Wi-Fi 7 certified devices support RADIUS-based authentication.

Cloud-native RADIUS is replacing on-premise servers for managed WiFi. Platforms like MyWiFi abstract the RADIUS layer entirely, allowing resellers to focus on portal design and marketing rather than network engineering. The RADIUS protocol still runs underneath, but the reseller never touches it directly.

For resellers, the practical implication is clear: understanding RADIUS helps you troubleshoot, sell, and deploy. But managing RADIUS infrastructure is not where you add value. Your value is in the marketing automation, analytics, and data capture strategy that runs on top of the RADIUS foundation.

---

FAQ

Do I need to manage a RADIUS server to use MyWiFi? No. MyWiFi operates cloud-hosted RADIUS infrastructure. When you connect a client's hardware through the Device Integration Wizard, RADIUS is configured automatically. You never touch the RADIUS server directly.

What is the difference between RADIUS authentication and RADIUS accounting? Authentication validates the guest's identity and grants network access. Accounting tracks the guest's session data (duration, bandwidth, AP identity) throughout the connection. Both use the RADIUS protocol but serve different functions and run on different ports (1812 and 1813).

Does MAC address randomization break RADIUS analytics? It breaks passive MAC-based tracking. RADIUS accounting still records the session data, but the MAC address changes per network connection on modern devices. Captive portal authentication provides the persistent identity that survives MAC randomization.

Can I use an existing RADIUS server with MyWiFi? Enterprise and MSP plan customers can configure hybrid RADIUS setups where local authentication is paired with MyWiFi's cloud accounting and portal platform. Contact support for architecture guidance on hybrid deployments.

What happens if the RADIUS server is unreachable? Most access points can be configured with a fallback behavior: deny all (secure but blocks guests), allow all (permissive but loses data capture), or use a locally cached authentication policy. MyWiFi's cloud RADIUS runs on redundant AWS infrastructure with 99.9%+ uptime.

Is RADIUS being replaced by newer protocols? Not in the near term. The IETF is developing RADIUS/TLS for improved security, and protocols like Diameter (RADIUS successor for carrier networks) exist, but RADIUS remains the universal standard for WiFi AAA. Every access point manufactured today supports RADIUS.