IGMP Proxy is broken?

Andrew453

Hi

I can see that the current build of pfSense incorporates IGMPProxy 0.1 beta2, Build 150319.

Looking here, that's the first beta release - there's a much later stable release (0.1): http://sourceforge.net/projects/igmpproxy/files/igmpproxy/

I'm having trouble getting IPTV to work - I think it's all set up ok, and it works for a few minutes, then the screen goes blank. Looking at the debug logs, it looks like it's because igmpproxy has crashed and the process terminated:

May 2 02:11:54 kernel: pid 27311 (igmpproxy), uid 0: exited on signal 11 (core dumped)
May 2 02:11:54 kernel: pid 75251 (igmpproxy), uid 0: exited on signal 11 (core dumped)
May 2 02:11:54 kernel: pid 76141 (igmpproxy), uid 0: exited on signal 11 (core dumped)
May 2 02:11:54 kernel: pid 74755 (igmpproxy), uid 0: exited on signal 11 (core dumped)
May 2 02:11:54 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:54 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:54 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Warn: unknown Mode in V3 report (16805920)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Warn: unknown Mode in V3 report (16805920)
May 2 02:11:53 igmpproxy: Warn: unknown Mode in V3 report (16805920)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 224.0.0.1 (ip_hl 24, data 12)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV Membership query from 192.168.111.1 to 233.51.229.114 (ip_hl 24, data 8)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:53 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:52 igmpproxy: Warn: unknown Mode in V3 report (16805920)
May 2 02:11:52 igmpproxy: Note: RECV V3 member report from 192.168.111.2 to 224.0.0.22 (ip_hl 24, data 16)
May 2 02:11:52 igmpproxy: Warn: unknown Mode in V3 report (16805920)
May 2 02:11:52 igmpproxy: Warn: unknown Mode in V3 report (16805920)

I'm not sure if this is a bug in igmpproxy, but given there's a stable release available from 2009 (whereas the version in pfSense is from 2005), it seems a good place to start to upgrade the igmpproxy version.

Is this something that can be built into the next release of pfSense please?

Also, is there a way in the meantime to upgrade it in my version please?

Many thanks,

Andrew

-flo- 0

I second this request!

While I do not get a blank screen with IPTV (had this problem in the beginning and never was able to track it down) in my place switching channels definitely does not work correctly. Whenever I switch channels in a fast succession this results in a blank screen. I blame this on the IGMP proxy. Using a consumer router this works like a charm. :-/

I can see that the current build of pfSense incorporates IGMPProxy 0.1 beta2, Build 150319.

Andrew, how can this be checked?

-flo-

Andrew453

If you go into diagnostics > command prompt and type "igmpproxy" into "command" it shows:

$ igmpproxy
igmpproxy, Version 0.1 beta2, Build 150319
Copyright 2005 by Johnny Egeland johnny@rlo.orgDistributed under the GNU GENERAL PUBLIC LICENSE, Version 2 - check GPL.txt

I did notice from the logs that igmpproxy is trying to handle igmpv3 traffic, which apparently it doesn't support.

On other forums, people have seemed to have more luck if igmpv2 is enforced. I'm trying to work out how to do that at the moment.

If anyone knows, please do let me know!/johnny@rlo.org

Andrew453

OK, I think I've cracked it. I've posted the instructions to upgrade to igmpproxy 0.1 (no IPTV problems for me after upgrading!), but I can't be held responsible if you brick your pfSense box whilst doing it.

First you need to upgrade igmpproxy in the shell.

pkg
pkg update
pkg install igmpproxy

However, once you've done this, because the command line options for igmpproxy 0.1 are different to the existing version on pfSense, igmpproxy won't start on boot. You therefore need a custom shell script to do it:

Create a new file called igmpstart.sh in /usr/local/etc/rc.d/

Use the vi editor to put the following line in it:

/usr/sbin/daemon igmpproxy /tmp/igmpproxy.conf

Make the file executable:

chmod +x igmpstart.sh

Then, when you reboot, all should be well.

:)

Andrew453

p.s. I didn't need to force igmp v2.

If the latest version of igmpproxy could be built into the next release of pfSense that would be fab. Not sure how I post feature requests?

-flo- 0

@Andrew453:

OK, I think I've cracked it. I've posted the instructions to upgrade to igmpproxy 0.1 (no IPTV problems for me after upgrading!) […]

Great, so that actually is worth the effort!

