> ## Documentation Index
> Fetch the complete documentation index at: https://docs.suji.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# Firewall

> Default-deny inbound firewall with one-click rules. Where to allow traffic, what's pre-allowed, what can never be opened.

The **Firewall** tab lets you control inbound traffic to your VM's **public IP**. The default is restrictive — only SSH (and the dashboard's control plane) is allowed.

Apps reached via the **tunnel hostname** (`<sub>.suji.fr`) don't need firewall rules — they ride Cloudflare Tunnel and never bind a public port.

## Inbound rules

Each rule has:

* **Direction** — `Inbound`.
* **Protocol** — TCP, UDP, or ICMP.
* **Port** — a single port (`443`) or a range (`3000-3010`). Valid range: 1–65535.
* **Source IPs** — one or more IPs or CIDRs. Use `0.0.0.0/0` + `::/0` for "anywhere" (the **Any IPv4** / **Any IPv6** pills). Use a specific IP / CIDR for "only my office".
* **Description** — free-form text, shows in the rules list.

Add rules with the **+ Add Rule** button next to the section. Each change is committed immediately — no two-stage save.

## Outbound rules

Mostly cosmetic — the VM allows outbound traffic by default. Add an outbound rule only if you want to **restrict** outgoing connections (e.g. deny everything except a specific webhook target).

## Pre-managed rules

Two rules are always present and **cannot be removed**:

### Platform rule

Allows Suji to manage the VM — it powers the dashboard's Terminal / Files / Logs / Metrics tabs. Locked to Suji's own addresses; removing it would break those tabs.

### Default SSH rule

Open `tcp/22` from `0.0.0.0/0`. This is a fallback so you don't lock yourself out by accident. **As soon as you add your own inbound TCP/22 rule** (e.g. SSH from your office only), this default disappears. You replace it, you don't delete it.

## Provider-blocked ports

Some outbound ports are blocked **at the network layer**, before any Suji firewall rule. Allowing them in the firewall does nothing.

* **TCP 25** (SMTP) — blocked outbound for anti-spam.
* **TCP 465** (SMTPS) — blocked outbound.
* **TCP 587** (Submission) — open. Use this for outbound mail.

If your app needs to send email, use an authenticated relay on 587 (Postmark, SendGrid, Mailgun, Resend) or an HTTP-API provider.

## Common patterns

<AccordionGroup>
  <Accordion title="Open HTTP/HTTPS on the public IP">
    Most users don't need this — apps are reached via the tunnel. If you have a non-HTTP service that has to be on the IP, add:

    * Inbound `tcp/80` from `0.0.0.0/0` + `::/0`
    * Inbound `tcp/443` from `0.0.0.0/0` + `::/0`
  </Accordion>

  <Accordion title="Lock SSH to your office">
    Add an inbound `tcp/22` rule with your office's public IP/CIDR as the source. The default open-world SSH rule disappears once your custom rule lands.
  </Accordion>

  <Accordion title="Open a game / database port">
    Add the inbound port + protocol with the right source IPs. Use a CIDR (e.g. `10.0.0.0/8`) rather than `0.0.0.0/0` for anything sensitive.
  </Accordion>

  <Accordion title="Allow incoming UDP only from a specific peer">
    Add an inbound `udp/<port>` rule with that peer's IP as the source.
  </Accordion>
</AccordionGroup>

## Audit

Every rule change shows in the audit log (org-level): who added/removed which rule, when, from which IP.

## Next

<CardGroup cols={2}>
  <Card title="Network" icon="network-wired" href="/manage-vm/network">
    See the public IPs you're protecting.
  </Card>

  <Card title="Snapshots" icon="camera" href="/manage-vm/snapshots">
    Restore a known-good VM state if a firewall change goes sideways.
  </Card>
</CardGroup>