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
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.
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.
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 sethip_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 sethip_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
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.
The release is available on Ansible Galaxy and GitHub release
Posted by semantic-release bot