Ansible for Firewall Automation: — Palo Alto and Fortinet Rules as Code

① Firewall-as-code — killing drift, GUI clicks and the mystery rules

Meet Sneha, an L2 engineer at Flipkart. A change ticket lands: "Allow the new payment service (203.0.113.40) to reach the app on tcp/8443." She opens the Palo Alto GUI, clicks Policies → Security, fills a form, clicks Commit. Same week, a teammate does the same change on the FortiGate by hand. Six months later an auditor asks "why does rule 47 exist and who approved it?" — and nobody knows. That gap is the disease this lesson cures.

Three things go wrong with click-by-hand firewalls. First, configuration drift: the running rulebase no longer matches any document. Second, no review: a fat-fingered any-any rule goes live with nobody checking. Third, no rollback: undoing a bad change means remembering what it used to be. Multiply that by two vendors with different GUIs and you have the classic outage waiting to happen.

Rules as code flips it. The firewall's objects and policies are described in an Ansible playbook kept in git. A change is now a pull request a colleague reviews; a wrong change is a git revert; and 'why does this rule exist?' is answered by the commit message. The firewall stops being a black box you poke and becomes a file you reason about.

Here's the part that surprises people coming from switch automation. Ansible does not SSH into these firewalls and type CLI. paloaltonetworks.panos drives PAN-OS over its XML API using a provider dict (or an httpapi connection). fortinet.fortios drives FortiGate over its REST API using the httpapi connection. So the connection is httpapi or local — never network_cli. The modules speak the firewall's native API, with structured idempotency baked in.

The four wins of rules-as-code, one tap each

Tap each card — these are the lines you'll repeat to a manager who asks 'why bother automating the firewall?'

② Palo Alto with panos — objects, security rules, and the commit step

Let's automate the Flipkart change properly on Palo Alto. Two ingredients: objects (named things like an address) and a security rule that references them. With panos_address_object you create the address partner-pay-host = 203.0.113.40, and with panos_security_rule you write the allow rule. The object comes first so the rule can point at it by name.

Connection is via the provider dict — ip_address, username, and a password or api_key (the modern path is an httpapi connection, but provider is what you'll see most). Key rule fields map straight to the GUI you already know: source_zone / destination_zone (e.g. untrust → dmz), source_ip / destination_ip, application (App-ID, e.g. web-browsing or ssl), service (defaults to application-default), action (allow/deny/drop), tag_name, and crucially location (top/bottom/before/after) which controls where in the rulebase it lands.

Now the gotcha that catches every newcomer. Your panos_security_rule task writes to the candidate config, not the running config. Nothing changes for users until a commit copies candidate to running. So a panos playbook is incomplete without panos_commit_firewall at the end. The inline commit: true parameter on the rule module is deprecated — use the dedicated commit module instead.

If you're driving Panorama instead of a single firewall, two more things change. You target a device_group (and optionally a template for network config), and committing is two steps: panos_commit_panorama commits Panorama, then panos_commit_push pushes it down to the firewalls. Miss the push and your rule lives on Panorama but never reaches the box enforcing traffic.

- name: Flipkart payment allow on PAN-OS
  hosts: paloalto
  connection: local
  gather_facts: false
  vars:
    provider:
      ip_address: "{{ pan_ip }}"
      username: "{{ pan_user }}"
      api_key: "{{ pan_api_key }}"     # from vault — next lesson
  tasks:
    - name: 1) Address object FIRST
      paloaltonetworks.panos.panos_address_object:
        provider: "{{ provider }}"
        name: "partner-pay-host"
        value: "203.0.113.40"
        description: "Partner payment service"

    - name: 2) Security rule that references it
      paloaltonetworks.panos.panos_security_rule:
        provider: "{{ provider }}"
        rule_name: "allow-partner-pay"
        source_zone: ["untrust"]
        destination_zone: ["dmz"]
        source_ip: ["partner-pay-host"]
        destination_ip: ["app-pay-server"]
        application: ["ssl"]
        action: "allow"
        tag_name: ["change-CHG10422"]
        location: "bottom"

    - name: 3) COMMIT — candidate -> running (or it never enforces)
      paloaltonetworks.panos.panos_commit_firewall:
        provider: "{{ provider }}"

PLAY [Flipkart payment allow on PAN-OS] ****************************
TASK [1) Address object FIRST] ************************ changed: [pa-fw-01]
TASK [2) Security rule that references it] *********** changed: [pa-fw-01]
TASK [3) COMMIT - candidate -> running] ************** changed: [pa-fw-01]
PLAY RECAP ********** pa-fw-01 : ok=3 changed=3 unreachable=0 failed=0

③ Fortinet with fortios — REST, VDOMs, tokens and object order

Same change, now on the FortiGate. The fortinet.fortios collection talks to the box over its REST API using the httpapi connection plugin (set ansible_connection: httpapi). The old fortiosapi Python library path is deprecated — httpapi is the supported way now. So, like Palo Alto, you're driving an API, not SSH-ing to the CLI.

