Firewall Rules
This chapter covers MSST-Net firewall rules.
What Are Firewall Rules
Firewall rules control which devices can access which ports and services on your device.
Each rule specifies:
- Principal: Who can (or cannot) access
- Protocol and port: Which traffic to allow or deny
- Action: Allow (
allow) or deny (deny) - Direction: Inbound (
inbound) or outbound (outbound)
Connection Tracking
The MSST-Net firewall has stateful connection tracking.
When your device initiates an outbound connection, the system automatically records the connection state. Return packets from the peer are automatically allowed — no additional rule is needed.
This means:
- Connections you initiate do not require rules for return traffic
- Rules only control inbound connections initiated by the peer
Rule Priority
When multiple rules match the same packet, the system uses the first matching rule in this priority order:
- Device-level Deny (highest priority)
- Device-level Allow
- User-level Deny
- User-level Allow
- Room-level Deny
- Room-level Allow (lowest priority)
Device-level rules take priority over user-level rules; user-level rules take priority over room-level rules.
Principal
The principal in a rule specifies which devices, users, or room members the rule applies to.
Principal Types
| Type | Description |
|---|---|
| Device | Rule applies only to the specified device |
| User | Rule applies to all devices under this user |
| Room (space) | Rule applies to all members currently in the same room as this device |
Principal Identifiers
Principals can be specified by:
| Method | Example | Description |
|---|---|---|
| Device ID | device-a7f29b3e | Exactly match the specified device |
| User ID | user-1a2b3c4d | Match all devices under this user |
| Device mnemonic | archlinux | Match the device with this mnemonic under the current user |
| Combined mnemonic | archlinux.abjust | Match the specified device under the specified user |
| User mnemonic | abjust | Match all devices under the specified user |
| Wildcard | * | Match all devices or all users |
Room wildcard (space-*) | space-* | Match all members in any currently shared room |
Room-level (space) rules do not require a specific ID — the system dynamically matches current room members when packets arrive.
For more on identifiers, see:
Protocol and Port
Rules can match specific protocols and ports.
Protocol
Supported protocols:
| Value | Description |
|---|---|
tcp | TCP traffic only |
udp | UDP traffic only |
tcp+udp | Both TCP and UDP (stored as two separate rules) |
Port
Ports can be specified as:
| Format | Example | Description |
|---|---|---|
| Single port | 25565 | Match only the specified port |
| Port range | 8000-9000 | Match all ports in the range |
| Wildcard | * | Match all ports (1–65535) |
Common Services
MSST-Net includes built-in presets for common service protocol/port combinations:
Games
| Service | Protocol / Port |
|---|---|
| Minecraft (Java Edition) | tcp/25565 |
| Minecraft (Bedrock Edition) | udp/19132 |
| Rusted Warfare | tcp/5123 |
| MSST Card Battle | tcp/9178 |
| Terraria | tcp/7777 |
| Factorio | udp/34197 |
Web Services
| Service | Protocol / Port |
|---|---|
| HTTP | tcp/80 |
| HTTPS | tcp/443 |
| HTTP/3 (QUIC) | udp/443 |
File Services
| Service | Protocol / Port |
|---|---|
| FTP | tcp/21 |
| FTPS | tcp/990 |
| NFS | tcp/2049 |
| SMB/CIFS | tcp/445 |
Databases
| Service | Protocol / Port |
|---|---|
| MySQL | tcp/3306 |
| PostgreSQL | tcp/5432 |
| MongoDB | tcp/27017 |
| Redis | tcp/6379 |
| MSSQL | tcp/1433 |
| Oracle DB | tcp/1521 |
Remote Access
| Service | Protocol / Port |
|---|---|
| SSH | tcp/22 |
| RDP | tcp/3389 |
| VNC | tcp/5900 |
Action
Each rule's action is one of:
| Action | Description |
|---|---|
allow | Allow matching packets through |
deny | Deny matching packets |
Direction
Each rule's direction is one of:
| Direction | Description |
|---|---|
inbound | Control inbound traffic from peers |
outbound | Control outbound traffic to peers |
In most cases, only inbound rules need to be configured.
Expiry
Rules can have an expiry time — they automatically expire and are removed from the list after the set time.
If no expiry is set, the rule is permanent.
Expiry is commonly used for temporary authorization (e.g., temporary rules created via Interactive Authorization).
Rule Matching Flow
When an inbound packet arrives, the system processes it in this order:
- Check if it is a return packet for a tracked connection → if so, allow immediately
- Iterate through all active rules by priority and find the first match
- If a matching rule is found, allow or deny per the rule's action
- If no rule matches, trigger Interactive Authorization
See:
Related
- Permission Groups — Group devices or users into reusable permission groups
- Interactive Authorization — Dynamic authorization when no rule matches