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

VPN - Allow termination over IP without specifying device #9056

New Issue
Open
opened 2025-12-29 20:44:52 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:44:52 +01:00
Owner
Copy Link

Originally created by @mlazzarotto on GitHub (Jan 8, 2024).

NetBox version

v3.7.0

Feature type

Change to existing functionality

Proposed functionality

I open this issue to ask about allowing VPN termination on an IP address without having to specify a device and its interface.

This is a simple mockup of the UI change.
image

Use case

The typical use case is where the other side of the VPN is terminated on a customer/vendor/contractor's device but the device and interface details are unknown.
Also, in this way, we would not be forced to create dummy devices that would end up staying on Netbox even though they are not actually owned by us.

Database changes

No response

External dependencies

No response

Originally created by @mlazzarotto on GitHub (Jan 8, 2024). ### NetBox version v3.7.0 ### Feature type Change to existing functionality ### Proposed functionality I open this issue to ask about allowing VPN termination on an IP address without having to specify a device and its interface. This is a simple mockup of the UI change. ![image](https://github.com/netbox-community/netbox/assets/8932945/f558357a-be56-40dd-ac1f-d08c80f8b734) ### Use case The typical use case is where the other side of the VPN is terminated on a customer/vendor/contractor's device but the device and interface details are unknown. Also, in this way, we would not be forced to create dummy devices that would end up staying on Netbox even though they are not actually owned by us. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurecomplexity: mediumnetboxstatus: backlog labels 2025-12-29 20:44:52 +01:00
adam commented 2025-12-29 20:44:53 +01:00
Author
Owner
Copy Link

@markkuleinio commented on GitHub (Jan 8, 2024):

This is actually our use case as well: no need to save the remote-side device details, just the termination IP address because that's the remote-side detail we need when provisioning the tunnel on our side.

@markkuleinio commented on GitHub (Jan 8, 2024): This is actually our use case as well: no need to save the remote-side device details, just the termination IP address because that's the remote-side detail we need when provisioning the tunnel on our side.
adam commented 2025-12-29 20:44:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 8, 2024):

This would have been a topic for discussion during the v3.7 beta valuation period last month. Unfortunately, now that v3.7 has been released we are no longer considering major changes to the VPN tunnels implementation.

However, please note that it is perfectly valid to create only one termination on a tunnel; you can use a custom field to record the IP address of the remote end for which complete termination details are unknown.

@jeremystretch commented on GitHub (Jan 8, 2024): This would have been a topic for discussion during the [v3.7 beta valuation period](https://github.com/netbox-community/netbox/discussions/14430) last month. Unfortunately, now that v3.7 has been released we are no longer considering major changes to the VPN tunnels implementation. However, please note that it is perfectly valid to create only one termination on a tunnel; you can use a custom field to record the IP address of the remote end for which complete termination details are unknown.
adam commented 2025-12-29 20:44:54 +01:00
Author
Owner
Copy Link

@markkuleinio commented on GitHub (Jan 8, 2024):

I've been testing with custom fields with VPN tunnels but the challenge with them is that they create (as far as I see it) a one-way relationship, meaning that if I configure a custom field in the VPN tunnel with the IP address object, I cannot trace back where the IP address is used. Also search does not find IP addresses in custom fields. (The same goes with contacts that I thought using in tunnels.)

Using tags could be another option. (Edit: text custom fields instead of objects could possibly work as well in some cases)

@markkuleinio commented on GitHub (Jan 8, 2024): I've been testing with custom fields with VPN tunnels but the challenge with them is that they create (as far as I see it) a one-way relationship, meaning that if I configure a custom field in the VPN tunnel with the IP address object, I cannot trace back where the IP address is used. Also search does not find IP addresses in custom fields. (The same goes with contacts that I thought using in tunnels.) Using tags could be another option. (Edit: text custom fields instead of objects could possibly work as well in some cases)
adam commented 2025-12-29 20:44:54 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Apr 19, 2024):

How about meeting halfway? Changing the termination to nullable might break something or have other consequences. But there's also the concept of circuits for external connections. Why not just add a circuit as a possible endpoint for tunnels?

@alehaa commented on GitHub (Apr 19, 2024): How about meeting halfway? Changing the termination to nullable might break something or have other consequences. But there's also the concept of circuits for external connections. Why not just add a circuit as a possible endpoint for tunnels?
adam commented 2025-12-29 20:44:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 28, 2024):

The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface.

@jeremystretch commented on GitHub (May 28, 2024): The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface.
adam commented 2025-12-29 20:44:55 +01:00
Author
Owner
Copy Link

@antoinekh commented on GitHub (Oct 25, 2024):

We had the same needs and we decide to create a fake device called “dummy_vpn_peer” that host all the interfaces for the tunnel termination of the remote peer

@antoinekh commented on GitHub (Oct 25, 2024): We had the same needs and we decide to create a fake device called “dummy_vpn_peer” that host all the interfaces for the tunnel termination of the remote peer
adam commented 2025-12-29 20:44:55 +01:00
Author
Owner
Copy Link

@mlazzarotto commented on GitHub (Oct 30, 2024):

The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface.

Yes, that's correct. We have more than one hundred site-to-site VPNs, most of them are with external vendors or customers which we don't manage the firewalls of. Therefore I think that cluttering our Netbox with hundreds of "dummy_customer/vendor_peer" devices would be counterproductive and would increase the management difficulty of Netbox, and also slow down the searches.

@mlazzarotto commented on GitHub (Oct 30, 2024): > The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface. Yes, that's correct. We have more than one hundred site-to-site VPNs, most of them are with external vendors or customers which we don't manage the firewalls of. Therefore I think that cluttering our Netbox with hundreds of "dummy_customer/vendor_peer" devices would be counterproductive and would increase the management difficulty of Netbox, and also slow down the searches.
adam commented 2025-12-29 20:44:55 +01:00
Author
Owner
Copy Link

@antoinekh commented on GitHub (Oct 30, 2024):

The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface.

Yes, that's correct. We have more than one hundred site-to-site VPNs, most of them are with external vendors or customers which we don't manage the firewalls of. Therefore I think that cluttering our Netbox with hundreds of "dummy_customer/vendor_peer" devices would be counterproductive and would increase the management difficulty of Netbox, and also slow down the searches.

Not hundreds, just one with a lot of interfaces. Of course this is not perfect but that’s for us the best solution now.
And with that we can store the internal tunnel IP of the partner

@antoinekh commented on GitHub (Oct 30, 2024): > > The proposal here (I believe) is to allow creating a tunnel termination with an outside IP address defined, but no termination interface. > > Yes, that's correct. We have more than one hundred site-to-site VPNs, most of them are with external vendors or customers which we don't manage the firewalls of. Therefore I think that cluttering our Netbox with hundreds of "dummy_customer/vendor_peer" devices would be counterproductive and would increase the management difficulty of Netbox, and also slow down the searches. Not hundreds, just one with a lot of interfaces. Of course this is not perfect but that’s for us the best solution now. And with that we can store the internal tunnel IP of the partner
adam commented 2025-12-29 20:44:55 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 23, 2025):

I just came across this situation as well and was thinking about potential solutions. Since the termination field on the TunnelTermination model is already a GFK, I like the idea of just extending it to support more models. A suggestion was already make for Circuit, but I'm thinking ProviderNetwork and maybe Tenant would also be good candidates. In our environment, that additional context would be a lot more useful than just a null value. For example, being able to go to a ProviderNetwork instance and see all the tunnels we have going to them would be super helpful.

@sleepinggenius2 commented on GitHub (Jul 23, 2025): I just came across this situation as well and was thinking about potential solutions. Since the `termination` field on the `TunnelTermination` model is already a GFK, I like the idea of just extending it to support more models. A suggestion was already make for `Circuit`, but I'm thinking `ProviderNetwork` and maybe `Tenant` would also be good candidates. In our environment, that additional context would be a lot more useful than just a null value. For example, being able to go to a `ProviderNetwork` instance and see all the tunnels we have going to them would be super helpful.
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: medium 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#9056
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?