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

Supporting Policy Based VPN Tunnels (Access Lists + Crypto Maps) #10289

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

Originally created by @Chiniquy on GitHub (Sep 25, 2024).

NetBox version

v4.0.11

Feature type

Data model extension

Proposed functionality

Brought up for discussion in #17385

Route based VPN tunnels are supported in Netbox as of 3.7.0 (see #9816). That proposal was scoped to only include Route based tunnels specifically, as Policy based tunnels requires the addition of what Cisco calls Crypto Maps to enable differentiation of multiple tunnels on the same interface (see #14666).

I propose that support for modeling policy based VPN tunnels is added to Netbox. This necessitates the creation of several new objects and relations in Netbox, including Access Lists and Crypto Maps. I based the rough outline of the Access List objects on cruse1977's netbox-acls plugin.

We use mostly Cisco equipment, so this model is going to be skewed in that direction, please let me know if the model can be made more general, either through changing the names of objects or their metadata/relations to eachother.

Note that I am not a developer, so I don't know the way in which objects and relations are connected in the backend, so my "Database changes" section may be a bit naive. I'm hoping that someone with more development chops can translate it to the proper format if or where it is necessary.

I've included a copy of my draw.io diagram that I've used to map out the different objects and relations during the process. It's a little messy and inconsistent with regards to colors etc., but should still give a decent overview.
Netbox Policy Based VPN PoC-V2.pdf
I believe this is everything one needs to properly model a Policy based VPN tunnel.

Are the contents of this FR sufficient with the database changes section + the drawing? Or should i type up a detailed description of each part of the feature? (it would likely be several pages)

Another question is with regards to splitting the FR into several constituent parts, this could also be done if necessary (one for ACL, one for Crypto maps, etc).

Use case

This feature would allow users to properly model Policy based VPN tunnels in Netbox.
Also, with the addition of Access Lists natively in Netbox, then need for a separate plugin for ACLs would be removed.

Database changes

The following new types of objects would be created in Netbox:
Lines with ** are things I am unsure about, and I welcome more input.

• Crypto Map
	○ Name
	○ Description
	○ Status
	○ Device or VM (many to 1 relation) 
	○ Crypto Map Entries (1 to many relation) 
	○ Tags
• Crypto Map Entry
	○ Name
	○ **Description (necessary or not?)**
	○ Nat Traversal  (bool)
	○ Reverse Route Injection (bool)
	○ Crypto Map (many to 1 relation)
	○ Peer IP **(many to 1 relation?)**
	○ Access List (many to 1 relation)
	○ VPN Tunnel **(1 to 1 relation?)**
	○ Tags
• Access List
	○ Name
	○ Description
	○ Type (Extended or Standard)
	○ Default Action (Allow or Deny)
	○ Crypto Map Entry **(many to 1 relation?)**
	○ EITHER - Standard Rules (1 to many relation)
	○ OR - Extended Rules (1 to many relation)
	○ Assigned Host (VM or Device, many to 1 relation)
	○ Interface Assignments (1 to many relation)
		• You should be able to see all related interfaces on the "Access List" object page
	○ Tags
• Interface Assigment (for Access Lists)
	○ Direction (Ingress or Egress)
	○ Access List (many to 1 relation)
	○ Assigned Interface (1 to 1 relation)
• Standard Rule
	○ Name
	○ Index (int)
	○ Action (Permit or Deny)
	○ Remark (string)
	○ CHOOSE ONE:
		• Source IP (many to 1 relation)
		• Source Prefix (many to 1 relation)
		• Source Text (string, for cases not covered by prefixes)
	○ Access List (many to 1 relation)
	○ Tags
• Extended Rule
	○ Name
	○ Index (int)
	○ Protocol **(IP, TCP, UDP?)**
	○ Action (permit or deny)
	○ Remark (string)
	○ CHOOSE ONE:
		• Source Service Object Group (many to 1 relation)
		• Source Ports: (ports in correct format)
	○ CHOOSE ONE:
		• Destination Service Object Group (many to 1 relation)
		• Destination Ports: (ports in correct format)
	○ CHOOSE ONE:
		• Source IP (many to 1 relation)
		• Source Prefix (many to 1 relation)
		• Source Network Object Group (many to 1 relation)
		• Source Text (string, for cases not covered by prefixes)
	○ CHOOSE ONE:
		• Destination IP (many to 1 relation)
		• Destination Prefix (many to 1 relation)
		• Destination Network Object Group (many to 1 relation)
		• Destination Text (string, for cases not covered by prefixes)
	○ Access List (many to 1 relation)
	○ Tags
• Network Object Group
	○ Name
	○ Description
	○ Device/VM (many to 1 relation)
	○ IP Addresses (must be IPv4) (many to many relation)
	○ IP Ranges (many to many relation)
	○ Prefixes (many to many relation)
	○ Network Object Group **(many to many relation?)**
	○ Extended Rules (1 to many relation)
	○ Subnet text (string, for cases not covered)
	○ Tags
• Service Object Group
	○ Name
	○ Description
	○ Device/VM (many to 1 relation)
	○ Service Object Group (many to many relation?)
	○ Extended Rules (1 to many relation)
	○ Services (many to many relation)
		• This is the existing Service object in Netbox

Changes to existing objects in Netbox:


• Service
	○ ADD Service Object Group (many to many relation)
• VPN Tunnel
	**○ ADD Type (Policy based or Route based)**
	○ ADD Crypto Map Entry **(1 to 1 relation?)**
• Device
	○ ADD Access Lists (1 to many relation)
	○ ADD Network Object Groups (1 to many relation)
	○ ADD Service Object Groups (1 to many relation)
	○ ADD Crypto Maps (1 to many relation)
• VM
	○ ADD Access Lists (1 to many relation)
	○ ADD Network Object Groups (1 to many relation)
	○ ADD Service Object Groups (1 to many relation)
	○ ADD Crypto Maps (1 to many relation)
• Interface
	○ ADD Crypto Map **(many to 1 relation?)**
	○ CHANGE Tunnel to Tunnels (1 to many relation instead of 1 to 1 relation)
		• Core to Policy Based Tunnels
	○ ADD Interface Assignment (1 to many relation)
		**• ADD view for Access Lists through Interface Assignments?**

External dependencies

Not sure about this one.

Originally created by @Chiniquy on GitHub (Sep 25, 2024). ### NetBox version v4.0.11 ### Feature type Data model extension ### Proposed functionality Brought up for discussion in #17385 Route based VPN tunnels are supported in Netbox as of 3.7.0 (see #9816). That proposal was scoped to only include Route based tunnels specifically, as Policy based tunnels requires the addition of what Cisco calls Crypto Maps to enable differentiation of multiple tunnels on the same interface (see #14666). I propose that support for modeling policy based VPN tunnels is added to Netbox. This necessitates the creation of several new objects and relations in Netbox, including Access Lists and Crypto Maps. I based the rough outline of the Access List objects on cruse1977's [netbox-acls](https://github.com/netbox-community/netbox-acls) plugin. We use mostly Cisco equipment, so this model is going to be skewed in that direction, please let me know if the model can be made more general, either through changing the names of objects or their metadata/relations to eachother. Note that I am not a developer, so I don't know the way in which objects and relations are connected in the backend, so my "Database changes" section may be a bit naive. I'm hoping that someone with more development chops can translate it to the proper format if or where it is necessary. I've included a copy of my draw.io diagram that I've used to map out the different objects and relations during the process. It's a little messy and inconsistent with regards to colors etc., but should still give a decent overview. [Netbox Policy Based VPN PoC-V2.pdf](https://github.com/user-attachments/files/16895406/Netbox.Policy.Based.VPN.PoC-V2.pdf) I believe this is everything one needs to properly model a Policy based VPN tunnel. Are the contents of this FR sufficient with the database changes section + the drawing? Or should i type up a detailed description of each part of the feature? (it would likely be several pages) Another question is with regards to splitting the FR into several constituent parts, this could also be done if necessary (one for ACL, one for Crypto maps, etc). ### Use case This feature would allow users to properly model Policy based VPN tunnels in Netbox. Also, with the addition of Access Lists natively in Netbox, then need for a separate plugin for ACLs would be removed. ### Database changes The following new types of objects would be created in Netbox: Lines with ** are things I am unsure about, and I welcome more input. ``` • Crypto Map ○ Name ○ Description ○ Status ○ Device or VM (many to 1 relation) ○ Crypto Map Entries (1 to many relation) ○ Tags • Crypto Map Entry ○ Name ○ **Description (necessary or not?)** ○ Nat Traversal (bool) ○ Reverse Route Injection (bool) ○ Crypto Map (many to 1 relation) ○ Peer IP **(many to 1 relation?)** ○ Access List (many to 1 relation) ○ VPN Tunnel **(1 to 1 relation?)** ○ Tags • Access List ○ Name ○ Description ○ Type (Extended or Standard) ○ Default Action (Allow or Deny) ○ Crypto Map Entry **(many to 1 relation?)** ○ EITHER - Standard Rules (1 to many relation) ○ OR - Extended Rules (1 to many relation) ○ Assigned Host (VM or Device, many to 1 relation) ○ Interface Assignments (1 to many relation) • You should be able to see all related interfaces on the "Access List" object page ○ Tags • Interface Assigment (for Access Lists) ○ Direction (Ingress or Egress) ○ Access List (many to 1 relation) ○ Assigned Interface (1 to 1 relation) • Standard Rule ○ Name ○ Index (int) ○ Action (Permit or Deny) ○ Remark (string) ○ CHOOSE ONE: • Source IP (many to 1 relation) • Source Prefix (many to 1 relation) • Source Text (string, for cases not covered by prefixes) ○ Access List (many to 1 relation) ○ Tags • Extended Rule ○ Name ○ Index (int) ○ Protocol **(IP, TCP, UDP?)** ○ Action (permit or deny) ○ Remark (string) ○ CHOOSE ONE: • Source Service Object Group (many to 1 relation) • Source Ports: (ports in correct format) ○ CHOOSE ONE: • Destination Service Object Group (many to 1 relation) • Destination Ports: (ports in correct format) ○ CHOOSE ONE: • Source IP (many to 1 relation) • Source Prefix (many to 1 relation) • Source Network Object Group (many to 1 relation) • Source Text (string, for cases not covered by prefixes) ○ CHOOSE ONE: • Destination IP (many to 1 relation) • Destination Prefix (many to 1 relation) • Destination Network Object Group (many to 1 relation) • Destination Text (string, for cases not covered by prefixes) ○ Access List (many to 1 relation) ○ Tags • Network Object Group ○ Name ○ Description ○ Device/VM (many to 1 relation) ○ IP Addresses (must be IPv4) (many to many relation) ○ IP Ranges (many to many relation) ○ Prefixes (many to many relation) ○ Network Object Group **(many to many relation?)** ○ Extended Rules (1 to many relation) ○ Subnet text (string, for cases not covered) ○ Tags • Service Object Group ○ Name ○ Description ○ Device/VM (many to 1 relation) ○ Service Object Group (many to many relation?) ○ Extended Rules (1 to many relation) ○ Services (many to many relation) • This is the existing Service object in Netbox ``` Changes to existing objects in Netbox: ``` • Service ○ ADD Service Object Group (many to many relation) • VPN Tunnel **○ ADD Type (Policy based or Route based)** ○ ADD Crypto Map Entry **(1 to 1 relation?)** • Device ○ ADD Access Lists (1 to many relation) ○ ADD Network Object Groups (1 to many relation) ○ ADD Service Object Groups (1 to many relation) ○ ADD Crypto Maps (1 to many relation) • VM ○ ADD Access Lists (1 to many relation) ○ ADD Network Object Groups (1 to many relation) ○ ADD Service Object Groups (1 to many relation) ○ ADD Crypto Maps (1 to many relation) • Interface ○ ADD Crypto Map **(many to 1 relation?)** ○ CHANGE Tunnel to Tunnels (1 to many relation instead of 1 to 1 relation) • Core to Policy Based Tunnels ○ ADD Interface Assignment (1 to many relation) **• ADD view for Access Lists through Interface Assignments?** ``` ### External dependencies Not sure about this one.
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: high labels 2025-12-29 21:29:29 +01:00
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 needs milestone 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#10289
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?