Configuration example: WAN with dynamic ipaddresses and dyndns (optional SSL/TLS)

[mockbot]

Hi,
is there a real world internet wan configuration for home labs available ?

1. both local networks (192.168.1.0/24 and 192.168.2.0/24) are connected to the internet via provider router, using NAT and dynamic router ip addresses
2. both endpoint are reachable by using dyndns FQDN (dds1.dyndns.org and dds2.dyndns.org)

rviz2-manager<--->dds-gw1--->router1(dds1.dyndns.org)<---internet--->router2(dds2.dyndns.org)<---dds-gw2<--->rover

How is this possible ?
What are the keywords for using this scenario ?
Is SSL/TLS secure communication between both dds-routers available (self signed certificates) ?

I guess, such wan-home-example.yaml is very useful for all homeworkers and students.

[jparisu]

Hi @mockbot

I am not sure what do you mean about "real world internet wan configuration for home labs", could you be more precise?
In the documentation, this example is a "real world internet wan configuration" and explains how to set-up an standard internet router so the communication could be established from home by port-forwarding: https://eprosima-dds-router.readthedocs.io/en/latest/rst/user_manual/wan_configuration.html
This configuration could be found here in the repository: https://github.com/eProsima/DDS-Router/blob/0.4.0/resources/configurations/examples/wan_client.yaml

Attention be careful if using main branch, as we are updating the configuration (it will add a new configuration version v3.0 so old executions work as they used to.

We have also tested dyndns and it works properly. It is possible to set a "Domain Name (DNS)" rather than an IP easily in the configuration. Check this documentation: https://eprosima-dds-router.readthedocs.io/en/latest/rst/user_manual/configuration.html#network-address

[mockbot]

ReHi,
thanks for the friendly reply...
I try to explain, where my problems are located.
"real world internet wan configuration for home labs"...
Oh yes, I'm a networking guy and I have problems to understand the usage of your keywords...
e.g.
ip means internet protocol, but you should use ipaddress. Next issue, you use the domain keywords for an identifier of a domain and as ipaddress when using a FQDN and TCP layer 3 protocol instead of a dotted ip address number...
Why do you have 2 different keywords for the partner ipaddress ? Confusing...
ipaddress should handle dotted ipaddress numbers and FQDN. The standard resolver libs getHostByName will handle it since the beginning ;-)

What is "real world internet wan configuration for home labs" ?

1. both ends are using dyndns and NAT, no hardcoded ipaddresses numbers.
2. communication protocol between both partners TCP/SSL

I've tried it with version from June 2022, but I've failed. Topics were not visible and I was not able to see open sockets. I guess, I need to go deeper into the traffic with wireshark tools.
Next week, I will give it a try again. I guess, we should talk about these scenario by using config files for both ends of the communication.

"Attention be careful if using main branch, as we are updating the configuration (it will add a new configuration version v3.0 so old executions work as they used to."
Maybe this will give me some hints and open my eye !!! ;-)
THX4ALL
Greetings from DE

[mockbot]

I've prepared a small documentation here: https://ns.xdsnet.de/extCloud/nextcloud/index.php/s/qYJWBoZEpAPKCyG

[jparisu]

Hi @mockbot
Thank you for the detail explanation.

IP and Domain

We separated ip from domain tag because we thought it would be easier to understand for a user. It seems is not though, so we may change it in future releases.
We appreciate a lot the users feedback so we can improve the user experience of the DDS Router.

Your Scenario

From your scenario, we assume the students and the teacher must be able to communicate with the Lab, but not between themselves.
The Lab will work as TCP server, and will need a ´listening-addressesconfiguration, while the TCP servers (students) only need to set theconnection-addresses` targeting this same address.

Answers

does each communication partner need a public dns registered FQDN or is it enough for the central lab side ?

No, it does not. Only one of the points needs to be accessible (ports forwarded and FQDN). The others will connect to it and the communication will be established.

Example for central side (lab). How to handle listen ?

The DDS Router is thought to forward every data that arrives from one side (WAN in this case) to the other (LAN). So the TurtleSim in the Lab will work as if the edge devices (Students) were in its local network.
No configurations or changes are required in the ROS2 sides, the Router will handle it.

Repeater Scenario

If this scenario implies the students to communicate with each other as well as with the Lab, you can use the new feature Repeater.
This is a feature that we are working on, and will be released in next version (it is already in main), and it allows to deploy a TURN server to communicate multiple points of the internet within each other (including the own server, that could communicate its own network: LAB).
Here it is the documentation available for the Repeater so far: https://eprosima-dds-router.readthedocs.io/en/latest/rst/use_cases/repeater.html
Handling the FQDN, ports and TCP is as easy as using a configuration like this one:
https://eprosima-dds-router.readthedocs.io/en/latest/rst/examples/repeater_example.html#client-participants

This is also achievable by Discovery Server, but the students would need a public FQDN and open ports in their routers.

Configuration files

Please, feel free to share configuration files with us if you need help or feedback about any of them.

[jparisu]

I moved this conversation to Discussion as it is not associated with any bug or malfunctioning of the Router, but rather with questions and answers about it.

[mockbot]

configuration v3 is a great improvement ! THX!
Now I try to debug the participiants sessions. Is there a chance to debug ddsrouter and see which topic match and forwarded to partner ?
At the moment, I use tcpdump and netstat...

[jparisu]

Compiling in Debug with CMake option -DLOG_INFO=ON and using ddsrouter argument -d/--debug you will be able to see the debug logs of the DDS Router. However this is not intended for users, and it may be too complex to follow.
I would consider two other possibilities:

Echo Participants

There is a kind of Participant available in the Router that echo in stdout discovery information and data forwarded.
https://eprosima-dds-router.readthedocs.io/en/latest/rst/examples/echo_example.html
NOTE: in main the EchoParticipant behaviours has been extended and enhanced, but it is still not documented. This documentation will be added soon.

Fast DDS Monitor

The Monitor is an eProsima tool that allows to get discovery and metatraffic information for DDS entities in a local network. It will not show remote entities, but it can be used to debug your network and to know how the DDS Router internal entities are working.
It also collects instrumentation data that could be plotted, but this requires extra CMake compilation options and configurations in Fast DDS.
https://fast-dds-monitor.readthedocs.io/en/latest/

[mockbot]

I'm still confused with the TCP WAN Client configuration. Did the client need a listener section ?
Without listener configuration, the server reports '[RTCP Warning] SEND [RTCS] Failed: Not connected ...
That's weird or makes no sense for me in a real world scenario. The server knows inband the clients return address and can respond. Inband hardcoded listener ip addresses cause a lot of trouble and need like SIP always addtional helpers (e.g. TUN) to survive in the NAT and DYNDNS world.
Maybe my configuration and understanding problem ?

[jparisu]

Hi @mockbot

I think it will be much easier for both if you could share the YAML configuration files you are working on. I encounter difficult to find a solution to your problem otherwise.

Regarding your concerns:

Did the client need a listener section ?

No, it does not. Using only connection-addresses should be enough to create a TCP channel with the listener (as long as this is reachable).

Without listener configuration, the server reports '[RTCP Warning] SEND [RTCS] Failed: Not connected ...

This is a known warning in Fast DDS RTCP. It is triggered because the "TCP Server" tries to reach the client, and this normally fails. But it still uses the TCP channel opened by the client, so the communication works though.