Why FortiGate Firewall Policies Have No Name — and How to Fix It

Pull up any FortiGate firewall that’s been in production for more than a year and sort the policy list by name. In environments without a naming discipline, what you typically find is a mix of blank names, a few policies named something like “Policy_1” or “test”, and maybe a handful of properly descriptive names from whoever most recently touched the configuration. In one environment I inherited, 312 of 389 policies had no name at all. The remaining 77 names were inconsistent: some used hostnames, some used ticket numbers, some used vague descriptions like “server access” or “outbound,” and a few were clearly test names like “temp2” and “new_rule_delete_me” that had been in production for three years.

This isn’t a minor cosmetic issue. Unnamed policies are a technical debt that compounds every month they exist. Troubleshooting becomes slower, change management becomes riskier, audits become more painful, and cleanup becomes nearly impossible because nobody can determine the intent of a policy from its parameters alone. This post explains why unnamed policies accumulate, the actual operational cost, and the complete workflow for remediation — including the CLI commands and the procedural changes that prevent recurrence.

Why FortiGate Policies So Often Have No Name

The GUI Default Behavior

In FortiOS, name is not a required field when creating a firewall policy through the GUI. In FortiOS 6.x, the name field is present but empty by default. In FortiOS 7.0 and later, the field is still optional. An engineer in a hurry — responding to an incident at 2 AM, onboarding a new application under deadline pressure — will click through required fields (interfaces, addresses, action) and skip the optional name field entirely. Multiply this behavior across a team of five engineers over four years, and you get a policy table where optionality became the norm.

The CLI behavior reinforces this. Creating a policy via CLI without a name is valid and requires no explicit acknowledgment:

FGT-PROD # config firewall policy
FGT-PROD (policy) # edit 0
FGT-PROD (policy-new) # set srcintf "internal"
FGT-PROD (policy-new) # set dstintf "wan1"
FGT-PROD (policy-new) # set srcaddr "10.10.5.0/24"
FGT-PROD (policy-new) # set dstaddr "all"
FGT-PROD (policy-new) # set action accept
FGT-PROD (policy-new) # set service "HTTPS" "HTTP"
FGT-PROD (policy-new) # set nat enable
FGT-PROD (policy-new) # end

This creates a valid, functional policy with no name. FortiOS assigns it an ID but leaves the name blank. The policy works perfectly. There’s no warning, no prompt, no required field. The operational consequence only becomes apparent months later when someone has to understand what this policy does and why it exists.

Inherited Configurations

Many FortiGate deployments are handed off between engineers, teams, or vendors without documentation. The receiving team inherits a configuration that was built without naming standards, and since understanding and adopting the history of 300 unnamed policies is a significant project, it gets deprioritized. New policies get added using whatever standard (or lack thereof) the new team has. The problem compounds.

Migration-Generated Policies

Configuration migrations — from another vendor, from an older FortiOS version, or from another FortiGate — often use automated tools or scripts that create policies programmatically. These tools frequently skip the name field or apply generic names like “RULE_001,” “Policy_247,” or the original vendor’s rule ID. After a Cisco ASA to FortiGate migration, for example, it’s common to see 200 policies all named “ASA_CONVERTED_RULE_XXX” — technically named, but operationally useless because the names convey no information about intent or ownership.

Lack of Enforced Standards

The root cause underlying all of these is the absence of an enforced naming standard. When naming is optional and there’s no peer review process that catches unnamed policies before they’re committed, the team gradually optimizes for speed over maintainability. The long-term cost is diffuse and invisible; the short-term convenience of skipping the name field is immediate. Without a forcing function, most teams will drift toward the path of least resistance.

The Real Cost of Unnamed Policies

Before addressing how to fix the problem, it’s worth quantifying what unnamed policies actually cost in operational terms, because this is what justifies the remediation investment to stakeholders.

Troubleshooting time: When a user reports that application X is blocked, the engineer has to determine which policy (or lack of policy) is causing the issue. On a firewall with named, commented policies, this is a 5-minute process: search for policies involving the relevant source, destination, or service, read the policy names and comments to understand the intended behavior, and determine whether the blocking is intentional or a misconfiguration. On a firewall with 300 unnamed policies, the same investigation can take 45 minutes to 2 hours, involving manual review of policy parameters, hit counts, and guesswork about intent.

