search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.37k stars 2.6k forks source link

Support for VPN Tunnels #9816

Closed mlazzarotto closed 1 year ago

mlazzarotto commented 2 years ago

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

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 commented 2 years ago

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

DanSheps commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

@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 commented 2 years ago

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

github-actions[bot] commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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. image

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)

topology

misch42 commented 1 year ago

Hi,

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

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

mlazzarotto commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jeremystretch commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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:

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:

jsenecal commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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