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

More tunnel options #9699

New Issue
Open
opened 2025-12-29 21:21:11 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:21:11 +01:00
Owner
Copy Link

Originally created by @TeroPihlaja on GitHub (May 17, 2024).

NetBox version

v4.0.2

Feature type

Data model extension

Proposed functionality

Add support for the following VPN tunnel types:

  • WireGuard
  • OpenVPN

Implications analysis (lifted up from comment below)
Wireguard

  • Endpoints have device/interface/IP and optional port number. Although mobile endpoint IP might not be known.
  • There is only one authentication, private key. It could be stored in Netbox with corresponding public key part. (Maybe Netbox could even calculated pubkey from privkey). At least public key must be stored.
  • There can be multiple connections to each endpoint. Different connections are identified by their public keys
  • Both sides can have list of subnets which are allowed & routed to them (AllowedIPs config)

OpenVPN
OpenVPN Static key mode is simple:

  • Point-to-point. Somewhat similar to current IPsec connections and PSK.
  • At least one side has known IP + port
  • Ciphers + compression can be configured but not much more.
  • Routing is handled outside OpenVPN. There can be scripts that are run after connection

OpenVPN TLS mode is complicated,

  • Point-to-multipoint.
  • SSL certificates are used for server and client authentication so there needs to be a CA.
    • I think this would require "certificate" concept in Netbox... which could then contain normal https certificates as well and handle their expiration checks etc.
  • Server has IP address pool from where it assigns IPs to clients like DHCP server
  • Server can push DNS/NTP configs to clients
  • Server can push routes to clients (i.e. routes added to client machines)
  • Server can have client-specific configs (e.g. IP address)
  • Server can route subnets towards specific client.

In all cases single device can have multiple Wireguard and OpenVPN servers in different ports with different keys and different set of connected endpoints.

Use case

Currently only IPsec tunnels are supported by Netbox.

We have also OpenVPN and WireGuard tunnels in use.

Database changes

NetBox needs a bunch of changes:

  • IKE/IPsec details are naturally IPsec specific and could be kept as-is.
  • Tunnels can work for other types but needs new "type" field or then "encapsulation" could be reused.
  • First termination would need port number
  • Second termination doesn't work with point-to-multipoint connections since there can be many of them. Something different needs to be thought here.
  • OpenVPN needs more configs so maybe "OpenVPN profile" entity would be good
  • Wireguard needs the keys but having separate entity feels a bit excessive since only priv/pubkey is needed. Although it should not work differently than IPsec/OpenVPN.
    • Due to way wireguard uses public keys as identifiers there needs to be way from Wireguard key entity to know which device owns it.
  • List of routes behind each endpoint is important. I think this is also missing from current IPsec implementation

External dependencies

No response

Originally created by @TeroPihlaja on GitHub (May 17, 2024). ### NetBox version v4.0.2 ### Feature type Data model extension ### Proposed functionality Add support for the following VPN tunnel types: - WireGuard - OpenVPN **Implications analysis** (lifted up from comment below) **Wireguard** - Endpoints have device/interface/IP and optional port number. Although mobile endpoint IP might not be known. - There is only one authentication, private key. It could be stored in Netbox with corresponding public key part. (Maybe Netbox could even calculated pubkey from privkey). At least public key must be stored. - There can be multiple connections to each endpoint. Different connections are identified by their public keys - Both sides can have list of subnets which are allowed & routed to them (AllowedIPs config) **OpenVPN** OpenVPN Static key mode is simple: - Point-to-point. Somewhat similar to current IPsec connections and PSK. - At least one side has known IP + port - Ciphers + compression can be configured but not much more. - Routing is handled outside OpenVPN. There can be scripts that are run after connection OpenVPN TLS mode is complicated, - Point-to-multipoint. - SSL certificates are used for server and client authentication so there needs to be a CA. - I think this would require "certificate" concept in Netbox... which could then contain normal https certificates as well and handle their expiration checks etc. - Server has IP address pool from where it assigns IPs to clients like DHCP server - Server can push DNS/NTP configs to clients - Server can push routes to clients (i.e. routes added to client machines) - Server can have client-specific configs (e.g. IP address) - Server can route subnets towards specific client. In all cases single device can have multiple Wireguard and OpenVPN servers in different ports with different keys and different set of connected endpoints. ### Use case Currently only IPsec tunnels are supported by Netbox. We have also OpenVPN and WireGuard tunnels in use. ### Database changes NetBox needs a bunch of changes: - IKE/IPsec details are naturally IPsec specific and could be kept as-is. - Tunnels can work for other types but needs new "type" field or then "encapsulation" could be reused. - First termination would need port number - Second termination doesn't work with point-to-multipoint connections since there can be many of them. Something different needs to be thought here. - OpenVPN needs more configs so maybe "OpenVPN profile" entity would be good - Wireguard needs the keys but having separate entity feels a bit excessive since only priv/pubkey is needed. Although it should not work differently than IPsec/OpenVPN. - Due to way wireguard uses public keys as identifiers there needs to be way from Wireguard key entity to know which device owns it. - List of routes behind each endpoint is important. I think this is also missing from current IPsec implementation ### External dependencies _No response_
adam added the type: featurenetboxstatus: backlogcomplexity: high labels 2025-12-29 21:21:11 +01:00
adam commented 2025-12-29 21:21:12 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (May 17, 2024):

