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
