ebtables-user — Questions on the usage of ebtables.

Re: [Ebtables-user] Hiding an IP address on a multi-homed bridging firewall!!

[Grant T. <gt...@ri...>]

On 7/3/2008 12:19 AM, Ramsurrun Visham wrote:
> I have a machine acting as a stealth firewall with three interfaces. 
> Only interfaces eth0 and eth1 are enslaved to the bridge device br0, 
> and none of them are given IP addresses. eth2 connects to a different 
> network and has an IP address assigned to it. Traffic travels from 
> eth0 to eth1 and vice-versa. I wanted to know how can I make 
> computers found on the eth0 and eth1 sides of the bridge, not see the 
> eth2 IP address. The problem is that I sometimes see ARP requests 
> with the eth2's IP address as src IP address. When I disable the eth2 
> interface, I get ARP requests with src IP address 0.0.0.0, which is 
> fine. But when eth2 is up, I see its IP address. How can I hide it?
> 
> Any help will be much appreciated..

First, I *think* you are /not/ crazy.  In fact, I had to re-read what 
you wrote a couple of times to make sure that there was not a problem 
with what you have in place.

After I was satisfied that the problem was not in your config, because I 
completely agree with it, I then immediately thought back to something I 
read about ARPs and the Linux kernel.  In short, (to quote the kernel 
documentation)  "IP addresses are owned by the complete host on Linux, 
not by particular interfaces.".  So, I think the kernel is allowing ARPs 
to ""leak across interfaces.

Do some reading (search for "arp") in the <kernel source 
directory>/Documentation/networking/ip-sysctl.txt file.

I think you will want to change the following entries to these values.

arp_filter = 1
arp_announce = 1
arp_ignore = 2 or better 3



Grant. . . .

Re: [Ebtables-user] Hiding an IP address on a multi-homed bridging firewall!!

[Jonothan K. <jon...@gm...>]

Try simply locking down your  ARP traffic for that interface eth2.
Any arp request with that interfaces IP or MAC .. drop them if they
are not going out the interface itself.

ebtables -A OUTPUT -p ARP -s eth2MACaddress -o ! eth2 -j DROP

Although if eth2 is truely a management interface, I'd lock it down
even further with

ebtables -A OUTPUT  -o ! eth2 -s eth2MACaddress -j DROP

That'd limit outbound traffic with eth2's MAC to only going out eth2.

J Kane

On Wed, Jul 2, 2008 at 10:19 PM, Ramsurrun Visham <vi...@gm...> wrote:
> Hi to all,
>
> I have a machine acting as a stealth firewall with three interfaces.
> Only interfaces eth0 and eth1 are enslaved to the bridge device br0,
> and none of them are given IP addresses. eth2 connects to a different
> network and has an IP address assigned to it. Traffic travels from
> eth0 to eth1 and vice-versa. I wanted to know how can I make computers
> found on the eth0 and eth1 sides of the bridge, not see the eth2 IP
> address. The problem is that I sometimes see ARP requests with the
> eth2's IP address as src IP address. When I disable the eth2
> interface, I get ARP requests with src IP address 0.0.0.0, which is
> fine. But when eth2 is up, I see its IP address. How can I hide it?
>
> Any help will be much appreciated..
>
> Warm regards,
> Visham
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Ebtables-user mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>

[Ebtables-user] Hiding an IP address on a multi-homed bridging firewall!!

[Ramsurrun V. <vi...@gm...>]

Hi to all,

I have a machine acting as a stealth firewall with three interfaces.
Only interfaces eth0 and eth1 are enslaved to the bridge device br0,
and none of them are given IP addresses. eth2 connects to a different
network and has an IP address assigned to it. Traffic travels from
eth0 to eth1 and vice-versa. I wanted to know how can I make computers
found on the eth0 and eth1 sides of the bridge, not see the eth2 IP
address. The problem is that I sometimes see ARP requests with the
eth2's IP address as src IP address. When I disable the eth2
interface, I get ARP requests with src IP address 0.0.0.0, which is
fine. But when eth2 is up, I see its IP address. How can I hide it?

Any help will be much appreciated..

Warm regards,
Visham

Re: [Ebtables-user] [Ebtables-devel] problem removing certain rules

[David P O. <ol...@us...>]

Jonathan,

  Thanks for the reply.  I did a little digging and found out that it was 
a bug in my release (V2.0.6) and was fixed in later releases.
I upgraded to v2.0.8 and the problem went away.

David O.




Jonathan Thibault <jon...@na...> 
06/10/2008 06:04 PM

To
David P Olshefski/Watson/IBM@IBMUS, ebt...@li...
cc

Subject
Re: [Ebtables-devel] problem removing certain rules






I think you have to delete rules by number.

For example:

ebtables -t nat -D PREROUTING 3

Jonathan

David P Olshefski wrote:
> 
> I can't seem to remove certain rules, unless I specifiy the rule number.
> 
> For example, I create a rule:
> 
> # ebtables -t nat -A PREROUTING  --protocol ARP -i vif1.0 -s ! 
> 00:16:3e:18:94:83 -j DROP
> 
> which works ok...but when I attempt to delete it:
> 
> # ebtables -t nat -D PREROUTING  --protocol ARP -i vif1.0 -s ! 
> 00:16:3e:18:94:83 -j DROP
> Sorry, rule does not exist.
> 
> yet the rule prints out when I do a "ebtables -t nat -L"
> 
> I am using ebtables v2.0.6-77, on SUSE running in Xen dom0.
> 
> 
> Dave O.
> 
> 
> ------------------------------------------------------------------------
> 
> 
-------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ebtables-devel mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-devel

Re: [Ebtables-user] [Ebtables-devel] problem removing certain rules

[Jonathan T. <jon...@na...>]

I think you have to delete rules by number.

For example:

ebtables -t nat -D PREROUTING 3

Jonathan

David P Olshefski wrote:
> 
> I can't seem to remove certain rules, unless I specifiy the rule number.
> 
> For example, I create a rule:
> 
> # ebtables -t nat -A PREROUTING  --protocol ARP -i vif1.0 -s ! 
> 00:16:3e:18:94:83 -j DROP
> 
> which works ok...but when I attempt to delete it:
> 
> # ebtables -t nat -D PREROUTING  --protocol ARP -i vif1.0 -s ! 
> 00:16:3e:18:94:83 -j DROP
> Sorry, rule does not exist.
> 
> yet the rule prints out when I do a "ebtables -t nat -L"
> 
> I am using ebtables v2.0.6-77, on SUSE running in Xen dom0.
> 
> 
> Dave O.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ebtables-devel mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-devel

[Ebtables-user] Problems deleting certain rules

[David P O. <ol...@us...>]

Running ebtables v2.0.6-77 on SUSE, 64bit, I cannot delete certain rules 
unless I specifiy the rule number.

For example,  I can create the rule:

> ebtables -t nat -A PREROUTING --protocol ARP -i vif1.0 -s ! 
00:16:3e:18:94:83 -j drop

but when I try to delete it I get.

> ebtables -t nat -D PREROUTING --protocol ARP -i vif1.0 -s ! 
00:16:3e:18:94:83 -j drop

"Sorry, rule does not exist."

Any suggestions?

Dave O.

[Ebtables-user] Filtering or dropping ARP Reply packets

[Bilal B. <bil...@ho...>]

Hello,

I am Bilal. I am working on my final project.

I need to drop incoming ARP Reply packets that have a payload but not starting with $$$.

I am implementing the current ARP more reliable. I put a string in the payload of ARP Reply packets.


If payload starts with $$$ that's OK but if it does not start with $$$, I want to drop it before it is written in the ARP cache table.

I hope I am clear with my statement.

Thanks in advance.

Yours Sincerely,


_________________________________________________________________
Back to work after baby–how do you know when you’re ready?
http://lifestyle.msn.com/familyandparenting/articleNW.aspx?cp-documentid=5797498&ocid=T067MSN40A0701A

Re: [Ebtables-user] [Bridge] bridge, vlan and *no* stp/bpdu

[Jonathan T. <jon...@na...>]

Hello Leigh and the lists,

I've had time to do some more tests on this today and here are my results.

First, I tried an ebtables rules as suggested by you and that link you 
offered:
  ebtables -t broute -A BROUTING -p 802_1Q -i in -j DROP

It did not seem to affect the issue at all, perhaps I did it wrong and 
would like some suggestions on that.

Now I figured I might try to find out exactly where the arp reply 
vanishes.  So I added this:

ebtables -t broute -A BROUTING -p arp --arp-opcode 2 --arp-mac-src 
00:18:18:62:3e:80 --arp-mac-dst 08:10:17:0D:70:61 --log

where 00:18:18:62:3e:80 is the gateway on the untagged (out) side of the 
bridge and 08:10:17:0D:70:61 is a host in vlan2 that never recieves its 
arp replies from the gateway as soon as I add in.3 to the bridge.

I added in.3 to the bridge, then I pinged 08:10:17:0D:70:61 from the 
outside (beyond the gateway) to have it arp the gateway.  Sure enough, I 
saw arp requests and replies on interface 'out' of the bridge but not in 
or in.2, as described in my previous post.

Here's what I got in the log:

Apr 11 11:56:18 bridgehost IN=out OUT= MAC source = 00:18:18:62:3e:80 
MAC dest = 08:10:17:0d:70:61 proto = 0x0806

Note the 'OUT=' field...  If things worked, I'd expect to see 'OUT=in.2' 
there.

So I put the bridge back in its 'working' state, removed 'in.3' so that 
I had only 'in.2' and 'out' as part of the bridge.

I ran another test and now the arp reply reached my host, it was able to 
reach the gateway and reply to my ping.  Time to check the logs...

Apr 11 11:59:03 ordralphabetix IN=out OUT= MAC source = 
00:18:18:62:3e:80 MAC dest = 08:10:17:0d:70:61 proto = 0x0806

Why don't I see 'OUT=in.2'.  If the arp reply reached my host, it 
obviously had to go through the bridge.  That is in the 'out' interface 
and out the 'in.2' interface.  It's pretty strange to me, I'd really 
like to know what's going on here.

Thanks a lot,

Jonathan
> Leigh Sharpe wrote:
>   
>> Hi Jonathan,
>>  Let me make sure I understand your situation properly:
>>
>> You have an interface on which you have two vlans:
>>
>> Vconfig add in 2
>> Vconfig add in 3
>>
>> You have created a bridge and assigned interface out and interface in.2
>> to the bridge:
>>
>> Brctl addbr br0
>> Brctl addif br0 out
>> Brctl addif br0 in.2
>> Ifconfig out up
>> Ifconfig in.2 up
>>
>> Then, when you add in.3 to the bridge with this command,
>>
>> Brctl addif br0 in.3
>>
>>   
>>     
> Correct until now.
>   
>> Things start to break, and devices connected to in.3 cannot talk to
>> devices on interface 'out'.
>>
>> Does this look correct?
>>
>>   
>>     
> No.  There are no devices connected to in.3 at all.  Devices connected 
> to in.2 stop being able to reach the gateway which is connected to 
> 'out'.  Actually, it's more a matter of being unable to ARP the gateway 
> connected to 'out'.  The arp request reaches the gateway, but the reply 
> never reaches the machine connected to in.2.  If the machine on in.2 
> already has the gateway's mac in its arp table, then it can talk to it 
> fine.  So far, the only thing that doesn't work with my setup is *arp 
> replies*.
>   
>> I'm presuming that the MAC of interest is 00:18:18:62:3e:80
>>
>> I suspect that your bridge is seeing this mac coming in, VLAN tagged, on
>> interface 'in', and is learning it on that interface, before you add
>> in.3 to the bridge. Once that happens, any replies coming in on
>> interface 'out' will not be sent to in.3, as they should.
>>
>>   
>>     
> That's interesting.  Interface 'in' is not part of the bridge however, 
> in.2 is (and at that point, in.3).  My assumption was that a 'vlan 
> interface' spits out packets untagged rather than the raw (tagged) 
> packets coming on the real physical interface, which would make logical 
> sense.
>
> Also of note is that I do see the reply show up on in.2 (you see it in 
> my tcpdump -i in.2 log) as it should be with tcpdump, so I don't think 
> the problem is that it goes to the wrong interface.  The problem is that 
> it doesn't come *out* of the physical interface at all, tagged or not, 
> onto the vlan trunk.  If it came out on vlan3 or untagged, I would still 
> see it.
>
> It shows up locally if I tcpdump -i in, but it never shows up on the 
> wire (tcpdump -i eth1 on a box connected to the trunk right next to the 
> bridge, no vlan switch involved, just a dumb hub acting as a repeater so 
> I can sniff the traffic).  And that is before it gets to any vlan-aware 
> switch.  So the problem at that point is not a matter of a switch not 
> knowing how to deal with this peculiar situation.
>
>
>               |   bridge   |       +-| 00:18:18:62:3e:80 & all other |
> gateway-|(out)|out-br0-in.2|(in)|-hub
>         |     |      +-in.3|    |  +-|(eth1)                         |
>         | linux box with bridge |    | linux box used to sniff trunk |
>
> The arp reply, from the gatway, shows up on 'in.2', it shows up on 'in', 
> but it never shows up on 'eth1'.  I seriously doubt the hub is smart 
> enough to notice that in.3 has been added to the bridge and suddently 
> stop passing *only* arp replies as I see all other traffic just fine. I 
> also see those arp replies when in.3 isn't part of the bridge.  So my 
> fair assumption is that the arp reply packets never make it onto the hub 
> at all.
>
> As far as I can tell, they vanish between 'in' and the hub.
>
>   
>> I recall reading somewhere that if you add an ebtables rule to 'in',
>> which drops all VLAN tagged packets, it will then be redirected to the
>> correct sub-interface (ie in.3). I envisage it would be something like 
>>
>> Ebtables -t broute -A BROUTING -p 8021_Q -I in -J DROP
>>
>>   
>>     
> I will give that a try for sure.  From reading the post you refer to, it 
> makes a bit of sense, but I'm not entirely sure it covers the whole 
> problem.  A problem such as what it refers to seems like it would affect 
> all traffic instead of just arp replies.
>
> Thanks a bunch, I will update you on my results with that ebtables rule 
> shortly.
>
> Jonathan
>   
>> Have a good look at this post if you need further details:
>>
>>  http://osdir.com/ml/linux.drivers.vlan/2006-07/msg00011.html
>>
>>
>> Hope this helps.
>> Regards,
>>              Leigh
>>  
>> Leigh Sharpe
>> Network Systems Engineer
>> Pacific Wireless
>> Ph +61 3 9584 8966
>> Mob 0408 009 502
>> Helpdesk 1300 300 616
>> email ls...@pa...
>> web www.pacificwireless.com.au
>>
>>  

