[SOLVED] IPTV, IGMPProxy and Firewall issues

lleachii · March 27, 2018, 11:40am

I guess you're still not willing to re-admit that the Wiki may have an error...despite my showing you that igmpproxy also makes UDP sockets...OK, cool...

I told you that was from LuCI...just look at your own firewall page, same as yours. Also...RAW rules can only be INPUT, FORWARD is not an option with RAW.

Same [normal] thing from iptables:

root@LEDE:~# iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DROP ipencap-- anywhere anywhere
DROP all -- !44.xxx.xxx.0/24 anywhere
ACCEPT all -- anywhere anywhere TTL match TTL < 7
ACCEPT all -- anywhere anywhere TTL match TTL < 7
ACCEPT udp -- anywhere base-address.mcast.net/4 TTL match TTL < 7
ACCEPT all -- 192.168.xxx.2 base-address.mcast.net/4 TTL match TTL < 7
DROP all -- anywhere anywhere TTL match TTL < 7

The confusion is that I contend that igmpproxy also proxies the downstream UDP traffic as well.

/etc/config/network:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd7e:xxxx:xxxx::/48'

config interface 'lan'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xxxx.1'
	option igmp_snooping '1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'
	option _orig_ifname 'eth0.1 radio0.network1 wlan0 radio1.network1 wlan1'
	option _orig_bridge 'true'
	option ifname 'eth0.1'

config interface 'wan'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'dhcp'
	option peerdns '0'
	option delegate '0'
	option dns '74.82.42.42 156.154.70.5 198.82.247.98 44.60.44.3 2001:470:20::2 2001:468:c80:6101:0:100:0:62 2610:a1:1018::5'
	option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '0t 1 4t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'
	option ports '0t 4t 5'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '0t 2 3 4t'

config interface 'network2'
	option proto 'static'
	option type 'bridge'
	option igmp_snooping '1'
	option _orig_ifname 'eth0.3'
	option _orig_bridge 'true'
	option ifname 'eth0.3'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xx.1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'

config interface 'untrusted'
	option proto 'static'
	option ifname 'eth0.5'
	option netmask '255.255.255.0'
	option delegate '0'
	option ipaddr '192.168.xxx.1'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '4'
	option ports '0t 4t'

config interface 'amprnet'
	option type 'bridge'
	option proto 'static'
	option delegate '0'
	option _orig_ifname 'eth0.4'
	option _orig_bridge 'true'
	option ifname 'eth0.4'
	option ipaddr '44.xxx.xxx.1'
	option netmask '255.255.255.0'
	option broadcast '44.xxx.xxx.255'

config route
	option interface 'amprwan'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option gateway '169.xxx.xxx.xxx'
	option onlink '1'
	option table '44'

config switch_vlan
	option device 'switch0'
	option vlan '5'
	option vid '5'
	option ports '0t 4t'

config interface 'henet'
	option proto '6in4'
	option peeraddr '216.xxx.xxx.xxx'
	option ip6addr '2001:470:xxxx:xxxx::2/64'
	option ip6prefix '2001:470:xxxx::/48'
	option mtu '1480'

config interface 'amprwan'
	option _orig_ifname 'tunl0'
	option _orig_bridge 'false'
	option ifname 'tunl0'
	option proto 'none'

config interface 'guest_net'
	option proto 'static'
	option ifname 'eth0.6'
	option ipaddr '192.168.xxx.1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'
	option type 'bridge'
	option netmask '255.255.255.0'

config switch_vlan
	option device 'switch0'
	option vlan '6'
	option vid '6'
	option ports '0t 4t'

config interface 'inet_wireguard'
	option proto 'wireguard'
	option private_key '+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list addresses '192.168.xxx.2/30'

config wireguard_inet_wireguard
	option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list allowed_ips '0.0.0.0/0'
	option endpoint_host 'vpn.xxxxxx.net'
	option endpoint_port '55555'

config route
	option interface 'inet_wireguard'
	option target '10.xxx.xxx.0'
	option netmask '255.255.0.0'

config interface 'home_wireguard'
	option proto 'wireguard'
	option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	option listen_port 'xxxxx'
	list addresses '172.xxx.xxx.1/24'

