[SOLVED] IGMP Proxy does not work any more after update to OPNsense 16.1.18

[segfault]

Some further information and questions. By looking at the igmpproxy opnsense port, it seems we're using the official v0.1 release https://github.com/opnsense/ports/blob/master/net/igmpproxy/distinfo.

Digging through the code I figured that the disabled interface state is completely ignored and that the default state is downstream. This seems to have been fixed after the v0.1 release in this commit: https://github.com/pali/igmpproxy/commit/85e240727305b156097ee7aa0f0c4473a136291f

[franco]

Anyone feeling lucky?

AMD64 test package with a promising fix that was incorporated in pfSense dev recently, but still not in FreeBSD:

# pkg add -f https://pkg.opnsense.org/snapshots/igmpproxy-0.1_3,1.txz


Cheers,
Franco

[ch3p]

Quick Question:

Is this already fixed in the current version 17.1? This would be currently the only reason to switch from pfSense to your OPNsense. I've already read, I can't import my pfSense config so this would end up in 2 or 3 hours of work.

pfSense was moving it on the roadmap from version to version and the bug with the VLANs was reported 10 months ago. But I need a working solution for my IPTV.


Thanks,
ch3p

[franco]

The patch is in since 17.1, and we haven't heard a complaint since. Sadly no positive feedback as well.


Cheers,
Franco

[Mech]

The patch is in since 17.1, and we haven't heard a complaint since. Sadly no positive feedback as well.


Cheers,
Franco

Hi Franco,

I'm on 17.1 i386 and don't seem to have the new package, if I do "pkg search igmpproxy" all I have available and installed is igmpproxy-0.1_2,1 and v3,1 isn't there?

Can you help?

Thanks

[franco]

Hi Mech,

We didn't bump the port revision. An option was added instead:

# pkg info igmpproxy | grep VLANFIX


Cheers,
Franco

[Mech]

Hi Mech,

We didn't bump the port revision. An option was added instead:

# pkg info igmpproxy | grep VLANFIX


Cheers,
Franco

Thanks for that Franco,

It turns out my issue was not that IGMP proxy wasn't working, but that it was ignoring the IGMP packets because they came back on the wrong interface.  The root cause was my switch which is quite old doing IGMP snooping, but instead of returning the IGMP on the VLAN it came from, it was putting it on the bare interface instead.  Incorrect logic, but it is over 10 years old now.

"sudo /usr/local/sbin/igmpproxy -d -v /usr/local/etc/igmpproxy.conf" was very useful in determining this for anyone who may read this thread in the future.  That turns on debugging and verbosity.  Make sure to stop igmpproxy in the WebGUI first.

[franco]

Alright, cheers for the explanation on how to debug and happy that this works as expected now. Marking it solved.

[Mech]

It's also worth noting this:

If you have more than one interface in a subnet, then BOTH of those interfaces have to be downstream interfaces in igmpproxy for it to not say "Membership report was recieved on a disabled interface. Ignoring." and "The found if for XXX.XXX.XXX.XXX was not downstream. Ignoring leave request."  I don't know if that is intentional but it seems to only check the first match, not all matches.  Interesting behaviour worth knowing about anyway.  In my case I had a dedicated management interface on the same subnet as my LAN, I just moved this to its own subnet and that cured that issue.

Still solved. I just want to give as much detail as possible for anyone else.