Possibility to persist id's in ipsec

[mdepedrof]

I know that due to limitations in the xml management, the object_id is not persisted. However, in the IPSec section there is already a value that is persisted and it is the ikeid for phase1 and the uniqueid for phase2. These values are used by the GUID to edit or delete an ipsec tunnel. I think it would be great to be able to use these identifiers as Object_id as it would eliminate a lot of headaches.

My use case: I have to create more than 2000 tunnels in several pfsense apliances and in order to do it via api if I were to use the phase1 endpoint in singular, every time I delete a tunnel I have to recreate ALL tunnels in the collection. To avoid this I have to use the phase1s?limit=1&ikeid=value endpoints to be able to locate and manage the tunnel in question without affecting the rest. This works fine for me, but the problem is that these endpoints query all the elements. As there are more and more elements, the api gets more and more saturated just to find a single element that I know has a certain ikeid (or a uniqueid in the case of phase2).

[jaredhendrickson13]

For v2, it was intentionally decided early on to rely solely on the pfSense IDs for all objects for these reasons:

• Consistency: IDs are uniform across all endpoints and match those used in the webConfigurator, so you don’t need to consult documentation for each endpoint.
• Performance: Using the object’s index in the configuration allows faster access without having to iterate over the entire set each time an object is read.
• Simplicity: Unlike v1, which allowed arbitrary unique fields as IDs for some endpoints, this approach is easier to maintain as it avoids the need for inconsistent manual logic and documentation for each endpoint.

However, I've had the idea of implementing templating features for API requests for a while now. This could be a use case for that. It would allow you to lookup the id (or any other field) of an object by another field using a lookup similar to Ansible's 'lookup' filters. For example, you could obtain the ID of an IPsecPhase1 by its ikeid within the id field specification of your request data. It would look something like:

"id": "{{ lookup('IPsecPhase1', 'ikeid', 2).id }}"

If that sounds suitable, I could look into implementing a feature like this in v2.3.0. Let me know what you think.

Thanks!

[mdepedrof]

it could be a solution but how is it different from the option of using the endpoint that performs this filter ipsec1s&ikeid=1

the problem with doing this is that it depends on the amount of elements in those arrays. In my case I already have more than 2400 elements. The first ones go very fast but when you call the last ones, when going through ALL the elements of the array to find the one that matches, it takes a lot of time.

My proposal was to use the ikeid value as the identifier. This identifier is pfsense's own and, in my point of view, it fulfills better the 3 premises you mentioned.

- Consistency: I think this would provide more consistency since in the Phase2 endpoints explicit reference is made to this id to relate the phase2 with the tunnel needed.

• Performance: As I said before, the current model fails in performance when there are high volumes. This approach would be more optimal because when retrieving a single element, it would not be necessary to go through all the previous ones, just retrieve a single record.

• Simplicity: from my point of view, it is simpler to use an identifier that the system itself already uses and not to generate a different one that changes with each modification of the array. Also that id is shown on the screen so it provides much more clarity because it is easy to get the id.

in any case, a great job! thanks for everything!

[schneemaier]

I have similar issue with Firewall rules:
In v1 I used tracer ID to enable, disable rules via the API. Tracker ID s are visible in the UI and presistent. Now with V2 I have to do 3 queries:

1. Query all rules and get the ID based on the tracker ID
2. Update the rule status with the ID
3. Apply all pending changes
   In V1 this was 1 single call

Thanks