On 7/31/2007 5:40 PM, Mike Wright wrote:
Your knowledge never cease to amaze me.
*nod* Thank you. I like to share my trials and tribulations with
others so that they do not have to fight the same problems that I have
had to fight. I'm still working on getting our sales staff to not write
such big checks with their moths that I can hardly cash with my sweat.
Could one use iptables to do this?
Possibly. If you enable the "Bridged IP/ARP packets filtering"
(CONFIG_BRIDGE_NETFILTER) support in the kernel, yes IPTables would be
able to filter this. However I do not know if it would be better to do
this with EBTables or IPTables. The only thing that I can say to this
effect is that EBTables is (native) OSI Layer 2 and IPTables is (native)
OSI Layer 3+. With the "Bridged IP/ARP packets filtering" option
enabled, you can use the OSI Layer 3+ features of IPTables on OSI Layer
2, however you are using a higher layer and more complex match than is
in my opinion really needed. I think it would be akin to opening up
Excel to calculate some numbers via formula verses using calculator.
Seeing as how EBTables is (native) OSI Layer 2, which is where you are
really needing to do you work, I think it would be a better solution.
Question, does the box that you are adding this 3rd NIC to already have
IPTables set up and installed? If the answer is yes, I suppose that it
would work just fine. If the answer is no (you are doing your SNAT /
Masquerading elsewhere) then EBTables's basic match of in / out
interface may work just as easily. Consider the complexity of what is
in kernel.
If you do do your NATing / Masquerading on the system in question, you
could have (for maintenance reasons) a clear separation of where your
OSI Layer 2 and OSI Layer 3 filtering is done, with EBTables and
IPTables respectively.
If you are concerned about needing to learn a new filtering structure
and command syntax, don't be as EBTables is so similar to IPTables that
it is uncanny. Incidentally so is ARPTables from what I remember. Nor
do I think this similarity is by accident.
-A FORWARD -physdev --physdev-in eth0 --physdev-out eth2 -j DROP
-A FORWARD -physdev --physdev-in eth2 --physdev-out eth0 -j DROP
-A FORWARD -j ACCEPT
I have never worked with the physdev match extension so I can not say
for sure. I do not recall which features were being taken out of main
line NetFilter code, but I want to say that physdev was one of them,
thus meaning you would have to keep patching the kernel when you upgrade
to make this work. Thus in my opinion making the EBTables option more
maintainable and thus more appealing.
Regardless, I'd still be very interested in seeing the ebtables
ruleset to accomplish this.
ebtables -A FORWARD -i eth0 -o eth2 -j DROP
ebtables -A FORWARD -i eth2 -o eth0 -j DROP
Note, you do not need to set the ACCEPT target because the default
policy is to ACCEPT.
Thanks,
*nod*
ps pls reply to list; my email is a throwaway.
No problem. I generally only reply to the list / news group unless
explicitly asked to do so. That way the answer is in the archives for
others to benefit from.
Grant. . . .
