3.7.0 - VPN Tunnels - Encapsulation: WireGuard

[dirtycache]

Encapsulation Type: WireGuard (or a generic 'Other')

WireGuard could benefit from a profile/parameters under Security, perhaps including: port, private key. Also would be good to capture defined WG peers and parameters such as allowed-ips, persistent-keepalive, and peer pubkey -- but I don't exactly grok how this would be modeled or associated with the tunnel object yet.

[bbenouarets]

I use Wireguard for a site-2-site termination. It would be very helpful if this would come soon so that I can also document my configuration.

[bobinson]

Same with us.

[chaeynz]

I also use WireGuard for S2S connections.. Please add

[fox1047]

Would be nice to have a Generic VPN option

[chaeynz]

I don't think a Generic VPN option makes sense. You need some information about the VPN tunnel to actually have useful data that you can use for automation. Surely I could just document it that way, but after all Netbox isn't just documentation.

Having all options for a tunnel interface is definetely a necessity, as I want all that to be accessible over the API

[fox1047]

I think that if it's not possible to include every single one tunnel type including proprietary ones then it will be useful to have a "generic type" as a backup option. Or alternatively add user-defined tunnel types, but I think it will be much more labour intensive.

[chaeynz]

There is a limited amount of tunneling protocols.
When taking proprietary ones into account, we just need to know which options an admin can configure.

I would say it just needs someone to go through the (maybe 10?) different popular tunneling protocols and add them to netbox.

Anyways. Lets start with WireGuard

[netravnen]

Should probably use PR #14276 (#9816) as reference implementation.

[chaeynz]

Thanks for linking that.. I will check this week if I'm capable enough to add this

[chaeynz]

I dont have my netbox instance available, but from what I see in the demo even the GRE encap type offers to specify a IPsec profile under security.
https://demo.netbox.dev/vpn/tunnels/add/

Does anyone have an idea how that should look with WireGuard? Just keep it there?

From my POV I would want to specify the following information:

Interface

• Listen Port
• Private Key
• Public Key
• VTI IP Address

Peer

( Option to select from existing WG interfaces )

• Public Key
• Endpoint Address
• Endpoint Port
• Allowed IPs
• Persistent Keepalive

Probably we would have to remodel the way that netbox currently treats tunnels and make dynamic fields that either appear or dissapear depending on the tunneling protocol specified.

Does anyone know if Netbox currently has such tentatively-visible fields in the "Add" View on Webinterface?

[fudnet]

Wireguard, OpenVPN, and generic "SSL" VPN would be nice including the related configuration options (ports, protocols, ciphers, hash, etc).

[flunda]

+1 for Wireguard and genericVPN

[chaeynz]

Could we have a conversation if it is smart to store private keys in Netbox?

[mcrute]

Definitely. If you have to store secrets they should be in a system designed for secure secret storage, not Netbox. That being said it would be nice to have the ability to at least store a link to an external secret storage system system in Netbox. For example: we have a custom field to store the path of the WireGuard secret in our Vault cluster in Netbox so automation can pull the two together later when synthesizing system configurations. It would be nice if the solution to this request would allow for a similar functionality.

[chbally]

There is a new featurerequest in the issues about VPN encapsulations: #17960
I added the wish of implementation of WireGuard and OpenVPN.
I think we need some commits from the community for this request.