If the latest version of igmpproxy could be built into the next release of pfSense that would be fab.

I agree, that would be great.

Thank you for the instructions. I'm running NanoBSD and there is not pkg command installed. Can anyone give a quick statement on whether this would work on NanoBSD at all? For one thing whether the igmpproxy package is available at all for NanoBSD and shouldn't the way the igmpproxy is started by default be changed / updated?

-flo-

heper

please create a bug report on https://redmine.pfsense.org/

Andrew453

Thanks. Have done so: https://redmine.pfsense.org/issues/4672

MSilva

Hello,

I have done one post on another thread, but since my issue is the same that is reported in this post, i ask here also:).

I am trying to route some multicast stream (UDP 239.x.x.x) to one GRE interface using pfSense 2.2.
But I am not having success in doing it.

I have done the following:

1)Create de GRE tunnel + create the GRE interface
I am able to ping the other endpoint of the GRE tunnel with success.

I have configured the IGMP proxy to have one Upstream and two downstreams.
First Interface Downstream is the GRE interface
Second Donwstream Interface is one physical interface.
I have step up the firewall rules to permit everyting, and also in the rules "Advanced Options" I have activated the flag "This allows packets with IP Options to pass".

I see that the multicast routed to the other Tunnel endpoint for some seconds and then stop!
I can see, on pfsense, using tcpdump that the IGMP requests are arriving from the GRE tunnel, but for some reason the multicasts are not routed to it.

I see that if i restart the IGMP Proxy service, the multicast start being routed again to the tunnel interface, but only for a short period of time.

I already read almost all the posts about this topic, and it were them that show me the right path, but now I am not able to figured out what is happening.

Can some have an idea of is the cause?

I have done the configuration mentioned on the post, but still no multicast is arriving on the tunnel.

The configurations are:

IGMP Proxy

:more igmpproxy.conf

##–----------------------------------------------------

Enable Quickleave mode (Sends Leave instantly)

##------------------------------------------------------
quickleave
phyint em3 upstream ratelimit 0 threshold 1
altnet 192.168.113.0/24
altnet 239.255.1.8/8

phyint gre0 downstream ratelimit 0 threshold 1
altnet 10.10.10.0/30
altnet 239.255.1.8/8

phyint bge0 disabled
phyint em0 disabled
phyint bge1 disabled
phyint em1 disabled
phyint em2 disabled

The firewall rules are: pfctl -sr | grep allow-opts

pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
pass out route-to (bge0 192.168.0.254) inet from 192.168.0.25 to ! 192.168.0.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (bge1 REMOTE_SERVER) inet from REMOTE_SERVER to ! REMOTE_SERVER/16 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (em2 192.168.3.254) inet from 192.168.3.25 to ! 192.168.3.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (gre0 10.10.10.2) inet from 10.10.10.1 to ! 10.10.10.0/30 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass in quick on em3 inet proto udp from any to 224.0.0.0/4 keep state allow-opts label "USER_RULE"
pass in quick on em3 inet from any to 192.168.113.0/24 flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on em3 inet proto icmp all keep state allow-opts label "USER_RULE"
pass in quick on em3 inet proto udp all keep state allow-opts label "USER_RULE"
pass in quick on em3 inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on em1 inet proto igmp all keep state allow-opts label "USER_RULE: Multicat traffic IGMP"
pass in quick on em1 inet proto udp from any to 224.0.0.0/4 keep state allow-opts label "USER_RULE: Multicat traffic UDP"
pass in quick on em2 reply-to (em2 192.168.3.254) inet proto igmp all no state allow-opts label "USER_RULE"
pass in quick on em2 reply-to (em2 192.168.3.254) inet proto icmp all keep state allow-opts label "USER_RULE"
pass in quick on em2 reply-to (em2 192.168.3.254) inet proto udp all keep state allow-opts label "USER_RULE"
pass in quick on em2 reply-to (em2 192.168.3.254) inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto igmp from 10.10.10.0/30 to 224.0.0.0/8 keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet from any to 192.168.113.0/24 flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto igmp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto udp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto icmp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto gre all keep state allow-opts label "USER_RULE"

The multicast are arriving in interface EM3 and should be routed to tunnel interface GRE0

