IGMP Proxy is broken?

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.

Andrew453

Multicast traffic works through a series of messages that allow clients to add or remove themselves from multicast groups. When the client is part of a group, the multicast server sends the stream to them. The server sends periodic "general queries", whereupon all clients will effectively confirm that they still want to receive the traffic.

Given that you say it's working for a bit suggests that the initial request for the client to join a multicast stream is working across the tunnel but that, for whatever reason, the general query is not being responded to by the client (or processed correctly by the server). When you restart the igmpproxy service, it renegotiates the multicast group memberships which is presumably why it then works again.

These symptoms could be for a number of reasons:

1) igmpproxy is crashing (that was the reason for me)
2) for some reason, the group query messages are not going across the tunnel correctly (that could be an issue with how igmpproxy is configured)
3) it might be that the client (on the other end of the GRE tunnel) is not receiving (or responding) to the general query properly.

Re (1), upgrading to the latest version of igmpproxy fixed it for me (as previously advised).

Re (2), did you try my suggestion in the previous post re the upstream interface definition in igmpproxy? It looks like you had the wrong network defined there.

Re (3), I'm not sure what the device is at the other end of the GRE tunnel (or what sort of multicast traffic you're trying to route), but it could be that the issue lies with the device on the other end of the tunnel, and not pfSense.

If you enable verbose logging in igmpproxy, you should see all of the membership requests etc being processed which should allow you to work out what's going on.

Beyond that, I'm running out of ideas so may be others in the forum could suggest something?

rudelerius

@-flo-:

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

@flo: I can confirm that pkg and igmpproxy can be installed on the current NanoBSD version of pfSense. However, prior to following Andre453's instructions, you must first (re)mount the file system as read/write. (Follow these instructions: https://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write.)

I was able to install pkg and install igmpproxy version 0.1. However, when I went to confirm it was running, it was not. When I attempt to run it, I get the response "You must specify the configuration file."

I thought that was what I was doing when I created the igmpstart.sh file in /usr/local/etc/rc.d/ and specified therein the path to /tmp/igmpproxy.conf to the daemon. I've double checked the spelling in the file names, locations, paths, etc. I made certain that the file system was mounted r/w when making all changes, including making the igmpstart.sh file executable with chmod, but I am still receiving the message that I need to specify the configuration file. Is it possible that there is something different about the way NanoBSD starts the daemons or uses the shell scripts, or whatever, that is different from the full version? Perhaps another step is required that I am unaware of?

Any assistance in making this work would be greatly appreciated. If this question would be better served by creating a new topic, instead of adding to this one, feel free to say so as well.

Thanks. Jon.

Andrew453

Hi. There's actually a better way to upgrade igmpproxy to the latest version.

Rather than creating igmpstart.sh to start the upgraded igmpproxy, you can actually edit the original function in pfSense to do it. This means the start/stop services etc options in pfSense work properly. The revised instructions to upgrade are:

Upgrade igmpproxy in the shell.

pkg
pkg update
pkg install igmpproxy

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 to edit pfSense's function that starts the service:

Use the editor in the GUI to open etc/inc/services.inc

Find the line which reads: "/* NOTE: -d4 means everything LOG_WARNING and smaller */"

Edit the line underneath to change -d4 to -v -v:

mwexec("/usr/local/sbin/igmpproxy -v -v {$g['tmp_path']}/igmpproxy.conf");

(n.b. the -v -v enables verbose logging, which might be useful if you're having problems. You can leave that out if you don't want your system logs to record igmpproxy activity.)

Thanks.

rudelerius

Thanks for the update Andrew453

Unfortunately, no matter what I do, I cannot seem to get igmpproxy to run after installing and updating using pkg. I tried editing etc/inc/services.inc as noted, but it still does not appear in top after a reboot. When I attempt to run it manually, I still receive the message that I must specify a configuration file. When I pass in the path to the configuration file at launch, using the -d mode, the application responds that "There must be at least 2 Vif's where one is upstream." I've checked the configuration file and both the upstream and downstream interfaces/addresses appear to be configured correctly.

I did a Google search and found this on the SourceForge page for igmpproxy: http://sourceforge.net/p/igmpproxy/bugs/4/, but I don't think it is valid, as both interfaces I've got assigned as upstream and downstream have an IPV4 address assigned. I don't really see any other detailed output of the debug command to try to troubleshoot anything else. Not sure where to look next.

Again, any help is appreciated.

Andrew453

