OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: tnsasse on March 19, 2017, 06:00:12 pm
-
Hi guys,
I am having issues routing multicast traffic. I have igmpproxy running, IGMP is working like a charme.
There is UDP multicast traffic coming inbound on my WAN2 interface: igb0_vlan8
tcpdump -i igb0_vlan8 -v -n udp and port 10000
17:53:41.239319 IP (tos 0x80, ttl 24, id 0, offset 0, flags [none], proto UDP (17), length 1356)
87.141.215.251.4000 > 232.0.20.234.10000: UDP, length 1328
17:53:41.239842 IP (tos 0x80, ttl 24, id 0, offset 0, flags [none], proto UDP (17), length 1356)
87.141.215.251.4000 > 232.0.20.234.10000: UDP, length 1328
17:53:41.241084 IP (tos 0x80, ttl 24, id 0, offset 0, flags [none], proto UDP (17), length 1356)
87.141.215.251.4000 > 232.0.20.234.10000: UDP, length 1328
This needs to go to my local client sitting on my "MAGENTA" network (interface igb2).
Yet the tcpdump shows nothing:
root@gateway:~ # tcpdump -i igb2 -v -n udp and port 10000
tcpdump: listening on igb2, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
4 packets received by filter
0 packets dropped by kernel
I have the following rules in place:
WAN2
Pass IPv4 IGMP * * IPTV_MULTICAST * * IPTV IGMP
Pass IPv4 UDP IPTV_ROUTERS * IPTV_MULTICAST * * IPTV Stream
And wide open on MAGENTA:
Pass IPv4 * * * * * *
Where the aliases are
IPTV_MULTICAST Network(s) 224.0.0.0/4, 232.0.0.0/4
IPTV_ROUTERS Network(s) 87.141.215.0/24, 10.48.0.0/16
Help is appreciated...
Thanks, Tobi
-
Hmmm
tried to get it working too a while ago -
https://forum.opnsense.org/index.php?topic=1968.msg6256#msg6256 (https://forum.opnsense.org/index.php?topic=1968.msg6256#msg6256)
Although my setup has been somewhat different (opnsense behind fritzbox), according to my understanding, igmp proxy lacks full support of the functions which are required to make it work with entertain, e.g.
- igmp cascading
- full vlan support. (required to send igmp group membership refreshes to the right vlan)
I have not yet seen that the suggestion to extend the igmp proxy with new features has been picked up and also the version suggests that it is still the same code base as when I tried it ...
br br
-
Thanks for your comment. I compiled a newer version of igmpproxy and the part you are describing at least seems to work, as I see IGMP membership queries and reports up- and downstream. The UDP multicast stream is also coming in on my WAN interface. Yet the router seems to just drop it / ignore it.
I did another test: tried to ping the multicast group directly on the router, which should result in a response from up and downstream devices. Yet nothing, 100% packet loss. When I specify my downstream interface, I even get the following:
root@gateway:~ # ping -I igb2 -c4 -T 16 224.0.0.1
ping: invalid multicast interface: `igb2'
Whereas ifconfig shows that MULTICAST is enabled on the interface:
root@gateway:~ # ifconfig igb2
igb2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
So this lets me thinking that there is a more general problem on my setup with multicast...
-
... how does your igmpproxy.conf look like?
Br br
-
Looks like this:
root@gateway:~ # cat /usr/local/etc/igmpproxy.conf
quickleave
phyint igb2 downstream ratelimit 0 threshold 1
phyint igb0_vlan8 upstream ratelimit 0 threshold 1
altnet 224.0.0.0/4
altnet 87.141.215.0/24
phyint igb0 disabled
phyint igb1 disabled
phyint enc0 disabled
phyint lo0 disabled
phyint pflog0 disabled
phyint pfsync0 disabled
phyint igb0_vlan7 disabled
phyint igb1_vlan10 disabled
phyint igb1_vlan20 disabled
phyint igb1_vlan30 disabled
phyint ppp0 disabled
-
and where is the downstream subnet defined? IMHO you need an altnet config item for downstream too, eg
phyint igb2 downstream ratelimit 0 threshold 1
altnet 192.168.x.0/32
-
Interesting. The same config ran on Linux, it seems as if the IGMPproxy figures out the downstream net itself. This matches with the output it provides when running in -dvv.
In the meantime I had to revert to Linux as I can't really spend days without a router ;-)
Yet I will give opnsense another shot probably at some point. So if someone finds the error, I'd appreciate that.
-
Tried it once again with my config and it works, but still as last year for 2 minutes only :(.
Did you set on both interfaces (igb2 AND igb0) in your firewall rules the tick for 'allow ip options' in the extended configuration? Otherwise igmp traffic will not pass through.
brbr
-
Tried it once again with my config and it works, but still as last year for 2 minutes only :(.
I would suggest disabling state tracking for the firewall rule that allows the multicast traffic through, as this may be a state timeout at 2 minutes.
-
Hi DjGrr
Tried this one - an put the field in the status type to none - no change :-\
Br br
-
Have you checked firewall logs to see if it shows up as being dropped there?
-
Hi DjGrr
Yes - with the original one its not an firewall issue (why should the firewall suddenly drop packets after 2 min. it let through before, no evidence in the logs for that). Its rather the missing cascading support (see also forum link above)
I am experimenting around with several side forks of igmpproxy from GitHub currently which received also updates up to freebsd 11 in the last 12 months (seem to have all the same code base and compile well on freebsd). All behave different but none giving the full functionality.
- The original opnsense igmpproxy plugin still 'forgets' after two minutes to send igmp refresh upstream - but at least gives stream on VLC
- The most promising one wrt igmp management is the the igmpproxy from 'ViToni' on GitHub which properly handles all the igmp management (with v1, v2 and v3 clients in downstream) as far as I could see - but unfortunately lets not through the UDP stream (could not yet analyse why) UDP packets reach the Upstream interface of the opnsense but get then 'lost' on their way through the opnsense ....
I use the same igmpproxy.conf config for all Versions ....
br br