(solved)Multicast packets cannot be forwarded to lan from wan

Installing and Using OpenWrt Network and Wireless Configuration
#1

I have 2 PCs which are linked by cables directly .PC1 address:10.10.10.1 , PC2 address:192.168.3.1 . Their firewalls have been shut down. PC1 is a stream server , sending multicast video to 239.1.1.1:1234 with VLC media player .PC2 could recieve and watch the video perfectly .

Now I have a router between PC1 and PC2 . The router is running LEDE 17.01.
Router's wan port is linked to PC1 ,lan port is linked to PC2.Router's lan IP is 192.168.1.1/24
And I changed the IP of PC2 to DHCP client mode.
According to this article : https://wiki.openwrt.org/doc/howto/udp_multicast
Install igmpproxy , /etc/config/igmpproxy:

config igmpproxy
        option quickleave 1

config phyint
        option network wan
        option direction upstream
        list altnet 0.0.0.0/0

config phyint
        option network lan
        option direction downstream

Enable IGMP snooping on LAN interface:

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option igmp_snooping '1'

Set firewall rules:

config rule
        option src      wan
        option proto    igmp
        option target   ACCEPT
config rule
        option src      wan
        option proto    udp
        option dest     lan
        option dest_ip  224.0.0.0/4
        option target   ACCEPT
        option family   ipv4

Force IGMP version:
Add to "net.ipv4.conf.all.force_igmp_version=2" to /etc/sysctl.conf

After all these things done and igmproxy running, I cannot watch the stream video.At first I thought it was about IP address , then I changed IP of PC1 and Routers'wan to a same subnet , the issue still.
Using "ifconfig" to see RX/TX bytes count of eth0.2 (wan) ,it was confirmed that the stream was already recieved by the router. But don't know why the stream was not forwarded to lan?

[Solved] Multicast and "youview" IPTV box
Multicast not working via wireless
#2

I traced the multicasting packets from wan , and I found that they've just be dropped after through table NAT chain PREROUTING.Normally they should keep moving to table FILTER chain FORWARD, but they didn't.
I believed it was caused by the defect of Openwrt, nothing to do about how I configure.I think there are some way to figure it out ,for example , pimd should fix that .And also remaking Openwrt to add multicast forwarding feature could work it out.

#3

REMOVE THIS LINE AND TEST! IGMP traffic would be an INPUT rule, as the router is a proxy.

Works for me with 17.01.4, using an INPUT instead of a FORWARD rule.

#4

do you got this working?

is this rule even needed?

> config rule
>         option src      wan
>         option proto    igmp
>         option target   ACCEPT

Can someone explain what this rule exactly does?
Hmm yeah igmp is used to join a multicast group.
So client tells the router, i want to join this group.
I use smcroute to route some ssdp traffic between 2 vlans and it does work with out this rule.
(one vlan is "isolated" only can reach some services on the router and no forward to the other vlan)
why?

What lleachii wrote, makes sense.
I guess a forward rule is only useful if you use a multicast routing daemon like pimd or smcroute.

if you only use that one multicast address and only2 pc, i guess that should also work?:

config rule
        option src      wan
        option proto    udp
        option dest_ip  239.1.1.0/31
        option target   ACCEPT
        option family   ipv4

config igmpproxy
        option quickleave 1

config phyint
        option network wan
        option direction upstream
        list altnet 239.1.1.0/31

config phyint
        option network lan
        option direction downstream
        list altnet 192.168.1.0/24

Im not sure if 0.0.0.0/0 is an valid option.
And i also dont know if 239.1.1.0/31 does work x)
Maybe use 224.0.0.0/4 instead.

and for the network option....
maybe you have to use br-lan instead.
and for your wan interface, maybe use the physical interface name. something eth0 or eth1.
you can check this with ifconfig or in the luci gui in the "physical settings" page of your interface under network --> interfaces

Setting igmp_snooping '1' on the bridge is only needed, if you have bridged multiple interfaces together and want that multicast traffic get passed through all bridged interfaces.
Something like your lan switch and wlan.
For exmaple with igmp_snooping 0 and multicast traffic on the lan switch,
the multicast traffic would not get passed through to your wlan clients and vice versa.
With igmp_snooping 1 the traffic gets also passed to the wlan clients and vice versa.
But im also not sure about this x)

#5

Thanks for your advice! I think what you said makes sense!Btw,Can you describe your network?

1 Like
#6

Thank you for your advice!
I modified /etc/config/igmpproxy following your instruction , igmpproxy cannot start successfully and there was no any process of it when using 'ps' .

#7

can you post your new config?
igmpproxy.conf and your network config /etc/config/network please

did you try the the possibilities?

hmm when i look at the man page of igmpproxy.
i think altnet for the downstream interface is not needed.

#8

