Enterprise Secured RADIUS for Large Projects

This is something ISN does on request. It is not a standard feature that every account has, and you do not switch it on yourself. Ask us, and we plan, host, secure and commission it for your project.

A secured RADIUS service is a central login-checking server that we host and operate for you. Your gateway, firewall or wireless controller asks it, for every guest, "may this person be online, and for how long?", and it answers using the same guest, voucher, data-plan and access rules your captive portal already uses. Because we run the server, you never have to build, patch or defend a RADIUS server yourself.

How you get it. You ask us, and it is arranged per project together with us. It is not a switch in the dashboard. We start with a design conversation about your network, agree the security and the testing, prove it on your real equipment in a pilot, and only then go live. The result is a RADIUS service dedicated to your project, separate from every other customer.

Who it is for. This is our enterprise offering, for organisations and projects where a central gateway or controller (often a high-availability pair) sits in front of many access points or sites, where the ISP or owner wants one place to enforce time, speed and usage, or where the buyer's IT or security rules say "central RADIUS with accounting". Enterprise projects also get a named technical contact, a written design, a pilot on your equipment and an agreed support and incident process. If you have one venue, a handful of routers or a small business, you almost certainly do not need this, and panel 4 explains what you use instead.

Not the same as the RADIUS option on the Routers page. Under Network, Routers, Advanced you can already point a router at a RADIUS server you run (see RADIUS authentication). That is a pass-through to your own server. This guide is about the server we host.

Think of your gateway as a doorman. The doorman does not decide who comes in; he phones a manager (the RADIUS server) and asks. Four things happen on that phone line:

Why a large project benefits. With dozens or hundreds of access points behind one gateway, there is no router per site for our agent to manage. The gateway is the one place that can let people in, so it must ask a server. A central RADIUS then gives you one set of rules for every access point, standard timers that the gateway enforces by itself, usage accounting for the whole estate, a clean audit trail for the owner, and one single connection point to secure instead of hundreds.

Why a small site should not use it. RADIUS is powerful but it adds moving parts: a server that must always be reachable, a secret to protect, firewall rules on both ends, a network path that must stay stable, and a person who understands all of it. Every extra moving part is one more thing that can fail or be attacked. A small site gets the same guest experience with far fewer parts (panel 4), so adding RADIUS there would make it less reliable and less secure, not more.

• The on-router agent. One command pasted on an OpenWRT-based router (Teltonika, GL.iNet and similar) or a MikroTik, plus the External Login URL, and the platform opens and closes access for each guest. See Routers and Network.
• Cloud-managed access points. Cisco Meraki and TP-Link Omada are connected through their own cloud APIs, with no RADIUS server involved.
• RADIUS pass-through, only if you already have a server. If your IT team runs its own RADIUS (often tied to Active Directory), you can point a router at it under Network, Routers, Advanced. We do not host that one. Details in RADIUS authentication.
• Everything else the platform does (vouchers, data plans, ads, surveys, internal accounts, Single Sign-On, fair usage, content filtering) works the same on a small site as on a large one.

1. The guest joins the WiFi. Before login, the gateway only lets them reach the captive portal and the few services you allow (the walled garden).
2. The guest is sent to your branded captive portal and does what your rules ask: a phone code, a voucher, a payment, an ad or a survey.
3. Only after the portal has proved that, the platform creates a single-use, short-lived login for that guest. It is not a reusable account.
4. The gateway sends it to the RADIUS service over the secured path. The service checks it against the same access rules as the portal and answers Accept with the session rules, or Reject with a reason.
5. While the session runs, the gateway sends accounting updates. The service keeps the usage, and when a quota is used up, a time limit is reached or an abuse rule fires, it sends a Disconnect.
6. If the guest buys more time or data mid-session, the service sends a CoA so the live session is extended without reconnecting.

Plain RADIUS is an old protocol with known weaknesses: it runs over UDP, protects passwords only with the shared secret, and in its basic form does not encrypt the rest of the packet. We do not rely on the protocol alone. We wrap it in layers so that no single mistake exposes you.

Our rule: plain RADIUS never crosses a network we do not control. The researchers who found the 2024 Blast-RADIUS flaw state that sending RADIUS over UDP across the internet is explicitly discouraged, and that even a private network or VLAN only reduces the risk, because one compromised device or misconfiguration on it is enough. So for an enterprise project we do not rely on "it is a private network". We use an encrypted, authenticated channel and the controls inside it. You can think of it as a locked armoured van (the tunnel) carrying a sealed, signed envelope (the RADIUS packet) that only one named person (the allow-listed gateway) may hand over.

Best practice for an enterprise project is two layers together: RadSec or a VPN for the channel, plus the packet-level protections of panel 7 inside it. If one layer is misconfigured or broken, the others still hold.

