PaloAltoNetworks/pan-os-ansible

panos_security_rule creates broken rules with Panorama v10 and connected firewall v9.1

thowerner opened this issue ยท 9 comments

Describe the bug

panos_security_rule creates broken rules with Panorama v10:

if attribute "hip-profiles" is not specified, it is set to "any"

in PAN-OS v10, the attribute "hip-profiles" does not exist anymore and is now called "source-hip"

when the rule is added via Ansible, the rule in Panorama now has both "hip-profiles" and "source-hip" attribute set to "any" (when checked via Panorama xml api)

Panorama commit is successful.

However, when commit push to device-group and firewall running PAN-OS v9.1, the "source-hip" gets apparently converted to back to "hip-profiles" and commit fails complaining about duplicate node "hip-profiles"

etails:
. Validation Error:
. rulebase -> security -> rules -> Test-added-by-Ansible -> hip-profiles is a duplicate node
. rulebase -> security -> rules is invalid
. Commit failed

Expected behavior

Use correct attribute names for PAN-OS 10
or
do not set "hip-profiles" to "any" when not specified ("any" is the default anyway)

Current behavior

Due to behaviour to set not specified attribute "hip-profiles" to "any", commit fails.

Possible solution

Do not set attribute "hip-profiles" at all when not specified.

Steps to reproduce

Panorama v10
Connected firewall v9.1
Add rule via Ansible to Panorama device group
Commit Panorama (successful)
Commit push (fails: hip-profiles is a duplicate node)

Screenshots

N/A

Context

N/A

Your Environment

  • Collection: 2.9.0
  • Panorama v10
  • Connected firewalls v9.1

๐ŸŽ‰ Thanks for opening your first issue here! Welcome to the community!

In the meanwhile I could find a workaround by deleting the "hip-profiles" after the rule was added by "panos_security_rule".

- name: "Fix hip-profiles issue"
  panos_type_cmd:
    provider: "{{ panorama_provider }}"
    cmd: "delete"
    xpath: "/config/devices/entry[@name='localhost.localdomain']/device-group/entry[@name='{{ device_group }}']/pre-rulebase/security/rules/entry[@name='{{ rule_name }}']/hip-profiles"

However, it would be better if the module "panos_security_rule" could be fixed to handle this constellation accordingly.

@thowerner

There's been an update on the pan-os-python side removing hip_profiles from the XML send to PAN-OS for PAN-OS >= 10.1.5. In the opening comment of this github issue, you say you're on v10. Can you confirm exactly which version of PAN-OS you are running? I am wondering if this should be lowered to 10.1.0, or if this change was really introduced in 10.1.5.

We are on Panorama version 10.0.x, so I guess it should be lowered to 10.0.0, in this version the hip-profiles was replaced by source-hip

Ok, I've updated the pan-os-python code to remove it in PAN-OS 10.0.0, and am making a release for it now.

If you upgrade pan-os-python to this new release, it will prevent pan-os-python from sending the hip_profiles param to PAN-OS, but until I can get around to fixing the Ansible collection, Ansible will report that changes are needed if you do not explicitly set hip_profiles to null.

2ps commented

Ok, I've updated the pan-os-python code to remove it in PAN-OS 10.0.0, and am making a release for it now.

If you upgrade pan-os-python to this new release, it will prevent pan-os-python from sending the hip_profiles param to PAN-OS, but until I can get around to fixing the Ansible collection, Ansible will report that changes are needed if you do not explicitly set hip_profiles to null.

Very sorry about all of the extra work this is causing for the open source team, but really appreciate your engagement on this issue. We also have pulls #314 related to this issue open.

Ok, I've updated the pan-os-python code to remove it in PAN-OS 10.0.0, and am making a release for it now.

If you upgrade pan-os-python to this new release, it will prevent pan-os-python from sending the hip_profiles param to PAN-OS, but until I can get around to fixing the Ansible collection, Ansible will report that changes are needed if you do not explicitly set hip_profiles to null.

With "explicitly set hip_profiles to null", you mean like this?

  • name: add SSH inbound rule to Panorama device group
    panos_security_rule:
    provider: '{{ provider }}'
    device_group: 'Cloud Edge'
    rule_name: 'SSH permit'
    description: 'SSH rule test'
    tag_name: ['production']
    source_zone: ['public']
    source_ip: ['any']
    destination_zone: ['private']
    destination_ip: ['1.1.1.1']
    application: ['ssh']
    action: 'allow'
    hip_profiles: null

@thowerner

I think that is the correct syntax, yes, but I haven't verified. The fix will actually be to not have a default value for hip_profiles, so it will be python None by default.

๐ŸŽ‰ This issue has been resolved in version 2.10.0 ๐ŸŽ‰

The release is available on Ansible Galaxy and GitHub release

Posted by semantic-release bot