In case you don't know, ssh has built-in VPN support which may be enough for lots of use cases.
> OpenSSH has built-in TUN/TAP support using -w<local-tun-number>:<remote-tun-number>. Here, a layer 3/point-to-point/ TUN tunnel is described. It is also possible to create a layer 2/ethernet/TAP tunnel.[0]
Just with invalid terminology (s/ssh/OpenSSH) and the likelihood of the added slowdown mentioned in the article.
man 1 ssh:
-w local_tun[:remote_tun]
Requests tunnel device forwarding with the specified tun(4)
devices between the client (local_tun) and the server
(remote_tun).
The devices may be specified by numerical ID or the keyword
``any'', which uses the next available tunnel device. If
remote_tun is not specified, it defaults to ``any''. See also
the Tunnel and TunnelDevice directives in ssh_config(5). If the
Tunnel directive is unset, it is set to the default tunnel mode,
which is ``point-to-point''.
Tunnel Request tun(4) device forwarding between the client and the
server. The argument must be yes, point-to-point (layer 3),
ethernet (layer 2), or no (the default). Specifying yes requests
the default tunnel mode, which is point-to-point.
TunnelDevice
Specifies the tun(4) devices to open on the client (local_tun)
and the server (remote_tun).
The argument must be local_tun[:remote_tun]. The devices may be
specified by numerical ID or the keyword any, which uses the next
available tunnel device. If remote_tun is not specified, it
defaults to any. The default is any:any.
PermitTunnel
Specifies whether tun(4) device forwarding is allowed. The argu-
ment must be yes, point-to-point (layer 3), ethernet (layer 2),
or no. Specifying yes permits both point-to-point and ethernet.
The default is no.
Independent of this setting, the permissions of the selected
tun(4) device must allow access to the user.