Updated May 8, 2026Documentation Index
Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt
Use this file to discover all available pages before exploring further.
Features
Two layers, both always on
- Raff Default Firewall (system) — applied automatically to every public network interface, blocks 7 dangerous ports, allows everything else. Cannot be disabled
- Your Firewall Groups (custom) — optional rule sets you create and attach to specific VM public IPs. Both layers must allow a packet for it to pass
Stateful filtering
- Connection-tracking is built in — when an inbound rule allows a connection, replies on the same connection are auto-allowed without an explicit outbound rule
- Same applies in reverse for outbound-initiated connections
- Most workloads only need to define inbound rules
Public-interface only
- Firewall Groups apply only to public IP traffic — IPv4 and IPv6
- VPC traffic is not filtered by Firewall Groups; isolate at the VPC layer or with guest-OS firewalls instead
- A VM with no public IP cannot have a Firewall Group attached (nothing to attach to)
Rule format
- Per rule: protocol (
TCP/UDP/ICMP/ALL), direction (INBOUND/OUTBOUND), optional port spec, optional source/destination CIDR, optional VPC scope, optional ICMP type - Port format: single (
22), comma list (80,443), colon range (3000:4000), or empty for “all ports” - IP format: CIDR (
0.0.0.0/0for any,192.168.1.100/32for a single host, etc.) - Database template can scope DB-port rules to a specific VPC ID
Templates
Five pre-built rule sets in the create dialog’s Start from template dropdown:| Template | Inbound | Outbound | Source-IP scope |
|---|---|---|---|
| Web Server | TCP 22, TCP 80,443, ICMP | ALL | Any |
| Database Server | TCP 22 (any), TCP 3306,5432 | ALL | DB ports VPC-scoped |
| SSH Only | TCP 22 | ALL | Any |
| Allow All | ALL | ALL | Any (not for production) |
| Deny All | (none) | (none) | n/a (lockdown) |
Apply, edit, attach, detach
- Edits propagate to the platform’s record immediately — but the guest VM picks them up only on reboot (see the warning under Limits)
- A group can be attached / detached at any time
- Multiple Firewall Groups can be attached to the same public IP — their allow lists union
- Default-block sanitization runs at save: any rule covering TCP 135 / 139 / 445 / 5985–5986 or UDP 137–138 has those ports stripped before save
Limits
| Item | Limit |
|---|---|
| Inbound rules per group | 40 |
| Outbound rules per group | 40 |
| Firewall Groups per account | No hard cap published; subject to overall account capacity |
| Firewall Groups per public IP | Unlimited in practice; one per IP is the common pattern |
| Source / destination per rule | One CIDR — for multiple distinct ranges, use multiple rule rows |
| Comma-separated ports per rule | No fixed limit; reasonable practice ~10 |
| Port range syntax | Colon — 3000:4000 (not AWS-style hyphen) |
| Group name | Free-form, must be unique per account, immutable after create |
| Description | Optional, free-form |
| Group rename | Not supported today — pick the name carefully |
Default Firewall — always-blocked ports
The system Default Firewall blocks TCP 135 / 139 / 445 / 5985–5986 and UDP 137–138 on every public interface, and Raff strips those ports from any user-rule range that covers them. Everything else inbound is allowed by default; ICMP (ping) is allowed; all outbound is unrestricted. For the full port list with the rationale per port, the visible-in-dashboard rules screenshot, and the Default-vs-Group precedence model, see Inbound vs outbound, layers, and rule format → What the Default Firewall blocks. If you genuinely need one of these ports, expose the service over a VPC instead and put a Firewall Appliance (OPNsense) in front. The public Default Firewall isn’t bypassable by design.Pricing
| Item | Cost |
|---|---|
| Raff Default Firewall | Free — applied automatically to every public interface |
| Your Firewall Groups | Free — no per-group, per-rule, or per-VM fees |
| Group attached to a VM | Free |
What’s not available today
- Group rename — names are immutable; create a new group + re-attach to rename in practice
- Hot-apply without reboot — a guest reboot is required for any rule change
- Explicit deny rules — only allow rules; deny is the default for anything not matched
- Rule comments / tags per rule — group-level Description only
- Rule audit log per group — system-wide audit log captures changes, but not surfaced per group in the dashboard
See also
Inbound vs outbound
The model behind these limits.
Add rules
Port and IP formats with copy-pasteable examples.
Create a Firewall Group
Walk the create dialog.