Multicast traffic should be at the L2 network layer, while wireguard (wg) is a L3 tunnel. I don't think you will be able to setup mcast traffic over wg. It'll be great if you can make it work tho.
I would suggest trying to setup an OpenVPN TAP tunnel, which is L2. That will work. Set up the TAP tunnel and bridge to the original IPTV LAN to your remote site. You will likely need to setup a separate bridge in your remote network to bridge the TAP tunnel.
Otherwise if you still want to stick to wg, tunnelling another GRETAP tunnel (which is also a L2 tunnel) over wg will also work, but that will shrink your tunnel MTU even further, and likely result in fragments being sent over the tunnel if your source packet is large. Be sure to setup GRETAP to allow fragmenting packets tho. You will also need a remote bridge setup for the GRETAP tunnel, just like OpenVPN TAP tunnel.
UDP 239.255.255.250 does not seem to traverse the VPN, assuming the tcpdump parameters are correct. See tcp dump parameters and sample results:
root@wg_site2site_b:~# tcpdump -n -i br-lan dst 239.255.255.250 and not igmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:51:32.396073 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:35.397121 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:38.398150 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:41.399640 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:44.401366 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:47.402282 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:50.403377 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:53.404394 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:56.405455 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
12:51:59.406517 IP 172.16.2.163.1049 > 239.255.255.250.8082: UDP, length 459
^C
no observations in wireguard:
root@wg_site2site_a:~# tcpdump -n -i wg_s2s_a dst 239.255.255.250 and not igmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg_s2s_a, link-type RAW (Raw IP), snapshot length 262144 bytes
^C
Any suggested next steps, assuming we target this UDP traffic first?
IGMP might, with some luck, traverse the VPN upstream, from B to A, because of igmpproxy, but 239.255.255.250 will not, in fact the multicast video will also not traverse the VPN downstream, from A to B, unless it gets multicast routed and forwarded. The exact method to build this multicast routing table might be with static commands
route add -net 224.0.0.0 netmask 240.0.0.0 dev wg | lan | wan
and setting their mc_forwarding in /proc
but typically multicast routing is dynamic and then it is maintained by some routing daemon (e.g. mrouted or pimd).
Hi all, See Site A and Site B existing routing tables:
root@wg_site2site_a:~# ip -4 route
default via 192.168.200.1 dev wan src 192.168.200.10 metric 1024
10.0.1.0/24 dev wg_s2s_a scope link src 10.0.1.1
10.0.1.2 dev wg_s2s_a scope link
10.0.1.3 dev wg_s2s_a scope link
172.16.1.0/24 dev br-lan scope link src 172.16.1.1
172.16.2.0/24 dev wg_s2s_a scope link
172.16.3.0/24 dev wg_s2s_a scope link
192.168.200.0/24 dev wan scope link metric 1024
224.0.0.0/4 dev wg_s2s_a scope link
239.0.0.0/8 dev wg_s2s_a scope link
root@wg_site2site_b:~# ip -4 route
default dev wg_s2s_b scope link
default via 10.0.0.1 dev wan src 10.0.0.34 metric 1024
10.0.0.0/24 dev wan scope link metric 1024
10.0.1.0/24 dev wg_s2s_b scope link src 10.0.1.2
10.0.1.1 dev wg_s2s_b scope link
70.53.109.43 via 10.0.0.1 dev wan metric 1024
172.16.1.0/24 dev wg_s2s_b scope link
172.16.2.0/24 dev br-lan scope link src 172.16.2.1
224.0.0.0/4 dev wg_s2s_b scope link
239.0.0.0/8 dev wg_s2s_b scope link
Suggests removal of igrpproxy, install of ipopt and smcroute, addition of smcroutes into the smcroute.conf and some custom firewall rules for TTL.
The smcroutes in my case, I assume would be Site B:
mgroup from wg_s2s_b group 239.255.255.250
mgroup from br-lan group 239.255.255.250
mroute from wg_s2s_b group 239.255.255.250 to br-lan
mroute from br-lan group 239.255.255.250 to wg_s2s_b
and Site A:
mgroup from wg_s2s_a group 239.255.255.250
mgroup from wan group 239.255.255.250
mroute from wg_s2s_a group 239.255.255.250 to wan
mroute from wan group 239.255.255.250 to wg_s2s_a
Seems worth trying ! ... a static multicast routing daemon.
I have no experience with that software ...
Note however that IGMP protocol packets may or may not be forwarded. It is a separate protocol and only meant to inform link local interest. So igmp proxy may still be needed.
smcroute seems to depend on physical interfaces. I was able to replicate multicast on the same br-lan interface however it would not replicate from br-lan onto the wg_s2s_b wireguard interface.
Other suggest? .. or do we now try an L2 tunnel as suggested by @quarky. I assume that does not depend on smcroute.
A L2 OpenVPN tap or any sort of L2 bridge over the Internet will works as if sender and receiver are on same subnet. Do you have sufficient control over the devices? Seems like ISP routers should then both provide same 192.168.c.0/24 towards the OpenWRT boxes. How that will go for DHCP (or IPv6) is not clear, it may need tweaking, maybe even ARP may need a twist. Then the OpenWRT LAN 172.16.c.0/24 subnets should perhaps also be equal, in fact, OpenWRT LAN and WAN should perhaps also bridge, because otherwise some sort of multicast forwarding and igmp proxy might be needed again. Basically the whole setup would become a giant L2 switch over the Internet. Not sure if that is desirable.
imgproxy is required at the edge device between two routed (with NAT) networks where upstream has the mcast source traffic. It's job is to proxy local IGMP requests to upstream mcast servers for mcast streams. mcast streams are handled at the L2 layer AFAIK.
When bridging two interfaces (i.e. TAP and bridge) together, they are logically one, so as long as the interfaces support mcast, it will be transparent.
When bridging network interfaces, they become essentially logically the same network. Using OpenVPN tap tunnel allows remote network to also join the same L2 network elsewhere, but because L2 is chatty, there will be non-stop traffic going in and out of the OpenVPN tunnel, due to all the L2 activities, like ARP, IGMP requests traffic, etc.
At the remote tunnel end, you will essentially have two separate networks and likely two or more bridges.
In the above L2 bridged scenario, smcroute should not be required.
Given I have found instructions for both L2 tunnels, L2TPv3 and OpenVPN/TAP, I will try the L2 bridge option. Do either of you have a preference? Based on the instruction set, is one more current and will have less issues with newer builds of openwrt? Or any other considerations?
@thema5on : I really admire your courage and I guess you might be one of the few persons ever to multicast this way over an OpenWRT VPN. Myself I worked 25 years as multicast developer and I must admit: it is not a simple protocol but an amazing (perhaps only) good one for things like, for example, live video and stock exchange information distribution. Getting multicast to work in any specific requirement is a challenge (beginning with understanding IGMP and multicast routing protocol aspects), certainly on DIY consumer equipment. But, I have a lot of confidence in open source software and its developers, especially OpenWRT, which/who never disappointed me to fulfill the, agreed, modest requirements ever I needed (like LAN multicasting DVB input with VLC or replacing provider gateway with OpenWRT including IP multicast TV). Again, each setup is a potential specific different challenge and I wish you good luck.
