Trouble with satisfactory server docker container for CGNAT tunneling with playit.gg

[blahblahblah552]

I'm trying to set up a dedicated satisfactory server and make it accessible over a CGNAT connection. I'm utilizing playit.gg as a tunneling service. I see where the ports for the SERVERMESSAGINGPORT=8888 is shared with the ReliablePort and ExternalReliablePort, but with playit.gg they give you consecutive ports that need to be mapped to. I got it to work using steams dedicated server running ./FactoryServer.exe -Port=7777 -ReliablePort=7778 -ExternalReliablePort=19219 -log -unattended.

Is there a way to add another port variable during setup to change the ExternalReliablePort. I tried adding it using the Environment variables but didn't have any luck or please tell me if I'm missing something.

[wolveix]

@blahblahblah552 I'm not sure I understand your question. SERVERMESSAGINGPORT set's the port for both internal and external. If you're being allocated consecutive ports, then you need to bind the game and messaging ports accordingly. I'm not sure why you'd need to set the internal and external ports separately, but perhaps I'm not understanding :)

[blahblahblah552]

I think it's how the Satisfactory Dedicated Server communicates its connection details to the client during the handshake.
When using playit.gg, the internal and external ports do not match. For example:

Game Port: Internal 7777 maps to External 19218

Reliable Port: Internal 7778 maps to External 19219

The server needs to be aware of the external port (19219) so it can tell the client where to send 'Reliable' traffic. Without the -ExternalReliablePort argument, the server defaults to telling the client to use the internal port (7778), which is not accessible through the tunnel.

In the standard Steam CLI, I can solve this with the -ExternalReliablePort=19219 flag. I am looking for a way to pass this specific parameter (or an equivalent environment variable) through your Docker image so the server correctly broadcasts the tunnel's port to connecting clients.

also thanks for the quick response

[wolveix]

No, I understand how it works for Satisfactory, but I'm unsure why the flag isn't doing what you're after. The flag sets both the internal and external ports, so that they remain the same because specifically for Docker, there's no reason to separate them.

[wolveix]

I'm not sure how you're running it, because you haven't given any details, but setting the SERVERMESSAGINGPORT environment variable should be all you need to do. Just set it to the port that is exposed.

[blahblahblah552]

The issue with setting SERVERMESSAGINGPORT to the external port (19219) is that it forces the server to listen on 19219 internally as well. My tunnel is specifically looking for traffic on the local port 7778 to pass it through to the public port 19219.

When I test locally (7777/7778), it works perfectly.

When using the tunnel:

• If I set the server to listen on 7778, it tells the client: 'Connect to me on 7778.' The client fails because the tunnel is only open on 19219.

• If I set the server to listen on 19219, the tunnel fails because it's trying to send traffic to the container on 7778.

This is why I need to set the ExternalReliablePort separately from the internal bind port. I need the server to listen on 7778 but advertise/broadcast to the client that it is on 19219.

If there's any other info I can share let me know.

here is a log dump of where you can see me getting timed out running on 7777 and 7778.

[2026.02.03-23.12.59:990][968]LogGame: Warning: Set Online State For Player : true - BP_PlayerState_C_2147456494

[2026.02.03-23.12.59:990][968]LogGame: Warning: Could not process player whose OnlineState changed: local user was invalid

[2026.02.03-23.12.59:990][968]LogAkAudio: AFGPlayerControllerBase::SetupWwise

[2026.02.03-23.12.59:991][968]LogWorldPartition: UWorldPartitionStreamingPolicy: CellsToActivate(103), CellsToLoad(0), CellsToUnload(0)

[2026.02.03-23.12.59:991][968]LogWorldPartition: UWorldPartitionStreamingPolicy: Sources[0] = X=-245713.656 Y=89033.938 Z=-1556.388,P=0.000000 Y=0.000000 R=-0.000000

[2026.02.03-23.13.00:286][968]LogGameState: Match State Changed from WaitingToStart to InProgress

[2026.02.03-23.13.00:286][968]LogNet: Join succeeded: ***

[2026.02.03-23.13.00:551][974]LogNavigationDataBuild: Display: ProcessTileTasksAndGetUpdatedTiles build time: 9.32s

[2026.02.03-23.13.02:222][ 24]LogReliableMessaging: Received connection announcement from client. Connection ID: '6328AAD244F634AEB0F4C3AD9D386774'.

[2026.02.03-23.13.09:271][235]LogNet: NotifyAcceptingConnection accepted aggregation: [::ffff:172.17.0.1]:35373 (24), [::ffff:172.17.0.1]:40958 (24), [::ffff:172.17.0.1]:55183 (24), [::ffff:172.17.0.1]:51346 (24)

[2026.02.03-23.13.21:167][591]LogServer: Display: Server startup time elapsed and saving/level loading is done, auto-pause is allowed to proceed from now on (if enabled in server settings). WorldTimeSeconds = 30.06

[2026.02.03-23.13.22:375][627]LogReliableMessaging: Warning: Handshake with player 'BP_PlayerController_C_2147480521' timed out. Removing component.

[2026.02.03-23.13.22:375][627]LogNet: UNetConnection::Close: [UNetConnection] RemoteAddr: [::ffff:172.17.0.1]:33173, Name: IpConnection_2147480722, Driver: GameNetDriver FGDSIpNetDriver_2147482114, IsServer: YES, PC: BP_PlayerController_C_2147480521, Owner: BP_PlayerController_C_2147480521, UniqueId: Steam:1 (ForeignId=[Type=6 Handle=0 RepData=[3151CF0401001001]), Channels: 872, Time: 2026.02.03-23.13.22

[2026.02.03-23.13.22:375][627]LogNet: UNetConnection::SendCloseReason:

[2026.02.03-23.13.22:375][627]LogNet: - Result=ConnectionTimeout, ErrorContext="ConnectionTimeout"

[2026.02.03-23.13.22:375][627]LogNet: UChannel::Close: Sending CloseBunch. ChIndex == 0. Name: [UChannel] ChIndex: 0, Closing: 0 [UNetConnection] RemoteAddr: [::ffff:172.17.0.1]:33173, Name: IpConnection_2147480722, Driver: GameNetDriver FGDSIpNetDriver_2147482114, IsServer: YES, PC: BP_PlayerController_C_2147480521, Owner: BP_PlayerController_C_2147480521, UniqueId: Steam:1 (ForeignId=[Type=6 Handle=0 RepData=[3151CF0401001001])

[wolveix]

Would you mind providing how you're running the container, please? The issue template helps avoid a lot of back and forth.

A large benefit of containers is not needing to worry about what's happening inside of them. Your tunnel should be ending at the end of the container, not to the process running within it.

Regardless of that though, why aren't you able to just change the tunnel configuration in the first place to use the SERVERMESSAGINGPORT value?

I promise I'm not trying to be difficult. It would obviously be easy to make the internal and external ports separately configurable; however, it goes against the whole point of containers.