SynadiaDocs

Synadia Protect

Ports

The gateway's unit of configuration is a port. A port is a named entry point — not just a TCP port number. Each port is a standalone proxy configuration with its own name (e.g., clients), network address, backend, and rule evaluation. You refer to ports by name in CLI commands like bundle activate.

The gateway currently supports two kinds of NATS protocols:

  • client — standard NATS client connections. Disconnecting or suspending a client affects only that one connection.
  • leaf — a NATS leafnode connection. A leafnode is a NATS server that routes messages between its local clients and a remote NATS cluster. Unlike a regular client, a leafnode transparently bridges traffic across network or security boundaries — disconnecting or suspending a leafnode stops all traffic flowing through that connection. See the NATS leafnode documentation for details.

NATS disconnected clients and leafnodes attempt to reconnect immediately. A suspended connection avoids this — the gateway drops all traffic but responds to PING, so the client or leafnode believes it is still connected.

Client port

ports:
  - name: clients
    kind: client
    host: 0.0.0.0
    port: 4222
    backend:
      urls:
        - nats://backend:4222

Leafnode port

ports:
  - name: leafnodes
    kind: leaf
    host: 0.0.0.0
    port: 7422
    compression: s2_fast
    backend:
      urls:
        - nats://backend:7422

Leafnode ports support an additional compression option: off, s2_fast, s2_better, or s2_best.

Multiple ports

A gateway can have multiple ports, each with its own backend. For example, you might proxy client connections to one cluster and leafnodes to another:

ports:
  - name: clients
    kind: client
    host: 0.0.0.0
    port: 4222
    backend:
      urls:
        - nats://cluster-a:4222

  - name: leafnodes
    kind: leaf
    host: 0.0.0.0
    port: 7422
    backend:
      urls:
        - nats://cluster-b:7422

Each port operates independently — its own backend, its own rule evaluation, and its own connection limits.

Rule direction

The default_rule_direction controls which direction traffic is evaluated by rules (unless a rule specifies its own direction):

DirectionDescription
to_backendrules only evaluate traffic flowing from the client/leafnode to the backend cluster
from_backendrules only evaluate traffic flowing from the backend cluster to the client/leafnode
bothrules evaluate traffic in both directions

The default is to_backend.

Rules can inspect subjects and payloads. In most cases you only need to evaluate traffic sent by clients to the backend. But in some cases you may want to inspect traffic flowing from the backend — for example, ensuring messages from the backend don't contain sensitive payload patterns. In those cases, set the direction to from_backend or both, or define individual rules that only apply to backend-originated traffic.

Unmatched action

When no rule matches a connection or message, the gateway applies the unmatched action. There are separate settings for each direction:

ActionDescription
allowforward the traffic
denyreject the traffic and disconnect the client
suspenddrop all traffic but respond to PING so the connection believes it is still alive

The defaults are both deny — the gateway blocks all traffic unless a rule explicitly allows it, preventing situations where unexpected data flows without being evaluated by any rules.

Per-port rule overrides

By default, all ports use the global rule settings from the rules section. Individual ports can override the direction and unmatched actions:

rules:
  default_rule_direction: to_backend
  unmatched_rule_to_backend_action: deny
  unmatched_rule_from_backend_action: deny
  ports:
    - name: clients
      default_rule_direction: both
      unmatched_rule_from_backend_action: deny
    - name: leafnodes
      unmatched_rule_from_backend_action: deny

Only the fields you specify are overridden — the rest fall back to the global values.

See the Configuration Reference for all available port options including TLS, connection limits, and timeouts.

Next
Rules