[Ebtables-user] Simulator with ebtables filter

[Benjamin H. <bh...@ud...>]

Hi,

I am building a network simulator based on OpenVZ, which allows
several virtual rootfs having their own TCPIP stack running on a
single linux kernel.

I am bridging all the vzeth* interfaces with brctl (20 of those).

Now I want to forbid packet exchanges from all the interfaces, exept
from interface1 (vzeth1) to interface13 (vzeth13).

How do I do that with ebtables?

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403

[Ebtables-user] Route packets by source IP

[Steffen H. <li...@st...>]

Hi

I have two servers, having public IPs A1, B1, connected via private IPs A2,
B2 on a openVPN network.
Now I need to make a service (port p) of server A1:p available via B1:p.
So I want to try the following:

1. At B: dnat every incoming connection for B1:p to A2:p.
    - this is to archieve my goal -
2. At A: Route every packet "from A2:P" to B2.
    - otherwise A would try to route to the client via its gateway, which
would fail because of the private sender ip. -

I think I can do the first:

iptables -t nat -I PREROUTING -p tcp --dport p -j DNAT --to A2:p

I can do the first, but I don't know how to do the second.
Any hints?

Regards,
  Steffen

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

> Great!!!  Go hoist a glass of your favorite drink to your self 
> (alcoholic or non, your choice)!

eh...is bog-standard, putrid, instant coffee ok?

> This all looks very good. 

Thank you. Actually since I posted my final script, 
I have really stessed the beast. I had four clients
imaging simultaneously yestereday, that's one
Zeroconf client and one "home" client on each interface.
I also tested ZeroConf address re-negotiation by
creating an artifical address conflict on the other
side of the bridge. Perfect, not a glitch. Samba
performed flawlessly and there was no observable
performance degradation compared to the single-homed,
non-briding scenario.

> Can I ask one last favor?  (I'll help if you would like.) 
> Can this be (read: will you) turned in to some form of a
> How-To that can be put with the other bridging How-Tos so
> that others  can benefit from your trials and efforts even
> more clearly?  We know what you were trying to achieve here,
> but others searching the archive might benefit from a
> concise document like a How-To.

I am agreeable to this proposal. I think if you look back over
this thread, the background and path to a solution are fairly
self-evident...all the info is there. It's just a matter of
removing some of the incorrect observations (on my part) and
tidying it up a bit. If you were prepared to kick of the HOW-TO,
leaving me with a template and posting instructions, I will do
the rest and perhaps you can then review the result and suggest
any changes.

Because it is, to say the least, a non-mainstream application,
my Imaging Server "project" has exposed me to many interesting
(often frustrating) challenges along the way, including an
innocuous e1000 bug and possible Linux/Samba stack reslience
issues. This particular one is the absolute icing on the cake.
I have left behind in my wake many useful threads on a number
of forums and I intend to bring all these together at some point
in a single Imaging Server HOW-TO document.

> P.S.  Congratulations!  You have now accomplished what some 
> will say can not be done.  It's a good feeling to be able to
> look at them and say "Yes it can! I've *DONE* it!" isn't it?  :)

Many thanks for the kind words and, yes, I have been slightly
mocked along the way by network purists on this topic, but that
is my own fault really. In hindsight, I feel embarrassed that
I even considered arp-filter and bonding solutions when this
is such a perfect case for bridging...sometimes, when you are
down in the trenches, it is hard to see the wood for the trees!
As a late convert, I must say that this experience has brought
home the supreme advantages of GNU/Linux/Open Source/Community.
Things are much more within your control and there is great
help out there when you need it.

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Grant T. <gt...@ri...>]

On 2/22/2008 4:03 PM, Vincent Callanan wrote:
> Okay, we have liftoff...finally!

Great!!!  Go hoist a glass of your favorite drink to your self 
(alcoholic or non, your choice)!

> I include final script below for anyone that runs into 
> this or similar issues and many thanks to Grant for 
> putting me on the right path.

This all looks very good.  Can I ask one last favor?  (I'll help if you 
would like.)  Can this be (read: will you) turned in to some form of a 
How-To that can be put with the other bridging How-Tos so that others 
can benefit from your trials and efforts even more clearly?  We know 
what you were trying to achieve here, but others searching the archive 
might benefit from a concise document like a How-To.



Grant. . . .

P.S.  Congratulations!  You have now accomplished what some will say can 
not be done.  It's a good feeling to be able to look at them and say 
"Yes it can! I've *DONE* it!" isn't it?  :)

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

Okay, we have liftoff...finally!

I include final script below for anyone that runs into
this or similar issues and many thanks to Grant for
putting me on the right path.

A few observations (benefits of hindsight)...

1. When testing brctl commands and ebtables rules from
   the command line, don't forget to:

   A. Flush existing rules (where applicable)
      use: ebtables -t <table> -F

   B. Flush ARP caches on all relevant hosts between tests
      For DOS/Windows clients use: arp -d *
      For Linux clients use: arp -d <IP Address>
      Anyone know a Linux command to flush all entries????

   Because I did not do this myself, some of my earlier
   observations on this thread were incorrect!!

2. When you get final script working, it is a good idea to
   cleanly reboot all affected hosts, including the bridge
   system itself, and test script again to be doubly sure

3. Ubuntu Dapper stock bridge-utils and ebtables packages
   are fine! No need to build custom packages

4. Grant's assertion that you can bind eth0 and eth1
   interfaces before bridging is correct!!!
   i.e. it is not correct to state that you must execute
        the following sequence before bridging:
          # ifconfig eth0 0.0.0.0
          # ifconfig eth1 0.0.0.0
        (this advice often appears on bridge docs)

