blinking leds obsession
What else is new, I can hear you think, but let me explain. Last weekend I picked up a Netgear FR318 firewall/router (which on it’s own is quite a capable firewall), supposed to be used as a switch only, but after thinking the possibilities over with a friend of mine, we both decided we would make an OpenBSD transparant bridge, so my router wouldn’t become totally useless…
So I did! Making the bridge on it’s own was quite easy. After a fresh install of OpenBSD/SPARC64 on my SUN Ultra 1 I had the bridge up&running in a matter of minutes. To explain it shortly what it does, here’s how it looks like:
|cablemodem|———|OpenBSD bridge|———-|netgear router/firewall|———-|my machines|
but the bridge itself is ‘invisible’, so it can’t be seen, judging from networktraffic and such, it doesn’t have an IP-number for instance, so it all behaves like this:
|cablemodem|———|netgear router/firewall|———-|my machines|
Except of course, whatever rules I decide to put into my pf.conf (packetfilter-configuration) on the bridge. Every packet it blocks(according to the ruleset) simply desolves into thin air and the one who sent it never even knew where it went :-) It simply isn’t there anymore…
But, the blocking of IP-packets and such went quite fine but still… my cablemodem flashes it’s activity led even when I don’t do anything (and that’s all ARP-noise) but to my surprise, the activity led on my Netgear flashed accordingly and somehow that gave me a bad feeling… So that explains the title of my post, skipping everything else, I wanted to let the Netgear-led show only the activity of ‘my’ traffic, not the noise my ISP is sending on the line…
So, after searching, thinking, sweating, little sleep and way too much coffee, I managed to let the bridge ‘filter’ all this ARP-noise from the line and so now my Netgear is in some sort of lab-environment instead of the jungle the interweb is out there ;-)
clickable
clickable
My old Classic II is the serial terminal to my SUN, simply because the SUN doesn’t have an ip-number, and therefore cannot be reached by SSH/telnet whatsoever… So how would a malicious cracker be able to send packets to the SUN? He isn’t :-)
(and the Shiva is there, so I will be able to remotely administer the Sun, even though it doesn’t have an IP-number :-))
Oh! before I forget… what in the end was the answer on how to block ARP-noise by a transparent OpenBSD-bridge?
Use brconfig to do it… this is how my bridgename.bridge0 looks like now:
add le0 #external interface connected to cablemodem
add le1 #internal interface connected to netgear
blocknonip le0
blocknonip le1
-learn le0 static le0 [MAC-adress cablemodem]
-discover le0
-learn le1 static le1 [MAC-address netgear]
-discover le1
rule pass in on le0 src [MAC-adress cablemodem] dst [MAC-address netgear]
rule pass out on le0 src [MAC-address netgear] dst [MAC-adress cablemodem]
rule block in on le0
rule block out on le0
up
permalink - 
add to del.icio.us
previous: All good things come in twos
next: One man’s junk is another man’s jewel
