0

I'm unable to reach the Internet from my VirtualBox VMs--both Windows 7 and Debian Linux. I need to troubleshoot what's wrong so I can get these VMs working again.

I have a Debian laptop host that's been running VMware VMs in the past and now VirtualBox VMs without any difficulty. Most of my VMs have bridged networking set up through my laptop's wi-fi card, with my home router serving DHCP addresses to the laptop and its VMs.

Lately I've also been using Docker and Docker Compose with no problems. I have a docker0 bridge, but my laptop's Network Manager has also shown br-xxxxxxxxxxxx bridges as well as other bridges with which I'm not familiar but I notice I get more and more each time I create or maybe just start Docker containers.

In any case, I've been able to use bridged networking in the VirtualBox guests to connect from the host laptop to the guest VMs via SSH, HTTP, etc. and vice versa, and to connect from the laptop and from the guest VMs to the Internet, at the very least being able to ping Google's 8.8.8.8.

I'm not sure if this is the cause, but it was definitely different: Over the weekend, I crafted a docker-compose.yaml file piecing together from other sources, and I added the following in mine that I haven't used before in any docker-compose.yaml before:

networks:
   default:
      driver: bridge

Out of all of my Docker Compose files, this is the only one with networks.

When I brought this up with docker-compose up the first time, I could've sworn I saw a different bubble in my notification area for Network Manager, but I can't be sure.

Normally, I do recall I get additional bridges and after a couple of days or weeks I go through Edit Connections and manually delete those extra bridges as they get older.

Anyway, I didn't pay much attention to the extra bubble, and my containers came up without any problem. I exposed ports and was able to browse to them via http://localhost:nnnn as usual, and I didn't give it much more thought.

Today was the first time in about a week or two that I started one of my VirtualBox VMs--a Windows 7 guest. Once it came up, I realized I couldn't connect to the Internet. I launched a Command Prompt and realized I couldn't even ping 8.8.8.8, and ipconfig reports no IP address.

I tried one of my Debian VMs. Same thing--can't ping 8.8.8.8 and no IP address reported by /sbin/ifconfig eth0.

The host laptop is perfectly happy with a private IP address and me visiting http://superuser.com to post this very question.

What are my next steps to troubleshoot this?

EDIT: I'm not exactly sure what I did, but I managed to get my VMs to get an IP address and connect to the Internet.

First of all, it took me a while to type up the above, so I don't know if I just needed to wait a while. That seems silly, and I have never had to do that before.

I recall earlier restarting the Docker daemon on the host (sudo /etc/init.d/docker restart), but I didn't see any obvious changes after I did that.

Prior to that, I had rebooted the laptop. I recall when it came back up, I started the VMs and the Internet connection still wasn't working in the VMs.

Prior to rebooting, I performed silly little ifdown/ifup and ipconfig /release and ipconfig /renew, and then I started deleting those bridges I mentioned in Network Manager, but this time I deleted all the bridges--even the ones that were current and the docker0 bridge. At the time, that didn't appear to make any difference.

I had also powered the VMs off and on in no particular order.

That's about it.

Update (3/15/2018): It's much worse now; my VMs are having difficulty getting an IP address and can't ping 8.8.8.8 at all now from inside the VMs. This is happening both with VirtualBox VMs and VMware VMs.

Docker containers are able to get to the Internet without any difficulty.

Here are my bridges on the host laptop while I have one of my Debian VMs running:

# brctl show
bridge name bridge id       STP enabled interfaces
br-993886a09e53     8000.02424635b59c   no      
br-9d3771956e43     8000.0242c5e9afa6   no      
br-ce4e98cb7458     8000.0242561fb6fc   no      
br-ef846b86506c     8000.0242982b55d7   no      
br-fd2186a1e375     8000.02426f4ae98a   no      
docker0     8000.024258c6aaa0   no

The VM's network settings show its Adapter 1 is Attached to Bridged Adapter Name wlan0. Promisuous mode is set to Deny and Cable Connected is checked.

Here are the devices I have:

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 24:b6:fd:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether c0:18:85:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: br-ef846b86506c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:98:xx:xx:xx brd ff:ff:ff:ff:ff:ff
7: br-fd2186a1e375: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:6f:xx:xx:xx brd ff:ff:ff:ff:ff:ff
8: br-993886a09e53: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:46:xx:xx:xx brd ff:ff:ff:ff:ff:ff
9: br-9d3771956e43: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:c5:xx:xx:xx brd ff:ff:ff:ff:ff:ff
10: br-ce4e98cb7458: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:56:xx:xx:xx brd ff:ff:ff:ff:ff:ff
11: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:58:xx:xx:xx brd ff:ff:ff:ff:ff:ff
12: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
13: vboxnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff

Here are my firewall rules. The list was much shorter until I tried to install ufw and gufw, then ran gufw, enabled it, and then disabled it.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-input  all  --  anywhere             anywhere            
ufw-before-input  all  --  anywhere             anywhere            
ufw-after-input  all  --  anywhere             anywhere            
ufw-after-logging-input  all  --  anywhere             anywhere            
ufw-reject-input  all  --  anywhere             anywhere            
ufw-track-input  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-ISOLATION  all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ufw-before-logging-forward  all  --  anywhere             anywhere            
ufw-before-forward  all  --  anywhere             anywhere            
ufw-after-forward  all  --  anywhere             anywhere            
ufw-after-logging-forward  all  --  anywhere             anywhere            
ufw-reject-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-output  all  --  anywhere             anywhere            
ufw-before-output  all  --  anywhere             anywhere            
ufw-after-output  all  --  anywhere             anywhere            
ufw-after-logging-output  all  --  anywhere             anywhere            
ufw-reject-output  all  --  anywhere             anywhere            
ufw-track-output  all  --  anywhere             anywhere            

