Open alexortize opened 8 months ago
Hello @alexortize, the firewall
subcommand targets the firewalls directly, does that solve your need?
I was more interested on direct connection when doing batch and HA upgrades.
On Tue, Feb 27, 2024 at 12:58 PM Calvin Remsburg @.***> wrote:
Hello @alexortize https://github.com/alexortize, the firewall subcommand targets the firewalls directly, does that solve your need?
— Reply to this email directly, view it on GitHub https://github.com/cdot65/pan-os-upgrade/issues/101#issuecomment-1967494040, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASSKTI2IDQNE3Z5JDPEQDVTYVY3IDAVCNFSM6AAAAABD4XEQL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGQ4TIMBUGA . You are receiving this because you were mentioned.Message ID: @.***>
Understood. A couple hurdles stand in the way and I'd be interested to getting your perspective:
Panorama provides a source of inventory as well as the connection to the devices. If we decide to target the firewalls directly, then we need to find a way of gathering a list of the devices and their IP addresses.
Since this is already captured when we run the batch
or inventory
commands, I'll assume that we can continue to keep this logic intact, but it would require a Panorama to be within the environment to derive our list from, is that okay?
Workflow would be like this: target Panorama to get a list of the devices, then use the IP address returned to form direct connections to the firewalls.
In order to pull this off, we would need to ensure that the authentication credentials work for both Panorama and every firewall. This may not be an issue for some environments, but it will pose challenges for others. Do you see any challenges with this requirement in your setup?
Multi-threading will prevent us from being able to prompt for unique username/password combinations across multiple firewalls.
That’s perfect!
On Tue, Feb 27, 2024 at 1:31 PM Calvin Remsburg @.***> wrote:
Understood. A couple hurdles stand in the way and I'd be interested to getting your perspective: Inventory
Panorama provides a source of inventory as well as the connection to the devices. If we decide to target the firewalls directly, then we need to find a way of gathering a list of the devices and their IP addresses.
Since this is already captured when we run the batch or inventory commands, I'll assume that we can continue to keep this logic intact, but it would require a Panorama to be within the environment to derive our list from, is that okay?
Workflow would be like this: target Panorama to get a list of the devices, then use the IP address returned to form direct connections to the firewalls. Authentication
In order to pull this off, we would need to ensure that the authentication credentials work for both Panorama and every firewall. This may not be an issue for some environments, but it will pose challenges for others. Do you see any challenges with this requirement in your setup?
Multi-threading will prevent us from being able to prompt for unique username/password combinations across multiple firewalls.
— Reply to this email directly, view it on GitHub https://github.com/cdot65/pan-os-upgrade/issues/101#issuecomment-1967541014, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASSKTIZABKQEN7DT6GHMPWTYVY7CZAVCNFSM6AAAAABD4XEQL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGU2DCMBRGQ . You are receiving this because you were mentioned.Message ID: @.***>
I agree with you that this would work only for environment where same creds work for both panorama and the firewalls.
On Tue, Feb 27, 2024 at 1:31 PM Calvin Remsburg @.***> wrote:
Understood. A couple hurdles stand in the way and I'd be interested to getting your perspective: Inventory
Panorama provides a source of inventory as well as the connection to the devices. If we decide to target the firewalls directly, then we need to find a way of gathering a list of the devices and their IP addresses.
Since this is already captured when we run the batch or inventory commands, I'll assume that we can continue to keep this logic intact, but it would require a Panorama to be within the environment to derive our list from, is that okay?
Workflow would be like this: target Panorama to get a list of the devices, then use the IP address returned to form direct connections to the firewalls. Authentication
In order to pull this off, we would need to ensure that the authentication credentials work for both Panorama and every firewall. This may not be an issue for some environments, but it will pose challenges for others. Do you see any challenges with this requirement in your setup?
Multi-threading will prevent us from being able to prompt for unique username/password combinations across multiple firewalls.
— Reply to this email directly, view it on GitHub https://github.com/cdot65/pan-os-upgrade/issues/101#issuecomment-1967541014, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASSKTIZABKQEN7DT6GHMPWTYVY7CZAVCNFSM6AAAAABD4XEQL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGU2DCMBRGQ . You are receiving this because you were mentioned.Message ID: @.***>
Is your feature request related to a problem? Please describe. No but a potential one if too many calls to Panorama API endpoint.
Describe the solution you'd like Provide a way to bypass default behaviour of proxying via Panorama
Describe alternatives you've considered None
Additional context We had issues when using upgrade assurance module in Ansible when proxying connection via Panorama