[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!  ;)


  • LAYER 8 Netgate

    Protocol IGMP is not protocol UDP.



  • @Derelict:

    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.


  • LAYER 8 Netgate

    @Mech:

    @Derelict:

    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.


  • Banned

    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.


  • Banned

    @Mech:

    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:

    @Derelict:

    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


  • Banned

    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.

    :( >:( >:(



  • @doktornotor:

    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.


  • Banned

    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:

    Youtube Video

    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!


  • LAYER 8 Netgate

    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.



  • @Derelict:

    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.


  • Banned

    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!


  • LAYER 8 Netgate

    You know that that rule will only match traffic coming IN the LAN interface (from LAN hosts) right?



  • @Derelict:

    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.


  • LAYER 8 Netgate

    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.



  • @Mech:

    … 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



  • @jahonix:

    Why do you think so?
    It only covers traffic coming in on the IP-TV interface with destination to 224.0.0.0/4

    Hi!  :)

    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)?


  • Banned

    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



  • @jahonix:

    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.

    @doktornotor:

    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!  ;)



  • Okedoke, done some more analysis, here's a multicast breakdown per channel:

    BT Sport 1          109. 59.247. 1 > 234.81.131. 1
    BT Sport Europe      109.155. 49.25 > 234.81.131. 3
    BT Sport 2          109.159.247. 1 > 234.81.131. 2
    BT Sport ESPN        109.159.247. 1 > 234.81.130.25
    BT Sport 1 HD        109.159.247. 1 > 234.81.130.35
    BT Sport Europe HD  109.159.247.17 > 234.81.130.40
    BT Sport 2 HD        109.159.247. 1 > 234.81.130.36
    BT Sport ESPN HD    109.159.247.10 > 234.81.130.44
    BT Sport X1          109.159.247.26 > 234.81.131.92
    BT Sport X2          109.159.247.26 > 234.81.131.93
    BT Sport X3          109.159.247.26 > 234.81.131.94
    BT Sport X4          109.159.247.26 > 234.81.131.95
    BT Sport X5          109.159.247.10 > 234.81.131.96
    BT Sport X6          109.159.247.10 > 234.81.131.97
    BT Sport X7          109.159.247.10 > 234.81.131.98
    BT Sport X1 HD      109.159.247.17 > 234.81.130.85
    BT Sport X2 HD      109.159.247.17 > 234.81.130.86
    BT Sport X3 HD      109.159.247.17 > 234.81.130.87
    BT Sport X4 HD      109.159.247.17 > 234.81.130.88
    BT Sport X5 HD      109.159.247.17 > 234.81.130.89
    BT Sport X6 HD      109.159.247.17 > 234.81.130.90
    BT Sport X7 HD      109.159.247.17 > 234.81.130.84

    The spec say that there is failover source for each multicast stream, so it's safe to assume that these source IP addresses are subject to change, but we can glean that 109.159.247.0/24 is probably all channels, do I need to add these as upstream networks in the IGMP proxy?

    Cheers.



  • YES! That did it.  ;D  The  source of the multicast stream also needs to be added as a network along with 224.0.0.0/4 on the upstream in IGMP Proxy.

    Thank you for trying to help everybody anyway.  ;)  The sarcasm kept me motivated.  ;D



  • Good work.



  • @KOM:

    Good work.

    Our great firewalls, fill the hallowed closets! \m/

    I haven't had this good of a fixit high in ages.  Better than drugs!  Haven't sat down yet.  ;D



  • I've been trying to follow these instructions, but when I do a packet capture I don't even see the IGMP traffic being generated.

    My pfSense is on a VM (esxi 6) and I have no idea if that could be impacting things?


Log in to reply