5. Initial rules proposed by Grant needed tweaking to:
  
   A. Allow Zeroconf ARP (not just IP) traffic through bridge
   B. Broute IP and ARP traffic on home networks

6. You can set up ebtables rules BEFORE setting up bridge

   This is a good idea in my case as it prevents spurious
   packets crossing networks just after bridge is created
   but before rules have been applied

And here is the final script to achieve my ends....  

#!/bin/sh

#######################################################
# Dual-Homed Imaging Server Bridge Configuration Script
# -----------------------------------------------------
# by RVJ Callanan
# with help from ebt...@li...
#
# Allows operation with Zeroconf imaging clients
# on either or both subnets (in absence of DHCP server)
#
# Assumes server already configured for home networks:
# eth0 on 192.168.3.13 netmask 255.255.255.0
# eth1 on 192.168.4.13 netmask 255.255.255.0
#
# After execution:
# bri0 bridges eth0 and eth1 for Zeroconf traffic only
# bri0 on 169.254.0.13 netmask 255.255.0.0
#######################################################

# Set up rules first so that no spurious packets will
# pass between networks just after bridge is enabled

# BROUTE rules (DROP means ROUTE instead of BRIDGE)

ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-src 192.168.3.0/8 -j
DROP
ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst 192.168.3.0/8 -j
DROP

ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-src 192.168.4.0/8 -j
DROP
ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 192.168.4.0/8 -j
DROP

ebtables -t broute -A BROUTING -p arp -i eth0 --arp-ip-src 192.168.3.0/8
-j DROP
ebtables -t broute -A BROUTING -p arp -i eth0 --arp-ip-dst 192.168.3.0/8
-j DROP

ebtables -t broute -A BROUTING -p arp -i eth1 --arp-ip-src 192.168.4.0/8
-j DROP
ebtables -t broute -A BROUTING -p arp -i eth1 --arp-ip-dst 192.168.4.0/8
-j DROP

# BRIDGE rules

ebtables -t filter -A FORWARD -p IPv4 --ip-src 169.254.0.0/16 -j ACCEPT
ebtables -t filter -A FORWARD -p IPv4 --ip-dst 169.254.0.0/16 -j ACCEPT

ebtables -t filter -A FORWARD -p arp --arp-ip-src 169.254.0.0/16 -j
ACCEPT
ebtables -t filter -A FORWARD -p arp --arp-ip-dst 169.254.0.0/16 -j
ACCEPT

ebtables -t filter -A FORWARD -j DROP

# Now set up bridge

brctl addbr bri0
brctl addif bri0 eth0
brctl addif bri0 eth1
ifconfig bri0 up
ifconfig bri0 169.254.0.13 netmask 255.255.0.0

# End-of-script

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

A little more research on this subject which may switch on a light bulb
or two...

> In any case, this is a critical point we need to clear up 
> from the outset!

Is this the horse's mouth on this subject?
http://www.linux-foundation.org/en/Net:Bridge#Network_cards

To Quote:
"Before you start make sure both network cards are set up and working
properly. Don't set the IP address, and don't let the startup scripts
run DHCP on the ethernet interfaces either. The IP address needs to be
set after the bridge has been configured...The command ifconfig should
show both network cards, and they should be DOWN"

> A conceptual data path diagram would be nice here i.e.
> where does the bridge filter actually reside in relation
> to the *bound* eth0 and eth1 interfaces (as distinct from
> the *raw*  interfaces). Would this depend on whether the
> interfaces were bound *before* or *after* the bridge was set up?

Some useful diagrams in this link:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

> My guess is that the bridge filter would need to be first in 
> line so perhaps additional rules are necessary before the 
> DROP rule to "route" 192.168.3.* and 192.168.4.* packets to
> the "internal" interfaces. Maybe I'm clutching at straws here.
> Any ideas?

Okay, I'm very unsure about these rules but I did come across
the following example, which might be pertinent:
http://ebtables.sourceforge.net/examples.html#ex_brouter

And yet, this seems to contradict the "horse's mouth" above
in relation to unbinding interfaces before bridging!

Vincent

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

I'm not actually back on site until this evening (Ireland/GMT).
Given the time difference, perhaps we can progress the discussion
a little further before then...

> > # ifconfig eth0 0.0.0.0
> > # ifconfig eth1 0.0.0.0
> > # brctl addbr bri0
> > # brctl addif bri0 eth0
> > # brctl addif bri0 eth1
> > # ifconfig bri0 up
> 
> You should not need to remove the addresses from the eth0 and eth1 
> interface.  You can easily have the addresses bound to them and use 
> bridging at the same time.

On my initial attempt, I followed your advice to the letter.
First I ensured that my home networks were working okay on each
interface,
the relevant /etc/network/interfaces excerpts being:

auto eth0
iface eth0 inet static
address 192.168.3.13
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

auto eth1
iface eth1 inet static
address 192.168.4.13
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255

I did a few ping tests to ensure home networks were okay.
Then I set up the bridge as follows:

# brctl addbr bri0
# brctl addif bri0 eth0
# brctl addif bri0 eth1
# ifconfig bri0 up

After issuing these commands, Zeroconf client ping tests failed
across the bridge and I could not ping on the home interfaces anymore.

But I'm now wondering did I wait long enough for the bridge to go
through its "learning" phase. You don't happen to know how long this
takes? Did I read 30 seconds somewhere? Is it dependent on interface
complexity?

Okay, in hindsight, I should probably try this again but, at the time,
I decided to scour Linux Bridging docs and I read somewhere that it was
necessary to unbind interfaces before bridging them by issuing the
following commands:

# ifconfig eth0 0.0.0.0
# ifconfig eth1 0.0.0.0

Now this may be a classic case of somebody making an assumption and
posting it as fact for newbies like me to latch onto...and it
wouldn't be the first time (I've probably done it myself).

In any case, this is a critical point we need to clear up from the
outset!

> > Next I set up slightly modified versions of your ebtables rules
> > specifying the ip4v protocol and ip-specific source/destination 
> > addresses. 
> > I assume you left these out for clarity.
> > 
> > # ebtables -t filter -A FORWARD -p IPv4 --ip-src 169.254.0.0/16 -j
> > ACCEPT
> > # ebtables -t filter -A FORWARD -p IPv4 --ip-dst 169.254.0.0/16 -j 
> > ACCEPT
> > # ebtables -t filter -A FORWARD -j DROP
> 
> I can't say why, but I'm not comfortable with these rules at 
> the moment. I feel like you should be doing something different,
> but I can't say what at the moment.

Your original rules did not work (I got an invalid source MAC
address error or something like that). Are my modifications above
at least correct in principle (whatever about the rules themselves)?

