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, including verification and the live stream, originates from ${SOURCE_IP}. Allow source ${SOURCE_IP}/32, protocol UDP, and the customer destination port. Do not add a source UDP port condition because it is not currently specified.

The examples use destination port 9000. Change that one value when your registered port differs. Keep the source exactly ${SOURCE_IP}/32. Apply the rule at every applicable cloud, edge, and host layer.

iptables

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

bash

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

Verify that the exact rule exists and inspect its counter:

bash

DESTINATION_PORT=9000
sudo iptables -C INPUT -p udp -s 64.130.40.90/32 --dport "$DESTINATION_PORT" -j ACCEPT
sudo 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 are not currently specified by the product. Save the verified rule through the host's established firewall-management package.

nftables

The following commands create a dedicated table and input base chain, then add the source-specific rule:

bash

sudo nft add table inet shredstream
sudo nft 'add chain inet shredstream input { type filter hook input priority -10; policy accept; }'
sudo nft add rule inet shredstream input ip saddr 64.130.40.90 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 64.130.40.90 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 64.130.40.90 to any port 9000

Verify the active numbered policy:

bash

sudo ufw status numbered

The expected line contains 9000/udp, ALLOW IN, and 64.130.40.90. Enabling ufw can affect unrelated host access, so this page does not instruct a user to enable or reset it. Apply the rule only when ufw already manages the host or when enabling it is covered by the customer's host policy.

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=9000
aws ec2 authorize-security-group-ingress   --group-id "$AWS_SECURITY_GROUP_ID"   --protocol udp   --port "$DESTINATION_PORT"   --cidr 64.130.40.90/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 with port range 9000 and source 64.130.40.90/32. 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=9000
GCP_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=64.130.40.90/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=9000
GCP_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 64.130.40.90 and udp dst port 9000'

Request a resend from the dashboard while tcpdump waits. If the packet appears, confirm that the application also receives it. If it does not appear, inspect rule attachment, rule order, public routing, NAT, cloud ACLs, and the dashboard pair.

Do not open 0.0.0.0/0 as a diagnostic. 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 selected platform and the exact identifiers created by the customer. This page does not provide deletion commands because removing the wrong firewall entry can interrupt unrelated access. Use the platform's displayed rule handle, line number, security-group permission, or resource name after confirming the target.

Parameters

Name	Type	Default	Notes
source CIDR	IPv4 CIDR	64.130.40.90/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?: The page provides inbound UDP rules for iptables, nftables, ufw, AWS security groups, and GCP firewall rules. Every example permits ${SOURCE_IP}/32 to destination port 9000. Replace only the example destination port and platform resource identifiers, then verify rule attachment and packet arrival.
Should I allow 0.0.0.0/0 while testing?: No. The documented service source is ${SOURCE_IP}, so use ${SOURCE_IP}/32. 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 can traffic still fail after adding a cloud rule?: A cloud rule controls one layer. A network ACL, route, NAT policy, host firewall, container policy, or closed socket can still block delivery. Trace the entire public-to-process path, inspect rule counters, run a source-filtered packet capture, and compare the registered port with the actual receiver binding.