VPN Appliance Security Guide: Vulnerabilities, Hardening and Replacement

The VPN appliance that lets staff in from the internet has become one of the most reliable ways for attackers to get in too. SSL VPN and IPsec gateways from most major vendors have had pre-authentication flaws exploited, several as zero-days, and some led to emergency directives that told agencies to disconnect devices within days. The appliances are closed boxes with no endpoint agent, thin logging and stored credentials for the corporate directory, so a compromise can persist after patching and go unnoticed. This guide covers why these devices are targeted, emergency response when a VPN vulnerability is announced, hardening for SSL and IPsec gateways, logging and integrity checking, exposure management and the case for replacement. It is for network, security operations and infrastructure teams. User authentication on remote access paths is covered in the Remote Access Identity Guide and ZTNA design in the ZTNA Guide.

Key takeaways

• Treat the VPN as an internet-facing application, not a network box. Its web portal and management plane are exposed to every scanner on the internet and are exploited as ATT&CK T1190 (Exploit Public-Facing Application).
• Patching does not evict an intruder. Vendors and CISA have documented persistence that survived upgrades, so every emergency patch needs an integrity check, a compromise hunt and credential rotation.
• Collect evidence before you reboot. Upgrades and resets destroy the logs and memory you need to know whether you were compromised.
• Shrink what is exposed. Keep management interfaces off the internet, disable unused portals and features, and restrict IPsec to UDP 500, UDP 4500 and ESP.
• Plan the exit. End-of-life appliances must go immediately, and moving remote access to a zero trust policy enforcement point removes the single internet-facing box that grants broad network access.

Why VPN appliances are a top initial access vector

The Five Eyes agencies published a joint series on edge devices in early 2025. The Canadian Centre for Cyber Security defines edge devices as "hardware or software tools that sit at the perimeter of networks", such as VPNs, firewalls and routers, and says targeting them "has now become a tactic of choice" for many threat actors. Several properties make VPN gateways especially attractive:

• Pre-authentication attack surface: the login portal, client download pages and web APIs run before any user authenticates, so a single input validation bug gives remote code execution or memory disclosure.
• Privileged position: the gateway terminates encrypted sessions, holds service account credentials for LDAP, RADIUS or SAML, and routes into the internal network.
• Poor visibility: no EDR agent, limited log detail and storage, and vendor-controlled operating systems that customers cannot inspect.
• Persistence: CISA's April 2025 alert described a malicious file created through previously exploited FortiGate SSL-VPN vulnerabilities that gave read-only access to the file system, including configurations, and persisted until the device was upgraded to fixed releases.
• Session theft: memory overread flaws such as CVE-2025-5777 in NetScaler Gateway expose live session tokens that bypass MFA. See the CitrixBleed 2 (CVE-2025-5777) and CitrixBleed 2023 pages.

SSL VPN, IPsec and the alternatives

• Split or full tunnelling: full tunnelling sends all traffic through corporate inspection but loads the gateway; split tunnelling saves bandwidth but leaves internet traffic to endpoint controls. Choose by endpoint security maturity, not bandwidth alone, and never allow split tunnelling to local networks on untrusted devices.
• Always-on VPN and kill switch: forcing the tunnel before logon keeps managed devices under policy and blocks traffic if the tunnel drops. It also makes the gateway a single point of failure, so size and cluster accordingly.
• Clientless web mode: rewriting proxies and portal bookmarks add a large web attack surface. Disable them unless there is a documented need.

Emergency response when a VPN vulnerability is announced

The directives above follow the same sequence. Write it into a runbook before you need it, with named owners and the vendor's support contacts.

1. Identify: find every instance, including virtual appliances, lab units and devices outside asset management. ED 25-03 opened with "Immediately identify all Cisco ASA platforms".
2. Mitigate now: apply the vendor workaround the same day (configuration change, mitigation file or IPS signature). Palo Alto's CVE-2024-3400 signatures worked only with vulnerability protection applied to the GlobalProtect interface, and the advisory was later updated to say that disabling device telemetry no longer mitigated the flaw, so recheck advisories daily.
3. Preserve evidence: collect support bundles, logs and, where the vendor or CISA provides a procedure, core dumps before rebooting or upgrading. Palo Alto advised collecting a Tech Support File first because logs from the prior installation become inaccessible after an upgrade. If compromise is found, CISA's instruction was to "disconnect the device from their network (but do not power off)".
4. Check integrity: run the vendor's integrity checking tool. For Ivanti, ED 24-01 required the external Integrity Checker Tool, which reboots the device, so run it after evidence capture. Treat a clean result as reassurance, not proof.
5. Patch or rebuild: upgrade to the fixed release. Where compromise is suspected or mitigation was late, factory reset from known-good media (Palo Alto offers an enhanced factory reset through support) and reimport a reviewed configuration.
6. Rotate secrets: follow ED 24-01: "Revoke and reissue any connected or exposed certificates, keys, and passwords", including admin passwords, stored API keys, local user passwords and directory service accounts. If domain accounts were reachable, reset them twice, revoke Kerberos tickets and revoke cloud tokens.
7. Kill sessions and hunt downstream: terminate all active VPN and AAA sessions after patching, since stolen session tokens outlive the fix, then hunt for logons from VPN address pools, new accounts and lateral movement.
8. Decide on disconnection: if no fix exists and exploitation is active, disconnecting or disabling the vulnerable service (as CISA advised for FortiOS SSL-VPN) is cheaper than an intrusion. Pre-agree the fallback access path.

Hardening a VPN appliance

The Australian Cyber Security Centre's practitioner guidance in the Five Eyes series groups edge device mitigations into seven strategies: know the edge, procure secure-by-design devices, apply hardening and patches, use strong authentication, disable unneeded features, secure management interfaces and centralise monitoring. Applied to VPN gateways:

• Management plane: never expose administrative web, SSH or SNMP interfaces to the internet. CISA BOD 23-02 names "VPN concentrators" among in-scope devices and gives agencies 14 days to remove such interfaces from the internet or put them behind a zero trust policy enforcement point. Use a dedicated management interface on an isolated management network with ACLs.
• Feature reduction: NSA and CISA advise "reducing the VPN's attack surface by disabling non-VPN-related features". The ACSC adds: "If a VPN feature is not being used, disable the service and block the service from the internet." Remove unused portals, clientless access, legacy protocols and IPv6 listeners you do not use; use SNMPv3 only from approved hosts.
• IPsec cryptography: NSA's IPsec guidance recommends only CNSSP 15-compliant proposals, with an example of Diffie-Hellman Group 16, AES-256 and SHA-384, lists DH Groups 20, 16 and 15 as compliant, and says to block DES, 3DES and DH Groups 1, 2 and 5. It recommends IKEv2 on Cisco ASA because the IKEv1 implementation only supports SHA-1, warns that wizard defaults enable extra suites that allow downgrade, and says to verify negotiated settings with commands such as show crypto isakmp sa detail. Replace pre-shared keys used with weak cryptography, and prefer certificates for site-to-site peers.
• Network filtering: limit IPsec gateways to UDP 500, UDP 4500 and ESP, restrict site-to-site peers to known addresses, and place an IPS in front of remote access gateways. Geo or reputation blocking reduces scanning noise but is not a control against targeted actors.
• TLS settings: SSL VPN portals should follow the same TLS baseline as other services; see the Cryptography Basics Guide.
• Procurement: NSA and CISA recommend tested and validated products on the NIAP Product Compliant List. The ACSC adds vendor track record on patches and transparent disclosure, and asks buyers to "explicitly demand product security as part of the procurement process".
• Lifecycle: the ACSC states "we strongly recommend replacing EOL edge devices immediately", and ED 25-03 ordered agencies to permanently disconnect ASA hardware reaching end of support by 30 September 2025.

Where identity fits

Most VPN compromises end in identity abuse, so the gateway's own credentials deserve the same care as user accounts.

• Directory service accounts: the LDAP bind or RADIUS account on the gateway is a non-human identity that attackers harvest from configuration. Give it read-only rights to the minimum directory scope, store it in a vault and rotate it after every appliance incident. The Ivanti Connect Secure Exploitation 2024 page shows credentials, service accounts and sessions exposed from VPN appliances. See the Service Account Security Guide.
• Appliance admin accounts: the ACSC recommends keeping edge device authentication separate from the corporate directory and managing local accounts through PAM or a secrets manager, so a directory compromise does not hand over the edge and vice versa.
• User authentication: phishing-resistant MFA on the VPN portal and removal of dormant accounts. The Colonial Pipeline Ransomware Attack 2021 began with an unused VPN account, and the SonicWall SSL VPN Account Compromises 2025 used valid credentials. Detail is in the Remote Access Identity Guide.
• Certificates and keys: gateway TLS keys, IPsec certificates and pre-shared keys are all exposed if the device is compromised; inventory them so they can be rotated in hours.

Logging, integrity checking and detection

The NCSC's digital forensics and protective monitoring specification (February 2025) sets a minimum for network appliances: log authentication with username, method, source address and session ID; vendor support access; HTTP and CLI activity; process creation; file system changes in the web root, configuration directories and system binaries; updates with checksums; configuration changes with previous and new values; and any attempt to clear or alter logs. Logs should go to a remote collector in near real time over TLS, with timestamps in ISO 8601 UTC and NTP failure alerts, and devices should send heartbeats containing the version, a SHA-256 digest of the running configuration, the last reboot time and a device GUID. Use it as a procurement checklist and enable everything your current devices already support.

• Ship logs off the box: the ACSC says edge devices "should not have access that allows the modification or deletion of any logs". Keep retention in the SIEM, not on the appliance; see the Log Management and Retention Guide.
• Alert on device changes: unexpected configuration changes, reboots, ACL or password changes, new local admins, firmware changes outside change windows, and large outbound transfers from the appliance itself.
• Alert on session anomalies: ATT&CK T1133 (External Remote Services) detection analytics include failed external logons followed by a successful session and internal movement. Add one session ID seen from two source addresses, VPN logons without an MFA event, and logons from hosting provider address space.
• Integrity checks: run vendor integrity tools on a schedule, not only in emergencies, and compare configuration digests against your last approved backup.
• Downstream detection: treat the VPN address pool and the gateway's own interface as sources to watch for directory queries, RDP and SMB to servers, and use of the gateway's service account from anywhere other than the gateway.

