On 06.04.2014 11:27, Brett Glass wrote: > A bit more investigation of IPFW's behavior on VLAN interfaces has > revealed some even stranger stuff. Consider the tallies on the > following firewall rules: > > # ipfw show | head > 00001 65071 36685513 count ip from any to any layer2 via re0 > 00002 65303 36856334 count ip from any to any layer2 via re0_1 > 00003 6 3381 count ip from any to any layer2 via re0_2 > 00004 49338 35208527 count ip from any to any layer2 via re0_3 > 00005 0 0 count ip from any to any layer2 in recv re0 > 00006 65071 36685513 count ip from any to any layer2 out xmit re0 > 00007 0 0 count ip from any to any layer2 in recv re0_1 > 00008 65303 36856334 count ip from any to any layer2 out xmit re0_1 > > It looks as if, when one adds "in" and "out" to the rules, one > never sees any Layer 2 packets coming "in" on either a vlan(4) > interface or its parent. There might be a problem with general > brokenness in IPFW's "in" and "out" qualifiers when dealing with > Layer 2 packets, or something else might be wrong.... Not sure, but > this behavior is definitely weird. And note that, again, re0_1 (a > child interface) shows more packets than re0 (the parent). Weird. > Do not have experience with pf, so do not know if it would do > better, but IPFW certainly has something broken. Help in figuring > out what to propose as a patch would be MUCH appreciated.
Try to replace "count" with "allow" in the rule 6 and "count" with "count log" in the rule 8 and look at /var/log/security to find out "extra" packets that hit rule 8. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
