configuration to enable communications with lan and vpn interface

[mitch-galea]

Hello,

Here is my system configuration:

Machine A:
connected to LAN, IP: 192.168.2.4
Machine B:
connected to LAN, IP: 192.168.2.1
connected to VPN, IP: 10.8.0.2
Machine C (remote):
connected to VPN, IP: 10.8.0.3

All machines have ros2 humble.

My goal is to enable Machine B to communicate with both Machine A and Machine C. At the moment Machine B can only communicate with either one of the machines but not both, depending on the ordering in my config file. Is there a way to configure this?

<?xml version="1.0" encoding="UTF-8" ?>
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
    <Domain id="any">
        <General>
            <Interfaces>
                <NetworkInterface address="10.8.0.2" />
                <NetworkInterface address="192.168.2.1" />
            </Interfaces>
        </General>
        <Discovery>
            <Peers>
                <Peer address="10.8.0.3"/>
                <Peer address="192.168.2.4"/>
            </Peers>
            <ParticipantIndex>auto</ParticipantIndex>
        </Discovery>
    </Domain>
</CycloneDDS>

[perchess]

Hey, @mitch-galea! Did you find a solution? I have the same question.

[eboasson]

I've seen variations of this question before and answered them, but this one completely escaped my notice until now. I am so sorry about that ...

In those other cases the problem was that one Cyclone DDS node would advertise two addresses (both valid on that machine) and another node would see both addresses as "routable addresses" and assume that both addresses would work despite one of them not being directly connected. If the kernel routes them it should work, but if not ...

In this particular case, e.g., B advertises both addresses, and A considers 10.8.0.2 a viable address despite A only being connected to the 192.168.2.x network. Then it can happen that A picks the 10.8.0.2 address to send data to B.

Some time ago I did a proper fix as part of something else, but that has stalled for a lack of time. I really need to finish that one, it really solves some nasty issues.

There is a way to avoid it making this assumption by configuring it differently: if you set the General/DontRoute option to true, it sets the corresponding IP option. Because that IP option means you can't send data to an address on a network you're not directly connected to, it then also ignores those addresses completely. So in that case, A will consistently use 192.168.2.1 to send data to B.