SSH Bastion or Direct VPN Access: Which Policy Applies?

Whether VPN users may reach servers without crossing a jump host is a policy question wearing a networking costume. If the bastion performs a required control, then joining the VPN must lead to it rather than around it. If the jump host merely bridged a segment that used to be unreachable, a narrow direct path can be the honest replacement. Work the checks below in order and stop at the first one that fails, because that answer decides the rest.

Check What the Bastion Actually Controls

Start with evidence about the present, not a diagram from the design document. Look at the target's SSH configuration and packet filter: if inbound port 22 is accepted only from the bastion's address, the jump host is an enforced control. If the same port accepts connections from the whole VPN pool, the bastion was a convenience and the enforcement lives somewhere else entirely. Ticket history usually confirms which of the two existed first.

State the finding as one sentence naming the control the bastion provides: destination restriction, a second authentication step, session recording, or operational visibility during an incident. That sentence is what the replacement policy has to preserve.

Check Whether the Target Can Tell the Paths Apart

Source-address rules only work while the two paths arrive with different source addresses. A VPN gateway that masquerades traffic to the server subnet erases that difference, and then every connection to port 22 appears to come from the gateway. The check is local to the target and takes a moment: list the established SSH sessions and read the peer address for each.

When both paths collapse into one address, the distinction has to be made earlier, by which destinations the VPN is allowed to push and by the gateway's own filters. Adding a rule on the target in that situation creates the illusion of a boundary without changing what arrives.

Check What Each Record Really Holds

Three different logs describe three different events, and none of them substitutes for another. The VPN's connection record shows that an identity entered the network scope. The bastion's forwarding record shows a TCP channel leaving it toward a destination and port. The target's authentication log shows that an account signed in over SSH. Reading them together is what produces a timeline; reading one alone produces a guess.

None of those records contains what happened inside the encrypted session between client and target. If command-level review is a requirement, it needs a deliberately deployed recording mechanism with its own data-handling rules. Expecting it from jump-host logs is how an audit gap stays hidden until it matters.

Check Where the Policy Is Actually Enforced

A client setting such as ProxyJump is a request, not a restriction. OpenSSH will happily open a direct connection when the destination is reachable, so configuration files on laptops describe intent while firewalls decide outcomes. Enforcement belongs at the VPN gateway's permitted destinations and at the target's own access rules, both of which a user cannot edit. Audit the alternative paths at the same time: a second interface, a public listener, a mesh overlay or an older site-to-site tunnel can each restore the shortcut you just closed.

Configure ProxyJump anyway, because it makes the approved route the easy one and stops routine work from generating exceptions. Confirm what the client actually resolves before trusting it.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verify With a Deliberate Direct Attempt

Policy that has never been tested is a hope. From a client attached to the VPN, attempt the path that should now be refused, then attempt the approved one, and keep both results. The refused attempt is the evidence that the change took effect.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

A clean result looks like a refused or timed-out direct connection to the target address, followed by a successful jump-host login and a target-side authentication entry naming the supported source. Anything else means the boundary is still porous, whatever the documentation says. Record the date, the rule that was changed and the two outcomes, then give the recovery path an owner and an expiry so that emergency access does not quietly become the everyday route.