> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Attach a Firewall Group to a VM
> Two ways to attach a Firewall Group to a VM's public IP — from the group's row menu, or from the VM's Network tab — plus the mandatory reboot to make the rules take effect inside the guest
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.
**A VM reboot is required after attaching.** The platform writes the rule set immediately, but the guest VM picks up the new firewall only at boot. Reboot the VM (Restart from the VM detail page, or `reboot` from inside the guest) to apply.
## 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:
| Action | What it does |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Edit Rules** | Opens the same dialog used to create the group, prefilled with the existing rules. There's no separate view-only screen — Edit Rules is how you both inspect and modify a group |
| **Assign to VM** | Opens the attach dialog — pick a VM in the same region to apply this group to |
| **Delete** | Removes the group. Disabled if any VM still has it attached (detach first) |
Click **Assign to VM**. The Assign Firewall Group to VM dialog opens.
The dialog has two fields:
| Field | Notes |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Firewall Group** | Read-only — set to whichever group you opened the menu on (the screenshot shows `Web Server`). To attach a *different* group, cancel and reopen from that group's row |
| **Select VM** | Dropdown of every VM in the dashboard's selected region. Pick one |
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:
| From | How |
| ------------------------------ | ------------------------------------ |
| **VM detail page** | **Restart** action button at the top |
| **Inside the guest (Linux)** | `sudo reboot` |
| **Inside the guest (Windows)** | `shutdown /r /t 0` |
After the reboot, the new firewall is live. Test from outside the VM with the new rules — `nmap -p ` from your laptop, or `curl` against the new ports.
## Detach later
Two equivalent paths, mirroring the attach options:
| From | How |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **VM detail → Network tab** | Click **Detach** next to the Firewall field on the IP card |
| **Firewall Groups list** | Group row's `⋮` → **Assign to VM** picker → uncheck the VM (when this is supported), or open the VM and detach there |
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**:
| Group rules | VM public IPs | What actually happens |
| ------------------------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IPv4 rules only (`0.0.0.0/0`, `1.2.3.0/24`) | Dual-stack (IPv4 + IPv6) | IPv4 traffic filtered by your rules. **IPv6 traffic falls through the group entirely** — only the system Default Firewall applies. Effectively, the VM is wide-open on IPv6 except for the 5 default-blocked Windows ports |
| IPv4 rules only | IPv6-only VM | The group is **functionally a no-op**. None of your rules ever match IPv6 source addresses; only the Default Firewall is active. The dashboard lets you attach it but it does no work |
| IPv6 rules only (`::/0`, `2001:db8::/32`) | IPv4-only VM | Same — group is a no-op, only the Default applies |
| IPv6 rules only | Dual-stack | IPv6 filtered by your rules. **IPv4 wide-open** |
| Mixed (both v4 and v6 source CIDRs) | Dual-stack | Both protocols filtered correctly |
| Mixed | Single-stack VM | Only the rules matching the VM's actual IP family do anything |
**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 ` 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](/products/network/vpc/quickstart-guides/manage-vpc#firewall-appliance-499-or-999--month) (OPNsense) as the VPC's gateway.
## Related
Build the rule set you'll attach.
Edit a live group's rules.
The model behind the rules.