Trouble for remote controlling same LAN PC

[rafoloru]

I found something, I don't know if you have a solution for that, here's my topology:

-- LAN 1
------ Breeze Server

-Internet

-- LAN 2
------ Computer 1
------ Computer 2

-Internet

-- LAN 3
------ Computer 3

I want to remote control from Computer 1 to Computer 2 (in the same LAN) and it can't connect. But, if i try to connect to Computer 3 (different LAN) it work. Same thing if I try from computer 3 to computer 2 it works.

It look like PC's in the same LAN can't remote control each other.

Thanks

[ToddHebebrand]

Thanks for the clear topology, that pattern points at one likely cause.

Most likely cause (inferred, not yet confirmed on your setup): remote desktop is WebRTC. Both ends learn their public address from STUN, and they relay through a TURN server only if one is configured. Across LANs, the two public addresses reach each other normally. Two PCs behind the same router, trying each other's public address, need the router to loop that traffic back inside (NAT hairpinning), and many routers don't. When direct and hairpin both fail and there's no TURN relay, the session has nowhere to go. That matches "same LAN fails, anything cross-LAN works".

What would confirm it:

• Is TURN_HOST (and TURN_SECRET) set in your server .env? If not, that's the missing fallback. Configuring coturn gives every session a relay path. See TURN server.
• Which viewer are you using on Computer 1, the browser or the desktop viewer app?
• In Computer 2's agent log around a failed attempt, look for ICE gathering complete with no relay candidates. That line means no TURN relay was available.

Two peers on the same LAN should normally connect directly over their local addresses, without any TURN, so I'll also check on our side why that path isn't being used.

[rafoloru]

Hello,

Here the informations:

• I have TURN_HOST et TURN_SECRET set in my .env file
• I'm using the desktop viewer
• Here's the log from computer 2 agent:

time=2026-09-29T09:59:33.076-04:00 level=INFO msg="dispatching command" component=websocket commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-3c13b9af-6092-40bc-a4d4-b12b7d02468f commandType=start_desktop
time=2026-09-29T09:59:33.076-04:00 level=INFO msg="processing command" component=heartbeat commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-3c13b9af-6092-40bc-a4d4-b12b7d02468f commandType=start_desktop
time=2026-09-29T09:59:33.076-04:00 level=INFO msg="start_desktop command received" component=heartbeat commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-3c13b9af-6092-40bc-a4d4-b12b7d02468f sessionId=fd87e697-6665-445e-9c69-6dda6e7c1ed8 hasOffer=true isService=true isHeadless=false hasBroker=true
time=2026-09-29T09:59:33.143-04:00 level=INFO msg="findActiveHelper: picked console session directly" component=heartbeat winSession=1 helperSession=helper-e4c5284869f868cb consoleID=1
time=2026-09-29T09:59:34.786-04:00 level=WARN msg="dropping unsolicited or unauthorized helper message" component=sessionbroker type=notify_result sessionId=helper-b5b406e5613deb34 role=user
time=2026-09-29T09:59:48.944-04:00 level=INFO msg="applied monitoring config" component=monitoring watches=0 intervalSeconds=60
time=2026-09-29T09:59:48.944-04:00 level=INFO msg="applied Windows Update source enforcement" component=heartbeat enforce=false managed=false enforced=false reverted=false reason="no Breeze-managed Windows Update suppression to revert; left as-found"
time=2026-09-29T09:59:53.472-04:00 level=INFO msg="dispatching command" component=websocket commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-600d23f7-19d7-473b-bc81-91d88de26af8 commandType=start_desktop
time=2026-09-29T09:59:53.472-04:00 level=INFO msg="processing command" component=heartbeat commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-600d23f7-19d7-473b-bc81-91d88de26af8 commandType=start_desktop
time=2026-09-29T09:59:53.472-04:00 level=INFO msg="start_desktop command received" component=heartbeat commandId=desk-start-fd87e697-6665-445e-9c69-6dda6e7c1ed8-600d23f7-19d7-473b-bc81-91d88de26af8 sessionId=fd87e697-6665-445e-9c69-6dda6e7c1ed8 hasOffer=true isService=true isHeadless=false hasBroker=true
time=2026-09-29T09:59:53.474-04:00 level=INFO msg="findActiveHelper: picked console session directly" component=heartbeat winSession=1 helperSession=helper-e4c5284869f868cb consoleID=1
time=2026-09-29T09:59:54.404-04:00 level=WARN msg="dropping unsolicited or unauthorized helper message" component=sessionbroker type=notify_result sessionId=helper-b5b406e5613deb34 role=user
time=2026-09-29T09:59:55.191-04:00 level=WARN msg="dropping unsolicited or unauthorized helper message" component=sessionbroker type=notify_result sessionId=helper-b5b406e5613deb34 role=user
time=2026-09-29T10:00:14.022-04:00 level=WARN msg="dropping desktop peer disconnect for non-owned session" component=heartbeat sessionId=fd87e697-6665-445e-9c69-6dda6e7c1ed8 helperSession=helper-e4c5284869f868cb
time=2026-09-29T10:00:14.863-04:00 level=WARN msg="dropping unsolicited or unauthorized helper message" component=sessionbroker type=notify_result sessionId=helper-b5b406e5613deb34 role=user
time=2026-09-29T10:00:31.664-04:00 level=WARN msg="network context collection incomplete" component=heartbeat error="unsupported capability\nunsupported capability"

