Remote Access Appliances at Scale: 2,163,654 OpenVPN, 1,225,643 Ivanti Connect Secure and 445,720 pfSense Fingerprints

Remote access infrastructure exists to accept connections from untrusted networks. That is its purpose, and it is why this class of device behaves differently from almost every other asset in an inventory: reachability is not a misconfiguration, it is the design.

The exposure question therefore changes. It is not whether the device is reachable. It is whether the reachable surface is limited to the authenticated entry point, or whether it extends to the management interface, the administrative API and the version banner.

The measurements

Queries executed 20 September 2026 against the ZoomEye AI cyberspace search service, sub_type=all:

Query	Count
app="OpenVPN"	2,163,654
app="Ivanti Connect Secure"	1,225,643
app="pfSense"	445,720
app="SonicWall"	2,508,736
app="WatchGuard"	31,255
app="Sophos XG Firewall"	1,604

All queries returned successfully. Each count describes assets matching a product fingerprint on a reachable address.

Why the counts are large by design

OpenVPN at 2,163,654 is the clearest case. An OpenVPN endpoint is meant to be reachable by clients that are not on the internal network. A large count is expected and is not by itself a finding.

The same logic applies, with more nuance, to the others. A pfSense deployment at 445,720 is typically a firewall and VPN concentrator whose WAN interface is reachable by definition. A SonicWall appliance at 2,508,736 serves the same role.

The narrow counts are equally informative. app="Sophos XG Firewall" returning 1,604 and app="WatchGuard" returning 31,255 suggest specific fingerprints that resolve for a subset of those vendors' deployments, not that the vendors have small customer bases.

Where the actual risk sits

The risk in this class is not the reachable VPN endpoint. It is everything reachable alongside it.

The management interface. An administrative console on the same address as the VPN endpoint is a second surface, and it frequently has a weaker authentication story than the VPN itself.

The version banner. A reachable service that announces its version tells an attacker which advisories apply before any exploitation attempt. This is a fingerprinting aid, not a vulnerability, but it changes the cost of targeting.

Pre-authentication parsing surfaces. Certificate handling, SAML assertion processing and session establishment occur before authentication completes. Flaws in those paths are reachable by an unauthenticated caller by definition.

The trust the device holds. A VPN concentrator holds certificates, keys and often directory credentials. Its compromise is a position inside the trust boundary, not outside it.

Reading a large count correctly

A count of 2,163,654 OpenVPN endpoints is not a count of vulnerable VPNs. It is a count of reachable endpoints running a product that is designed to be reachable.

What it supports is a scoping argument with a specific shape: because this class of device is reachable by design, the population of devices that could be affected by a flaw in it is approximately the population of devices deployed. There is no segmentation to reduce the number.

That is different from an exposed database, where the correct remediation is to remove the exposure. For a VPN endpoint, the exposure is the service.

What to inventory

Enumerate the remote access estate. Vendor, model, firmware version, the address the service answers on, and the address the management interface answers on. These are frequently different and should be recorded separately.

Confirm the management plane is not on the public path. This is the control that most often fails.

Confirm the version is current. For a device that must be reachable, the patch is the primary control.

Confirm the authentication configuration. Certificate-only, MFA-enforced and password-only deployments are the same fingerprint and different risk profiles.

Re-measure after changes. A management interface moved behind an authenticated path should disappear from a public query.

Why this class keeps producing urgent advisories

A flaw in a reachable-by-design device is exploitable by anyone who can route to it, which is everyone. There is no reconnaissance barrier, no internal foothold required and no user interaction to engineer. The population is large because the product category is large.

That combination — universal reachability, no preconditions, and a device that holds trust material — is why pre-authentication flaws in remote access appliances consistently receive the fastest remediation timelines in the industry.

Using ZoomEye for remote access inventories

ZoomEye's product fingerprints let you enumerate this class across vendors and compare the result against your own remote access register. The useful comparison is not the global count but the difference between what is reachable and what you have documented: an appliance answering on a public address that nobody has recorded is the finding worth acting on.

References

• ZoomEye AI cyberspace search, queries executed 20 September 2026, sub_type=all: app="OpenVPN" = 2,163,654; app="Ivanti Connect Secure" = 1,225,643; app="pfSense" = 445,720; app="SonicWall" = 2,508,736; app="WatchGuard" = 31,255; app="Sophos XG Firewall" = 1,604. Counts describe internet-observable matching assets at query time and do not confirm vulnerability, misconfiguration or exploitation.
• ZoomEye search: https://www.zoomeye.ai/