The RADIUS agreement has been in use for years at the Wi-Fi certification scene and is very mature, but in actual projects, takeWiFi web certification systemThe interface with RADIUS services is still not very frequent. Most of the problems are not about the RADIUS protocol itself, but about configuration details, network environments, equipment compatibility. These issues are easy to solve, but it will be time-consuming to check if you are not familiar with common setup.
RADIUS 's location in the authentication process
In a typical deployment structure, wireless access devices (AP or AC) act as RADIUS clients.WiFi web certification systemThe server will be used as a RADIUS server. After the user has been connected to Wi-Fi, AP will encrypt the authentication request into a RADIUS Access-Request message to the authentication server, which will return access-Access or Access-Reject to allow users to network on the basis of the returns.
The process looks simple, but each link may have a problem. AC/AP RADIFUS configuration, share copy, interface address, port number, time-over retry parameters, any error will lead to a failure of authentication and the failure is similar."Authentication is not approved"or"Authentication timeout"。
Shared Secret Configuration Error
Shared Secret is a shared key between the RADIAS client and the server to verify the signature of the message. The configuration error is one of the most common problems, and the phenomenon is not intuitive enough——On the AP side, a request for authentication was sent but no response was received; on the server side, a submission was received but the check failed and it was thrown away without any error information.
Check method: Open debugging logs on RADIUS server to see if there are any"Received invalid authenticator", or a similar log. If yes, confirm that the share set on the AP side is identical to the configuration on the server side, with care to be case-sensitive and whether there are spaces or non-visible characters mixed (which can easily appear when pasting from some management interfaces).
The RADIUS service port problem
The RADIUS standard ports are 1812 (certification) and 1813 (counting). But some old or customized devices use 1645/1646, and some service providers allow for the configuration of non-standard ports. If the AP configured port and the server listener port do not agree, the authentication request is called out but no one answers it, and the certification fails after timeout.
Confirm method: Execute netstat or ss command on the server to view ports that would actually be monitored by RADIUS services; confirm configured RADIFUS server IP and port at the AP management interface; confirm with tcpdump or grab tool that a message sent by AP has reached the correct port of the server.
Interception of the network firewall
RADIUS servers are usually in the Intranet, but authentication requests may have crossed firewalls or security strategy boundaries. The failure to release UDP traffic at RADIUS ports is a common problem, especially with certified servers deployed on cloud ends, and UDP 1812/1813 is easily overlooked in safety group rules.
The entire link from AP to RADIAUS server is checked against firewall rules, including the exit rule for the AP section, the access rule for the RADIAS segment and ACL for any intermediate network device."Connection"Status cleared. The next request for certification needs to be re-established, which may result in the first request being timed out.
NAS-IP-Address and client white list
The RADIUS server usually maintains a client white list (NAS list), which only responds to requests from IPs in the white list. If AP IPs are not on this white list, the server simply drops the request and does not return any errors, which is just as bad as the port.
This problem is more likely to arise when multiAP deployments occur: new AP or AC, IP changes in the project, but the RADIUS server's client white list has not been updated, which makes some equipment uncertified. Maintaining a clear RADIUS client IP list and synchronizing it with network equipment changes is an effective means of avoiding such problems.
Properties mismatch and Vendor Extension Properties
The RADIAS agreement defines standard attributes (Attributes), but the manufacturers also have their own extension properties (Vendor-Specific Attributes, VSA).WiFi web certification systemAdditional information (e.g. bandwidth restrictions, VLAN ID, Internet access limitations) is usually needed to be transmitted through RADIUS and used in VSAs.
The problem is that the VSA, as defined by AP Vendor A, may be another attribute ID on AP Vendor B’s equipment, or even unsupported. If a certification system sends VSA, which it does not know, AP will simply ignore it and will not misstate it, but neither the expected bandwidth limits nor the distribution of VLAN will work. Such problems are difficult to detect through simple tests, requiring specific validation of the actual effects of each function point.
Method of checking: Open a full report log on the authentication server to see what properties and VSAs are contained in Access-Accept; confirm that AP can recognize and process these properties against the AAP manufacturer ' s documents; verify whether bandwidth limits, VLAN distribution etc. are actually effective in a test environment.
Configuration of the RADIUS billing (Accounding)
The billing is another major feature of RADIUS, besides authentication. AP sends billing messages to the RADIUS server after the user has been online, after it has been downlined, and regularly (Interim Update), which uses them to record users’ time and traffic on the Internet.
Common problems in billing: A misallocation or non-configuration of the P billing server address resulted in only a failure to record the certification records, poor Internet time and traffic statistics; an unreasonable setting of interim Update intervals that would lead to user flippage but billing records were shown online and costing data and actual discrepancies; and a confusion between billing ports and authentication ports that sent requests for certification to the billing port, or vice versa.
And then you can get a performance problem from the certification scene.
Large sites can be identified during peak periods (open/dismissal/entry peaks in the morning). If RADIUS servers are not equipped to handle them, there will be delays or even time-over. AP RADIUS overtime retransmission mechanisms will repeat requests after they have passed hours and a large number of re-emergers will further burden the servers and create a vicious circle.
When checking and issuing performance, concern is given to the CPU and memory usage of RADIFAS servers, delays in database queries (account validation usually requires a database) and authentication timeouts on the AP side. If a delay in authentication due to slow database queries is found, priority is given to checking whether the database index is complete (username, mobile phone number field must be indexed), and whether the connection pool configuration is reasonable.
RADIUS interfaces are mostly easy to solve, but require systematic line-up. Most problems can be identified in a relatively short time from IP connectivity, port connectivity, Sharad Secret, client-end white lists and attribute configuration, which is sequentially listed. In complex situations, the catch pack is the most direct diagnostic tool, relying on vague misinformation displayed on the device interface.