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

Add new (extend list of) protocols in service templates and services #6964

New Issue
Closed
opened 2025-12-29 19:47:14 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:47:14 +01:00
Owner
Copy Link

Originally created by @stavr666 on GitHub (Sep 11, 2022).

NetBox version

v3.3.2

Feature type

Data model extension

Proposed functionality

Either add other IP protocols and combinations, that works over IP, or allow define options in FIELD_CHOICES.

Use case

It'll makes easier to use binding services for external inspections or for defining ACL, firewall and QoS rules, without unnecessary adding custom fields or config contexts.

Examples:

  • DNS uses both UDP and TCP, according to RFCs
  • MS RDP starting from v8 uses both UDP and TCP
  • NetBIOS using both UDP and TCP
  • ICMP must be allowed/blocked in some cases
  • PPPoE protocol
  • FCoE protocol

Database changes

No response

External dependencies

No response

Originally created by @stavr666 on GitHub (Sep 11, 2022). ### NetBox version v3.3.2 ### Feature type Data model extension ### Proposed functionality Either add other IP protocols and combinations, that works over IP, or allow define options in FIELD_CHOICES. ### Use case It'll makes easier to use binding services for external inspections or for defining ACL, firewall and QoS rules, without unnecessary adding custom fields or config contexts. Examples: - DNS uses both UDP and TCP, according to RFCs - MS RDP starting from v8 uses both UDP and TCP - NetBIOS using both UDP and TCP - ICMP must be allowed/blocked in some cases - PPPoE protocol - FCoE protocol ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:47:14 +01:00
adam closed this issue 2025-12-29 19:47:14 +01:00
adam commented 2025-12-29 19:47:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 12, 2022):

It sounds like the crux of your issue is being limited to the definition of a single protocol per service (e.g. TCP or UDP). However, applications which can use multiple underlying protocols should be modeled separately, to be more explicit about which protocol(s) and/or port(s) are actually being used.

It'll makes easier to use binding services for external inspections or for defining ACL, firewall and QoS rules

Wouldn't it be easier to define a discrete service for protocol? For example, if you have a DNS/TCP service and a DNS/UDP service, it's very straightforward to template out the generation of policy rules. However, if you're dealing with a service which may specify more than one protocol, your template needs to account for that and have the ability to potentially generate multiple rules for a single service. (It would also be impossible to declare a different set of ports for either protocol.)

@jeremystretch commented on GitHub (Sep 12, 2022): It sounds like the crux of your issue is being limited to the definition of a single protocol per service (e.g. TCP _or_ UDP). However, applications which can use multiple underlying protocols should be modeled separately, to be more explicit about which protocol(s) and/or port(s) are actually being used. > It'll makes easier to use binding services for external inspections or for defining ACL, firewall and QoS rules Wouldn't it be easier to define a discrete service for protocol? For example, if you have a DNS/TCP service and a DNS/UDP service, it's very straightforward to template out the generation of policy rules. However, if you're dealing with a service which _may_ specify more than one protocol, your template needs to account for that and have the ability to potentially generate multiple rules for a single service. (It would also be impossible to declare a different set of ports for either protocol.)
adam commented 2025-12-29 19:47:15 +01:00
Author
Owner
Copy Link

@stavr666 commented on GitHub (Sep 13, 2022):

I started Netbox integration as The Ultimate Source of Truth for infrastructure engeneers, so it's looks logical, to implement all network-related definition as new "service". I know, it's just added in 3.2, but looks promising.

I assume that it is theoretically possible to duplicate all the rules for common services in two services in the accounting system, just as it is done on window devices.
But from a practical point of view, to reduce the overhead when creating new services and to increase observability, it is more logical to keep one rule for one service (where possible). And to create correspondence on end devices in orchestration mechanisms.

Example (from our router) of ACL from Cisco:

remark --- V 20.07.2021 ---
remark ### NET CCTV ###
permit ip object-group TT-CCTV-NETS host 10.101.67.19
remark *** SERVICE Terminal farm - CCTV ***
permit tcp object-group TT-CCTV-NETS eq 3389 5650 object-group BRC-RD-FOR-SUPPORT
permit udp object-group TT-CCTV-NETS eq 3389 object-group BRC-RD-FOR-SUPPORT
remark *** TEMP ***
permit ip object-group TT-CCTV-NETS object-group BRC_VPN_GP
!EOF

Example of ufw rule from linux-server:

sudo ufw allow 5353/tcp
sudo ufw allow 5353/udp

Example of firewall rule from windows-server (posh):

New-NetFirewallRule -Display 'DNS' -Dir Inbound -Action Allow -Prot @('TCP', 'UDP') -LocalP 53

I know, implementing my request does not cover all scenarios, that will be defined either by additional tags, custom fields or config contexts. But it'll still reduce number of unnecessary actions in Netbox when deploying common services: ICMP, DNS, RDP, Bonjour.

@stavr666 commented on GitHub (Sep 13, 2022): I started Netbox integration as **The Ultimate Source of Truth** for infrastructure engeneers, so it's looks logical, to implement all network-related definition as new "service". I know, it's just added in 3.2, but looks promising. I assume that it is theoretically possible to duplicate all the rules for common services in two services in the accounting system, just as it is done on window devices. But from a practical point of view, to reduce the overhead when creating new services and to increase observability, it is more logical to keep one rule for one service (where possible). And to create correspondence on end devices in orchestration mechanisms. Example (from our router) of ACL from Cisco: ```shell remark --- V 20.07.2021 --- remark ### NET CCTV ### permit ip object-group TT-CCTV-NETS host 10.101.67.19 remark *** SERVICE Terminal farm - CCTV *** permit tcp object-group TT-CCTV-NETS eq 3389 5650 object-group BRC-RD-FOR-SUPPORT permit udp object-group TT-CCTV-NETS eq 3389 object-group BRC-RD-FOR-SUPPORT remark *** TEMP *** permit ip object-group TT-CCTV-NETS object-group BRC_VPN_GP !EOF ``` Example of ufw rule from linux-server: ```bash sudo ufw allow 5353/tcp sudo ufw allow 5353/udp ``` Example of firewall rule from windows-server (posh): ```powershell New-NetFirewallRule -Display 'DNS' -Dir Inbound -Action Allow -Prot @('TCP', 'UDP') -LocalP 53 ``` I know, implementing my request does not cover all scenarios, that will be defined either by additional tags, custom fields or config contexts. But it'll still reduce number of unnecessary actions in Netbox when deploying common services: ICMP, DNS, RDP, Bonjour.
adam commented 2025-12-29 19:47:15 +01:00
Author
Owner
Copy Link

@stavr666 commented on GitHub (Oct 5, 2022):

Temporal workaround for simple both-protocol cases:

  1. Since we don't use SCTP in acl and firewall rules, we use it as "both protocol" indication.
  2. If in some distant future option to choose more flexible definition of services will be added, this non-conventional use case was tagged with "service:both" custom tag.
@stavr666 commented on GitHub (Oct 5, 2022): Temporal workaround for simple both-protocol cases: 1. Since we don't use SCTP in acl and firewall rules, we use it as "both protocol" indication. 2. If in some distant future option to choose more flexible definition of services will be added, this non-conventional use case was tagged with "service:both" custom tag.
adam commented 2025-12-29 19:47:16 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 5, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 5, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:47:16 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 4, 2023):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jan 4, 2023): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#6964
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?