config interface 'azire_wireguard'
	option proto 'wireguard'
	option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list addresses '10.10.xxx.xxx/32'
	list addresses '2a03:8600:xxxx:xxxx::1f65/128'

config wireguard_azire_wireguard
	option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	option endpoint_host '193.xxx.xxx.xxx'
	option endpoint_port 'xxxxx'
	list allowed_ips '0.0.0.0/0'
	list allowed_ips '::'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.168.xxx.0/24'
	option priority '22'
	option lookup 'main'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.168.xxx.0/24'
	option priority '23'
	option lookup 'main'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.xxx.xxx.0/24'
	option priority '24'
	option lookup 'main'

config rule
	option dest '44.xxx.xxx.0/24'
	option priority '44'
	option lookup 'main'

config rule
	option in 'amprwan'
	option dest '0.0.0.0/0'
	option priority '45'
	option lookup '44'

config rule
	option in 'amprnet'
	option dest '0.0.0.0/0'
	option priority '46'
	option lookup '44'

config rule
	option src '44.xxx.xxx.0/24'
	option priority '47'
	option lookup '44'

I get:

Body is limited to 32000 characters; you entered 35522.

If i add firewall, that'll be a 2nd post.

lleachii · March 27, 2018, 11:59am

My firewall is too long to post, but you've seen the relevant rules.

I still receive:

Body is limited to 32000 characters; you entered 35522.

but again, the only rules I created related to igmpproxy multicast is:

Custom /etc/firewall.user:

#Allow Multicast
iptables -t raw -A PREROUTING -i eth0.2 -d 224.0.0.0/4 -p udp -m ttl --ttl-lt 7 -j ACCEPT
#Final Drop
iptables -t raw -A PREROUTING -m ttl --ttl-lt 7 -j DROP

Again, I can remove the above 2 iptables rules and also make this working rule instead:

config rule
option target 'ACCEPT'
option src 'wan'
option family 'ipv4'
option proto 'udp'
option dest_ip '224.0.0.0/4'
option name 'Allow-UDP_Multicast_In'

dlakelan · March 27, 2018, 2:33pm

It's official description is pretty meager but it explicitly says it only handles IGMP...

Based on that it seems like a forward rule would be the intended use...

lleachii · March 27, 2018, 2:47pm

I 100% understand that, which is why I looked at the code...and found that it creates UDP sockets. Again, that would prove INPUT. Otherwise, why would IGMPProxy be making UDP sockets that relate to the requests in the IGMP packet???

I think we forget that the IGMP request expects UDP traffic in reply - that's the protocol, folks! Why would someone only write code to solve half the protocol???

In addition, the FORWARD rule only seems to work if users create a route to the desired network wanting multicast - for the control traffic. This was another warning.

