Bryan

Curious…

I just found that we can connect if we

online-mode=false

allow-list=false

Current findings
Investigation of the PS4-to-Bedrock Dedicated Server connection shows that LAN discovery is working correctly, but the subsequent NetherNet connection does not complete.
The PS4 sends UDP discovery traffic to broadcast address  192.168.100.255:7551 . The server receives this traffic and responds directly to the PS4 on  192.168.100.124:7551 , confirming that discovery, Layer 2 connectivity, IP addressing, and UDP/7551 communication are working.[Attachment]
The PS4 then establishes bidirectional UDP traffic with the server on UDP/19132. Both directions exchange packets with changing encrypted payloads and advancing per-direction sequence values, rather than repeated retransmissions or one-way traffic. This indicates that the NetherNet transport handshake is progressing beyond simple discovery.[Attachment]
However, the connection never reaches the point where the game client successfully joins the world. The remaining failure therefore appears to be at the NetherNet session/application stage, potentially involving ICE candidate selection, endpoint advertisement, authentication/session state, or a required connection message that is not being accepted or completed.
What has been ruled out
The evidence currently rules out, or makes highly unlikely, the following causes:
• Basic network connectivity: The PS4 and server exchange traffic in both directions.
• Incorrect IP configuration: The PS4 is communicating with the expected server address,  192.168.100.13 , on the local  192.168.100.0/24  network.
• LAN discovery failure: UDP/7551 broadcast requests reach the server and receive direct replies.[Attachment]
• UDP/19132 being completely blocked: The server and PS4 exchange sustained bidirectional traffic on UDP/19132.[Attachment]
• A Linux host firewall silently dropping all relevant traffic: Server replies are visible on the wire, and the PS4 continues responding.
• Packet loss at the capture host: The tcpdump capture reported packets received by the filter with zero packets dropped by the kernel.[Attachment]
• A simple ESXi virtual-switch or vNIC connectivity problem: The server’s physical/virtual network path is passing broadcast discovery and bidirectional UDP traffic. Nothing observed so far indicates that ESXi is preventing the relevant packets from traversing the network.
• A basic NAT issue for this LAN test: The PS4 and server are on the same private LAN, and the observed exchange does not depend on Internet NAT traversal.
These findings do not prove that ESXi, the virtual switch, or firewall configuration can never affect the final session. They do show that they are not preventing the initial discovery or the visible UDP/19132 exchange.
Relevant external evidence
A related Bedrock Dedicated Server report describes the same general symptom: the server is visible but the client times out when NetherNet is enabled. The report identifies connection behavior involving UDP transport endpoints and ICE candidate handling, rather than a basic server-visibility problem.[Attachment]
That report also documents different behavior depending on the  server-udp-ports  configuration, including cases where the transport socket is allocated but no  Player connected  event occurs. This is consistent with the current capture: the transport exchange is present, but the session does not complete.[Attachment]
Current working theory
The strongest current theory is a Bedrock NetherNet connection/session bug or incompatibility, rather than a general ESXi, LAN, firewall, or UDP-port failure.
The packet capture demonstrates that the PS4 discovers the server and exchanges structured NetherNet traffic with it, but the game session does not transition to a connected/spawned state. The next investigation should focus on server logs and the exact NetherNet/ICE state after the UDP/19132 exchange, including whether the server logs transport allocation without subsequently logging  Player connected .

bedrock-server-1.26.52.3.zip

ps4 minecraft 3.5

BDS 1.26.52.3 + PS4 client

online-mode=false, allow-list=false:
Player connected
Player PartyIdUpdate
Player Spawned

online-mode=true, allow-list=false:
PS4 reports Boat / InitialConnection-145

online-mode=true, allow-list=true:
allowlist.json contains soulrider2k
PS4 still reports Boat / InitialConnection-145

online-mode=false, allow-list=true:
BDS exits with:
"Using an allowlist without online authentication can be dangerous
and is not allowed."

Therefore the failure is correlated with online-mode authentication,
not allow-list authorization.

If authenticated NetherNet is now a thing, maybe Mojang are prepping for internet p2p connectivity. nethernet, like the nether in the game, is a portal.

