I created many squeeze/wheezy containers by the same instruction (http://blog.foaa.de/2010/05/lxc-on-debian-squeeze/)
The only thing I do different way is that I use a virtual network bridge.
(And I think the problem is that you have a bridge to your network card, not to a virtual device)
Add something like this to your /etc/network/interfaces (using your own numbers):
#VLAN 5
auto eth0.5
iface eth0.5 inet manual
vlan_raw_device eth0
auto vzbr5
iface vzbr5 inet static
address 10.11.15.1
netmask 255.255.255.0
network 10.11.15.0
broadcast 10.11.15.255
bridge_maxwait 0
bridge_ports none
post-up /usr/sbin/brctl addif vzbr5 eth0.5
post-up /sbin/ifconfig eth0.5 up
Then
sudo ifup vzbr5
After that use vzbr5 as a network device.
Please see the complete instruction.
A better way to make your change permanent is to use sysctl instead of writing to /proc directly since that is the standard way to configure kernel parameters at runtime so they are set correctly at next boot:
# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start
As for the answer to the question in your update...
bridge-netfilter (or bridge-nf) is a very simple bridge for IPv4/IPv6/ARP packets (even in 802.1Q VLAN or PPPoE headers) that provides the functionality for a stateful transparent firewall, but more advanced functionality like transparent IP NAT is provided by passing those packets to arptables/iptables for further processing-- however even if the more advanced features of arptables/iptables is not need, passing packets to those programs is still turned on by default in the kernel module and must be turned off explicitly using sysctl.
What are they here for? These kernel configuration options are here to either pass (1) or don't pass (0) packets to arptables/iptables as described in the bridge-nf FAQ:
As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.
Is it safe to disable all bridge-nf-*? Yes, it is not only safe to do so, but there is a recommendation for distributions to turn it off by default to help people avoid confusion for the kind of problem you encountered:
In practice, this can lead to serious confusion where someone creates
a bridge and finds that some traffic isn't being forwarded across the
bridge. Because it's so unexpected that IP firewall rules apply to
frames on a bridge, it can take quite some time to figure out what's
going on.
and to increase security:
I still think the risk with bridging is higher, especially in the
presence of virtualisation. Consider the scenario where you have two
VMs on the one host, each with a dedicated bridge with the intention
that neither should know anything about the other's traffic.
With conntrack running as part of bridging, the traffic can now
cross over which is a serious security hole.
UPDATE: May 2015
If you are running a kernel older than 3.18, then you may be subject to the old behavior of bridge filtering enabled by default; if you newer than 3.18, then you can still be bitten by this if you've loaded the bridge module and haven't disabled the bridge filtering. See:
https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44
After all these years of asking for the default of bridge filtering to
be "disabled" and the change being refused by the kernel maintainers,
now the filtering has been moved into a separate module that isn't
loaded (by default) when the bridge module is loaded, effectively
making the default "disabled". Yay!
I think this is in the kernel as of 3.17 (It definitely is in kernel
3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")
Best Answer
It is possible to run a different distribution, but the kernel that's being used, has to be the same.
So if your Debian and ubuntu use the same kernel or can work with the same kernel, there shouldn't be a problem. I don't know however if 12.04 can support the latest lenny kernel (it's pretty dated and support has been dropped for lenny by debian).