Date: Thu, 26 Apr 2007 22:06:43 -0300 From: AT Matik <asstec@matik.com.br> To: freebsd-ipfw@freebsd.org Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address Message-ID: <200704262206.44161.asstec@matik.com.br> In-Reply-To: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> References: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 26 April 2007 19:54, Lubomir Georgiev wrote:
> Yeah! People, we can congratulate ourselves! We've done it! With a few
> modifications I've finally found the smallest working MAC filtered NAT
> system. So here's what I ended up with - I'm including the queues just for
> the entirety of the ruleset, they have nothing to do with the filtering.
>
not so loud, the honors are coming only at the end and often only after the=
=20
end :) when we are dead already :) unfortunatly of course but life is hard :
( :) =20
fun aside, even if you might be able to *block* access using a layer2 rule =
any=20
further layer2 rules as skipping in order to jump to another rule on a=20
*router* is not catching anything else as arp, means it is certainly useles=
s=20
a natd router is what the name says a router and so the legitmate traffic i=
n=20
this scenario is *IP* hitting the GW IP and *NOT* layer2, being then "route=
d"=20
to the servers default gateway - so - as long as the mac of the src-ip is i=
n=20
the arptable it's traffic goes through whatever nasty fun you do=20
with "layer2" level rules
if then exists a natd this traffic might be diverted before leaving the box
finally, here is *NO* layer2 traffic (BRIDGED traffic)=20
hence, what you can do is make traffic flow decision based on src/dst IPs o=
r=20
ports, nothing else
then, even if you (can) block layer2 mac traffic (arp) on a router it does=
=20
not touch any legitimate ip traffic, so obviously your arptable will *age=20
out* and suddenly no arp goes through (or to) this box anymore and/or=20
depending on your rules anything is diverted and you lose access to the=20
router ... so as hint, any who likes to play with arp of any kind should no=
t=20
only do ipfw flush but also run arp -ad in order to get clean and reliable=
=20
results for nasty rules "in real time" :)=20
blocking a mac by blocking arp is one thing
controlling traffic flow based on MAC is another
in order to control layer2 TRAFFIC flow you need a bridge
what follows is a thought because i never needed something like this but th=
e=20
only possible setup for *YOUR* wish I can imagin is first making it a bridg=
e=20
with no IP on the inner NIC, then associating the GW IP of the internal=20
subnet to the bridge or the external nic
if you have then two IPs on the external NIC you divert on IP and not the N=
IC
*NOW* finally you get bridged traffic (LAYER2) to the gw ip which you CAN=20
control as "skipto proto ip layer2 mac" not from authorized macs to a rule=
=20
higher than the divert rule in order not hitting the divert rule. Ok?
Resuming, as long you have a router you can not control layer2 traffic, you=
=20
only might be able to block certain arp traffic to a certain extense
Sooo, at the end this are only my thoughts and opinions, like I said before=
=20
router and layer2 with ipfw sounds strange to me so I do not use it today a=
nd=20
what I said here might work for one and not for another so please don't hit=
=20
me if you get unexpected results :)=20
some comments, no ofense pleease:
> 00100 allow ip from any to me not dst-port 8668 via xl0
> 00101 allow ip from me not 8668 to any via xl0
useless
> 00300 allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any
> 00:19:d2:36:b8:48 } layer2
not sure if you want "or" or even {}
> 00800 deny log logamount 200 ip from any to any MAC any any layer2 via xl0
this is your time-bomb which kills access to the router internally, means y=
our=20
ruleset might work until the active macs (arptable) are timing out (!on a=20
router)
> 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0
> 01205 divert 8668 ip from any to me in via fxp0
ook
> 01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0
> 01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0
> 01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0
> 01500 allow ip from any to any
> 65535 deny ip from any to any
>
whatever ... but
if your interest or concern is only with tcp:80 you might consider squid wh=
ich=20
has some kind of mac acl and you reduce your ipfw-brain-damage on this=20
issue :)
Jo=E3o
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704262206.44161.asstec>