Skip to main content
Updated May 8, 2026 This page is the format reference for the Ports and Source IP fields you fill on every rule row. The model itself — what inbound vs outbound means, how rules combine, what the system Default blocks — is on Inbound vs outbound, layers, and rule format. This page is the cheat sheet.

Port format

The Ports field accepts four shapes: Mixing list and range is allowed: 80,443,3000:4000 is a valid single Ports value. A quick note on syntax: AWS Security Groups use a hyphen for ranges (3000-4000) — Raff uses a colon (3000:4000), matching OpenNebula’s underlying format. If you copy a rule spec from AWS docs, swap the hyphen for a colon.

Common port values

Ports the Default Firewall blocks

TCP 135 / 139 / 445 / 5985–5986 and UDP 137–138 are always denied regardless of what you write — the system Default is layered on top of every public interface and Raff actively strips these ports out of any range you submit. Practical example: writing Range = 130:200 for inbound TCP saves as 130:134,136:138,140:200 (135 and 139 carved out). For the canonical table with per-port rationale and the dashboard screenshot, see Inbound vs outbound, layers, and rule format → What the Default Firewall blocks. If you genuinely need WinRM or SMB, run them inside a VPC and reach them via a Firewall Appliance (OPNsense) — not via a public-facing Firewall Group.

Source / destination IP format

The third box on each rule row is CIDR. For inbound it’s “from where can traffic come”; for outbound it’s “to where can traffic go”. The /32 (single IPv4) and /128 (single IPv6) are how you allowlist exactly one address. The dialog accepts CIDR with or without explicit prefix on /32, but type the /32 for clarity.

IPv6 examples — same shape, different addresses

If your VM has an IPv6 public IP attached (auto-assigned or reserved), the same rule rows apply — just use IPv6 CIDRs in the source field. Add a separate rule row for the IPv6 CIDR; one row carries one CIDR. A “fully open to v4 + v6” inbound on TCP/443 is two rule rows — one with 0.0.0.0/0 and one with ::/0. Same for outbound.

Common rule recipes

Each row below is one rule row in the create dialog. Add multiple rows for combinations. Public web server (IPv4 + IPv6): Bastion host (SSH only, locked-down outbound): Database VM (only reachable from VPC): Game server (UDP-heavy):

Limits per group

If 40 isn’t enough, split into multiple groups and attach them all to the IP — the union of allow lists applies.

How saving / editing works

  • Save creates the group as a unit — all rule rows submit together. Validation runs on the whole set; if one row is invalid (bad port format, invalid CIDR), the dialog shows the error inline and nothing saves.
  • Edits update the platform record immediately — but the guest VM does not pick up the new rules until you reboot it (see the warning below).
  • Default-block sanitization runs at save time — if you write 135, that exact rule is dropped from the saved set with no error. If you write 130:140, the saved rule excludes 135 and 139.
A VM reboot is required after any firewall change. Attaching a group, detaching a group, or editing rules in an attached group all need a reboot of every affected VM to take effect inside the guest. Until you reboot, the VM keeps running with its previous firewall state.

Inbound vs outbound

The model these rules slot into.

Create a Firewall Group

Walk the create dialog end-to-end.

Update rules

Edit a live group without detaching.
Last modified on May 8, 2026