IPFW In-kernel NAT -- Visibility into Dropped Packets, State Table?

jef

Active Member

Reaction score: 21
Messages: 143

I'm working through a puzzle with a new ipfw configuration and am trying to confirm if the packets are being dropped by the in-kernel NAT (called by nat tablearg ip4 from any to any [recv|xmit] table(nat_from_if)) or if there is something else going on.

While natd(8) has the -log_denied option, I don't see anything equivalent for ipfw configuration. The log option only appears to provide counts of connections, unless I'm missing something somewhere.

It would also be valuable to see if anything is getting through to the NAT that shouldn't be on a continuing basis.

I don't know that it was ever possible to "dump" the current NAT state table, but if there's a way to do that, it would be helpful as well.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,005
Messages: 31,463

The log option only appears to provide counts of connections, unless I'm missing something somewhere.
I don't use ipfw(8) myself but:
Code:
     log [logamount number]
             Packets matching a rule with the log keyword will be made
             available for logging in two ways: if the sysctl variable
             net.inet.ip.fw.verbose is set to 0 (default), one can use bpf(4)
             attached to the ipfw0 pseudo interface.  This pseudo interface
             can be created after a boot manually by using the following
             command:

                   # ifconfig ipfw0 create
If I read that correctly the logged packet will be available on the ipfw0 interface, you should be able to run tcpdump(1) on that.
 
OP
OP
J

jef

Active Member

Reaction score: 21
Messages: 143

Thanks, yes the log feature for ipfw(8) is very useful as it will log when a specific rule's condition matches. For debugging one can "tag" packets of interest early in the rule set and periodically count log tagged NNNN to trace their flow. Putting the tagging and logging into a numbered rule set lets one easily enable/disable tracing, without reloading the rules.

I'm looking for something a bit different though. The nat rule always matches just prior to passing the packet to the in-kernel NAT and would always log at the rule level. I'm trying to log did the in-kernel NAT drop the packet after it was passed it by the ipfw rule matching?
 

VladiBG

Aspiring Daemon

Reaction score: 261
Messages: 635

To enable logging on the nat rule use:
ipfw nat nat_number config log
 
OP
OP
J

jef

Active Member

Reaction score: 21
Messages: 143

While adding log to the ipfw rule will log when the rule matches, it unfortunately does not seem to change the logging behavior of the in-kernel NAT itself.

In the days of 30 Mbps lines, the user-space NAT daemon wasn't an overwhelming burden. Now that residential lines are more than an order of magnitude faster, I'd prefer to keep things neatly in the kernel, without the need for additional system-critical processes and their supervision.

Packet tee and diversion to netgraph is certainly a good way to see packets that exist. Part of the challenge is that if a packet is dropped by the in-kernel NAT, you're looking for the absence of a packet that previously was there.
 
Top