Generate a shred-feed firewall rule

Open one port to one address

Firewall syntax is one of those things that is easy once and irritating every time after. This holds the correct form for each platform so you are not reading three sets of documentation to allow one port.

The rules here all say the same thing: accept UDP on the port you nominate, but only from our source address. That is deliberately narrower than the minimum. You could open the port to everything and it would work. You would also be accepting datagrams from anyone who found the port, and since UDP sources are trivially spoofable, that is a bad habit to build.

Method

The port parser accepts an integer from 1 through 65535. It rejects ranges, service names, decimal points, shell characters, and pasted commands. The source address is fixed rather than entered by the visitor.

direction = inbound
protocol = UDP
source = 64.130.40.90/32
destination_port = validated port
action = allow

The generator substitutes the validated port into a fixed template. It does not run the command. It cannot determine the correct chain, interface, cloud project, security group, instance tag, or persistence method without operator input.

iptables

For UDP port 9000:

sudo iptables -I INPUT 1 -p udp -s 64.130.40.90/32 --dport 9000 -j ACCEPT
sudo iptables -C INPUT -p udp -s 64.130.40.90/32 --dport 9000 -j ACCEPT

Insert places the rule at position one. Inspect iptables-save before applying because a managed host may use a custom chain. Persistence depends on the distribution.

nftables

Assuming an existing inet table named filter and input chain named input:

sudo nft insert rule inet filter input ip saddr 64.130.40.90 udp dport 9000 counter accept
sudo nft list chain inet filter input

Table and chain names are local policy. The counter reveals whether matching packets reached this boundary. The tool asks for validated names rather than assuming that creating a new base chain is safe.

ufw

The ufw form is:

sudo ufw allow proto udp from 64.130.40.90 to any port 9000
sudo ufw status numbered

Check whether ufw is active and whether another firewall manager owns the host. A displayed host rule says nothing about cloud ingress.

AWS security groups

Use custom UDP, port 9000, and source 64.130.40.90/32. The CLI form needs the security group attached to the receiver:

aws ec2 authorize-security-group-ingress   --group-id sg-REPLACE   --ip-permissions 'IpProtocol=udp,FromPort=9000,ToPort=9000,IpRanges=[{CidrIp=64.130.40.90/32,Description=shredstream.sh}]'

Network ACLs, routes, public IP mapping, load balancers, and the host firewall remain separate. Replace only the security-group ID and generated port.

GCP firewall rules

A network-tag target keeps the rule scoped to receiver instances:

gcloud compute firewall-rules create allow-shredstream-udp-9000   --direction=INGRESS   --action=ALLOW   --rules=udp:9000   --source-ranges=64.130.40.90/32   --target-tags=shred-receiver

Attach the shred-receiver tag to the intended instance. Select the correct project and network. Hierarchical policy or a higher-priority deny can still block the traffic. A service-account target is another valid design, so the tool presents it as a separate option.

Order matters more than you expect

On ufw, firewalld and cloud security groups, rules are evaluated as a set and the specific allow will be honoured. On raw iptables and nftables, rules are evaluated in order, and an earlier DROP wins over a later ACCEPT. If you paste an accept rule at the bottom of a chain that already drops everything, nothing changes and it looks like the rule did not work.

Insert rather than append when you are unsure. The generated iptables rule uses -I for that reason.

Cloud security groups

If your server is on a cloud provider, you almost certainly have two firewalls: the one on the machine and the one in the provider's console. Both must allow the traffic. Fixing only the one you remember is the single commonest reason a correctly configured host still receives nothing.

Worked example

Assume an AWS instance listens on UDP 9000 and also runs ufw. Add the AWS rule to the security group attached to its network interface. Add the ufw rule on the host. Bind the receiver to the intended local interface and port.

Run the endpoint tester. If the AWS boundary records traffic but the ufw counter stays zero, inspect routes, network interfaces, and public-address mapping. If the ufw counter rises but the process reads nothing, inspect socket binding, network namespace, competing listeners, and receive errors.

The free test sends five real datagrams from 64.130.40.90. A successful result proves reachability at that moment. It does not reproduce the measured 54.3 Mbps and 5,585 packets per second production load.

Security and scope

Source filtering reduces unrelated internet traffic. It is not cryptographic authentication because UDP source addresses can be spoofed on permissive networks. Verify shred signatures under the receiver's policy.

The feed is one-way UDP. No return UDP rule is required. The endpoint test's temporary receiver reports its nonce through outbound HTTPS so the browser can display arrival.

Containers and Kubernetes can add namespaces, host rules, service policy, and provider policy. IPv6 rules are outside this IPv4 source contract. The tool does not open a port range because one destination uses one port.

Checking it worked

Do not trust the rule, test it. Start a listener and use the endpoint tester. A rule that looks right and a path that works are different claims, and only one of them can be verified from where you are sitting.

The activation challenge expires after 600 seconds. It verifies the selected destination, not persistence across a restart. Save host rules through the platform's configuration process and retest after changes.