[jefferai]

By "direct network access" we mean between the client and the end host. The Boundary worker node (which proxies traffic) would need to be able to make a network connection to the end host, and the client in turn would need to be able to make a network connection to the worker node.

This indirection provides a way to keep your public and private (or even private and private) networks distinct to remove "being on the same network" as a sufficient credential for access. At the same time, it ensures that the traffic is only proxied if that particular session is authenticated.

[A_No_Name_Mouse]

I can see how that works for an internal network. How does this work for SaaS solutions that would normally be directly on the internet? Would they have to be "shielded" to be on a private network and somehow be "Boundary enabled"?

And could this be done in a way that is completely transparent to the user (without them having to start a connection to the worker first, and then make a connection to the desired service)?

[jefferai]

Generally speaking this is designed for accessing your own systems, not the systems of a third party being consumed as a SaaS. That said, any such provider that allows you to restrict the set of IPs allowed to make calls to the service would operate in a Boundary-friendly mode.