Access Control
Rabtly’s access control lets you decide which devices can reach which other devices on your network. This section explains the model, then walks you through a complete hands-on demo where you create groups and connect them — so you can learn by doing on a throwaway setup before applying it for real.
The mental model
Rabtly’s access control is group-based and default-deny. Two ideas are all you need:
- Groups — you sort devices into named groups like
laptops,servers, ordatabase. A device is always in exactly one group; anything you don’t place explicitly lives in the built-indefaultgroup. - Connections — you add allow rules between groups: “this group may reach that group.” Everything not explicitly allowed is blocked.
Rules connect groups, never individual devices or IP addresses. To change what a device can reach, move it to a different group or add a connection between groups.
Three rules of thumb
- Same group → always allowed. Devices in the same group can always reach each other, on every port. (This is implicit and never stored as a rule.)
- Different groups → blocked until you allow them. There are no “deny” rules and no wildcards. You describe what is allowed; everything else is denied automatically.
- You never write “deny everything.” Default-deny is the baseline, so the policy stays small — it only ever lists the traffic you want.
Connections have a direction
The firewall is directional. A connection between two groups can be:
| Symbol | Meaning |
|---|---|
↔ | Two-way — either group may start a conversation with the other |
→ | One-way — only the left group may initiate to the right |
← | One-way — only the right group may initiate to the left |
New connections default to two-way (↔), so a single gesture means “these groups can talk.” You can narrow it to one-way afterwards — useful when, say, laptops should reach a database but the database should never initiate back.
Connections can be limited to specific ports
By default a connection allows all ports. You can restrict it to specific protocol/port combinations instead. Each entry is one of:
| Form | Examples |
|---|---|
proto/port | tcp/22, tcp/443, udp/53 |
proto/range | tcp/8000-8100 |
| protocol only | icmp, any |
Valid protocols are tcp, udp, icmp, and any. Ports are per direction, so a two-way connection can allow different ports each way (for example tcp/5432 one way, ping-only icmp back).
The three editing views
Open Access Control in the dashboard sidebar. The Map tab is the policy editor, and there are three equivalent ways to add a connection — use whichever fits how you think:
| View | How you add a connection |
|---|---|
| Map | Drag from the edge of one group node to another |
| Matrix | Click the cell where a “from” row meets a “to” column |
| List | Click Add connection and pick the two groups |
All three edit the same underlying policy — switching tabs never loses your work.
Test before you trust
Use Test reachability (top-right) to check a source/destination pair against your current, unsaved policy before you commit. It returns one of:
- Two-way — both groups can initiate to each other
- One-way — allowed in a single direction
- Blocked — not allowed
- Same group — always reachable, on all ports
Changes apply as soon as you Save — no restart, no client reconnect needed. You can also Export your saved policy as JSON for backup or version control (the dashboard is the editor; there is no JSON import).