starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Firewall/ACL rules #11804

New Issue
Closed
opened 2025-12-29 21:50:03 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:50:03 +01:00
Owner
Copy Link

Originally created by @alexrsagen on GitHub (Nov 3, 2025).

NetBox version

v4.4.5

Feature type

Data model extension

Proposed functionality

  • Add data type: IPAM -> IP Addresses -> IP Lists (or IP Groups), with the following data model:
    • IP Addresses (one-to-many relation)
    • IP Ranges (one-to-many relation)
    • Prefixes (one-to-many relation)
    • IP Lists (one-to-many relation)
    • Hostnames (static list?)
  • Add data type: IPAM -> Other -> ACL Rules, with the following data model:
    • Chain:
      • Input
      • Output
      • Forward
      • Other (any user specified name, used with Jump/Return action)
    • Source address: Can be any of: IP List, IP Address, IP Range, Prefix, Hostname
    • Destination address: Same as source address
    • Protocol: See IPAM/Application Services and the suggestion to extend with additional protocols in this issue. A single 8-bit unsigned integer.
    • Source port: See IPAM/Application Services. A single 16-bit unsigned integer or a list/range of several ports, only applicable to the following protocols:
      • TCP/UDP (convenience option)
      • TCP
      • UDP
      • DCCP
      • SCTP
      • UDP-Lite
    • Destination port: Same as source port
    • Input interface: Any device interface, with option to select multiple interfaces
    • Output interface: Same as input interface
    • Connection state (for stateful firewalls): Invalid, Established, Related, New, Untracked
    • Action:
      • Accept
      • Drop
      • Reject
      • Jump (with a selection for which Chain to jump to)
      • Return (to previous chain, does not have to be specified, as multiple chains can jump to another chain)
    • Open to discussion: Should the data model be extended with additional advanced properties, such as layer 7 filtering options, MAC address, IPsec policy, packet size, TCP flags, ICMP options, IPv4 options, TTL, etc?
  • Extend IPAM/Application Services with additional protocols. Some of the most common protocols are listed here:
    • TCP/UDP (convenience option, as these protocols are commonly used together, for example in the case of DNS and HTTP/QUIC)
    • ICMP (1)
    • IGMP (2)
    • GGP (3)
    • IPv4 encapsulation (4)
    • ST (5)
    • EGP (8)
    • PUP (12)
    • HMP (20)
    • XNS-IDP (22)
    • RDP (27)
    • ISO-TP4 (29)
    • DCCP (33)
    • XTP (36)
    • DDP (37)
    • IDPR-CMTP (38)
    • IPv6 encapsulation (41)
    • RSVP (46)
    • GRE (47)
    • IPsec-ESP (50)
    • IPsec-AH (51)
    • RSPF/CPHB (73)
    • VMTP (81)
    • OSPF (89)
    • IPIP (94)
    • ETHERIP (97)
    • ENCAP (98)
    • PIM (103)
    • VRRP (112)
    • L2TP (115)
    • UDP-Lite (136)
    • Other (enter protocol number)

NAT rules could also be useful to document, but they behave differently and should have a different data model. As such I believe it should be a separate issue.

Use case

Useful for documenting firewall rules or L3 switch ACL rules.

Database changes

No response

External dependencies

No response

