Skip to main content
Updated November 5, 2026 The most-seen issues with Raff Firewall and the fix that resolves each. If your issue isn’t here, contact support@rafftechnologies.com.

​
Changes don’t seem to apply

Check with a new connection. Changes apply without a restart: saved rules within a few seconds, an attach or detach in about 20 seconds. Connections that were already open stay open, so an SSH session or a download that started before the change keeps working.Test from outside the VM with a new connection: nmap -p <port> <ip>, curl https://<ip>:<port>, or a fresh ssh.If the dashboard showed an error naming the server, that server has not applied the change. Save the rules again, or power the server off and on from its detail page.
Possible causes:
  1. The Firewall Group isn’t actually attached to that VM. Open the VM’s detail page → Network tab → check the IP card’s Firewall: field. If it says None, the group isn’t attached. Click Attach to fix.
  2. You’re testing from inside the VPC. Internal traffic to the VM’s public IP can take a different code path; firewall rules only apply to public-internet traffic. Test from your laptop or a VM in another account/region.
  3. Guest-OS firewall is also blocking. ufw status (Ubuntu/Debian), firewalld (RHEL/CentOS), or Windows Firewall might be blocking on top of the Raff firewall. Open the port in the guest too.
  4. Wrong protocol. TCP rule won’t match UDP traffic and vice versa. Confirm your client is using the protocol the rule allows.
  5. System Default Firewall is blocking — see below.

​
System Default Firewall blocks

What’s happening: Raff actively strips these ports from any inbound rule you save. The system Default Firewall blocks them on every public interface and the platform won’t let you punch a hole.Why: these are well-known Windows-network attack vectors (MS-RPC, SMB / WannaCry, NetBIOS, WinRM). Allowing them on a public IP is almost never what you want.Fix: if you genuinely need one of these ports:
  • Run the service inside a VPC instead of on a public IP, then deploy a Firewall Appliance (OPNsense) as the VPC’s gateway and configure inbound rules there. The system Default doesn’t apply to private interfaces, and OPNsense can allow whatever you want.
  • Tunnel over a different port — run SMB inside a WireGuard tunnel on a different port, expose only the WireGuard endpoint
What’s happening: the platform sanitized the range to remove ports the system Default blocks. A rule of 130:200 is saved as 130:134,136:138,140:200 — ports 135 and 139 carved out.Fix: that’s working as designed. The sanitization is honest about what’s actually allowed; if you tried to save 130:200, traffic to 135 and 139 was never going to reach the VM anyway. The saved form just makes the actual behavior visible.

​
Saving and editing

What’s happening: the Ports field has a value the validator rejects.Common mistakes:
What’s happening: the Source / Destination IP field has a value the validator rejects.Common mistakes:
Limit: 40 inbound rules + 40 outbound rules per Firewall Group.Fix:
  • Combine rules where you can — 80,443 in one row instead of two; 3000:4000 instead of forty single-port rules
  • Use a Firewall Appliance (OPNsense) inside a VPC for unlimited rule complexity; the public Default + your group apply to the public interface; OPNsense applies to anything routed through the VPC
Fix: Firewall Group names are unique per account. Pick a different name. Renaming an existing group doesn’t free its name for a new group while it exists — but if you’re trying to delete-and-recreate, the name is freed once the old group is deleted.

​
Locked out

What’s happening: you tightened the inbound rules, and new SSH connections are now blocked along with everything else. An SSH session you opened before the change keeps working, so if one is still open, use it while you fix the rules.Recovery — three paths:
  1. VNC console — every VM has a built-in browser console that bypasses the network entirely. From the VM detail page → Console action. Log in with the VM’s password (or reset the password first if you don’t know it). From the console, fix the firewall: detach the restrictive group with raff-cli firewall detach …, or if you don’t have the CLI in the VM, use the dashboard from another browser tab.
  2. Detach the restrictive group from the dashboard: VM detail page → Network tab → IP card → Detach firewall. The system Default Firewall applies again (it allows SSH), and you can connect in about 20 seconds.
  3. Attach an SSH-only group: create or pick a Firewall Group with at least TCP 22 from 0.0.0.0/0 (or your office IP) and attach it to the VM. SSH works again in about 20 seconds; then iterate on the rules from a stable baseline.
Going forward: test restrictive firewall changes on a single VM first, and keep an SSH session and the VNC console open while you test, in case you lock yourself out.
Same root cause as above: your edit removed (or restricted) the rule that was allowing your management traffic. Add back an inbound rule for the management protocol (TCP 22 SSH, TCP 3389 RDP) from your client IP and save.Common gotchas:
  • Your office’s public IP changed. Most ISPs give residential / office customers dynamic IPs. The CIDR you whitelisted six months ago may not be your current egress IP. Check curl ifconfig.me from your client and update the rule’s Source field
  • You’re connecting via VPN — the source IP is the VPN’s egress, not your local IP. Whitelist the VPN range
  • You disabled the rule rather than removing it (or vice versa) — the dashboard doesn’t have a per-rule “disable” toggle; rules are either present (allow) or absent (deny). Add the rule back fresh

​
Attach, detach, delete

What’s happening: the group is still attached to one or more VMs.Fix: the VMs column on the Firewall Groups row tells you the count. Open each attached VM’s Network tab → click Detach next to the IP’s Firewall field. After detaching from every VM, the row’s ⋮ menu unblocks Delete.See Delete a Firewall Group for the full flow.
What’s happening: no VMs in the dashboard’s selected region have a public IP, or every VM in the region already has this exact group attached.Possible reasons:
  1. VMs without a public IP can’t have a Firewall Group attached. Firewall Groups apply to public traffic only; VPC-only VMs aren’t in the picker. To filter VPC traffic, deploy a Firewall Appliance gateway on the VPC instead
  2. All VMs in the region already have this group. The picker filters out duplicates
  3. Wrong region selected — switch the top-bar region selector
The empty state is rare; if you expected to see VMs, double-check the region and the “VMs without public IPs” angle.

​
Port forwarding interaction

What’s happening: Platform Router (or Firewall Appliance) is itself a VM. If you attach a restrictive Firewall Group to its public IP, the inbound port-forwarding rules can’t actually deliver traffic.Fix: the Platform Router gateway is best left without a Custom Firewall Group — the system Default Firewall already covers the dangerous Windows ports, and port forwarding handles the application-level routing. If you genuinely want firewalling in front of port forwarding, deploy a Firewall Appliance (OPNsense) instead — it’s designed for this case and has full rule-set capability that port-forwarding doesn’t conflict with.See Manage a VPC → Port Fwd for the gateway model.

​
Still stuck?

Email support@rafftechnologies.com with:
  • The Firewall Group ID and name
  • The VM ID that’s affected
  • What you expect to work and what’s actually happening — exact ports, source IPs, protocols
  • When you made the change, and any error the dashboard showed
Same-day response in business hours; faster for production-impacting issues.

Inbound vs outbound

The model behind the rules.

Add rules

Port and IP format reference.

Update rules

Edit an existing group’s rules.
Last modified on November 4, 2026