Which VPN Process Does That Vulnerability Finding Hit?

A scanner result names an address, a port and something it negotiated there. It does not name the process behind that socket, and on a VPN host several processes can share the machine while only one of them is the tunnel. Reading a version string from a side utility or finding a library file on disk adds evidence about the host, not about the listener. The finding becomes actionable only when it is attached to one running component and then matched to the scope an advisory actually states.

The order matters: component first, advisory second, remediation third.

The Report Names a Port, Not a Program

Start from the endpoint that was actually assessed. A probe against the HTTPS administration port measured the web service, its TLS stack and whatever proxy sits in front of it; it learned nothing about the OpenVPN or WireGuard listener on a different port. Reverse proxies and management agents make this worse, because the certificate and banner can belong to the front end while the vulnerable library sits behind it in a backend process.

Record the destination, transport, port and service name with the result so the scope travels with the finding.

What the Running Build Actually Is

On a general-purpose host, the installed package and the loaded library are separate questions. A package database can list a patched version while a long-running daemon still holds the old shared object mapped into memory, and a bundled appliance image can carry its own libraries that no package manager reports. Ask the service manager what is running, then inspect the process and its linkage.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

The start time in the process listing is the detail people skip. A daemon started before the last package upgrade is still running the build it loaded at boot, which is exactly the case where an inventory says fixed and the socket says otherwise.

Matching the Build to an Advisory's Scope

Advisories describe products, versions and sometimes required conditions, and those three fields do not always align with a package version. OpenVPN's April 2014 Heartbleed advisory is a useful historical example because it separates affected Access Server releases from the web services and the VPN daemons, which had different exposure. The lesson is to read which component the text covers rather than pattern-matching the word OpenSSL.

That advisory is also dated. Its fixed release numbers are not installation advice now, and a flaw fixed in 2014 says nothing about later issues in the branch you run today.

Resolving Disagreement, Then Closing Exposure

When inventory and assessment disagree, check whether both describe the same endpoint and runtime: another address, a front-end proxy, a second service, an old process still bound to the port, or a bundled library the package manager never saw. Resolve that at the boundary before rewriting a report.

Apply the supported correction, restart the affected service and confirm the new build is the one now running. A patched file on disk with the old process still serving traffic is not remediation.

Then handle what the component could have held during the exposure window. Patching and credential replacement answer different questions, and a certificate stored near the affected host is not by itself a list of what leaked. Follow the incident owner's procedure for revocation, session removal and client updates, and record which component was affected, why the evidence applied and what closed it. That record is what a later review will read.