Palworld Server Firewall Rules: Windows, Linux, and UDP 8211

If friends cannot join your Palworld dedicated server, allow inbound UDP 8211—or the value passed to -port—at each firewall that filters the route. The server does not need UDP 27015 as a universal game rule, and a TCP port test cannot prove that its UDP listener is reachable. Use the steps below to check Windows, Linux, or cloud rules without exposing the server’s admin interfaces. If you are still choosing a server route, our dedicated-server overview compares the main options.

Allow the Palworld server’s actual UDP port#

Start with the port the server listens on, then open that UDP port through the host firewall. Pocketpair lists UDP 8211 as the default and says -port changes the listening port. If your launch command contains -port=9000, for example, the firewall rule must allow UDP 9000 instead of 8211. Confirm the running command or server panel before adding a rule.

-publicport is different: it sets the external community-server port advertised to players, not the socket that PalServer listens on. Do not copy it into a host rule without checking how the particular route maps traffic. Pocketpair’s current requirements do not list 27015 as a universal requirement. If documentation for a specific server manager or listing route calls for another port, verify that route before opening it; do not add guessed ports to every server.

Setting	What it controls	Firewall implication
`-port`	The local game listener; default UDP 8211	Allow this UDP port at each filtering layer
`-publicport`	Advertised external community port	Check the route’s mapping; it does not replace the listener
RCON / REST settings	Optional server administration interfaces	Keep private; do not add public game ingress rules

Use Pocketpair’s server requirements and server arguments to confirm your installed version’s settings. A mismatch between the launch argument and firewall port is a common reason that an otherwise correct rule does nothing.

Add a Windows Defender Firewall rule for UDP 8211#

Allow the server’s inbound UDP traffic on the Windows network profile it actually uses. Check the profile, then add a narrow rule for the configured listener:

Check the network profile Windows is using
Run this in an elevated PowerShell window. Microsoft documents the profile categories and command output:
powershell
```
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
```
A home LAN may be Private; an internet-facing VPS adapter may be Public. A rule limited to Private will not match an interface classified as Public, even if a router forwards the packet correctly. Choose the active profile that should accept players. Do not change Windows’ network classification just to make a rule work.
Allow only the configured UDP port
Replace 8211 with the server’s configured -port. This example assumes the interface is classified as Private; use Public or Domain instead when that is the intended active profile:
powershell
```
New-NetFirewallRule -DisplayName 'Palworld UDP 8211' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 8211 -Profile Private
```
A program rule for the actual PalServer.exe path is another option; it allows the selected executable across its listening ports, while this port rule is limited to one UDP port. In the graphical firewall console, use Inbound Rules → New Rule → Port → UDP → Specific local ports, then allow it only on the intended profiles; Microsoft documents the inbound-rule fields. Do not create a TCP 8211 rule for the game listener. Microsoft recommends allowing a specific app or port instead of disabling the firewall, as described in its consumer firewall guidance. For the full install sequence, see the Windows server guide.

Allow UDP in Ubuntu’s ufw without locking yourself out#

On Ubuntu, add the game port as UDP and confirm the rule appears in UFW’s status. Replace 8211 if your server uses a custom -port value:

Add and inspect the UDP rule
bash
```
sudo ufw allow 8211/udp
sudo ufw status numbered
```
The /udp suffix matters. A rule such as sudo ufw allow 8211/tcp permits the wrong protocol for the normal Palworld game listener. The status output shows whether UFW is active; adding a rule does not mean the firewall is enabled or that the packet passed every other layer.
Protect remote SSH before enabling UFW
If UFW is inactive, decide whether to enable it. On a remote VPS, first identify the SSH port and allow the actual management path, then enable UFW from a session where you can recover access. Assuming SSH uses port 22 or enabling a deny-by-default firewall before permitting your current SSH connection can lock you out. Ubuntu documents UFW as its default firewall frontend; its UFW guide and man page describe protocol-specific rules. The Linux server setup guide covers the wider installation task.