The IP rules, spelled out.

• Default deny. The hosting firewall and the host's own firewall both start by dropping everything. Only your registered gateway addresses (single hosts, or the inner addresses of the tunnel), only on the RADIUS ports, are let through. Two independent firewalls mean one mistake does not open the door.
• Return path for Disconnect and CoA. Our server may send these to your gateway only, on the port your vendor uses (commonly UDP 3799). Your gateway must accept them only from our server's addresses and drop them from everyone else. A gateway that accepts a Disconnect from anywhere would let a stranger kick your guests off.
• No public management. The RADIUS hosts' administration ports are never open to the internet. Administrators reach them only through a separate management VPN with multi-factor sign-in, and the NSA's out-of-band management guidance is the model: management traffic is kept apart from operational traffic.
• Anti-spoofing. We ask that your edge also drops packets that claim to come from addresses that cannot be behind that interface (source-address validation, BCP 38), and we do the same on ours. This stops an attacker pretending to be your gateway from somewhere else.
• IPv6 treated the same. Either allow-listed with the same strictness or switched off for this service. There is no forgotten second door.
• Fixed addresses. A gateway behind carrier-grade NAT or with a changing address cannot be allow-listed reliably, so we ask for fixed addresses or a tunnel with fixed inner addresses.
• Flood limits. Per-source rate limits and connection limits, plus provider-level protection against large floods and a standby server (panel 7).
• Outbound lock. The RADIUS hosts may only call out to what they strictly need (updates, our own back end, log storage). A compromised host therefore cannot freely contact an attacker.

This is the standard we hold the hosted service to. A server that is easy to break defeats every network control in front of it, so we treat the host as carefully as the path.

• Dedicated and minimal. The RADIUS service runs on its own hosts, never on the same machine as the website or dashboard, with only the software it needs. Nothing else is installed, so there is less to attack.
• Least privilege. The service runs as an unprivileged user in a confined container or virtual machine, with a read-only file system where possible and system confinement profiles (AppArmor or SELinux, and syscall filtering) switched on.
• Packet checks on. A valid Message-Authenticator is required from every client, and proxied-state attributes are not accepted without one. This is the vendor-recommended fix for Blast-RADIUS and is set to "yes", never left on automatic.
• Strong secrets, handled safely. At least 32 random characters, a different one for every gateway and every customer, rotated at least yearly (anything under 20 characters or older than two years is treated as already compromised). Secrets live in an encrypted vault, are never in source code, chat or email, and are shown once at hand-over.
• Patching. Operating system, RADIUS software and libraries are updated on a schedule, and urgent security fixes are applied outside it. Our code dependencies are scanned for known vulnerabilities every week.
• Encrypted at rest. Disks and backups are encrypted, backups are tested by restoring them, and an offline copy is kept.
• Admin access. Key-based sign-in only (no passwords), multi-factor on top, named individual accounts (no shared logins), every session logged, and access removed the same day someone leaves.
• Trustworthy time. Authenticated time sources, because certificates, session timers and log evidence all depend on the clock.
• Tamper-resistant logs. Logs are copied off the host to separate storage that the RADIUS host cannot alter, so an intruder cannot quietly erase their tracks.
• Watching. Alerts on repeated failures, requests from unknown addresses, certificate or tunnel problems, odd traffic volumes and any change to the allow-list.
• Testing. Regular vulnerability scans, and an independent penetration test of the hosted service can be arranged for your project if your rules require one.
• Incident plan. A written plan for a suspected breach: contain, rotate every secret and certificate, tell you within the time in your service agreement, and give you the evidence.

Security is about stacking obstacles, so that beating one is not enough. To forge a login answer or kick guests off, an attacker would have to defeat every row below at the same time.

No system is unhackable and we will not tell you that it is. The goal is layers, so one failure is not a breach, plus logging so we notice and react quickly. We do not claim an ISO 27001 or SOC 2 certification; if your tender requires one, tell us at the start so we can be honest about it together.

• Run, patch and monitor the RADIUS servers, and alert on failures and unusual traffic.
• Keep backups of the configuration and restore it if a server is lost.
• Generate, store, hand over and rotate the shared secrets.
• Keep the allow-list of your registered gateway addresses and change it only on your written request.
• Keep the logs, and give you reports for your own users and sessions.
• Investigate incidents and tell you within the time set in your service agreement.
• Agree maintenance windows with you in advance so a restart never surprises you.
• Tell you plainly where the hosting is located. If your rules require data to stay in a particular country, say so at the start.

Most problems on RADIUS projects come from the network around the server, not from the server itself. This is the list we work through together before go-live.

Our service can be perfectly secure and the project still fail if the sites themselves are open. These are the basics we ask every deployer to put in place. They are good practice for any public WiFi, not only RADIUS.