Change risk: When making a change to a named policy, the engineer can verify they’re editing the right one from the name alone. With unnamed policies, engineers verify by checking parameters — but in complex environments with many similar policies, this verification is unreliable. I’ve seen engineers edit the wrong policy because two policies with similar parameters existed and the intended one wasn’t distinguishable by inspection alone. The resulting misconfiguration wasn’t caught until an application team reported an outage.

Audit failures: ISO 27001 Annex A.13.1, PCI-DSS requirement 1.3, and SOC 2 CC6.6 all require that firewall rules be documented and reviewed. An auditor reviewing a FortiGate policy table with 80% unnamed policies will flag this immediately. The finding is typically “firewall rules lack documentation and cannot be verified against business requirements” — a medium-to-high severity finding that requires remediation evidence before the audit closes.

Cleanup paralysis: As covered in detail in our analysis of FortiGate policy bloat, unnamed policies can’t be safely cleaned up because their purpose is unknown. An engineer looking at an unnamed policy with a zero hit count and parameters like “srcaddr: 10.10.7.0/24, dstaddr: 172.16.3.50, service: TCP/8443” has no idea whether this is a critical application path, a decommissioned test, or a DR access rule that gets used once a year. The safe response is to leave it alone. The result is permanent bloat.

Auditing Your Current Naming Status

Before beginning remediation, establish baseline metrics. Here’s the CLI workflow:

Count total policies:

FGT-PROD # show firewall policy | grep "^    edit" | wc -l
389

Count policies with no name:

FGT-PROD # show firewall policy | grep -c "^        set name"
77

The difference (389 – 77 = 312) represents unnamed policies. As a percentage: 312/389 = 80.2% unnamed.

Export a full policy list with IDs and names for review:

FGT-PROD # show firewall policy | grep -E "^    edit|set name|set srcintf|set dstintf|set srcaddr|set dstaddr|set service|set action|set comments"

This output gives you the full picture of each policy’s parameters alongside its name and comments. Redirect this to a file for offline analysis:

FGT-PROD # execute ssh-keygen rsa
# Or use the REST API to export programmatically:
GET /api/v2/cmdb/firewall/policy?vdom=root&format=policyid|name|srcintf|dstintf|srcaddr|dstaddr|service|action|comments
Authorization: Bearer <api-token>

The API approach returns JSON that can be loaded into a spreadsheet for bulk review and name assignment. This is the recommended approach for policy tables over 100 entries.

Developing a Naming Convention That Lasts

A naming convention only works if it’s:

1. Unambiguous — each component has a clear, single meaning
2. Consistent — the same structure applies to every policy
3. Informative — reading the name tells you enough to understand the policy without looking at its parameters
4. Searchable — the structure enables filtering by environment, direction, ticket, etc.
5. Enforceable — the structure can be validated by a human reviewer or automated check

Here is a naming convention that meets all five criteria and has been used successfully in environments ranging from 50 to 1,200+ policies:

[ENV]-[FUNCTION]-[TRAFFIC_DIRECTION]-[YYYYMM]-[TICKET_ID]

ENV:        PROD | STAGING | DEV | DMZ | MGMT | INFRA
FUNCTION:   Short description of the permitted traffic purpose
DIRECTION:  INBOUND | OUTBOUND | EAST-WEST | MGMT-ACCESS | VPN
YYYYMM:     Year and month the policy was created
TICKET_ID:  Change management ticket or JIRA issue ID

Examples:
PROD-WEBSERVER-INBOUND-202311-CHG0041892
DMZ-DATABASE-EAST-WEST-202402-CHG0048201
INFRA-MONITORING-OUTBOUND-202309-CHG0039114
PROD-SSLVPN-INBOUND-202401-CHG0046557
STAGING-DEVOPS-EAST-WEST-202312-CHG0043881
TEMP-VENDOR-PATCHING-202404-CHG0051009-EXP20240430

The TEMP prefix with an EXP suffix is particularly important. Any policy created for temporary access must have a visible expiry indicator in its name. This makes temporary policies immediately identifiable during quarterly reviews without having to read comments or check creation dates.

For policies inherited from migrations with no clear business context, use a holding convention:

MIGRATED-[ORIGINAL_ID]-REVIEW-[YYYYMM]
Example: MIGRATED-ASA-RULE-247-REVIEW-202403

