0

Case: [ Subnet A , 192.168.2.0/24, Padavan firmware based internet gw ]

[ Subnet B , 192.168.1.0/24, Padavan firmware based internet gw ]

Host from subnet A (2.155) is connected via VPN (possible options: PPTP, OpenVPN, L2TP w/o ipsec) to subnet B, and receives address, saying 1.245/32

In subnet B exists host (1.10/32) which sends multicast datagramms to 224.0.0.50:9898 ; On router I see them with

tcpdump -i br0 -c 10 dst host 224.0.0.50 and port 9898 and multicast

13:46:54.345369 IP 192.168.1.10.4321 > 224.0.0.50.9898: UDP, length 135

I am looking for solutions, to receive/forward those broadcast messages, so they could be seen by hosts, connected via VPN

On router B, which is Padavan firmware based, I have, and limited to udpxy, igmproxy utilities, if needed.

On client host, I am debian based, and generally not limited in tools.

Datagrams are proprietary protocol, i.e. not a iptv or video stream.

Any ideas are welcomed.

[UPD] Additional info - per discussion in comments

That's a very specific hardware device, which is not very chatty in ethernet terms (saying max 1-2 datagramms in 5 seconds), thus for sure should be pretty forwardable. Unfortunately, It sends status updates purely via broadcasting. in Subnet A do exist similar device + control software. Thus I am looking for a way datagramms broadcasted to 224.0.0.50:9898 in subnet B to re-appear in subnet A. May be with help of some tool. May be smcroute, may be udpxy, maybe igmproxy

Voronenko
  • 56
  • 7
  • Any multicast address in the `224.0.0.0/24` block is a link-local multicast ("_they MUST NOT be shipped as defaults in implementations_") that is not allowed to be forwarded. That particular multicast address, `224.0.0.50`, is in a range, `224.0.0.37`-`224.0.0.68` that is registered to someone else. You should be using an address in the Organization-Local Scope, `239.0.0.0/8`. You also need a tunnel that supports multicast, e.g. GRE, and you need to enable multicast routing (very different than unicast routing).. – Ron Maupin Nov 06 '18 at 12:19
  • See the _[IPv4 Multicast Address Space Registry](https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml)_: "_The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. Multicast routers should not forward any multicast datagram with destination addresses in this range, regardless of its TTL._" – Ron Maupin Nov 06 '18 at 12:22
  • @RonMaupin I realize that limitation - that's why I am looking either for workarounds or way to omit limitation / re-broadcast that. More powerful players (cisco, mikrotik) - have some workarounds. There are utilities, like udpxy - which transform multicast into stream for http clients (mostly video) I am also seeking for an advice, how can I implement kind of re-broadcasting tunnel, and hope - workaround do exist. http://troglobit.github.io/howto/multicast/ – Voronenko Nov 06 '18 at 13:15
  • You should use a correct multicast address that you are actually allowed to use, not one registered to someone else. Multicast, like other network standards, works quite well when you use it as designed. What you are trying to do is akin to trying to run ethernet on UTP for over 100 meters; it may work in some circumstances, but it is non-standard, and you should not whine if it doesn't work, just use the standard fiber optics for distances over 100 meters. Standards exist for a reason. – Ron Maupin Nov 06 '18 at 13:22
  • @RonMaupin That's a specific hardware device, which is not very chatty in ethernet terms (saying max 1-2 datagramms in 5 seconds), thus for sure should be pretty forwardable. It sends status updates via broadcasting. in Subnet A do exist similar device + control software. Thus I am looking for a way datagramms broadcasted to `224.0.0.50:9898` in subnet B to re-appear in subnet A. May be with help of some tool. May be https://github.com/troglobit/smcroute, may be udpxy, maybe igmproxy. Some tools do exist ^ – Voronenko Nov 06 '18 at 13:32
  • "_thus for sure should be pretty forwardable_" No, because it is using an address that is explicitly _not_ able to be forwarded. Also, addresses in that range will have a TTL of `1`, and they do not use IGMP. In any case, asking for a recommendation for a tool is off-topic here, and on all SE sites, except [softwarerecs.se] and [hardwarerecs.se]. – Ron Maupin Nov 06 '18 at 13:47
  • @RonMaupin ... still there are possible solutions: (a) patch specific packets to increase TTL saying with iptables or (b) setup a layer-2 connection to avoid layer-3 processing (c) use some tool to setup kind of multicast tunnel (hakish) etc so hope for someone to join thread. – Voronenko Nov 06 '18 at 14:21

2 Answers2

0

As I don't like to leave resolved questions unanswered, here is currently working solution

In subnet B I have installed openVPN server endpoint, configured as L2.

In subnet A, on a control host I have installed openvpn client, that connects to subnet B, assigned interface is tapz

20: tapz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether 0a:da:be:96:78:d9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.245/24 brd 192.168.1.255 scope global noprefixroute tapz
       valid_lft forever preferred_lft forever
    inet6 fe80::8da:beff:fe96:78d9/64 scope link 
       valid_lft forever preferred_lft forever

So now on a control host I have:

broadcasting from local device on physical ethernet enp5s0

sudo tcpdump -i enp5s0 -c 10 dst host 224.0.0.50 and port 9898 and multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:55:05.642963 IP lumi-gateway-v3_miio56591509.4321 > 224.0.0.50.9898: UDP, 
length 136

and now I also receive broadcasts from remote network device on tapz

sudo tcpdump -i tapz -c 10 dst host 224.0.0.50 and port 9898 and multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tapz, link-type EN10MB (Ethernet), capture size 262144 bytes
13:53:49.141751 IP 192.168.1.10.4321 > 224.0.0.50.9898: UDP, length 135

So far that it what I was looking for I am getting necessary datagrams on a VPN client. OpenVPN on remote side can be also optimized on filter of information forwarded for multicasts.

Voronenko
  • 56
  • 7
0

For those who come here, with the same question.

When you will have necessary multicast on tap0,

you can create bridge from, saying, eth0 and tap0

For notes of everyone interested, who would came here.

ip link add br0 type bridge
ip link set tap0 master br0
ip link set eth0 master br0

POC - both multicasts on single interface

sudo tcpdump -i br0 dst host 224.0.0.50 and port 9898
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:09:51.823632 IP 192.168.1.10.4321 > 224.0.0.50.9898: UDP, length 135
21:09:55.045138 IP 192.168.2.214.4321 > 224.0.0.50.9898: UDP, length 136
Voronenko
  • 56
  • 7