Igmpproxy noworking

[the6thday]

@Ting:

But there are still questions from my side:
a) In 2.5 you say "And now you need to allow opts on the LAN and the IPTV interface:". Does this refer to the new rule described before or is this an additional rule?

b) Will the IPTV traffic now on my normal LAN interface which is connected to VLAN agnostic switch? I suppose this will not work. Is there a way to route the VLAN8 traffic to another hardware network interface on my pfsense box?

Thanks again!

a: you normally have only one rule on the iptv and the lan interface… (allows everything in any direction) so you have to enable allow opts in this rule...

b: i don't understand the question... the iptv traffic will be on your normal lan interface or whatever you set as downstream interface in the igmp config...
since you have a t-home connection i assume you are german so maybe you should send me a PM in german...

btw: i've updated the igmpproxy attachment in the last post with the new version that currently is included in pfsense 2.0 beta1

In pfsense 2.0 igmp is finally working as it should (igmp leave works)...
In pfsense 1.2.3 igmp leaves are not processed correctly (the same igmpproxy version was used to test this, its not igmpproxy's fault) which could cause problems if you switch channels very often in a short period of time, (but with a vdsl 50mbit connection thats currently not an issue for normal tv use...)

[xpapa]

@the6thday:

@Ting:

@the6thday: Maybe you could also share how you resolved this?

OK heres a litte tutorial for german T-Home IPTV

1)As far as i know the current igmp proxy package is still broken(at least the version number is still the same) @Eugene could you update the package to the latest version?

To resolve this issue i attached a working filter.inc file and a working igmpproxy to this post. !!!!!!!!!remove the .txt extension from the files!!!!!!!!
After you install the package(like you normally would…) you have to upload these two files via sftp to the pfsene box:

The igmpproxy binary can't load on nanobsd.

from shell:
[root@pfSense.local]/root(6): igmpproxy
ELF interpreter  not found
Abort

Thx from germany.

Edit: i have build the igmpproxy on virtual freebsd mashine and copy to pfsense, now is igmpproxy runing, are iptv is nothing going. the filter.inc build a firewall-ruleset with syntax errors on pfsense 1.2.3 (see in system-log).

[Clouseau]

@Eugene:

Howto
….....
Setup and configuration procedure.
1. Install igmpproxy package from System->Packages
2. Create a rule on LAN interface in Firewall->Rules
Pass Proto=IGMP Source=LANnet Destination=224.0.0.0/4 in AdvancedOptions check "This allows packets with ip options to pass …"
Save/Apply
It will allow igmpproxy to receive IGMP-reports on LAN.
3. Create a rule on WAN interface in Firewall->Rules
Pass Proto=UDP Destination=224.0.0.0/4
Save/Apply
It will allow you to receive multicast stream with any multicast IP.
4. Configure igmpproxy in Services->IGMP proxy. Make LAN Downstream and WAN Upstream interfaces.
5. Check that igmpproxy is running (green) in Status->Services.

90% probability that this is it - enjoy.
Optional steps:
6. Extraordinary case one - provider sends packets with source IP which does not belong to your network configured on Upstream-WAN (different from 1.1.1.0/24 on our diagram), for example packets have 3.4.5.42. We need to add this network in igmpproxy config for Upstream interface - add 3.4.5.0/24 in Networks for this interface.
7. Extraordinary case two - you have complex network connected to LAN and there is a router which is capable to route multicast packets and the device that wants to see IPTV is connected not directly to pfSense LAN segment but to other segment (after this router) having IP belonging let's say to 10.10.10.0/24. In this case we need to add this subnet in igmpproxy config for Downstream interface - add 10.10.10.0/24 in Networks. Probably you'll need to create a rule on LAN interface for this subnet as we did for LAN subnet in step 2. I depends how your router is configured.
8. Extraordinary case three - this is when you have extraordinary cases one and two at the same time.Complete both steps 6. and 7.
....

Thanks Eugene!
Now finally It works! Basic setup and configuration plus that I had your mentioned "Extraordinary case one". Your picture is good help for understanding of how IGMP works! This kind of basic tutorial is needed on help!

Thanks again Eugene !!  ;D

[jose1711]

hello, i read through the posts (and some articles on the web too) but still have problems with the setup i intend. what i'm about to do is forward multicast communication from eth0 to openVPN's tun0 device to another computer. it looks as follows:

/ISP providing multicast stream/ –- /my multicast-capable router/ -- /laptop A with linux on it, if: eth0 & tun0 / - - - /remote laptop B connected via tun0/

Laptop A:
eth0 192.168.1.104
tun0 172.16.0.1

Laptop B:
eth0 x.x.x.x
tun0 172.160.0.2

igmpproxy.conf on laptop A looks as follows:

phyint eth0 upstream  ratelimit 0  threshold 1
phyint tun0 downstream  ratelimit 0  threshold 1

there's no firewall in the way.

now i have a problem understanding whether i should do a NAT on laptop A using iptables (masquerade) and/or what should be the routing table on laptopA/B look like. can you please give me some assistance?

thank you very much in advance,

jose

[Eugene]

First of all it's not Linux but FreeBSD people here.
Then I am not sure that you can disseminate multicast stream into tunnel. But you should start with trying to determine wheter your Laptop A receive IGMP join request on tun interface. Without receiving it igmppoxy will never send multicast stream to your remote laptop.

[athurdent]

Hi,

could it be, that the IGMP proxy is somewhat broken in the latest pfSense 2.0 betas? I am trying to use it for T-Home IPTV, switching over from a working Linux Setup. Compared to the Linux IGMP proxy available at sourceforge, the pfSense one behaves odd. Sometimes it takes very long for it to join a new Multicast Source, sometimes it does not work at all.
I have never seen IGMP Packets like this on the WAN Side, they don't really make any sense to me. It seems it's trying to join 0.0.0.0?

18:57:59.010020 IP (tos 0xc0, ttl 1, id 58359, offset 0, flags [none], proto IGMP (2), length 40, options (RA))
    VLAN8-EXT-IP > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 0.0.0.0 is_ex { }]

My IPTV Provider relys on IGMP v3 an the WAN side, though v2 is used in the LAN. Sometimes IGMP proxy seems to stop using IGMP v3 on the WAN side completely and is not able to join v3 Multicasts. These are the only IGMP Packets trying to join the Multicast Source at that time:

18:58:05.012499 IP (tos 0xc0, ttl 1, id 32049, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    VLAN8-EXT-IP > 239.35.84.11: igmp v2 report 239.35.84.11

I have tried using the respective IGMP sysctl values to force pfSense to use IGMP v3 only, but that did not work.
Any thoughts?

Edit: After reading here: https://rcs.pfsense.org/projects/pfsense-tools/repos/Eugene-igmpproxy/comments I understand part of the IGMP Proxy behaviour. It would be nice if we had an option to choose the desired IGMP version as T-Home seems to get confused with the new v2-v3 logic.

[Eugene]

The first packet indeed looks weird.
Can you send me off-list:

• packet captures from downstream and upstream for the same time frame.
• what you see in System->Logs for the same time frame.
  Regarding 2.0 - several people reported that igmpproxy worked for 2.0 though I've never tested it.