ChunkPodFree beta
Sign in

Tools / Utilities

Minecraft Firewall Rules Generator

Generate ufw or iptables rules that open your Minecraft server's game or proxy port, keep SSH reachable and leave RCON closed unless you allow your own address.

Start from a preset

Firewall

ufw comes with Ubuntu and Debian and is the simpler choice. iptables (with ip6tables) works on any Linux machine

Always allowed, so enabling the firewall does not lock you out. Change it only if sshd listens on another port

Minecraft

What runs on the machine these rules are for: one server, a Velocity or BungeeCord proxy, or a backend server behind a proxy on another machine

server-port in server.properties, 25565 by default

For server list sites and status bots. Needs enable-query=true in server.properties

RCON

RCON sends its password and every command unencrypted, and nothing limits login attempts. Leave the port closed and run RCON tools on the server itself or through an SSH tunnel. If you must open it, allow only your own address.

Off keeps RCON reachable only from the machine itself

Get a strong password from the RCON password generator and set the ports in the server.properties generator.

ufw-rules.sh · 19 lines
#!/bin/sh
# Minecraft firewall rules for ufw
# Generated by https://chunkpod.com/tools/firewall-rules
# Run as root: sudo sh ufw-rules.sh
set -e

# Block everything coming in unless a rule below allows it
ufw default deny incoming
ufw default allow outgoing

# SSH first, so you keep access to the machine. limit slows down
# password guessing by blocking addresses with 6+ tries in 30 seconds
ufw limit 22/tcp comment 'SSH'

# Minecraft
ufw allow 25565/tcp comment 'Minecraft'

ufw --force enable
ufw status verbose

Ask the AI assistant

Questions and answers are stored for 30 days to improve the assistant. Privacy policy

Why a Minecraft server needs a firewall

This Minecraft firewall rules generator writes a short shell script that sets up ufw or iptables on the Linux machine your server runs on. It blocks every incoming connection by default, keeps SSH open so you do not lock yourself out, and then opens only the ports your setup needs: the game port for a single server, the proxy port for a Velocity or BungeeCord network, the game port for just the proxy's address on a backend server, and optionally the query and RCON ports.

A Minecraft server machine usually runs more than Minecraft. RCON listens on 25575 as soon as it is enabled, a database for plugins may listen on 3306, a web map on 8123, and backend servers of a network listen on their own ports. Every one of them binds to all network interfaces unless told otherwise, which means they are reachable from the internet. Scanners check the whole IPv4 address space for open Minecraft and RCON ports all day, so an open port is found within hours, not months.

A firewall turns that around: nothing is reachable unless you allowed it. If you later install a plugin that opens a port you did not know about, it stays private.

Ask the AI assistant

The AI assistant under the generator reads the script you've built and explains it before you run it: what each rule opens, why SSH comes first, or how to add a second server's port. It's free, with 20 questions a day.

Which ports Minecraft uses

PortProtocolUsed byOpen it?
25565TCPJava Edition game portYes, on a single server or the proxy's public port
25565UDPQuery (enable-query)Only for server lists or status bots that need it
25575TCPRCON remote consoleNo. Use it from the machine itself or an SSH tunnel
25577TCPVelocity and BungeeCord defaultYes, on the proxy machine
19132UDPBedrock Edition and GeyserOnly if Bedrock players join
22TCPSSHYes, or you lose access to the machine

The game port is whatever server-port in server.properties says. The query port is query.port, which defaults to the game port but over UDP, so both can be 25565 without clashing. The server.properties generator sets all three.

The tool covers Java Edition. If you run Geyser for Bedrock players, add ufw allow 19132/udp (or the matching iptables line) to the script yourself.

The three setups

A single server

The common case: one Minecraft server on one machine. The script opens the game port to everyone and nothing else besides SSH.

A proxy network

With Velocity or BungeeCord, players connect to the proxy, and the proxy connects to the backend servers. Only the proxy port should be public. The backends must not be reachable from the internet, for two reasons:

  • Security. BungeeCord's IP forwarding and Velocity's legacy forwarding trust whatever the connection says about the player. Backend servers run with online-mode=false, so a player who connects to a backend directly can claim to be anyone, including an operator. Velocity's modern forwarding signs that data with a secret, which stops the impersonation, but a backend reachable from outside still skips the proxy's plugins, bans and permission checks
  • Players get lost. Someone who finds a backend's port joins it directly, lands outside the lobby and bypasses whatever the network set up

When the proxy and backends run on the same machine, pick "A Velocity or BungeeCord proxy". The script opens only the proxy port. The proxy reaches the backends over localhost, which the firewall always allows, and their ports stay closed. You can also set server-ip=127.0.0.1 on each backend so they only listen on localhost in the first place; the two together are the safe setup.

When a backend runs on another machine, generate a second script for it with "A backend server behind a proxy on another machine" and enter the proxy's address. Its game port is then open only to that one address. Use the private network address if both machines are at the same provider, since traffic between them then stays off the public internet.

The Velocity config builder and the BungeeCord config creator set up the proxy side, including forwarding. If you are still choosing a proxy, the server software comparator explains how Velocity's forwarding differs from BungeeCord's.

RCON: keep it closed

RCON gives full console access to anyone with the password. The protocol has not changed since it was designed for early Source engine servers, and two of its properties make it a poor fit for the open internet:

  • Nothing is encrypted. The password and every command cross the network in plain text
  • Nothing limits login attempts. A script can try passwords as fast as the connection allows, and the server does not lock anyone out

