feature request: config option to no configure the interfaces and run DHCP

[klaernie]

When running a tunnel in tap mode it would be useful for me to not require a completely routed VPN, when I could just bridge the remote tap interface into the actual network and obtain an IP via DHCP.

Right now the VPN is very opinionated in that it is presuming that the remote end must be manually set up (which is as easily done with e.g. a systemd-networkd configuration matching all tun* or tap* interfaces) and that automatic configuration of an IP is impossible. It also assumes that the remote end is not needed as the DNS server.

In my setup I tunnel very occasionally "back home" when on vacation, and having an openvpn setup running for that is definitely overkill. Tinkering with it took me a while to setup this VPN in a way that allows me to access the remote network properly. My lessons learned were:

• running DHCP directly is not supported by the config
• In order to get DNS resolved on the remote end the nameserver must be configured explicitly as "additional DNS server"
• In order to reach anything besides the internet on the remote network an additional route for the target network is required
• Making the local machine reachable in the regular remote network on requires either static host routes in each machine of the remote network or setting a static route on the gateway of the remote site
• full back-and-forth routing requires configuration in stricter firewalls like pfsense to allow the asymmetric routing internally
• firewalls like pfsense require explicit allow rules for allowing the VPN to talk to internet
• a DNS resolver might require additional ACL allowances to allow recursion (again the pfsense unbound default config)
• alternative to all the routing and firewall/acl trouble is configuring masquerading on the remote server, which cannot be practically setup by NetworkManager-ssh, but this of cause looses the direct access from the remote network to the local machine which can be useful for example for centralized backup systems

Most of this can be solved by directly putting the machine into the remote network and letting the regular infrastructure on the other end manage it all, but this of cause requires a bridge set up on the other end. But for the people that already have this in place (e.g. because the machine being remoted into is a KVM hypervisor) this would make trivial.

As it is right now this direct integration is not implementable at all unless manually undoing all the setup done by the plugin and reconfiguring it both locally (well, running dhclient tap100) and remotely (ip addr del …; brctl addif br0 tap100).

So while there were a lot of fringe usecases semi-supported in the previous versions (like SOCKS or Port-Forwarding) the basic VPN-usability has some use cases missing. I hope this writeup provides a good perspective into what I would consider useful.

[danfruehauf]

Absolutely valid. When I first wrote nm-ssh, it was meant as a "poor man's VPN", though it looks like it got some traction, and more "comprehensive" features are requested.

But I wonder, if you do have such a setup, wouldn't it be better to use a "proper" VPN instead? Like OpenVPN or similar?

[klaernie]

You are right, a proper VPN is superior if I'd be on the road regularly. But maintaining OpenVPN means also maintaining a bunch of tls keys - which SSH completely forgoes or makes trivial to delegate into hardware crypto like yubikeys.

As soon as I'd require more than one or two machines on the road or would be working exclusively over a VPN for months at a time. But I've maintained an OpenVPN setup for my home systems and sooner or later I got tired of it and ignored it. Also having a few ancient clients in the mix makes life hard, if ciphers get deprecated.