Blocking traffic on same LAN segment



  • I am quite confused with why my firewall is logging the following blocked traffic.

    Here is the raw log
    Dec 5 14:27:51 filterlog: 484,16777216,,1461874052,em1,match,block,in,4,0x0,,128,24459,0,none,17,udp,79,192.168.10.102,192.168.10.182,56294,161,59

    My confusion is for multiple reasons

    1. The two addresses listed on on the same Ethernet segment. My firewall has an address of 192.168.10.1, so a unicast message between 192.168.10.102 and 192.168.10.182 should not even make it to the interface (switches are smart), and if they did, I would think the Ethernet address would block further processing of the message in the chip that implements Ethernet.

    2. The rule listed is that last rule, that rejects all LAN traffic not permitted by previous rules. I have a rule that allows TCP/UDP protocol for an alias of ports including SNMP port 161 traffic destined for an alias of addresses for the internal LAN devices. The implication is that that rule was not matched.

    3. Final confusion is how to interpret the raw log data, which seems to have more data than the formatted log entry. I assume that understanding all the log data will help better understand why this entry was made.

    Dec 5 14:53:58 LAN Reject other (1461874052)   192.168.10.102:52850   192.168.10.182:161 UDP
    Dec 5 14:53:58 filterlog: 484,16777216,,1461874052,em1,match,block,in,4,0x0,,128,25088,0,none,17,udp,68,192.168.10.102,192.168.10.182,52850,161,48

    I can tell em1=LAN plus I can guess what 484 and "match,block,in" mean, but that leaves ",16777216,," and ",4,0x0,,128,25088,0,none,17," plus 68 and 48 as unformatted mysteries to me.

    4. Not sure I understand how you tell the difference between blocked and rejected traffic in the raw log data either…


  • Banned

    While the documented log format for sure is fascinating when you need to do things like exporting the logs to ELK, humans normally use the human readable format.

    Untick the "Raw logs" checkbox, choose one of the options in "Where to show rule descriptions" and post some screenshots, noone's keen on deciphering this mess.



  • Thanks doctornotor but I already know how to disable and reenable log formatting.

    Do you know what the rest of the data means? Is there other log data I can look at that can explain why the firewall is even seeing this unicast traffic in the first place?



  • @hendersonmc:

    Thanks doctornotor but I already know how to disable and reenable log formatting.

    I think you missed the part where he said:

    @doktornotor:

    Untick the "Raw logs" checkbox, choose one of the options in "Where to show rule descriptions" and post some screenshots, noone's keen on deciphering this mess.

    Like he said, I dunno wtf I'm looking at. You will get more help if more people can easily understand what you're talking about.

    It's definitely strange that LAN to LAN traffic is being firewalled…


  • Rebel Alliance Global Moderator

    You are correct pfsense shouldn't even "see" unicast traffic to IP that is not his on an interface.  Are you running a bridge on pfsense?  Do you have a issue some static arp table pointing that IP to pfsense mac?

    But with dok here, posting up the normal logs would prob draw more help.  What is the description of the rule that is blocking that traffic, is it the default rule or some specific rule you created?  But again I hear you pfsense should not even notice that traffic.  Unless that traffic is being sent to pfsense because its outside the senders network (wrong mask maybe) so its actually sending it to pfsense since that is its gateway.

    For example if your 192.168.10.102 device had a mask of /25 (255.255.255.128) then that .182 would be outside its network and would send any traffic for that IP to pfsense MAC at 192.168.10.1 in that case pfsense would see the traffic and then block/reject it based upon rules.