Transport type "nethernet" renders server inaccessible

I can reproduce a related issue on BDS 1.26.51.1 with transport=nethernet.

Behind IPv4 NAT, external connections only work reliably when I explicitly specify the public IPv4 address in server-udp-ports.

Also:

• With only one UDP mapping, only the first distinct client can connect. The same client can reconnect repeatedly, but another client cannot connect until BDS is restarted.

• Multiple clients can connect if I list several UDP mappings individually, for example:
  server-udp-ports=<PUBLIC_IP>:55000:55000,<PUBLIC_IP>:55001:55001,...

• The documented range syntax, for example:
  server-udp-ports=<PUBLIC_IP>:55000-55019:55000-55019
  does not work for me.

The router/firewall configuration is unchanged between these tests, and packet captures confirm that UDP traffic reaches the BDS host.

I also have this issue running BDS on Ubuntu. When I try to go back to RakNet either via changing the transport or going back to my older server.properties file I receive the following message and no one can connect.
[2026-09-17 09:19:25:018 ERROR] ================ TRANSPORT TYPE ERROR ===================
[2026-09-17 09:19:25:018 ERROR] Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported transport type.
[2026-09-17 09:19:25:018 ERROR] Players will not be able to connect to your game without NetherNet.
[2026-09-17 09:19:25:018 ERROR]
[2026-09-17 09:19:25:018 ERROR] To switch, set 'transport=nethernet' in server.properties.
[2026-09-17 09:19:25:018 ERROR]
[2026-09-17 09:19:25:018 ERROR] For more information, please reference the included bedrock_server_how_to.html file.
[2026-09-17 09:19:25:018 ERROR] =======================================================

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.

I actually accidentally fixed the issue
I just removed the transport=, server-udp-ports= and server-ip= in the server.properties
All my players appear to have normal connection

though the console say

[2026-09-18 13:26:01:048 ERROR] ================ TRANSPORT TYPE ERROR ===================
[2026-09-18 13:26:01:048 ERROR] Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported transport type.
[2026-09-18 13:26:01:048 ERROR] Players will not be able to connect to your game without NetherNet.
[2026-09-18 13:26:01:048 ERROR]
[2026-09-18 13:26:01:048 ERROR] To switch, set 'transport=nethernet' in server.properties.
[2026-09-18 13:26:01:048 ERROR]
[2026-09-18 13:26:01:048 ERROR] For more information, please reference the included bedrock_server_how_to.html file.

I also tested on some Minecraft server status website, including websites that fetching the server player numbers, and it seems all went back to normal.

Both server-* were commented out, so I commented out the transport= part. No go on mine. Note that I do have online-mode true because my players use their XBox accounts to connect to the world. As of right now, no one can play in this world.

Did you set enable-lan-visibility=true? In the first few attempts in the previous versions, I found that must having this setting for players to connect

my current setting:
online-mode=true
allow-list=true
server-port=19132
server-portv6=19133
enable-lan-visibility=true

@Cedric Watsons, to clarify, you didn’t fix the issue, you just are now using Raknet as the transport protocol, which still works, but throws the errors you posted, as well as were posted before.

@Cedric Watsons, those settings are the exact same.

If I try to use Raknet, it doesn’t work either, get the warning on the console, and clients get same “boat” error.

Had the same issue. Bedrock server running in Ubuntu, mostly used on internal LAN via discovery. After updating I first got :

ERROR] Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported transport type.

Changed it in settings and tried to connect and immediately got error code boat with InitialConnection-145 (Transport: NetherNet:2193).

Then tried to connect by adding the server manually to the server tab with internal IP, got some prompts about trust etc - but it worked. Right after I was able to join via LAN discovery as well - so no idea on why it was failing but working now

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.

So that is a good workaround. When I added the server IP manually and connected it did work. After successfully connection now connecting via LAN discovery also works. Very strange bug.

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.

Thanks, I fixed my connectivity issues by switching to raknet. I have only managed to once connect to my server with Nethernet and IPV6, which is required for my network. I’m running Ubuntu. I’m also not interested in doing more testing with this, I spend hours debugging the connectivity issues on each new BDS update (:

It was working on LAN with Nethernet, but I suspect that was over IPv4

I dont understand how you are able to connect by switching to raknet?

When using raknet i can connect from devices connected to my local network, however when using a vpn/using devices from outside my network it gives me either the “nethernet” error, or the “door” error.

Yeah, if removed and added manually o through add to my servers button on aternos it works again.

I've got a working setup now and figured out what's actually going on. There are two things here, and the second one corrects something I had backwards earlier.

1. Neither peer advertises a routable candidate.

Setup: BDS 1.26.51.1 on Ubuntu, single interface at 192.168.50.221, IPv4 only, behind home NAT. transport=nethernet.

Signaling is plaintext HTTP, so you can read the SDP with tcpdump. An external client's offer contains exactly one candidate, its own private LAN address:

c=IN IP4 192.168.1.169
a=candidate:... 192.168.1.169 54222 typ host ...

The server's answer does the same thing with its private address. No server reflexive candidate on either side, so the server sends STUN checks to an address it can't reach and the client does the same. Nothing pairs and you get Door / InitialConnection-83.

I put a small HTTP proxy in front of the signaling port that rewrites only the address on the c= and a=candidate: lines. The client's private address becomes its public address (taken from the TCP source), and the server's private address becomes the server's public IP. ufrag, ice-pwd and fingerprint are left alone, and ICE integrity still validates because each side computes over the SDP it actually received. Connections work normally after that.

1. There is no single player cap. BDS allocates one UDP socket per session, and each one has to be reachable.

This is the part I had wrong before. With one player connected I saw one socket and assumed server-udp-ports was being ignored. It isn't. The range pins which ports the per session sockets come from, and BDS hands out the next one for each additional player:

server-udp-ports=19150-19158

Player 1's answer advertises 19150, player 2's advertises 19151, player 3's advertises 19152, and ss shows a bound socket per connected player inside that range. If only one of those ports is reachable from outside then only one player can connect, which is exactly what the cap looked like.

One thing worth flagging: my router silently ignored a 19150-19158 range forward. Individual per port rules worked fine. If you're testing this, verify the forward actually applies instead of trusting the range.

With the candidate rewriting plus one forwarded port per player slot, I currently have a local PS5, an external PC, and an external PS5 all connected at the same time.

So the underlying bug looks like candidate gathering. NetherNet's HTTP signaling uses full ICE with STUN and TURN discouraged, nothing ever gathers a reflexive candidate, and there's no relay fallback. Two peers both behind NAT have no working path to offer each other. That fits why LAN works, why servers with a public IP directly on the interface work, and why self hosted behind NAT doesn't.