How does a hosted browser reach an internal site that has no public address?
answer
- reachability is arranged, not inherent
- the dial goes the other way
- a process inside, reaching out
- egress permission, not an inbound rule
- the relay requests from where it sits
basics
~20 sA relay process inside your own network opens an outbound connection to the provider and holds it open; the rented browser's requests for internal names travel back down that connection, so no inbound firewall opening is needed.
solid answer
~50 sAn internal-only site has no address the provider's network can route to and no name its resolvers can answer, so the reach is arranged from your side rather than theirs. You run a relay process on a machine that can already reach the site, and that process **dials out** to the provider and keeps the connection open. Because the connection was established outbound, it crosses your egress policy instead of needing an inbound rule or a published record. The rented browser then hands requests for your internal names to that held-open connection rather than resolving and connecting itself; the relay performs the request from inside, where the name means something, and passes the response back. The direction of the *dial* is the opposite of the direction the *traffic* later flows, and that inversion is the whole mechanism.
go deeper
Know the one-line shape: a helper you run inside your network connects out to the provider, and the rented browser's requests for internal addresses come back through it. Be able to say why publishing the site instead would be the wrong fix.
Be ready to trace a request end to end and say which machine performs it. Explain why the connection direction is the opposite of the traffic direction, and what permission that swaps an inbound firewall rule for.
Expect to be asked what the arrangement actually exposes. Talk about the relay's host as the real boundary, about established connections carrying traffic both ways, and about failures that look like application bugs because the provider reports no error.
Be ready to state what you would require before allowing this at all: where such a relay may run, what it may reach, who owns it, and what evidence you would want that the path is gone when it should be.
## Why an internal-only target is unreachable by default A hosted browser provider runs browsers on machines it owns, attached to networks it operates. When your suite tells one of those browsers to open an insurer's internal claims-adjuster tool, the browser behaves exactly as any browser does: it asks its own resolver for the hostname, then tries to connect to whatever address comes back. Both steps fail for an internal application. The name is published only by resolvers sitting inside your network, so the provider's resolver has nothing to return. And even where a name does resolve, the address behind it is usually not routable from outside, and your perimeter would drop the attempt in any case. The instinctive fix is to make the target reachable from outside: publish a record, open a port, allow the provider's address ranges inbound. That inverts the posture of an internal tool for the sake of a test run, and it leaves you maintaining somebody else's address ranges in your firewall indefinitely. The tunnel agent model exists so that you do not have to. ## The relay, and the direction of the dial Rather than making your network reachable, you put a process inside it and let that process reach out. - The relay runs on a machine that **already** has the access you want the rented browser to borrow: it resolves your internal names with your resolvers and routes to your internal addresses. - It opens a connection **outbound**, to the provider, and holds that connection open. - The provider associates the held-open connection with sessions started under your account. - When a rented browser needs the claims-adjuster hostname, the request is carried down that existing connection instead of being attempted from the provider's network. - The relay performs the request from where it sits — inside — and returns the response up the same connection. That inversion is what the word *reverse* denotes in "reverse tunnel": **the connection is established in the opposite direction to the traffic that later flows across it.** Nothing dials in. The permission that makes the arrangement work is an egress permission for a process you run, not an ingress rule for a network you do not. ## What the direction buys, and what it does not | arranged on your side | the alternative it replaces | |---|---| | an egress permission for a process you run | an inbound rule for foreign address ranges | | a hostname that stays unpublished | a public record for an internal service | | a path that exists while the relay runs | a perimeter opening that persists until removed | What the direction does **not** buy is one-way traffic. Once a connection is established it carries bytes both ways, which is precisely what makes it useful here. So the honest claim is not "nothing can reach in". It is that what can reach in is bounded by two things a tenant can actually observe and control: what the relay is willing to perform on the far side's behalf, and the network vantage point of the machine the relay runs on. Anything past that — how the provider's end is built, what it records, how long it holds a connection — is not something to take from a product description. It is something to establish. ## How its absence presents Because the reach is arranged rather than inherent, losing it looks like an application problem rather than a plumbing problem: - A suite whose relay never started sees connection or name-resolution failures reported from inside the browser, not an error from the provider. Session creation succeeds and the navigation is what fails, a confusing pair of symptoms. - A relay on the wrong machine produces a browser that reaches some internal names and not others, because a relay can only lend the reachability its own host already has. - A relay that stops while sessions are live turns a working suite red from that moment on, with nothing in the test output naming the cause. The practical consequence for a harness is to check the path deliberately rather than infer it: have the suite open the target early and fail with a message that names the relay as a suspect, so a whole red run is not read as a regression in the claims-adjuster tool. ## Misreadings worth correcting - **"It is a VPN for the browser."** The arrangement is narrower and more specific than joining a network: it relays requests, and the rented browser does not acquire an address on your network. - **"The browser is inside my network now."** The browser is exactly where it always was, on the provider's machines. Only the requests it makes for your names take the detour. - **"Outbound means no exposure."** It means no inbound rule. A path still exists while the relay runs, and it is as wide as the relay's own host. - **"The provider needs my firewall opened."** In this model it needs the opposite: your machine has to be allowed out. Providers of this kind — BrowserStack, Sauce Labs and LambdaTest among them — are the subject here, and no program name, option or address belonging to any of them appears above, because no artefact exists against which such a claim could be checked. The mechanism is fully teachable without one.
- If the connection is opened outbound, why is this still worth a security review?Because an established connection carries traffic both ways. The relay lends the rented browser whatever its own host can resolve and route to, for as long as it runs. The review question is not whether an inbound rule exists — it is how wide the relay's vantage point is, and who can cause requests to be sent down it.
- Your relay is running and the session starts, but the claims-adjuster page fails to load. Where do you look?At what the relay's host can reach, not at the provider. Confirm from that machine that the hostname resolves and the service answers. A relay cannot lend access its own host does not have, so a target reachable from your laptop but not from the relay's host fails exactly this way.
- Does the rented browser get an address on your network?No. Requests are relayed on its behalf; the browser stays on the provider's machines with the provider's addressing. That is why internal services see the connection as coming from the relay's host rather than from anything recognisably foreign, and why any allowlisting on the target must name the relay's host.
saying these in an interview costs you the question
- Thinks the provider dials into your network
- Says an inbound firewall rule is required
- Calls it a VPN that joins the browser to your LAN
- Assumes outbound means no exposure at all
- Believes the relay can reach names its host cannot
- Expects session creation to fail when the relay is down