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

Naïve / generic approach to tunnel interfaces #5668

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

Originally created by @BarbarossaTM on GitHub (Nov 16, 2021).

NetBox version

v3.0.3

Feature type

Data model extension

Proposed functionality

It would be great if it were possible to model tunnels between devices/VMs in Netbox. As the field of tunnel mechanisms (GRE, SIT, IPIP, IPsec, Wireguard, OpenVPN, Tinc, fastd, ...) is huge, there is no way to model all possibilities and attributes here.

While thinking about options to model this in Netbox I first arrived at "Let's build a plugin" and later boiled it down to "What I really need is much simpler". Therefore I propose the following naïve and generic approach:

  • Add an interface type tunnel for devices and VMs
  • Add a connection type tunnel and allow connecting interfaces of type tunnel to it
  • Let users add any missing information via custom filds on the tunnel type
  • Be golden

Depending on whether to support PTMP setups the tunnel type would need to be created before making the connection. So I guess it would be something like a Provider Network but without circuits require for attachment.

One thing to consider is adding a Tunnel type field to the Tunnel model. If added it would be an extensive list and will require some iterations to be more or less complete. The alternatives obviously are to let the user add this a a custom field or add it as a field of type string. I would be in slight favor of the latter, as this field most likely will be required anyway.

Use case

The approach described above would allow to model

  • PTP tunnels
  • the relationship between tunnel endpoints
  • IPs on both ends
  • Underlay interfaces by use of the parent functionality

Which would suffice for GRE tunnels on Linux for example. If you were to use Wireguard or OpenVPN this would require to device at least on custom field on the tunnel and define the UDP port for example.

One could think about the ability to connect more than 2 endpoints to a tunnel. Allowing this should not fundamentally change the model and I would assume it wouldn't complicate things a lot, thereby offering support for more possible deployment scenarios like PTMP OpenVPN/Tinc setups etc.

Database changes

I guess this would require a new Tunnel type which allows to connect two (or more?) Interfaces of type tunnel.

External dependencies

None.

Originally created by @BarbarossaTM on GitHub (Nov 16, 2021). ### NetBox version v3.0.3 ### Feature type Data model extension ### Proposed functionality It would be great if it were possible to model tunnels between devices/VMs in Netbox. As the field of tunnel mechanisms (GRE, SIT, IPIP, IPsec, Wireguard, OpenVPN, Tinc, fastd, ...) is huge, there is no way to model all possibilities and attributes here. While thinking about options to model this in Netbox I first arrived at "Let's build a plugin" and later boiled it down to "What I really need is much simpler". Therefore I propose the following naïve and generic approach: - Add an interface type tunnel for devices and VMs - Add a connection type _tunnel_ and allow connecting interfaces of type tunnel to it - Let users add any missing information via custom filds on the tunnel type - Be golden Depending on whether to support PTMP setups the _tunnel_ type would need to be created before making the connection. So I guess it would be something like a Provider Network but without circuits require for attachment. One thing to consider is adding a _Tunnel type_ field to the _Tunnel_ model. If added it would be an extensive list and will require some iterations to be more or less complete. The alternatives obviously are to let the user add this a a custom field or add it as a field of type string. I would be in slight favor of the latter, as this field most likely will be required anyway. ### Use case The approach described above would allow to model - PTP tunnels - the relationship between tunnel endpoints - IPs on both ends - Underlay interfaces by use of the _parent_ functionality Which would suffice for GRE tunnels on Linux for example. If you were to use Wireguard or OpenVPN this would require to device at least on custom field on the tunnel and define the UDP port for example. One could think about the ability to connect more than 2 endpoints to a _tunnel_. Allowing this should not fundamentally change the model and I would assume it wouldn't complicate things a lot, thereby offering support for more possible deployment scenarios like PTMP OpenVPN/Tinc setups etc. ### Database changes I guess this would require a new Tunnel type which allows to connect two (or more?) Interfaces of type tunnel. ### External dependencies None.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:31:06 +01:00
adam closed this issue 2025-12-29 19:31:06 +01:00
adam commented 2025-12-29 19:31:08 +01:00
Author
Owner
Copy Link

