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

[Chiniquy]

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.