This signals that the policy requires research before it can be properly named, creates a searchable category for all migration-era policies, and provides accountability through the date stamp.

The Remediation Process: Naming 300 Policies Without Breaking Anything

The temptation when facing 300 unnamed policies is to approach it as a single project and assign names based on parameter analysis. This approach works, but it carries risk: an engineer who assigns names based on parameter inference might misidentify a policy’s purpose, leading to a name that gives false confidence. The safer approach is a two-tier process: documentation first, then naming.

Tier 1: Urgent Naming (Policies with High Hit Counts)

Start with the most active policies. These are the most likely to be touched during troubleshooting or changes, and accurate naming provides the most immediate operational value.

FGT-PROD # diagnose firewall iprope show 100004 0 | sort -t= -k3 -rn | head -50

This lists policies sorted by hit count, descending. For the top 50 most active policies, prioritize name assignment. Research each policy’s purpose through:

• Checking change management system for the policy’s creation date (from config version history if available)
• Consulting with application owners who own the source/destination IPs
• Checking monitoring systems for traffic patterns on those IPs

Once purpose is confirmed, add name and comment in a single CLI change:

FGT-PROD # config firewall policy
FGT-PROD (policy) # edit 47
FGT-PROD (policy-47) # set name "PROD-ERP-APP-INBOUND-201906-CHG0012447"
FGT-PROD (policy-47) # set comments "SAP ERP application server inbound from internal users. Owner: enterprise-apps@company.com. Reviewed 2024-03-15 by J.Smith."
FGT-PROD (policy-47) # end

Tier 2: Bulk Naming via API

For the remaining lower-traffic policies, the REST API enables bulk updates that would take hours via CLI. Build a CSV with policy IDs, proposed names, and comments, then script the updates:

#!/bin/bash
# bulk-rename-policies.sh
# Input: policies.csv with columns: policyid,name,comments
# Requires: FortiGate API token with write access

FQDN="192.168.99.1"
TOKEN="your-api-token"
VDOM="root"

while IFS=, read -r policyid name comments; do
    curl -sk -X PUT \
        "https://${FQDN}/api/v2/cmdb/firewall/policy/${policyid}?vdom=${VDOM}" \
        -H "Authorization: Bearer ${TOKEN}" \
        -H "Content-Type: application/json" \
        -d "{\"name\": \"${name}\", \"comments\": \"${comments}\"}"
    echo "Updated policy ${policyid}: ${name}"
done < policies.csv

This approach can update 200 policies in under 5 minutes with consistent formatting. Validate a subset via CLI before running the full batch:

FGT-PROD # show firewall policy 47 | grep -E "name|comments"
    set name "PROD-ERP-APP-INBOUND-201906-CHG0012447"
    set comments "SAP ERP application server inbound..."

Using Policy Comments Effectively

Names identify a policy; comments explain it. The combination gives you complete context. A good comment answers the questions a future engineer will have when they encounter the policy:

• What business function does this support?
• Who owns the application or service?
• Why was this created (incident, project, vendor requirement)?
• When was it last reviewed and by whom?
• Are there any special notes (e.g., “do not remove — used by DR runbook step 4”)?

Example of a well-commented policy:

FGT-PROD # config firewall policy
FGT-PROD (policy) # edit 156
FGT-PROD (policy-156) # set comments "Purpose: Outbound HTTPS for corporate proxy bypass — Salesforce CRM. Business owner: salesops@company.com. Created 2023-09 per CHG0038421. Last reviewed 2024-03-15 by netops@company.com. Note: specific IPs are Salesforce CDN endpoints, do not consolidate into broader rule."
FGT-PROD (policy-156) # end

The comment is long, but that length is appropriate for a policy that’s been in production 18 months and needs to survive the next three engineer transitions.

Preventing Recurrence: The Operational Changes That Actually Work

Peer Review for All Policy Changes

Implement a peer review requirement in your change management process. Every firewall policy addition or modification must be reviewed by a second engineer before being committed to production. The reviewer’s checklist should include:

• Policy has a name following the convention
• Policy has a comment explaining purpose and owner
• Change ticket number is present in both name and comment
• Policy is placed in the correct position (not below a shadow rule, not above rules it should be below)
• Service is specific (not ALL unless justified in comment)
• Temporary policies have EXP suffix and linked calendar event

