Tavis Delahunt

Follow-up with additional controlled testing on BDS 1.26.51.1 (Linux, build 51061372).

I was able to reproduce a very clear difference in behavior based only on the server-udp-ports setting.

Server:

• Ubuntu Linux BDS 1.26.51.1

• Build 51061372

• transport=nethernet

• Server is behind IPv4 NAT

• Existing router NAT forwards public UDP/TCP 19132 to the BDS host on port 19132

• No router/firewall changes were made during these tests

With no server-udp-ports setting:

• An Xbox on the same LAN was eventually able to connect successfully.

• A Windows client over a VPN into the server LAN connected successfully.

• Direct Internet connections failed.

• A remote external client reached the new server trust prompt, and BDS allocated its UDP transport socket, but no Player connected event was logged and the client ultimately failed with Door.

I then added exactly one setting:

server-udp-ports=<PUBLIC_IPV4>:19132:19132

No router/firewall/NAT settings were changed.

After restarting BDS, the same remote external player successfully connected and spawned in the world. BDS logged the normal Player connected, Player PartyIdUpdate, and Player Spawned sequence.

This is a clean A/B result showing that explicitly publishing the public IPv4/UDP mapping fixed external connectivity in this NAT environment.

However, with that explicit public mapping configured, the Xbox on the same LAN could no longer join. It remains at "Connecting to multiplayer world."

During the failed LAN attempt, BDS does allocate its UDP transport socket, but the connection never progresses to a Player connected event.

Current observed behavior is therefore:

• No explicit server-udp-ports: LAN works, Internet fails

• Explicit <PUBLIC_IPV4>:19132:19132: Internet works, LAN fails

The external player was disconnected before retesting the Xbox, so the LAN failure persisted with no other player connected.

This appears related to NetherNet connection/ICE candidate handling rather than the normal Bedrock player session, because both failed cases reach the point where BDS creates its UDP transport endpoint but never reach Player connected.

I have retained both configurations and can perform additional controlled testing if useful.

I can reproduce this on the official Linux BDS 1.26.51.1 (Build ID 51061372) on Ubuntu after upgrading from 1.26.45.1.

I have some additional diagnostics that may be useful. My BDS is behind IPv4 NAT and currently has transport=nethernet; server-udp-ports is not explicitly configured.

Using the exact same Minecraft for Windows 1.26.51 client/account:

• Connecting through a VPN into the BDS LAN succeeds consistently.

• Connecting directly from the same remote network without the VPN fails with InitialConnection-83 / Door (Transport: NetherNet:2193).

• A successful connection immediately produces Player connected, Player PartyIdUpdate, and Player Spawned in the BDS console.

• A failed InitialConnection-83 attempt produces absolutely no event in the BDS console.

I also monitored the BDS sockets. At idle it has TCP *:19132 and UDP *:7551. During a successful NetherNet connection, an additional UDP socket appears on the server's LAN address at 192.168.0.128:19132. That UDP socket disappears again when the player disconnects.

There is also an Xbox running 1.26.51 on the same LAN. It automatically discovers the BDS and correct world, but joining fails with InitialConnection-145 (Transport: NetherNet:2193).

I temporarily tested transport=raknet. In my environment the Xbox then stopped discovering the BDS entirely, so I restored transport=nethernet.

The BDS itself starts normally and reports Signed in to signaling service successfully followed by Server started.

@guregoro's findings regarding explicit public IPv4 mappings in server-udp-ports are particularly interesting given the VPN/direct comparison above. I have intentionally not configured server-udp-ports yet so I could preserve the failing configuration while diagnosing it.