All-Ports Listener

The all-ports listener is a single listener that matches every port on its protocol — one rule covers every TCP (or UDP) destination port from 1 to 65535. Use it for workloads where the destination port is part of the protocol and the backend already knows how to handle every port itself.

How It Works

All-ports listener: every destination port preserved end-to-end

A client connecting to any port on the VIP is matched by the listener, the scheduler picks a healthy backend, and the client's destination port is preserved on its way to the backend. Different flows on different ports may land on the same or different backends — the port stays the same end-to-end.

For this to work, the backend's port must be configured as "same as listener port." See Backend Servers for the field.

When to Use, When Not To

Scenario	Use it?	Why
Backends use the destination port as part of the protocol — FTP active mode, RTSP / RTP, MMO and game servers, dynamic-port custom protocols	✅ Yes	One listener rule covers the whole port surface; the original destination port reaches the backend unchanged.
Passthrough VIP in front of a service where every port decision belongs to the backend	✅ Yes	Keeps the LB out of the port-policy choice.
You can express the workload with explicit ports — even a long list	❌ No	Explicit ports are easier to monitor, audit, and reason about.
You also want explicit-port listeners on the same protocol	❌ No	All-ports and explicit-port listeners overlap on every port; configure one or the other, not both.
Health needs to be evaluated per port	❌ No	One probe per backend covers the whole port range; partial-port failures aren't detected.

Limitations

• One protocol per listener. If you need both TCP all-ports and UDP all-ports, create two listeners.

• All ports share one backend pool, scheduler, and health check — scheduling and health behavior cannot vary across the port range.

• Per-port observability (per-port traffic counters, per-port rate limits) is not available.