Automated Validation via API Monitoring

Schedule a daily API call that checks for unnamed policies and alerts the team:

GET /api/v2/cmdb/firewall/policy?vdom=root&filter=name%3D%3D
# Returns all policies with empty name field

# Alert trigger: if response contains any policies, send alert to teams channel

When an unnamed policy is detected within 24 hours of creation, the engineer who created it is much more likely to remember the context and can add the name immediately. Unnamed policies discovered a year later require research to name accurately.

Quarterly Naming Review as Part of Policy Review

Add naming and comment quality to the quarterly policy review agenda alongside hit count analysis. For each policy flagged for review, verify: Is the name current? Does the comment still accurately describe the policy? Has the owner changed? Has the application been decommissioned?

For comprehensive policy review frameworks that extend beyond naming to include optimization and cleanup, the guide on FortiGate policy optimization for network engineers provides a complete quarterly review process that integrates naming governance with performance and security analysis.

A Naming Remediation Tracking Template

FortiOS Version Considerations for Naming

The behavior of the name field has evolved across FortiOS versions:

• FortiOS 6.0–6.2: Policy name is optional. GUI shows “(Unnamed)” for blank name fields. No validation.
• FortiOS 6.4–7.0: Same optional behavior, but the column is more visible in the GUI, which subtly encourages naming.
• FortiOS 7.2+: The GUI policy list now shows a warning indicator for unnamed policies in some builds, but naming remains optional. The API still accepts policy creation without a name.

None of the current FortiOS versions enforce naming at the platform level. This will remain a governance and process issue until Fortinet makes the name field required — which, based on the current product trajectory, doesn’t appear imminent. The enforcement must come from your operational process.

When upgrading firmware as part of your remediation plan, verify that existing policy names survive the upgrade process. In all standard upgrades, names and comments are preserved in the configuration file and carry forward correctly. For complex upgrade path planning, particularly across major version jumps, see the detailed guidance on FortiGate firmware upgrade paths and common pitfalls.

Measuring Remediation Success

Define clear success metrics before beginning remediation so you can demonstrate progress and maintain momentum:

• Week 1 target: Top 50 policies by hit count named and commented
• Month 1 target: All policies with hit count > 100 named and commented (typically 30–40% of policies by count, 80%+ of traffic by volume)
• Month 3 target: 90% of all policies named according to convention
• Month 6 target: 100% named, peer review process operational, automated monitoring active
• Ongoing: 0 unnamed policies survive 24 hours in production

In the 389-policy environment referenced at the beginning of this post, following this framework brought naming compliance from 19.8% to 94.3% over a 14-week period. The remaining 5.7% were policies where purpose could not be determined from available records — these were treated as cleanup candidates rather than naming candidates, and were disabled pending owner confirmation.

The most significant operational benefit was a measurable reduction in troubleshooting time. Average time to diagnose and resolve policy-related access issues dropped from 47 minutes to 11 minutes over the six months following remediation completion — a 77% reduction attributable almost entirely to the improved clarity of the policy table.

Conclusion

Unnamed FortiGate policies are not an inevitable consequence of firewall management — they’re a consequence of optional fields, time pressure, and the absence of enforced standards. The accumulation is gradual and the cost is diffuse until it suddenly isn’t: until you’re three hours into a P1 outage trying to understand a policy table nobody has touched in two years, or until an auditor asks you to justify 300 undocumented firewall rules.

The fix is entirely achievable. It requires a naming convention, a peer review process, automated monitoring for compliance, and a structured remediation project for existing unnamed policies. None of these require budget. They require discipline and organizational buy-in, which starts with quantifying the cost of the status quo and making that cost visible to the people who set team priorities.

Start with the audit. Run the CLI commands in this post, calculate your naming compliance percentage, and present that number to your team lead. A firewall with 80% unnamed policies is a technical debt that’s been accumulating silently. Now you have the number to make it visible.

Related Articles

• APO Tool: FortiGate Firewall Policy Analyzer for Network Engineers
• FortiGate Policy Optimization: A Complete Guide for Network Engineers
• FortiGate Firmware Upgrade: What Nobody Tells You About the Upgrade Path
• Why Our FortiGate SSL VPN Kept Dropping After 4 Hours — and the Fix