1

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
  • 219

1 Answers1

1

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
  • 219