LearnDocsLog inDeploy a serverDeploy

Port rules

Opening a port with an inbound rule, the values the panel accepts, the 15-rule cap, and what changes when you edit or delete one.

DDoS protection6 min read

On this page
  1. What a rule is, and why a port needs one
  2. Adding a rule
  3. Restricting what the port accepts
  4. Values the panel accepts
  5. A server can hold 15 rules
  6. Editing a rule
  7. Deleting a rule
  8. Related

An inbound rule opens one port on one protocol and carries the settings Prism applies to traffic arriving there. Everything you tune per port, the rate ceilings, the source restrictions, and the protection engines, hangs off a rule.

Servicesyour serverFirewallInbound rules
The Inbound rules tab. The Default for unlisted ports sits above the rules, each rule is one row with its protocol, port and policy, and the pencil, copy and bin icons on a row edit, duplicate and remove it. Step 1 of adding a rule is the Add rule button. Example view.

What a rule is, and why a port needs one

Inbound rules are an allow-list. A rule names the port, the protocol, and the service you actually run there, and that is what tells Prism how to judge the traffic: which protocol validator to run, which packet-rate ceilings apply, and which sources are acceptable.

A port with no rule of its own is not unprotected, but it is not tuned either. It falls to the Default for unlisted ports setting on the same tab: under Allow it stays reachable and is filtered only by the always-on protections, and under Deny all it is dropped. See The Firewall tab.

A packet arrivesUDP, to port 30120 on 203.0.113.10Is there a rule for UDP 30120?Same protocol, and the port or the range covers 30120NoDefault for unlisted portsAllow: reachable, behind thealways-on protections onlyDeny all: droppedYesWhat the rule checks, in orderAlongside, where they apply: the engines (TCP fingerprint,Signature (zero-day), UDP first-packet challenge), on bydefault.RestrictionsProxied sources only, Drop UDP on this portBoth off on a new ruleDropped, if switched onProxied only: sources outsideproxy and CDN rangesDrop UDP: every UDP packetRate limitsWhole port and Per connection, packets/sec0 on a new rule: no ceilingDroppedPackets over a ceilingProtocol validation (L7)Does the traffic speak the service's protocol?Off on a new ruleDroppedTraffic that does not speakthe service's protocolYour service on UDP 30120Receives only what passed every checkA packet arrivesUDP, to port 30120 on 203.0.113.10Is there a rule for UDP 30120?Same protocol, and the port or the rangecovers 30120No: Default for unlisted portsAllow: reachable, behind the always-onprotections onlyDeny all: droppedYesWhat the rule checks, in orderAlongside, where they apply: the engines (TCPfingerprint, Signature (zero-day), UDPfirst-packet challenge), on by default.RestrictionsProxied sources only, Drop UDP on this portBoth off on a new ruleDropped, if switched onProxied only: sources outside proxy andCDN rangesDrop UDP: every UDP packetRate limitsWhole port and Per connection, packets/sec0 on a new rule: no ceilingDroppedPackets over a ceilingProtocol validation (L7)Does the traffic speak the service'sprotocol?Off on a new ruleDroppedTraffic that does not speak the service'sprotocolYour service on UDP 30120Receives only what passed every check
What a packet meets on its way to a port. With no rule for its protocol and port, the Default for unlisted ports decides. With a rule, it passes the rule's checks in order, and any of them can drop it; the engines run alongside, where they apply. On a new rule the switches are off, the ceilings are 0 and protocol validation is off, so the rule opens the port and those checks wait for you to set them. Illustration.

Two things about a rule's shape are worth knowing before you add one:

  • A rule is TCP or UDP, never both. A service that needs both, such as a FiveM server, needs two rules.
  • A rule is identified by its start port and protocol together. Only one rule can own a given pair, so there is one TCP 30120 rule and one UDP 30120 rule, not two of either.

Adding a rule

The Add port rule dialog as it opens. The numbers match the steps below; step 1 is the Add rule button on the tab. Example view.

  1. Open the dialog

    Press Add rule in the top right of the Inbound rules card. The dialog is titled Add port rule and describes itself: "Open a port (or range). Cap its packet rate, restrict sources, drop UDP, and choose which protection engines run on it."

    It opens neutral. Service sits on Generic / custom, Port is blank, and nothing is written until you press the button at the end.

  2. Pick the Service

    Service is a grouped list: Infrastructure, Web, Database, VPN, Voice, Game servers, and Other. Pick the service you actually run on the port, because Prism uses it to decide which protocol checks are even possible. An entry suffixed · L7 ships a protocol validator; see Protocol validation.

    Picking a service fills Port and Protocol in for you from that service's usual defaults, and clears the range end. Anything you type afterwards wins. Generic / custom has no canonical port, so it leaves the fields alone for you to fill in.

  3. Set the Protocol

    TCP or UDP. If the service picker filled this in and your server runs the service somewhere unusual, change it here.

  4. Enter the Port

    A whole number from 1 to 65535. A blank or invalid port is rejected with "Enter a valid start port (1-65535)."

  5. Set the range end, if you need one

    The field labelled to (optional) covers a contiguous range. Leave it blank for a single port. Filled in, it must be a whole number, no lower than Port, and no higher than 65535, or the panel refuses with "End port must be ≥ start port and ≤ 65535."

  6. Set the rate limits, if you know your traffic

    The Rate limits group holds Whole port, packets/sec (0 = unlimited) and Per connection, packets/sec (0 = service default). Both start at 0. They depend on each other and the numbers matter, so they have a page of their own: Rate limits. Leaving both at 0 is a valid rule.

  7. Choose the switches

    Below the rate limits are Proxied sources only and Drop UDP on this port, described in the next section, then Protocol validation (L7) and the per-rule engine switches, covered on Protocol validation.

  8. Press Add rule

    The rule appears in the table above. It takes effect on your server at its next configuration poll, within about 30 seconds.