I'm wondering if the third rule above is causing 192.168.3.* and
192.168.4.*
packets to be dropped. A conceptual data path diagram would be nice here
i.e. where does the bridge filter actually reside in relation to the
*bound* eth0 and eth1 interfaces (as distinct from the *raw*
interfaces).
Would this depend on whether the interfaces were bound *before* or
*after*
the bridge was set up?

My guess is that the bridge filter would need to be first in line so
perhaps additional rules are necessary before the DROP rule to "route"
192.168.3.* and 192.168.4.* packets to the "internal" interfaces.
Maybe I'm clutching at straws here. Any ideas?

> Hum.  You should have been able to.  Do your EBTables rules show that 
> your third rule, "DROP" is matching frames?  Try flushing 
> your EBTables rules and see if things work.

I will try this first thing this evening.

> > The Dapper Universe version of EBtables I'm using is 2.0.6 
> (2003) which 
> > is quite old. Perhaps I will need to build from latest 
> source but I am 
> > a bit reluctant to do this in case it upsets anything else 
> in the stack.
> 
> I think you would be getting errors about the ebtables binary 
> not being 
> able to function with the kernel if there was a problem, but 
> I'm not sure.
> 

Would you consider EBtables 2.0.6 a reasonably solid version?
If not, is there a risk that I might de-stabilise my system if
I build EBtables from latest source? For example, would this
also require that I build the latest version of bridge-utils
from source?

Rgds,

Vincent

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Grant T. <gt...@ri...>]

On 02/14/08 07:46, Vincent Callanan wrote:
> I've finally got back on site to test your configuration settings. 
> I'm not quite there yet, so maybe you can get me over the last hurdle.

I'll try.

> # ifconfig eth0 0.0.0.0
> # ifconfig eth1 0.0.0.0
> # brctl addbr bri0
> # brctl addif bri0 eth0
> # brctl addif bri0 eth1
> # ifconfig bri0 up

You should not need to remove the addresses from the eth0 and eth1 
interface.  You can easily have the addresses bound to them and use 
bridging at the same time.

> After issuing these commands, I waited about a minute 
> to allow the server to settle into it's new role in life.
>  
> At this point, two Zeroconf clients connected on each interface 
> were able to ping each other. So far so good...

*nod*  This is as I would expect.

> Next I bound the bridge interface to it's own Zeroconf address
> 
> # ifconfig bri0 169.254.0.13 netmask 255.255.0.0
> 
> The two Zeroconf clients were still able to ping each other 
> and also ping the server. The server was also able to ping each 
> Zeroconf client. So far so good...

*nod*

> Next I set up slightly modified versions of your ebtables rules 
> specifying the ip4v protocol and ip-specific source/destination 
> addresses. 
> I assume you left these out for clarity.
> 
> # ebtables -t filter -A FORWARD -p IPv4 --ip-src 169.254.0.0/16 -j 
> ACCEPT
> # ebtables -t filter -A FORWARD -p IPv4 --ip-dst 169.254.0.0/16 -j 
> ACCEPT
> # ebtables -t filter -A FORWARD -j DROP

I can't say why, but I'm not comfortable with these rules at the moment. 
  I feel like you should be doing something different, but I can't say 
what at the moment.

> At this point, the two Zeroconf clients were still able to ping each 
> other 
> and also ping the server. The server was still able to ping each client. 
> So far so good...
> 
> Next I attempted to bind eth0 and eth1 to their home networks
> 
> # ifconfig eth0 192.168.3.13 netmask 255.255.255.0
> # ifconfig eth1 192.168.4.13 netmask 255.255.255.0

*nod*

> And this is where the "happy ever after" ending did not happen! 
> I was unable to ping any hosts on 192.168.3.* or 192.168.4.* 
> or ping the Image Server from these hosts.
> 
> Any suggestions would be welcome?

Hum.  You should have been able to.  Do your EBTables rules show that 
your third rule, "DROP" is matching frames?  Try flushing your EBTables 
rules and see if things work.

> BTW, I have had good reason in the past not to trust software from the 
> Dapper *universe* repository, particularly low level stuff like 
> EBtables. 
> The Dapper Universe version of EBtables I'm using is 2.0.6 (2003) which 
> is quite old. Perhaps I will need to build from latest source but I am 
> a bit reluctant to do this in case it upsets anything else in the stack.

I think you would be getting errors about the ebtables binary not being 
able to function with the kernel if there was a problem, but I'm not sure.



Grant. . . .

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

Okay Grant,

I've finally got back on site to test your configuration settings.
I'm not quite there yet, so maybe you can get me over the last hurdle.

Here's what I did thus far...

For anyone else reading this, my system is:
Ubuntu 6.06 LTS Server Edition (Dapper)

First, I needed to install the Bridge Utilies:

# apt-get install bridge-utils
# mandb

This completed OK (package is available in main repository)

Next, I needed to install EBtables:

EBtables is not in the *main* Dapper package repository.
It is however available in the *universe* repository.
So I first needed to modify my /etc/apt/sources.list file to include
universe packages.

# apt-get install ebtables
# mandb

After rebooting my system, I issued the following commands
to set up a raw bridge with no other funny stuff

# ifconfig eth0 0.0.0.0
# ifconfig eth1 0.0.0.0
# brctl addbr bri0
# brctl addif bri0 eth0
# brctl addif bri0 eth1
# ifconfig bri0 up

After issuing these commands, I waited about a minute
to allow the server to settle into it's new role in life.
 
At this point, two Zeroconf clients connected on each interface
were able to ping each other. So far so good...

Next I bound the bridge interface to it's own Zeroconf address

# ifconfig bri0 169.254.0.13 netmask 255.255.0.0

The two Zeroconf clients were still able to ping each other
and also ping the server. The server was also able to ping each
Zeroconf client. So far so good...

Next I set up slightly modified versions of your ebtables rules
specifying the ip4v protocol and ip-specific source/destination
addresses.
I assume you left these out for clarity.

# ebtables -t filter -A FORWARD -p IPv4 --ip-src 169.254.0.0/16 -j
ACCEPT
# ebtables -t filter -A FORWARD -p IPv4 --ip-dst 169.254.0.0/16 -j
ACCEPT
# ebtables -t filter -A FORWARD -j DROP

At this point, the two Zeroconf clients were still able to ping each
other
and also ping the server. The server was still able to ping each client.
So far so good...

Next I attempted to bind eth0 and eth1 to their home networks

# ifconfig eth0 192.168.3.13 netmask 255.255.255.0
# ifconfig eth1 192.168.4.13 netmask 255.255.255.0

And this is where the "happy ever after" ending did not happen!
I was unable to ping any hosts on 192.168.3.* or 192.168.4.*
or ping the Image Server from these hosts.

Any suggestions would be welcome?

BTW, I have had good reason in the past not to trust software from the
Dapper *universe* repository, particularly low level stuff like
EBtables.
The Dapper Universe version of EBtables I'm using is 2.0.6 (2003) which
is quite old. Perhaps I will need to build from latest source but I am
a bit reluctant to do this in case it upsets anything else in the stack.


