23.01.b.20230106.0600 IGMP proxy stops TV stream
-
@haraldinho said in 23.01.b.20230106.0600 IGMP proxy stops TV stream:
Ok, pasting 45.57.40.1:443 into a browser leads to a site with a blocked Netflix certificate. So that gives some idea into what the box tries to do. The other IP, 52.19.109.21:443 does not reveal any information as far as I can see.
Indeed see my post above where I ask you to use my FW rules and delete all other rules for these two interfaces. You are blocking too much traffic which causes different issues. NTP, DNS issues but also proven by the logs that Netflix traffic is denied.
-
@thebear @haraldinho
It seems I got it to work; both live TV and recordings can be paused now! See the screenshots of my settings. I will keep these settings, and see if they remain working :).I disabled the rule in IPTV VLAN to LAN net. Can I put that back, and only grant access to "This firewall" and ports 53 (DNS) and 123 (NTP)?
-
@thebear Thanks for the settings! I was busy in the past days, but this afternoon I changed my settings to match the above. I struggled a bit with the "IP Options": it took me some time to realise I had to enable those for the lines with the settings wheel in front of them to get it to work. I am currently testing to see if this resolves my issue that after some time you cannot unpause paused recordings. And I am monitoring my logs to look out for blocked calls.
Question for @thebear: it seems to me the way you have set your rules up is allowing basically all IGMP and UDP traffic into the IPTV_WAN interface, rather than from specific IP ranges? I understand it is more future proof but isn't that a security risk? -
-
Is the 213.76.112.0/21 too limited?
-
@haraldinho firewall and nat are two separate things.
Can you post your FW rules for IPTV WAN and IPTV LAN?
Via IGMP is the box requesting streams, the streams could be source from multiple subnets. Therefore its way to complex to filter on the sources, software updates comes from 10.a.b.c. and streams from other sources.
Regarding security, it's not the internet. It's a private IPTV vlan within your ISP. That reduces the risk for an attack with a million percentage. But yes hack could occur always, every minute your pfSense instance is attacked on the WAN internet interface.
-
@haraldinho My logs are clean now, no IPTV WAN and VLAN anymore. Pausing of live TV and recorded programma is working. But not at home (holidays...) so no recent experience to share.
The "cat sitter" is mostly streaming YT :). -
-
@haraldinho Same as my settings. Are your settings at NAT and IGMP also like mine (I posted them a few days ago).
-
-
I'm not seeing a mistake in the share configuration parts, don't know where you hitting the default deny log rule. I'm sorry
In generic the fixed the issue in the GUI where we where not able to add 0.0.0.0/0 that's fixed for now.
I have added some more security to the ruleset, there is no traffic allowed to the other LAN components when "the hacker" has access to the STB.
WAN
LAN
-
@thebear @haraldinho
I read about solving the GUI issue as well (0.0.0.0/0 is possible now).@haraldinho Perhaps clearing the stating table via the "x" in the firewall rules on IPTV_WAN and IPTV_VLAN solves your issue? Or rebooting the Netgate...
@thebear thanks for the extra security; that's partly going back to what I had. What extra settings do you have in the firewall rules flagged with the 3 thicks in the box; the second WAN rule and rules 2 and 3 at your LAN rules?
-
@michiel said in 23.01.b.20230106.0600 IGMP proxy stops TV stream:
@thebear @haraldinho
I read about solving the GUI issue as well (0.0.0.0/0 is possible now).Way more cleaner to read.
@haraldinho Perhaps clearing the stating table via the "x" in the firewall rules op IPTV_WAN and IPTV_VLAN solves your issue? Or rebooting the Netgate...
Good point!
@thebear thanks for the extra security; that's partly going back to what I had. What extra settings do you have in the firewall rules flagged with the 3 thicks in the box; the second WAN rule and rules 2 and 4 at your LAN rules?
Only enabled logging to see if I can narrow down the rules further more. But don’t want to spend more time at it. The chance of being attacked over vlan4 is almost none by allowing only UDP multicast. With the LAN rule blocking to the other LAN segments, if they where able to take controle over the STB, makes the attacker only look on that vlan. My STB is the only device in that VLAN.
-
@thebear I understand. And what is defined in LAN_v4_v6? My idea was to allow DNS (53) and then block LAN-net…
-
@michiel said in 23.01.b.20230106.0600 IGMP proxy stops TV stream:
@thebear I understand. And what is defined in LAN_v4_v6? My idea was to allow DNS (53) and then block LAN-net…
In that alias are all my other lan subnets v4 and v6.
The STB communicates with the KPN NTP and DNS servers and that’s handled via the last rule. My STB is not using any pfsense service like NTP or DNS. The DHCP sever for this VLAN is handing out the KPN dns servers :)
-
@thebear @michiel I think I figured it out. For some reason asymetric routing seems to happen. So some packets sent by the box through route A return to the box through route B. No clue why. But after reading about this issue in this article on the Netgate website I enabled "Bypass firewall rules for traffic on the same interface". For now, it seems that the logs are now clean.
-
@haraldinho do you have multiple routers in your network?
-
@thebear Nope, only multiple VLANs. The comment with this option is "This option only applies if one or more static routes have been defined. If it is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be desirable in some situations where multiple subnets are connected to the same interface."
-
@haraldinho do you be sure you did not disable the whole security layer?
Is it a router with one or two ports?
This option only applies if one or more static routes have been defined. Is that your case?
-
This post is deleted!
