On 06/09/2016 10:24 PM, Simon Hobson wrote:
>> Or I could do as Mr. Hobson does and run shorewall in a container. Would that actually be a more insulated "secure" approach?
>
> "Security" is a relative thing, and depends on your priorities. Putting the firewall in it's own VM would improve isolation (the netfilter rules will be processed in the VM) - but the traffic still goes through the host Dom0. You can, AIUI, reduce this latter bit by running a separate driver domain to own the virtual interfaces and further insulate the traffic from Dom0.
> You could also use PCI passthrough to make a NIC owned by a VM - so Dom0 doesn't handle the packets.
>
> But this all depends on your priorities (or level of paranoia !). I don't think handling the network traffic in Dom0 is "insecure" - just not as secure as if it doesn't handle it.
>

Indeed. And if I was really paranoid, I might use something other than
LXC, since other technologies isolate even more. Though, I might put the
firewall in it's own container even if just for the sake of
modularity/maintenance.


On 06/10/2016 08:06 AM, Greg Olsen wrote:
> On 2016-06-09 02:50, Simon Walter wrote:
>> It seems that bridges do not start with ifup (-a) unless one of their
>> bridged interfaces are up.
>
> That doesn't sound right.
> Here's a bridge I have defined for LXC containers:
>

 > auto lxcbr0
 > iface lxcbr0 inet static
 >          pre-up    brctl addbr $IFACE
 >          address   10.0.0.1
 >          netmask   255.255.0.0
 >          network   10.0.0.0
 >          broadcast 10.0.255.255
 >          bridge_stp off           # disable Spanning Tree Protocol
 >          bridge_waitport 0        # no delay before a port becomes
 > available
 >          bridge_fd 0              # no forwarding delay
 >          up        ip link set $IFACE up
 >          down      ip link set $IFACE down
 >          post-down brctl delbr $IFACE

>
> The IP address is assigned as part of the bridge definition. Like
> Rainer said, no tap device needed.
>
> Due to the "auto lxcbr0" the bridge is brought up automatically
> during system startup.
> It comes up just fine with *no* containers running.

Though, you do need to specify the bridge to be created and destroyed,
which is something I thought was done automatically. It is when there
are ports specified. As Rainer pointed out, when bridge_ports is "none",
then the bridge device is created automatically and one not need to
create it and destroy it pre-up and post-down. Though it seems to do it
explicitly is a bit faster. I am not sure which is better or if there
are any side affects.

> Here's the ifstate resulting from ifup:
> # grep lxcbr0 /run/network/ifstate
> lxcbr0=lxcbr0
>
> I've never had the need to specify a *bridge* interface on the
> Shorewall wait_interface list.
>
> /etc/default/shorewall "wait_interface" is used when you need to
> detect a dynamically assigned IP. I.e. so
> 'find_first_interface_address' can return an IP, which it can't do if
> one hasn't been assigned yet.
>
> However as can be seen in the example above, it already has an IP and
> therefore no need for Shorewall to *wait* for one to be assigned. I
> suggest leaving the bridge off the wait list.

OK, that's good to know. I couldn't find documentation for it. I wasn't
sure what it was for.

> In my setup Dnsmasq is configured to listen on the bridge IP. When
> dnsmasq starts up, the bridge is already there. The LXC containers
> are then DHCP assigned the bridge IP as their default GW. And the
> kernel handles the routing from there, provided IP forwarding is
> turned on.
>
> To have Shorewall turn on forwarding for you, just specify
> "IP_FORWARDING=On" in /etc/shorewall/shorewall.conf.

Yes, I did notice this and have that set up. In fact it was working in
the convoluted way with a tap interface. However, thanks to everyone's
advice, the end result will probably be much better.

Thanks and kind regards,

Simon