Support for VPN Tunnels #6705

@mlazzarotto commented on GitHub (Jul 21, 2022):

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

@mlazzarotto commented on GitHub (Jul 21, 2022): Please don't close and mark as duplicate. It is indeed a duplicate of #5845 but this is more detailed.

adam commented

@DanSheps commented on GitHub (Jul 21, 2022):

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.

@DanSheps commented on GitHub (Jul 21, 2022): 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.

adam commented

@ryanmerolle commented on GitHub (Jul 21, 2022):

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 on GitHub (Jul 21, 2022): Feels like the perfect candidate for a plugin. If it was well built, it could even make it into the core at some point.

adam commented

@ryanmerolle commented on GitHub (Jul 24, 2022):

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.

@ryanmerolle commented on GitHub (Jul 24, 2022): 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.

adam commented

@jeremystretch commented on GitHub (Jul 26, 2022):

@mlazzarotto missed the MTU

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

@jeremystretch commented on GitHub (Jul 26, 2022): > @mlazzarotto missed the MTU MTU is an attribute of the virtual interface on either end (which we already track), rather than the tunnel itself.

adam commented

@ryanmerolle commented on GitHub (Jul 27, 2022):

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

@ryanmerolle commented on GitHub (Jul 27, 2022): Yes I agree I was just looking at the model he was drawing reference from.

adam commented

@github-actions[bot] commented on GitHub (Sep 25, 2022):

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.

@github-actions[bot] commented on GitHub (Sep 25, 2022): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@pobk commented on GitHub (Feb 27, 2023):

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.

@pobk commented on GitHub (Feb 27, 2023): 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.

adam commented

@saifvs commented on GitHub (Feb 27, 2023):

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)

@saifvs commented on GitHub (Feb 27, 2023): 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](https://user-images.githubusercontent.com/66313945/221584853-cfd1d616-9077-419f-a5ed-6c357c64bc39.png) 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](https://user-images.githubusercontent.com/66313945/221585390-7ac8e469-eb6a-48e5-8423-14c11716f984.jpg)

adam commented

@misch42 commented on GitHub (Jun 2, 2023):

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.

@misch42 commented on GitHub (Jun 2, 2023): 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.

adam commented

@mlazzarotto commented on GitHub (Aug 11, 2023):

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.

@mlazzarotto commented on GitHub (Aug 11, 2023): 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.

adam commented

@p-rintz commented on GitHub (Aug 11, 2023):

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.

@p-rintz commented on GitHub (Aug 11, 2023): 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.

adam commented

@mlazzarotto commented on GitHub (Aug 11, 2023):

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

@mlazzarotto commented on GitHub (Aug 11, 2023): > 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

adam commented

@shepherdjay commented on GitHub (Aug 11, 2023):

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

@shepherdjay commented on GitHub (Aug 11, 2023): > https://github.com/robertlynch3/netbox-tunnels2 Only downside of using plugins is that like @saifvs [stated ](https://github.com/netbox-community/netbox/issues/9816#issuecomment-1446387266) 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

adam commented

@ryanmerolle commented on GitHub (Aug 11, 2023):

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

@ryanmerolle commented on GitHub (Aug 11, 2023): @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.

adam commented

@mlazzarotto commented on GitHub (Aug 18, 2023):

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.

@mlazzarotto commented on GitHub (Aug 18, 2023): 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.

adam commented

@st-nip commented on GitHub (Oct 9, 2023):

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

@st-nip commented on GitHub (Oct 9, 2023): This seems like a good idea, and I'd also rather have it included as base functionality rather than having to use a plugin.

adam commented

@misch42 commented on GitHub (Oct 9, 2023):

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.

@misch42 commented on GitHub (Oct 9, 2023): 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.

adam commented

@jeremystretch commented on GitHub (Oct 20, 2023):

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.

@jeremystretch commented on GitHub (Oct 20, 2023): 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.

adam commented

@misch42 commented on GitHub (Oct 20, 2023):

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.

@misch42 commented on GitHub (Oct 20, 2023): 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.

adam commented

@jaylik commented on GitHub (Oct 31, 2023):

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

@jaylik commented on GitHub (Oct 31, 2023): Also support for connecting tunnels to virtual machine interfaces (used with virtual routers / firewall) would be great.

adam commented

@jeremystretch commented on GitHub (Nov 7, 2023):

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

@jeremystretch commented on GitHub (Nov 7, 2023): I believe I've identified a workable model to support general VPN tunnel topologies, so I'm tagging this as a v3.7 initiative.

adam commented

@jsenecal commented on GitHub (Nov 8, 2023):

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.

@jsenecal commented on GitHub (Nov 8, 2023): I was looking at your [branch ](https://github.com/netbox-community/netbox/tree/9816-tunnels) @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.

adam commented

@BarbarossaTM commented on GitHub (Nov 9, 2023):

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

@BarbarossaTM commented on GitHub (Nov 9, 2023): 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 :)

adam commented

@jeremystretch commented on GitHub (Nov 9, 2023):

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.

@jeremystretch commented on GitHub (Nov 9, 2023): 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.

adam commented

@DanSheps commented on GitHub (Nov 10, 2023):

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.

@DanSheps commented on GitHub (Nov 10, 2023): 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.

adam commented

@jeremystretch commented on GitHub (Nov 15, 2023):

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.

@jeremystretch commented on GitHub (Nov 15, 2023): > 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](https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-6)) > 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](https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-4) 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](https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8). > 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.

adam commented

@misch42 commented on GitHub (Nov 15, 2023):

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

@misch42 commented on GitHub (Nov 15, 2023): 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". ...

adam commented

@jeremystretch commented on GitHub (Nov 15, 2023):

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

@jeremystretch commented on GitHub (Nov 15, 2023): @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.

adam commented

@DanSheps commented on GitHub (Nov 15, 2023):

@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

@DanSheps commented on GitHub (Nov 15, 2023): > @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

adam commented

@jsenecal commented on GitHub (Nov 15, 2023):

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.

@jsenecal commented on GitHub (Nov 15, 2023): > 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](https://github.com/netbox-community/netbox/pull/14276/files#diff-a3e8aef1a511583c0596162a748e6768b32659bf81577f45b830c7b95e44caeeR34) and [there](https://github.com/netbox-community/netbox/pull/14276/files#diff-a3e8aef1a511583c0596162a748e6768b32659bf81577f45b830c7b95e44caeeR48) ...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.

adam commented