Rgds,

Vincent

[Ebtables-user] DIALER

[AA Inter.N. S. / S. J. <aa...@ho...>]

Hi,
 
I know this is not the exact place, but plz help.
 
I have a VPN Server. at cleint end I have to manually setup vpn dialer and settings, is there any software via which I can create my own vpn dialer with my settings, and give it to clients as a software package like clientvpnsetup.exe or like this? so that I dont have to manually setup vpn dialer for clients.In short, I need a VPN dialer creator tool ?

 
Regards, 

SYED JAHANZAIB
 
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Grant T. <gt...@ri...>]

On 02/12/08 16:15, Carl-Daniel Hailfinger wrote:
> Yes, but unless the client is connected to two different switches, I 
> don't see a way to abuse STP to trick the switch to send all traffic 
> to it.

I think I could come up with ways to abuse STP (making a royal mess of 
the STP topology), but all of which are beyond what the OP was wanting 
to do.  I mainly brought STP up as optional reading down the road.

> And exactly this is how you can force a switch to send all traffic to 
> the client. Have the client send a continuous stream of packets with 
> a spoofed source MAC of the computer you want to eavesdrop on. The 
> switch is tricked into learning that the most recent location of the 
> victim is the sniffing client. No need to mess with ARP. However, 
> this usually causes the switch to not send packets to the victim 
> anymore, so it may not be exactly what you want.

*nod*  This MAC Spoofing will get you the packets, but it will tend to 
leave the spoofed real client dead in the water, and thus break connections.

> The other way to get all traffic to a switch relayed to the sniffing 
> client relies on downgrading the switch to a hub. Switches only have 
> a limited number of MAC addresses they can store in their forwarding 
> table. If you fill the table with fake entries, the switch doesn't 
> know where to send a specific packet and sends it everywhere. Thus, 
> it has effectively become a hub.

Now you are starting to do some things that are easily detectable and 
will tend to set off alarms.

> To prevent attacks of that type, you can enable port security on the 
> switch or use more advanced features.
> 
> On the other hand, if you are the network admin, you can tell a 
> switch to copy all traffic it receives to another port with a feature 
> called "port mirroring" or "roving analysis".

These are all viable things that more than casual network admins should 
at least be aware of in case they ever need to do them.  They are also 
beyond what the OP was wanting to do.



Grant. . . .

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Carl-Daniel H. <c-d...@gm...>]

On 12.02.2008 20:52, Grant Taylor wrote:
> On 02/12/08 13:14, Vincent Callanan wrote:
>   
>> Just a by-the-way on this promiscuous mode business...
>>
>> I did in fact understand that modern switches (unlike old hubs) 
>> monitor MAC activity and learn where source and destination ports 
>> reside.  However, I assumed that if a NIC is placed in promiscuous 
>> mode, then this fact will somehow be communicated to the switch, 
>> perhaps in some status bit in packet headers, and the switch will 
>> then send all traffic to the NIC port.  Obviously, from what you say, 
>> this assumption is incorrect and I need have no concerns about my 
>> server getting overloaded with extraneous traffic.
>>     
>
> About the only thing that the client computer can to to effect what is 
> or is not sent to it (aside from doing some very nasty things with ARP) 
> is to enable Spanning Tree Protocol and mis-configure it and or allow 
> loops in the network.  If you want to have a discussion about STP, just 
> say the word.
>   

Yes, but unless the client is connected to two different switches, I
don't see a way to abuse STP to trick the switch to send all traffic to it.

>> But that leads me to ask the question:  How do Linux network sniffing 
>> utilities (which also use promiscuous mode) manage to pick up all 
>> traffic?
>>     
>
> In short, they do not.  The Linux (or what ever) networking sniffing 
> utilities only see the traffic that comes to the NIC its self.  That is 
> why if you want to sniff a switched network you either need to put a Hub 
> in-line or use a SPAN / Mirror port on a switch.  This way, all the 
> traffic makes it to the Linux (or what ever) system's NIC in promiscuous 
> mode.
>
> Remember that switches and bridges will (by default) only send traffic 
> to all ports if they do not know where the destination MAC is.  Thus if 
> they do know where the destination MAC is, they will send it only to the 
> destination MAC, *NOT* all ports.
>   

And exactly this is how you can force a switch to send all traffic to
the client. Have the client send a continuous stream of packets with a
spoofed source MAC of the computer you want to eavesdrop on. The switch
is tricked into learning that the most recent location of the victim is
the sniffing client. No need to mess with ARP. However, this usually
causes the switch to not send packets to the victim anymore, so it may
not be exactly what you want.
The other way to get all traffic to a switch relayed to the sniffing
client relies on downgrading the switch to a hub. Switches only have a
limited number of MAC addresses they can store in their forwarding
table. If you fill the table with fake entries, the switch doesn't know
where to send a specific packet and sends it everywhere. Thus, it has
effectively become a hub.

To prevent attacks of that type, you can enable port security on the
switch or use more advanced features.

On the other hand, if you are the network admin, you can tell a switch
to copy all traffic it receives to another port with a feature called
"port mirroring" or "roving analysis".

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

> About the only thing that the client computer can to to 
> effect what is 
> or is not sent to it (aside from doing some very nasty things 
> with ARP) 
> is to enable Spanning Tree Protocol and mis-configure it and or allow 
> loops in the network.  If you want to have a discussion about 
> STP, just 
> say the word.

ooh, I'll leave that for another day...my aging brain is already
overloaded :)

> In short, they do not.  The Linux (or what ever) networking sniffing 
> utilities only see the traffic that comes to the NIC its 
> self.  That is 
> why if you want to sniff a switched network you either need 
> to put a Hub 
> in-line or use a SPAN / Mirror port on a switch.  This way, all the 
> traffic makes it to the Linux (or what ever) system's NIC in 
> promiscuous 
> mode.

ah yes! I do recall reading something about this in the past.
My neural networks are obviously misconfigured :)

All has been revealed!
This very satisfied "customer" will report back in due course with
postscript.

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Grant T. <gt...@ri...>]

On 02/12/08 13:14, Vincent Callanan wrote:
> This is fantastic assistance Grant.

I'm glad that I was able to help.

> I am chomping at the bit to get this up and running when I get back 
> on-site.  I will report back when job is complete.

*nod*

Please do respond with a details post so that someone else like your 
self will hopefully find the response in the archives useful.

> Just a by-the-way on this promiscuous mode business...
> 
> I did in fact understand that modern switches (unlike old hubs) 
> monitor MAC activity and learn where source and destination ports 
> reside.  However, I assumed that if a NIC is placed in promiscuous 
> mode, then this fact will somehow be communicated to the switch, 
> perhaps in some status bit in packet headers, and the switch will 
> then send all traffic to the NIC port.  Obviously, from what you say, 
> this assumption is incorrect and I need have no concerns about my 
> server getting overloaded with extraneous traffic.

