4

Context

  • I develop websites on my Ubuntu laptop (Ubuntu 13.04 64b).
  • Each site runs within a dedicated LXC container¹ on network 10.0.3.x
  • I sometimes need to reach those sites from a virtualbox guest running Windows²

It used to work "out of the box", but a few weeks ago, it just stopped. I guess after an Ubuntu update but was it a LXC or a Virtualbox or even a "network stuff" update ? I can't tell since I don't run those tests every day.

¹ To fake various and complex platforms and only use ressources I actually need.

² To test them under Windows browsers.

The question :

How should I setup my Virtualbox/LXC/host network configurations to reach the websites on LXC containers from the Virtualbox guest ?

What I have done so far

My current virtualbox setup is to have 2 network cards.

  • A bridge on wlan0 (to access the Internet)
  • A bridge on LXC virtual card lxcbr0 (to access the containers)

A Weird thing : I can ping LXC containers from the Windows VM, but I can't access them in HTTP (browsers or telnet on port 80).

Only actually started containers responds to ping.

I tried a bunch of others setups but I am more "guessing" than understanding what is going on.

My current workarround

I setup a port forward on my host with iptables, as I would do to make a container reachable on the whole network (it's actually what it does).

When I do so I can reach the forwarded container from the Windows VM.

But this is definitly not a clean solution :

  • I can only access one container at the time (or I have to use different ports)
  • I need to reconfigure iptables any time I switch project
  • I actually give access to the container to the outside world
  • I need to have an active LAN or WAN connection
  • I can hardly use domain names anymore (I have a host file in Windows matching container's ip)

3 Answers 3

2

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:

VirtualBox configuration

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
1
  • Well, I can't really test and validate your solution since I switched to Docker a long time ago, but nice answer for those who would come accross the same issue in the future, thanks for sharing!
    – Huge
    May 24, 2016 at 8:44
1

Had exactly the same problem. Almost certainly the "fault" of VirtualBox, which seems to do bridged networking it's own way, probably to remain consistent across the various platforms (Mac, Solaris and that other one). Evidence:

  • VBox bridged network interfaces do not appear in "brctl show" (as do LXC veth's)
  • documentation has: "VirtualBox uses a device driver on your host system that filters data from your physical network adapter"

Really weird that ICMP is getting through, but TCP (and likely others) ain't...

However, documentation also has "you can still use TAP interfaces for certain advanced setups", so I investigated attaching a new TAP to my bridge:

# ip tuntap add mode tap
# brctl addif brY tapX
# ip link set tapX up

Then adjusted the VBox network settings to use tapX instead of brY and it all came good (after rebooting the guest).

Experimented with two guests sharing the same tapX, not sure it worked so well. Probably safest to use one tap for each VBox guest.

0

If you can ping the target but can not access applications there then it is an iptables issue, almost sure.

My guess is during update process you got the system flag "net.bridge.bridge-nf-call-iptables = 1" checked ON in /etc/systcl.conf.

If so, I would not drop it OFF, but revise the iptables setup instead.

2
  • I don't have this param in the file nor in /etc/sysctl.d/*. Also, sudo iptables --list return no rules on laptop startup with or without a container started. I guess the magic happens somewhere else (netwok-manager stuff ?). I am using Ubuntu 13.04, I'll edit my question to add that precision.
    – Huge
    Nov 25, 2013 at 10:05
  • I can not imagine such kind of magic except VirtualBox introduces very special networking tricks. What type of network does the VirtualBox use?
    – Veniamin
    Nov 25, 2013 at 16:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .