Remote Access – Is VPN the Almighty Solution?

In addition, as Secure Infrastructure Consultants, we are frequently asked about our thoughts on that very same topic of Remote Access. It can be summarized as “Remote Access VPN are sometime useful, most often they are not needed. In essence, Remote Access VPN is usually the wrong answer to the wrong question”.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Is VPN the Almighty Solution for remote access?

• Many breaches handled by Truesec originate from misconfigured or weakly protected Remote Access VPNs, especially lacking MFA or exposed globally.
• In most cases, organizations do not need network-level access; data, application, or desktop access can be securely provided without a VPN.
• When a Remote Access VPN is unavoidable, it must be always-on, MFA-protected, geofenced, tightly segmented, and continuously patched, with IPsec preferred over SSLVPN.
• Conclusion: Remote Access VPN is not inherently insecure, but it is often the wrong solution and, when used, must be strongly hardened and limited to avoid becoming a primary attack vector.

What is a Remote Access VPN? 

This question may seem a bit silly: of course, everyone knows what a Remote Access VPN is: it is a way to get access to the resources local to a remote network from a client. 

A Virtual Private Network (VPN) is a network technique to create a point-to-point link between two devices over a set of networks. The idea is that any network packet put on the link at one end will exit at the other end without the underlying networks knowing anything about these packets. This is, for example, a way to interconnect two sites that are using RFC1918 IP addresses, the so-called “private IP addresses”, over a public backbone.

But that is only one part of the whole story. 

Site-to-Site VPN 

A site-to-site VPN creates a virtual connection between two sets of networks, each called “a site” as site-to-site VPN were historically configured as substitutes or backups to dedicated physical connections such as dark fibers.

In a site-to-site VPN, the identity of each peer is usually set as the IP address. To authenticate these identities, site-to-site VPN often use the so-called “preshared keys” (PSK), a form of password – which is considered “safe enough” when combined with the static IP addresses requirement of a site-to-site VPN – configured on both devices and used to encrypt the negotiation of the tunnel.  

Client-to-Site VPN (Remote Access VPN) 

The “Remote Access” indicates that one side of the VPN will be a single machine, the client, the other side being an organization’s network. The client side is often dynamic – its IP may change over time – while the corporate side is typically static, its IP does not change very often. 

A Remote Access VPN is, first and foremost, a VPN: any traffic on the machine that is routed to the VPN will end in the corporate network. In a nutshell, Remote Access VPN is a network connection into the organization’s network. If you are old enough, you may remember companies that had pools of modem to enable their workers to connect to the network when not in the office. A Remote Access VPN is about the same over the internet.

The Main Difference 

Astute readers have spotted the main difference: in a site-to-site VPN, each side of the VPN is more or less static and a PSK is often – not always – considered enough to protect the access.  

However, in the case of a Remote Access, the identification of the client side cannot rely on “just” the IP address. In that case, it must include another form of identity to clearly identify who is attempting to create this VPN. Usually, that information comes from a supplied username. 

Remains the question of the authentication: this can take many form, the simplest being a password and very secure implementation using several methods such as a user password, a time-based one-time password, a push notification and a client certificate.

Network, Desktop, Application or Data Access? 

Let us take a step back. Often “Remote Access VPN” comes as the answer to all “access questions”, for the simple reason that the feature is available on most firewalls by default. Oftentimes, it is not the best answer. 

Often, the need, although not expressed in those terms, is to access internal documents. This we will call “Data Access”: the how the access is made is not relevant, what counts is to be able to open the documents, spreadsheets, or presentations. 

Many business applications are presented via a web interface. This is the case, among other things, for helpdesk applications and intranet services. Let us call this “Application Access.” 

At other times, the need is to access an application that has a dedicated client, often called a “fat client”. A classic example of such fat client is an ERP application: these are usually applications that need a direct connection to the ERP database and for which no web equivalent is available. This we will call “Desktop Access”: the client must run on the desktop the user is connected to while having a line of sight to the server.

Lastly, there are cases where true network-level access is indeed needed. That will be our “Network Access.”

But Which One? 

Setting the Scene 

