Which firewall platforms are covered here?

Coverage includes host rules for ufw, nftables, and iptables, plus GCP firewall rules and AWS security groups for inbound UDP. Every example admits ${SOURCE_IP}/32 toward destination port 9000. Replace only that example port and required platform resource identifiers, then verify rule attachment and packet arrival.

Should testing use an internet-wide source?

No. Use ${SOURCE_IP}/32, the documented service source. A public rule admits unrelated UDP and weakens diagnostic counters. If the narrow rule does not match, inspect its destination port, rule order, attachment, NAT mapping, route, cloud ACL, and host socket instead of widening the source.

Why might traffic fail despite a cloud rule?

A cloud rule controls one layer. Another ACL, routing decision, NAT rule, local filter, container policy, or missing listener may still block delivery. Trace the entire public-to-process path, inspect rule counters, run a source-filtered capture, and compare the registered port with the actual receiver binding.

Docs

Firewall configuration

This page lets you permit verification and shred traffic from the fixed service source using five common firewall platforms.

Before you start

Know the customer destination UDP port.
Have administrator access to the selected host or cloud firewall.
Know whether another firewall or network ACL also filters the receive path.
Replace the example port 9000 consistently before applying a rule.

Apply the same policy everywhere

Every shredstream.sh datagram originates from ${SOURCE_IP}, whether it carries the challenge or a shred. Admit ${SOURCE_IP}/32 as source toward the customer port over UDP. No published source port should constrain this rule.

The examples use destination port 9000. Change that one value when your registered port differs. Keep the source exactly ${SOURCE_IP}/32. Install equivalent admission across all applicable cloud, edge, and host layers.

iptables

Set the example port and insert the allow rule at the start of the INPUT chain:

bash

DESTINATION_PORT=9000sudo iptables -I INPUT 1 -p udp -s 203.23.178.228/32 --dport "$DESTINATION_PORT" -j ACCEPT

Verify that the exact rule exists and inspect its counter:

bash

DESTINATION_PORT=9000sudo iptables -C INPUT -p udp -s 203.23.178.228/32 --dport "$DESTINATION_PORT" -j ACCEPTsudo iptables -L INPUT -n -v --line-numbers

iptables -C exits with status 0 when the matching rule exists. The -I INPUT 1 position evaluates the allow before later rules in that chain. Another table, earlier hook, cloud rule, or network device can still drop traffic.

Persistence commands vary by Linux distribution and fall outside the product contract. Save the verified rule through the host's established firewall-management package.

nftables

The following commands create their own nftables table, establish an input base chain, and add the source-specific rule:

bash

sudo nft add table inet shredstreamsudo nft 'add chain inet shredstream input { type filter hook input priority -10; policy accept; }'sudo nft add rule inet shredstream input ip saddr 203.23.178.228 udp dport 9000 counter accept

Verify the resulting chain:

bash

sudo nft list chain inet shredstream input

Run the creation commands once. They report File exists when the named table or chain already exists. If the host already has an nftables input chain with a drop policy, add the same ip saddr 203.23.178.228 udp dport 9000 counter accept expression to that established chain according to its rule order. An accept in one base chain cannot reverse a drop from another hook or chain.

Persist the rule through the distribution's existing nftables configuration. The configuration file location and service manager are not currently specified.

ufw

Add the narrow inbound rule:

bash

sudo ufw allow proto udp from 203.23.178.228 to any port 9000

Verify the active numbered policy:

bash

sudo ufw status numbered

The expected line contains 9000/udp, ALLOW IN, and 203.23.178.228. Because enabling ufw can affect unrelated host access, these instructions never enable or reset it. Add the rule only when ufw already manages the host or customer policy covers activation.

AWS security group

Set the actual security group ID and destination port, then authorize one inbound UDP CIDR:

bash

AWS_SECURITY_GROUP_ID='sg-0123456789abcdef0'DESTINATION_PORT=9000aws ec2 authorize-security-group-ingress   --group-id "$AWS_SECURITY_GROUP_ID"   --protocol udp   --port "$DESTINATION_PORT"   --cidr 203.23.178.228/32

Replace the example group ID before running the command. The AWS CLI must already target the account and region that contain the receiving network interface.

Verify the group definition:

bash

AWS_SECURITY_GROUP_ID='sg-0123456789abcdef0'aws ec2 describe-security-groups --group-ids "$AWS_SECURITY_GROUP_ID"

In the AWS console, create an inbound custom UDP rule. Set its port range to 9000, its source to 203.23.178.228/32, and attach the security group to the receiving instance or network interface. A security-group rule cannot override a restrictive network ACL, host firewall, or missing public route.

Running the authorize command when an identical rule exists can return InvalidPermission.Duplicate. Inspect the existing rule rather than widening its source.

