Support for VPN Tunnels

[mlazzarotto]

NetBox version

3.2.6

Feature type

New functionality

Proposed functionality

I suggest to add support for site-to-site VPN tunnels.
In this way I can have a clear view of all of my tunnels

Use case

I have an Excel with 100+ site-to-site vpn tunnels.
This would help to store all the details about VPN.

Database changes

This is a list of fields that I'd like to have

• Name
• status (Active, Offline, Backup, Planned, Deprecated)
• type (route based VTI, policy based)
• nat traversal enabled (true, false)
• interface of the device (linked to device interface)
• local peer ip (one or more, linked to ip in IPAM)
• remote peer ip (one or more, linked to ip in IPAM)
• list of local subnets (linked to Subnets in IPAM)
• list of remote subnets (linked to Subnets in IPAM)
• protocols used (IKEv1/IKEv2 and IPsec)
• date created
• contact field
• description field

External dependencies

I looked at this https://pypi.org/project/netbox-tunnels-plugin/, I don't know if it can be implemented or not

[mlazzarotto]

Please don't close and mark as duplicate. It is indeed a duplicate of #5845 but this is more detailed.

[DanSheps]

This may be something that is better off as a plugin, at least until it gets a chance to be properly implemented in core.

Given that the plugin you linked is 2 years old, I doubt it would work with the current iteration of netbox.

[ryanmerolle]

Feels like the perfect candidate for a plugin. If it was well built, it could even make it into the core at some point.

[ryanmerolle]

The maintainer @jdrew82 of the example package abandoned that plugin for work on a Nautbot plugin of the same approach.

The approach looks solid if it made it to core, but could get some refinements.

@mlazzarotto missed the MTU. The maintainer specifically set:

• Tunnel MTU
• CLNS MTU (I did not realize you could set MTU for other types of traffic, but this makes sense, I'd probably take a more simple approach and just allow for MTU to be set the same as any other interface)

I feel like the remote details would just be derived from modeling the remote end in NetBox. I recognize this is not always the case with edge devices, but this issue is not specific to tunnels, and it may be a can of worms addressing that with this feature.

[jeremystretch]

@mlazzarotto missed the MTU

MTU is an attribute of the virtual interface on either end (which we already track), rather than the tunnel itself.

[ryanmerolle]

Yes I agree I was just looking at the model he was drawing reference from.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[pobk]

Could this be done using Circuits if NetBox adds config-contexts to circuits and terminations? I'm not sure what would be best here; making a virtual termination possible under circuit terminations and allowing encryption domain specifications to be stored under the connection info, or under the circuit?

IPSec is by it's very nature point-to-point so stands to reason that a circuit might be a more appropriate model for describing point-to-point tunnels? The L2VPN stuff really model better to MPLS/VPLS/Point-to-multipoint stuff.

My reasoning is NetBox already supports the linkages for local/remote networks, VRFs, MTUs, etc. The only thing that's missing on the circuits is to parameterise the encryption domain specific info.

[saifvs]

IPsec is commonly used for branch connectivity due to its cost-effectiveness. At one organization I worked with, there were over 50 tunnels, making it difficult to document them all in Excel. It would be great if the IPsec feature could be added to netbox. Currently, to connect sites, I use the interface type 'other,' but if I try to select 'virtual,' an error message appears stating that virtual interfaces cannot have a cable attached.

The reason for including IPsec details in netbox is not only for documentation purposes but also to display it in the topology view plugin. Currently, I am constructing my WAN topology using 'other' as the cable type in netbox cable management. (see the connection between firewalls)

[misch42]

Hi,

I would would support this feature. An ipsec VPN is of type virtual, but has a heck more parameters.

• contacts
• Identification (IP, hostname, ...)
• authentication (PSK, cert, DNSKEY)
• authorization (authorized networks to connect)
• ciphers used
• timeing
• Options like NAT, DPD, ...

I really would like to see this feature, perhaps realized as a plugin.

[mlazzarotto]

I'm terribly sorry for bumping this conversation.
Please don't get me wrong, I understand this project is being carried on by non-paid developers, but I was wondering for which reason, after 1 year since the opening of the issue, this hasn't been added to any milestone.

[p-rintz]

A plugin that works with the current version of Netbox is the following:
https://github.com/robertlynch3/netbox-tunnels2

Not sure if it fully does what you need, yet.
It does support custom fields, with which you can add a lot of information that you requested above.

[mlazzarotto]

A plugin that works with the current version of Netbox is the following: https://github.com/robertlynch3/netbox-tunnels2

Not sure if it fully does what you need, yet. It does support custom fields, with which you can add a lot of information that you requested above.

Thanks, I wasn't aware the old 'netbox-tunnels' was forked. I'll give it a try

[shepherdjay]

https://github.com/robertlynch3/netbox-tunnels2

Only downside of using plugins is that like @saifvs stated a big component of tunnels being supported as a formal model in netbox is that topology plugins could rely on it to show the appropriate edges

[ryanmerolle]

@mlazzarotto

Please don't get me wrong, I understand this project is being carried on by non-paid developers, but I was wondering for which reason, after 1 year since the opening of the issue, this hasn't been added to any milestone.

I think you answered your own question. NetBox maintainers volunteer their time or their employers volunteer the developers’ time. As such, when they contribute new features, they are incentivized to contribute where the return on investment benefits them. Which is 100% fair and frankly highly successful for many similar/popular open-source projects.

You are welcome to flesh out the feature specifics and work required e-bike working on a PR. The maintainer group is very good at reviewing and providing feedback. Issues with PRs that look clean, have some basic tests, don’t break any existing features, and look simple enough to maintain longterm would get mapped to a near term milestone.

Plugins are also a good way to flesh out features before proposing them to be merged into core NetBox.

[mlazzarotto]

My main fear about using a third-party plugin is that there is no guarantee that it will be supported when Netbox makes any breaking changes, thus forcing me to stay with an older version of Netbox to use the external plugin.

[st-nip]

This seems like a good idea, and I'd also rather have it included as base functionality rather than having to use a plugin.

[misch42]

Hi,

I think this would be a good idea for a plugin, not as a core function. Not everybody needs this functionality. So a plugin would be the correct place.

[jeremystretch]

I think it makes sense to implement this natively in NetBox. While not everyone needs it, the same can be said for most models in NetBox. Tunnels are a fundamental part of network configuration in general, so we should strive to support modeling them.

Now, where in NetBox it would go is another matter. We recently added L2VPN modeling under the ipam app, which still doesn't feel quite right IMO. Maybe it would make sense to introduce a new vpn app for tunnels, although I think that would obligate us to move L2VPN there as well.

I'll also point out that the proposal above is limited to simple, point-to-point tunnels: It does not broach the topics of encryption profiles or multi-point topologies (e.g. DMVPN). While we wouldn't necessarily need to implement all of these simultaneously, we should at least have a plan for their eventual inclusion (or not) when designing the data model.

[misch42]

Hi,

I did model VPN tunnels as a Circuit. Circuit type "IPsec VPN".

I added the IKE/IPsec as custom fields (encryption, integrity, DH, IKE version, DPD, ...).
A and Z end as IP address objects. Also authentication, traffic selectors and identity as custom fields of the termination.

This works for me and I can request the data via the API. I have an ansible playbook to create and deploy the config file for strongswan.

Of course this does not work for DMVPN, but I don't know how to solve this problem.

Michael.

[jaylik]

Also support for connecting tunnels to virtual machine interfaces (used with virtual routers / firewall) would be great.

[jeremystretch]

I believe I've identified a workable model to support general VPN tunnel topologies, so I'm tagging this as a v3.7 initiative.

[jsenecal]

I was looking at your branch @jeremystretch and it makes me wonder if it makes sense to include IPSec parameters as first class model attributes to the Tunnel Model as we're supporting GRE and IP-IP as well (might as well add Wireguard while we're at it?)
Perhaps this is a case of Multi-table Inheritance to document the many types of tunnels and their attributes.

Anyways, just my 0.02$ as I noticed a thing or two.

[BarbarossaTM]

I had the same thoughts as @jsenecal. The idea looks neat, I also think though we might want to decouple the IPSec details a bit, assuming the intention is to support more VPNs in the future, with Wireguard being the first which comes to mind.

I saw there is a foreign key relation to the outside IP - is that a required field? From looking at the code I have the impression it is, but am not sure :)

[jeremystretch]

I guess I'm a bit confused by the comments above. The IPSec attrbiutes aren't first-class attributes; they're defined in a separate IPSecProfile model which may optionally be assigned to a Tunnel as appropriate. Nothing about this arrangement precludes us from accurately representing non-IPSec tunnels.

[DanSheps]

Looking at everything, I think the model is pretty good for the most part. A couple of things I might change:

