[Solved] Firewall rule applied inconsistently
-
Solved. Solution.
Hi, me again. I've cluttered up my other thread too much now, so I'm starting another to solve the final hurdle.
I've got UDP hitting my External interface now:
I have a rule that should be letting it through but it's consistently inconsistent and only lets one packet in while rejecting the rest.
There's not even any indication of it blocking the packets in the log. Here's the rule:
And here's the traffic it is dropping:
This no longer an ISP issue now it's purely pfSense Firewall configuration. Is it a NAT issue? Hope you can help! ;)
-
Protocol IGMP is not protocol UDP.
-
Protocol IGMP is not protocol UDP.
I realise this, sorry that picture may have been confusing but I merely posted it to demonstrate the ABSENCE of any UDP packets being logged as dropped! Despite logging being enabled in the rule. :D All those IGMP packets are from my IGMP switch, they are pretty much random clutter and can be ignored. They are past static groups that are still in the snooping table and that the switch is still querying.
-
Perhaps a crude diagram will help here?
The only remaining problem area is how to get the UDP that is arriving on the IPTV interface onto the LAN interface. The network address can stay exactly the same, which means I don't want a NAT rule, correct? I just need to bridge it onto the LAN, but only UDP.
-
Protocol IGMP is not protocol UDP.
I realise this, sorry that picture may have been confusing but I merely posted it to demonstrate the ABSENCE of any UDP packets being logged as dropped! Despite logging being enabled in the rule. :D All those IGMP packets are from my IGMP switch, they are pretty much random clutter and can be ignored. They are past static groups that are still in the snooping table and that the switch is still querying.
I don't get it. You have a pass rule, marked for logging, that isn't logging anything being dropped. That's expected behavior.
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.
-
After some thought (that's what the shower is for, right?) I think I need a static route/gateway. The router is receiving and "passing" the UDP packets but it doesn't know they need to go to the LAN interface. So I need to tell it that anything sent to 224.0.0.0/4 on the IPTV interface needs to be sent to the LAN interface.
Can someone confirm this and give me a hint on how to set it up?
Ta.
-
You certainly don't do this with a rule applied to UDP when the blocked protocol is IGMP. Sigh.
-
Kurka wodna! The blocked protocol is not IGMP, it's UDP. Just ignore that screenshot, it's causing more trouble than it helps. Take a look at the diagram I drew, IGMP goes out, it doesn't come back in. Only UDP comes back. I have the IGMP part solved, I just have to get the UDP that hits the IPTV interface with destination addresses in the range 224.0.0.0/4 to go to the LAN interface. I don't think it knows that those packets go there, so I think it needs a static route or something like that.
EDIT: To elaborate, IGMP is merely a management protocol, it negotiates streams, the actual stream itself is all UDP.
-
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.
