Attach a Firewall Group to a VM

_{Updated May 8, 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.

​

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 ⋮. The menu has three actions: Click Assign to VM. The Assign Firewall Group to VM dialog opens. 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. 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.

​

Reboot the VM

Either path writes the rule set to the platform’s record immediately. The guest VM does not pick up the new firewall until it reboots. Reboot from one of: After the reboot, the new firewall is live. Test from outside the VM with the new rules — nmap -p <port> <ip> from your laptop, or curl against the new ports.

​

Detach later

Two equivalent paths, mirroring the attach options: After detach, the platform clears the rule set from the VM’s IP — but the same reboot rule applies: the guest keeps using the previous rules until it reboots. Reboot to actually drop them. If you’re switching one group for another (web-prod-v1 → web-prod-v2), do them in order: detach the old, attach the new, reboot once at the end. One reboot covers both changes.

​

Multiple Firewall Groups on one IP

The dashboard allows attaching more than one Firewall Group to a single public IP. When multiple groups are attached, their allow lists union — a packet is allowed if any attached group has a rule allowing it. Each Firewall Group still has its 40-inbound + 40-outbound limit, so stacking groups is the workaround when one group isn’t enough. Common pattern: a base group (infra-essentials — SSH from office, DNS, NTP) plus a per-service group (web-prod, api-prod) — combine the two on every web/api VM, edit one without touching the other.

​

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.

​

Related