I see the multicast report arriving on the GRE0 interface, 10.10.10.2 is the remote tunnel endpoint :
15:39:04.138013 IP 10.10.10.2 > 239.255.1.8: igmp v2 report 239.255.1.8
15:39:11.757964 IP 10.10.10.2 > 239.255.1.8: igmp v2 report 239.255.1.8
15:39:16.461933 IP 10.10.10.2 > 239.255.1.8: igmp v2 report 239.255.1.8

When these igmp are arriving on the GRE0 interface I see on the igmpproxy logs the error message:
No interfaces found for source 10.10.10.2

And I see no igmp traffic on EM3 interface when i do "tcpdump -vvni em3 igmp.

I can not understand why this is not working, I must be doing something wrong.
Do someone has some advise for me please?

Manuel Silva.

Andrew453

Have you had a look at the debug logs to see if igmpproxy is crashing and exiting? That was my problem, that was solved by upgrading igmpproxy to the latest version.

If it works for a time then stops, it sounds like your setup is ok, but for some reason there's an issue with igmpproxy.

Another possibility is that the igmp negotiation that keeps the stream going is failing for some other reason. I would check the igmpproxy logs first though.

MSilva

Hello,

thanks for the reply.

Well in the old igmpproxy, sometimes it worked for some seconds the reception of the multicast on the remote GRE tunnel endpoint, but at that time i did not do any more deep debugging inside pfSense.

After doing the upgrade of the igmpproxy it simply does not work.

I am running igmpproxy as:
/root: /usr/sbin/daemon igmpproxy -d /tmp/igmpproxy.conf

But apart from the console messages i do no see any place where the logs are recorded on the /var/log folder.

I already read the 85 posts of pfSense about this topic :), that was good to understand how it should work and to learn some debug possibilities, but even so I am not able to bypass this wall :)

When I receive the IGMP requests from the GRE interface(downstream), they should appear on the EM3 interface (upstream) correct? That step is not happening.

All advises would be very welcome..

Manuel

Andrew453

Have you confirmed that the igmpproxy service is running in Status > Services after the upgrade?

The command line options changed in the latest version. Try it without the "-d" as per my post above:

i.e. /usr/sbin/daemon igmpproxy /tmp/igmpproxy.conf

The logging messages appear in Status > System Logs > General tab. You might need to filter by "igmpproxy" if there's lots of other log entries.

MSilva

Hum..

if i start the igmpproxy as:
/usr/sbin/daemon igmpproxy /tmp/igmpproxy.conf

on the status->service the igmpproxy is stopped.

But I see it running doing PS - AX, but only for a minute or so.
I see some logs, but are the same as the ones I see when I run IGMPPROXY with the -d option

2)if i start the igmpproxy as:
/usr/sbin/daemon igmpproxy -d /tmp/igmpproxy.conf

on the status->service the igmpproxy is started.

And the messages are the ones below:

"No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2
The source address 192.168.123.139 for group 239.255.255.250, is not in any valid net for upstream VIF.
No interfaces found for source 10.10.10.2
The source address 192.168.123.51 for group 239.255.255.250, is not in any valid net for upstream VIF.
No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2
The source address 192.168.123.58 for group 239.255.255.250, is not in any valid net for upstream VIF.
No interfaces found for source 10.10.10.2
The source address 192.168.123.139 for group 239.255.255.250, is not in any valid net for upstream VIF.
No interfaces found for source 10.10.10.2
The source address 192.168.123.139 for group 239.255.255.250, is not in any valid net for upstream VIF.
The source address 192.168.123.46 for group 239.255.255.250, is not in any valid net for upstream VIF.
The source address 192.168.123.51 for group 239.255.255.250, is not in any valid net for upstream VIF."

Note that when I receive the IGMP on the GRE interface coming from the other endpoint (10.10.10.2), I get the message: "No interfaces found for source 10.10.10.2".

Since I have other interfaces connected to the pfSense, but are not configured on IGMPPROXY must be that the reason why I get the other type of messages.

Should I be able to run the IGMPPROXY without the -d option?

Manuel.

Andrew453

If igmpproxy is running, I wouldn't worry about it for now, as it sounds like there's some other issue. If it doesn't start up when you reboot, you need to double check the command line options. Mine doesn't have the -d and starts ok.

Re the other issues, are you sure you've captured all the multicast addresses properly? The multicast range is divided up into different parts for control and data. If some of the control traffic isn't getting through, that might explain why the stream gets cut off.

The usual netmask is 224.0.0.0/4

Also, your netmask for the 10.10.10.x network looks a bit odd. What address range are you trying to capture? If it's 10.10.10.0-10.10.10.255, it should be 10.10.10.0/24