RFC5771 (https://tools.ietf.org/html/rfc5771) states that the control block traffic is local, hence making a route for it is not best practice and likely dangerous...especially if the router only has Global IP address space on some or all interfaces (i.e. no NAT used).

Local Network Control Block (224.0.0/24)

Addresses in the Local Network Control Block are used for protocol
control traffic that is not forwarded off link. Examples of this
type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

FORWARDING OFF-LINK FROM WAN TO LAN DEFINITELY BREAKS THIS.

I also see varions other router manuals: MicroTik, Cisco, Alpine Linux etc....few of them state a FORWARD rule is required...and if so, they add a routing rule.

dlakelan · March 27, 2018, 2:57pm

So it seems like maybe igmpproxy expanded it's scope and now the docs are out of date.

Mushoz · March 27, 2018, 3:59pm

This is not true. I have no such rule. The only rule I have added on top of the default Lede firewall rules is the UDP FORWARD rule for packets with destination 224.0.0.0/4.

lleachii · March 27, 2018, 4:08pm

Can you show the hits for this rule as well as results of:

ip route show

Also, we all agree that the igmpproxy script makes a FW3 rule to FORWARD to the downstream interface, so why is creating a second FORWARD rule necessary???

Mushoz · March 27, 2018, 4:25pm

root@LEDE:~# iptables --list -v | grep -i iptv
2452K 3286M zone_lan_dest_ACCEPT  udp  --  any    any     anywhere             base-address.mcast.net/4  /* !fw3: iptv */

root@LEDE:~# ip route show
default via 195.190.228.161 dev pppoe-wan  proto static 
10.0.32.0/19 dev eth0.4  proto kernel  scope link  src 10.0.39.67 
10.0.32.1 dev eth0.4  proto static  scope link  src 10.0.39.67 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
192.168.3.0/24 dev vpn  proto kernel  scope link  src 192.168.3.1 
195.190.228.161 dev pppoe-wan  proto kernel  scope link  src XX.XX.XX.XX (my WAN IP) 
213.75.112.0/21 via 10.0.32.1 dev eth0.4  proto static  src 10.0.39.67

Because of the following:

lleachii · March 27, 2018, 4:33pm

That may be the case; but the rule exists in the proper zone in my config. Even when creating a second one, it appears directly under it.

But I realize you believe that rule is merely a bug pointing to the wrong zone...I think it merely should be INPUT. I understand your reasoning now.

shm0 · March 27, 2018, 7:25pm

@lleachii
That is indeed interesting. Actually i can't believe that is it working without forward rule x)

Yes those addresses are reserved for various applications.
And most online sources say that those addresses can't be routed (or shall not?).
But i think it is possible to use those addresses anyway and route them. I will test this later.
(Maybe not use .1 and .2 doh)
From the view that the /24 range is reserved Indeed the forward rule could be more tightened.
But i guess the igmpproxy package maintainers choose that range to make it more fool proof?
Also you dont know if some ISPs do fishy stuff and use those addresses for their purposes.

Can you use ip mroute and post the output please.
Somehow multicast routing entries (created by multicast routing daemons) are not shown with ip route show.
There is also netstat -g but that is not supported by openwrt netstat binary. (busybox?)

I will test this igmpproxy forward rule thing later too and post the results.

There is also some other thing going through my mind about igmp snooping.
Isn't this iptv igmpproxy thing, a perfect example for this?
It seems like that on the isp site they are using igmp snooping.
Because the multicast traffic only flows if the client is joining a proper igmp group.
If they would not use igmp snooping.
Someone could just setup static routes and done.
But that would generate insane amount of traffic i guess?

Mushoz · March 27, 2018, 7:28pm

Make sure IPTV is actually running when using that command, or it won't show anything useful. IGMPProxy adds/removes routes as needed. If nothing is running, it is probably not going to show any routes.

lleachii · March 28, 2018, 12:21am

WHOA!!!

@shm0...I just realized something...

You both also agree to this:

and @Mushoz said:

I'm not sure I really understand your bug theory anyways....but what I do grasp is this...if it's true that your config places a FORWARD rule in the wrong zone, it's likewise true that:

your multicast routes are probably pointing to the wrong network!!!
Hence, my igmpproxy properly INPUT the packets, and there's a multicast route in my Kenrel...
My igmpproxy places the packet at the proper spot in netfilter after receiving it, and the route to my network2 is found!

Your workaround is merely redirecting multicast packets to the correct firewall zone (LAN). I believe you could remove igmpproxy under your config, except the need to forward IGMP upstream.

shm0 · March 28, 2018, 1:37am

Okay i tried to debug this but failed miserably x)

Test setup was 2 networks.
No forwarding allowed between them.
I tried vlc streaming feature to test -> legacy udp to a multicast address.
I tested some addresses but nope nothing works.

First i could not get igmpproxy to show any routes in its verbose log.
But the firewall log shows hits for the igmp input rules.
So maybe its a problem of igmpproxy that is shipped with openwrt.
I compiled the new version. Still no go.
No routes in igmpproxy verbose log. ip mroute shows also nothing.
Hmm. Maybe it is a problem of the igmp snooping feature.
So disabled that.
And indeed on the green zone network. igmpproxy now showed my desired route.
But it still didn't work.
My client on the red zone could not retrieve any multicast stream.
So i tried some manual firewall rules. input rules for igmp and udp multicast. also tested forward rules.
Nothing works. Only the igmp input rules showed hits.
Also the firewall log doesn't show any dropped packets.
So yeah im a bit lost. Hmm
I will test it tomorrow again. when i have more time. I also only have one wifi android phone to test from the red zone. So yeah...

//edit
Forgot to add ttl increase rule was also used.

dlakelan · March 28, 2018, 1:53am

Here's the sequence of events that I think should occur:

