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
