Gateways and bastions

This is an Early Access feature. To enable it, contact Okta Support.

Gateways are inserted at project ingress when you connect using SSH to a server on a project that has gateways enabled. To ensure that any combination of gateways and bastions that you use match your networking requirements, it's useful to understand the connection ordering behavior between gateways and bastions. For example, you might have a situation where you have a single network bastion that you can't use as a gateway.

There are three general possibilities when using gateways and bastions:

Gateways without bastions

In this basic scenario, a gateway is always traversed before connecting to a server on a project where gateways are enabled.

Gateways with bastions configured in Advanced Server Access

The following situations may occur when you specify the Bastion option in a server's server agent configuration. See Configure and use the Advanced Server Access server agent. These servers are considered to be bastions managed by Advanced Server Access since they are not specified manually by users from the command line.

Server and bastion are on the same project that requires a gateway

If the server and bastion both belong to the same project that requires a gateway, then the gateway is inserted prior to the bastion. The client connects to the gateway, then the bastion, and then to the target server.

Server and bastion are on different projects

Server project requires a gateway, bastion project does not

The gateway is inserted between the bastion and the target server. The client connects to the bastion, then the gateway, and then to the target server.

Server project does not require a gateway, bastion project does

The gateway is inserted prior to the bastion. The client connects to the gateway, then the bastion, and then to the target server.

Server and bastion projects both require gateways

Gateways are inserted both before the bastion and before the server. For example, if the gateway selector for the bastion project matches gateway A and the gateway selector for the server’s project matches gateway B, then the client connects to gateway A, then the bastion, then gateway B, and then to the target server. In this example, only gateway B records the session.

Note: Gateway A and B can be the same gateway. This can result in a cycle, if the gateway selectors for both projects allow it. This isn't harmful, but it's recommended that projects are configured appropriately to avoid unnecessary network hops.

Gateways with bastions configured using the command line

In addition to bastions that are automatically used by properly configuring the Advanced Server Access server agent, clients can specify bastions to use by using the --via or --bastion flags with the Advanced Server Access client. See Use the Advanced Server Access client.

The behavior of bastions configured using the command line flags is the same as that for bastions that are configured in Advanced Server Access. Bastions specified using the command line are always added before bastions that were configured through their server agent configuration. For example, suppose you have BastionA, a bastion specified using the command line, and BastionB, a bastion specified through its server agent configuration. If you attempt to reach a target through both bastions, then the connection would go from the client to BastionA, then BastionB, and then to the target server. Depending on the project configuration, gateways would be inserted at project ingress.

Related topics

Install an Advanced Server Access gateway

Advantages of Advanced Server Access gateways

Session capture