Using Nexthink Data to Identify Suspicious or Underperforming Wi-Fi Access Points
Based on my previous post, I would like to share another example of how Nexthink data can be used creatively across different teams.
This time, the question is:
How can we use Nexthink to identify potentially underperforming or suspicious Wi-Fi access points?
At first glance, this may seem difficult. After all, Nexthink primarily shows us which SSID an endpoint is connected to.
However, in addition to the SSID, Nexthink also records the associated BSSID. This information allows us to associate a client connection with a specific wireless network interface.
What Is a BSSID?
BSSID stands for Basic Service Set Identifier. In simple terms, it is the unique MAC address of a specific wireless network interface.
For example, multiple access points can broadcast the same SSID:
SSID: Company-WiFi
Despite using the same SSID, each individual wireless network has its own BSSID.
In centrally managed Wi-Fi systems such as FortiAP, ExtremeCloud IQ, or UniFi, a separate BSSID is often created for each combination of the following components:
- Access point
- Wireless module or radio
- Frequency band
- SSID
- Virtual wireless interface
A single access point can therefore have multiple BSSIDs at the same time, for example one for the 2.4 GHz band and another for the 5 GHz band. If the access point broadcasts multiple SSIDs, the number of BSSIDs increases accordingly.
Does a BSSID Change Regularly?
Under normal operating conditions, a BSSID usually remains stable (Thanks Lord!).
Simply restarting the access point or wireless controller does not normally change it.
However, a BSSID may change when:
- An access point or radio module is replaced
- An SSID is deleted and recreated
- The assignment between the SSID, radio, and virtual wireless interface changes
- A firmware or configuration change modifies virtual MAC address allocation
- A mesh repeater or another access point takes over the connection
- The vendor-specific method for calculating or assigning BSSIDs changes
In many environments, the BSSID is therefore a useful technical key for correlating Nexthink connection data with information from the wireless infrastructure.
An Example from the Fortinet Ecosystem
The environment used in this example is based on Fortinet access points. The FortiAPs are centrally managed by a FortiGate, which acts as the wireless controller.
Fortinet provides its own solution for analyzing and monitoring Wi-Fi environments through FortiAIOps. Among other things, it can help identify problematic access points, affected clients, and possible causes of poor wireless experiences.
Depending on the size of the environment and the existing licensing model, however, such an additional solution can involve considerable costs - and it's always good to have an argument for saving budget.
An alternative approach is to intelligently combine data sources that are already available.
Retrieving BSSIDs from the FortiGate
An overview of the virtual access point interfaces managed by the FortiGate and their corresponding BSSIDs can be retrieved using the following diagnostic command:
diagnose wireless-controller wlac -c vap
Depending on the FortiOS version and configuration, the output contains information that can be used to associate BSSIDs with the corresponding FortiAPs, radios, and SSIDs.
A useful tip at this point: FortiGate Automation Stitches can execute specific actions according to a schedule. This makes it possible to run the diagnostic command at a defined interval and send the generated output by email to a dedicated mailbox or functional email address.
This approach should be coordinated with the responsible firewall administrators, particularly regarding the execution schedule, administrative permissions, generated output, and the recipients of the email.
For automated processing, the output can then be converted into a structured format and exported as a CSV file, for example.
Identifying Suspicious Wi-Fi Connections with Nexthink
On the Nexthink side, we can now analyze endpoint connection events and aggregate them by BSSID and SSID.
The following example examines Wi-Fi connections from the past seven days for which Nexthink rated the average signal strength as poor:
connectivity.events during past 7d
| where primary_physical_adapter.type == wifi
| where wifi.signal_strength.avg.rating in [poor]
| summarize
signal_strength_in_dBm = wifi.signal_strength.avg(),
devices_ = device.count()
by wifi.bssid, wifi.ssid
| where signal_strength_in_dBm != null
| where devices_ > 1
| sort signal_strength_in_dBm asc
| sort devices_ desc
Among other things, the aggregation shows us:
- Which BSSIDs are affected by poor signal ratings
- Which SSID was broadcast through the respective BSSID
- The average measured signal strength
- The number of affected endpoints
The devices_ > 1 condition helps reduce individual outliers. Instead of looking at a single client, we focus on BSSIDs for which multiple devices have reported poor signal strength.
The query can also be restricted to specific SSIDs, locations, device types, organizational units, or time periods.
Connecting Nexthink and FortiGate Data
We can now combine both data sources:
- The FortiGate provides the mapping between the BSSID and the access point.
- Nexthink provides the connection quality measured on the endpoints.
- The BSSID acts as the common key.
The result is a list of specific wireless networks or access points that show unusual behavior within the analyzed environment.
Depending on the information available from the FortiGate, the analysis can be enriched with details such as:
- Access point name
- Management IP address
- Serial number
- Location
- Wireless module
- Frequency band
- Broadcast SSID
- Number of affected endpoints
- Average signal strength
This list can then be handed over to the infrastructure or network team for further analysis.
What Can We Learn from the Results?
Poor signal strength does not automatically mean that an access point is defective.
Possible causes include:
- Insufficient Wi-Fi coverage
- Poor access point placement
- Structural obstacles
- Transmit power that is too low or too high
- Incorrect channel planning
- Heavy interference
- Overloaded wireless cells
- Outdated client drivers
- Inefficient roaming behavior
- Clients remaining connected to a distant access point for too long
The results should therefore be treated as a starting point for a more detailed investigation.
The major advantage is that the analysis is not limited to the perspective of the wireless controller. Nexthink also provides the perspective of the actual endpoints and therefore shows how the Wi-Fi connection is experienced by the user.
Did the Implemented Changes Work?
This approach can also help answer that question.
After the network team has moved an access point, adjusted the channel plan, or changed the transmit power, the same Nexthink query can be executed again.
This makes it possible to verify:
- Whether the average signal strength has improved
- Whether fewer devices are affected
- Whether the issue has shifted to other BSSIDs
- Whether the change has actually improved the user experience
A one-time analysis therefore becomes a simple before-and-after comparison.
Using the Data from a Security Perspective
The combination of Nexthink and infrastructure data can also be valuable for security teams.
If Nexthink detects a BSSID broadcasting an internal SSID that cannot be associated with a managed access point, the situation should be investigated further.
Possible explanations include:
- An undocumented access point
- A misconfigured device
- A privately installed or unauthorized access point
- A Wi-Fi repeater
- An outdated BSSID remaining after a hardware replacement
- An evil twin or rogue access point
It is important to remember that an unknown BSSID is initially only an anomaly and not proof of an attack. However, it provides a concrete starting point for further investigation.
Conclusion
Nexthink data does not have to be used exclusively within Workplace or Digital Employee Experience teams.
By correlating the BSSID recorded by Nexthink with information from the wireless infrastructure, organizations can create a shared data foundation for:
- Workplace teams
- Network and infrastructure teams
- Service desk teams
- Security teams
Using data that is already available, organizations can determine which wireless cells appear problematic from the endpoint perspective, which users are affected, and whether technical changes actually result in measurable improvements.
What other use cases can you think of where Nexthink data could be meaningfully combined with infrastructure information?