About the only thing that the client computer can to to effect what is 
or is not sent to it (aside from doing some very nasty things with ARP) 
is to enable Spanning Tree Protocol and mis-configure it and or allow 
loops in the network.  If you want to have a discussion about STP, just 
say the word.

> But that leads me to ask the question:  How do Linux network sniffing 
> utilities (which also use promiscuous mode) manage to pick up all 
> traffic?

In short, they do not.  The Linux (or what ever) networking sniffing 
utilities only see the traffic that comes to the NIC its self.  That is 
why if you want to sniff a switched network you either need to put a Hub 
in-line or use a SPAN / Mirror port on a switch.  This way, all the 
traffic makes it to the Linux (or what ever) system's NIC in promiscuous 
mode.

Remember that switches and bridges will (by default) only send traffic 
to all ports if they do not know where the destination MAC is.  Thus if 
they do know where the destination MAC is, they will send it only to the 
destination MAC, *NOT* all ports.



Grant. . . .

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

This is fantastic assistance Grant.

I am chomping at the bit to get this up and running when I get back
on-site.
I will report back when job is complete.

Just a by-the-way on this promiscuous mode business...

I did in fact understand that modern switches (unlike old hubs) monitor
MAC
activity and learn where source and destination ports reside.
However, I assumed that if a NIC is placed in promiscuous mode, then
this
fact will somehow be communicated to the switch, perhaps in some status
bit
in packet headers, and the switch will then send all traffic to the NIC
port.
Obviously, from what you say, this assumption is incorrect and I need
have
no concerns about my server getting overloaded with extraneous traffic.

But that leads me to ask the question:
How do Linux network sniffing utilities (which also use promiscuous
mode)
manage to pick up all traffic?

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Grant T. <gt...@ri...>]

On 02/12/08 07:09, Vincent Callanan wrote:
> Many thanks for your prompt and detailed response. Let me step back and
> give you some background before I answer your questions....

You are welcome.

<snip>

Thank you for the helpful and informative explanation of what you are 
wanting and what you have tried to do.

> Because of routing conflict (as discussed above)

I was thinking bind the 169.254.0.0/16 network to eth1 only, not eth0 
and eth1.  You are correct that binding to both will cause a routing 
problem if you can get it to bind at all.

> Sorry, I should have just said bridge from eth0 to eth1 (not eth0:0 to
> eth1)

No problem.

> eth1 will interface to both 169.254.*.* and 192.168.4.*
> eth0 will interface to both 169.254.*.* and 192.168.3.*
> 
> That's THREE subnets in total on TWO interfaces
> with no routing between these subnets
> but I do need to bridge between eth0 and eth1 for 169.254.*.* traffic
> only

*nod*

This is a perfect case for bridging.

> That looks good and makes sense even to me :)
> You say that my services will be bound to eth0 and eth1.
> Does that mean all three subnets will be visible?

Well, you have the option to have services bound to all subnets.  If 
they are bound, yes they will be visible.

> That's fine - I have no need for IP filtering (or forwarding) anyway.

Ok.

> I will want ARP broadcasts on 169.254.*.* to permeate both interfaces
> so that Zeroconf clients on either interface can detect conflicts during
> address negotiation. But I don't want ARPs from other subnets getting
> bridged.

This is not a problem.

> Do I need extra ebtables commands to ensure this?

No.

Based on what you are wanting to do, bind your 192.168.3/24 and 
192.168.4/24 subnets to eth0 and eth1 respectively.  Then bridge eth0 
and eth1 together in bri0.  (I like to name my bridges "bri" rather than 
"br", but what ever will work.)  Then bind 169.254/16 to bri0.  Set up 
ebtables rules that will cause any traffic entering the bridge not from 
and to the 169.254/16 network to be routed.  In EBTables terms this 
means to DROP (the packet out of the bridge and pass it on up to the 
routing code) the frame in the BROUTING chin of the broute table.

I believe this will have your desired result.  192.168.3/24, 
192.168.4/24, and 169.254/16 networks will all appear on their own 
interface where you can choose to bind (or not) your services to them. 
You should have little fear of traffic crossing the bridge that should 
not.  In fact, the only thing that may cross the bridge is ARP traffic 
(that does not need to), however you can even set up EBTables rules to 
stop that.

> My very basic understanding about Linux bridging is that each NIC is
> placed
> in promiscuous mode and the switches will also pass traffic which would
> not otherwise be visible on the Image Server ports. In other words,
> all traffic on each subnet is visible to the server and needs to be
> processed (and ignored where applicable).

Note quite.

The interface(s) are indeed put in to promiscuous mode.  However 
switches connected to the system do not do any thing different (save for 
Spanning Tree if it is used).  The promiscuous mode is just so that all 
frames that enter the interface can be passed to the bridging code, 
which will act like a software switch and decide what needs to be done 
with the frame.

> So let's say there is a heavy NFS backup happening on the 192.168.3.*
> subnet
> between two other servers. Will this traffic create a lot of unnecessary
> processing overhead for my Image Server?

No, that will not be a problem as long as you are on a modern (switched) 
network.

Remember that a switch will learn where a MAC address is at.  Thus if 
you have one (or more) MAC address(es) talking to one (or more) other 
MAC address(es), the switch will learn where source and destination MACs 
are in the conversation.  Once the switch has learned where (which 
port(s)) the destination MAC(s) is connected to, it will no longer send 
the frames out the other ports in the switch.  Thus if you are connected 
to a network with an NFS server and client (or what ever protocol) they 
will communicate directly with each other with out the switch sending 
the traffic to your system.

> Many thanks again for your help

You are welcome.



Grant. . . .

Re: [Ebtables-user] Dual-Homed/Triple-Subnet Bridge Challenge

[Vincent C. <vi...@ca...>]

Grant,

Many thanks for your prompt and detailed response. Let me step back and
give you some background before I answer your questions....

It seems to me that I have a VERY UNUSUAL server configuration
requirement. To solve it, I have progressed from examining the following
possible solutions:

1. Arp-filter
2. Bonding/Port Trunking 
3. Bridging

The system in question is an "Image Server" based around Ubuntu 6.06 LTS
(Dapper) Server Edition and Samba. It is essentially a repository for
hard disk images which can be pushed to (and pulled from) the server
using special purpose DOS-based client network boot disks.

These network boot disks use a DHCP address if available but will fall
back to a ZeroConf/LinkLocal/APIPA address in the 169.254.*.* range if a
DHCP Server is not available. This behaviour was originally prompted by
the requirement to be able to use a laptop and cross-over patch lead as
an "Imaging Server" when on the road (the laptop will fall back to a
Zeroconf address in the absence of DHCP). These
universal/general-purpose boot disks are tried-and-tested and I do not
want to modify them or have to maintain different versions for different
Image Server configurations.

