Server Firewall

Every server interface has a firewall: a list of rules the hypervisor enforces on the traffic entering and leaving the server. The rules live in VirtFusion and are applied on the hypervisor, outside the server, so they work whatever operating system the server runs and cannot be changed from inside it.

Two things are separate from the firewall and covered elsewhere. The network protections (MAC and IP anti-spoofing, and the Native v2 components) are described under Network Filtering. Which engine enforces the firewall rules on a hypervisor, libvirt nwfilter or Native nft, is chosen per hypervisor and described under Firewall engine. This page is about the rules themselves.

Rules

A rule matches traffic and allows or denies it. Rules run in order, lowest priority value first, and the first rule that matches decides. Traffic that no rule matches is allowed; to block everything else, add a deny rule for all protocols with the highest priority value.

Field	Meaning
Action	Allow lets the traffic through and allows the replies. Deny drops it without a reply. Reject drops it and tells the sender it was refused; it applies to outbound traffic only.
Direction	Inbound is traffic arriving at the server, Outbound traffic leaving it. Both matches either direction and is checked packet by packet, so replies are not tracked.
Protocol	TCP, UDP, ICMP, SCTP, GRE, ESP, AH, IPIP, L2TP or all protocols. Ports apply to TCP, UDP and SCTP.
IP Version	IPv4 or IPv6. A rule matches one or the other.
Source and Destination	An address or a subnet in CIDR notation, and for TCP, UDP and SCTP a port or a range such as 8000-8100. Left blank, any address or any port matches. For inbound traffic the destination is normally one of the server's addresses; for outbound traffic the source is.
Priority	500 to 1000. Lower values run first.
Rate Limit	The most new connections the rule allows per second or per minute, with an optional burst, and optionally counted per source address for inbound rules.
ICMP Type and Code	On an ICMP rule, the type and optionally the code to match.
Note	What the rule is for. Shown to the server's owner in the client area.
Enabled	A disabled rule is kept but not applied.

Reject, Rate Limit, the ICMP type and the GRE, ESP, AH, IPIP and L2TP protocols need the Native nft firewall engine on the hypervisor. On a hypervisor using libvirt nwfilter such a rule is stored but not enforced: the administrator's page marks it Not applied on this hypervisor and the client area marks it Not enforced. A rate limit applies to an allow rule with a single direction.

Managing a server's rules

Open the server, choose the Network tab and find the Firewall section of the interface. The switch beside the title turns the firewall on or off for that interface; with it off the rules are kept but nothing is enforced. Add Rule adds a rule, and each rule in the list can be edited, disabled or removed.

Saving a rule stores it. Nothing reaches the hypervisor until Update Server is clicked, which applies the whole list of the interface in one transaction. While stored changes have not been applied the section shows Changes not yet applied and, above the rules, lists what is waiting: the rules added, changed (with what they were) and removed since the hypervisor last received the list. Turning the firewall on or off is not listed; the switch shows it. Starting or restarting the server, or applying its configuration, also applies the stored rules.

Rulesets

A ruleset is a named list of rules kept under Firewall Rulesets in the admin menu, for rules you want on many servers: closing the mail ports, allowing a monitoring host, and so on. Add Ruleset on a server's firewall section copies the ruleset's rules onto the interface. The copy is what the server runs; a later change to the ruleset does not reach servers that already have it. A package can name rulesets too, and a server built from the package gets them on its primary interface.

Locked rules

A rule on a server is either locked or unlocked. A locked rule is the provider's: it runs before every unlocked rule whatever the priorities say, and the server's owner cannot change, disable or remove it from the client area. Rules added by an administrator are locked unless the Locked switch on the rule form is turned off, and rules copied from a ruleset are always locked. Unlocked rules belong to the server's owner and are the ones the owner manages.

The lock only matters when the owner can manage the firewall, described next. With owner management off, every rule behaves the same and the administrator manages them all.

Management by the server's owner

Since 7.1 a server's owner can manage the firewall of their own server from the client area, within the limits the provider sets. It is off until three things allow it:

1. The global setting. Under Settings, in the Users card, turn on Allow Firewall Management. The Firewall Rule Limit beside it is the most rules an owner may add on one interface; it defaults to 100, and locked rules do not count against it.
2. The server. In the server's Firewall section the Owner switch grants or withdraws management for that server. A shared user never gets it; only the owner does. To set it for many servers at once, tick them in the servers list and choose Allow Firewall Management or Disallow Firewall Management under Set State in the bar at the bottom.
3. Or the package. Firewall Management on the package's Network card sets the server's switch when a server is built from it. Changing the package does not change servers that already exist.

Turning the global setting off hides the feature for every server at once. The servers keep their own switches for when it is turned on again.

What the owner sees

With management allowed, the server page in the client area gains a Firewall tab. When the server has a secondary interface the owner chooses Primary Network or Secondary Network; an interface the hypervisor cannot filter (MacVTap or an Open vSwitch bridge) is not offered.

The owner can:

• Turn the firewall of the interface on or off, unless it carries locked rules. Locked rules keep the firewall on, and the page says so.
• Add, edit, disable and remove their own rules, up to the rule limit. The form offers the same fields as the administrator's, less the lock. Options the hypervisor's engine cannot enforce are not offered, and are refused if sent anyway.
• Turn all of their own rules off and on together with Enforce rules, which appears when the interface also carries locked rules. Locked rules are not affected.
• Apply their changes. As on the administrator's side, a change is stored first and the page shows Changes not yet applied, with a list of the rules added, changed and removed since the last apply, until Apply Changes pushes the whole list to the hypervisor. The button is disabled when nothing is pending.

Locked rules appear in the owner's list marked Managed, with the note the administrator gave them, so the owner can see what runs before their rules. They cannot change them.

The owner's changes are throttled, and the administrator's pages show the same Changes not yet applied badge and the same list of waiting changes when an owner has stored changes without applying them, so both sides see the same state. Every change and every refused request is recorded in the server's log.

info

A rule the owner adds is unlocked. Adding a locked rule that matches an existing unlocked rule, from the rule form or a ruleset, takes the rule over: it becomes locked and the owner can no longer change it. That is how a provider enforces a rule an owner already had.

Hypervisor engines

Owner management works with either firewall engine. On a Native nft hypervisor the rules of a server live in the bridge vffw table, locked rules first; on libvirt nwfilter they are written into the server's network filter with the locked rules at a higher priority. The commands for inspecting either are under Seeing the rules on a hypervisor.