I've recently set up an OpenVPN client container to route a few containers through as I don't want the VPN to affect all of the server's traffic, however I'm unsatisfied with the setup and loss of features such as easy access to routed containers' WebUIs and I think this could be done better.
Proposed changes:
Add "Container" as a "Network Type" option which would then display another dropdown with available containers.
This will address the need to enable the "Advanced" view to manually write the command to do so, unRaid could also keep track of the target/VPN container's name and update all dependent templates accordingly.
Apply ports defined in a routed container's template on the target/VPN container.
This will address the need to modify both containers during setup, the issue of a container setup breaking when the network type set in the UI is still "Bridge" with ports defined, and the need to modify the target/VPN container to remove the ports after removing the routed container, and re-enable easy access to WebUI.
Allow multiple network setups such as using the "Bridge" network type when the target/VPN container is shut down when VPN routing is not desired for any reason temporarily, without needing to modify routed containers to "Bridge", redefining ports only to undo so when VPN routing is desired again.
I'm still new to docker (and Linux in general) but from what I understand this might require two installations of the docker containers, but this could be handled by unRaid by starting/stopping the appropriate install based on whether the target/VPN container is running and restarting the routed containers when the state changes (but not when the target/VPN container is restarting).
Enable the WebUI menu option on containers under more conditions (or a toggle in the template to always enable it).
This spans a bit beyond the initial scope of this request but it will allow the easy access of routed containers' WebUIs among other use cases, the option is currently dependent on the network type (at least it wouldn't work on any container network) and at least one port being defined in the template (even if blank or if the port is hardcoded), this prevents the use of hardcoded/remote addresses, dynamic DNS and hardcoded ports.