GCP firewall rule

Set the actual project and VPC network, then create an ingress allow rule:

bash

GCP_PROJECT_ID='my-project-id'GCP_NETWORK='my-vpc'DESTINATION_PORT=9000GCP_RULE_NAME="allow-shredstream-udp-$DESTINATION_PORT"gcloud compute firewall-rules create "$GCP_RULE_NAME"   --project="$GCP_PROJECT_ID"   --network="$GCP_NETWORK"   --direction=INGRESS   --action=ALLOW   --rules="udp:$DESTINATION_PORT"   --source-ranges=203.23.178.228/32

Replace both example identifiers before running the command. Without a target tag or target service account, a GCP ingress rule applies to eligible instances on the selected VPC network, subject to firewall policy evaluation.

Verify the rule:

bash

GCP_PROJECT_ID='my-project-id'DESTINATION_PORT=9000GCP_RULE_NAME="allow-shredstream-udp-$DESTINATION_PORT"gcloud compute firewall-rules describe "$GCP_RULE_NAME"   --project="$GCP_PROJECT_ID"

If a rule with that name exists, create reports that the resource already exists. Inspect or update the existing rule through the customer's change process. Hierarchical firewall policies, routes, instance reachability, and host firewalls can still prevent delivery.

Validate the complete path

Start the receiver before testing. Replace the example port and capture one challenge:

bash

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

While tcpdump waits, issue a fresh challenge through the dashboard. A captured packet must also appear in application counts. If capture remains empty, inspect rule attachment, rule order, public routing, NAT, cloud ACLs, and the dashboard pair.

Do not open this internet-wide range as a diagnostic:

text

0.0.0.0/0

That change admits unrelated traffic and does not isolate a missing ${SOURCE_IP} rule. Use rule counters and captures at successive layers.

Change and remove rules safely

When the customer destination port changes, prepare a new rule for ${SOURCE_IP} and the new port before saving the address. Complete re-verification and confirm stream packets before removing the old customer-side rule.

Rule deletion syntax depends on the platform and customer-created identifiers. Deletion commands are omitted because targeting the wrong firewall entry can interrupt unrelated access. After confirming the target, use its displayed handle, line number, security-group permission, or resource name.

Parameters

Name	Type	Default	Notes
source CIDR	IPv4 CIDR	203.23.178.228/32	Use this exact source in all five platform rules.
protocol	IP transport	UDP	Verification and stream delivery both use UDP.
destination port	UDP port	9000 in examples	Replace with the port registered in the dashboard.
AWS_SECURITY_GROUP_ID	AWS security group ID	none	Replace the example with the group attached to the receiving interface.
GCP_PROJECT_ID	GCP project ID	none	Replace the example with the project containing the firewall rule.
GCP_NETWORK	GCP VPC network name	none	Replace the example with the receiving instance's VPC network.

When it goes wrong

A repeated AWS command fails. Example error: `InvalidPermission.Duplicate`.

Cause. The security group already contains an identical inbound permission.

Fix. Inspect the existing group and keep the narrow rule instead of adding a duplicate.

nftables creation fails. Example error: `Error: Could not process rule: File exists`.

Cause. The dedicated table, chain, or rule was created during an earlier run.

Fix. List the existing chain and add only the missing source-specific expression in the established policy order.

The firewall rule exists but captures remain empty. Example error: `0 packets captured`.

Cause. The rule targets the wrong port, interface, group, VPC, or translated path, or another layer drops traffic.

Fix. Compare the dashboard pair with every rule attachment, NAT mapping, route, and host socket.

GCP rule creation fails. Example error: `Could not fetch resource: The resource was not found`.

Cause. The project or VPC network identifier is wrong for the receiving instance.

Fix. Select the actual project and network, then rerun the source-specific create command.

Questions

Which firewall platforms are covered here?: Coverage includes host rules for ufw, nftables, and iptables, plus GCP firewall rules and AWS security groups for inbound UDP. Every example admits ${SOURCE_IP}/32 toward destination port 9000. Replace only that example port and required platform resource identifiers, then verify rule attachment and packet arrival.
Should testing use an internet-wide source?: No. Use ${SOURCE_IP}/32, the documented service source. A public rule admits unrelated UDP and weakens diagnostic counters. If the narrow rule does not match, inspect its destination port, rule order, attachment, NAT mapping, route, cloud ACL, and host socket instead of widening the source.
Why might traffic fail despite a cloud rule?: A cloud rule controls one layer. Another ACL, routing decision, NAT rule, local filter, container policy, or missing listener may still block delivery. Trace the entire public-to-process path, inspect rule counters, run a source-filtered capture, and compare the registered port with the actual receiver binding.