Lan multicast is being blocked by default rules



  • New to Pfsense here, I setup about a week ago, but in the last few days noticed 169.254, 224.0, and 239.255, and I think 255.255 being blocked by default rules on the LAN. I used ntopng to verify it’s valid traffic, but it’s all being blocked. I found posts with similar issues over the years but don’t see any setting to allow this traffic. I added lan rules to allow it but don’t remember seeing this the first week. Shouldn’t the lan allow this kind of traffic to flow between lan devices? I have the block private and boson networks off for the lan interface.



  • Blocked which direction?  Some of those, such as 169.254.0.0 /16 and broadcasts are not supposed to be routed.  Multicast may need some configuration.  However, pfSense does not block anything that’s only on the LAN.


  • Netgate

    pfSense is not in the picture for communications between LAN hosts. They happen on LAN. Perhaps your switch (or wi-fi gear) is getting in the way.



  • The traffic is between hosts on the lan only, I see apple devices like iPhone, watch, etc. but also from DirecTV receivers using 169. Pfsense is connected to an hp2520 switch which is connected to ethernet devices and wireless via 2 AirPort Extreme routers. Pfsense show a bunch of blocked traffic for these ranges. Should I just add rules for them?


  • Netgate

    Those addresses are supposed to be link-local only (Assuming 169 really means 169.254):

    https://en.wikipedia.org/wiki/Link-local_address#IPv4

    If you have a vendor that expects them to work across routed subnets, you need to have a conversation with them and ask what you are supposed to do to route APIPA addresses across a router.

    Any answer other than “you can’t expect that to work” is a wrong answer.

    It does not matter if they are connected via a switch as long as they are on the same layer 2 broadcast domain.

    If your Airport Extreme “routers” are actually behaving as “routers” that might be part of your problem.

    If they are acting as wireless bridges (access points) their clients should also be on the same broadcast domain as your “LAN.”

    Are you just seeing the log entries or is something actually not working?



  • Yes they are 169.254, airports are in bridge only not in router mode,everything appears to be working even AirPlay. Seems only the log shows blocks. Ntopng shows the these addresses between lan devices only. An allow rule eliminates the log entries. I just thought they should not need the rules.


  • Netgate

    I would, instead, add a reject rule and disable logging on it if those logs really bother you. No reason to pass traffic that should not be passed.



  • The problem is that they flood the log, way more than anything else. Will see what happens with all blocked and will update if anything important crops up that may be of interest. Thank you very much.



  • The traffic is between hosts on the lan only,

    Then pfSense has nothing to do with it.  It only filters traffic between the LAN and WAN.  Other than the DHCP function, you could remove it completely and you wouldn’t see any difference for traffic between hosts on the LAN.


  • Netgate

    Some stupid host is probably sending that traffic to pfSense for processing - resulting in log spam.


  • Rebel Alliance

    169.254 should not be logged on lan side interface… Unless he has bogon selected on the lan and set to log?

    List in bogon table…
    “169.254.0.0/16”

    PFsense should just ignore broadcast traffic on the lan… My guess is he enabled bogon blocking on his lan interface…



  • Block private networks and block bogon for LAN has been off since day one. I agree this should not happen, still trying to figure it out. Here are examples of blocked (I added an easy rule but before that it was trapped by the default rule):

    LAN Easy Rule: Passed from Firewall Log View (1510441518)   169.254.200.84:49152   239.255.255.250:1900 UDP
    LAN Easy Rule: Passed from Firewall Log View (1510441518)   169.254.9.203:49152   239.255.255.250:1900 UDP
    LAN Easy Rule: Passed from Firewall Log View (1510441518)   169.254.9.203:52613   224.0.144.1:52613         UDP

    Also, according to ntopng it is on multiple devices, iPhones, watches, DirecTV receivers, Philiphs hue hub.


  • Rebel Alliance

    well yeah there is going to be a bunch of that noise… I don’t log default block which is prob why I am not seeing it… I only turn that on if troubleshooting something.  I setup a specific block rule that only blocks syn traffic.  I don’t care to see out of state blocks, or noise like that.



  • This is all new to me since my old router never displayed those in the logs. If this is normal I guess it’s OK to let it pass. As for logging, I always looked at the log every day to see who is attacking. Right now I am puzzled why default rules should not log. But maybe when I add some tools like pfblockerng, suricata, etc. which I am still reading about they may take the place of logs. Thanks for the info.


  • Rebel Alliance

    “I always looked at the log every day to see who is attacking.”

    Noise on the internet is not attacking 😉  I log the syn traffic… But I don’t want to see all the noise… Out of state, UDP, etc.

    Your off the shelf router wasn’t logging shit 😉



  • It was a Zyxel USG100, it email thousands of blocks every midnight from the 2 WANs, I saw attempts from around the world lasting up to 48 hours trying different ports, I assume that’s an attack. Pfsense seems to be catching (or logging) more things so it’s clearly much better at blocking. Pfsense is great, I will never go back! Can’t wait to figure what blocking packages to install.



  • @johnpoz:

    “I always looked at the log every day to see who is attacking.”

    Noise on the internet is not attacking 😉  I log the syn traffic… But I don’t want to see all the noise… Out of state, UDP, etc.

    John

    Could you give an example of "just logging syn packets"
    I suppose you have a specific block rule with logging enables , and ANY w. SYN ,
    and then a block rule wo. logging or ??

    TIA
    /Bingo


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy