One non-logging rule on interface yields logs - how?

  • I once wrote about a "logging inconsistency" and turned out to be mistaken, due to a messy setup of multiple port mappings for several internal non-standard ports and also duplicates in port forward table due to multiple editings and some having logging on and others not etc…

    Messy it was.

    Now however, after having looked at this for a while, I cannot see what I am missing, and there's no port forwarding even involved.

    And yet I see strange logging again in system logs / firewall. (I have been looking into similar issues earlier and haven't been able to pin point things in log but haven't written anything about it.)

    I have used logging for some rules sometimes on WAN side to be able to troubleshoot and still have them on for a few rules.

    Now - on firewall tab under system logs - I see logged connections from LAN interface, going outbound. And looking on LAN tab I have ONE rule, the normal "allow anything out" rule and it is not logging and has never been logging.

    Also, when pressing the green arrow for the info on triggering rule, the pop-up turns up blank, unlike the other triggered entries from the WAN side, which are indeed correctly filled in.

    Can someone tell me what's going on? Am I mistaken or is there something not working correctly?


  • Rebel Alliance Developer Netgate

    To really get to the bottom of it, we'd probably need to see the output of both these commands run at the same time:

    pfctl -vvsr


    clog /var/log/filter.log

    Some amount of sanitizing may be needed on those if you want to hide IPs, etc, but try not to go overboard :)

    You may also need to factor in that some packages can add rules (some that log) dynamically. UPNP is especially known for doing this.

    It may also help to install the latest Dashboard package if you haven't already - I have included in it many improvements to the log parsing and rule finding code.

  • Ok, I'll check.

    I have not seen this earlier, logging from that interface.
    And UPnP has never been activated.
    Doing a quick nslookup on the IPs that are repeatedly shown tells me it's a well known open source ftp-site, so the traffic seems to maybe be ftp client traffic from the LAN.


  • Rebel Alliance Developer Netgate

    Ah, yeah, I think the FTP proxy does put in a logging pass rule, but I forget the circumstances that lead to that. I don't remember if it's all the time or just in certain scenarios.

    Looking at the output of pfctl -vvsr should show the rule if you catch it while doing an FTP transfer.

    That's the problem with looking at logs that refer to dynamic rules… if the rule disappears, you can't tell what really caused the log entry.

  • Nice to hear an explanation :)

    I'll try and check that during ftp transfer later, just to see. Always nice to learn something new.


  • @jimp:

    It may also help to install the latest Dashboard package if you haven't already - I have included in it many improvements to the log parsing and rule finding code.

    Another thing (relating to question,16268.0.html): does the Dashboard package in any way alter the menus?
    I'm asking since I did install the Dashboard package - looking nice BTW - and can't remember having seen the 4 entries under "VPN" before.
    And no one has come forward telling me I'm all confused and remembering incorrectly about that either..


  • Rebel Alliance Developer Netgate

    I suppose it could have, but I'd have to check. I didn't write that part of it, I'm just maintaining what's currently there for the time being :)

    I'll have to find a stock copy of index.php and compare. If they are supposed to be in other places, I'll fix it in the dashboard package.

  • Rebel Alliance Developer Netgate

    Yeah the Dashboard was moving that.

    I'm not sure it will fix itself unless you do a firmware update and then reinstall the Dashboard package though, as you'll need a fresh copy of /usr/local/www/

Log in to reply