Skip to content

Firewall Rules ​

Firewall Rules is the list of ports the server accepts traffic on, and from where. Everything not listed here is closed.

Firewall rules

Overview ​

URL: /admin/settings/firewall-rules

Open it from Settings > Security > Firewall Rules in the sidebar. The page subheading reads "Manage system firewall rules, including port access and IP restrictions."

The rule list ​

ColumnMeaning
ProtocolTCP, UDP, ICMP (IPv4), or ICMPv6 (IPv6).
IP VersionWhich address family the rule is applied over: IPv4, IPv6, or IPv4 + IPv6.
SourceThe address traffic must come from. Any when unrestricted.
Source PortThe port traffic must come from. Any when unrestricted.
DestinationThe address on this server the rule applies to. Any when unrestricted.
Destination PortA port or a range, for example 443 or 49152-65535.
CommentWhat the rule is for, for example AdminBolt - HTTPS.

Each row has Edit and Delete. The search box works across the visible columns, and the page size can be set to 5, 10, 25, 50, or All.

Since panel 1.9.3, a port the firewall cannot read is shown as it is stored, marked "Not applied: not a port from 1 to 65535 or a range such as 2000-3000." See Ports.

Fix System Ports restores the rules the managed services need. Use it after an experiment closes a port the panel, web server, DNS, FTP, or mail depends on. Since panel 1.9.2 it opens SSH on the ports the server's SSH service is set to and listens on, rather than on a port the panel remembered.

SSH rules ​

Since panel 1.9.2 the firewall keeps SSH reachable on its own:

  • The SSH rule is protected. The SSH rule for a port SSH listens on cannot be edited or deleted here. The message reads, for example, "This rule keeps SSH reachable on port 22, where sshd listens, so it cannot be changed or deleted here." To move SSH, change the port on SSH Access, which opens the new port before SSH moves and removes the old rule afterwards.
  • A rule cannot block SSH for everyone. A Drop or Reject TCP rule that covers a port SSH listens on, with no Source IP (or one meaning every address, such as 0.0.0.0/0) and no Source Port, cannot be saved, for example: "This rule would block SSH on port 22, where sshd listens, so it cannot be saved." Restrict the rule to the addresses you want to block, or move SSH to another port first.
  • Changes wait for an SSH port change. While an SSH port change or Fix System Ports is running, a change to an SSH rule, or to a block rule for every source, is refused with "An SSH port change or a firewall rebuild is in progress, so this rule was not changed." Try again in a moment.

Default rules ​

A fresh installation creates these:

CommentProtocolDestination Port
AdminBolt - AdminTCP8443
AdminBolt - HTTPTCP80
AdminBolt - HTTPSTCP443
Allow ICMP (IPv4 ping and diagnostics)ICMP (IPv4)Any
Allow ICMPv6 (IPv6 ping and diagnostics)ICMPv6 (IPv6)Any
DNS TCPTCP53
DNS UDPUDP53
FTPTCP21
FTP PassiveTCP49152-65535
Mail - DovecotTCP4190
Mail - IMAPTCP143
Mail - IMAPSTCP993
Mail - POP3TCP110
Mail - POP3STCP995
Mail - SMTPTCP25
Mail - SMTPTCP587
Mail - SMTPSTCP465
SSHTCP22

The two ICMP rules keep the server answering ping and the diagnostics that depend on it, over each family separately.

Creating a rule ​

Create Firewall Rule opens a form:

FieldDescription
ProtocolTCP, UDP, ICMP (IPv4), or ICMPv6 (IPv6).
Action (required)Accept lets the traffic through, Drop discards it silently, Reject answers with an error. Block rules are applied before accept rules, so a block cannot be shadowed by an accept on the same port.
Source IPThe address the rule applies to. Leave blank for any source.
Source PortThe port traffic comes from. Leave blank for any source port.
Destination IPThe address on this server. Leave blank for any.
Destination PortA single port or a range. Leave blank to cover all ports, which is how a rule is written for an address rather than for a service.
CommentA description you will recognise later.

A rule that would match every address on every port asks for an explicit confirmation before it is saved, so a rule that opens or closes the whole server is never one field away. Since panel 1.9.3, saving with the box unticked shows "Confirm that this rule should match every address on every port."

Execute Rule saves and applies the rule; Cancel closes the form. Edit on a row reopens the same form with the current values.

