Date: Thu, 26 Apr 2007 21:56:58 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org Subject: ipfw with nat - allowing by MAC address Message-ID: <937e203f0704261156ia80fad3v80d12d9e09adeb07@mail.gmail.com> In-Reply-To: <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for everyone's continuing attempts to help! OK so I tried putting in the ruleset which you provided - and I hit a rock very early in the run. IPFW returns that it doesn't understand the tag option. ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 via $ifi Does this sound familiar? What should I do? On 4/26/07, eksffa@freebsdbrasil.com.br <eksffa@freebsdbrasil.com.br> wrote: > > > Ok, I got home (when I have some time) and tried exactly your rule set. > The main deal why it worked on my example and not your approach is: > > - once packets get dropped (denied) on layer2, it will never reach upper > layers > > Thus, NO OTHER action besides deny will avoid the packet getting into > ip_input or ip_output. > > This is crystal-clear on man page, on PACKET FLOW session, and yes, > sometimes we just ignore the man pages, this si why I found very strange > when I tried your setup and it showed the exact behavior you described (as > I didnt expect). > > What was happening: > > When you skipped packets on layer2 to somewhere-else, it was ONLY skipped > for layer2. Since the packet was still in the network stack, when it > hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. > In your set, the DIVERT rule matched the packet, and it obviously got > diverted. > > What I did to find it out was: > > tail -f /var/log/security | grep 1203 > > Among other "debug funs", using the ruleset present in the body of this > message. > > So, we can be sure that SKIPTO, ALLOW or anything else on Layer2 will > NEVER avoid a packet getting filtered on upper layers. > > So, what we needed? A way to identify packets the we dont want to divert. > Which packets we dont want to divert? That ones that, while were flowing > on Layer, DID NOT match the ruleset comparing MAC address. We need to > point the finger and say: > > - Hey, you dont have the allowed MAC address, so you wont get diverted > > Or we could finger: > > - Hey, you have the allowed MAC, so you will be diverted. > > Doesnt matter for the system, matters for who is making the rulesets. But > how to do this? > > My approach was tagging the ones that did not have the allowed MAC. > > Please, read rule 501. > > Its action is skipto. Why? Because I was lazy and did not want to rewrite > it as a "count" rule, because in fact, it does NOTHING to the current > ruleset. It skips to somewhere were there is no layer2 rules. So it skips > to nowhere and the packet reaches the "allow from any to any" while on > layer2 flow. Meaning, it only tags. That is enough. > > Later, on rule 203 and 205 (selective divert) we only divert the packets > that was not tagged (the allowed MAC). Please note that rule 501 is about > the internal interface. If we make a mistake and do it for all interfaces, > our own (as "our own" pleas read: "the firewall, "me") packets will get > tagged 1. This is not what we want. > > Please keep reading: > > --------------------------------------------------------------------- > > # MY TESTING RULESET > > my_mac="00:17:31:df:bc:ab/48" > my_net="10.69.0.0/16" > ife="vr0" # external if > ifi="xl0" #internal > > /sbin/sysctl net.link.ether.ipfw=1 > > ipfw -f f > > ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC > $my_mac any } layer2 // try lubomir_s approach > #ipfw add 301 skipto 1200 ip from any to any MAC $my_mac any layer2 // not > needed since lubomir_s approach worked fine > #ipfw add 500 deny all from any to any layer2 > ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 > via $ifi // skipto only on L2 and tag for further ch > ipfw add 1200 count log all from any to any layer2 // somebody passed here > - check the logs > ipfw add 1203 divert 8668 log logamount 0 ip from $my_net to any out via > $ife not tagged 1 > ipfw add 1205 divert 8668 log logamount 0 ip from any to me in via $ife > not tagged 1 > ipfw add 1240 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted > ipfw add 1250 queue 1 ip from any to any src-port 80 via $ife not layer2 > ipfw add 1251 queue 1 ip from any to any dst-port 80 via $ife not layer2 > ipfw add 1300 queue 2 ip from any to any not src-port 80 via $ife not > layer2 > ipfw add 1398 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted - since one_pa > ipfw add 1399 count log logamount 0 all from any to any not diverted not > layer2 // lets see whos got here undiverted > ipfw add 1440 allow ip from any to any > > ipfw queue 1 config weight 10 mask src-ip 0x000000ff pipe 1 > ipfw queue 2 config weight 2 mask src-ip 0x000000ff pipe 1 > ipfw pipe 1 config bw 4Mbit/s queue 30 > > --------------------------------------------------------------------- > > Maybe the better and more clear (to read and understand) approach would > be: > > - tag on laye2 packets with the ALLOWED MAC > - on upper layers, only divert packets tagged 1 > - be sure no other rule will tag packets with tag 1 > - be sure ng_tag wont tag packets with tag 1 > > Anything else on FreeBSD besides ipfw and netgraph are able to tag > packets? Probably not right now. Maybe a geom class one day (hehe, just > kidding..). PF tags are not compatible with ipfw/netgraph ones so, no > special attention is required. > > Hope I could help you better this turn. > > > > > > OK, so let's get started. Here's my ruleset - > > > > 00300 131732 19262748 skipto 1200 ip from any to any { MAC any > > 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 > > 00500 4723 1941536 skipto 1400 ip from any to any layer2 > > 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out > > via > > fxp0 > > 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 > > *01250 410160 534966441 queue 1 ip from any to any src-port 80 via > fxp0 > > *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via > fxp0 > > *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 > via > > fxp0 > > 01400 12581325 6691776490 allow ip from any to any > > > > I've marked the dummynet rules with an asterisk. I'm using Patrick's > > ruleset > > - since I'm only allowing internet access for a single machine I've > > combined > > his first two rules into one. My internal network is 192.168.1.0/24 and > my > > external iface is fxp0. What I'm experiencing right now as I'm using > this > > set is this - I have internet on this machine I desired /OK/ and on all > > others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For > > me, > > the rules that concern layer2 don't do what they're supposed to and > thusly > > the traffic reaches rule 1203 and 1205 and onward. Interestingly enough > > traffic does hit the first and second rule. Here's my uname - > > > > FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 > > 10:54:10 > > EEST > > 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 > > > > And my sysctl - > > > > bogoqho# sysctl -a | egrep "one_pass\|ether" > > bogoqho# > > > > which as you can see returns nothing using the command you instructed me > > to > > use. > > > > If there's anything that would help you - just say the word... Let's > > brainstorm :) > > > > -- > > mEsS wItH tHe bEsT > > dIE liKe tHe rESt > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > -- mEsS wItH tHe bEsT dIE liKe tHe rESt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?937e203f0704261156ia80fad3v80d12d9e09adeb07>