Update: retested with BDS 1.26.52.3 (Build ID 51798919, commit
54116bb5ee0b7aee0b5591efbcc8bc3cf64f168a) and PS4 Minecraft
1.26.52-playstation_4 after the PS4 app update to 3.50.

The issue remains reproducible here. The PS4 reports:

Error Detail: InitialConnection-145
Transport: NetherNet:2193
NetworkType: 1
Client: Sony,C,PS4,-Orbis

BDS starts normally and reports:

Version: 1.26.52.3
Signed in to signaling service successfully
Server started.
Accepting clients on [::]:19132

During the failed PS4 attempt, tcpdump shows:

192.168.100.124:64329 > 192.168.100.255:19132 UDP, length 33
(repeated approximately once per second)

192.168.100.124:7551 > 192.168.100.255:7551 UDP, length 64
192.168.100.13:7551 > 192.168.100.124:7551 UDP, length 192
(repeated approximately every two seconds)

The server therefore responds to the NetherNet discovery request on UDP
7551.

However, during the same attempt:

• No response is sent to the UDP 19132 LAN discovery packets.

• No TCP 19132 connection is observed.

• No additional per-session UDP socket is allocated.

• BDS logs no Player connected, Player PartyIdUpdate, or Player Spawned event.

• The client still displays Boat / InitialConnection-145.

At this point, NetherNet discovery on UDP 7551 appears to work in
1.26.52.3, but the PS4 does not proceed to TCP signaling or session
transport after receiving the discovery response. Normal UDP 19132 LAN
discovery remains unanswered.

This reproduces on a directly connected LAN with:
PS4: 192.168.100.124
BDS: 192.168.100.13

Our PS4 has just updated to 3.50, and our BDS is a new, un-altered bedrock-server-1.26.52.3.zip.

I can reproduce this on a direct local LAN with a PlayStation 4, without NAT, port forwarding, or an Internet path.

Environment:

• BDS 1.26.51.1

• Ubuntu Linux VM

• Server IP: 192.168.100.13

• PS4 IP: 192.168.100.124

• Same subnet: 192.168.100.0/24

• PS4 client: 1.26.51-playstation_4

• PS4 update/version: 3.49

• server.properties: transport=nethernet

• Vanilla world, no packs

• Ubuntu UFW inactive

The PS4 reports:

• Error: InitialConnection-145

• Transport: NetherNet:2193

• NetworkType: 1

• WorldName: Bedrock level

Packet capture during one failed join:

• 17 PS4 NetherNet discovery requests:
  192.168.100.124:7551 -> 192.168.100.255:7551

• 17 BDS responses:
  192.168.100.13:7551 -> 192.168.100.124:7551

• 21 PS4 RakNet broadcast probes:
  192.168.100.124:61999 -> 192.168.100.255:19132

• No BDS responses on UDP/19132

• No subsequent gameplay/session UDP traffic on any dynamic port

The PS4 therefore discovers the server and receives repeated NetherNet advertisements, but does not establish a gameplay session. The failure occurs on the same LAN, so this is not dependent on public NAT or port forwarding.

This appears related to NetherNet address/candidate selection or LAN session establishment. It may be useful to compare this direct-LAN PS4 result with the existing reports where explicit server-udp-ports mappings change external versus LAN behavior.

I can provide the complete PCAP and the PS4 error screenshot if required.

My old user when I got the texture/add-ons and packs was Balmierfriend76 I recently changed it to just Balmier76

Can I show you that I have a world with the dwellers mod and a video of it in my world. That's all that I have of the mod I can look for recipes to of me buying the starter packs if I find them.

G Real. So I was able to get the world onto my gfs pc since she has bedrock and the world works! Is there anyway for me to get this back onto my Xbox on my account? I dont have minecraft on pc unfortunately.

Having the same issue here. Was happy to find this thread but no luck getting my world to download from the cloud, just getting the cloud sync failed. Version 1.21.10101.0

Hi Pheelster,

I’ve been searching around and found a few references to server-ip online.

If it’s not a current feature (perhaps it’s been removed), then perhaps we consider this a feature request to get it put back in? 🙂

Yes, I’m running this on ESXi, and would like to be able to bundle up multiple Bedrock servers on a single VM. My VM has multiple IP addresses already assigned and responding, so it’s just Bedrock server-ip that’s failing there.