ipfw with nat - allowing by MAC address

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]