[ToddHebebrand]

Thanks, that's exactly what I needed. Short version: we found a bug on our side that matches your symptom. Please check it first.

Likely cause: the bundled TURN server refused every relay in v0.118.x

Verified in our code (not yet confirmed on your server): Breeze v0.118.0 to v0.118.2 shipped a coturn setting, --denied-peer-ip=::, that coturn reads as "deny every address". In those versions coturn starts and looks healthy, but it refuses to relay any session. This is fixed in v0.119.0 (#7536).

It also fits your pattern (inferred):

• Across LANs, the two PCs reach each other's public address directly, so TURN is never needed. That's why Computer 3 works.
• On the same LAN, the direct path is not available, as explained below. The session needs the TURN relay, and that relay was refusing everything.

Important: this setting is in your docker-compose.yml, not in the Docker images. Changing BREEZE_VERSION and pulling new images does not fix it. Do one of the following:

• Update your docker-compose.yml to the v0.119.0 version, keeping any local changes you made, or
• Delete this single line from the coturn service in your docker-compose.yml (and from docker/turnserver.conf if you use that file):

  - '--denied-peer-ip=::'
  

  Then run docker compose up -d coturn. Don't replace it with 0.0.0.0 or with a range that starts at ::.

Upgrade notes: https://docs.breezermm.com/deploy/upgrades/ (the coturn section).

If it still fails after that, please check these

1. Which Breeze version is your server running? Are you using the bundled coturn (docker compose --profile turn up -d, or COMPOSE_PROFILES=turn in .env) or your own TURN server?

2. Does the API container actually see the values? Run:

   docker compose exec api printenv | grep ^TURN_
   

   TURN_HOST and TURN_SECRET must not be empty. Our compose file passes them through, but the container only picks up .env changes when it is recreated. Use docker compose up -d; docker compose restart is not enough. If either value is empty, the server gives out STUN only and does not report an error.

3. Is coturn running?

   docker compose ps coturn
   docker logs breeze-coturn --tail 50
   

4. Network, because your server is behind a router (LAN 1): coturn uses host networking, so Docker maps no ports for it.

   • TURN_HOST must be the public IP of LAN 1. It cannot be a hostname or an address behind a Cloudflare tunnel.
   • The LAN 1 router must forward these to the Breeze server, and the server's own firewall must allow them:
     • UDP + TCP 3478
     • UDP 49152–65535 (the relay port range)

   See TURN server.

5. The right log file. The log you pasted is from the agent service. On Windows, the remote desktop connection runs in a separate helper process inside the user's session, so the network (ICE) details are in another file on Computer 2:

   C:\ProgramData\Breeze\logs\desktop-helper.log
   

   Around the time of a failed attempt, please paste the lines that contain:

   • ICE server configured. You should see a turn: entry with hasCreds=true. If there is no turn: entry, the agent never received TURN settings.
   • ICE candidate gathered, and especially any with type=relay.
   • ICE gathering complete. If this line says with no relay candidates, Computer 2 could not get a relay from your TURN server.
   • Desktop WebRTC ICE state.

   About the warnings in your service log: dropping desktop peer disconnect … at 10:00:14 fits a connection that gave up about 20 seconds after the second attempt (inferred). The notify_result lines look like unrelated noise.

Optional: test TURN on its own from Computer 1. On the server, in the Breeze folder, generate a temporary login:

set -a; . ./.env; set +a
u="$(( $(date +%s) + 600 )):breeze:test"
printf '%s\n' "$u"
printf '%s' "$u" | openssl dgst -sha1 -hmac "$TURN_SECRET" -binary | base64

Then on Computer 1:

1. Open https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
2. Add turn:<TURN_HOST>:3478?transport=udp, using the first line as the username and the second line as the password.
3. Click Gather candidates. A relay candidate means Computer 1 can reach your TURN server and the secret is correct.

This test does not check the v0.118 bug above, so apply that fix as well.

Why the two PCs don't simply connect over the LAN

This part is inferred, not yet confirmed. Normally they should. Our current guess:

• To protect privacy, the desktop viewer hides its LAN address behind a random .local name, which is standard WebRTC behaviour in Chromium-based views. Computer 2 has to resolve that name with multicast DNS on the local network.
• Windows Firewall on Computer 2 may also block the incoming LAN packets.

If both of those happen, the only paths left are your router looping traffic back (hairpin) or the TURN relay. We'll look at making the direct LAN path more reliable on our side. Until then, a working TURN relay covers this case.

Status: likely fixed by v0.119.0's compose change. Waiting on your version, and on desktop-helper.log if it still fails.