IP allowlisting

Build the rule from three fields

Construct the allowlist from ${SOURCE_IP} as IPv4 source, UDP as transport, and the port recorded for this customer destination. When CIDR notation is required, write the source as ${SOURCE_IP}/32.

Every datagram sent by shredstream.sh comes from ${SOURCE_IP}. The same allowlist covers initial proof and continuing shred traffic. Keep it active before, during, and after destination verification.

Do not allow a guessed subnet. Avoid the following internet-wide range when a source-specific rule is possible:

0.0.0.0/0

Do not constrain source port, since this contract supplies no value for it.

Understand the authentication boundary

Raw UDP does not provide request headers that could carry an API key. The receiving process initiates no provider connection and establishes no authenticated session. IP allowlisting is the documented control for delivery authentication.

The firewall rule limits admitted traffic to the fixed sender address. Published facts do not define encryption, a secret inside stream datagrams, or an added per-packet cryptographic signature from the delivery service.

Proof of destination control is a separate activation control. It confirms receipt of a one-time challenge at the configured pair. Continuing admission from the source still depends on this allowlist.

Inventory enforcement points

List every device or policy that can drop traffic between the public address and process. Possible layers include cloud security controls, a network ACL, edge firewall, NAT gateway policy, host firewall, container policy, and source checks inside the application.

1. Identify the public interface that owns the destination IP.
2. Identify the destination UDP port at that interface.
3. Identify each upstream filtering layer.
4. Identify any translated internal port.
5. Identify the receiver's host firewall.
6. Identify the receiver's bind address.
7. Identify how the application checks packet sources.

Install an equivalent rule at each applicable firewall. A later allow cannot override an earlier drop. Preserve the original source through customer-controlled proxies when the final application checks ${SOURCE_IP}.

Verify the rule before activation

Start a receiver before requesting the challenge. In this capture, replace 9000 with your registered port:

sudo tcpdump -n -i any -c 1 'src host 203.23.178.228 and udp dst port 9000'

Request a challenge while the command waits. Only one proof datagram follows a request. If it is lost, use the dashboard to issue another.

When one packet appears, verify receipt through the application as well. A packet visible only in tcpdump points toward local firewall policy, socket binding, container namespace, or the receive queue.

If the command shows no packet, inspect the registered public pair, cloud rules, edge rules, routing, and NAT mapping. Do not change the source filter to a broad public range before confirming the exact rule placement and counters.

Keep source and destination roles distinct

The source is always ${SOURCE_IP} under the current product contract. Customer configuration supplies the public destination pair. Reversing these roles makes a rule incapable of matching inbound service traffic.

For a destination port of 9000, the logical rule is:

source: 203.23.178.228/32protocol: UDPdestination port: 9000

No source-port condition is present. No TCP rule is required for the packet path. Dashboard access may use other protocols, but dashboard networking is outside this delivery rule.

Update rules during an address change

Changing the customer IP or port requires re-verification. Prepare the rule for the new pair before saving the address in the dashboard. Retain ${SOURCE_IP} as the source and change only the customer-side destination match.

When NAT translates the destination port, the public firewall matches the external port and the host firewall may match the internal port. Document both. The exact observation point determines which destination field a rule sees.

Remove the obsolete customer-side rule only after confirming traffic on the new receiver. Provider-side parallel delivery during a change is not currently specified.

Avoid dynamic discovery

Do not add sources automatically from observed packet traffic, reverse DNS, geolocation, or a hostname lookup. The product facts define one literal source IP and no discovery endpoint or rotation protocol.

Do not use a cloud service tag unless it resolves specifically to ${SOURCE_IP}/32. A larger tag admits addresses that are not documented service sources.

An address-rotation notice period, secondary source, failover address, and signed allowlist document are not currently specified. Treat any packet from another source as unrelated until the source of truth changes.

Monitor the control

Use firewall rule counters when the platform provides them. Compare increments with packet-capture counts and application receive counts over one UTC interval. A rule counter that stays at zero indicates that traffic did not match that rule at that observation point.

Alert on unauthorized source traffic separately from missing authorized traffic. Unrelated UDP can reach a broad public interface even when the application discards it. Keep those packets out of service health calculations.

Review the rule after firewall deployments and destination changes. A destination can remain verified while a customer policy change blocks the stream. UDP has no persistent connection to signal that the rule was removed.