Chain DOCKER (6 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain ufw-after-forward (1 references)
target     prot opt source               destination         

Chain ufw-after-input (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-input (1 references)
target     prot opt source               destination         

Chain ufw-after-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-after-output (1 references)
target     prot opt source               destination         

Chain ufw-before-forward (1 references)
target     prot opt source               destination         

Chain ufw-before-input (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-input (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-before-output (1 references)
target     prot opt source               destination         

Chain ufw-reject-forward (1 references)
target     prot opt source               destination         

Chain ufw-reject-input (1 references)
target     prot opt source               destination         

Chain ufw-reject-output (1 references)
target     prot opt source               destination         

Chain ufw-track-input (1 references)
target     prot opt source               destination         

Chain ufw-track-output (1 references)
target     prot opt source               destination

I tried creating a /etc/sysctl.d/bridge.conf with the following:

# Reference: https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

Then ran sysctl -p.

I tried running Wireshark and also tcpdump on the host laptop and watched what happened when I ran dhclient eth0 inside the VM:

# tcpdump -ni wlan0 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:03:45.275713 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275788 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418183 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418277 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220658 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953865 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953936 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275713 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.275788 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418183 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:45.418277 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220658 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:49.220749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953865 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:03:51.953936 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:04.084840 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:04.084909 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:16.898585 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:16.898688 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:26.201038 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300
19:04:26.201150 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:xx:xx:xx, length 300

If I did everything correctly, this is telling me traffic is leaving the bridge but not getting back in, so it's an ingress problem?

Also I noticed today that another laptop on the same home network cannot log-in via SSH to this laptop; I'm not sure if it's related.

I can SSH to the laptop from itself:

$ ssh user@localhost
$ ssh [email protected]

However, if I try to connect via WinSCP from another laptop, it seems to time out. Wireshark showed absolutely no activity coming into this laptop from the other laptop.

This laptop used to be able to connect about six weeks ago.

I checked the router's configuration, and there didn't appear to be anything out of the ordinary.

Similarly, I tried connecting over SSH from an Android phone using the ConnectBot app. This used to work as well, and now I'm seeing the following in the ConnectBot output:

Connecting to 192.168.1.8:22 via ssh

Connection Lost
recvfrom failed: ECONNRESET (Connection reset by peer)
recvfrom failed: ECONNRESET (Connection reset by peer)
Improve this question

2 Answers 2

Reset to default
0

Although I don't think I have a clear answer for you based on the data provided, I can provide some steps that might in general help you troubleshoot this.

First, if the issue happens again, and you're using regular Linux bridging, you can use brctl show to get a list of the bridges and attached devices like this:

$ brctl show
bridge name bridge id       STP enabled interfaces
bridge0     8000.fc4ee55116da   no      eno1
                                        vnet0
                                        vnet1
docker0     8000.0242e112327f   no      vethb4eb5fc
virbr0      8000.5254004579e4   yes     virbr0-nic

In the above, bridge0 has my ethernet card and two VM's, each with one interface apiece. I also run Docker and have a docker bridge, and have a NAT'd libvirt network which spawns virtio as a bridge (but I don't have any VM's doing anything with it right now). I imagine yours, if it's experiencing problems, might be disconnected or not showing up under the bridge. You can use ip link show to see what devices are present.

If everything is fine there, perhaps the firewall/netfilter is blocking bridge traffic. You can read more about this here on Libvirt's doc page (I know you are using VirtualBox but this applies to bridges overall, not just any one virtualization mechanism).

Lastly, you might want to see if traffic is getting to the VM's at all. You can do this with tcpdump, although if you're not familiar with networking it might be a bit hard to decipher the traffic. Just pick an interface and tap it; might I recommend tapping the bridge to see if you can see DHCP traffic coming out at all from the VM. Steps would be something like:

  1. On the VM, run dhclient eth0 or the suitable process to try and get an IP address from your DHCP server.

  2. On the host, tap the bridge and inspect DHCP traffic (UDP port 67).

    $ sudo tcpdump -ni bridge0 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge0, link-type EN10MB (Ethernet), capture size 262144 bytes

  3. If you see traffic passing by that has the MAC address of your VM, then traffic is leaving the bridge but probably not getting back in, meaning we have an ingress problem. If you see no traffic at all, tap the vnet device in the same way as the bridge itself and see if you see the DHCP traffic; if you do, then traffic isn't leaving the bridge, meaning we have a problem with egress. Both probably require looking at firewall rules/sysctls/netfilter.

Improve this answer
0

Rebooting the home router fixed both problems for me. The remote laptop was able to SSH into my Debian laptop after the router was rebooted, and my VMs' Internet access and LAN access was working well once again.

Improve this answer

You must log in to answer this question.

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