Simon Walter <simon@???> writes:
> On 06/05/2016 12:16 AM, Rainer Weikusat wrote:
>> Simon Walter <simon@???> writes:
>>
>> [...]
>>
>>> I am adding containers (LXC) and
>>> virtual network to the box, I think I will add an tap and bridge
>>> interface to an /etc/network/interface.d/ file. If I use something
>>> like:
>>>

>>> auto br0
>>> iface br0 inet static
>>>      pre-up ip tuntap add dev tap0 mode tap
>>>      pre-up ip link set tap0 up
>>>      post-down ip link set tap0 down
>>>      post-down ip tuntap del dev tap0 mode tap
>>>      bridge_ports tap0
>>>      address 10.1.1.1
>>>      netmask 255.255.255.0
>>>      broadcast 10.1.1.255

>>>
>>> And make sure there is the source /etc/network/interface.d/* line in
>>> the interfaces file. Then route with iptables between the a physical
>>> NIC (eth0 for example) and the virtual NIC (tap0) and have all the
>>> containers connected to br0.
>>>
>>> Are there any glaring problems with this setup?
>> This will create a bridge with one virtual network interface bridged to
>> a character device an application could use to talk 'ethernet' to the
>> network stack. That's certainly not inherently related to/ useful for
>> anything-lxc.
>>
>
> I will route the packets to the physical device using iptables,
> thereby creating a firewalled private network. I have only tried it
> out and not done much research and testing on whether this is actually
> secure or not.

You don't need the tap port for that, the bridge will happily work
without any ports statically assigned to it.

The machines I'm dealing with use a bridge as 'main interface' a
principally arbitrary number of (lxc) containers connect to via veth
with one physical interface also assigned to the bridge to provide
actual connectivity. It's also possible to do packet filtering between
bridge ports if that's considered to be desirable/ useful. 'Introduction
site'

http://ebtables.netfilter.org/

One of the advantages of ip(route) over the older, BSD-style tools is
that they can be used to assign an arbitrary number of protocol
addresses to a single interface without employing 'interface aliases'.