LAN side client sends IGMP requesting subscription
router br-lan bridge with igmp_snooping enabled sees IGMP request and unblocks the port on which it arrived.
router igmpproxy program hears the IGMP request and sends a matching request on WAN side to ISP
ISP equipment unblocks the appropriate stream and starts sending UDP to router WAN port.
igmpproxy program adds dynamic mcast route forwarding WAN side UDP with mcast dest to br-lan bridge.
br-lan bridge's igmp snooping filters the packets and sends them to only the bridge ports that had the request in steps 1,2
TV lights up and plays stream

Now, after the mcast route is created in step 5, it can STILL be blocked by the firewall, so there should be a firewall rule allowing mcast to be forwarded from WAN zone to LAN zone so that the mcast route works.

Also, there may be igmp snooping bugs, and/or wifi may interact poorly with igmp snooping.

The other way this can be done is for steps 5,6,7 to be replaced by a daemon to listen on WAN for UDP to multicast addresses and then re-send the packets on LAN... and this is what @lleachii seems to be suggesting is going on. However this is not consistent with anything I've read about online, so it's understandably strange.

If you want it to work like my steps suggest, it does seem to require a forward rule, and a TTL increment rule so that the forwarding will occur.

shm0 · March 28, 2018, 1:58am

thank you for that summary.
This is also how i would assume it should work.

lleachii · March 28, 2018, 7:45am

And this was my other warning... you require a TTL increment...why?

I surmise you're working around and bypassing igmpproxy, thereby merely dumping the packets onto your LAN.

Since...multicast packets usually have a low TTL (usually 1), this prevents routing of the packets... unless you add an increment (as the TTL would have been exceeded in transit, which should happen on an improperly configured IGMP segment). Those who managed to successfully configure redirects (those who mcast routes are working somewhere) are merely using the NAT features, those who manually create a static route will decrement their TTL.

There's also something called Uni-directional Links (e.g. IGMP request originates on LAN eth0.1 to WAN eth0.2...and is received through a stream on 3rd IPTV link like eth0.4)...see: https://networklessons.com/cisco/ccie-routing-switching-written/multicast-igmp-proxy/

I'm not sure igmpproxy accounts for UDL scenarios like this.

Mushoz · March 28, 2018, 8:24am

This is incorrect, you misunderstood me. The init.d script that accompanies the Lede version of IGMPProxy has a bug, not igmpproxy itself. This script does 3 things more or less:

It adds the required firewall rules (<- the bugged part)
It converts the UCI igmpproxy config file at /etc/config/igmpproxy to a native igmpproxy file at /var/etc/igmpproxy.
It launches the igmpproxy daemon with the required switches (config location at /var/etc/igmpproxy, optionally some verbosity switches)

The daemon itself creates the proper routes as can be viewed by ip mroute when watching iptv and is not affected by the bug in the startup script.

Not true, because igmpproxy wouldn't be adding the required multicast routes.

That's how I understand igmpproxy as well, however, there is 1 major reasons to believe that this isn't (fully) the case:

@lleachii requires an INPUT to get his setup to work. A FORWARD rule results in a non-working setup for him.

What I think would be an interesting test, would be for @lleachii to run the following command:
tcpdump -i <DownStreamInterfaceWithIptvDevice> dst net 224.0.0.0/4

While watching IPTV. IF igmpproxy does indeed proxy the UDP traffic itself, I would except the visible multicast stream to show a source IP from the router. If it does not, I would expect an external source IP from the ISP's network. For me I am certainly seeing a large stream of the latter:

10:26:48.427748 IP 213.75.167.6.44582 > 224.0.251.124.8248: UDP, length 1328
10:26:48.428527 IP 213.75.167.6.44582 > 224.0.251.124.8248: UDP, length 1328
10:26:48.429429 IP 213.75.167.6.44582 > 224.0.251.124.8248: UDP, length 1328
10:26:48.430259 IP 213.75.167.6.44582 > 224.0.251.124.8248: UDP, length 1328

I require no such increment with my FORWARD setup. So this isn't the entire picture either unfortunately.

lleachii · March 28, 2018, 8:29am

@Mushoz we are on the same page...and I recalled you don't need the TTL rule...but these things only further prove my point.

OK...I am now clear on that point.

Agreed.

