EngineSpire Technologies Inc., home
Menu
Request a consultationPlan a site visit

NWNetworkGuide

VPN Architecture for Hybrid Teams and Third-Party Support

Remote access VPNs give staff and vendors a path into internal systems, and attackers target them for the same reason. This guide covers design choices, hardening, vendor access and when to move toward identity-based access.

Published
Updated
Reading
3 minutes
Prepared by
EngineSpire Technologies

Key points

  • VPN gateways face the internet and are heavily targeted. Patch them quickly and expose as little as possible.
  • Require MFA and check device health before granting access.
  • Grant access to specific applications and networks by group, not the whole network.
  • Handle vendor access separately: time-limited, approved, recorded and restricted.
  • Identity-based access can replace broad VPN access one application at a time.

Why VPN design deserves attention

VPN appliances sit on the internet edge and grant network access once a user authenticates. Vulnerabilities in remote access products have repeatedly been exploited in real attacks, and many appear in CISA's Known Exploited Vulnerabilities catalog. Stolen passwords and MFA fatigue attacks target the same entry point. A good design limits what an attacker gains even when one control fails.

Design principles

  • Strong authentication: MFA for every user, with phishing-resistant methods for administrators.
  • Device trust: certificates on managed devices and posture checks for operating system updates and endpoint protection.
  • Least privilege: group-based policies that allow specific subnets, ports or applications, not everything.
  • Separate administration: privileged access through a jump host or privileged access management tool, not directly from the VPN pool.
  • Small attack surface: no management interface on the internet, and unused portals and features disabled.
  • Modern protocols: IKEv2 or TLS-based VPNs with current cipher suites; retire legacy protocols such as PPTP.

Split or full tunneling

ModeHow it worksAdvantagesTrade-offs
Full tunnelAll traffic goes through the corporate networkCentral inspection and consistent policyBandwidth demand, latency to cloud applications
Split tunnelOnly traffic for internal systems uses the VPNBetter performance for SaaS and video callsInternet traffic needs protection on the device or through a cloud security service

Capacity and resilience

Size gateways and licences for the day everyone works remotely, such as during a typhoon or transport disruption, not for a normal Tuesday. Deploy redundant gateways, ideally on separate internet links, and test failover.

Vendor and third-party access

  • Give every vendor engineer an individual named account. Never share accounts.
  • Require MFA, approval before each access window and automatic expiry.
  • Restrict access to the specific systems the vendor supports.
  • Record privileged sessions, and review what was done.
  • Remove standing, always-on vendor tunnels where possible.
  • Write access and logging expectations into support contracts.
  • Review vendor accounts regularly and disable any that are unused.

Logging and detection

  • Log authentication attempts, session start and end, source addresses and assigned addresses.
  • Forward logs to a central platform and keep them long enough to investigate incidents.
  • Alert on brute-force attempts, sign-ins from unexpected countries, unusual hours for a user and repeated MFA denials.

Patching and hardening

  • Subscribe to vendor security advisories and have an emergency patching process for internet-facing devices.
  • Check new advisories against CISA's Known Exploited Vulnerabilities catalog to prioritize.
  • Review configuration against the vendor's hardening guide at least yearly.
  • Back up configurations and test restoring them.

Reviewing an existing VPN

  1. List every VPN group and what each can reach; many grant far more access than their members need.
  2. Find accounts that have not signed in for months, and any shared or generic accounts.
  3. Confirm MFA is enforced for every group, including vendor and service accounts.
  4. Compare the gateway's software version with the vendor's latest security advisories.
  5. Check which management interfaces are reachable from the internet, and close them.
  6. Confirm that logs reach the central logging platform and that someone reviews the alerts.
  7. Test failover to the secondary gateway or internet link.

Moving toward identity-based access

Zero trust network access (ZTNA) connects users to specific applications after checking identity and device, without placing them on the network. It fits the principles in NIST SP 800-207. Most organizations migrate gradually: web applications first, then others through connectors, while keeping VPN for the remaining cases.

Common questions

Is a VPN still secure enough for remote work?

A well-managed VPN with MFA, device checks, least-privilege policies and prompt patching can be. The risks come from broad network access, weak authentication and unpatched gateways; identity-based access reduces that exposure further.

Should vendors use the same VPN as employees?

They can use the same platform, but with separate policies: individual accounts, MFA, approval, time limits and access only to the systems they support, with privileged sessions logged or recorded.

What is split tunneling, and is it safe?

Split tunneling sends only traffic for internal systems through the VPN while other internet traffic goes directly. It improves cloud application performance, but devices then need their own protection for internet traffic, such as endpoint security and web filtering.

Sources and further reading

  1. [1]SP 800-77 Rev. 1: Guide to IPsec VPNs — NIST
  2. [2]Known Exploited Vulnerabilities Catalog — CISA
  3. [3]SP 800-207: Zero Trust Architecture — NIST

Need this applied to your environment?

We can turn this guide into a scoped assessment of your own sites, systems and constraints.

Request a consultationPlan a site visit

Keep reading