ipfw with nat - allowing by MAC address
OK - So I guess we might have a problem... bogoqho# uname -a FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE # I'm currently thinking about using the deny approach you initially recommended. I'll just add an allow rule via the internal iface which will still allow me to ssh in and if everything else is OK then I guess that will be it. I'll check back shortly - in the mean time if you have any suggestions, feel free. On 4/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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? tag/tagged features were commited somewhere in time between 6.1-STABLE and 6.2-RELEASE, if I remember well. So the first release to have it is 6.2-R; csup to RELENG_6 branch to get the latest -STABLE; -- 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 [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
I'm surprised you haven't tried the firewall set I sent you.. I practically wrote the whole thing for you. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw with nat - allowing by MAC address
The reason I haven't tried it is because I try to keep things as simple as possible. Your set contained *a lot* of rules which, if the ruleset I'm trying to use right now works, would be pointless. Don't take it personally - I'm very grateful for all your help. And again - if you have any ideas on how to get the ruleset I posted a couple of minutes ago working feel free to share them. On 4/26/07, Julian Elischer [EMAIL PROTECTED] wrote: I'm surprised you haven't tried the firewall set I sent you.. I practically wrote the whole thing for you. -- 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 [EMAIL PROTECTED]
ipfw with nat - allowing by MAC address
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.
00100 allow ip from any to me not dst-port 8668 via xl0
00101 allow ip from me not 8668 to any via xl0
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
00800 deny log logamount 200 ip from any to any MAC any any layer2 via xl0
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
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
Just one note - when I first reached this conclusion I had two very
strange *blackouts*. As if the 100 and the 101 rule just suddenly stop
working and I'm left out of the box e.g. I can't ssh in although the
diverting still works - I can ping hosts on the Internet. It seems to be
fine now and once I gain some knowledge I'm probably going to expand this
ruleset, but for now I've accomplished my goal!
I have all of you to thank for that! Even though it wasn't easy /mostly
because of my ignorance I'm sure/ you pulled me through.
Respect.
One last request - if someone happens to have some free time and wishes to
donate it to me I'd really like to better understand the whole *layer*
thing. I have searched the Internet for answers on this as well as read the
ipfw man page, but I can't really understand it.
\/ Peace.
--
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 [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
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.
I presume xl0 is the inside interface?
here is how you should comment your script.
# The following rules are applied at layer 2 and layer 3.
# Allow anything on the inside to talk to me directly if it wants to,
# * unless it wants to use port 8668 * (why 8668?)
ipfw add 00100 allow ip from any to me not dst-port 8668 via xl0
ipfw add 00101 allow ip from me not 8668 to any via xl0
#
# BTW also.. try not use the via keyword.. instead specify exactly what you want
# as it hides exactly what you are doing.. use in, out, recv and xmit
# (possibly in combination).
# Anything that is not to me directly is bound for the outside.
# At layer 2 we clobber any that are not 'blessed machines'.
ipfw add 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
ipfw add 00800 deny log logamount 200 ip from any to any MAC any any layer2 via
xl0
# easier written as
# ipfw add 800 deny log logamount 200 ip from any to any layer2
# In layer 2 we have no more packets by this point.
# In layer 3, only packets that escaped layer 2 alive get diverted
ipfw add 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0
ipfw add 01205 divert 8668 ip from any to me in via fxp0
# The rest is for conditionning the traffic on the external link
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
Just one note - when I first reached this conclusion I had two very
strange *blackouts*. As if the 100 and the 101 rule just suddenly stop
working and I'm left out of the box e.g. I can't ssh in although the
diverting still works - I can ping hosts on the Internet. It seems to be
fine now and once I gain some knowledge I'm probably going to expand this
ruleset, but for now I've accomplished my goal!
I have all of you to thank for that! Even though it wasn't easy /mostly
because of my ignorance I'm sure/ you pulled me through.
Respect.
One last request - if someone happens to have some free time and wishes to
donate it to me I'd really like to better understand the whole *layer*
thing. I have searched the Internet for answers on this as well as read the
ipfw man page, but I can't really understand it.
\/ Peace.
and here is how I would write it:
#!/bin/sh
INSIDE=xl0
OUTSIDE=fxp0
BLESSED_MAC=00:19:d2:36:b8:48
OUTSIDE_IP=1.1.1.1
#
# START. ALL PACKETS FROM EVERYWHERE COME HERE. #
# A packet being routed comes here 4 times. #
#
# first split up the layer 2 packets and layer 3 packets
ipfw add 100 skipto 1000 ip from any to any not layer2
###
# ## START LAYER 2 PROCESSING #
# this happens as the packet is traversing
# the ethernet driver.
# A routed packet comes here TWICE.
#
# In layer 2 just allow packets not traversing the inside
# interface as we have no interest in other interfaces.
# Now split up incoming and outgoing.
ipfw add 110 skipto 120 ip from any to any in
PACKETS EXITING ${INSIDE} #
# packet is exiting the INSIDE ethernet
# If it is not from us, and not to a blessed machine, kill it.
ipfw add 111 allow ip from any to any not xmit ${INSIDE}
#ipfw add 112 allow ip from me to any
#ipfw add 113 allow ip from any to any MAC {$BLESSED_MAC} any
#ipfw add 114 deny ip from any to any
# this is actually pointless as there will be no such traffic,
# so in fact just allow everything.
ipfw add 112 allow ip from any to any
# PACKETS COMING IN THROUGH ${INSIDE}
# If it is not to us, and not from a blessed machine, kill it.
ipfw add 120 allow ip from any to any not recv ${INSIDE}
ipfw add 122 allow ip from any to me
ipfw add 124 allow ip from any to any MAC any ${BLESSED_MAC}
ipfw add 126 deny log logamount 200 ip from any to any
##
# END OF ALL LAYER 2 PROCESSING #
##
# START LAYER 3 PROCESSING #
##
# SPLIT FOR DIRECTION
ipfw add 1000 skipto 1500 ip from any to any in
# ## OUTGOING PROCESSING
# ignore everything not on ${OUTDSIDE}.. we just don't care.
# NAT anything that is not from my outside address.
ipfw add 1100 allow ip from any to any not xmit ${OUTSIDE}
ipfw add 1110 divert natd ip from not ${OUTSIDE_IP} to any
#
Re: ipfw with nat - allowing by MAC address
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
end :) when we are dead already :) unfortunatly of course but life is hard :
( :)
fun aside, even if you might be able to *block* access using a layer2 rule any
further layer2 rules as skipping in order to jump to another rule on a
*router* is not catching anything else as arp, means it is certainly useless
a natd router is what the name says a router and so the legitmate traffic in
this scenario is *IP* hitting the GW IP and *NOT* layer2, being then routed
to the servers default gateway - so - as long as the mac of the src-ip is in
the arptable it's traffic goes through whatever nasty fun you do
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)
hence, what you can do is make traffic flow decision based on src/dst IPs or
ports, nothing else
then, even if you (can) block layer2 mac traffic (arp) on a router it does
not touch any legitimate ip traffic, so obviously your arptable will *age
out* and suddenly no arp goes through (or to) this box anymore and/or
depending on your rules anything is diverted and you lose access to the
router ... so as hint, any who likes to play with arp of any kind should not
only do ipfw flush but also run arp -ad in order to get clean and reliable
results for nasty rules in real time :)
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 the
only possible setup for *YOUR* wish I can imagin is first making it a bridge
with no IP on the inner NIC, then associating the GW IP of the internal
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 NIC
*NOW* finally you get bridged traffic (LAYER2) to the gw ip which you CAN
control as skipto proto ip layer2 mac not from authorized macs to a rule
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
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
router and layer2 with ipfw sounds strange to me so I do not use it today and
what I said here might work for one and not for another so please don't hit
me if you get unexpected results :)
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 your
ruleset might work until the active macs (arptable) are timing out (!on a
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 which
has some kind of mac acl and you reduce your ipfw-brain-damage on this
issue :)
João
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
[EMAIL PROTECTED] 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.
I'm adding code to make divert work at layer 2 too.
(We have that at work).
so be careful.
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 0x00ff pipe 1
ipfw queue 2 config weight 2 mask src-ip 0x00ff 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
ipfw with nat - allowing by MAC address
Julian if you mean thishttp://lists.freebsd.org/pipermail/freebsd-ipfw/2007-April/002957.html Then I did received it but Patrick's setup seemed much easier and he claimed that it worked. This is why I decided to try his first. But now that I've re-examined it I see that it's not that much more complicated. I will try it tonight, but it the mean time if you have time you can have a look at Patrick's ruleset. 10x everyone for your efforts. -- 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 [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
Lubomir Georgiev escreveu: Julian if you mean thishttp://lists.freebsd.org/pipermail/freebsd-ipfw/2007-April/002957.html Then I did received it but Patrick's setup seemed much easier and he claimed that it worked. This is why I decided to try his first. But now that I've re-examined it I see that it's not that much more complicated. I will try it tonight, but it the mean time if you have time you can have a look at Patrick's ruleset. 10x everyone for your efforts. The rules I sent you are still working right now ;) Just tested it again. If you could give us the pleasure to see your loaded rules when it does not work, as well as uname -a and sysctl -a | egrep one_pass\|ether, this would help to. Try to minimize your setup only to the rules you are working in, since if existing, other rules unrelated to layer2 or upper layers may be matching first. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw with nat - allowing by MAC address
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 47231941536 skipto 1400 ip from any to any layer2
01203684798449298 divert 8668 ip from 192.168.1.0/24 to any out via
fxp0
0120571215 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 [EMAIL PROTECTED]:/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 [EMAIL PROTECTED]
ipfw with nat - allowing by MAC address
H1 again. So I did try dividing the first rule up into two. But the problem still remains - all the machines on the 192.168.1.X get diverted through natd regardless of their MAC address. I don't think that the problem lies with the rule that allows the traffic rather with the ones that denies /skips/ natd traffic from the MAC not specified. Please share your thoughts on how your setup work and mine doesn't. P.S. Thanks from the dummynet heads-up! -- 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 [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
Lubomir Georgiev wrote:
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
for a packet from a client through this machine to the internet:
on the first pass (packet in ethernet receive) this skips to 1203,1205 where
nothing happens
because divert does not work on layer 2.
on the second pass (packet entering IP stack) it goes to 500 then 1203 where it
doesn'r match (not output for 1203 and not to me for 1205.
on the third pass (packet leaving IP stack, it goes to 500 then 1203 where
it diverts (is outgoing and from 192.x.x.x.), returning just in time for 1205.
on the 4th pass it (packet being transmitted on an ethernet) it goes to 500 and
thus 1400 because it now has different MAC
00500 47231941536 skipto 1400 ip from any to any layer2
01203684798449298 divert 8668 ip from 192.168.1.0/24 to any out via
fxp0
0120571215 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 [EMAIL PROTECTED]:/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 :)
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
Julian Elischer wrote:
Lubomir Georgiev wrote:
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
for a packet from a client through this machine to the internet:
on the first pass (packet in ethernet receive) this skips to 1203,1205
where nothing happens
because divert does not work on layer 2.
on the second pass (packet entering IP stack) it goes to 500 then 1203
where it doesn'r match (not output for 1203 and not to me for 1205.
on the third pass (packet leaving IP stack, it goes to 500 then 1203
where it diverts (is outgoing and from 192.x.x.x.), returning just in
time for 1205.
on the 4th pass it (packet being transmitted on an ethernet) it goes to
500 and thus 1400 because it now has different MAC
What I meant to say is that keeping all this sort of thing in mind all the time
makes it hard to debug this, which is why in my example I alwyays send the
different
passes to separate rules as quickly as possible.
00500 47231941536 skipto 1400 ip from any to any layer2
01203684798449298 divert 8668 ip from 192.168.1.0/24 to any
out via
fxp0
0120571215 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 [EMAIL PROTECTED]:/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 :)
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw with nat - allowing by MAC address
I'd like to thank all the people who replied to the thread I started. Your help has been invaluable. The reason I didn't immediately respond to Jao is that I wanted to make sure I wasn't mistaking - I was sure that IPFW + NAT + MAC address filtering in a single box was possible because I had seen it with my own two eyes. I just didn't take the time to see the ruleset then. I was going there in a couple of days and was going to shed some light on the subject but it turns out I don't need to - Patrick and Julian have backed me up. I am going to try out what you've recommended and post the results. Once again thanks for all your efforts and Jao please do try not to go all high and mighty over other seeking help when what we really want is one and the same thing - to help each other, and that I think is the purpose of this list. So, I'll keep you posted. -- 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 [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
the trick is to remmeber that check-state just re-runs the rule that had the orginal keep-state, and that that rule can be almost anything, including a skipto. What if it is a FWD? -- Patrick Tracanelli ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
ok so I just emailed how I would do this.. Did you not receive it? Lubomir Georgiev wrote: OK people - here's the deal. I have tried the setup as described by *Patrick Tracanelli at *click http://lists.freebsd.org/pipermail/freebsd-ipfw/2007-April/002956.html but the shitty thing still doesn't want to just let it be! Since I don't want to 00500 468 30071 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 I'm trying to integrate a rule that just skips the natd but still allows normal client - freebsd box communication. The problem is - I can manipulate layer2 any way I like e.g. use skipto with MAC as described and everything but as soon as I add a rule like this ipfw add 500 skipto 1400 /after the divert natd/ all from any to any not layer2 I lose worldwide connectivity. And if I don't add this rule my whole 192.168.1.0/24 segment in enabled because of the 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 Can someone please explain this? And just give the word and I'll send a more substantial part of the ruleset and the different strategies /of rulesets :)/ that I've tried. The bottom line - Patrick's setup doesn't work, at least here. I'm certain that I've written the rules they're supposed to be /just change ip ranges, if names etc./ 10x in advance and please do bare with me... ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
On Sunday 22 April 2007 06:13, Lubomir Georgiev wrote: As a side note - I had found sysctl net.link.ether.ipfw=1 and it was enabled during my endless futile attempts. I believe that my problem lies in my rules but I can't figure out what's wrong with them So someone please help. you do not read with attention ... on a router (natd) you do not have layer2 traffic, obviously then you can not analise it, even loading if_bridge makes no sense since there is no such traffic so you're wasting your time if you need to block MACs you need to do it on switch level or put a freebsd bridge between the stations and your natd gateway João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
On Sunday 22 April 2007 07:59, Lubomir Georgiev wrote: Thanks for the response but I have to disagree with you - I have read the responses time and time again with great attention, but to no avail. From what you said I understand that in order to utilize MAC address filtering I would need a managed switch or another box aside from the one that will be performing the NATing - is that right? Are you sure that there's no way to combine MAC filtering with NAT in a single box? man, you can control layer2 traffic only if you have some and this is not the case on a natd router P.S. I have heard of another way of filtering which uses the ARP tables - any comments on that? The thing that I don't think I'll be able to accomplish with the ARP tables is to use any of the 192.168.1.X IP addresses. arptables on a router do not have anything to do with layer2 traffic you can fake the mac address and make it permanent in the arptable on the nat router which then certainly blocks the correct mac as well as you can open a door with an ax or check your blood pressure with a knife, what I am trying to say is that this are last resource methods João Once again thanks for all your help and I hope we can reach the final conclusion of this problem. A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
I could not understand Joao's statement, so I tend to disagree that
there is no layer2 traffic flowing on a NAT box. Makes no sense to me. I
am sure it is possible to do all 2 sub-layer layer 2 filtering (MAC and
LLC).
So I have just tried what you are willing to get working Lubomir, right
now in the network I am.
My current enviroment is the simplest the possible:
[ 10.69.0.0/16 network ] = [ switch ] = [FreeBSD] = [Internet]
My external interface is vr0
My internal one is xl0
I have just allowed two stations to go to the DIVERT (natd) rules by
using skipto approach, and all other machines are not skipped, so they
tend to match an intermediary rule which does deny all traffic based on
layer2. I kept only the relevant rules so it gets very clear to understand:
# ipfw show
00300 688 62538 skipto 1000 ip from any to any { MAC any
08:00:46:bd:da:a3 or MAC any 00:17:31:df:bc:ab } layer2
00310 637 84252 skipto 1000 ip from any to any { MAC
08:00:46:bd:da:a3 any or MAC 00:17:31:df:bc:ab any } layer2
00500 468 30071 deny log logamount 100 ip from any to any MAC any
any layer2 via xl0
01000 527 50710 divert 8668 ip from 10.69.0.0/16 to any out via vr0
01100 556 68585 divert 8668 ip from any to me in via vr0
65535 14642 1214437 allow ip from any to any
In case ipfw list may be clearer:
# ipfw list
00300 skipto 1000 ip from any to any { MAC any 08:00:46:bd:da:a3 or MAC
any 00:17:31:df:bc:ab } layer2
00310 skipto 1000 ip from any to any { MAC 08:00:46:bd:da:a3 any or MAC
00:17:31:df:bc:ab any } layer2
00500 deny log logamount 100 ip from any to any MAC any any layer2 via xl0
01000 divert 8668 ip from 10.69.0.0/16 to any out via vr0
01100 divert 8668 ip from any to me in via vr0
65535 allow ip from any to any
Some relevant information: I am doing selective divert based on my
network, on vr0 (external interface) while explicitly denying all layer2
traffic based on mac, on rule 500, only on xl0 (internal network),
because if I do it on all networks or on vr0, I will certainy deny my
own outgoing packets.
So it worked perfectly, and right now while I send this message only the
two MAC addresses are allowed to get diverted to natd (and go to internet).
As you can see, some traficc is still hitting rule # 500, so I want to
know what it is:
# grep 500 /var/log/security | tail -5
Apr 22 19:54:32 HomerSimpson kernel: ipfw: 500 Deny UDP
208.239.76.163:5060 10.69.69.39:5060 out via xl0
Apr 22 19:54:33 HomerSimpson kernel: ipfw: 500 Deny MAC in via xl0
Apr 22 19:54:36 HomerSimpson kernel: ipfw: 500 Deny UDP
208.239.76.163:5060 10.69.69.39:5060 out via xl0
Apr 22 19:54:37 HomerSimpson kernel: ipfw: 500 Deny MAC in via xl0
Apr 22 19:54:50 HomerSimpson kernel: ipfw: limit 100 reached on entry 500
So, it is IP 10.69.69.39, which for sure has a different MAC address:
# arp 10.69.69.39
? (10.69.69.39) at 00:12:17:fb:ee:e7 on xl0 [ethernet]
You also said you wanted allow other stations to talk to the gateway,
what in the above examples, I am not allowing, so for example if I add
rule 400 like this:
# ipfw add 400 allow all from 10.69.0.0/16 to me via xl0 not layer2
keep-state
00400 allow ip from 10.69.0.0/16 to me via xl0 not layer2 keep-state
I am certainly allowing any station on 10.69/16 network, regardless of
its IP address (unless it is on 10.69/16 network) or MAC address (since
I am not filtering on layer2):
# ipfw show
00300 2544 519800 skipto 1000 ip from any to any { MAC any
08:00:46:bd:da:a3 or MAC any 00:17:31:df:bc:ab } layer2
00310 2415 601710 skipto 1000 ip from any to any { MAC
08:00:46:bd:da:a3 any or MAC 00:17:31:df:bc:ab any } layer2
00400292548 allow ip from 10.69.0.0/16 to me via xl0 not layer2
keep-state
00500 1236 65813 deny log logamount 100 ip from any to any MAC any
any layer2 via xl0
01000 1904 469946 divert 8668 ip from 10.69.0.0/16 to any out via vr0
01100 2049 525859 divert 8668 ip from any to me in via vr0
65535 42049 5911000 allow ip from any to any
Since ipfw is a first-match-based firewall you don't need to worry about
this allow from any to any rule, because the hosts which get to this
rule certainly were not skipped on the later rules, so they simply never
get diverted, because they match on this allow and divert rules
happens AFTER the allow.
Lets see who is matching rule # 400 (which is a keep-state rule, so it
is generating dynamic state rules):
## Dynamic rules (2):
00400 1 100 (1s) STATE tcp 10.69.2.40 59235 - 10.69.2.1 22
00400 0 0 (0s) STATE udp 10.69.69.13 59577 - 10.69.69.1 53
Both 10.69.2.1 and 10.69.69.1 are me (the firewall itself). So just
perfect, anyone can freely go through the private network, in the above
dynamic we see an ssh session and an expired DNS query to the firewall
which for sure is also the DNS server for the network).
Last thing, remember to enabled ethernet filtering on IPFW:
sysctl -w net.link.ether.ipfw=1
If not, no layer2 filtering
Re: ipfw with nat - allowing by MAC address
AT Matik wrote:
On Sunday 22 April 2007 06:13, Lubomir Georgiev wrote:
As a side note - I had found sysctl net.link.ether.ipfw=1 and it was
enabled during my endless futile attempts.
I believe that my problem lies in my rules but I can't figure out what's
wrong with them So someone please help.
you do not read with attention ...
on a router (natd) you do not have layer2 traffic, obviously then you can not
analise it, even loading if_bridge makes no sense since there is no such
traffic so you're wasting your time
if you need to block MACs you need to do it on switch level or put a freebsd
bridge between the stations and your natd gateway
you are incorrect.
The data will pass through the firewall as it enters and exits the system via
the ethernet interfaces. The trick is that it will also pass through the
firewall
when it is routing in and out of the system at the IP level.
What I always do is something like:
ipfw add 10 skipto 1000 ip from any to any not layer2
# now we are only processing packets from the ethernet layer.
keep track of sessions with MAC addresses we don't want to NAT
ipfw add 100 skipto 3000 {mac spec} keep_state
[...]
# now we do layer 3 processing.
# divide up according to interface and direction.
ipfw add 100 skipto 1000 ip from any to any in recv ${inside_interface}
ipfw add 101 skipto 1100 ip from any to any out xmit ${inside_interface}
ipfw add 102 skipto 1200 ip from any to any in recv ${outside_interface}
ipfw add 103 skipto 1300 ip from any to any out xmit ${outside_interface}
# effectively we are not filtering anything else
ipfw add 104 accept ip from any to any
ipfw add 1000 allow ip from any to any
ipfw add 1100 allow ip from any to any
# Now the outside interface where NAT happens.
# first incoming packets are always sent to NAT of they are to us.
# unless the layer2 code exempted the session in question. They will go to 3000
ipfw add 1200 check-state
ipfw add 1201 divert natd ip from any to ${outside_address}
# The same number.. drop anything not diverted.
ipfw add 1201 drop ip from any to any
# nat/divert will reinject the packet here.
ipfw add 1202 accept ip from any to any
# now the outgoing packets.
ipfw add 1300 check-state
ifpw add 1301 accept ip from ${outside_address} to any
ipfw add 1302 divert natd ip from any to any.
# anything NATD allows through will be reinjected here.
ipfw add 1303 accept ip from any to any
# when the layer2 packets come here, just let them go on..
ipfw add 3000 accept ip from any to any layer2
# but when the layer 3 packets come here.. do something completely different.
[]
João
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw with nat - allowing by MAC address
On Thursday 19 April 2007 18:00, Lubomir Georgiev wrote: Hi all, I've lost 2 nights sleep over this and I still can't get through it! - Here's the thing : I have a FreeBSD box with ipfw and natd running. My internal ifaces are internal - xl0 /3com/ - ip 192.168.1.254 external - fxp0 - 10.11.0.33 ipfw l 00200 skipto 1200 ip from 192.168.1.100 to not me via fxp0 #00400 skipto 1200 ip from 192.168.1.0/24 to not me layer2 out #00600 skipto 1200 ip from any to any MAC any 00:19:d2:36:b8:48 layer2 in you will not have so much luck with this until you are loading the bridge or if_bridge module, on a router this will not work João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
