NAT Logging done right
-
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/softflowdKind regards,
Eduardo Bragatto -
@bragatto Ever find any solution or work around to logging NAT (or DNAT specifically)?
-
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.
-
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