@ta-raider commented on GitHub (Nov 16, 2021):

Sounds perfect for my IPSec Gateways, to get the Tunnel stuff also into Netbox.
For that case I would want to distinguish between Route-based and Policy-based Tunnels, but that fits also into custom fields :)

@ta-raider commented on GitHub (Nov 16, 2021): Sounds perfect for my IPSec Gateways, to get the Tunnel stuff also into Netbox. For that case I would want to distinguish between Route-based and Policy-based Tunnels, but that fits also into custom fields :)
adam commented 2025-12-29 19:31:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2021):

It's pretty odd that this got ten upvotes within two hours of being opened, most from users I've never seen participate here. 🤔

@jeremystretch commented on GitHub (Nov 16, 2021): It's pretty odd that this got ten upvotes within two hours of being opened, most from users I've never seen participate here. :thinking:
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@herbetom commented on GitHub (Nov 16, 2021):

@jeremystretch It was discussed in a DENOG (German Network Operators Group) chat group. Those Upvotes are indeed from actual distinct Users who are interested in this feature.

@herbetom commented on GitHub (Nov 16, 2021): @jeremystretch It was discussed in a [DENOG](https://www.denog.de/) (German Network Operators Group) chat group. Those Upvotes are indeed from actual distinct Users who are interested in this feature.
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 16, 2021):

I hate to say this, but this isn't as easy to model as adding a field and a new cable model. Something like this needs to be carefully considered. For example, on Cisco ASA's, policy based VPN's don't have a "interface", they are functions of the assigned interface. How do you display a L2 relationship between them? Use a bridge interface? Well that doesn't exactly follow the model.

It is a greate idea, I just think it isn't going to capture all the possible use cases that we need to think about and we can't be as generic as you are suggesting here, The data models generally should mimic real word models, so if you are modelling a P2P policy based VPN on a Cisco ASA you shouldn't need to create a tunnel interface to do it, when that isn't what you are doing on the ASA with a policy based VPN.

I think we could definitely look at giving this a go, based on how much interest there is, it just might need a re-write to capture all the possible use cases and be a little more encompassing.

Potentially related FR's:

@DanSheps commented on GitHub (Nov 16, 2021): I hate to say this, but this isn't as easy to model as adding a field and a new cable model. Something like this needs to be carefully considered. For example, on Cisco ASA's, policy based VPN's don't have a "interface", they are functions of the assigned interface. How do you display a L2 relationship between them? Use a bridge interface? Well that doesn't exactly follow the model. It is a greate idea, I just think it isn't going to capture all the possible use cases that we need to think about and we can't be as generic as you are suggesting here, The data models generally should mimic real word models, so if you are modelling a P2P policy based VPN on a Cisco ASA you shouldn't need to create a tunnel interface to do it, when that isn't what you are doing on the ASA with a policy based VPN. I think we could definitely look at giving this a go, based on how much interest there is, it just might need a re-write to capture all the possible use cases and be a little more encompassing. Potentially related FR's: - #7588 - Virtual Circuit Overlays - #6425 - Routing Features - #5960 - VPN Tunnels - #5845 - VPN Tunnels - #4243 - VXLan - #3738 VXLan - #2800 - VXLan - #1800 - VXLan (+ other overlays) - #1725 - VXLan - #1324 - 802.1ad - #1058 - VXLan - #825 - VXLan - #777 - VLAN service identifier (VXLAN or ISID) - #138 - VPN support
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2021):

I'll echo Dan's concerns somewhat. I think that, on its own, it's certainly a valid FR and worthy of exploration. But my primary concern would be avoiding making any design choices that would exclude (or greatly impede) other potential tunnel/virtual circuit-type features in the future. (For example, consider point-to-multipoint VPNs.)

