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")
Following the suggestion of user228273 i could find configuration that solved the problem:
First I created a tap interface named tap0, and I brought it up:
ip tuntap add mode tap tap0
ip link set tap0 up
if one of the previous command fails, it is probably because you already have a tap0
interface. Use the command
ip link show
to assess the situation, and eventually change the interface name.
Now you can add the tap0
interface to the default bridge that under Ubuntu is named lxcbr0
.
brctl addif lxcbr0 tap0
Then i configured my VirtualBox to use a "Bridged Adapter" on the interface tap0
as shown below:
And then the VirtualBox instance and the LXCs can "see" each others.
2019 Update :
If you're using NetworkManager you can make this addition using nmcli:
nmcli connection add type tun ifname tap0 con-name tap0 mode tap master lxcbr0
Best Answer
If you're still having this problem, can you post the /etc/network/interfaces file for the container?
If you have a netmask of 255.0.0.0 that could be a problem, because github.com's IP is 192.30.253.113. Switching the netmask to 255.255.255.0 may resolve this after restarting the container.
I just had a similar problem on a debian VirtualBox machine and this resolved it for me.