Metrics:

• Time from vendor advisory to mitigation, and to patch, for internet-facing VPN devices (target: hours for KEV-listed flaws).
• Percentage of VPN and edge devices with management interfaces reachable from the internet (target: zero).
• Percentage of edge devices sending logs and heartbeats to the SIEM, with gaps over one hour alerted.
• Number of end-of-life or unsupported edge devices in service.
• Percentage of VPN users and admins on phishing-resistant MFA, and dormant VPN accounts removed per quarter.
• Percentage of remote access applications moved behind ZTNA.

Exposure management and patch timelines

• Scan daily: the ACSC recommends vulnerability scanning of internet-facing devices "at least daily". Pair it with external attack surface monitoring to find forgotten gateways, test units and cloud marketplace images.
• Subscribe to sources: vendor PSIRT feeds, CISA KEV and national CERT alerts, routed to the network team's on-call rota, not a shared mailbox.
• Pilot and roll back: keep a standby or high-availability peer for upgrading one node first, a configuration backup taken before every change, and the previous firmware image to revert to if the upgrade breaks authentication. See the Patch Management Guide.

Replacing the VPN: ZTNA and other options

BOD 23-02's preferred option for exposed interfaces is access through a zero trust policy enforcement point separate from the interface, and the same logic applies to user access. ZTNA brokers connect users to named applications after checking identity and device posture, and connectors usually make outbound connections, so nothing listens on the internet at the private network edge.

• Move first: web applications, SSH and RDP to specific servers, third-party and contractor access, and admin access to infrastructure. These benefit most from per-application policy.
• Keep for now: legacy thick-client protocols, voice and some site-to-site needs may stay on IPsec while vendors catch up, on a hardened and monitored gateway.
• Small organisations: a cloud-delivered ZTNA or SASE service can remove the appliance entirely, transferring patching to the provider. Check the provider's own vulnerability disclosure and logging export.
• Large organisations: run VPN and ZTNA in parallel, migrate by application group, measure the remaining VPN users each month and set a decommissioning date for the appliance.
• What does not change: brokers and connectors are software that needs patching, logging and integrity monitoring, and over-broad application policies recreate a flat network.

Design detail is in the ZTNA Guide.

Common failure patterns

• Patch and walk away: CISA's FortiOS alert showed attacker files persisting until upgrade; organisations that patch without an integrity check and hunt can stay compromised.
• Not rotating credentials: configurations hold directory service account passwords, keys and certificates; ED 24-01 required all of them to be reissued.
• Leaving sessions alive: session tokens stolen before patching still work afterwards unless sessions are terminated, as both CitrixBleed incidents showed.
• Rebooting first: upgrading or power cycling before evidence capture destroys the logs and memory needed to scope an intrusion.
• Dormant accounts and weak MFA: valid credentials on an unused account need no exploit, as the Cisco Breach 2022 and Colonial Pipeline cases show.
• Running end-of-life hardware: devices without fixes for new zero-days were the reason ED 25-03 ordered permanent disconnection.

Framework mapping

Practitioner checklist

• Inventory every VPN gateway, virtual appliance and test unit, with version, support end date and owner.
• Remove management interfaces from the internet and disable unused portals, clientless access and services.
• Write an emergency runbook: mitigate, preserve evidence, integrity check, patch or rebuild, rotate secrets, kill sessions, hunt.
• Restrict IPsec to UDP 500, UDP 4500 and ESP with CNSSP 15-strength proposals, IKEv2 and no DES, 3DES or DH Groups 1, 2 and 5.
• Run the gateway's directory account with least privilege from a vault and rotate it after any appliance incident.
• Enforce phishing-resistant MFA for VPN users and admins, and remove dormant VPN accounts.
• Send appliance logs and heartbeats to the SIEM in real time and alert on configuration, reboot and session anomalies.
• Scan internet-facing devices daily and track KEV-listed VPN flaws to mitigation within hours.
• Replace end-of-life devices now and set a dated plan to move user access to ZTNA.

Standards and references

• CISA: ED 24-01, Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities
• CISA: ED 25-03, Identify and Mitigate Potential Compromise of Cisco Devices
• CISA: BOD 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces
• NCSC: Digital forensics and protective monitoring specifications for producers of network devices and appliances
• ACSC: Mitigation strategies for edge devices, practitioner guidance
• NSA: Configuring IPsec Virtual Private Networks
• Palo Alto Networks: CVE-2024-3400 PAN-OS GlobalProtect security advisory
• CISA: Fortinet Releases Advisory on New Post-Exploitation Technique for Known Vulnerabilities

Related NHI Mgmt Group resources: ZTNA Guide · Remote Access Identity Guide · Patch Management Guide · Firewall Management Guide · Service Account Security Guide