• Separate networks. Guests, staff and device management each get their own VLAN. Guests must never be able to reach the management side of the gateway, controller, switches or access points.
• Client isolation. Guests cannot talk to each other. This stops one guest attacking or scanning another and removes most local session-hijack tricks.
• Lock the equipment. Change every default password, give each engineer their own login, turn on multi-factor sign-in where the device offers it, switch off telnet, plain HTTP management and any service you do not use, and restrict management to a small trusted address range.
• Keep firmware current. Patch the gateway, controller and access points on a regular schedule and subscribe to the vendor's security notices.
• Protect the switch and DHCP layer. Use DHCP snooping and dynamic ARP inspection (or your vendor's equivalent), and block rogue DHCP servers, so a guest cannot impersonate the router.
• Wireless hardening. Enable protected management frames (802.11w) where the clients support it, switch off WPS, and turn on rogue access-point detection if your controller has it.
• Per-guest limits. Cap each guest's speed and connection count so one device cannot flood the link or the gateway.
• Log and watch. Send gateway and controller logs to a central log server, keep them for the period your rules require, and look at them.
• Back up configurations and keep an offline copy so a failed gateway can be rebuilt fast.
• Physical security. Controllers, switches and gateways sit in locked cabinets. Outdoor access points are mounted out of casual reach.
• Name and train your administrators, and remove leavers on the day they leave.
• Plan for the worst day. Keep a written plan for a gateway failure, a link failure and a suspected breach, with who to call. Include us.

1. Discovery. We learn your topology, equipment, numbers and rules, and walk through this guide with you.
2. Design. We write down the secured path, the addresses, the ports, the session rules per package, the interim interval, the redundancy and the log retention, and you approve it.
3. Pilot on your equipment. We connect to a test gateway and prove each rule, with the acceptance tests below.
4. Go-live. We switch on for real guests in an agreed window, with both teams watching.
5. Hand-over and support. You get the reports, the contacts and the incident process, and we review the numbers after the first weeks.

Acceptance tests we run before go-live:

• Vendors differ. Speed attributes, CoA support and portal behaviour vary by make and firmware. We confirm each rule on your real device in the pilot and tell you if something cannot be done.
• Volume limits are counted, not built in. Because gateways have no standard data-quota attribute, we count accounting updates and disconnect. The cut-off is as accurate as the interim interval you choose, not to the exact byte.
• It needs a stable network path. If the gateway cannot reach our server, new guests cannot log in. That is why we plan a standby server and agree what existing sessions do during a failure.
• RADIUS does not replace the portal or HTTPS. It is the gateway's way of asking permission. Guests are still verified on the portal, which must stay on HTTPS.
• Your own security still matters. An open management interface or a default password on your gateway undoes everything above. Panel 11 is part of the deal.
• It is not for every project. If panel 3 says you are small, you will be better served by the simpler options in panel 4.

Do I have to run the RADIUS server? No. ISN hosts and runs it for your project, on request.

Can a small business switch it on? It is not offered as a dashboard switch and we do not recommend it for small sites. See panels 3 and 4.

Does it cost extra? It is arranged and quoted per project, so ask us. The standard platform plans are on the pricing page.

Can I use my own RADIUS server instead? Yes, through the pass-through option described in RADIUS authentication. You are then responsible for securing and running it.

Where do I start? Ask us for it. Email info@isnfreewifi.co.za with your equipment list, the number of sites and access points, your expected peak users, and any security or privacy rules your project must follow.

These are the public references we based the security design on. Your own security team is welcome to check each one.

• Blast-RADIUS (CVE-2024-3596): the 2024 forgery attack on RADIUS, with the mitigations we apply (Message-Authenticator on everything, and moving RADIUS into an encrypted channel).
• Jisc advisory on enforcing Message-Authenticator: practical guidance for operators.
• FreeRADIUS client configuration reference: the require_message_authenticator and related settings.
• IETF RadSec: RADIUS over TLS and DTLS: the standard that replaces the experimental RFC 6614 and RFC 7360, with mutual authentication and the TLS recommendations of RFC 9325.
• RFC 9765, RADIUS/1.1: removes MD5 and the shared secret from RADIUS when used over TLS.
• Fortinet: RADSEC client support and Fortinet: RADIUS CoA behaviour: for a FortiGate, a Disconnect must carry both the user name and the client's IP address or it is refused, and accounting interim updates are configured on the gateway.
• WireGuard: the formal security analysis: the cryptographic design and its forward-secrecy properties.
• NSA and CISA: out-of-band network management: keeping management traffic apart from operational traffic.

Standards change. The cryptographic settings in panel 7A are our current recommendation and are reviewed whenever a vendor or standards body changes its advice.