This is a good decision all things considered, but there are plenty of hardware vendors with proprietary firmware that only support ovpn and now mullvad is unusable for them. I suppose the onus is on them to support wireguard, but still think of how long it took python3 to become standard after it was released, I hope to see wireguard become the standard soon but I expect lots of vendors will take their time on the transition.
I think whatever warning is OK with the users who pay them. There's a feedback mechanism there, they get paid more the more customers they have.
I don't know how most mullvad users use it, but I've never used their ovpn configurations, and I use it on client devices and not some network gateway. It's not going to affect me one bit. I've considered using it on some network hardware I have that only supports openvpn to give myself network wide benefits of it, but because I often use it on my clients to change IPs, and otherwise cycle through different servers as needed, haven't made that move yet. So even if I wanted to, I'd probably have to do a custom solution which means I can use wireguard anyway.
Never been a Mullvad user, but namespaced-openvpn (https://github.com/slingamn/namespaced-openvpn) was one of the only ways to torrent-over-proxies that I found (years ago); user namespace with the torrent client & openvpn as it's only link out.
There is gluetun, https://github.com/qdm12/gluetun, which servers a similar purpose whole supporting ovpn and wireguard (including prepared configs for various commercial VPN providers). It's usable with, e. g., Docker to have namespace-based proxying of traffic for a container.
I love wireguard and the configuration methods compared to openvpn.
reply