MSilva

Hi,

I change to 224.0.0.0/4 mask on the firewall rules.
And have also permit all rules.

/root: pfctl -sr | grep allow-opts
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
pass out route-to (gre0 10.10.10.2) inet from 10.10.10.1 to ! 10.10.10.0/30 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass in quick on em3 inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on em3 inet proto udp from any to 224.0.0.0/4 keep state allow-opts label "USER_RULE"
pass in quick on em3 inet from any to 192.168.113.0/24 flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on em3 inet proto icmp all keep state allow-opts label "USER_RULE"
pass in quick on em3 inet proto udp all keep state allow-opts label "USER_RULE"
pass in quick on em3 inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on em1 inet proto igmp all keep state allow-opts label "USER_RULE: Multicat traffic IGMP"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet all flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto igmp from 10.10.10.0/30 to 224.0.0.0/4 keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet from any to 192.168.113.0/24 flags S/SA keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto igmp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto udp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto icmp all keep state allow-opts label "USER_RULE"
pass in quick on gre0 reply-to (gre0 10.10.10.2) inet proto gre all keep state allow-opts label "USER_RULE"

The GRE tunnel is 10.10.10.0/30 network.
10.10.10.1 in the local endpoint, 10.10.10.2 is the remote endpoint of the tunnel. I can ping the remote endpoint with success and I can see the IGMP coming.

"AF IPv4 (2), length 36: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.10.10.2 > 224.0.0.2: igmp leave 239.255.1.8"

They are arriving with TTL =1, does this makes any difference to the IGMP Proxy?

Regards,

Andrew453

Hi. I assume from your post that it's still not working?

Another thing to check is your firewall logs. I had an issue where one of the hidden rules in pfSense was blocking the multicast traffic inadvertently. It's worth checking to see if any traffic originating from 224.0.0.0/4 is being blocked, despite your allow all rules to the contrary.

See here: https://forum.pfsense.org/index.php?topic=93190.0

doktornotor

@MSilva:

They are arriving with TTL =1, does this makes any difference to the IGMP Proxy?

Pretty much expected… Means stay on this network, tells the router to not forward those anywhere.

MSilva

Correct, the igmpproxy still not work, but I must be close to some solution:)

When i start the igmpproxy using the command line i see on the system-generallogs->

May 21 15:39:29 kernel: em3: promiscuous mode disabled
May 21 15:39:33 kernel: gre0: unable to attach encap
May 21 15:39:33 kernel: gre0: promiscuous mode disabled

On the firewall->Normal view
I do not see any blocking messages for the interfaces em3 (upstream) and gre0 (downstream).

The IGMP Proxy is giving these messages:

No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2
No interfaces found for source 10.10.10.2

When I receive the IGMP requests from the gre0 interface.

Do you know what could be the reason for these messages on system log and on the output of the IgmpProxy?

I am trying to increase the TTL value of the IGMP requests to see if something change for better..

Regards,

Andrew453

I'm not sure what the "unable to attach encap" message is. Perhaps another contributor can help with that.

A few other thoughts though:

I noticed from your log output before that you had entries such as:

The source address 192.168.123.139 for group 239.255.255.250, is not in any valid net for upstream VIF.

In your upstream definition you've got:

altnet 192.168.113.0/24

i.e. 113 instead of 123.

I suggest changing that and trying again. If it still does't work, I'm not sure you need 239.255.1.8/8 in your downstream config, so try taking that out.

Not sure if anyone else has any suggestions?

MSilva

Hi,

I am back again…
I re-install the pfsense 2.2 again.

Have now configured on the igmpproxy the upstream and downstream as 224.0.0.0/4.

And have permitted everything on the firewall.

But i have the same result:

I restart the service IGMPPROXY
I go on the remote GRE tunnel endpoint and do IGMP request for the multicast
Using tcpdump, i see that the multicast is sent to the GRE endpoint on pfsense
After some time, the multicast stops being sent to the tunnel, although i continuously do the IGMP request
That is only fixed restarting again the IGMP Proxy service (point 1).

Checking the logs I do not see anything related to the IGMPProxy.

If that was some firewall/Rules issue, I suppose it should affect all the time and not only after some minutes.

I could set some cron job to, every minute, restart the igmpproxy, but that would not be very correct:)

Do someone have some advise that I could use please?

Best.