ROS 1 Topics Over a VPN: Follow the Advertised Endpoint

Your workstation reaches the ROS 1 master over the tunnel and still shows an empty topic list. That pattern is common because master registration and topic transport are two different conversations, and only the first one goes through the master. The checklist below walks the second conversation: the endpoint a publisher advertises, the address a subscriber must be able to reach, and the permission that lets the pair talk. Everything here is scoped to legacy ROS 1, whose Noetic support window ended in May 2025.

Step 1: prove the master connection is not the topic connection

Start by separating what works from what does not. A successful rostopic list proves that your shell can reach the master's XMLRPC port and that the master knows about topics; it says nothing about whether a subscriber can reach the publisher. The three commands below make the distinction visible, and all of them are read-only.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

The output of rostopic info names the publisher's node URI, which is an XMLRPC address on the publisher's host. That address is the one your subscriber will call next, so it must be reachable from wherever the subscriber runs. If it points at an interface that only exists on the robot's own LAN, the master lookup succeeds and the data never arrives.

Step 2: read the advertised endpoint from the node itself

ROS 1 chooses its advertised host identity from ROS_IP or ROS_HOSTNAME when either is set, and falls back to the host's own name resolution otherwise. Inspect the environment of the process that was actually launched, because a systemd unit, a container or a second terminal can carry a different value from the shell where your test worked.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

A hostname advertisement only works if every peer resolves that name to the intended reachable address. If that name resolves only inside the robot's own network, a workstation on the far side of the tunnel has no way to use it, and a VPN that pushes no DNS suffix makes the mismatch worse. Setting ROS_IP to the tunnel address is the smaller change when the topology is routed. Whichever you choose, record it for both ends, because a publisher and a subscriber that disagree about identity will negotiate and then fail to connect.

Stop here if the advertised URI uses an address that no peer can route to. No amount of firewall work will fix a name that resolves to the wrong interface.

Step 3: make the advertised address resolvable and routed

With the URI in hand, test reachability from the subscriber's host rather than from the robot. The TCPROS port is chosen during negotiation, so the useful early test is the XMLRPC port and the useful later test is the established socket. A route that exists in only one direction is a common failure on routed VPNs, and the return path matters as much as the forward one.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

A routed TUN interface carries these IP conversations without extending the robot's Ethernet segment, which is usually what a remote operator wants. If something in the stack depends on broadcast or multicast instead, that requirement has to be evaluated on its own; converting the tunnel to TAP to satisfy one tool widens the network for every participant.

Stop here if the route or the return path is missing. A publisher that answers on its own host but cannot be reached from the workstation has a routing problem, not a ROS problem.

Step 4: permit the peer conversation and watch one topic

Open only the ports the negotiated conversation needs, and scope each rule to the declared participants. The master's listener is not a relay for topic payloads, so permitting it alone leaves the publisher's endpoint closed. Keep the ROS listeners on the private VPN boundary instead of exposing them to the public internet.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Watch one benign topic from the real publisher to the real subscriber and confirm both the advertised endpoint and the reply path. A single message proves the path works; a steady rate proves it stays open. Keep actuator control and safety checks outside this network-only test, because a working topic does not certify a working robot. Record the ROS version and the endpoint pair you observed, so the next person can tell a topology change from a regression.

The checklist is finished when the advertised URI is reachable from the subscriber, the negotiated port is open to that peer only, one declared topic flows, and the environment values are written down for both hosts. Legacy ROS 1 will not receive fixes in this area, so the record is the part that keeps working after the people change.