More tunnel options

[TeroPihlaja]

NetBox version

v4.0.2

Feature type

Data model extension

Proposed functionality

Add support for the following VPN tunnel types:

• WireGuard
• OpenVPN

Use case

Currently only IPsec tunnels are supported by Netbox.

We have also OpenVPN and WireGuard tunnels in use.

Database changes

No response

External dependencies

No response

[jeffgdotorg]

Thank you for your interest in improving NetBox. OpenVPN and WireGuard are indisputably popular tunnel technologies, and NetBox would better reflect reality if it included support for them.

Before we could proceed, though, we would need more detail than you've provided here. Please explore the ways that the requested technologies differ from IPSEC, and call out any resulting challenges that a developer implementing this feature would need to take into account. It doesn't need to be a code-level analysis; we just want to encourage you to think through the implications of what you're requesting. The maintainer team is currently quite small and so we generally must prioritize FRs that offer the biggest impact for the smallest development effort.

Please revise your issue body accordingly, and we will give it due consideration.

[Aketzu]

Current Netbox seems to be modeled pretty much around IPsec ideology but OpenVPN and Wireguard semantics don't match well with that.

Wireguard,

• Endpoints have device/interface/IP and optional port number. Although mobile endpoint IP might not be known.
• There is only one authentication, private key. It could be stored in Netbox with corresponding public key part. (Maybe Netbox could even calculated pubkey from privkey). At least public key must be stored.
• There can be multiple connections to each endpoint. Different connections are identified by their public keys
• Both sides can have list of subnets which are allowed & routed to them (AllowedIPs config)

OpenVPN Static key mode is simple,

• Point-to-point. Somewhat similar to current IPsec connections and PSK.
• At least one side has known IP + port
• Ciphers + compression can be configured but not much more.
• Routing is handled outside OpenVPN. There can be scripts that are run after connection

OpenVPN TLS mode is complicated,

• Point-to-multipoint.
• SSL certificates are used for server and client authentication so there needs to be a CA.
  • I think this would require "certificate" concept in Netbox... which could then contain normal https certificates as well and handle their expiration checks etc.
• Server has IP address pool from where it assigns IPs to clients like DHCP server
• Server can push DNS/NTP configs to clients
• Server can push routes to clients (i.e. routes added to client machines)
• Server can have client-specific configs (e.g. IP address)
• Server can route subnets towards specific client.

In all cases single device can have multiple Wireguard and OpenVPN servers in different ports with different keys and different set of connected endpoints.

Netbox needs bunch of changes:

• IKE/IPsec details are naturally IPsec specific and could be kept as-is.
• Tunnels can work for other types but needs new "type" field or then "encapsulation" could be reused.
• First termination would need port number
• Second termination doesn't work with point-to-multipoint connections since there can be many of them. Something different needs to be thought here.
• OpenVPN needs more configs so maybe "OpenVPN profile" entity would be good
• Wireguard needs the keys but having separate entity feels a bit excessive since only priv/pubkey is needed. Although it should not work differently than IPsec/OpenVPN.
  • Due to way wireguard uses public keys as identifiers there needs to be way from Wireguard key entity to know which device owns it.
• List of routes behind each endpoint is important. I think this is also missing from current IPsec implementation

[github-actions]

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.