From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 01:06:55 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C2E316A401 for ; Fri, 27 Apr 2007 01:06:55 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id C0B7913C44C for ; Fri, 27 Apr 2007 01:06:53 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l3R16tuj074528; Thu, 26 Apr 2007 22:06:55 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Thu, 26 Apr 2007 22:06:43 -0300 User-Agent: KMail/1.9.5 References: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> In-Reply-To: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704262206.44161.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 01:06:55 -0000 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