Remote-access questions become easier when you separate four decisions that are often mixed together: who is connecting, what traffic enters the tunnel, how the administrator reaches the device, and whether that management path depends on the production network.
The full Domain 3 Network Operations guide teaches the broader operational context. This Quick Review is for choosing among nearby access and management options quickly.
Fast rule: First ask whether the scenario connects networks, one endpoint, or one application. Then decide what traffic should use the tunnel and whether the management path must survive a production-network failure.
1. Access decision map
| Scenario question | Think first | Why |
|---|---|---|
| Two networks need persistent encrypted connectivity | Site-to-site VPN | The tunnel joins network locations rather than one roaming endpoint |
| One remote laptop needs internal-network access | Client-to-site VPN | The endpoint becomes the remote side of the connection |
| User needs one web application without a full network tunnel | Clientless access | Access can be application-focused through a browser or portal |
| Only corporate destinations should use the VPN | Split tunneling | Selected traffic enters the tunnel while other traffic follows the local path |
| All remote-client traffic must traverse organizational controls | Full tunneling | The remote endpoint sends all covered traffic through the VPN according to policy |
| Need device access after production routing fails | Out-of-band management | The management path must not depend on the failed production path |
2. Separate VPN access models by who connects
A virtual private network (VPN) protects traffic across an untrusted or shared network by creating a secured logical path. For Network+ decisions, start with the endpoints of that path.
| Access model | Connects | Best-fit clue |
|---|---|---|
| Site-to-site VPN | Network gateway to network gateway | Branch office, partner site, or two networks need ongoing protected connectivity |
| Client-to-site VPN | Individual endpoint to remote network | Remote employee laptop needs access to internal resources |
| Clientless access | User or browser to selected applications or services | Limited application access without installing or operating a full VPN client |
A site-to-site VPN does not require every employee at one site to start a personal VPN session. The gateways protect traffic between the connected networks according to policy.
A client-to-site VPN is endpoint-focused. The endpoint commonly authenticates before gaining access to permitted remote resources.
Clientless access is narrower. It can fit a contractor or user who needs selected browser-accessible resources without broad routed access into the internal network.
3. Choose split or full tunneling from traffic policy
The tunnel type answers who connects. Split versus full tunnel answers which traffic uses that connection.
Split tunneling
With split tunneling, selected destinations use the VPN and other traffic follows the endpoint's local network path.
Useful clues:
- Corporate subnets should use the VPN.
- Ordinary internet browsing should continue through the user's local connection.
- The organization wants to reduce VPN gateway bandwidth consumption.
- The policy accepts the security tradeoff of simultaneous local and remote-network connectivity.
Full tunneling
With full tunneling, the remote client's covered traffic is sent through the VPN according to policy before reaching other destinations.
Useful clues:
- Internet traffic must pass through organizational filtering or inspection.
- The organization wants centralized egress controls for remote users.
- The remote endpoint should not bypass organizational network controls through its local connection.
| Question | Split tunnel | Full tunnel |
|---|---|---|
| Corporate traffic | Uses VPN for selected destinations | Uses VPN |
| Other internet traffic | Can use local internet path | Traverses VPN path according to policy |
| Central inspection | Not all traffic passes through central controls | Supports centralized inspection of tunneled client traffic |
| Gateway bandwidth | Lower demand from noncorporate traffic | More traffic may traverse VPN infrastructure |
Do not answer a split-versus-full question by changing the VPN from client-to-site to site-to-site. Those are different decision layers.
4. Use clientless access when application scope is the clue
Clientless remote access is useful when a user needs selected services rather than broad network-layer connectivity.
Typical clues include:
- Browser-based access
- A portal exposing approved internal applications
- Limited contractor access
- A managed application path without installing a traditional VPN client
Clientless does not mean unauthenticated. Access still needs identity, authorization, encryption, logging, and session controls appropriate to the environment.
It also does not automatically provide access to every internal protocol. If a user needs arbitrary network connectivity, specialized client software or another remote-access method may be a better fit.
5. Match the management method to the task
Remote management and VPN access overlap, but they are not the same decision. A VPN may provide the protected path. The administrator still needs a method for managing the device or service.
| Method | Best-fit clue | Important distinction |
|---|---|---|
| Secure Shell (SSH) | Encrypted command-line administration | Useful for interactive device CLI access over IP |
| HTTPS graphical interface | Administrator needs a browser-based GUI | Protect the management session and restrict who can reach it |
| Application programming interface (API) | Automation or integration should read or change state programmatically | Use scoped credentials, access controls, error handling, and secret protection |
| Console | IP networking is unavailable or the device needs direct recovery access | Can provide local or dedicated management independent of normal IP access |
| Jump host | Administrative access should enter a protected environment through a controlled intermediary | Centralizes an access point; it does not automatically make the path out-of-band |
SSH and HTTPS answer how the administrator interacts with the device. In-band and out-of-band answer which path carries that management traffic.
6. Use a jump host as a controlled administrative entry point
A jump host is an intermediary system used to reach protected systems that should not accept direct administrative connections from ordinary user networks.
It can support:
- Strong authentication before deeper access
- Centralized logging
- Restricted source addresses
- Session control
- Reduced exposure of management interfaces
The key exam distinction is architectural: a jump host centralizes access, but it does not automatically create an independent management network.
If administrators connect to the jump host through the same production switches, routers, and links that serve ordinary traffic, that access remains dependent on the production path.
7. Separate in-band from out-of-band management by dependency
In-band management
In-band management uses the same production network or routing infrastructure that carries ordinary traffic.
Examples can include:
- SSH to a switch management address over the production LAN
- HTTPS administration over routed production interfaces
- A jump host reachable only through normal production routing
It is convenient because no separate management infrastructure is required. Its weakness appears when the production network is the thing that failed.
Out-of-band management
Out-of-band management uses a separate management path designed to remain available when the production data path is unavailable or badly misconfigured.
Examples can include:
- Dedicated management interfaces on an independent management network
- Console server access
- Separate cellular or other independent management connectivity
Decision rule: If fixing the production network requires the production network to be working first, you do not have a truly independent recovery path.
A management VLAN can improve separation while still being in-band if it depends on the same production switching and routing infrastructure. Logical separation alone does not guarantee path independence.
8. Scenario comparisons
Two offices need automatic protected connectivity
Use site-to-site VPN. The gateways connect the networks, so users at either office do not need to initiate a separate endpoint VPN for every internal conversation.
One employee works from a hotel and needs file-server access
Use client-to-site VPN. One remote endpoint needs protected access into the organization's network.
A contractor needs only an internal web application
Clientless access can fit if the application can be safely exposed through the approved portal and the user does not need broader network access.
Corporate traffic should use the VPN, but streaming traffic should use the employee's home connection
Use split tunneling. Selected organizational destinations use the VPN while unrelated traffic remains on the local path.
Every remote-user web request must pass through corporate security controls
Use full tunneling. Sending covered client traffic through the organizational VPN path supports centralized inspection and policy enforcement.
An administrator needs to configure a router from a terminal
Use SSH when IP reachability exists and encrypted command-line management is appropriate.
A network outage broke routing to the switch management addresses
An out-of-band path is the important distinction. A console server or independent management network can remain useful when the production route is unavailable.
Administrators must enter a sensitive server network through one hardened system
Use a jump host as the controlled administrative entry point. Do not call it out-of-band unless its own management path is independent of the failed production network.
9. Common exam traps
- Choosing site-to-site when the scenario describes one roaming endpoint.
- Choosing client-to-site when the requirement is persistent network-to-network connectivity.
- Treating clientless as a synonym for no authentication.
- Confusing VPN type with tunnel-routing policy.
- Choosing split tunneling when all remote traffic must pass through central controls.
- Choosing full tunneling when the scenario specifically wants local internet traffic to bypass the corporate gateway.
- Calling SSH a VPN. SSH is a secure management protocol, not the VPN access model in these scenarios.
- Calling a GUI out-of-band simply because it is a separate application.
- Treating a management VLAN as automatically out-of-band.
- Treating a jump host as automatically out-of-band.
- Choosing an API for a one-time interactive CLI task when SSH fits the stated need.
- Choosing SSH when the production IP path is down and the scenario asks for recovery access.
- Assuming console access must be physically local to the device. Console servers can provide remote access to console ports through a separate management design.
- Forgetting that remote access still needs authentication, authorization, logging, and policy even when the tunnel itself is encrypted.
10. Rapid review grid
| Clue | Best first answer | Why |
|---|---|---|
| Branch to headquarters | Site-to-site VPN | Network-to-network |
| Remote employee laptop | Client-to-site VPN | Endpoint-to-network |
| Browser-only selected app | Clientless access | Application-scoped access |
| Only corporate prefixes through VPN | Split tunnel | Selected traffic uses tunnel |
| All remote traffic through corporate controls | Full tunnel | Centralized path and policy |
| Encrypted interactive CLI | SSH | Secure command-line management |
| Automation/integration | API | Programmatic access |
| Production IP path failed | Console or other out-of-band path | Independent recovery path |
| Controlled admin gateway | Jump host | Central administrative entry point |