> So I guess shit never stops... As I said I'm currently trying to use the > deny rule which you initially supplied to drop the packets which don't get > skipped. Here's my current ruleset -
Now it is a different ruleset, where you want to allow first. You have to have the flow picture in mind: > > 00100 173035 29328940 allow ip from any to any via xl0 You dont want it! since net.link.ether.ipfw is on, the above rule allows everything on layer2, when it reaches ether_demux() via xl0 device. So who will match the next rule? Probably L2 packets flowing via a different interface. What you probably want is to allow only on upper layers, on a later packet inspection when packets finally reach L3 layer and so on: ipfw add 100 allow log logamount 0 ip from any to any via $ifi not layer2 > 00300 292524 50232419 skipto 1200 ip from any to any { MAC > 00:19:d2:36:b8:48 any or MAC any 00:19:d2:36:b8:48 } layer2 Ok here, but if you do "via xl0" you will better avoid further problems, which do not exist right now, but maybe will, in a bigger setup. > 00800 0 0 deny log logamount 100 ip from any to any MAC any > any layer2 via xl0 This one is good, denying via xl0, so you wont drop your own (firewall´s own) L2 packets. > 01203 3802723 1050820011 divert 8668 ip from 192.168.1.0/24 to any out via > fxp0 > 01205 2218931 1145072418 divert 8668 ip from any to me in via fxp0 Untill Elischer´s patches reach the tree, divert will only get processed on ip_input and ip_output, so it is ok if you DO understand that, only after L2 packets get processed, packets will finally get diverted. So, the "skipto" action on rule 300 does not sends that packets to divertion. No. They only say "go try to reach other rules what understand L2 and exist". No further rule you have that satisfies it (in fact you do: the kernel rule, which allows), so, when packets reaches upper layers they will matched by this divert rule. So you will understand the bavior better if you explicitly say "not layer" for divert rules. This rules: ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC $my_mac any } layer2 ipfw add 300 skipto 1500 ip from any to any { MAC any $my_mac or MAC $my_mac any } layer2 Are just the same in your setup. If you use "allow" action instead of "skipto", it is the same too. Do you understand why? Because no further rule can make an action with L2 packets, other than deny or allow. > 01250 81843 84998617 queue 1 ip from any to any src-port 80 not layer2 > via fxp0 > 01251 64777 18975661 queue 1 ip from any to any dst-port 80 not layer2 > via fxp0 > 01300 4279821 1513380511 queue 2 ip from any to any not src-port 80 not > layer2 via fxp0 Good. To be sure we are only working on ip_*() layers. > 01500 6137984 2192285003 allow ip from any to any > 65535 5 416 deny ip from any to any They match L2 and upper layers, because no "layer2" or "not layer2" are used. Once again a working ruleset. Try to use it first, before you change, and keep the logging untill the whole ruleset is completly tested/ready to go production. (logging, makes me remember ipfw0 bpf device logging patch Rizzo has made in the past, why didnt it reach the tree? would be a lot more helpfull than the current kind of logging we have) Here is the ruleset # ipfw show 00100 2973 955186 allow log ip from any to any via xl0 not layer2 00300 2967 953994 allow ip from any to any { MAC any 00:17:31:df:bc:ab or MAC 00:17:31:df:bc:ab any } layer2 // allow everything on L2 00500 52 10586 deny log ip from any to any layer2 via xl0 01203 1422 830971 divert 8668 log ip from 10.69.0.0/16 to any out via vr0 01205 5623 3452838 divert 8668 log ip from any to me in via vr0 01250 39 7832 queue 1 ip from any to any src-port 80 via vr0 not layer2 01251 35 12373 queue 1 ip from any to any dst-port 80 via vr0 not layer2 01300 11126 6030053 queue 2 ip from any to any not src-port 80 via vr0 not layer2 01440 23275 12119240 allow ip from any to any 65535 0 0 allow ip from any to any Only that MAC, flowing via xl0, is getting diverted (because only the packets belonging to that mac can reach L3 and above layers, where things get diverted). So who is matching the deny rule that much? # grep 500 /var/log/security | tail -2 Apr 26 18:16:17 mmach kernel: ipfw: 500 Deny UDP 10.69.69.39:55937 200.167.232.15:53 in via xl0 Apr 26 18:16:17 mmach kernel: ipfw: 500 Deny UDP 10.69.69.39:55937 200.167.232.14:53 in via xl0 RIGHT, certainly someone else, with a different MAC. Just in case: # arp 10.69.69.39 ? (10.69.69.39) at 00:12:17:fb:ee:e7 on xl0 [ethernet] _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"