Match the UDP rule in your cloud security group#

A cloud firewall is an additional gate, so a correct rule on the VM can still be blocked before the packet reaches Ubuntu or Windows. For a VPS, add an inbound rule in the provider’s security group or network firewall for UDP and the exact configured game port. On AWS, a new security group has no inbound permissions by default; its rule needs a protocol, port range and source. Other providers use different names, but the same layers apply.

For a server intended to accept friends over the public internet, the source may need to include their current public IPs or the broader internet. A narrow source rule is safer when everyone has stable addresses, but a friend’s changing ISP address can make yesterday’s rule stop working. Keep the host firewall rule and the cloud rule aligned, and change only one layer at a time so you can tell which change fixed the route.

Do not add TCP just because a control panel labels a field “port,” and do not expose every port on the VM. The game listener is UDP. RCON and REST are separate management interfaces and should remain limited to private access. AWS explains security-group rule fields and inbound defaults; verify the same values in your provider’s own documentation before applying a rule.

Keep RCON and REST off the public internet#

Do not open RCON or the REST API to solve a timeout on the game port. RCON is an administration interface, disabled unless enabled, and its documented default is TCP 25575; Pocketpair says to use it within the LAN and marks it deprecated. The REST API is also an admin interface protected by HTTP Basic Authentication. Its port is controlled by RESTAPIPort; do not assume a fixed port if the server configuration has changed.

A management connection should stay on localhost, a trusted private network, or behind a firewall that permits only the administrator’s address. A strong password does not make a public management endpoint necessary. If you need remote administration, use a private access method and confirm the listener’s actual binding and port before exposing anything. Pocketpair’s RCON guidance and REST API introduction explain the interfaces and their exposure risks. This page covers only the safe firewall boundary; use Pocketpair’s current API documentation for interface-specific setup.

Test Palworld UDP reachability from another network#

The useful check is whether a Palworld client can reach the running server from outside the host’s LAN. Ask a friend on another network—or use another connection you control—to try the appropriate direct-join route with the public address and game port. A successful LAN join only proves the local path. A community-server listing is a separate route; console players use the in-game community list, and a server must use the required -publiclobby launch argument for that listing path.

Do not use Test-NetConnection -Port 8211 as proof that UDP works. That PowerShell command tests TCP and reports TcpTestSucceeded; the Palworld game listener is UDP. A generic UDP scan can also be inconclusive because an application may not reply to an empty probe. If a client still times out, confirm the server is running and listening on the same UDP port you allowed, then verify the OS rule, cloud ingress and router mapping in order. The port-forwarding guide covers the router side; changing router rules cannot repair a Windows profile mismatch or a cloud ingress block.

Tell the host firewall from the router when a join fails#

Trace the packet path one layer at a time. First check the server process and its actual -port value. Next confirm that Windows or UFW allows inbound UDP on the host’s active profile. If the server runs on a VPS, verify the matching cloud ingress rule. Then check the home router’s UDP mapping and public address; CGNAT or an upstream network can prevent unsolicited inbound traffic even when the host firewall is correct.

Change one rule, retry from the external client, and record whether the result changed. Avoid adding guessed ports or opening TCP and UDP “just in case.” If LAN works but an outside client fails, focus on the router, cloud or public-address layer. If neither works, start with the process, listener and host firewall. The dedicated-server overview compares ways to run a shared world, while the Windows setup and Linux setup guides cover each host’s complete install. For the router checklist, return to Palworld port forwarding.

Quick answers

What firewall rules does a Palworld server need?

Allow inbound UDP 8211, or the server's configured -port, at each firewall layer that filters the route. Do not open TCP 8211 by mistake.

Should I open the Palworld RCON port on my firewall?

Keep RCON private; it is an administration interface, not the game's join port, and Pocketpair recommends using it within your LAN.

Why does Windows Firewall block my Palworld server?

Check the active network profile, the server executable or local port, the UDP protocol, and any router or cloud filter upstream.