Skip to main content
Updated November 5, 2026 A Firewall Group only filters traffic once it’s attached to a VM’s public IP. The group itself sits idle on the Firewall tab until you wire it up. There are two equivalent entry points; both produce the same result.
The rules apply when the attach finishes, in about 20 seconds, with no restart. Connections that are already open stay open; every new connection follows the group’s rules.

Path A — From the Firewall Groups list

This is the right path when you have a group already and want to apply it to one or more VMs. In Networking → Firewall, find the group’s row and click ⋮.
Firewall Groups list with a row context menu open showing Edit Rules (pencil), Assign to VM (link icon), and Delete (red)
The menu has three actions: Click Assign to VM. The Assign Firewall Group to VM dialog opens.
Assign Firewall Group to VM dialog with subtitle "Attach 'Web Server' to a VM's public network interface", a read-only Firewall Group field showing "Web Server", a Select VM dropdown labeled "Choose a VM...", and Cancel / Attach buttons
The dialog has two fields: Click Attach. The group is attached to that VM’s primary public IP (typically the only one). The Firewall Groups row’s VMs column now shows the count (e.g. 1 VM instead of None), and the VM’s Network tab shows the group name where None used to be. To attach the same group to multiple VMs, repeat: open the row’s ⋮ → Assign to VM → pick the next VM. Each Assign action attaches to one VM at a time.

Path B — From the VM’s Network tab

This is the right path when you’re already on a VM’s detail page and decide it needs a firewall. Open the VM in Compute → click the Network tab. The IPv4 card has a Firewall field that reads None and an Attach button next to it.
VM detail page Network tab showing the IPv4 public IP card with eth0 - Public Network, Public + Primary tags, IP 23.26.4.27, MAC, Gateway 23.26.4.254, and a Firewall row showing "None" with an Attach button. A red Remove Public IP button sits below.
Click Attach. A picker shows every Firewall Group in the account; pick one and confirm. The card refreshes — the Firewall field now shows the group’s name (with a Detach action where Attach used to be), and the group’s row in Networking → Firewall updates its VMs count.

When it takes effect

Either path applies the group when the attach finishes, in about 20 seconds. There is no restart. Connections that are already open stay open; every new connection follows the group’s rules. A VM that is off gets the group when it starts. Test from outside the VM with a new connection: nmap -p <port> <ip> from your laptop, or curl against the new ports. If the dashboard says the server has not applied its rules yet, power the server off and on from its detail page.

Detach later

Two equivalent paths, mirroring the attach options: Detaching takes effect in about 20 seconds, with no restart: the IP goes back to the Raff Default Firewall. To switch one group for another (web-prod-v1 → web-prod-v2), attach the new group. It replaces the old one on that IP, and the new group goes on before the old one comes off, so the IP is never left without a firewall.

One Firewall Group per IP

Each public IP takes one Firewall Group. Attaching a group replaces the one the IP had. If 40 inbound and 40 outbound rules are not enough, combine ports into comma lists (80,443) and ranges (3000:4000). Common pattern: one group per role (web-prod, api-prod), each with the essentials it needs (SSH from your office, DNS, NTP) plus the service’s own ports. Edit a group and every VM using it gets the change.

IP-version mismatch — what if the group’s rules are IPv4-only and the VM is IPv6-only (or vice versa)?

A Firewall Group attaches to the VM’s public network interface, not to a specific IP address. The same group covers both IPv4 and IPv6 traffic on that interface — but only the rules whose source CIDR matches that traffic’s family actually fire: The common mistake is copying an IPv4-only template (Web Server, Database, SSH from Office) onto a dual-stack VM and assuming it locked the box down — IPv6 is still wide-open. Either:
  1. Add the matching IPv6 source rows to every inbound rule (0.0.0.0/0 → also add ::/0, 1.2.3.0/24 → also add the partner’s IPv6 prefix), or
  2. Don’t attach an IPv6 to the VM at all — auto-assign IPv4 only, or detach the existing IPv6 from the VM’s Network tab. With no IPv6 on the interface there’s nothing for unfiltered IPv6 rules to expose.
For a real lockdown on a dual-stack VM, the safest pattern is: attach the group, then run nmap -6 -Pn <ipv6-addr> from outside to verify what’s reachable on IPv6.

What about VPC-only VMs?

A VM with no public IP cannot have a Firewall Group attached — there’s nothing to attach to. The Network tab shows the IPv4 / IPv6 sections only when public IPs exist; the Attach button doesn’t appear for VPC-only VMs. To filter private VPC traffic, use guest-OS firewalls (ufw, iptables, Windows Firewall) on the destination VMs, or deploy a Firewall Appliance (OPNsense) as the VPC’s gateway.

Create a Firewall Group

Build the rule set you’ll attach.

Update rules

Edit a live group’s rules.

Inbound vs outbound

The model behind the rules.
Last modified on November 4, 2026