Restrict inbound access to app ports

Inbound access is a per-application allowlist for the non-HTTP ports an application publishes on your server: managed databases, game servers, RustDesk, DNS and other raw TCP or UDP services. Every application starts open. You choose which ports to restrict and which address ranges may reach each one; everyone else is dropped by the server's firewall, which the Impreza agent manages for you.

What it covers — and what it does not

Covered	Not covered
The TCP and UDP ports an application publishes directly on the server (apps with raw ports, alone or next to a web interface).	HTTP and HTTPS. Web traffic goes through the managed proxy; protect it with Impreza Shield.
One allowlist per application, per port and protocol.	SSH and the shared proxy ports: `tcp/22`, `tcp/80`, `tcp/443` and `udp/443` are reserved and can never be restricted.
IPv4 and IPv6 sources, written as CIDR ranges.	Ports the application does not publish, and services you run on the server outside Impreza.

Restricting a port only filters new connections arriving from outside the server. Connections that are already established keep going, and the server's own containers and local processes keep reaching the service.

An allowlist is not authentication. Keep the service's own password or keys: the allowlist narrows who can try, it does not prove who is connecting.

Before you start

The application publishes at least one non-HTTP port. Applications that only serve the web have nothing to restrict here, and the portal shows no card.
The server's agent is 0.6.25 or later and reports support for inbound access. 0.6.26 or later is recommended; see agent requirement.
Reading needs the read scope. Changing an allowlist needs the manage scope. In the portal, viewing the state is available to anyone who can see the app; changing it needs the account owner or a team member with Manage Products & Services.
Know the public address ranges your clients connect from. Use the narrowest range that works: a single IPv4 address is /32, a single IPv6 address is /128.

Restrict ports in the portal

Open My Apps and switch to Advanced view.
On the application's card, open App settings → Inbound access. The summary shows the current state: open, restricted with enforced, pending or not enforced, or agent update required.
The card lists every published port with its label and whether it is open to everyone or how many ranges may reach it.
Tick Restrict next to each port you want to close, and enter the allowed ranges in its box, one per line (commas also work).
Select Save allowlist and confirm. The confirmation warns that anyone outside the listed ranges, possibly including you, is blocked from those ports.
The card shows pending until the agent applies the change, usually in under a minute, then enforced. Reload the page to see the update.

To remove every restriction, select Open all ports and confirm. The saved ranges are deleted and every published port becomes reachable from anywhere again. A port you leave unticked when saving is open.

The portal deliberately has no "use my IP" button: it would have to store the address you are browsing from.

Read and change the allowlist

The allowlist is always sent as the complete desired state, never as a change to apply on top of the previous one:

rules lists only the restricted ports, each with its port, protocol (tcp or udp) and sources.
A published port that is not in rules is open to everyone.
rules: [] opens every port again.
base_revision is the revision you read. If the allowlist changed since then, the write is refused with 409 REVISION_CONFLICT and nothing changes: read it again, reapply your edit and save.

MCP

Read the current state with impreza_get_ingress:

{"deployment_id":"dpl_<your-deployment-id>"}

Then replace it with impreza_set_ingress. Restricting can block your own connections, so a call with a non-empty rules list requires confirm: true; opening every port does not.

{
  "deployment_id": "dpl_<your-deployment-id>",
  "base_revision": 3,
  "rules": [
    {"port": 5432, "protocol": "tcp", "sources": ["203.0.113.0/24", "2001:db8::/48"]},
    {"port": 27015, "protocol": "udp", "sources": ["198.51.100.7/32"]}
  ],
  "confirm": true
}

To open every port again:

{"deployment_id":"dpl_<your-deployment-id>","base_revision":4,"rules":[]}

Both tools are available on the hosted MCP connector and in the local impreza-mcp package from version 0.52.0.

REST API

Method	Path	Scope	Purpose
`GET`	`/v1/platform/deployments/{id}/ingress`	`read`	Read the ports, the revision and the status.
`PUT`	`/v1/platform/deployments/{id}/ingress`	`manage`	Replace the allowlist. Body: `{"base_revision": N, "rules": [...]}`.
`DELETE`	`/v1/platform/deployments/{id}/ingress?base_revision=N`	`manage`	Open every port again (same as `PUT` with `rules: []`).

PUT and DELETE answer 202 Accepted with the same view as GET: the change is saved and queued for the agent, not yet enforced. The body accepts only base_revision and rules.

The example keeps the credentials out of the command line and shell history, as in the MCP credential example:

(
  : "${IMPREZA_API_URL:?Set the official REST base URL}"
  : "${IMPREZA_API_KEY:?Load the account REST key}"
  : "${IMPREZA_API_SECRET:?Load the account REST secret}"
  : "${DEPLOYMENT_ID:?Set the deployment id}"
  curl --fail-with-body --silent --show-error --proto '=https' --config - \
    --request PUT --header 'Content-Type: application/json' \
    --data '{"base_revision":3,"rules":[{"port":5432,"protocol":"tcp","sources":["203.0.113.0/24","2001:db8::/48"]}]}' <<EOF
url = "${IMPREZA_API_URL}/v1/platform/deployments/${DEPLOYMENT_ID}/ingress"
header = "X-API-Key: ${IMPREZA_API_KEY}"
header = "X-API-Secret: ${IMPREZA_API_SECRET}"
EOF
)

The data of a read looks like this:

{
  "deployment_id": "dpl_<your-deployment-id>",
  "revision": 4,
  "status": "enforced",
  "reason": null,
  "applied_revision": 4,
  "reported_at": "<timestamp>",
  "agent": {"supports_ingress": true, "minimum_version": "0.6.25"},
  "ports": [
    {"port": 5432, "protocol": "tcp", "label": "PostgreSQL", "state": "restricted", "sources": ["203.0.113.0/24", "2001:db8::/48"]},
    {"port": 8080, "protocol": "tcp", "label": null, "state": "open"}
  ]
}

An application that does not belong to the credential's account answers 404, like every other deployment route.

Sources and limits

Limit	Value
Restricted ports per application	32
Sources per port	64
Sources per application, all ports together	512

Each source must be a CIDR range in its network form:

IPv4 such as 203.0.113.0/24 or IPv6 in hex groups such as 2001:db8::/48. A single address is /32 or /128.
Host bits must be zero: 203.0.113.5/24 is refused with HOST_BITS_SET; write 203.0.113.0/24 or 203.0.113.5/32.
A range, or a set of ranges, that covers every IPv4 or every IPv6 address is refused with SOURCE_TOO_BROAD. That would not be a restriction: leave the port open instead.
IPv4-mapped IPv6 (::ffff:…) and IPv6 written with an embedded IPv4 address are refused. Use the IPv4 range itself.
Repeated sources and repeated ports are refused.

Other refusals: a port the application does not publish answers 422 PORT_NOT_PUBLISHED; a reserved port answers RESERVED_PORT; a server whose agent cannot enforce allowlists answers 409 AGENT_UPDATE_REQUIRED when you try to restrict a port. Every refused write changes nothing. Error messages name the position of a bad source, such as rules[0].sources[1], never the address itself.

Statuses and reasons

Status	Meaning
`open`	No port is restricted. Every published port is reachable from anywhere.
`pending`	A new revision is saved and waiting for the agent, usually under a minute. Until then the previous state holds on the server.
`enforced`	The agent proved that this exact revision is live on the server.
`not_enforced`	The agent could not apply this revision. `reason` says why. Treat the restricted ports as reachable by everyone.
`agent_update_required`	Restrictions are saved, but the server's agent cannot enforce them. The response includes the minimum agent version.

enforced is only shown when the agent reports the current revision with a matching fingerprint of the saved rules; a revision the agent has not confirmed is never shown as enforced.

When the status is not_enforced, the new revision is not in force. A restriction that was never enforced leaves its ports open. Rules from an earlier enforced revision may still be in place on the server until a later revision applies.

Reason	Meaning
`iptables_unavailable`	The firewall tooling the agent uses is not available on the server.
`ipv6_unavailable`	The server has a routable IPv6 address, but the IPv6 firewall is unavailable, so the allowlist could not be applied to IPv6 traffic.
`apply_failed`	Installing the firewall rules failed on the server.
`reset_locally`	Someone ran `impreza-agent ingress reset` on the server. The allowlist stays off until you save a new revision.
`port_not_published`	The agent did not find a restricted port published by this application's containers on the server.
`invalid_policy`	The agent's own validation refused the allowlist it received.
`fingerprint_mismatch`	The agent reported rules that do not match the saved revision, so the revision is not counted as enforced.
`missing_on_agent`	The agent reported no allowlist for this application.
`agent_rejected`	The agent refused or failed the update for another reason, for example when the server's public network interface is a Docker bridge.

To recover, fix the cause on the server if there is one, then save the allowlist again; the new revision is sent to the agent.

Alerts

The first time you restrict a port on an application, an ingress_not_enforced alert rule is created for it automatically: enabled, with a one-minute window. If the application already has a rule for that metric, even a disabled one, it is left as it is.

The alert opens when restricted ports have stayed not_enforced for the rule's window, and closes when the condition clears. Like other alerts, it is recorded in the portal and delivered to your account webhook as deployment.alert; read it with impreza_list_alerts and change the rule with impreza_set_alert_rule. See metrics and alerts.

The alert evidence contains the reason, the affected ports, the revision and how long the allowlist has not been enforced. It never contains an address range.

Agent requirement

Inbound access needs agent 0.6.25 or later on a server where the agent can manage the firewall; the agent reports the capability only there. Agent 0.6.26 or later is recommended: every update from 0.6.26 installs or repairs the boot unit that restores your allowlists before Docker starts after a reboot. The agent also re-applies the rules when a firewall reload or Docker removes them.

Servers are never updated automatically. Update from the server card in My Apps or with the commands in update your agent, wait for the agent's next check-in, then save the allowlist again if it showed agent_update_required.

Locked yourself out?

SSH (tcp/22) and the proxy ports are reserved and never restricted by an allowlist, so you can still reach the server and the portal keeps working.

In the portal, select Open all ports, or save the allowlist with your current range added.
Through MCP or REST, write rules: [] or a corrected list.
On the server, sudo impreza-agent ingress status shows each application's revision and enforcement without printing any source. sudo impreza-agent ingress reset removes every allowlist on the server at once, opening all published ports. The portal then reports not_enforced with reset_locally until you save the allowlist again.

Privacy

An allowlist can contain your own addresses, so they are handled narrowly:

Sources are stored only to enforce the allowlist. The request body is kept out of the request log, and command results, heartbeats and alerts carry revisions and fingerprints, never a source.
Error messages point to the position of a bad source, not its value.
The saved ranges are deleted when you open all ports, uninstall the application or delete the account.

Related reference

Impreza Shield protects HTTP and HTTPS routes.
Metrics and alerts for alert rules and webhook delivery.
Update your agent for versions and update commands.
REST API reference for authentication headers and the response envelope.