Hi. Can you post your config file please?

rudelerius

Here is my /tmp/igmpproxy.conf file:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint em0 upstream ratelimit 0 threshold 1
altnet 224.0.0.0/4
altnet 184.60.0.0/16
altnet 184.61.0.0/16

phyint em1_vlan10 downstream ratelimit 0 threshold 1
altnet 10.10.0.0/24

phyint lagg0_vlan80 disabled
phyint lagg0_vlan10 disabled
phyint em1_vlan12 disabled
phyint em1_vlan80 disabled
phyint bridge2 disabled

Here are the ifconfig outputs for em0 and em1_vlan10:

$ ifconfig em0
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
	options=5209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter,vlan_hwtso>ether 00:01:xx:xx:xx:xx
	inet6 fe80::201:69ff:fe01:24b9%em0 prefixlen 64 scopeid 0x1 
	inet 192.168.0.16 netmask 0xffffff00 broadcast 192.168.0.255 
	nd6 options=23 <performnud,accept_rtadv,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active</full-duplex></performnud,accept_rtadv,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast>

Yes, my WAN address is a private IP. Until I can figure out this igmpproxy problem, my pfSense firewall is sitting behind my ISPs Actiontec modem/router.

$ ifconfig em1_vlan10
em1_vlan10: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
	options=3 <rxcsum,txcsum>ether 00:01:xx:xx:xx:xx
	inet6 fe80::201:69ff:fe01:24b8%em1_vlan10 prefixlen 64 scopeid 0xe 
	inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 
	nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 10 vlanpcp: 0 parent interface: em1</full-duplex></performnud,auto_linklocal></rxcsum,txcsum></up,broadcast,running,promisc,simplex,multicast>

All looks fine to me. I don't get it.

Andrew453

I had a look at the source code for igmpproxy to see when it throws this error. Basically, it iterates through the available interfaces and adds them in if (1) they have an IPv4 address and (2) they're not a loopback adapter. Both your interfaces seem to have ipv4 and aren't loopback, so I imagine that for some reason it's not finding the interfaces in the first place.

I wonder if it might have something to do with your vlans - they're not physical interfaces.

Just for testing purposes, have you tried disabling your vlans, giving em1 the 10.8.0.x address range and trying again? If it picks it up then, at least you know what the problem is.

rudelerius

@Andrew453-
I've been kicking around your comment about igmpproxy not finding my interface at all. I think that, as you also noted, that the vlan may be the issue. Here's why:

After looking around the interwebs a bit, I think I may have stumbled onto a possible cause/solution at this link: http://wiki.ipfire.org/en/addons/igmpproxy/start.

Specifically, the notation of the interface name in the config file posted there:

phyint red0.8

It makes me wonder if the use of the alias "em1_vlan10" may be the cause of the problem. I speculate that if I change the interface name in the config file to em1.10, it might work. I've no real idea if that's the cause, but it can't hurt to try it!

I'll post results here once I've had a chance to give it a go.

rudelerius

Well- tried using the following config with no luck:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint em0 upstream ratelimit 0 threshold 1
altnet 224.0.0.0/4
altnet 184.60.0.0/16
altnet 184.61.0.0/16

phyint em1.10 downstream ratelimit 0 threshold 1
altnet 10.10.0.0/24

phyint lagg0.80 disabled
phyint lagg0.10 disabled
phyint em1.12 disabled
phyint em1.80 disabled
phyint br2 disabled

According to the logs (see attached), it keeps failing on the upstream (em0) interface; it doesn't even appear to make it to the downstream interface. But, I see absolutely no reason why that should be the case- I'm not using any VLAN on the WAN interface. I don't get it.

log.PNG_thumb

rudelerius

I really suspect that this line in the source code for igmpproxy is causing the failure to find the downstream interface:

if(strlen(token) >= IF_NAMESIZE) return NULL;

I think the IF name: "em1_vlan1" may be longer than the value held in that constant.

Unfortunately, after looking in all of the files included in the tar file for igmpproxy, I could not find where that constant was defined and what the maximum number of characters is for the if name.

Perhaps someone more saavy could find it for me?

Jon.

EDIT: this link indicates it is defined in system file sys/net/if.h. Not clear to me if the max size is 16 bits.
http://fxr.watson.org/fxr/ident?v=FREEBSD51;im=bigexcerpts;i=IF_NAMESIZE
Seems too small.

Andrew453

It's 16 characters, rather than bits.

I think that part of the code is actually reading the interface config from your file - so it's sanity checking what's in the config file rather than what the hardware is reporting exists. There's a separate bit of the code that actually loads in the physical interfaces, and then attempts to match the two.

If you look in your logs at start up you should see it initialise the interfaces, e.g.:

Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 2 Fl 0x0 IP 0x[ ] ath0_wlan0, Threshold: 1, Ratelimit: 0
Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 1 Fl 0x0 IP 0x[ ] re1, Threshold: 1, Ratelimit: 0
Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 0 Fl 0x0 IP 0x[ ] re0, Threshold: 1, Ratelimit: 0

I suspect you'll find your Vlan is missing.

Perhaps try to rename it to shorten it and remove any out of the ordinary characters etc (no underscores, spaces, dots etc). I suspect that's probably not the issue though. You're not the first person to have trouble getting igmpproxy to work with vlans: http://community.ubnt.com/t5/EdgeMAX/How-do-I-add-vlan-to-igmp-proxy/td-p/1099265

I saw a reference elsewhere to giving your vlans different mac addresses, in an attempt to get igmpproxy to pick them up.

Andrew453

Hi rudelerius. I've had a bit more of a look at this - I was wondering whether igmproxy supports vlans or not, so I tried it on my set up.

I can confirm it does support vlans so it should see them. e.g. below is my log when I had a vlan running:

Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 3 Fl 0x0 IP 0x[ ] re1_vlan12, Threshold: 1, Ratelimit: 0
Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 2 Fl 0x0 IP 0x[ ] ath0_wlan0, Threshold: 1, Ratelimit: 0
Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 1 Fl 0x0 IP 0x[ ] re1, Threshold: 1, Ratelimit: 0
Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 0 Fl 0x0 IP 0x[ ] re0, Threshold: 1, Ratelimit: 0

Are you sure you've got your vlans set up right?

You need to define the vlan in Interfaces > (assign) > VLANs.

Then you need to add it to the interfaces list and enable it. pfSense will give it another interface name, e.g. OPT2

Once you've got that, give it an IP etc.

Then, in Services > IGMP proxy, define your upstream and downstream interfaces and select the vlan interface as appropriate e.g. OPT2

When the igmpproxy service restarts, all should be well. There's no need to edit the igmpproxy.conf file directly (services.inc overwrites it anyway), nor start/stop the service from the command line if you've followed my updated instructions to patch services.inc

Hope this helps!

rudelerius

Are you sure you've got your vlans set up right?

You need to define the vlan in Interfaces > (assign) > VLANs.

Then you need to add it to the interfaces list and enable it. pfSense will give it another interface name, e.g. OPT2

Once you've got that, give it an IP etc.

Then, in Services > IGMP proxy, define your upstream and downstream interfaces and select the vlan interface as appropriate e.g. OPT2

When the igmpproxy service restarts, all should be well. There's no need to edit the igmpproxy.conf file directly (services.inc overwrites it anyway), nor start/stop the service from the command line if you've followed my updated instructions to patch services.inc

Hope this helps!

Thanks for trying to help Andrew453. Unfortunately, nothing works.

I have double checked all of my configuration of the vlan, interfaces, igmpproxy, etc. and I cannot find anything that isn't set up correctly. I have followed all of your instructions to the letter. Whenever I restart pfSense (or try to start igmpproxy manually), I see the following in the logs:

Aug 6 09:24:00 php-fpm[7798]: /rc.newwanip: The command '/usr/local/sbin/igmpproxy -v -v /tmp/igmpproxy.conf' returned exit code '255', the output was ''
Aug 6 09:24:00 igmpproxy[47493]: There must be at least 2 Vif's where one is upstream.
Aug 6 09:24:00 igmpproxy[47493]: adding VIF, Ix 0 Fl 0x0 IP 0x1000a8c0 em0, Threshold: 1, Ratelimit: 0

em0 is my WAN interface. The next line in my config should configure my LAN interface (em1_vlan10) as the upstream interface, but it fails as noted above. I have no idea why and it just doesn't make any sense.

Name Type Values Description
WAN upstream 224.0.0.0/4, 184.60.0.0/16, 184.61.0.0/16 TDS TV UPSTREAM IGMP PROXY
LAN downstream 10.10.0.0/24 TDS TV DOWNSTREAM IGMP PROXY

I'm at a complete loss of what to do to fix this problem.

Andrew453

Can you post your Interfaces > (assign) screen, and your Interfaces > VLANs screen please?