[Solved] Firewall rule applied inconsistently
-
Just ignore that screenshot
Wonderful… You have shown us zero info regarding UDP being blocked. Good luck. While you keep blocking IGMP, the IPTV thing obviously will NOT ever work.
-
It's very difficult to screenshot a complete absence of packets ;) The very first screenshot is showing the UDP hit the external interface. I can do a packet capture on my LAN side if you want but it will just show that the UDP doesn't make it there. The problem is that I have a pass rule for that UDP, but no UDP getting to the LAN interface, now if Derelict is to be believed:
Someone correct me if I'm wrong but isn't the only thing logged on a pass rule the packet that creates the state, not subsequent packets? Logs would quickly be unwieldy if otherwise.
Then my logs indicate that the UDP is getting passed off the External IPTV interface, which leads me to believe that the router doesn't know they go to the LAN. I need to get these passed packets to the LAN. Can you help. Trust me, IGMP is working, if you really insist I will make a video demonstrating the IGMP Joins going out and triggering the UDP.
Thanks! :D
-
Have you configured the IGMP proxy yet? How? So, really… you have a "cluttered" (one page!!!) thread, not even a day old. Now you start another, with half info missing and half of the info irrelevant. Don't have time for this.
:( >:( >:(
-
Have you configured the IGMP proxy yet? How? So, really… you have a "cluttered" (one page!!!) thread, not even a day old. Now you start another, with half info missing and half of the info irrelevant. Don't have time for this.
:( >:( >:(
Because none of that is relevant any more. I fixed all that stuff. This is a different problem, I thought you would appreciate a decently ordered page with lots of info on it without unnecessary clutter, I thought it would make troubleshooting easier! Here, I'm going to make troubleshooting even easier! I'm uploading a video demonstrating everything.
-
To summarize this:
- your IPTV doesn't work
- you have a shitton of blocked IGMP traffic in the logs
- your IGMP proxy settings are unknown
- instead of allowing the traffic and providing the requested info, you start a duplicate thread, produce a messy drawing not even showing the IPs/subnets and are making a video of the issue…
-
Hey, I know you deal with a lot of idiots around here, so it's easy to assume everyone is one. But you seem very bitter and antagonistic about everything, so cheer up! If I'm being an idiot I will gladly admit it, but I don't think I am. Just watch the video, it covers all your points. I said the drawing was crude myself, but it conveys enough to understand what is going on and demonstrate this is not an IGMP problem any more. Hence why I started a new thread. Just watch the video and remember we are all people, we all deserve a little respect. I respect your knowledge, that is why I am still asking you for help, as long as you can respect the fact that I'm not some prat who's just posted this after only spending a few minutes looking at it themselves, then we will have no problems. ;)
If you want the full technical details, then knock yourself out. But be aware that I've already read it and understand it and condensed it here. Like I say, (and the video will demonstrate) IGMP ain't the problem.
Video is here:
As you can see, IGMP correctly subscribes me to a stream and unsubscribes me. The UDP hits the firewall IPTV interface and ALL I NEED is to get that onto my LAN.
Thanks!
-
As you can see, IGMP correctly subscribes me to a stream and unsubscribes me. The UDP hits the firewall IPTV interface and ALL I NEED is to get that onto my LAN.
So put a rule on the IPTV interface passing the traffic.
-
As you can see, IGMP correctly subscribes me to a stream and unsubscribes me. The UDP hits the firewall IPTV interface and ALL I NEED is to get that onto my LAN.
So put a rule on the IPTV interface passing the traffic.
Hi, sorry about late reply, I went out. Thanks for your earlier answer by the way, about only one pass log per stream, it makes a lot of sense actually. So with that in mind, I already have a rule in place, 3rd picture of the first post, 1:30 in the video. It does pass the UDP and that is what we were talking about. So it is marked as pass in the logs, but it's not going to the LAN, therefore I think the router doesn't know that 224.0.0.0/4 belongs on the lan, and I need to set up a gateway/static route to get it there, does that make sense?
Many thanks.
-
Dude, that's the proxy job. Perhaps it'd work better if you finally stopped blocking IGMP. ::) ::) ::)
https://doc.pfsense.org/index.php/IGMP_Proxy
-
Ok, so I've already done this in the past, but I modified my rule on the external interface to match any packet, not just UDP:
Now I'd always interpreted that last line in the wiki "A firewall rule is also required on the downstream side (typically LAN) that matches/passes this traffic which has the Advanced Options checked to Allow packets with IP Options."
To mean that the default allow any IPv4 rule covered it. But just for good measure I added another (at the bottom):
It still doesn't work unfortunately. No traffic on the LAN with or without IGMP snooping on the switch.
Thanks!
-
You know that that rule will only match traffic coming IN the LAN interface (from LAN hosts) right?
-
You know that that rule will only match traffic coming IN the LAN interface (from LAN hosts) right?
Which one are we talking about here, the default one? Yes, "Allow LAN to any" not the other way round, so I've added the other, "Allow any to 224.0.0.0/4" and done the same "Allow any to 224.0.0.0/4" on the External interface. That lets everything remotely multicast through. Still no UDP on the LAN though.
Cheers.
-
The one on LAN. The last one. I fact, your source LAN net rule will match first anyway.
Interface rules match connections established coming INTO the interface.
https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
-
Yep, so I have this one on the external interface as well, that should have me covered in both directions shouldn't it?
Ta.
-
… that should have me covered in both directions shouldn't it?
Why do you think so?
It only covers traffic coming in on the IP-TV interface with destination to 224.0.0.0/4 -
Why do you think so?
It only covers traffic coming in on the IP-TV interface with destination to 224.0.0.0/4Hi! :)
But coupled with the other rule on the LAN with the same parameters they do cover both directions is what I was trying to say. Is that right?
Thanks in advance.
-
Are you generating multicast traffic to 224./4 or do you want to receive and watch it (AKA consume)?
-
Afraid we won't ever learn what's 10.10.10.10, nor what are the IPs on other interfaces. But good that we now have a video and a drawing with ~27 colors, showing inexplicable things like the pinky PPPoE gateway connected to both WAN and some unknown re0 thing which in turn is connected to modem, but that WAN is somewhere behind pfSense or god knows
-
I saw this too late, I'm afraid.
27 colors is next to monochrome. I usually run my shows in 16,7m colors. SCNR
-
Are you generating multicast traffic to 224./4 or do you want to receive and watch it (AKA consume)?
I want to receive it. Well I am receiving it, but only on my external interface, it's not making it to the LAN, which is what I am trying to solve.
Afraid we won't ever learn what's 10.10.10.10, nor what are the IPs on other interfaces. But good that we now have a video and a drawing with ~27 colors, showing inexplicable things like the pinky PPPoE gateway connected to both WAN and some unknown re0 thing which in turn is connected to modem, but that WAN is somewhere behind pfSense or god knows
If you want to know what something is, just ask! 10.10.10.10 is a randomly selected 1918 IP I gave to the IPTV interface, interpreting these instructions. If you read that technical document I linked earlier you'll know that the IPTV streams come to the local cabinet over a dedicated 500mbps link and then the multicast is done from the local cabinet to the CPE.
What the diagram is trying to show is that there are 2 internal "logical" interfaces connected to one physical interface. One of them goes through a PPPoE gateway and serves my broadband connection, the other is just regular IPoE and that is the interface with the random 10.10.10.10. It could be any IP, it doesn't matter, as long as it is private.
I'm sorry the drawing is confusing to you, I made it quick and dirty. I can spend ages drawing a pretty one if you want but I'd hoped it would be useful to get the gist.
EDIT: Do I need udpxy?No, I don't.Thanks! ;)