The reality is that true network access is seldom needed: most of the time, when people ask for access they need access to the data, an application or a desktop but not to the network itself. Here are a few scenarios. 

A salesperson is on a commercial trip and wants to create a contract from a template stored in their organization’s file repository. In addition, they must retrieve the client’s information from the accounting application, which has a web frontend. The former describes a need for “Data Access”, the latter for “Application Access.

A production manager is writing a report about the previsions for the next quarter. They need some figures from the corporate ERP, a software that runs on a legacy platform and whose client consists of a terminal application. The former expresses the need for “Data Access”, the latter for “Desktop Access.” 

An engineer is working at home on a design with a CAD application that has a per-seat license. The CAD application is a program that has very high requirements in terms of memory and CPU. The application validates its license against a network license server, located on the corporate network. This is an example of a need for “Network Access.”

Of these three examples, only the last one would require a VPN. The needs of the first two can be met with other means. 

Data Access 

As we wrote above, this is the need to access any information that would be normally accessible if the computer was on the corporate network: usually word processor documents, spreadsheets, presentations and other files that are often stored on internal file servers. Does this mean that VPN is unavoidable? Not at all.

A typical alternative is to use cloud storage, for example Microsoft OneDrive as part of Microsoft Office365 or Google Drive as part of Google Workspace. This also includes the professional versions of DropBox and Box.com. These have several security features to protect the data, including multifactor authentication and access controls. 

As a recent question has been digital sovereignty, European providers will likely emerge to provide the same services. 

For some organizations, using storage managed by a third party is not an option. In that case, it is possible to self-host a storage solution such as Apache Ozone. The drawback of a self-hosting solution is the need for the hosting company to maintain the solution adequately. 

Application Access 

Many applications, and most modern applications in all cases, have a web interface instead of a “fat client” which enables using the application without needing to install any new software on the clients. Network-wise, the client must be able to reach the server on its HTTP/HTTPS port. 

Again: a VPN is not required for these applications. 

While exposing these applications directly to the Internet is, generally, not a good idea, a Microsoft Azure Application Gateway can be leveraged to present the application to clients using a normal internet connection. The Azure Application Gateway adds a layer of authentication, including conditional access and multifactor authentication, prior to letting the client access the application. 

In case self-hosting is required, the application is presented via so-called “identity-aware proxy” or IAP. Similarly to the Azure Application Gateway, the IAP will request the user to authenticate prior to authorizing the access. Once these steps are performed, the user is presented with the application page. 

Desktop Access 

Some applications do not or cannot have a web frontend. For example, applications running on legacy platforms usually have either a “fat client” or a terminal client. For these applications, presenting them via a proxy is often not feasible. 

In that case, if the application cannot come to the desktop, why not make the desktop come to the application? In other words, instead of running the client on the user’s computer and trying to make the connection between the remote device and the local application, why not run the desktop on a server on the corporate network and have the user connect to that desktop. You may know this under the name “terminal server” or “Remote Desktop Services.” 

Truesec recommends against exposing RDP directly to the internet. In several incidents we responded to, this was the point of entry. Instead Truesec recommends using an RDP Gateway, or RDPGW in short, a web server that requires authentication prior to granting access to the desktop, which itself may use separate authentication.

Network Access 

Lastly, there are circumstances when a computer needs a line of sight between itself and an internal server and that no other means can be used instead. In those cases, a Remote Access VPN is unavoidable. 

What Remote Access VPN Should We Use? 

For the rest of the article, let us consider that a Remote Access VPN is the only possible solution. 

On-Demand or Always On? 

Remote Access VPN can connect to its configured gateway either on demand, i.e. the user requests the connection, or can automatically initiate the connection, for example when the computer boots.

Truesec recommends the always-on VPN (AOVPN) without split VPN. In this mode, all the network traffic the computer generates goes through the organization’s network and is subjected to the network protections offered by, for example, the organization’s firewall. This is important, for example, if the firewall applies application control or Data Leakage Protection (“DLP”). As usual, all machines accessing the organization systems should be protected with an EDR.

SSLVPN or IPsec 

