Configuration around having one ingress worker & 2 egress workers

Hi Brain Trust,
I have one ingress worker and two egress workers

(ingress worker>1st egress worker>2nd egress worker>Target Resource)

so ingress worker will have "initial_upstreams=“Boundary controller IP” and tagged with “upstream” and then 1st egress work will have initial_upstreams=“Ingress worker IP” and tagged with “downstream or upstream” and then 2nd egress worker will have initial_upstreams=“1st egress worker IP” and tagged with “downstream”

Also, do 1st and 2nd egress workers has to authenticate with boundary controller or ingress worker? (I am taking about KMS “aead” section for worker-auth). I believe Ingress worker will have worker-auth from controller and how about 1st and 2nd egress worker, would these workers have same worker-auth under kms “aead”

can someone please help me with the above scenario.

For your workers, the “1st egress worker” doesn’t necessarily need tags. If your target has an ingress filter set to match the “upstream” tag, and an egress filter to match the “downstream” tag, the controller will generate a route from ingress to egress that passes through your “1st egress worker”. If it’s helpful, we have a tutorial on multi-hop workers here: Manage multi-hop sessions with HCP Boundary | Boundary | HashiCorp Developer

Downstream workers authenticate to controllers; some more details on that flow is here:

in my case, there is only one egress worker (2rd egress worker) which will be connecting to the target, and 1st egress worker just proxying the connection from ingress worker and passing to 2nd egress worker. Is this relevant to have 1st egress worker in the middle between ingress worker and 2nd egress worker.
i have attached file showing all these workers flow and i hope it makes sense what I am trying to achieve here.
I am trying to achieve multi-hop session across various networks.
on side note, how these worker will authenticate using kms “aead”. how do i setup as per attached setup.
many thanks

The flow makes sense, though worker tags must be all lowercase (“Downstream” is invalid on 1st Egress Worker). If this is changed to “downstream”, then it will match the target egress filter you’re planning, so you might want to use a different tag value for the 1st egress worker if your intention is for only the 2nd egress worker to connect to the target.

To authenticate multi-hop workers with KMS, you’ll need to add KMS blocks to the worker and controller configs for this purpose. There are two options; you can either use a KMS block with the purpose of “worker-auth” in the worker and the controller configs, or you can use a KMS block with the purpose “downstream-worker-auth” in the config files of the workers you want to connect to each other.
Both of these KMS authentication approaches are explained here with examples: Worker configuration | Boundary | HashiCorp Developer

Thank you for this info, Sorry, I just want to show you the worker setup and flow, forgot about syntax or case sensitivity around tags. I will use different tag for 1st egress worker. how about initial_upstream values, are they looking fine to you as per the previous attachment. so basically, Ingress worker talk to boundary controller then 1st egress worker talk to ingress worker and then 2nd egress worker talk to 1st egress worker. it is basically proxy the sessions all the way to target via these workers initiated by client.

In case of authentication of workers, do worker has to authenticate with each other or with boundary controller. as per above diagram: Ingress worker will have “kms aead: worker-auth” extracted from controller hcl file, would 1st and 2nd egress worker will have same “kms aead worker-auth”.

Thanks for sharing your setup! It seems well-structured. Regarding authentication, typically, each worker would authenticate separately. In this case, both the 1st and 2nd egress workers would authenticate with the boundary controller or the Vpro Apk ingress worker directly. However, for clarity and security, it’s best to check your specific configuration and consult any relevant documentation.