Multi-hop sessions

Most organizations want to provide access to infrastructure without exposing private networks. Many organizations also have complex network topologies requiring inbound traffic to route through multiple network enclaves to reach the target system. Multi-hop sessions allow you to chain together two or more workers across multiple networks to form reverse proxy connections between the user and the target, even in complex networks with strict outbound-only policies.

In multi-hop scenarios, there are typically three types of workers:

1. Ingress worker - An ingress worker is a worker that is accessible by the client. The client initiates the connection to the ingress worker.
2. Intermediary worker - An optional intermediary worker sits between ingress and egress workers as part of a multi-hop chain. There can be multiple intermediary workers as part of a multi-hop chain.
3. Egress worker - An egress worker is a worker that can access the target. The egress worker initiates reverse proxy connections to intermediary or ingress workers.

After the persistent connection chain is established between the workers, when you attempt to connect to a target host, you are automatically proxied from:

1. Boundary client to ingress worker
2. Ingress worker to intermediary worker, where applicable
3. Ingress worker to egress worker
4. Egress worker to desired target

Multi-hop worker capabilities

Multi-hop capabilities, including multi-hop sessions and Vault private access, is when a session or Vault credential request goes through more than one worker. To enable this, two or more workers must be connected to each other in some configuration. There are no limits on the number of workers allowed in a multi-hop session configuration.

It helps to think of “upstream” and “downstream” nodes in the context of multi-hop. If you view controllers as the “top” node of a multi-hop chain, any worker connected to a node is "downstream" of that node; the node that any particular worker connects to (whether another worker or a controller) is the "upstream" of that node. For example, in the diagram below, Worker 2’s upstream is Worker 1, and its downstream is Worker 3.

You can deploy multi-hop workers in scenarios where inbound network traffic is not allowed. A worker in a private network can send outbound communication to its upstream worker, and create a reverse proxy to establish a session.

You can configure target worker filters with multi-hop workers to allow for fine-grained control on which workers handle ingress and egress for session traffic to a target. Ingress worker filters determine which workers you connect with to initiate a session, and egress worker filters determine which workers are used to access targets.

Multi-hop worker requirements

When you configure multi-hop sessions, there is an "ingress" worker, an "egress" worker, and any number of intermediary workers. Ingress, egress, and intermediary workers have the following requirements.

Ingress worker requirements

To proxy target connections, ingress workers require outbound access to the Boundary control plane and inbound access from clients.

Intermediary worker requirements

Intermediary workers require outbound access to an upstream worker. The upstream worker may be an ingress worker or another intermediary worker. Intermediary workers also require inbound access from a downstream worker. The downstream worker may be an egress worker or another intermediary worker.

Egress worker requirements

To proxy target connections, egress workers require outbound access to an upstream worker and outbound access to the destination host or service.

Complete worker configuration

For the full set of worker parameters and a complete configuration example, refer to the worker stanza documentation.