• Add IKE parameters somewhere
  • Authentication type (Certificate, Manual PSK, Auto PSK)
  • IKEv2: Integrity (This could be "Authentication"), PRF
• Add lifetime size (bytes) in addition to duration, while not common both can be set. Some systems enforce it (Cisco Firepower)
• Add missing encryption types:
  • AES-GCM-128
  • AES-GCM-192
  • AES-GCM-256
  • NULL
  • DES
• Add missing hash types:
  • SHA256
  • SHA384
  • SHA512
  • NULL
• Add missing DH groups
  • 14
  • 15
  • 16
  • 19
  • 20
  • 21
  • 24
  • 31
• Remove non-existant DH group
  • 7 (Checked the RFC, Cisco, Juniper, Watchguard, Sonicwall), this group does not exist

Technically, DH groups 3,4,17,18 exist but I haven't seen them on any platform

A later feature or perhaps something to consider for now: Define PSK per peer per tunnel termination. Not sure how feasible this is but it is possible with most variants.

[jeremystretch]

Authentication type (Certificate, Manual PSK, Auto PSK)

We should come up with a clearer name for this to avoid confusion with the IKE authentication mechanism (e.g. HMAC). It also probably needs further discussion around what additional fields may be required for each type.

IKEv2: Integrity (This could be "Authentication"), PRF

This looks like it may need a separate field? (IANA reference)

Add lifetime size (bytes) in addition to duration

I've added a second lifetime field for phase 2 to measure throughput in kilobytes. I don't think this would ever be needed for phase 1.

Add missing encryption types

I've added some of these, but there are a lot more we might want to consider. Let's defer that conversation until after we've locked in the fundamental models.

Add missing hash types

Same as above.

Add missing DH groups

I've fleshed out the choices with all DH groups registered with IANA.

Remove non-existant DH group

I don't recall where I came across this, but it's gone.

I'm hoping to have a draft PR in later today; let's continue the discussion there so we can more easily reference the code.

[misch42]

netbox should use the terms of the RFC 5996. i.e. section 3.8 "Authentication Method".
Section 3.3.2: "Encryption Algorithm", "Integrity Algorithm", "Diffie-Hellman-group". ...

[jeremystretch]

@misch42 while I generally agree, we also need to be cognizant of the vernacular in common use. For instance, referring to the HMAC flavor as the "integrity" protocol can be confusing if most vendors refer to it as "authentication." (And I'm not arguing that this is the case, just providing an example.)

Ultimately, the terminology is very easy to manipulate up to and during the beta evaluation. For now, let's focus on the fundamental models.

[DanSheps]

@misch42 while I generally agree, we also need to be cognizant of the vernacular in common use. For instance, referring to the HMAC flavor as the "integrity" protocol can be confusing if most vendors refer to it as "authentication." (And I'm not arguing that this is the case, just providing an example.)

Just double checked my stuff (Cisco only, sorry). There definitely is a bit of disparity even between Cisco. I think "Authentication" might be best to keep it simple, but only between the models.

I wonder if it would make more sense to break it out into some different models for Phase 1 and Phase 2, and also between IKEv1 and IKEv2:

• IKEv1 (Phase 1)
• IKEv2 (Phase 1)
• IPSec (Phase 2)

The only reason I am thinking this, is because, at least on the FMC, you can associate multiple IKEv1 and IKEv2 profiles with a peer. I am also good with leaving it somewhat generic, so we don't have to break out the models, but I think it might need to be moved to a 1:Many relationship (although M2M might be easier to just deal with)

For reference:

• FMC:
  • Phase 1:
    • IKEv1:
      • Encryption
      • Hash
      • Diffie-Helllmana Group
    • IKEv2:
      • Integrity Algorithhm
      • Enncryption Algorithm
      • PRF Algorithm
      • Diffie-Hellman Group
• Phase 2:
  • IKEv1:
    • ESP Encryption
    • ESP Hash
  • IKEv2:
    • ESP Encryption
    • ESP Hash
• Cisco IOS (All CLI)
  • Phase 1:
    • IKEv1:
      • encryption
      • authentication
      • group
    • IKEv2:
      • integrity: "Set integrity hash algorithm(s) for proposal"
      • encryption: "Set encryption algorithm(s) for proposal"
      • group: "Set the Diffie-Hellman group(s)"
      • prf: "Set prf algorithm(s) for proposal"
  • Phase 2:
    • IKEv1:
      • AH
      • ESP
    • IKEv2:
      • AH
      • ESP

[jsenecal]

I guess I'm a bit confused by the comments above. The IPSec attrbiutes aren't first-class attributes; they're defined in a separate IPSecProfile model which may optionally be assigned to a Tunnel as appropriate. Nothing about this arrangement precludes us from accurately representing non-IPSec tunnels.

There and there

...but you are right in the sense that they are optional attributes. I would then advocate for validation against setting these fields when a tunnel of a non-ipsec encapsulation type is selected for good measure.

[jronnblom]

Late to the game, but here are a few comments:

We have different setups depending on the customers hardware setup. So a VPN server on our side could talk ikev1 and ikev2. Also different encryption and authentication algorithms. And both tunnel and policy based ipsec configuration.

The VPN server on our side has different ipsec setups. Both ikev1 and ikev2 are present. Multiple customer terminate here. On the same external IP. Different hardware VPN servers is present at customer site depending on the customers choice.

—< example for tunnel ipsec >--

ipsec proposal sha2-*
esp authentication-algorithm sha2-*
esp encryption-algorithm aes-*

ike proposal 1
encryption-algorithm aes-*
dh group*
authentication-algorithm sha2-*
authentication-method pre-share
integrity-algorithm hmac-*
prf hmac-*

ike peer jr-gw1
undo version 1
exchange-mode auto
pre-shared-key not-so-secret
ike-proposal 1
local-id-type ip ip-configurable
remote-id-type ip
remote-id x.y.49.136
local-id x.y.114.4
rsa encryption-padding oaep
rsa signature-padding pss
local-id-preference certificate enable
ikev2 authentication sign-hash sha2-*

ipsec profile jr-gw1
ike-peer jr-gw1
proposal sha2-*
anti-replay enable

interface Tunnel101
ip binding vpn-instance labb1
ip address 10.99.0.4 255.255.255.248
tunnel-protocol ipsec
source x.y.112.6
destination x.y.49.136
service-manage ping permit
ipsec profile jr-gw1

ip route-static 10.x.y.z 255.255.255.0 Tunnel101

—< end example >--

———

This is a setup for policy based ipsec (might be called interesting traffic).

—< example for policy based ipsec >--

ip address-set central-nettype object
address 0 10.x.y.z mask 24

ip address-set customer-local-net type object
address 0 10.x.y.z mask 24

acl number 3000
rule 5 permit ip source address-set central-net destination address-set customer-local-net

ipsec proposal prop57235052749
encapsulation-mode auto
esp authentication-algorithm sha2-*
esp encryption-algorithm aes-*

ike proposal 2
encryption-algorithm aes-*
dh group*
authentication-algorithm sha2-*
authentication-method pre-share
integrity-algorithm hmac-*
prf hmac-*

ike peer ike57235052749
undo version 1
exchange-mode auto
pre-shared-key not-so-secret
ike-proposal 2
local-id-type ip ip-configurable
remote-id-type ip
remote-id x.y.z.36
local-id x.y.114.9
dpd type periodic
remote-address x.y.z.36
rsa encryption-padding oaep
rsa signature-padding pss
local-id-preference certificate enable
ikev2 authentication sign-hash xxx

ipsec policy ipsec5723262732 2 isakmp
security acl 3000
ike-peer ike57235052749
proposal prop57235052749
anti-replay enable
tunnel local applied-interface
alias l2l_labb2
sa trigger-mode auto
sa duration traffic-based 0
sa duration time-based 86400

—< end of example >--

Would I be able to model both setups with this proposal?

And terminate multiple tunnels/policy-based ipsecs on the same device?

[markkuleinio]

Unfortunately I'm late on this game, I've been monitoring Discussions but never been looking at the issues or PRs specifically. But the question by @jronnblom above was left open, and I asked similar question in discussion #14666:

How should the VPN tunnels be configured in NetBox 3.7 when I cannot use the same Outside IP for more than one tunnel? Have I misunderstood some aspect of the intended modeling?

[DanSheps]

How should the VPN tunnels be configured in NetBox 3.7 when I cannot use the same Outside IP for more than one tunnel? Have I misunderstood some aspect of the intended modeling?

Open a new Feature Request/Bug Report describing the issue, making a justification for it (and if you open it as a bug why it is a bug and not a feature request).

[markkuleinio]

Open a new Feature Request/Bug Report describing the issue, making a justification for it (and if you open it as a bug why it is a bug and not a feature request).

#14706 opened