Protocol/Port Template Builder

Build firewall rules from CSV templates

Quick Add Common Services

NameProtocolPortEnd Port

Output Format

2 valid rules

Simple Output

tcp/80
tcp/443

The Protocol/Port Template Builder generates consistent firewall rule syntax from structured CSV input specifying protocols and ports. Provide a CSV like TCP,443,HTTPS,0.0.0.0/0,192.168.1.20 and a template pattern, and get properly formatted rules for iptables, nftables, AWS security groups, or any custom format.

Understanding Firewall Rule Templating

Building firewall rules by hand is one of the most error-prone tasks in network administration. Each rule follows the same structure -- protocol, port, source, destination, action -- but the exact syntax differs between every firewall platform. An iptables rule looks nothing like an nftables rule, which looks nothing like an AWS security group JSON definition. When you need to create 20 or 30 rules for a new application deployment, manually formatting each one in the target syntax is tedious and inevitably introduces typos that cause rules to silently fail.

The template approach solves this by separating the data (what you want to allow) from the format (how your firewall expresses it). You describe your port requirements once in a simple CSV -- protocol, port, description, source, destination -- and then apply a template to generate the rules in whatever syntax you need. If you later migrate from iptables to nftables, you do not rewrite 30 rules by hand. You change the template and regenerate. If the security team hands you a spreadsheet of approved ports, you use it directly as input rather than manually transcribing each row into firewall syntax.

This matters most in environments where consistency is critical. When multiple team members write firewall rules by hand, you end up with inconsistent formatting, missing comments, inconsistent protocol casing, and subtle syntax variations that make rules harder to review and audit. A template ensures every rule follows exactly the same pattern, with comments automatically generated from the description field, making your firewall configuration a reliable source of documentation rather than an ad hoc collection of hand-written commands.

How to Build Firewall Rules from CSV Templates

  1. Prepare your CSV data with columns for protocol (TCP, UDP, or both), port or range, description, and optionally source/destination
  2. Choose or customize a rule template for your target firewall platform
  3. The builder applies variable substitution to generate one rule per CSV row
  4. Review the generated rules for correctness
  5. Copy the output and apply to your firewall configuration

CSV Input Format

protocol,port,description,source,destination
TCP,22,SSH Management,10.0.0.0/8,192.168.1.10
TCP,80,HTTP Web Traffic,0.0.0.0/0,192.168.1.20
TCP,443,HTTPS Web Traffic,0.0.0.0/0,192.168.1.20
UDP,53,DNS Queries,10.0.0.0/8,192.168.1.5
TCP,3306,MySQL Database,192.168.1.0/24,192.168.1.30
TCP,8080-8085,App Server Ports,10.0.0.0/8,192.168.1.40

Template Output Examples

iptables Rules

# SSH Management
iptables -A INPUT -p tcp -s 10.0.0.0/8 -d 192.168.1.10 --dport 22 -j ACCEPT
# HTTP Web Traffic
iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 192.168.1.20 --dport 80 -j ACCEPT
# HTTPS Web Traffic
iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 192.168.1.20 --dport 443 -j ACCEPT
# DNS Queries
iptables -A INPUT -p udp -s 10.0.0.0/8 -d 192.168.1.5 --dport 53 -j ACCEPT
# MySQL Database
iptables -A INPUT -p tcp -s 192.168.1.0/24 -d 192.168.1.30 --dport 3306 -j ACCEPT

nftables Rules

# SSH Management
nft add rule inet filter input ip saddr 10.0.0.0/8 ip daddr 192.168.1.10 tcp dport 22 accept
# HTTP Web Traffic
nft add rule inet filter input ip daddr 192.168.1.20 tcp dport 80 accept

AWS Security Group JSON

{
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "IpRanges": [{"CidrIp": "10.0.0.0/8", "Description": "SSH Management"}]
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "IpRanges": [{"CidrIp": "0.0.0.0/0", "Description": "HTTPS Web Traffic"}]
    }
  ]
}

Template Variables

