IP allowlisting

Build the rule from three fields

Allow source IPv4 address ${SOURCE_IP}, protocol UDP, and the customer-selected destination port. Express the source as ${SOURCE_IP}/32 when the platform requires CIDR notation.

Every datagram sent by shredstream.sh comes from ${SOURCE_IP}. This applies to the verification challenge and the live shred stream. Keep the rule active before, during, and after destination verification.

Do not allow a guessed subnet. Do not use 0.0.0.0/0 when a source-specific rule is possible. Do not filter a source UDP port because its value is not currently specified.

Understand the authentication boundary

Raw UDP does not provide request headers that could carry an API key. The customer receiver does not connect to a provider endpoint and does not establish an authenticated session. The documented delivery authentication control is IP allowlisting.

The firewall rule limits admitted traffic to the fixed sender address. The product does not specify encryption, a shared secret in each stream datagram, or an added per-packet cryptographic signature from the delivery service.

Proof of destination control is a separate activation control. It confirms that the customer can receive a one-time challenge at the configured pair. It does not replace the continuing source allowlist.

Inventory enforcement points

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

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 the application source check.

Apply the rule at every applicable firewall. One allow rule cannot override a drop that occurs earlier in the path. Preserve the original source through customer-controlled proxies when the final application depends on checking ${SOURCE_IP}.

Verify the rule before activation

Start a receiver before requesting the challenge. Then run a packet capture after replacing 9000 with the registered port:

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

Request a challenge while the command waits. The service sends one challenge datagram per request, so an earlier loss is not recovered unless you request a resend.

If the command shows one packet, confirm that the application also receives it. If the application misses a packet visible to tcpdump, inspect the host firewall, socket binding, container namespace, and 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. The destination is the customer-supplied public IP and UDP port. A rule that reverses these fields cannot match inbound service traffic.

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

source: 64.130.40.90/32
protocol: UDP
destination 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.