0

I have a host with two Docker containers (with NET_ADMIN capability):

  • backend with an interface eth0 (172.16.7.3)
  • openvpn-server with interfaces eth0 (172.16.7.2) and tun0 (10.8.0.1), running an OpenVPN server (tun mode)

There is an OpenVPN client on another machine openvpn-client with interface tun0 (10.8.0.2). The VPN is working.

Additional route setup:

  • backend has routes 10.8.0.0/24 via 172.16.7.2 and 224.0.0.0/4 via eth0.
  • openvpn-server has routes 10.8.0.0/24 dev tun0 and 224.0.0.0/4 dev tun0.

backend can successfully ping openvpn-client (routed through openvpn-server): ping 10.8.0.2 works like a charm.

Observations:

When I run ping -t3 239.1.2.3 on openvpn-server, those go through the VPN tunnel, and I can see the ICMP packets arriving on openvpn-client (with tcpdump -i tun0 net 224.0.0.0/4 on openvpn-client).

Also, when I run ping -t3 239.1.2.3 on backend, those exit through that host's eth0 and enter on openvpn-server's eth0. I can see them on openvpn-server using tcpdump -i eth0 net 224.0.0.0/4.

Problem:

I would like to be able to run ping -t3 239.1.2.3 on backend and have the pings forwarded to openvpn-client, just as if 10.8.0.2 had been pinged. (The final goal is to multicast UDP packets from backend to all VPN clients.)

My attempt:

smcroute -d -n -j eth0 239.1.2.3 -a eth0 172.16.7.3 239.1.2.3 tun0

I thought this would set up the multicast route, but actually it does nothing. I cannot see outgoing ICMP packets on openvpn-server's tun0. -- What's wrong?

I also tried setting up pimd on any two pairs of the three hosts, and also on all three of them. As a result, I could do an iperf benchmark (as suggested here) between backend and openvpn-server, and also between openvpn-server and openvpn-client, but not between backend and openvpn-client. It looks like the forwarding/routing across the hop in the middle somehow does not work. (I had set the TTL to 5, so that should not be the issue.)

I am happy to provide more details if needed (such as ip route list output), but did not want to clutter the question unnecessarily.

Peter Thomassen
  • 169
  • 1
  • 6
  • See [this answer](https://serverfault.com/a/814296/324849). – Ron Maupin Jan 23 '20 at 16:13
  • I know that I need to set up an IGMP daemon on the hosts, and as I said above, I already did that. What else is required? I am not sure how to tell openvpn-client which multicast group to join... – Peter Thomassen Jan 23 '20 at 16:21
  • By the way, multicast addresses in the `225.0.0.0/8` range are RESERVED and not to be use. You probably want to use multicast addressing in the Organization-Local scope of `239.0.0.0/8`. Also, multicast groups in the `224.0.0.0/24` range are Link-Local multicasts that cannot be forwarded to a different network. See the _[IPv4 Multicast Address Space Registry](https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml)_. – Ron Maupin Jan 23 '20 at 16:22
  • Not all tunneling protocols even support multicast. GRE does, but things like SSH do not. – Ron Maupin Jan 23 '20 at 16:23
  • In any case, you do not have a multicast routing protocol, like PIM, configured. – Ron Maupin Jan 23 '20 at 16:23
  • Ok, let's use 239.1.2.3. I have pimd running on all three hosts, with default config. Is that not sufficient? -- I suppose the routing host in the middle needs to know that the destination host would like to join 239.1.2.3. How do I configure that? Maybe that's the missing piece. – Peter Thomassen Jan 23 '20 at 16:28
  • That would be PIM between the two servers of the tunnel, assuming the tunnel even supports multicast, which I have my doubts about. Most tunneling protocols do not support multicast. – Ron Maupin Jan 23 '20 at 16:30
  • I am not sure I'm following. Would you mind having a chat? https://chat.stackexchange.com/rooms/103616/1000126-set-up-multicast-route-across-a-middle-hop – Peter Thomassen Jan 23 '20 at 16:36

1 Answers1

0

The issue was that I did not make sure that openvpn-client joins the multicast group, so the router in the middle (openvpn-server) did not know that it was supposed to send multicast traffic there.

The following setup suffices:

  • On backend, set up the route 224.0.0.0/4 via 172.16.7.2 -- this makes sure that traffic for the multicast IP range is sent off to openvpn-server (you may want to specify a narrower range)
  • Install and start pimd on openvpn-server

  • Make sure that openvpn-client announces that it wants to join the multicast group. To that end, an IGMP daemon such as scmroute is needed. This works in two steps only:

    1. smcroute -d -- start the daemon
    2. smcroute -j tun0 239.1.2.3 -- to join the group

    Note that it is not possible to run both in one command (smcroute -d -j tun0 ...).

This way, everything works as expected.

Note: If you start the pimd or smcroute daemons before OpenVPN has configured tun0, things won't work. It is best to start them using OpenVPN's route-up hook.

Peter Thomassen
  • 169
  • 1
  • 6
  • That's what I was trying to explain. Multicast routing is all about preventing multicast from going where it is not wanted. :) You must specifically say that you want it before it will come to you. I'm glad you got it to work. – Ron Maupin Jan 24 '20 at 19:59
  • Well yes, I knew that as an abstract fact. My question was how to do that. Thanks for your help though! – Peter Thomassen Jan 27 '20 at 12:16