So the generator leaves the RCON port closed unless you ask for it. RCON still works from the machine itself: backup scripts, restart timers and bots running on the server connect to 127.0.0.1, which is not affected by the firewall. From your own computer, forward the port through SSH:

code
ssh -L 25575:127.0.0.1:25575 you@your-server

Your RCON client then connects to 127.0.0.1:25575 on your side, and the traffic travels inside the encrypted SSH connection. A VPN such as WireGuard or Tailscale does the same for a whole team.

If a tool somewhere else really needs direct access, turn on "Open the RCON Port" and put its address in "Allow RCON From". The rule then only lets that address in. Leaving the field empty opens RCON to everyone; the tool shows a warning and writes one into the script, because that setup relies on the password alone. Whichever way you connect, use a long random password from the RCON password generator.

ufw or iptables?

ufw (Uncomplicated Firewall) comes with Ubuntu and is available on Debian. It is a front end for iptables that keeps rules across reboots, handles IPv4 and IPv6 in one command and reads almost like English. If your machine has it, use it.

iptables works on any Linux machine. The script adds rules for IPv4 with iptables and repeats them for IPv6 with ip6tables, because the two are separate: rules added with iptables do nothing for IPv6 traffic. Leave "IPv6 Rules" on unless you know the machine has no IPv6 address. A rule limited to an IPv4 address, such as a proxy address or your home IP, has no IPv6 version, so that port stays closed over IPv6.

On newer Debian and Ubuntu releases, the iptables command is a wrapper around nftables, and the generated rules work the same way. On Fedora, Rocky Linux, AlmaLinux and other Red Hat family systems, firewalld is the usual tool instead; the equivalent of the game port rule there is firewall-cmd --permanent --add-port=25565/tcp followed by firewall-cmd --reload.

What the script does

ufw

  1. Sets the default policy to deny incoming and allow outgoing connections
  2. Adds SSH with ufw limit, which blocks an address that opens 6 or more connections in 30 seconds and slows down password guessing
  3. Adds a rule for each Minecraft port, with a comment so ufw status shows what each one is for
  4. Enables ufw with --force, which skips the "may disrupt existing ssh connections" prompt, and prints the result

The SSH rule is added before ufw is enabled, so your current session stays connected.

iptables

  1. Defines a small allow function that adds a rule only if it is not already there, so running the script twice does not create duplicates
  2. Accepts loopback traffic, replies to connections the server opened itself, and ICMP. IPv6 needs ICMPv6 to work at all, and ICMP lets path MTU discovery and ping work on IPv4
  3. Accepts SSH and each Minecraft port
  4. Sets the policy of the INPUT chain to DROP, only after every accept rule is in place

iptables rules live in memory and are gone after a reboot. The end of the script shows how to keep them on Debian and Ubuntu: install iptables-persistent, then run netfilter-persistent save whenever you change the rules.

How to install the rules

  1. Check which port SSH uses: sudo ss -tlnp | grep sshd. If it is not 22, enter the right port in the tool
  2. Save the script on the server, for example as ufw-rules.sh
  3. Read it once. It is short, and you should know what it does before running anything as root
  4. Run it: sudo sh ufw-rules.sh or sudo sh iptables-rules.sh
  5. Keep your SSH session open and open a second one. If the second one connects, the SSH rule works
  6. Test the game port from another network, for example by adding the server in your Minecraft client, or with nc -zv your-server 25565 from another machine

To see the active rules, run sudo ufw status numbered or sudo iptables -L INPUT -n --line-numbers. To remove a ufw rule, use sudo ufw delete <number>. To start over with iptables, run sudo iptables -P INPUT ACCEPT and then sudo iptables -F INPUT.

If you do lock yourself out, most hosting providers have a web console that works without SSH. Log in there and run ufw disable or reset the iptables policy.

Common mistakes

Enabling the firewall without an SSH rule

The classic lockout. ufw enable with the default deny policy and no SSH rule cuts off your session as soon as it drops. The generated script always allows SSH first. If you moved SSH to another port, change the port in the tool before you run it.

Docker ignores ufw

Ports published by Docker with -p 25565:25565 do not go through ufw's rules. Docker adds its own iptables rules that forward the traffic before ufw sees it, so a port that ufw status does not list can still be open. A container running the itzg/minecraft-server image with -p 25575:25575 exposes RCON to the internet even with ufw enabled. Publish only the ports you mean to share, bind private ones to localhost with -p 127.0.0.1:25575:25575, or add rules to the DOCKER-USER chain.

Forgetting the provider's firewall

Many cloud providers have a network firewall in front of the machine: security groups on AWS, firewall rules on Google Cloud, cloud firewalls on Hetzner and DigitalOcean. Both have to allow a port for it to be reachable. If the game port is open in ufw but nobody can connect, check the provider's panel.

Opening the query port without enable-query

The firewall rule alone does nothing. The server only answers on the query port when enable-query=true is set in server.properties. The same goes for RCON and enable-rcon.

Hosting at home

A firewall on the server does not replace port forwarding on your router. At home, the router has to forward the game port to the server's local address, and the firewall on the server has to allow it. Only forward the game port; never forward RCON.

A proxy port that players cannot reach

Velocity and BungeeCord listen on 25577 by default. If players are told to connect without a port, the proxy has to listen on 25565, and the firewall rule has to match. Set the proxy port in the tool to whatever the proxy's config says.

Performance and lag

A firewall with a handful of rules has no measurable effect on server performance. If players see lag, the cause is almost always on the server itself; the guide on how to fix Minecraft server lag covers finding it. On a managed host such as ChunkPod you do not run the machine yourself, so there are no firewall rules to write.