Thanks for opening this Issue! We really appreciate the feedback & testing from users like you!

I let Ryan comment on the questions asked in this. But IMO, even if ip addresses are to be used, we should use them via the ipam > ipaddress model as a foreign key. I'd discourage the use of char fields for adding any arbitrary ip addresses.

+1 for adding IPs as a src or dst item. We have alot of ACLs that have host IPs listed in entries.

also of note, as a result of the source/destination object being required to be a netbox "prefix" object you can't represent a default any prefix object. Netbox does not allow you to create a prefix to represent any that is 0.0.0.0/0 prefix/netmask combination. There have been several requests asking for that functionality that were rejected. so that is unlikely to change.

adding support for /0 netmask was discussed/rejected here -
netbox-community/netbox#10968
netbox-community/netbox#6825

as a result you can't configure the following policy/rule with netbox-acl:

source: any / 0.0.0.0/0
destination: 192.168.1.0/24
destination port: 22
protocol: tcp
action: deny

also of note, as a result of the source/destination object being required to be a netbox "prefix" object you can't represent a default any prefix object. Netbox does not allow you to create a prefix to represent any that is 0.0.0.0/0 prefix/netmask combination. There have been several requests asking for that functionality that were rejected. so that is unlikely to change.

adding support for /0 netmask was discussed/rejected here - netbox-community/netbox#10968 netbox-community/netbox#6825

as a result you can't configure the following policy/rule with netbox-acl:

source: any / 0.0.0.0/0
destination: 192.168.1.0/24
destination port: 22
protocol: tcp
action: deny

Hey, you can leave the Source/Destination-Prefix/Port field blank and then you have your "Any" rule.

I'd like to work on this feature (ideally implement it for v1.5.0 and newer), can it be approved and assigned to me?
@ryanmerolle
@abhi1693

Being able to select a Service as target instead of an IP address and port would be awesome as well.

@ryanmerolle
@abhi1693
@cruse1977

Right now i'm simply adding source_<model> and destination_<model> fields, that each link to their respective model.
And i'm setting form- and model constraints, so that only one source/destination can be set.
However, in the Interface Assignment, i discovered how you implemented dynamic association through assigned_object.
I could replicate this behavior for the source and destination, but it would likely get unnecessarily complicated, and the changes to the API would not be backwards compatible.

I'm proceeding with my approach for now, but let me know, if the assigned_object approach is preferred!

@ryanmerolle
@abhi1693
@cruse1977

I have completed the work for this feature.
Please have a look at the merge request above :)

(I was not able to backport it to 1.5.0. I think we would need version specific release branches for that)

hi @rvveber will look to review this next week - thanks for your submission, please note for future commits please don't bump the version number, more than likely this will go into a 1.7.0 release (for NetBox 4.1)

Great! Thanks!
(I have removed the version bump for your convenience)

Hi people, is there a blocker to this PR? I would love to have this merged.

Thanks for your work!

Hi people, is there a blocker to this PR? I would love to have this merged.

Thanks for your work!

+1. We also need this Feature very urgently!

hi @rvveber will look to review this next week - thanks for your submission, please note for future commits please don't bump the version number, more than likely this will go into a 1.7.0 release (for NetBox 4.1)

I really don't want to be rude, but i put a lot of effort into the solution 2 months ago, and it's kind of important that it will be available before the end of this year.
@cruse1977 Could you please consider merging and releasing?

Hey @jeremystretch, please can you take a look on this? We need this function as soon as possible, but are unfortunately dependent on the merge request. Many thanks in advance!

Do we have update on this? I urgently need this feature

@ryanmerolle may i ask to help you maintain this project?
Looks like the maintainers are too busy and contributions have come to a halt.
Maybe because the development environment is in a non functional state
and maybe because the big refactor you planned was a little too big.
I could provide a nix based development environment,
removing the need for docker, vscode plugins and other dependencies entirely.

Happy last day of the year!

Any update on this?

First of all, thank you very much for addressing this issue and for the incredible effort you've put into providing a valid solution that's ready to be merged. Your work is highly appreciated!

@ryanmerolle @abhi1693 @cruse1977
Right now, I'm simply adding source_<model> and destination_<model> fields, that each link to their respective model. I'm setting form- and model constraints so that only one source/destination can be set. However, in the Interface Assignment, I discovered how you implemented dynamic association through assigned_object. I could replicate this behavior for the source and destination, but it would likely get unnecessarily complicated, and the changes to the API would not be backwards compatible.
I'm proceeding with my approach for now, but let me know if the assigned_object approach is preferred!

Would you be open to reconsidering the assigned_object approach?

While your current solution is a valid and functional implementation, I believe that adopting the assigned_object methodology could offer significant advantages, particularly in light of FR #56 and the ever-expanding NetBox model and plugin ecosystem. Specifically, the assigned_object approach seems more scalable and future-proof.

Moreover, migrating from the source_<model>/destination_<model> approach to an assigned_object implementation later could be considerably more challenging than transitioning the existing prefix data in NetBox to an assigned_object solution now. Would you agree?

I understand that such a change would introduce a breaking API modification, but this could potentially be addressed as part of a version 2.0.0 release.

Regarding the complexity: I’ve implemented a similar feature before and would be more than happy to assist you with this if needed.

Thank you again for all your hard work!

@pheus I don't have the time to re-implement this with dynamic assignments.
Maybe someone else can take the time, contact @pheus and continue on this branch.

Personally, i think your suggestion is unrealistic:
It will cause this issue to be dragged along for even longer and it will break existing API calls which introduces additional work from users.

@pheus If you want to contribute this, feel free. I have rebased the branch.
However, if you also have no time, i would suggest doing this in a future major update that will break things anways.

