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

[Chiniquy]

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.

I've spent some time for the past few weeks thinking about what changes would need to be made to Netbox to enable support for Policy Based VPN tunnels, and have come up with the following suggestion. I based the rough outline of the Access List objects on cruse1977's netbox-acls plugin.

I am not a developer, so I'm sure this suggestion will need to be modified extensively to fit within the Netbox model, this is the main reason I'm putting this in the Discussion section before submitting a Feature Request.

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.

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

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?**

Questions:
Should this be modeled in Netbox Core at all? Or just be added as a plugin?
I would argue that since the decision was made to include Route Based VPN Tunnels, then supporting Policy Based VPN Tunnels is a logical next step. Obviously Policy based tunnels would require a substantial amount of effort in terms of expending the data model in Netbox to support it, but each of the added objects (ACLs, Crypto Maps, NOG/SOG) are a natural part of the configuration of the network devices that are already modeled in Netbox.

Are there any obvious flaws or omissions with this suggested model?

Are the existing IPSec/IKE objects for VPN tunnels sufficient for modeling Policy Based Tunnels as well? Or will they need changing in some way?

Do we create full relations between objects? Or just 1 way relations?
Being able to traverse both directions of the connection sounds better to me, but I'm sure there are considerations that need to be taken into account that I can't think of.

Can i use the same Network Object Group or Service Object Group across multiple devices/VMs?
No. Although it is likely common that duplicate NOG/SOG objects exist across devices in a network, and contain the exact same lines of configuration, these objects do not (as far as I know) exist outside of the specific device that they are configured on. There may be an intention from a business standpoint to enforce some NOG's to be the same across devices, but they are still strictly speaking separate objects on each device.