Okay, so I’m in the middle of testing Boundary for some secure access use cases, comparing its session handling to how other platforms manage credential injection. But I’ve hit a wall with debugging.
I set up a worker, a target, and a host set. When a user connects via `boundary connect`, sometimes the connection just fails immediately—like, it times out or says “connection refused.” The weird part? The worker logs show absolutely nothing. No errors, no events, just… silence. The controller logs have the session creation and authorization, but the worker seems to be skipping the actual connection attempt entirely.
Here’s what I’ve checked:
- Worker config file has `observations` and `audit` logging set to `"info"`.
- Worker is definitely registered and shows as active in `boundary workers list`.
- The target’s network address is reachable from the worker node (tested with netcat).
- No firewall rules blocking the ephemeral port range on the worker.
Has anyone else run into this? I’m used to platforms like Salesforce or HubSpot having super verbose connection logs, so this is throwing me. Is there a hidden debug setting for the worker’s proxy layer, or maybe a specific event stream I should be tailing?
For context, my setup is pretty standard: Boundary v0.15 in a dev environment, worker on a separate Linux VM.
Still looking for the perfect one
The worker logs often stay silent on pure network failures because they happen downstream of the session handoff. The session is authorized, but the actual TCP proxy attempt to your target can fail without hitting the worker's structured logging.
You need to check the worker's stderr output or system journal, not just the configured log files. The proxy layer errors often dump there, especially on immediate "connection refused." Run the worker with `BOUNDARY_LOG_LEVEL=debug` in its environment and watch the console. Also verify the worker's advertised address is correct and the controller can route to it.
—AF
That's an accurate description of the silent failure mode. The crux is, if the proxy can't establish a socket, it often fails before it can even log a structured event to the configured file.
But "check the worker's stderr" assumes a direct invocation. In a production deployment where it's run as a systemd service, this advice just moves the black box. The journal will likely have the same nothing unless the logging configuration explicitly routes *all* output there, which it often doesn't.
So the real problem is the telemetry gap between the proxy's network stack and the worker's log sink. It's a design choice that makes debugging a pain.
—EB