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

I rather know have the feeling that all igmp proxy guides i found online are wrong.
They all specify the multicast ip (-range) as altnet.
But this is not needed right?

altnet is only useful for example:
if someone has network 192.168.0.0/16 and wants to receive multicast traffic from a different network
like 192.172.0.0/16 right?
Otherwise this makes no sense to me?¿

And when i read through this igmp/multicast thing.
I think the allow proto igmp rule is needed?
How i understand this works is, every router, capable switch, client etc, can join a igmp group.
And then? Is the multicast traffic only delivered to members of the group?
Would make sense ?¿
But makes me wonder why multicast works on my setup without this rule.
Hmm...
Can you elaborate this more please?

Did you see my last post about the wildcard patch?

It is not needed, and such a config is incorrect. The received traffic would have a SRC IP of the sending server, the destination IP is the mulitcast address.

Correct...somewhat. Remember, multicast is local, we're using a proxy here. The IGMPPROXY manual states that you need to specify an altnet when the traffic (SRC IP) will come from a subnet NOT EQUAL to the interface. So in your example - if WAN was 192.168.0.0/16 and the multicast was coming from 192.172.0.0/16, the altnet would be 192.172.0.0/16. The LAN subnet is irrelevant - it's being proxied.

It's needed only if you block INPUT ON LAN. See the photograph here: https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol

Yes...and my coding is rusty...it appears validate CIDR ranges from: /0 to /32...and assign the correct subnetmask...what about this "patch" concerns you???

Okay. thank you.
So why do most igmpproxy guides specify the multicast ip(-range) as altnet?
This is wrong or?

About the patch.
As i said before i was not sure if 0.0.0.0/0 is a valid option.
As the patch shows this only works because openwrt has this patched in.
I guess with default igmp proxy this will not work.

Maybe you can explain this behavior about my setup please x)

I have the following setup:
Two networks.
First network is green zone. Has full access to other zones and to the router.
Second network is the red zone. Restricted forwading to the green zone and to the router.
Only explicit services are allowed.
In the green zone i have a dlna server running.
The red zone has access to the dlna server.

As far as i know dlna/ssdp uses multicast.
I set up smcroute to route the multicast traffic between the networks.
I created the following firewalls rules:

  1. Allow input rule. igmp to the router from redzone (works also without but with this it works reliable)
  2. Allow forward of dlna multicast to the green zone from the red zone.
    239.255.255.250 port 1900 udp
  3. also a third rule to allow the direct connection to the dlna server after discovery.
    but this is not important now.

Everything works as expected.

But my firewall log shows the following log:

REJECT(src redzone)IN=br-redzone OUT= MAC= SRC="ip from dlna server from green zone" DST=239.255.255.250 LEN=122 TOS=0x00 PREC=0x00 TTL=2 ID=27142 PROTO=UDP SPT=59744 DPT=1900 LEN=102

Why is that?
How can the src ip be from the green zone and the src zone be the redzone.
When i create a fourth rule.
an input rule to allow 239.255.255.250 port 1900 from the red zone to the router this message disappears.

I wouldn't know why. I've never seen a guide showing this incorrect information.

See: https://github.com/Distrotech/igmpproxy/blob/master/igmpproxy.conf
and: https://openwrt.org/docs/user-guide/services/udp_multicast
and: http://manpages.ubuntu.com/manpages/bionic/man5/igmpproxy.conf.5.html
and: https://manpages.debian.org/testing/igmpproxy/igmpproxy.conf.5.en.html

Not sure, I know they broadcast to those IPs.

It should, that's the DST IP. I've noted multiple times, you have to have a rule for the received traffic:

Now regarding your firewall log:

I don't see a SRC IP. I see a destination IP. NOR DO I SEE THE GREENZONE. This appears to be traffic from your WAN that you REJECTED. It appears you FINALLY made the correct rule to allow your received multicast traffic.

I edited my post above

i wrote the text in SRC= in "<>" but that made the text disappear

what makes me wonder is it says src redzone and the src ip is from the green zone.
?¿

i run this setup for quite some time now. but that message always made me wonder.