Originally created by @alexrsagen on GitHub (Nov 3, 2025). ### NetBox version v4.4.5 ### Feature type Data model extension ### Proposed functionality - Add data type: **IPAM -> IP Addresses -> IP Lists** (or **IP Groups**), with the following data model: - IP Addresses (one-to-many relation) - IP Ranges (one-to-many relation) - Prefixes (one-to-many relation) - IP Lists (one-to-many relation) - Hostnames (static list?) - Add data type: **IPAM -> Other -> ACL Rules**, with the following data model: - Chain: - Input - Output - Forward - Other (any user specified name, used with Jump/Return action) - Source address: Can be any of: IP List, IP Address, IP Range, Prefix, Hostname - Destination address: Same as source address - Protocol: See **IPAM/Application Services** and the suggestion to extend with additional protocols in this issue. A single 8-bit unsigned integer. - Source port: See **IPAM/Application Services**. A single 16-bit unsigned integer or a list/range of several ports, only applicable to the following protocols: - TCP/UDP (convenience option) - TCP - UDP - DCCP - SCTP - UDP-Lite - Destination port: Same as source port - Input interface: Any device interface, with option to select multiple interfaces - Output interface: Same as input interface - Connection state (for stateful firewalls): Invalid, Established, Related, New, Untracked - Action: - Accept - Drop - Reject - Jump (with a selection for which Chain to jump to) - Return (to previous chain, does not have to be specified, as multiple chains can jump to another chain) - **Open to discussion:** Should the data model be extended with additional advanced properties, such as layer 7 filtering options, MAC address, IPsec policy, packet size, TCP flags, ICMP options, IPv4 options, TTL, etc? - Extend IPAM/Application Services with [additional protocols](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Some of the most common protocols are listed here: - TCP/UDP (convenience option, as these protocols are commonly used together, for example in the case of DNS and HTTP/QUIC) - ICMP (1) - IGMP (2) - GGP (3) - IPv4 encapsulation (4) - ST (5) - EGP (8) - PUP (12) - HMP (20) - XNS-IDP (22) - RDP (27) - ISO-TP4 (29) - DCCP (33) - XTP (36) - DDP (37) - IDPR-CMTP (38) - IPv6 encapsulation (41) - RSVP (46) - GRE (47) - IPsec-ESP (50) - IPsec-AH (51) - RSPF/CPHB (73) - VMTP (81) - OSPF (89) - IPIP (94) - ETHERIP (97) - ENCAP (98) - PIM (103) - VRRP (112) - L2TP (115) - UDP-Lite (136) - Other (enter protocol number) NAT rules could also be useful to document, but they behave differently and should have a different data model. As such I believe it should be a separate issue. ### Use case Useful for documenting firewall rules or L3 switch ACL rules. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featureplugin candidatenetbox labels 2025-12-29 21:50:03 +01:00
adam closed this issue 2025-12-29 21:50:03 +01:00
adam commented 2025-12-29 21:50:03 +01:00
Author
Owner
Copy Link

@cruse1977 commented on GitHub (Nov 3, 2025):

Have you considered https://github.com/andy-shady-org/netbox-security - as a number of features are already within this plugin

@cruse1977 commented on GitHub (Nov 3, 2025): Have you considered https://github.com/andy-shady-org/netbox-security - as a number of features are already within this plugin
adam commented 2025-12-29 21:50:04 +01:00
Author
Owner
Copy Link

@alexrsagen commented on GitHub (Nov 3, 2025):

Thanks for the mention @cruse1977, I will check it out.

Not sure what is the Netbox approach to feature requests and development, when a plugin exists. I'd like to keep the feature request up if possible.

I did try to look around a bit for any Netbox firewall documentation solutions, and all I was able to find quickly was a fork of Netbox.

I believe that either having the feature built into Netbox or perhaps maintaining a list of endorsed plugins would help with discoverability.

@alexrsagen commented on GitHub (Nov 3, 2025): Thanks for the mention @cruse1977, I will check it out. Not sure what is the Netbox approach to feature requests and development, when a plugin exists. I'd like to keep the feature request up if possible. I did try to look around a bit for any Netbox firewall documentation solutions, and all I was able to find quickly was a fork of Netbox. I believe that either having the feature built into Netbox or perhaps maintaining a list of endorsed plugins would help with discoverability.
adam commented 2025-12-29 21:50:05 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 3, 2025):

Not sure what is the Netbox approach to feature requests and development, when a plugin exists. I'd like to keep the feature request up if possible.

I can't speak for every maintainer, but my view would be this is outside of the scope of the NetBox core (and in-scope for a plugin)

@DanSheps commented on GitHub (Nov 3, 2025): > Not sure what is the Netbox approach to feature requests and development, when a plugin exists. I'd like to keep the feature request up if possible. I can't speak for every maintainer, but my view would be this is outside of the scope of the NetBox core (and in-scope for a plugin)
adam commented 2025-12-29 21:50:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 3, 2025):

Agreed; this has been proposed before but is not something we would take on as part of the core product. @alexrsagen you find a list of commercially supported NetBox plugins here.

@jeremystretch commented on GitHub (Nov 3, 2025): Agreed; this has been proposed before but is not something we would take on as part of the core product. @alexrsagen you find a list of commercially supported NetBox plugins [here](https://netboxlabs.com/plugins/).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox plugin candidate type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11804
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?