/etc/rc.conf has: > firewall_enable="YES" > firewall_type="open" > firewall_logif="YES" I know for a fact that the 'nat' ipfw rule with a "log" keyword works: > ipfw -q nat 59000 config ip 192.168.5.3 reset log But tcpdump complains about the promiscuous mode and doesn't log anything: > # tcpdump -t -n -i ipfw0 > tcpdump: WARNING: ipfw0: That device doesn't support promiscuous mode > (BIOCPROMISC: Invalid argument) > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ipfw0, link-type EN10MB (Ethernet), capture size 262144 bytes FreeBSD 12.0-STABLE r347548
AFAIK, it never worked like this. NAT has its own logging facilities and it doesn't know how to use BPF.
In the ipfw(8) manpage, under the section "IPv6/IPv4 NETWORK ADDRESS AND PROTOCOL TRANSLATION" it says: > log Turn on logging of all handled packets via BPF through ipfwlog0 > interface. ipfwlog0 is a pseudo interface and can be created > after a boot manually with ifconfig command. Note that it has > different purpose than ipfw0 interface. Translators sends to BPF > an additional information with each packet. With tcpdump you are > able to see each handled packet before and after translation. Does this mean that the manpage contains a wrong information?
(In reply to Yuri Victorovich from comment #2) > In the ipfw(8) manpage, under the section "IPv6/IPv4 NETWORK ADDRESS AND > PROTOCOL TRANSLATION" it says: > > > log Turn on logging of all handled packets via BPF through ipfwlog0 > > interface. ipfwlog0 is a pseudo interface and can be created > > after a boot manually with ifconfig command. Note that it has > > different purpose than ipfw0 interface. Translators sends to BPF > > an additional information with each packet. With tcpdump you are > > able to see each handled packet before and after translation. > > Does this mean that the manpage contains a wrong information? This entry belogns to NAT64 module, it should work.
I see, this is for ipfw_nat64. I don't think that this manpage describes how to use logging with ipfw_nat.
(In reply to Yuri Victorovich from comment #4) > I see, this is for ipfw_nat64. I don't think that this manpage describes how > to use logging with ipfw_nat. It looks like something should be showed by `ipfw nat N show log` command. :)
(In reply to Andrey V. Elsukov from comment #5) No, actually: > $ sudo ipfw nat 998 show log > ipfw: Error getting nat 998 instance info: No such file or directory kernel log: > 78332 ipfw CALL socket(PF_INET,0x3<SOCK_RAW>,IPPROTO_RAW) > 78332 ipfw RET socket 3 > 78332 ipfw CALL getsockopt(0x3,IPPROTO_IP,IP_FW3,0x800697000,0x7fffffffd92c) > 78332 ipfw RET getsockopt -1 errno 2 No such file or directory > 78332 ipfw CALL write(0x2,0x7fffffffd180,0x6) > 78332 ipfw GIO fd 2 wrote 6 bytes > "ipfw: " > 78332 ipfw RET write 6 > 78332 ipfw CALL write(0x2,0x7fffffffd280,0x23) > 78332 ipfw GIO fd 2 wrote 35 bytes > "Error getting nat 998 instance info" 'sudo ipfw nat 998 show config' works though.
(In reply to Yuri Victorovich from comment #6) Sorry, I take this back. "log" wasn't in it. Now it shows something.
It shows this: > # ipfw nat 998 show log > ipfw: unknown redir mode > ipfw nat 998 config log reset reverse[root@yv /tmp]# I was expecting to see the log of packets. It definitely altered some packets.
This doesn't look very hard to add such support. I'll try this at the end of week. For now you can add "count log" rule just after nat rule, in case of one_pass=0 it will show translated packets.
Created attachment 206306 [details] Proposed patch (untested) Can you try this patch? It adds to ipfw_nat module support of logging via ipfwlog0. You need to rebuild kernel or ipfw_nat kernel module, then create ipfwlog0 interface and enable logging with "log" keyword in the nat instance. Then you can capture packets before translation and after. The only exception is "nat global", packets before translation will not be captured for such configuration.
Created attachment 206307 [details] Proposed patch (untested) Added rule number to the logging info.
Yuri, are you still interested in testing the patch?