What device is that, as that doesn't appear to be an OpenWRT log...?

Perhaps you have a misconfigured server?

And do you have an IGMP Proxy enabled on this device?

this is with openwrt/lede. compiled from latest git source.

with misconfigured server you mean the dlna server?
But it works x)

i dont use igmp proxy. i use a static multicast routing daemon (smcroute)

When i exchange the forward rule for an input rule. it doesnt work anymore.
Which does make sense since smcroute is an actual routing daemon and not an proxy?
The question is, is the input rule for 239.255.255.250 to the router needed, so the clients can join the igmp group on the router properly?
//edit
okay. ip mroute shows that the clients joined the igmp properly. so this is also not the case.

This thread is regarding IGMPPROXY.

Of course your stops working, as smcroute is a routing software, not a proxy.

That's because your device is trying to route the packet to the other interface.

Correct.

Yes, sorry for hijacking this thread.

Can you elaborate this more please?

REJECT(src redzone)IN=br-redzone OUT= MAC= SRC= DST=239.255.255.250 LEN=122 TOS=0x00 PREC=0x00 TTL=2 ID=27142 PROTO=UDP SPT=59744 DPT=1900 LEN=102

When i ignore the first part (src redzone)
And only look at
IN=br-redzone SRC="ip from dlna server from greenzone"
okay, could make sense. but green zone can forward all traffic it wants to the red zone.
So i dont know.
Also how an input rule from redzone to the router itself fixed this?¿

@shm0...I think you're trying to make it more difficult.

  • You're running a software named smcroute
  • A packet is received on LAN
  • SMCROUTE RECEIVED THIS PACKET
  • SMCROUTE (NOT THE KERNEL) FORWARDS THE PACKET
  • YOUR KENERL'S FIREWALL BLOCKS THE PACKET
  • You need a firewall rule.

Perhaps smcroute is misconfigured? Please make a new thread.

actually smcroute directly manipulates the kernel multicast tables.
so the kernel does the for forwarding stuff.
Yes the firewall blocks it. but it makes no sense to me, from the point of view -> IN and SRC.

maybe i will make a thread about this. could also be some bug in the bridge code or something else.

Hey,guys!I am tired but still working on it!
I've tried all kinds of configuration of /etc/config/igmpproxy and found the original one which according to Openwrt Official could works good(could tell from debug message).

igmpproxy.log