@cruse1977

Thank you for taking the time to respond and consider my suggestion.

I completely understand your concern about dragging this issue out further, and I agree that delaying it might not be ideal. That said, I still believe that migrating later could make things even more complicated.

Regarding the API breaking changes, I agree that they can be inconvenient, but since NetBox itself introduces such changes from time to time, users might already be accustomed to adapting.

Nonetheless, I’d be happy to try contributing this approach based on your work, if that’s okay with you. It would be really helpful if you could find the time to test my implementation when it’s ready. If you’re not satisfied with the results, I’m completely fine with my suggestion or implementation being canceled.

Thanks again for your efforts!

@rvveber I just wanted to let you know that I’ve been working on the assigned_object / dynamic assignment approach. Unfortunately, I couldn’t reuse much of your code since the approaches were quite different :/ — please don’t take this in a negative way.

I’ll post a first draft in the coming days.

@pheus No worries, i was aware that it would change a lot, which is why i didn't have the time.

@users
If all you need are custom Entities requestable via API and you are okay with putting minimal effort into creating the Entitites, then why not go with Directus? You will be able to create whatever you need without programming or waiting for others.

@rvveber Thank you! 😀

@cruse1977 As you may have noticed, I’m working on backporting all small fixes, code cleanups, and minor features to the dev branch, ensuring that all unrelated changes remain separate from this feature. I hope this works in your favor.

@pheus your work is very much appreciated! I'm keeping an eye and approving as required - however am split over a number of projects currently and circling as time allows. With Netbox 4.3 due relatively shortly I expect that release to wrap in any major new feature updates.

@cruse1977 Thank you, I really appreciate it! 😊
I completely understand that you’re balancing multiple projects. I’ll keep pushing updates as needed, and we can align as time allows.

Quick status update on this feature: I’ve completed most of the work but am currently focusing on backporting all drive-by fixes and enhancements.

If there’s interest, I can publish the current version to a WIP branch. Once all backports are merged, I’ll create a complete PR.

Being able to select a Service as target instead of an IP address and port would be awesome as well.

@killermoehre How would you expect the behavior to work when using a Service as a source and/or destination?

I don’t currently use Services extensively, so I’m not too familiar with their typical usage. From my testing, I noticed that Services must be bound to a Device, a protocol (TCP, UDP, SCTP), and ports, but they don’t necessarily need an assigned IP address.

Would you expect only Services with an assigned IP address to be valid as source/destination? Or should a Service serve as an alternative to defining TCP/UDP ports and not require an assigned IP address?

The more I think about this, the more it seems like this should be a separate Feature Request. This would allow for a dedicated discussion on expectations and the implementation of more complex logic and tests. What do you think?

@pheus If a service is not bound to an IP, then I expect that all IP addresses of the device are valid sources/destinations.

The same if you would bind your local service to 0.0.0.0, listening on all interfaces and IPs.

Thank you for clarifying, @killermoehre.

I think that behavior should be possible, but I believe these cases would be better handled as a new feature. Would you mind opening a new issue as a feature request so we can separate these detailed discussions? It would be awesome if you could provide your use case and expectations.

Oh, my. I'm not any more in the project where this was a necessary feature. @rvveber can you describe the expectation here?

Does it matter? @pheus
Service is an entity, and it should be addressable, just like the other entities.
As far as i understand, netbox does nothing, it is just another relational database
with pre-defined entities that can be edited via GUI and can be accessed via API.
It always has to be interpreted via API in actual programmatic scenarios.
It is not our concern what is done exactly with the entity.

Can you not implement it exactly how i did, just dynamically?

Thanks for your responses, @rvveber and @killermoehre!

I think I understand your point — your stance is that the API user should handle the different scenarios, right?
While I agree that translating NetBox's data model into vendor-specific configurations isn't the responsibility of this plugin, I do believe the plugin should enforce only valid combinations for an ACL rule.

I've already implemented dynamic support for Services, but during testing I noticed that, without proper validation, it's possible to define both a Service and custom TCP/UDP ports at the same time. There's also the use case where users define Services based solely on ports (e.g., a Service named "SSH" with TCP/22) and want to combine that with a manually specified IP address or prefix. Another example would be something like Microsoft Active Directory, which could be modeled as a Service without an IP, and used in an ACL with a destination IP address and destination service MS-AD.

That’s why I feel this should be handled separately from the original feature request, which focuses on supporting IP addresses and IP ranges directly. A dedicated feature request would give us space to discuss expectations and implementation details for Service-based rules more thoroughly.

Just to clarify: I’m happy to implement this behavior — I just want to make sure we clearly understand the intended use cases and can apply the right validation logic.
In short: I’d prefer to split the Service-related discussion into its own feature request.

Thanks again!

Hi everyone,

I just wanted to share a quick update on the current status of this feature request, especially after a bit of quiet here.

Most of the relevant backports have already been submitted as PRs and merged — thank you to everyone involved! There are just a few outstanding issues still pending, all of which already have open PRs:

• [Housekeeping]: Develop Plugin Tests - Models #47
• [Housekeeping]: Develop Plugin Tests - API #131
• [Feature]: Add internationalization (i18n) support to AccessList models #264

In the meantime, as many of you know, NetBox v4.3 was recently released. This version introduces changes that require a complete rewrite of the GraphQL filters, which is now being tracked in #261. I assume that getting the plugin fully compatible with NetBox 4.3 is a high priority for most of us.

Once those last few backports are merged and the 4.3 migration is complete, I’ll rebase the feature branch and open a proper PR for review.

Thanks again to everyone for your patience and support. I'm optimistic we’re getting close!