IPsec (“IP Security”) was initially defined in the RFC 1825 to 1827 published in 1995. Over the years, the protocol has evolved, for example to IPsec-v2 in 1998 with the publication of RFC2401 and to IPsec-v3 in 2005 in RFC4301, which is the version in use nowadays albeit several documents have been published that add new algorithms and deprecate obsolete methods. IPsec is thus based on open, public standards available to all vendors, and it is possible to interconnect the client from one vendor to the gateway from another vendor.

SSLVPN was introduced in the early 2000s to compensate for the poor support for Remote Access VPN that IPsec offered at the time. Since then, many vendors have defined their own SSLVPN client. There are no public standards defining SSLVPN or its operations, and as such, clients and devices from different vendors are usually not interoperable.  

It would be hard to pick one versus the other when it comes to vulnerabilities: in 2025 alone, several CVE were published regarding vulnerabilities in implementations of SSLVPN, for example: CVE-2025-40601 (SonicWall), CVE-2025-25250 (Fortinet), or CVE-2025-20133 (Cisco). The same year saw the publication of CVE-2025-21674 (Linux Kernel), CVE-2025-58071 (BigIP F5), or CVE-2025-14733 (Watchguard) that affect IPsec implementations. 

A determining point may be the announcements from Fortinet and Cisco to deprecate SSLVPN and remove it from their products. For this reason, Truesec recommends choosing IPsec. 

Where Is This VPN From? 

A common misconfiguration Truesec sees in many firewalls is the lack of filtering for inbound VPN connections: a client can establish a VPN tunnel with the firewall from anywhere in the world. Is it convenient? Yes. Is it needed? Unlikely.  

To that effect, many firewalls have the concept of “geofencing” or “geofiltering”: this is a firewall rule where, instead of using a classic IP, subnet or FQDN, one or more countries are defined as the source. Behind the scene, the firewall has a database associating the IP subnets and their geographical location, subnets which are then used for the actual filtering. 

Restricting the sources for VPN connections is important as it hinders the threat actors’ effort to guess or use valid credentials. It also reveals to the whole world that a VPN server is running on the device: a search performed on Shodan.io in March 2026 showed that more than 35,000 devices were identified as “Cisco ASA SSL VPN” and are likely widely accessible, making them potential targets for threat actors.

What Authentication? 

Regardless of AOVPN or on-demand VPN, multifactor authentication (“MFA”) is, nowadays, no longer an option. In many incidents Truesec has responded to, the lack of MFA was an important factor in the threat actor’s success in gaining access to the networks.

MFA may take many forms, for example a client certificate and a time-based one-time password, or a password and a push notification. 

Keep It Updated 

An often-overlooked step in keeping a Remote Access VPN secure is to be on top of vendor’s notifications and patches.  

Many, if not all, vendors send notifications regarding updates and vulnerabilities. Additionally, each new version has release notes that present the issues fixed, the known existing issues and the possible restrictions or conditions, such as recommended update paths.

Truesec always recommends keeping the firmware and software running on security devices as up-to-date as possible, with the release notes providing the information on whether an update is urgent. 

VPN Is Not a Free Pass 

Lastly, it is important to understand that a machine coming via a VPN should never be implicitly trusted. Instead, the reachable destinations should be limited to what is needed for the user to perform their tasks.  

There are parts of the network that should never be reachable from a VPN client. The network interconnecting the infrastructure components, such as the virtualization platforms, network cores, backup systems, and storage devices (“The fabric”), is one of them.

Conclusions 

Remote Access VPN is not inherently bad or insecure. Its misuse and misconfiguration, however, is usually the open door to compromise. The solution is often deployed because it is available in the firewalls and many sites explain how to configure a basic VPN access. What these sites actually miss is the hardening of the solution once in place. 

Other solutions exist that provide access to data, applications, or desktop without requiring the additional connectivity that a Remote Access VPN brings. Truesec recommends that, prior to opting for any solution, careful considerations be made on what the actual needs are and what are the adequate solutions. 

The post Remote Access – Is VPN the Almighty Solution? appeared first on Truesec.

Article Link: Remote Access - Is VPN the Almighty Solution? - Truesec

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics