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

Implications analysis (lifted up from comment below) 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 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.

Use case

Currently only IPsec tunnels are supported by Netbox.

We have also OpenVPN and WireGuard tunnels in use.

Database changes

NetBox needs a 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

External dependencies

No response