Thank you for your interest in improving NetBox. OpenVPN and WireGuard are indisputably popular tunnel technologies, and NetBox would better reflect reality if it included support for them.

Before we could proceed, though, we would need more detail than you've provided here. Please explore the ways that the requested technologies differ from IPSEC, and call out any resulting challenges that a developer implementing this feature would need to take into account. It doesn't need to be a code-level analysis; we just want to encourage you to think through the implications of what you're requesting. The maintainer team is currently quite small and so we generally must prioritize FRs that offer the biggest impact for the smallest development effort.

Please revise your issue body accordingly, and we will give it due consideration.

@jeffgdotorg commented on GitHub (May 17, 2024): Thank you for your interest in improving NetBox. OpenVPN and WireGuard are indisputably popular tunnel technologies, and NetBox would better reflect reality if it included support for them. Before we could proceed, though, we would need more detail than you've provided here. Please explore the ways that the requested technologies differ from IPSEC, and call out any resulting challenges that a developer implementing this feature would need to take into account. It doesn't need to be a code-level analysis; we just want to encourage you to think through the implications of what you're requesting. The maintainer team is currently quite small and so we generally must prioritize FRs that offer the biggest impact for the smallest development effort. Please revise your issue body accordingly, and we will give it due consideration.
adam commented 2025-12-29 21:21:12 +01:00
Author
Owner
Copy Link

@Aketzu commented on GitHub (May 23, 2024):

Current Netbox seems to be modeled pretty much around IPsec ideology but OpenVPN and Wireguard semantics don't match well with that.

Wireguard,

  • Endpoints have device/interface/IP and optional port number. Although mobile endpoint IP might not be known.
  • There is only one authentication, private key. It could be stored in Netbox with corresponding public key part. (Maybe Netbox could even calculated pubkey from privkey). At least public key must be stored.
  • There can be multiple connections to each endpoint. Different connections are identified by their public keys
  • Both sides can have list of subnets which are allowed & routed to them (AllowedIPs config)

OpenVPN Static key mode is simple,

  • Point-to-point. Somewhat similar to current IPsec connections and PSK.
  • At least one side has known IP + port
  • Ciphers + compression can be configured but not much more.
  • Routing is handled outside OpenVPN. There can be scripts that are run after connection

OpenVPN TLS mode is complicated,

  • Point-to-multipoint.
  • SSL certificates are used for server and client authentication so there needs to be a CA.
    • I think this would require "certificate" concept in Netbox... which could then contain normal https certificates as well and handle their expiration checks etc.
  • Server has IP address pool from where it assigns IPs to clients like DHCP server
  • Server can push DNS/NTP configs to clients
  • Server can push routes to clients (i.e. routes added to client machines)
  • Server can have client-specific configs (e.g. IP address)
  • Server can route subnets towards specific client.

In all cases single device can have multiple Wireguard and OpenVPN servers in different ports with different keys and different set of connected endpoints.

Netbox needs bunch of changes:

  • IKE/IPsec details are naturally IPsec specific and could be kept as-is.
  • Tunnels can work for other types but needs new "type" field or then "encapsulation" could be reused.
  • First termination would need port number
  • Second termination doesn't work with point-to-multipoint connections since there can be many of them. Something different needs to be thought here.
  • OpenVPN needs more configs so maybe "OpenVPN profile" entity would be good
  • Wireguard needs the keys but having separate entity feels a bit excessive since only priv/pubkey is needed. Although it should not work differently than IPsec/OpenVPN.
    • Due to way wireguard uses public keys as identifiers there needs to be way from Wireguard key entity to know which device owns it.
  • List of routes behind each endpoint is important. I think this is also missing from current IPsec implementation