My WAN is a Multicast network, my LAN must receive those multicasts, I have the same igmpproxy conf file as you, and a RAW ACCEPT firewall rule (I'll show it, if it helps below). I made no syscrtl changes.

Make sure that you have enabled igmpproxy system process to run, if it is not already enabled.

No, such a rule isn't needed on WAN, you only need to ALLOW INPUT of the multicast traffic itself. The LAN interface does need to receive IGMP (but the firewall is set to ALLOW by default).

It is valid, especially if you don't know the source IP of the multicast traffic. You must specify the SRC_IP by CIDR notation allowed to send multicast traffic - if the traffic will come from a SRC not equal to the subnet configured on the WAN interface.

THIS IS INCORRECT!!! NO LEGITIMATE PACKET ON THE INTERNET HAS THIS RANGE AS A SRC ADDRESS!!! THIS IP RANGE ARE ONLY VALID AS DESTINATION IPs ONLY

config igmpproxy
option quickleave 1

config phyint
option network wan
option direction upstream
list altnet 0.0.0.0/0

config phyint lan
option network lan
option direction downstream

MAKE SURE YOU FIX YOUR LAN IGMPPROXY RULE!!!

iptables -t raw -A PREROUTING -i eth0.2 -d 224.0.0.0/4 -m ttl --ttl-lt <TTL_here> -j ACCEPT
(NOTE: I only needed a RAW rule because I block some malicious traffic by TTL)

This is my previous rule:

config rule
option target 'ACCEPT'
option src 'wan'
option family 'ipv4'
option proto 'udp'
option dest 'lan'
option dest_ip '224.0.0.0/4'
option name 'Allow-UDP_Multicast_In'

#9

0.0.0.0/0 is only valid because openwrt includes some patch for this.

THIS IS INCORRECT!!! NO LEGITIMATE PACKET ON THE INTERNET HAS THIS RANGE AS A SRC ADDRESS!!! THIS IP RANGE ARE ONLY VALID AS DESTINATION IPs ONLY

This is true indeed. No isp would route multicast from their end customers all over the internet.

But his wan interface is not connected to the internet.
And some ISP use this range to deliver their IPTV services. (through vlan tagging though)
I think they use:
239.0.0.0/8
232.0.0.0/8
So each IP on this net represents 1 tv channel.
I made they advise to use 224.0.0.0/4 cause this wil cover the entire multicast range and makes debugging easier.

#10

THAT IS ALSO INCORRECT!!! I think you have the flow of multicast backwards. See the manual for igmpproxy config file, from another distro!: http://manpages.ubuntu.com/manpages/bionic/man5/igmpproxy.conf.5.html

In any case, my wokring config is displayed.

These IP's would be used to REQUEST and PROVIDE the traffic, meaning, in all cases THESE WOULD BE DESTINATION IP ADDRESSES.

  • In LAN, they would go to IGMPPROXY in OpenWRT - DST in 224.0.0.0/4
  • They then are proxied to the upstream router
  • The ISP then subscribes the OpenWRT to the IP in 224.0.0.0/4
  • The traffic is sent to a destination in 224.0.0.0/4 to the interfaces subsctibed (i.e. the OpenWRT)
  • The OpenWRT receives this traffic, DST IP in 224.0.0.0/4
  • The OpenWRT proxies it to LAN, DST IP in 224.0.0.0/4
  • NO SRC IP IS KNOWN
#11

I get your point that 0.0.0.0/0 should represent a wildcard to cover all networks.
Where in the doc it states that 0.0.0.0 is valid?
Also i think it is not an good idea to blindly accept all multicast traffic.
But in his case, where everything is local only, it should be okay.

#12

Multicast is always 'local,' 224.0.0.0/4’ is not a valid RIR-issued SRC IP, nor a valid DST, it is only used for MULTICAST.

In fact, I HAVE A BOGON FIREWALL RULE ON MY WAN, IT BLOCKS SRC IPs OF 224.0.0.0/4.

#13

are you high?
did you even read my posts? To get the point?

#14

I did read your posts, and I helped provide the OP the correct config. You continue to provide misguided and incorrect information about multicast.

See: https://tools.ietf.org/html/rfc5771

8.1. Assignment Guidelines

Because the SSM model essentially makes the entire multicast address
space local to the host, no IANA assignment policy is required.
Note, however, that while no additional IANA assignment is required,
addresses in the Source-Specific Multicast Block are explicitly for
use by SSM and MUST NOT be used for other purposes.

I understand the OP has a server that isn't on the Internet, but the same model applies, as it's the same technology. YOUR IMMEDIATELY UPSTREAM ROUTER IS LOCAL, THAT'S WHY IT'S IN THE SAME SUBNET!

#15

Hmm now im not sure quite sure anymore.

why is there an altnet option then?

Defines alternate sources for multicasting and IGMP data. The
network address must be on the following format 'a.b.c.d/n'. By
default the router will accept data from sources on the same
network as configured on an interface. If the multicast source
lies on a remote network, one must define from where traffic
should be accepted.

?

Maybe no altnet option is needed in this case.

#16

I explained this:

And yes, since the SRC subnet in this case is known and local, it can safely be omitted. I would suggest adding the WAN subnet or server /32, though.

#17

Hmm
Sorry but i dont get this?
You say that no src ip is known.
But then this entire altnet thing makes no sense?

0.0.0.0/0 mask

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/igmpproxy/patches/200-allow_wildcard_addr.patch;h=0dd772007a4715ef74da2c99e93b7741d0879953;hb=refs/heads/lede-17.01

#18

It does make sence in an ISP's Autonomous System, though...where they can send the packet from any SRC IP they control...

#19

So the src ip is known then isnt it?

1 Like
#20

Yes...in the OP's case...but the OP asked about MY config.