My Image Server will, in the first instance, be configured for it's
"home network" for the purpose of software updates and general admin,
file transfers, etc. However, as far as imaging operations are
concerned, it needs to be a general purpose solution and cannot make any
assumptions about the presence or otherwise of a DHCP Server.

For example:

1. I may be imaging (or restoring) the DHCP Server itself (which will be
off-line during the imaging process).

2. I may be imaging (or restoring) on a subnet which does not support
DHCP by design.

3. I may be imaging (or restoring) using a direct/cross-over cable or a
spare switch in the lab.

4. I may even have my Image Server with me on the road.

I might also point-out that adding DHCP Server functionality to the
Image Server itself is not an option as it would conflict with an
existing DHCP server (if present).

In the absence of DHCP, my Image Server needs to match the behaviour of
my client boot disks. Fortunately, the range of "dynamic" Zeroconf
addresses used by the client is restricted so that I can confidently
assign a "static" fall-back address alias to the Imaging Server outside
this range but within the Zeroconf subnet.

My original /etc/network/interfaces file (in the SINGLE-HOMED case)
would have looked something like this:

auto eth0
iface eth0 inet static
address 192.168.3.13
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

auto eth0:0
iface eth0:0 inet static
address 169.254.0.13
netmask 255.255.0.0
network 169.254.0.0
broadcast 169.254.255.255

This SINGLE-HOMED solution has worked exceptionally well and proven
itself over time.

Having recently added a second subnet to my network, I was faced with
the choice of installing a second Image Server on the new subnet or
changing my existing Image Server to a DUAL-HOMED system by adding a
second NIC. Apart from the cost saving, a single image repository is
always preferable from an administration point of view.

The DUAL-HOMED version of my /etc/network/interfaces file would have
looked something like this:

auto eth0
iface eth0 inet static
address 192.168.3.13
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

auto eth0:0
iface eth0:0 inet static
address 169.254.0.13
netmask 255.255.0.0
network 169.254.0.0
broadcast 169.254.255.255

auto eth1
iface eth1 inet static
address 192.168.4.13
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255

auto eth1:0
iface eth1:0 inet static
address 169.254.0.14
netmask 255.255.0.0
network 169.254.0.0
broadcast 169.254.255.255

Of course, my fallback Zeroconf addresses will no longer work in this
scenario because eth0:0 and eth1:0 are within the same subnet and you
have what essentially boils down to a routing conflict.

I initially tried an arp-filter solution, which I was able to verify by
pinging the server from Zeroconf clients on each subnet. Unfortunately
Samba will not play nicely in this scenario, probably something to do
with netbios broadcasts, which are initiated from the server side. This
pointed to the need for a round-robin ARP broadcast mechanism across the
two interfaces.

This prompted me to try a bonding solution using mode 3 (broadcast). My
/etc/network/interfaces configuration then looked something like this: 

auto bond0
iface bond0 inet static
address 169.254.0.13
netmask 255.255.0.0
network 169.254.0.0
broadcast 169.254.255.255

auto bond0:0
iface bond0:0 inet static
address 192.168.3.13
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

auto bond0:1
iface bond0 inet static
address 192.168.4.13
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255

The bonding solution worked perfectly...well almost so.

This solution falls down if I am imaging multiple Zeroconf clients
simultaneously on both subnets. As both sides of the Zeroconf subnet are
distinct, address conflicts may not get picked up during client address
negotiation. Admittedly, this will be a rare eventuality, particularly
since client addresses are generated randomly and seeded uniquely, but
nevertheless, it is not a strictly correct solution.

...and that brought me to my bridging "challenge" and your reply.

And so to your questions:

> I must ask, why not bind the 169.254.x.y/16 subnet to the 
> eth1:0 interface?

Because of routing conflict (as discussed above)
 
> Note that aliased interfaces are usually not ""real 
> interfaces in such 
> as they do not appear as an interface that can be used in 
> routing and / 
> or firewalling / filtering.  As such, you are effectively 
> dealing with 
> the real unaliased interface.

Sorry, I should have just said bridge from eth0 to eth1 (not eth0:0 to
eth1)

> Are you planing on having the eth1 network having multiple subnets on 
> it, i.e. the 169.254/16 subnet, or will devices on the 192.168.4/24 
> network route via 192.168.4.13 to get to the 169.254/16 subnet?

eth1 will interface to both 169.254.*.* and 192.168.4.*
eth0 will interface to both 169.254.*.* and 192.168.3.*

That's THREE subnets in total on TWO interfaces
with no routing between these subnets
but I do need to bridge between eth0 and eth1 for 169.254.*.* traffic
only

> For the sake of discussion I'm going to presume that you will not be 
> routing the 169.254/16 subnet and that devices will be directly 
> connected to eth1.
> 
> Build a bridge containing eth0 and eth1 and use EBTables to filter 
> traffic that is bridged based on the source / destination IP address. 
> For example:
> 
> ebtables -t filter -A FORWARD -s 169.254.0.0/16 -j ACCEPT 
> ebtables -t filter -A FORWARD -d 169.254.0.0/16 -j ACCEPT 
> ebtables -t filter -A FORWARD -j DROP
> 
> Seeing as how the only use of the bridge (as I see it) is to 
> bridge the 
> 169.254/16 traffic, you can and should have the bridge block 
> (DROP) all 
> other traffic.  Your services will still be bound to the eth0 
> and eth1 
> interfaces, thus not being dependent on the bridge.

That looks good and makes sense even to me :)
You say that my services will be bound to eth0 and eth1.
Does that mean all three subnets will be visible?
 
> I'd suggest that you not have IPTables see your bridged 
> traffic unless 
> you have a specific reason to do so.  Use EBTables to do your 
> filtering.

That's fine - I have no need for IP filtering (or forwarding) anyway.

> 
> One thing to keep in mind with this bridge is that you will have some 
> ARP broadcasts that are common that you may what to filter out.
> 

I will want ARP broadcasts on 169.254.*.* to permeate both interfaces
so that Zeroconf clients on either interface can detect conflicts during
address negotiation. But I don't want ARPs from other subnets getting
bridged.
Do I need extra ebtables commands to ensure this?

> > If this is indeed possible, will server performance
> > be seriously degraded by non-169.254.*.* traffic on 
> > either interface?
> 
> Unless you are talking about millions of packets, I don't 
> think you will 
> have a problem.
> 

My very basic understanding about Linux bridging is that each NIC is
placed
in promiscuous mode and the switches will also pass traffic which would
not otherwise be visible on the Image Server ports. In other words,
all traffic on each subnet is visible to the server and needs to be
processed (and ignored where applicable).

So let's say there is a heavy NFS backup happening on the 192.168.3.*
subnet
between two other servers. Will this traffic create a lot of unnecessary
processing overhead for my Image Server?

Many thanks again for your help