That said I see a surprising degree of parallel with the wireless link and wireless LAN models; we might leverage lessons learned from those models in the coming months to inform development here.

@jeremystretch commented on GitHub (Nov 16, 2021): I'll echo Dan's concerns somewhat. I think that, on its own, it's certainly a valid FR and worthy of exploration. But my primary concern would be avoiding making any design choices that would exclude (or greatly impede) other potential tunnel/virtual circuit-type features in the future. (For example, consider point-to-multipoint VPNs.) That said I see a surprising degree of parallel with the wireless link and wireless LAN models; we might leverage lessons learned from those models in the coming months to inform development here.
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@ta-raider commented on GitHub (Nov 17, 2021):

So maybe start with a less complicated scenario - like tunnel-generic ? with less dependencies - and see how it fits itself into 3.x ?

I run Netbox within AS28918 and AS49097 for a lot of our stuff in the meantime, but our IPSEC tunnels do not really fit into it and therefore are documented "somewhere else" :)

That generic approach would still help us a lot, as we could allocate these tunnels to Tenants and VRFs already added to our Netbox. With some few custom fields I think we could end up creating these tunnels only with Netbox and Ansible, as most of our IPSEC parameters are the same at the moment

@ta-raider commented on GitHub (Nov 17, 2021): So maybe start with a less complicated scenario - like tunnel-generic ? with less dependencies - and see how it fits itself into 3.x ? I run Netbox within AS28918 and AS49097 for a lot of our stuff in the meantime, but our IPSEC tunnels do not really fit into it and therefore are documented "somewhere else" :) That generic approach would still help us a lot, as we could allocate these tunnels to Tenants and VRFs already added to our Netbox. With some few custom fields I think we could end up creating these tunnels only with Netbox and Ansible, as most of our IPSEC parameters are the same at the moment
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 17, 2021):

IMO, I think it would make sense to focus on the more requested scenario, vxlan and then branch out.

@DanSheps commented on GitHub (Nov 17, 2021): IMO, I think it would make sense to focus on the more requested scenario, vxlan and then branch out.
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 18, 2021):

So maybe start with a less complicated scenario - like tunnel-generic ? with less dependencies - and see how it fits itself into 3.x ?

Per my comment above, this is exactly what we want to avoid. We should not be making any changes to the data model without first considering their potential impact on future work. Doing so is likely to create much more work for both developer and users. We should at least have some idea how we might want to tack future implementations that would inform or overlap with this proposal before proceeding.

@jeremystretch commented on GitHub (Nov 18, 2021): > So maybe start with a less complicated scenario - like tunnel-generic ? with less dependencies - and see how it fits itself into 3.x ? Per my comment above, this is exactly what we want to avoid. We should not be making _any_ changes to the data model without first considering their potential impact on future work. Doing so is likely to create much more work for both developer and users. We should at least have some idea how we might want to tack future implementations that would inform or overlap with this proposal before proceeding.
adam commented 2025-12-29 19:31:09 +01:00
Author
Owner
Copy Link

@snowie-swe commented on GitHub (Dec 1, 2021):

support for a generic ipsec would go a long way,

@snowie-swe commented on GitHub (Dec 1, 2021): support for a generic ipsec would go a long way,
adam commented 2025-12-29 19:31:10 +01:00
Author
Owner
Copy Link

@ossark commented on GitHub (Dec 1, 2021):

At least general tunneling to represent relationships between virtual interfaces. That would really cater for most use cases to large degree.

@ossark commented on GitHub (Dec 1, 2021): At least general tunneling to represent relationships between virtual interfaces. That would really cater for most use cases to large degree.
adam commented 2025-12-29 19:31:10 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 31, 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. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 31, 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:31:10 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 2, 2022):

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 (Mar 2, 2022): 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#5668
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?