But with "List IPSec crypto profiles" Inconsistent returns #274
Comments
|
I did a quick fix within my api I'll release to work around this issue as I log this internally as an error as well and you can see how I'm getting a bunch of errors I'm needing to correct: 2023-02-19 15:16:28,729 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,729 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,729 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,729 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,730 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,731 prismasase.restapi: ERROR Palo Alto SASE returning incorrect folder
location; expected Service Connections, recieved Remote Networks
2023-02-19 15:16:28,731 prismasase.restapi: INFO Retrieved List of all Ike Crypto Profiles
in Folder=Service Connections total=13Here is a sample code I pass responses to work around it: def bug_274_fix_ensure_folder(folder: str, data: list) -> list:
"""See https://github.com/PaloAltoNetworks/pan.dev/issues/274 pushing
response through verification to ensure that the folder is
correct otherwise it causes issues down the line if you don't get
the correct response. Pending resolution of issue or explaintion.
Till then pass the response through this to ensure consistency.
Args:
folder (str): folder location
data (list): List of dictionary data response from API call
Returns:
list: _description_
"""
for _ in data:
if _['folder'] != folder:
prisma_logger.error(
"Palo Alto SASE returning incorrect folder location; expected %s, recieved %s",
folder, _['folder'])
_['folder'] = folder
return datareleasing in (sase-api)[https://github.com/atav928/prisma-access-sase/tree/service-connection-changes] I would hope that I could remove this extra function as I would like to rely on a correct response instead of having to do additional checks and balances on the data being sent back. Please work on fixing this. As, it now has me concerned with my production configurations and has me passing all global searches through this function for verification to ensure you are passing the correct info. |
|
Update on my sample code. Apparently not all returns received from Palo Alto API send back the folder location causing the above to crash. Which makes it difficult to know where a configuration is located if you cannot determine the folder or position some configuration is in. I made another modification to now add that field to every response so that I have the ability to know what location it is in. This is similar to how I had to build out my Panorama SDK where I always could traceback what location something is in as just using the UUID is great, but does't tell you where that config is located. def bug_274_fix_ensure_folder(folder: str, data: list) -> list:
"""See https://github.com/PaloAltoNetworks/pan.dev/issues/274 pushing
response through verification to ensure that the folder is
correct otherwise it causes issues down the line if you don't get
the correct response. Pending resolution of issue or explaintion.
Till then pass the response through this to ensure consistency.
Args:
folder (str): folder location
data (list): List of dictionary data response from API call
Returns:
list: _description_
"""
for _ in data:
if _.get('folder', "") != folder:
prisma_logger.error(
"Palo Alto SASE returning incorrect folder location; expected %s, recieved %s",
folder, _.get('folder', "empty"))
_['folder'] = folder
return data |
Documentation link
https://pan.dev/access/api/prisma-access-config/get-sse-config-v-1-ipsec-crypto-profiles/
Describe the problem
When calling on ike-crypto-profiles you need to specify the folder that you are looking to get a response from. Unfortunately, I send a specific Folder in the query to get a list of al IKE Crypto Profiles in Service Connection Folder, yet I get a response with everything in the "Remote Network" folder instead; which I know is wrong because there is a specific IKE Crypto Profile I use called "ike-crypto-profile-standard" that is located in the "Service Connection" Folder and not in the "Remote Networks" folder. So, somehow you are returning the incorrect folder location which is breaking all my back end code as I reformat your data based on the location of where it is making everything look like it is in the "Remote Network" location which is a bit of a problem.
Here is my curl:
Here is my response:
{ "data": [ { "id": "2b1b21fd-6703-4190-9db9-289e677bac99", "name": "CloudGenix-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512" ], "dh_group": [ "group5" ], "encryption": [ "aes-256-cbc" ], "lifetime": { "hours": 8 } }, { "id": "3f7915a0-f3c3-4c6e-ad52-20585710ae25", "name": "Citrix-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha256" ], "dh_group": [ "group20" ], "encryption": [ "aes-256-cbc" ], "lifetime": { "hours": 8 } }, { "id": "a02486d2-8bbf-489e-85bb-5280669aeeba", "name": "Riverbed-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512" ], "dh_group": [ "group2" ], "encryption": [ "aes-256-cbc" ], "lifetime": { "hours": 8 } }, { "id": "8f42e98b-f55f-4945-a0f3-691862b38168", "name": "SilverPeak-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512" ], "dh_group": [ "group14" ], "encryption": [ "aes-256-cbc" ], "lifetime": { "hours": 8 } }, { "id": "03e6ad27-ba15-425e-ad47-31229658ced8", "name": "CiscoISR-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512", "sha384", "sha256", "sha1" ], "dh_group": [ "group5", "group2" ], "encryption": [ "aes-256-cbc", "aes-192-cbc", "aes-128-cbc" ], "lifetime": { "hours": 8 } }, { "id": "cd418541-d678-4900-95a4-869267ab0406", "name": "CiscoASA-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512", "sha384", "sha256", "sha1", "md5" ], "dh_group": [ "group5", "group2", "group1" ], "encryption": [ "aes-256-cbc", "3des" ], "lifetime": { "hours": 8 } }, { "id": "a5f9778e-73d6-42ba-9ace-d018be74cf6c", "name": "Viptela-IKE-default", "folder": "Remote Networks", "hash": [ "sha1" ], "dh_group": [ "group2" ], "encryption": [ "aes-128-cbc" ], "lifetime": { "hours": 8 } }, { "id": "35920918-010c-4aa5-9982-7f239a1a2387", "name": "Suite-B-GCM-128", "folder": "Remote Networks", "hash": [ "sha256" ], "dh_group": [ "group19" ], "encryption": [ "aes-128-cbc" ], "lifetime": { "hours": 8 } }, { "id": "ac20decb-90ee-4ba9-b3d9-10467e5be04e", "name": "Suite-B-GCM-256", "folder": "Remote Networks", "hash": [ "sha384" ], "dh_group": [ "group20" ], "encryption": [ "aes-256-cbc" ], "lifetime": { "hours": 8 } }, { "id": "ce26111c-b01e-4595-830a-87d06e7b9765", "name": "Velocloud-IKE-default", "folder": "Remote Networks", "hash": [ "sha1" ], "dh_group": [ "group5" ], "encryption": [ "aes-128-cbc" ], "lifetime": { "hours": 8 } }, { "id": "d646d190-094d-4ed2-96c3-c68f9c551d22", "name": "PaloAlto-Networks-IKE-Crypto", "folder": "Remote Networks", "hash": [ "sha1" ], "dh_group": [ "group2" ], "encryption": [ "aes-128-cbc", "3des" ], "lifetime": { "hours": 8 } }, { "id": "83d4bdf0-87cb-4177-845c-478f336b40c8", "name": "Others-IKE-Crypto-Default", "folder": "Remote Networks", "hash": [ "sha512", "sha384", "sha256", "sha1", "md5" ], "dh_group": [ "group20", "group19", "group14", "group5", "group2", "group1" ], "encryption": [ "aes-256-cbc", "aes-192-cbc", "aes-128-cbc", "3des" ], "lifetime": { "hours": 8 } }, { "id": "19f22703-f04d-403b-a7f4-cffdcd8c1154", "name": "ike-crypto-profile-standard", "folder": "Remote Networks", "dh_group": [ "group14" ], "lifetime": { "hours": 8 }, "encryption": [ "aes-256-cbc" ], "hash": [ "sha256", "sha384", "sha512" ] } ], "offset": 0, "total": 13, "limit": 200 }You can see from the above response you are sending me back the folder location of "Remote Networks" which is incorrect as when I specify "Remote Networks" there are actually 29 IKE Profiles listed in that folder causing all types of confusion and issues with retrieving correct information.
Suggested fix
Return the correct responses based on the query being sent or remove the folder requirement and ensure each UUID has the correct associated folder to it?
The text was updated successfully, but these errors were encountered: