Interactive Authorization
This chapter covers the Interactive Authorization mechanism in MSST-Net.
What Is Interactive Authorization
Interactive Authorization is MSST-Net's default mechanism when no matching firewall rule exists.
When a device tries to access a port on your device but no existing rule matches, the system does not immediately deny the request. Instead, it sends an authorization request to the controller for the user to decide in real time.
Trigger Conditions
Interactive Authorization is not triggered for all unknown traffic. Only connection requests from the following sources trigger an authorization notification:
| Condition | Description |
|---|---|
| Other devices on your account | Devices on the same account can trigger it by default |
| Recently contacted devices | Devices that have recently communicated with your device |
| Devices explicitly referenced in rules | Connections from devices whose ID appears in any firewall rule |
| Room member devices | In Room Mode, all members in the room |
Connection requests that do not meet any of the above conditions are silently dropped without any notification.
Authorization Request Contents
When Interactive Authorization is triggered, the controller receives:
- Source device ID
- Source device display name (if known)
- Associated user information (if known)
- Target protocol (TCP / UDP)
- Target port
- Service name (if it matches a known service, e.g., Minecraft, SSH)
Authorization Decisions
The user can make one of four decisions in the controller:
| Decision | Meaning |
|---|---|
| Allow Once | Temporarily allow this connection, expires after 10 minutes |
| Always Allow | Permanently allow, automatically creates an allow rule |
| Deny Once | Temporarily deny this connection, expires after 10 minutes |
| Always Deny | Permanently deny, automatically creates a deny rule |
Choosing "Always Allow" or "Always Deny" automatically generates the corresponding firewall rule and saves it permanently.
Packet Buffering
Interactive Authorization handles TCP and UDP differently.
TCP
When an authorization request is triggered, the system immediately sends a TCP RST back to the sender, notifying the remote side that the connection was refused (ECONNREFUSED).
If the user chooses Allow, the remote side can retry the connection after authorization is approved, and the connection succeeds normally.
If the user chooses Deny, subsequent connection attempts are matched by the deny rule and rejected.
TCP uses RST instead of buffering because connection setup depends on handshake timing — buffering a SYN and replaying it later typically fails because the remote application has already timed out. An immediate RST gives the remote side fast, clear feedback and lets it retry as soon as authorization is granted.
UDP
When an authorization request is triggered, the packets that triggered it are temporarily buffered (up to 32 packets or 256 KB).
If the user chooses Allow, the buffered packets are immediately forwarded to your device after authorization, and the connection continues seamlessly.
If the user chooses Deny, the buffered packets are discarded.
Timeout
Authorization requests that receive no response within 60 seconds of being sent are considered timed out.
After timeout, the buffered packets are discarded and the request's status in the access log is updated to silently denied.
Relationship with Firewall Rules
Interactive Authorization complements firewall rules — together they form a complete access control system:
- Rules take priority: If a matching firewall rule exists, it is applied immediately without triggering Interactive Authorization
- Triggered when no rule matches: Interactive Authorization only activates when no rule matches
- Authorization can become rules: Choosing "Always Allow/Deny" automatically generates a rule, so future identical connections no longer trigger authorization
Related
- Firewall Rules — Proactively configure access control rules
- Permission Groups — Group devices into permission groups to simplify rule management