Thomas Eizinger

https://github.com/firezone/firezone/pull/6427 paves the way for doing this. We now just need to add the routes to that as well.

Here is my suggestion for how to implement this: 1. We merge #6403 ASAP. 2. We introduce a successor message to `prepare_connection` that in addition to `resource_id` and `connected_gateways` also...

> Is there any reason why client can't generate ICE creds and send them over in connection intent and eliminate an async process of distributing them from the portal? If...

> @thomaseizinger what if, to eliminate 2nd roundtrip, the portal will figure out if tunnel can be reused? You already send `connected_gateway_ids` so if I select one of the gateways...

Thanks for drafting up more ideas. How does the above solution support sending multiple concurrent `connect`s for different resource IDs where some of them may get routed via the same...

I wonder if we can find a different name from `setup_connection`? We could treat it as a "connection to a resource" but it is still kind of an overloaded term,...

> Should we call it `setup_flow` maybe? Or something that implies the upsert behaviour? Maybe `upsert_flow`? Also, on the client, it will just be the "response" to `connect`, right? And...

> @thomaseizinger renamed, lmk if you want to change more - I'm don't have any strong opinions about naming there LGTM, thank you

@AndrewDryga While implementing this, I noticed a subtlety that I wanted to spell out explicitly: When the ICE credentials are generated, it is important that they are unique to this...

@conectado @AndrewDryga I discovered something: Currently, when we receive an `allow_access` request, we always check that the specific domain is actually a sub-domain of the resource domain. With the above...