VariableDescriptionExample Value
{protocol}Protocol from CSVtcp
{PROTOCOL}Protocol uppercaseTCP
{port}Port number or range443 or 8080-8085
{port_start}Range start port8080
{port_end}Range end port8085
{description}Description from CSVHTTPS Web Traffic
{source}Source IP/CIDR10.0.0.0/8
{destination}Destination IP/CIDR192.168.1.20

When to Use the Template Builder

  • Building initial firewall configurations from application port requirement spreadsheets
  • Standardizing rule formats across team members to ensure consistent syntax
  • Generating rules from security team spreadsheets that document approved ports and access
  • Migrating between firewall platforms by re-templating the same CSV for a different syntax
  • Creating documentation-as-code where the CSV serves as both human-readable documentation and configuration source
  • Bulk rule generation when onboarding new applications that require many firewall entries

How Template Variable Substitution Works

Basic Substitution

The builder reads each row of the CSV and replaces template variables with the corresponding column values. A template like:

iptables -A INPUT -p {protocol} --dport {port} -j ACCEPT  # {description}

Applied to the row TCP,443,HTTPS Web Traffic produces:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT  # HTTPS Web Traffic

Port Range Handling

For port ranges like 8080-8085, the {port} variable contains the full range string. The {port_start} and {port_end} variables provide individual endpoints for platforms that require separate from/to port parameters (like AWS Security Groups).

Protocol Expansion

When the protocol column is both or TCP/UDP, the builder generates two rules per row -- one for TCP and one for UDP -- ensuring complete coverage without manual duplication.

Template Building in Practice

The biggest advantage of the template approach is not the initial rule generation -- it is the ongoing maintenance. When you add a new service to your infrastructure, you add one row to your CSV and regenerate the rules. When you migrate to a new firewall platform, you change the template and regenerate. When the security team asks for a list of all open ports, the CSV already is that list. The CSV becomes your single source of truth for firewall policy, and the generated rules are just a computed output.

For teams that use infrastructure-as-code tools like Terraform or Ansible, the template builder fills the gap between human-friendly port documentation and machine-readable configuration. The security team maintains a spreadsheet of approved ports, exports it as CSV, and the template builder generates the Terraform variable definitions or Ansible task parameters. This eliminates the manual transcription step where errors are most commonly introduced, and it keeps the security team's documentation synchronized with the actual configuration.

A practical tip: always include the description field in your CSV and configure your template to emit it as a comment. Firewall rules without comments are a maintenance nightmare. Six months from now, no one will remember why port 8443 is open to 10.0.0.0/8. A comment like "HTTPS Alternate -- API Gateway for Mobile App" makes the purpose immediately clear during audits and change reviews.

Frequently Asked Questions

Can I use custom templates for platforms not listed?

Yes. The template system is text-based with simple variable substitution. Define any template string using the available variables and the builder will apply it to your CSV data. This works for proprietary firewalls, custom scripts, or any text-based configuration format.

How are port ranges handled in the template?

If a CSV row specifies a range like 8080-8085, the {port} variable contains 8080-8085 as-is. For platforms needing separate start and end values (like AWS FromPort/ToPort), use {port_start} and {port_end} which resolve to 8080 and 8085 respectively. For single ports, both variables return the same value.

Does the builder validate port numbers and IP addresses?

Yes. Each CSV row is validated before template application. Invalid port numbers (outside 0-65535), malformed IP addresses, and unrecognized protocols are flagged with errors, and the corresponding row is skipped in the output.

Can I generate deny rules as well as allow rules?

Yes. The template is fully customizable. For iptables deny rules, use a template like iptables -A INPUT -p {protocol} --dport {port} -j DROP # {description}. You can maintain separate templates for allow rules, deny rules, logging rules, and rate-limited rules, and apply whichever is appropriate to your CSV data.

How do I handle services that need both TCP and UDP?

Set the protocol column to both or TCP/UDP in your CSV row. The builder automatically generates two separate rules -- one for TCP and one for UDP -- from a single CSV row. This ensures complete protocol coverage without requiring you to duplicate the row manually.

Related Tools

IPparse•Free Network & Subnet Calculator Tools

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected