Yes these are from the "log (all)", looks like a bug to me.
On 2011-08-25, Matt Van Mater <matt.vanma...@gmail.com> wrote: > I thought that this might be a common occurrence and that it simply wasn't > in the documentation (where I looked). Is no one else seeing this same > behavior? > > By the way, this host is running as a virtual machine inside VMWare ESXi 4.1 > (I chose FreeBSD as the guest OS when I initially created the VM). > > Matt > > On Mon, Aug 22, 2011 at 5:09 PM, Matt Van Mater > <matt.vanma...@gmail.com>wrote: > >> Hi All, >> >> See my configuration at the bottom of this email. I am looking into why my >> pflog has these ambiguous entries that show source and destination as all >> zeros e.g. 0.0.0.0.0 > 0.0.0.0.0. >> >> I saw that there was a related thread earlier this year asking questions >> that was unresolved/unconfirmed and I would like to get feedback from one of >> the developers (Daniel, Henning?) to confirm my suspicions. I believe that >> these lines are a result of the log (all) statement, which logs all >> subsequent packets in a stateful session (and not just the first packets >> matching the rules). If that is true, then IMO the log entries are not very >> intuitive or useful without the true source/destination IP Addresses >> included... I can't grep for src/dst any more, now I assume I would have to >> correlate the session information some other way (e.g. sequence numbers?) >> >> So to put my questions more succinctly: >> 1) Are logs with 0.0.0.0.0 > 0.0.0.0.0 a result of the pf.conf log (all) >> statement, and are therefore an indication of a continuing tcp session? >> 2) Are there any plans to update the logging to represent the actual >> src/dst of these packets? If not, what is your suggested method for >> correlating these stateful session log entries? >> >> >> By the way, I tried to post this to the pf mailing list but got bounced >> back on the SPAM filters when trying to subscribe. Same goes for when I >> tried to email Daniel directly to resolve the issue. Can someone get in >> touch with him and inform him of the issue? >> >> My configurations: >> # uname -rsvm >> OpenBSD 4.9 GENERIC#477 amd64 >> >> >> # pfctl -s rules >> pass all flags S/SA keep state >> pass in log (all) quick on em0 proto tcp from any to any port = https flags >> S/SA keep state >> pass in log (all) quick on em0 proto tcp from any to any port = ssh flags >> S/SA keep state >> block drop in log (all) on em0 all >> pass out log (all) on em0 all flags S/SA keep state >> block drop in on ! lo0 proto tcp from any to any port 6000:6010 >> >> >> # tcpdump -ne -ttt -r /var/log/pflog host 0.0.0.0 | head >> tcpdump: WARNING: snaplen raised from 116 to 160 >> Aug 17 16:00:30.673967 rule 2/(match) pass in on em0: 0.0.0.0.0 > >> 0.0.0.0.0: P 142855442:142855478(36) ack 49382696 win 256 (DF) >> Aug 17 16:00:30.867230 rule 2/(match) pass out on em0: 0.0.0.0.0 > >> 0.0.0.0.0: . ack 93472783 win 2190 (DF) [tos 0x10] >> Aug 17 16:01:30.988858 rule 2/(match) pass in on em0: 0.0.0.0.0 > >> 0.0.0.0.0: P 36:72(36) ack 1 win 256 (DF) >> Aug 17 16:01:31.179997 rule 2/(match) pass out on em0: 0.0.0.0.0 > >> 0.0.0.0.0: . ack 93472819 win 2190 (DF) [tos 0x10] >> Aug 17 16:02:15.903119 rule 3/(match) block in on em0: 0.0.0.0.68 > >> 255.255.255.255.67: xid:0x5d366a85 flags:0x8000 [|bootp] >> Aug 17 16:02:31.301720 rule 2/(match) pass in on em0: 0.0.0.0.0 > >> 0.0.0.0.0: P 72:108(36) ack 1 win 256 (DF) >> Aug 17 16:02:31.492758 rule 2/(match) pass out on em0: 0.0.0.0.0 > >> 0.0.0.0.0: . ack 93472855 win 2190 (DF) [tos 0x10] >> Aug 17 16:03:31.615561 rule 2/(match) pass in on em0: 0.0.0.0.0 > >> 0.0.0.0.0: P 108:144(36) ack 1 win 256 (DF) >> Aug 17 16:03:31.815571 rule 2/(match) pass out on em0: 0.0.0.0.0 > >> 0.0.0.0.0: . ack 93472891 win 2190 (DF) [tos 0x10] >> Aug 17 16:04:31.929505 rule 2/(match) pass in on em0: 0.0.0.0.0 > >> 0.0.0.0.0: P 144:180(36) ack 1 win 256 (DF) >> >> >> Thanks, >> Matt
