Remote access and out-of-band management

Why this matters

Objective 3.5 is "compare and contrast network access and management methods", and it covers two related things: how users reach the network from outside, and how administrators reach the equipment.

The second half contains the single most valuable idea in domain 3 — out-of-band management. If you have ever taken down the link you were administering a device over, you already understand why it exists. If you have not, this is the lesson that stops you doing it.

The lesson

Site-to-site VPN

A site-to-site VPN permanently connects two networks across the internet, normally firewall to firewall or router to router. It uses IPsec in tunnel mode, so the original packet is encrypted and wrapped in a new header addressed between the two gateways.

Its defining property is that users run nothing. Someone at the branch reaches a server at head office exactly as if they were on the same network; the tunnel is infrastructure, not an application. Set up once, always on.

Use it to join offices, to connect to a cloud VPC, and to reach a partner's network. The limitation is that it connects networks, not people — it does nothing for a user working from home.

Client-to-site VPN

A client-to-site VPN — also called remote access VPN — connects an individual device to the network. The user runs client software that authenticates and builds a tunnel to a concentrator or firewall.

This is what a home worker uses. Authentication is per user, ideally with multifactor, and access can be scoped by identity: contractors reach one segment, staff another.

Clientless VPN is the variant with no installed software. The user connects through a web browser over TLS, and the gateway presents specific applications — a web portal, an internal site, sometimes RDP or SSH proxied through the page.

• Nothing to install, so it works from a device you do not manage, and it suits contractors and emergency access.
• It gives access only to what the portal publishes, not full network connectivity. That is a limitation and a security benefit.
• Because it runs on an unmanaged device, the endpoint's security posture is unknown — which is precisely why limiting it to specific applications is the right design.

Split tunnel versus full tunnel

The routing decision on any client VPN, and a frequent exam item.

Full tunnel sends all the client's traffic through the VPN, including ordinary web browsing, which then exits via the corporate internet connection.

• Everything is inspected, filtered and logged by corporate controls.
• The device is effectively on the corporate network and nowhere else.
• It consumes corporate bandwidth for traffic that had no business there, and adds latency for the user — noticeably so for video calls.

Split tunnel sends only traffic bound for corporate resources through the tunnel; everything else goes out the local internet connection directly.

• Far better performance, and much less load on the concentrator. This is why it became common when everyone started working from home.
• The device is simultaneously on the corporate network and the open internet, with its general traffic uninspected — which is the exposure security teams object to, since a compromise arriving over the untunnelled path has a route inward.

There is no universally right answer, and an exam question will give you the deciding constraint: bandwidth and call quality point to split tunnel, inspection and compliance point to full tunnel.

Connection methods

How an administrator reaches a device, roughly in order of preference.

SSH is the standard: an encrypted command-line session on TCP 22. It replaces Telnet, which sends everything including the password in clear text and should not be enabled on anything. SSH also supports key-based authentication, which is stronger than a password and easier to automate.

GUI (Graphical user interface) — a web interface or management application. Easier for occasional tasks and for visualising state, and usually slower for bulk work. Ensure it is HTTPS: plenty of equipment still offers plain HTTP management, which is Telnet's problem wearing a nicer face.

API access lets software configure the device — REST or NETCONF, returning structured data. This is what makes the automation and infrastructure-as-code from domain 1 possible: a script can read state and apply configuration without pretending to be a human at a terminal.

Console is the physical serial port on the device. It needs a cable and physical presence — or a console server — and it is the only method that works when the device has no working network configuration at all.

That last property is what makes it indispensable: console access is how you recover a device whose management IP is wrong, whose VLAN is misconfigured, or which has just been factory reset. It is also why console ports are a physical security concern, since anyone who can reach one can usually perform password recovery.

Jump box

A jump box (or jump host, or bastion host) is a hardened intermediate system. Administrators connect to it first, then from it to the target devices. Management protocols are permitted only from the jump box, not from the general network.

Why it is worth the inconvenience:

• One entry point to secure. Hardening, patching and multifactor authentication are applied in one place instead of on every device.
• One place to audit. All administrative access passes through it, so session logging and recording are centralised.
• A much smaller attack surface. A compromised workstation cannot reach management interfaces directly, because the firewall only permits them from the jump box.

The obvious risk is that it becomes a single point of both failure and compromise, which is why jump boxes are hardened aggressively, monitored closely, and usually deployed in pairs.

In-band versus out-of-band management

The most important distinction in this objective.

In-band management uses the production network to manage the devices. You SSH to a switch across the same network that carries user traffic.

• Nothing extra to build, and it costs nothing.
• It fails exactly when you need it. If the network is down, your route to the equipment is down with it. And a configuration change that breaks connectivity cuts off the session making the change — the classic way to strand yourself, which usually ends in a long drive.

Out-of-band (OOB) management uses a separate path that does not depend on the production network. Implementations include a dedicated management network on separate switches, dedicated management ports on each device, console servers reached over that network, and a cellular modem or separate broadband line for the management network itself.

• It works when the production network does not, which is the entire point.
• It survives your own mistakes: push a bad ACL, lose in-band access, fix it over OOB.
• It keeps management traffic off the user network and reduces the attack surface, since management interfaces are not reachable from where users are.
• It costs money — extra hardware, extra cabling, a second circuit.

The exam scenario is always the same shape: a remote site, a change that could break connectivity, or a failure that has already cut off access. The answer is out-of-band management, and the reason given is that it does not depend on the network being managed.

The practical rule worth carrying out of this lesson: never make a change that could break your only path to the device without a second way in. Out-of-band access is that second way. Where it does not exist, a scheduled automatic rollback — the device reverting if you do not confirm within ten minutes — is the poor relation that has saved a great many careers.