@Aketzu commented on GitHub (May 23, 2024): Current Netbox seems to be modeled pretty much around IPsec ideology but OpenVPN and Wireguard semantics don't match well with that. Wireguard, - Endpoints have device/interface/IP and optional port number. Although mobile endpoint IP might not be known. - There is only one authentication, private key. It could be stored in Netbox with corresponding public key part. (Maybe Netbox could even calculated pubkey from privkey). At least public key must be stored. - There can be multiple connections to each endpoint. Different connections are identified by their public keys - Both sides can have list of subnets which are allowed & routed to them (AllowedIPs config) OpenVPN Static key mode is simple, - Point-to-point. Somewhat similar to current IPsec connections and PSK. - At least one side has known IP + port - Ciphers + compression can be configured but not much more. - Routing is handled outside OpenVPN. There can be scripts that are run after connection OpenVPN TLS mode is complicated, - Point-to-multipoint. - SSL certificates are used for server and client authentication so there needs to be a CA. - I think this would require "certificate" concept in Netbox... which could then contain normal https certificates as well and handle their expiration checks etc. - Server has IP address pool from where it assigns IPs to clients like DHCP server - Server can push DNS/NTP configs to clients - Server can push routes to clients (i.e. routes added to client machines) - Server can have client-specific configs (e.g. IP address) - Server can route subnets towards specific client. In all cases single device can have multiple Wireguard and OpenVPN servers in different ports with different keys and different set of connected endpoints. Netbox needs bunch of changes: - IKE/IPsec details are naturally IPsec specific and could be kept as-is. - Tunnels can work for other types but needs new "type" field or then "encapsulation" could be reused. - First termination would need port number - Second termination doesn't work with point-to-multipoint connections since there can be many of them. Something different needs to be thought here. - OpenVPN needs more configs so maybe "OpenVPN profile" entity would be good - Wireguard needs the keys but having separate entity feels a bit excessive since only priv/pubkey is needed. Although it should not work differently than IPsec/OpenVPN. - Due to way wireguard uses public keys as identifiers there needs to be way from Wireguard key entity to know which device owns it. - List of routes behind each endpoint is important. I think this is also missing from current IPsec implementation
adam commented 2025-12-29 21:21:12 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 31, 2024):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (May 31, 2024): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:21:13 +01:00
Author
Owner
Copy Link

@TeroPihlaja commented on GitHub (Jun 6, 2024):

@jeffgdotorg Can you check the above comment?

@TeroPihlaja commented on GitHub (Jun 6, 2024): @jeffgdotorg Can you check the above comment?
adam commented 2025-12-29 21:21:13 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 24, 2024):

@TeroPihlaja thanks for the update and apologies for the silence. I've added this issue to the agenda for a team standup this week.

@jeffgdotorg commented on GitHub (Jun 24, 2024): @TeroPihlaja thanks for the update and apologies for the silence. I've added this issue to the agenda for a team standup this week.
adam commented 2025-12-29 21:21:13 +01:00
Author
Owner
Copy Link

@chaeynz commented on GitHub (Jul 11, 2024):

links to this https://github.com/netbox-community/netbox/discussions/14683

@chaeynz commented on GitHub (Jul 11, 2024): links to this https://github.com/netbox-community/netbox/discussions/14683
adam commented 2025-12-29 21:21:13 +01:00
Author
Owner
Copy Link

@mulmat commented on GitHub (Oct 22, 2024):

I've spent some time thinking how to model Wireguard vpns in Netbox: https://github.com/netbox-community/netbox/compare/develop...351ab1ecb07e918ed032e8ebda98735b6614cf6d
I wish to get some feedback if this modelling looks like something that could be accepted.

@mulmat commented on GitHub (Oct 22, 2024): I've spent some time thinking how to model Wireguard vpns in Netbox: https://github.com/netbox-community/netbox/compare/develop...351ab1ecb07e918ed032e8ebda98735b6614cf6d I wish to get some feedback if this modelling looks like something that could be accepted.
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 complexity: high netbox status: backlog 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#9699
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?