Delete removes a rule after a confirmation. Deleting a rule closes the port it opened, so check what depends on it first.

IPv4, IPv6, and both ​

The addresses you pin a rule to decide which family it covers, and the IP Version column states the result for every row:

RuleIP Version
Source or destination is an IPv4 addressIPv4
Source or destination is an IPv6 addressIPv6
No source and no destination addressIPv4 + IPv6

This matters when you open a port to a single address. A rule that allows 203.0.113.10 opens the port over IPv4 for that address and leaves it closed over IPv6. To reach the same service over both families, create a second rule pinned to the corresponding IPv6 address.

Where a restriction cannot be expressed for one family, the port stays closed there rather than being opened to everyone. Identical rules are applied once, so a duplicate you create by accident does not produce a duplicate rule on the server.

Ports ​

Since panel 1.9.3, Source Port and Destination Port accept a single port from 1 to 65535, or a range such as 2000-3000 with the lower port first. Both are checked when you create or edit a rule. A value with spaces, a line break, or anything else around the port is refused, with "Enter a port from 1 to 65535 or a range such as 2000-3000, with no spaces or other characters."

A stored rule whose port cannot be read, for example one saved by an earlier version, is left out of the firewall and has no effect. It stays in the list, and Some firewall rules are not applied above the table names each such rule by number and comment until you edit its port or delete it. The other rules keep being applied.

Updating to 1.9.3 removes stray spaces and line breaks around stored ports and applies the repaired rules. A rule it cannot repair is named in a warning on System Updates until it is fixed here.

JetBackup access ​

Since panel 1.9.3, on a server with JetBackup, JetBackup access above the table decides who can reach JetBackup through the firewall:

ChoiceEffect
Open to everyoneJetBackup's port is open to every address. This is the default.
Only the networks belowOnly the addresses or networks you list under Allowed networks can reach it, one IPv4 or IPv6 address or network per line, for example 203.0.113.0/24 or 2001:db8::/48.
Nobody (port closed)The port is closed.

A restriction also limits where administrators and hosting customers can open JetBackup from, because the JetBackup links in the panel open JetBackup's port in their browser. A network of one family does not open the port for the other family, so list an IPv6 network as well if you need one. A network that matches every address is refused; choose Open to everyone instead.

Save applies the choice to the JetBackup rule and leaves your other system rules as they are. When the rules cannot be applied, the previous access is kept and the message says so. Fix System Ports and a JetBackup reinstall keep the choice. Restricting or closing the port also removes an older rule that kept it open to everyone.

Before 1.9.3, the way to limit JetBackup was a Source IP on its system rule, which a rebuild of the system rules could undo. Updating to 1.9.3 carries a Source IP you set there, or a Drop or Reject rule that closed the port for every address, over into JetBackup access.

The administrator REST API offers the same setting: GET /api/admin/firewall/jetbackup reads it, and PUT /api/admin/firewall/jetbackup sets mode (open, restricted, or disabled) and, with restricted, sources. A refused value answers 422 naming the field, a firewall rebuild in progress answers 409, and rules that cannot be applied answer 503 with the previous access kept.

firewalld ​

The panel's firewall is the ruleset this page manages, and the panel never installs or starts firewalld. Since panel 1.9.3, when firewalld runs next to it, for example because it was started outside the panel, the page warns: firewalld is running next to the panel firewall. firewalld drops every port its own zone does not list, so ports this page shows as open, including the panel port, 443, and 80, may not answer. The warning gives the command that stops it; the panel firewall works without it.

DHCPv6 ​

Since panel 1.9.3, the firewall accepts DHCPv6 replies over IPv6 as part of its built-in rules, so a server that gets its IPv6 address by DHCPv6 keeps its lease. The rule is not in the list and needs no action.

Updating to 1.9.3 applies it to existing servers and then removes a manual rule that earlier versions needed for this: UDP, Accept, Source IP fe80::/10, Source Port 547, Destination Port 546, with no destination address. Other rules are left alone. If the server's bolt-agent is too old for the new rule, that upgrade step changes nothing and fails with a message naming the bolt-agent version to install. Update bolt-agent, then run the step again:

bash
bolt-cli run-upgrade-steps --retry-failed
  • Fail2Ban Settings - automatic bans, which are written into the same firewall.
  • SSH Access - the SSH port and the addresses allowed to reach it.