Add Native "Any" Objects and Improved NAT Rule Mapping

[JHarrison712]

Summary:
When modeling Palo Alto Networks (PAN-OS 11.1.1) NAT and Security policies in the Nautobot Security plugin, several gaps exist that make it difficult or impossible to accurately represent basic rules especially those that use the standard “any → any” logic or dynamic NAT translations.

Palo Alto firewalls natively support any for source, destination, service, and zone fields, but Nautobot Security requires fully defined object references (IP range, prefix, etc.). This creates validation errors, prevents imports, and breaks fidelity when syncing or documenting real-world firewall configurations.

Environment:
Firewall Platform: Palo Alto Networks PA-850
PAN-OS Version: 11.1.1
Nautobot Version: 2.4.20
Nautobot Security Plugin: 2.3.0

Example Issue
Palo Alto Rule:

Field	Value
Name	NAT_GBR1_XYZ_EXT_DYNAMIC
Source Zone	ZONE-GBR1-XYZ
Destination Zone	ZONE-GBR1-EDGE1-UNTRUST
Destination Interface	any
Source Address	any
Destination Address	any
Service	any
Source Translation	dynamic-ip-and-port (ethernet1/1)
Destination Translation	none
Tags	outbound

Root Cause:
Nautobot Security does not provide built-in “any” placeholder objects or dynamic translation templates compatible with Palo Alto’s configuration schema.

[itdependsnetworks]

As noted in: https://docs.nautobot.com/projects/firewall-models/en/latest/user/capirca/#special-considerations we provide recommendations for how to use it to generate all capirca configurations. Specifically we note:

In addition to the above, you can add to any header or term by creating specific custom fields on the PolicyRule data model. They must start with:

• chd_ - Capirca Header Data - will be applied to the header for any given rule.
• ctd_ - Capirca Term Data - will be applied to the term for any given rule.

The process is to create a custom field, such as ctd_pan-application, this will be applied to the PolicyRule as you describe. This can become problematic if you share the model for multiple firewall OSs. This can be conditionally applied via a custom field to the Platform model. This custom field must be named capirca_allow and be of type JSON and be a single list. For each OS defined by the platform, you can allow that custom field to populate. This allows you to use the same model, and not let the custom fields for one OS conflict with another OS.

capirca_allow = ['ctd_pan-application', 'ctd_expiration']

That means, there is the ability to support all of these configuration options that are supported by capirca, for not only data modeling, but also configuration generation.

I know that these are not the best options, but I am not sure what data model would be generic, simple, and feature complete with every vendor implementation. That being said, if you have any feedback for how to complete all 3, would be great to get such feedback.