• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

NAT Logging done right

Scheduled Pinned Locked Moved Development
4 Posts 4 Posters 1.8k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B
    bragatto
    last edited by Sep 1, 2021, 12:21 AM

    Hi,

    There are several questions regarding NAT Logging on this forum but it doesn't seem there's definite answer for them. I suspect maybe there isn't one because pfSense lacks a reliable solution for this problem. So, I’m opening this thread in an attempt to collect information on what's currently possible to do regarding NAT Logging and to explore more elegant solutions that could be implemented.

    Logging addresses translations is essential for troubleshooting and to identify hosts in case of abuse or malicious use of resources. There are even legal implications when an operator must respond to a subpoena or court order and disclose which host in the network performed a given request.

    So, the question I’m raising is: How can pfSense reliably log all addresses translations on a global scope?

    Most answers to questions regarding this subject says you should enable logging for every existing firewall rule that allows traffic, in order to get translations logged in. However, since this is a manual process, as the number of rules increase it becomes more likely that one of them might not be enabled, resulting in translations not being logged.

    Ideally, pfSense would implement RFC8158[1] and send translation information via IPFIX, or at least some sort of NAT-LOG[2] implementation to have information sent over Syslog. Although softflowd[3] doesn’t seem to support IPFIX, I have looked into it for this task, but since it relies on promiscuously capturing packets over the wire, it doesn’t have access to the connection states in order to retrieve the translation information.

    I’m not very familiar with FreeBSD, so excuse me for any wrong assumptions going forward. From what I can tell, FreeBSD allows NAT to be done in kernel-space (ipfw in-kernel NAT) or user-space (natd daemon), with the kernel-space being preferred for performance and used by pfSense.

    When pfSense runs in HA, it uses pfsync to sincronize the states over the standby firewall. According to the manpage:

    State changes can be viewed by invoking tcpdump on the pfsync interface.

    So I believe what I’m looking for is a daemon that reads the pfsync interface to export all addresses translations. Does anything like that already exists? Also, would it be possible to configure the pfsync interface for this purpose only (i.e. without having a second firewall to receive the states)?

    Alternatively, if pfSense supports natd, I could try to retrieve the information from its logs, but that doesn’t seem to be a good choice since the kernel solution is preferred.

    Anyone out there shares this same problem and is willing to work towards a robust solution?

    [1] https://datatracker.ietf.org/doc/html/rfc8158
    [2] https://datatracker.ietf.org/doc/html/draft-ietf-behave-syslog-nat-logging
    [3] https://github.com/irino/softflowd

    Kind regards,
    Eduardo Bragatto

    G 1 Reply Last reply Sep 3, 2024, 6:29 AM Reply Quote 1
    • G
      GPz1100 @bragatto
      last edited by Sep 3, 2024, 6:29 AM

      @bragatto Ever find any solution or work around to logging NAT (or DNAT specifically)?

      S 1 Reply Last reply Sep 7, 2024, 4:30 AM Reply Quote 0
      • S
        skogs @GPz1100
        last edited by Sep 7, 2024, 4:30 AM

        I think there wasn't much work in this area because it is seeking a solution in the firewall itself when such things are far more appropriate to be logged by another device entirely.

        Whether one uses a nice gagamon network tap or less reliable switch mirror ports, you can get very solid telemetry on anything you could ever want on the inside part of the network.

        The NAT logging isn't needed. If you capture it on the inside...you capture the real source/destos just fine. Some law enforcement agency comes up to you and says you had X happen and it shows your external IP...you go cool...here are the logs.

        Some people need to have log retention of traffic for years.

        If you're into this activity...you don't want a firewall log of every packet that goes through with internal/external/desto information. You want the real connection data...which pfsense has absolutely no business wasting cpu cycles on.

        Get a real SIEM. Hardware requirements are rather modest if you're only tracking metadata. If you go full packet capture...well then that starts getting more expensive on the storage side. There are enormous product suites that are designed to handle attestation and such...the firewall log of NAT is literally of less value than MAC address records.

        1 Reply Last reply Reply Quote 1
        • S
          stephenw10 Netgate Administrator
          last edited by Sep 17, 2024, 4:16 PM

          Since 24.03 there is packet flow data exporting available which could meet this requirement:

          https://docs.netgate.com/pfsense/en/latest/firewall/pflow.html

          Steve

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received