AND YOU DON'T NEED A TTL INCREMENT!!! My other clue! You could merely be redirecting the packet to an interface where igmpproxy listens and then moves the packet...that could create 'slutter.'

I will run this test...my TVs have recently done their Guide and software updates...so it may take some time, as it's hard to determine what TV programming the ISP will deliver on the ONT coax band, or over IPTV via multicast...or unicast...but I believe the proxy simply moves the packet untouched, and would have the ISP's IP and DST of multicast, with the original TTL of 1.

I'm now under the impression you have a Multicast-via-UDL scenario, though. You only need to make a FORWARD rule from UDL link (IPTV) to LAN. I am on a bi-directional link, which the scripts and igmpproxy were written for (but not noted in the software's manual)...I INPUT and the proxy receives through a socket and places on netfilter...my mcast has a route like @Mushoz's, our packets are received! Those making routes and TTL increments have bad configs.

I believe the manual improperly instructs users to make a route and/or FORWARD rule on bi-directional multicast links...the script likewise follows this (which is the bug @Mushoz's describes)...it should be an INPUT rule. Those on uni-directional links should create a FORWARD rule. Both @Mushoz and I have proper configs!

Mushoz · March 28, 2018, 9:45am

I agree with you there. Creating the routes should be handled by igmpproxy and should not be configured manually. Manual TTL increments is just a workaround to get an improper configuration to work.

Are you sure? I don't know how multicast-via-UDL works, but in that case I wouldn't have outgoing traffic on my VLAN connected to my ISP's IPTV network, right? I can see outgoing traffic from my router though:

root@LEDE:~# tcpdump -i eth0.4 src 10.0.39.67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.4, link-type EN10MB (Ethernet), capture size 262144 bytes
11:42:05.289862 IP 10.0.39.67.33535 > 213.75.119.136.50270: UDP, length 28
11:42:05.289869 IP 10.0.39.67.54793 > 213.75.119.136.50271: UDP, length 28
11:42:10.296052 ARP, Request who-has 10.0.32.1 tell 10.0.39.67, length 28
11:42:16.826103 IP 10.0.39.67 > igmp.mcast.net: igmp v3 report, 4 group record(s)
11:42:25.938807 IP 10.0.39.67.54793 > 213.75.119.136.50271: UDP, length 148
11:42:25.957142 IP 10.0.39.67.34749 > 213.75.119.131.50261: UDP, length 28
11:42:25.957142 IP 10.0.39.67.38319 > 213.75.119.131.50260: UDP, length 28
11:42:25.966145 IP 10.0.39.67 > igmp.mcast.net: igmp v3 report, 1 group record(s)
11:42:25.976303 IP 10.0.39.67.33950 > 213.75.119.131.8263: UDP, length 112
11:42:25.990694 IP 10.0.39.67.55376 > 213.75.119.136.8273: UDP, length 256
11:42:26.726117 IP 10.0.39.67 > igmp.mcast.net: igmp v3 report, 1 group record(s)
11:42:26.966117 IP 10.0.39.67 > igmp.mcast.net: igmp v3 report, 1 group record(s)
11:42:26.999215 IP 10.0.39.67.33950 > 213.75.119.131.8263: UDP, length 104
11:42:27.006129 IP 10.0.39.67 > igmp.mcast.net: igmp v3 report, 1 group record(s)

And that makes sense. The subscribe packets need to be able to reach my ISP in order for the ISP to know which channel to send over multicast.

lleachii · March 28, 2018, 9:53am

I agree, your's is likewise bi-directional...in your original config...you stated should you placed these in different zones...or something to that effect...

I don't quite understand your issue, but it surrounds this script bug...

Have you tried...if i understand correctly...fixing (reconfiguring) your firewall zones back so that they like similar to mine, upstream and downstream are interfaces in their own zones...then making an INPUT rule instead?

Mine: Upstream WAN Downstream netwokr2
Yours: Upstream IPTV Downstream LAN

I honestly think that's the point of needing a proxy - to overcome the security boundary...

But let me be clear...in igmpproxy, you specify the Interfaces not Firewall Zones. In firewall, you INPUT from <upstream_link_zone> to router on a bi-directional link, and on a uni-directional link, you FORWARD from <upstream_link_zone> to <downstream_link_zone>.