ROS/Tutorials/MultipleRemoteMachines discusses a networking approach which would allow ROS nodes to communicate across different networks, including the public internet, but it does so by suggesting port forwarding of udp://:1025-65000 and tcp://:1025-65000 (ie: all TCP+UDP ports) from the public IP of a NAT router to a host on the network behind it. Firewalls or VPNs are not discussed, nor any other form of network security.
This is dangerous in any case, but exposing a ROS 1 node graph to the public internet like that is not a good idea, as many papers and security conferences have already demonstrated (hackers waving your PR2’s arms at you, etc).
The fact this tutorial follows the regular multi-machine tutorial makes it seem like this is an “official guide” or even best practice (as the OP of Best Practice for Running ROS Remotely on ROS Answers thought).
I’ve already added a warning to the tutorial, but I believe deleting the page would be the better.
My reason for posting this here first is to see whether others here agree with my assessment.
(an alternative would be to edit the page, but seeing as it’s almost 90% about port forwarding and a specific network setup which depends on that, that doesn’t seem feasible or efficient)
I would recommend creating a new tutorial for using a tunnel, encrypting ROS communication, that is, the solution you propose, and then add a link to that tutorial in the warning in ROS/Tutorials/MultipleRemoteMachines.
This would allow people visiting the page from an earlier Q&A or external links to understand the threat and use the safer option, and yet have the option to use port forwarding if they want to raise the technical debt and just want their system to get to work at the moment.
As for providing a suitable alternative tutorial when working with multiple remote ROS1 machines…
Perhaps providing an example tutorial using WireGuard with ROS1 would be helpful; WireGuard being considerably simpler to setup and use than other VPN utilities like OpenVPN.
Example docs for point to point setup, and user friendly GUI utilities for managing connections:
that’s a nice idea, but it’s often the case users come in via a search engine which deep links to a section. A (single) warning at the top of the page has a high chance of going unnoticed then (especially when people are in a hurry and skip everything which doesn’t look like (copy-pasteable) steps towards the solution).
It would also require someone to write that tutorial, which I don’t believe should be a condition for whether or not corrective action should be taken now.
I’m one of those people who likes to keep things around forever – if only to preserve history – but in this case I’d be in favour of making an exception and just remove it.
Port-forwarding like that is not needed (as there are safer approaches), potentially dangerous (and not just for your ROS node graph) and doesn’t scale (what if I have multiple hosts which should participate in the same node graph? Ports can only be forwarded once).
Wireguard is nice, yes. Certainly when compared to the heavy-handed and central setup OpenVPN typically requires.
I’ve personally used tinc, which is peer-to-peer, cross-platform, user-space and exposes virtual NICs (Wireguard can also do that I believe, but needs additional configuration/software (?)). Especially the latter makes using it with something like ROS really easy.
These are good points. Even in one of the workshops I conducted, I saw people blindly copy paste all the commands, also running all of the installation options!
One solution is to remove contents of ROS/Tutorials/MultipleRemoteMachines, mention why it was removed, and if someone writes a tutorial on the safer proposed solution, add a link to that. Maybe also add link to archived version of the page via wayback machine for example, for someone referring resources which tells them to use port forwarding.
Also, this article seems to not be factoring in communicating over cellular networks. From my experience, trying to reach a remote robot over a cellular network is very painful. Cell providers have NAT setup and do not make it easy. If anyone knows something I don’t I’d be curious more than anything.
I just use a VPN to control my robot. I can log in from my laptop from anywhere, and my mobile robot logs in over a cellular connection from anywhere. I just use standard ROS setup options, no port reconfigurations or additional web socket work. Connections are encrypted. Latency isn’t bad so far (sub 40ms) but I’m still prototyping and am sure I can bring that down.
One note - OpenVPN has a release candidate for openvpn3 on ARM. If you ask their support team they may give it to you (they did for me and I don’t have any inside connections) It’s what I’ve been using to connect to OpenVPN cloud. Ultra easy.
This is an important point. However, I considered that eliminating the MultipleRemoteMachines tutorial is so drastic. People may need that tutorial for certain projects, the warning message should be enough, since it is expected that people with an appropriate understanding of ROS follow that intermediate-level tutorial.
I’ve gone ahead and implemented a compromise: instead of deleting the page, I’ve edited it to remove the “offending” content. Then added an admonition explaining why the content was removed.
To allow people to still access the old version, the admonition includes a link to rev82 of the page, with a warning that it’s not a good idea to implement what the tutorial describes.
Old links to the page will still work, but (new) users should not find the old content there any longer.
