Connection between discovery server and client through a NAT port forwarding

[jishnuj74]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

we are trying to connect DDS server in listener node is in one PC with IP address and talker as a client that is in another subnet . we have a router which we have port forwaded from for example 192.168.7.1 to 192.168.8.250 and talker is running in 192.168.8.90 . we have imported profiles as well in server side and client as well . But we are unable to communicate between talker and listener.

Required assistance to setup xml files in server and client side to listen the message between

Current behavior

NOdes are not communicating with the discovery server

Steps to reproduce

1.Run discovery server on 1st laptop (192.168.7.15:11811)
2. run listener on same PC in another terminal.
3. set up a router in between where u forward the port from 192.168.7.1 to 192.168.7.120
4. Run talker on the 192.168.8.19 pc .

Fast DDS version/commit

fast dds version - v2.6.4

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

UDPv4

Additional context

No response

XML configuration file

client XML is: 
<defaultMulticastLocatorList>
                    <locator>
                        <udpv4>
                            <!-- Access as physical, like UDP -->
                            <port>7416</port>
                            <address>192.168.7.90</address>
                        </udpv4>
                    </locator>
                   </defaultMulticastLocatorList>

Relevant log output

No response

Network traffic capture

No response

[excasm]

We have the same problem. No need to add details. I would add the same content.

[jishnuj74]

Anything on how to solve this problem.

[excasm]

One thing I can say from my struggles.
I currently busy with the need to disable the multicast discovery service.

Multicast will end at each broadcast border, in your case your router (routers and bridges are broadcast borders).
If you want to be able to get multicast packages out of your subnet, you have to instanciate something like igmp snooping on the distributing router.

In the end you have to request for this multicast group periodically to be sure that the packages will arrive.

This is only for multicast distribution.

You (and me too) should think of a unicast discovery service solution.
Or if you are going to distribute something in a vpn tunnel or somewhere else, also a solution with brokers can be considered.

In the end I'm also searching for a solution but this will definitly not a multicast discovery service in this scenario.

Because multicast is per design thought for something else in a normal network environment it reaches every endpoint and be used as for example a discovery service, but outside of the network you(and me) have to think about another solution like unicast discovery services, directly known endpoints, broker, etc.

Don't know haven't found a suitable solution yet.

But if someone knows, please let us know

[jishnuj74]

one i have found out is DDS router by eproxima in fast DDS which is able to communicate in this possible scenario. I am able to now communicate between each other and able to get unicast data.

[JesusPoderoso]

Hi @jishnuj74 and @excasm
It seems that it is a deployment problem. According to our contributing guidelines, i've moved this issue to support section.
As @excasm suggested, unicast would be recommended instead of multicast in this scenario. In any case, it would help if you can share a complete XML configuration file for both server and client.
Have you tried to set up the discovery phase as here?

Including a DDS router would not be neccessary if the discovery deployment gets fixed.

[jishnuj74]

HI
@JesusPoderoso
I have disabled the multicast by mentioning the peer address as in XML file . These are the XML files both in server and client side . Im trying to establish connection between discovery server and client in a port forwarding scenario.
server.docx
client.docx
Please review this and waiting for your comments.