NETWORK SECURITY · LAB

Secure Remote Access Lab

A simulated enterprise environment used to examine how identity, endpoint trust, network segmentation, access policy and logging work together when remote users connect to internal resources.

1. Objective

The purpose of this lab was to test remote access as an access-control architecture rather than only as a VPN connection.

The environment was designed to answer several practical questions:

  • Can a remote user authenticate securely?
  • Does successful VPN authentication provide only the access actually required?
  • Can management resources remain isolated from ordinary remote users?
  • Can user activity be traced through authentication and firewall logs?
  • What happens when the user attempts to access a resource outside the permitted scope?

The main objective was therefore not simply to establish a working tunnel.

It was to verify that identity, network policy, trust boundaries and logging continued to work together after the tunnel was established.

All addresses and systems used in this lab are simulated and do not represent a production environment.

2. Scenario

The lab represents a small enterprise environment where authorised staff need remote access to selected internal resources.

The environment contains four logical areas:

Remote Access Pool — 10.50.50.0/24

Addresses assigned to authenticated remote VPN users.

Infrastructure Services — 10.50.10.0/24

Directory, DNS and other supporting infrastructure services.

Application Network — 10.50.20.0/24

Internal resources that authorised remote users may need to access.

Management Network — 10.50.99.0/24

Administrative interfaces for infrastructure components.

The test user is permitted to connect remotely and access selected resources in the Application Network.

The same user should not have general access to the Management Network or unrelated internal services.

The lab assumes that the remote endpoint is a managed Windows workstation using a VPN client and multi-factor authentication.

3. Architecture

The simulated architecture consists of:

Remote Windows Client

A managed endpoint used to initiate the remote-access session.

VPN Client

Establishes the encrypted connection to the security gateway.

Internet

Represents the untrusted network between the endpoint and enterprise perimeter.

Security Gateway

Terminates the VPN, authenticates the user, assigns a remote-access address and enforces access policies.

Identity Services

Windows-based directory and supporting authentication services.

Application Network

Contains the internal resources the remote user is authorised to reach.

Management Network

Contains privileged administrative interfaces and is intentionally excluded from normal remote-user access.

The logical traffic path is:

Remote Client → Internet → VPN Gateway → Remote Access Zone → Permitted Internal Resources

Traffic from the remote-access zone to other internal networks is not assumed to be trusted simply because the VPN connection has been established.

4. Trust Boundaries

The lab uses several distinct trust boundaries.

Internet → VPN Gateway

Traffic originates from an untrusted network. Access is permitted only through the remote-access service.

VPN Gateway → Remote Access Zone

Successful authentication establishes an authorised session, but it does not grant unrestricted internal access.

Remote Access Zone → Application Network

Communication is permitted only for explicitly required destinations and services.

Remote Access Zone → Management Network

Access is denied for the standard remote user.

Administrative Access

Management resources require a separate privileged path and should not inherit trust from an ordinary VPN session.

Authentication answers “Who is connecting?” It does not automatically answer “What should this user be allowed to reach?”

5. Access Policy

The lab uses a least-privilege access model.

Remote VPN user → required application service: allow

Remote VPN user → required infrastructure services: allow only as required

Remote VPN user → unrelated server networks: deny

Remote VPN user → management network: deny

Remote VPN user → infrastructure administrative interfaces: deny

Invalid or unauthorised VPN authentication: deny

Relevant allowed and denied traffic: log

The user should receive connectivity to the required service, not broad access to the internal environment.

6. Test Cases

Test 1 — Valid user authentication

Expected result: authorised user successfully establishes the VPN session.

Test 2 — Invalid credentials

Expected result: authentication fails and the event is recorded.

Test 3 — MFA failure

Expected result: the session is not established even when the primary credential is correct.

Test 4 — Access to permitted application resource

Expected result: the required application service is reachable.

Test 5 — Access to Management Network

Expected result: traffic is denied and logged.

Test 6 — Access to unrelated internal resource

Expected result: traffic is denied unless explicitly permitted by policy.

Test 7 — Session logging

Expected result: authentication, assigned remote address, session activity and relevant firewall events can be correlated.

7. Observations

The lab reinforced several practical points.

A successful VPN session should not be treated as equivalent to trusted internal network presence.

Authentication, network access and privilege should remain separate decisions.

The most important control was not tunnel encryption itself, but the policy applied after authentication.

Separating the remote-access address pool from ordinary internal networks made the access model easier to understand and control.

Explicit deny rules toward management resources also provided a clear security boundary and useful evidence when prohibited access was tested.

Logging was particularly important.

Authentication logs established who connected and when.

Firewall logs showed which destinations were reached, which attempts were denied and how the session interacted with internal resources.

Together, these records provided considerably more context than the VPN connection event alone.

The lab also demonstrated that broad rules make remote access easier to configure but harder to defend.

A narrow policy takes more initial work, but the resulting access model is easier to explain, review and investigate.

8. What I Would Change

For a larger or higher-risk environment, I would extend this design in several areas.

Endpoint posture

Access decisions could consider whether the connecting endpoint is managed, patched and running the required security controls.

Stronger privileged-access separation

Administrative remote access should use a separate policy path rather than sharing the same access model as ordinary users.

More granular application access

Where possible, access could be defined by specific resources and services rather than broad network ranges.

Centralised logging

VPN, firewall, identity and endpoint events could be correlated centrally to improve detection and investigation.

Access review

Remote-access permissions should be reviewed periodically to remove unnecessary users, destinations and legacy exceptions.

Conditional access

Identity, device state, location, risk and requested resource could be evaluated together before access is granted.

The final design principle remains simple:

A VPN should provide a protected path into the environment.

It should not automatically provide trust in everything behind that path.