ipfw with nat - allowing by MAC address
eksffa at freebsdbrasil.com.br
eksffa at freebsdbrasil.com.br
Thu Apr 26 21:24:19 UTC 2007
> 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]
More information about the freebsd-ipfw
mailing list