root@LEDE:~# igmpproxy -dvvvv /var/etc/igmpproxy.conf
Searching for config file at '/var/etc/igmpproxy.conf'
Config: Quick leave mode enabled.
Config: Got a phyint token.
Config: IF: Config for interface eth0.2.
Config: IF: Got upstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 0.0.0.0/0.
Config: IF: Altnet: Parsed altnet to default.
IF name : eth0.2
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 1
Allowednet ptr : 26ef0
Config: Got a phyint token.
Config: IF: Config for interface br-lan.
Config: IF: Got downstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
IF name : br-lan
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 2
Allowednet ptr : 0
buildIfVc: Interface lo Addr: 127.0.0.1, Flags: 0x0049, Network: 127/8
buildIfVc: Interface br-lan Addr: 192.168.1.1, Flags: 0x1043, Network: 192.168.1/24
buildIfVc: Interface eth0.2 Addr: 192.168.8.1, Flags: 0x1043, Network: 192.168.8/24
Found config for br-lan
Found config for eth0.2
adding VIF, Ix 0 Fl 0x0 IP 0x0101a8c0 br-lan, Threshold: 1, Ratelimit: 0
Network for [br-lan] : 192.168.1/24
adding VIF, Ix 1 Fl 0x0 IP 0x0108a8c0 eth0.2, Threshold: 1, Ratelimit: 0
Network for [eth0.2] : 192.168.8/24
Network for [eth0.2] : default
Got 262144 byte buffer size in 0 iterations
Joining all-routers group 224.0.0.2 on vif 192.168.1.1
joinMcGroup: 224.0.0.2 on br-lan
SENT Membership query from 192.168.1.1 to 224.0.0.1
Sent membership query from 192.168.1.1 to 224.0.0.1. Delay: 10
Created timeout 1 (#0) - delay 10 secs
(Id:1, Time:10)
Created timeout 2 (#1) - delay 21 secs
(Id:1, Time:10)
(Id:2, Time:21)
RECV Membership query from 192.168.1.1 to 224.0.0.1
Route activate request from 10.10.10.1 to 239.1.1.1
No table entry for 239.1.1.1 [From: 10.10.10.1]. Inserting route.
No existing route for 239.1.1.1. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 239.1.1.1 on VIF #-1
No downstream listeners for group 239.1.1.1. No join sent.

Current routing table (Insert Route):

#0: Src: 0.0.0.0, Dst: 239.1.1.1, Age:2, St: I, OutVifs: 0x00000000

Current routing table (Activate Route):

#0: Src: 10.10.10.1, Dst: 239.1.1.1, Age:2, St: A, OutVifs: 0x00000000

RECV V2 member report from 192.168.1.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.1.121 to 239.1.1.1
Should insert group 239.1.1.1 (from: 192.168.1.121) to route table. Vif Ix : 0
Updated route entry for 239.1.1.1 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 10.10.10.1 -> 239.1.1.1, InpVIf: 1
Joining group 239.1.1.1 upstream on IF address 192.168.8.1
joinMcGroup: 239.1.1.1 on eth0.2

Current routing table (Insert Route):

#0: Src: 10.10.10.1, Dst: 239.1.1.1, Age:2, St: A, OutVifs: 0x00000001

RECV V2 member report from 192.168.8.1 to 239.1.1.1
The IGMP message was from myself. Ignoring.
Route activation request from 192.168.8.1 for 239.1.1.1 is from myself. Ignoring.
RECV V2 member report from 192.168.1.121 to 239.1.1.1
Should insert group 239.1.1.1 (from: 192.168.1.121) to route table. Vif Ix : 0
Updated route entry for 239.1.1.1 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 10.10.10.1 -> 239.1.1.1, InpVIf: 1

Current routing table (Insert Route):

#0: Src: 10.10.10.1, Dst: 239.1.1.1, Age:2, St: A, OutVifs: 0x00000001

RECV V2 member report from 192.168.1.121 to 239.255.255.250
Should insert group 239.255.255.250 (from: 192.168.1.121) to route table. Vif Ix : 0
No existing route for 239.255.255.250. Create new.
Found existing routes. Find insert location.
Inserting after route 239.1.1.1
Inserted route table entry for 239.255.255.250 on VIF #0
Joining group 239.255.255.250 upstream on IF address 192.168.8.1
joinMcGroup: 239.255.255.250 on eth0.2

Current routing table (Insert Route):

#0: Src: 10.10.10.1, Dst: 239.1.1.1, Age:2, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001

RECV V2 member report from 192.168.8.1 to 239.255.255.250
The IGMP message was from myself. Ignoring.
Route activation request from 192.168.8.1 for 239.255.255.250 is from myself. Ignoring.
RECV V2 member report from 192.168.8.1 to 239.1.1.1
The IGMP message was from myself. Ignoring.
About to call timeout 1 (#0)
Aging routes in table.

Current routing table (Age active routes):

#0: Src: 10.10.10.1, Dst: 239.1.1.1, Age:2, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001

RECV V2 member report from 192.168.8.1 to 239.1.1.1
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.8.1 to 239.255.255.250
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.8.1 to 239.255.255.250
The IGMP message was from myself. Ignoring.
Route activation request from 192.168.8.1 for 239.255.255.250 is from myself. Ignoring.
^Cselect() failure; Errno(4): Interrupted system call
Got a interupt signal. Exiting.
clean handler called
Removing route entry for 239.1.1.1
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Removing MFC: 10.10.10.1 -> 239.1.1.1, InpVIf: 1
Leaving group 239.1.1.1 upstream on IF address 192.168.8.1
leaveMcGroup: 239.1.1.1 on eth0.2
Removing route entry for 239.255.255.250
Route is not active. No kernel updates done.
Leaving group 239.255.255.250 upstream on IF address 192.168.8.1
leaveMcGroup: 239.255.255.250 on eth0.2
All routes removed. Routing table is empty.
Shutdown complete....

It looked work normally.It's not a big deal about 'list altnet' , just means the src ip could be anywhere as long as the dest ip is in multicasting group, it's ok.
What i focuse on is the traffic seems to be stucked when it went to INPUT/FORWARD from table NAT . Because the traffic counts in table NAT but doesn't count in tabel FILTER . The rules we add to /etc/config/firewall are in table FILTER , so they doesn't work.There is a judging between NAT and FILTER according to the Routing Table to decide how to deal with a packet ,Input or forward.Apparently to a multicast packet , it shall be forwarded. There must be something wrong in this process.

WHAT!?!? The rule exists where you put them (this is why I said remove the incorrect 'option dest lan' line)...perhaps you should use the Web GUI instead.

First I should note:

  • As I said, I have multicast working on 17.01.4, using the configs I posted above
  • I suggested you fix the LAN rule in IGMPPROXY config file
  • I suggest that you ensure the process is enabled to run on boot
  • The firewall rule I posted had "network2" instead of "lan," please fix that if you copied and pasted
  • In this case...the NAT table would be for FORWARD, FILTER for INPUT. This is simply how the IPTABLES named them, OpenWRT uses the terms INPUT AND FORWARD RULES. AND YOU NEED AN INPUT RULE, AS I NOTED ABOVE.

@cayxxx

can you post your network config /etc/config/network please

yes. what i mean is that 'the' rules ,according from openwrt official article . I also tried 'iptables -t nat -A prerouting_wan_rule -d 224.0.0.0/4 -p udp -j ACCEPT' ,but the traffic still cannot be forwarded.

This is incorrect!!! It should not be a forward rule!!! It should be an INPUT rule...IGMPPROXY IS THE SOFTWARE RECEIVING THE DATA, THEREFORE IT'S AN INPUT RULE - BECAUSE THIS SOFTWARE RUNS ON THE ROUTER.

If you typed the rule in command line, it should read:

iptables -t filter -I INPUT -i eth0.2 -p udp -d 224.0.0.0/4 -j ACCEPT

(UPDATE: I also noted that I didn't have to make edits to sysctrl)

still the same

Summary

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

but igmpproxy isn't running directly with this file .It would create a new one '/var/etc/igmpproxy.conf' according to '/etc/config/igmpproxy'

Summary

quickleave

phyint eth0.2 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/0

phyint br-lan downstream ratelimit 0 threshold 1

br-lan 192.168.1.1 eth0.2 192.168.8.1

I think you missed something I said twice...

You have:

I ASKED YOU TO PUT:

If you don't wanna fix it (and firewall rules), it probably won't work...

The file name is /etc/config/igmpproxy This is the file you should be editing...let's not get into the /var directory today in this thread...

my /var/etc/igmpproxy.conf

quickleave

phyint eth0.2 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/0

phyint br-lan downstream ratelimit 0 threshold 1

(It appears identical, I'd make sure the firewall rule is working).

8105 284.94 KB ACCEPT all eth0.2 * 0.0.0.0/0 224.0.0.0/4 TTL match TTL < <TTL_HERE>

oh sorry~~my english is quite poor ,sometimes may miss something..
now /etc/config/igmpproxy
config igmpproxy
option quickleave 1

option verbose [0-2]

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

config phyint lan
option network lan
option direction downstream

and /etc/config/firewall
config rule
option src 'wan'
option dest_ip '224.0.0.0/4'
option proto 'udp'
option family 'ipv4'
option target 'ACCEPT'
igmpproxy can run automatically when booting.but I still could not watch the video... :frowning:
is there anything else I miss .

I guess wan and lan for you phyint and network options are wrong.
you have to use the real interface name.
read my post above how to get this info.
But im not sure x)
also you didnt set the firewall rules according to lleachii recommendations.

//edit
hmm
is option network openwrt specific?
i guess here you can use the openwrt created alias.