Find out why a connection is blocked

When an application times out calling something, the boundary's network rules are one of the first things to rule out. Open the boundary and its Network tab. It needs boundaries/network/read, which Owner, Contributor and Reader all have.

See what was blocked

The top of the tab reports real traffic:

1. Pick the Period, from the last 15 minutes to the last 7 days. The default is the last 4 hours, and everything on the tab follows it.
2. Read the three tiles: how many connections were blocked, how many distinct destinations were involved, and when the most recent block happened.
3. Under Blocked connections, the chart splits blocks into outbound and inbound over time. A spike that lines up with a deployment answers "did my change cause this?". Show these numbers as a table gives the same figures as a table.
4. In the log below it, each row is one workload, other end, port and direction, with the number of attempts and when the last one happened. Choose Why? on a row for the reason and, where there is one, the change that would allow it. When the period holds more rows than can be shown, the log says so; narrow the period to see the rest.
5. Who talks to whom shows every connection in the boundary over the period, as a Diagram or a List, with blocked connections marked.

The other end of a connection is described, never named: "a different boundary", "an address outside the cluster", "platform services". Nothing about another boundary's workloads is shown.

When the tab says it has nothing to show

Blocked-traffic records come from the cluster's network layer, and not every cluster provides them. On such a cluster the tab says Not available on this cluster yet instead of showing an empty log — an empty log would wrongly read as "nothing was blocked". Your platform administrator can turn the records on. The check below works either way.

Ask whether a connection would work

Can this reach that?, folded away at the bottom of the tab, answers from the boundary's rules, so it needs no traffic and works before a deployment as well as after one.

1. Choose Open.
2. Under From, pick the Starting point — a container instance, app, function, database or build job, or Another workload in this boundary — then its Resource group and, optionally, the Workload. Leave the workload empty to ask about any workload in the group, for example one that does not exist yet.
3. Under To, pick the Destination — an address outside the cluster, a container instance, app, function or database in this boundary, platform services, a different boundary, the ingress controller, or DNS. For an address, enter one address, not a range.
4. For a database, on either side, pick its Database firewall setting, the same choice as the database's own Firewall: Anything in this boundary (default), Only its own resource group or Anything on the cluster. The answer depends on it.
5. Pick the Protocol (TCP, UDP or SCTP) and the Port, and choose Check.

The answer is Allowed or Blocked, with a sentence explaining why. Rules considered lists every grant that applies to the workload in that direction. For an outbound connection to an address outside the cluster on a closed port, How to allow it shows the exact address, protocol and port an outbound rule would need; such rules cannot be added today. When the block is the platform's own fault, the answer says so and there is nothing for you to change. The reasons and grants are listed in Network rules and reasons.

When the resource group is on several clusters

The check runs against one cluster. When the resource group you picked exists on more than one, the check asks you to name the cluster, and the portal form has no field for it. Ask through the API instead, with the cluster's ID in clusterId:

POST https://api.example.com/boundaries/<boundary-id>/network/check
Content-Type: application/json

{
  "from": { "kind": "app", "resourceGroup": "<namespace>", "name": "web" },
  "to": { "kind": "cidr", "value": "203.0.113.10" },
  "protocol": "TCP",
  "port": 5432,
  "clusterId": "<cluster-id>"
}

resourceGroup is the resource group's namespace name, rg-….