Restricting what the port accepts

Two switches on the rule narrow which packets are acceptable at all, before any rate limit or detection engine is involved.

SwitchFieldWhat it does
Proxied sources onlyonly_proxied"Accepts traffic only from known proxy or CDN source ranges." Ordinary players connecting directly are not in those ranges, so use it only where every legitimate client genuinely arrives via a proxy or CDN.
Drop UDP on this portdisallow_udp"For services that are TCP only. Discards every UDP packet aimed here." On a UDP game that is every player.

Both are off on a new rule.

On a TCP-only service, TCP 443TCP visitors pass; only the UDP is dropped.Packets per second, relativeUDP floodVisitors, over TCPTimeAcceptedDroppedOn a UDP game, UDP 30120The players are UDP too: every packet is dropped.Packets per second, relativePlayers, droppedTimeAcceptedDropped
The same switch on two ports. Drop UDP on this port discards every UDP packet aimed at the port, whatever sent it. On a TCP-only service that is only the junk; on a UDP game it is every player, and the server looks down. Illustration: relative, not measured.

Values the panel accepts

Both the browser and the server check a rule before it is written:

FieldAccepted
PortA whole number, 1 to 65535
to (optional)Blank, or a whole number no lower than Port and no higher than 65535
ProtocolTCP or UDP
Rate limitsZero or above

Ownership is re-checked on the server for every change, so a rule can only ever be written against a server on your own account.

If the start port and protocol already belong to another rule, the panel names the clash rather than overwriting anything, with a message such as "A TCP rule starting at 3389 already exists." Edit the existing rule instead of adding a second one.

A server can hold 15 rules

Plan the 15 rather than spending them. A service needing both TCP and UDP costs two, and a contiguous range costs one rather than one per port, so use to (optional) where the ports really are adjacent.

One server's rules, planned two waysTen adjacent ports added one by oneFiveMSSH10 single-port rules13 of 15The same ports as one rangeFiveMSSH4 of 1515 per server051015Inbound rules on the serverFiveM: TCP and UDP, 2 rulesSSH: 1 ruleTen adjacent portsOne server's rules, planned two waysTen adjacent ports added one by one10 single-port rules13 of 15The same ports as one range4 of 1515 per server051015Inbound rules on the serverFiveM: TCP and UDP, 2 rulesSSH: 1 ruleTen adjacent ports
One server planned two ways. FiveM costs two rules because it needs TCP and UDP. Ten adjacent ports cost ten rules added one by one, or one as a range. Derived from the limits on this page; example rules.

Editing a rule

The pencil on a rule's row opens the same dialog, titled Edit port rule, pre-filled from the rule as it stands. The button reads Save changes.

The other trap in editing is the Service picker. Changing it rewrites Port and Protocol from the new service's defaults and clears the range end, exactly as it does on a new rule. If you only wanted to relabel a rule, you have moved it: either onto a different port, or onto one another rule already owns, which returns the collision error above. Check Port and Protocol after changing Service, every time.

Relabelling a generic rule for TCP 8080 to 8090 as HTTP / HTTPS rewrites it to TCP 80 and clears the range end. Saving would move the rule onto TCP 80 alone and leave 8080 to 8090 without a rule, or, if a TCP 80 rule already exists, the panel refuses with “A TCP rule starting at 80 already exists.” Example view.

A saved edit reaches your server at its next configuration poll, within about 30 seconds. If a change turns out to be too strict, work through When players cannot connect.

Deleting a rule

The bin icon on a rule's row asks you to confirm, on a dialog titled Remove this rule? naming the rule and stating the effect: "…will no longer be reachable. Anything connecting to it is dropped at the edge from the next config poll." The buttons are Cancel and Remove rule.

Deleting is also the only way to change a rule's Disabled status, because there is no control anywhere in the panel that enables or disables an individual rule. If a rule reads Disabled, note its settings, delete it, and add it again.

Rate limits

The two packet-rate ceilings a rule carries, and how they depend on each other.

Protocol validation

The L7 switch and the three per-rule engine toggles.

Game presets

Adding several rules at once for a known workload.

When players cannot connect

Working out which rule is dropping real traffic.

On clouduxe.com. The pages on the main site that go with this guide.

clouduxe.com/ddos-protectionDDoS protectionThe filter in front of every server, and what it stops.clouduxe.com/ddos-protection/how-it-worksHow the filter worksFrom the upstream network to your server, layer by layer.clouduxe.com/ddos-protection/game-serversGame server protectionWhich games get protocol validation and which run on port presets.

Need a server, or a hand with one?

Pick a plan to deploy a server, or open a ticket in the panel. Support runs 24/7/365.

Deploy a serverTalk to support