I assume the issue that prevents Roon from working on mobile devices over VPN is down to broadcasts not being propagated, especially with iOS devices which introduces other issues into the VPN with its VPN framework.
On iOS at least Roon does not appear to follow the apple suggested practice of upon connect failure, using the reachability service to complain about lack of WiFi 
What I suggest is simply to add an option to allow the IP address/hostname of the Roon core server to be user entered and stored in settings as a fallback whenever core discovery fails. It could even just cache the discovery response into app-local storage/settings and use that as a fallback on failure.
Similar if required, allow the device to specify its address to core as a music destination (I don’t know if core relies upon discovery broadcasts to determine that an iPhone exists as an endpoint).
I think these two small changes to all client apps would finally open up easy to use VPN access to our home Roon servers without the headache of various complex methods for proxying broadcasts and/or SSDP specifically (I assume this is what Roon uses for discovery?).
I personally would like to use Roon from work and from in my car, however even though my VPN server is actually running on the same QNAP NAS as Roon server, it cant discover Roon server due to the standard lack of subnet local broadcast propagation. I have even been vaguely thinking of creating my own costum build of OpenVPN until I remembered then even if I hacked OpenVPN to convert local broadcasts into directed broadcasts, the VPN extension framework in iOS will probably prevent this from working anyway as will using TUN mode VPN.
So, it seems by far the easiest resolution for everyone is for the Roon controller apps to allow configuration of the Roon server address or hostname and allow registration of the device as an audio recipient (if it doesn’t already) as that then bypasses all of the VPN/VLAN related issues by removing broadcasts completely.