Auth is a REST API token. You generate it on the box under System → Administrators → Create New → REST API Admin, then pass it to tasks as access_token (kept in Vault, of course). Every fortios task also names a vdom — default root — so your objects land in the right virtual firewall. Put an object in the wrong vdom and the policy in another vdom can't see it.

The FortiGate version of the object-first rule is strict and bites people constantly. A fortios_firewall_policy references its source/destination by the names of fortios_firewall_address objects. If the policy task runs before those address objects exist, FortiOS rejects it with entry not found in datasource. Ansible runs tasks top-down, so the fix is just ordering: address tasks above the policy task.

One more FortiGate-specific wrinkle: policy position and idempotency. A policy has a numeric policyid and an order in the list (FortiGate evaluates top-down, first match wins). Creating/updating a policy by id is idempotent — run it twice, the second run is ok not changed. But moving a policy's position is a separate action: move (before/after) operation; if you rely on creation order alone, re-running may not re-assert position, so be explicit when order matters to avoid rule shadowing.

- name: Flipkart payment allow on FortiGate
  hosts: fortigate
  connection: httpapi
  gather_facts: false
  vars:
    vdom: "root"
    ansible_httpapi_use_ssl: true
    ansible_httpapi_validate_certs: false
  tasks:
    - name: 1) Address objects FIRST
      fortinet.fortios.fortios_firewall_address:
        access_token: "{{ forti_token }}"   # from vault
        vdom: "{{ vdom }}"
        state: present
        firewall_address:
          name: "partner-pay-host"
          type: ipmask
          subnet: "203.0.113.40 255.255.255.255"

    - name: 2) Policy that references the object by name
      fortinet.fortios.fortios_firewall_policy:
        access_token: "{{ forti_token }}"
        vdom: "{{ vdom }}"
        state: present
        firewall_policy:
          policyid: 12
          name: "allow-partner-pay"
          srcintf: [{ name: "port2" }]
          dstintf: [{ name: "port1" }]
          srcaddr: [{ name: "partner-pay-host" }]
          dstaddr: [{ name: "pay-app" }]
          service: [{ name: "HTTPS" }]
          schedule: "always"
          action: "accept"
          status: "enable"

PLAY [Flipkart payment allow on FortiGate] ************************
TASK [1) Address objects FIRST] ********************** changed: [fg-01]
TASK [2) Policy that references the object by name] ** changed: [fg-01]
PLAY RECAP ********** fg-01 : ok=2 changed=2 unreachable=0 failed=0
# re-run -> ok=2 changed=0  (idempotent: state already matches)

④ Safe rollout — git, --check, gated commit, both vendors from one run

You can write rules in code now. The discipline that makes it safe is the rollout flow: playbooks live in git, every change is a pull request a colleague reviews, the play is dry-run with --check, and the commit/push is a deliberate gated step — never an accident. Manual GUI clicking had none of these gates; this is where the payoff is.

Check mode is your preview. ansible-playbook site.yml --check --diff reports which rules would be created or changed, and the diff shows before/after — all without touching the firewall. On Palo Alto you get a second safety net for free: even a real run leaves edits in candidate config until you run the commit task, so you can stage changes and commit only after a human says go. That commit becomes your gate.

Now the headline trick: one inventory, both vendors. You group your boxes — a paloalto group and a fortigate group — and keep the intent once in group_vars (allow 203.0.113.40 → the payment app on HTTPS). One play targets the paloalto group with panos modules (+ commit); another targets the fortigate group with fortios modules. The same business change is translated into each vendor's object + rule syntax from a single source of truth.

arjun@netauto:~/firewall-iac$ git checkout -b chg10422-allow-pay
arjun@netauto:~/firewall-iac$ ansible-playbook -i inventory.ini site.yml --check --diff
arjun@netauto:~/firewall-iac$ git commit -am "CHG10422 allow 203.0.113.40 -> pay-app (HTTPS)"
arjun@netauto:~/firewall-iac$ git push origin chg10422-allow-pay   # open PR, get review
# --- after a teammate approves the PR ---
arjun@netauto:~/firewall-iac$ ansible-playbook -i inventory.ini site.yml

PLAY [Palo Alto] ** changed: address-object, security-rule, COMMIT (candidate->running)
PLAY [FortiGate] ** changed: firewall_address x2, firewall_policy (REST, live)
PLAY RECAP **********
pa-fw-01 : ok=3  changed=3  failed=0
fg-01    : ok=3  changed=3  failed=0

Why bother with all this rigour? Because the perimeter is a live target. In 2024, PAN-OS CVE-2024-3400 (GlobalProtect command injection, CVSS 10.0) was actively exploited in the wild, and CVE-2024-0012 let attackers bypass the management web interface auth. When the next advisory drops, the team that can review, dry-run and roll out a hardening rule across every firewall from code in minutes — with an audit trail — is in a very different place from the team clicking 40 GUIs by hand at 2 a.m. Rules-as-code isn't just tidiness; it's how you respond fast and prove what you did.