[Resolved] Host-only network stops working, when connecting to 192.168.x.x IP-network (#18857)

[socratis]

---

ModEdit; related ticket: #18857: Host-only network: Guest -> Host communication fails when host connected to 192x168.X.X IP-network

---

Running fresh out of ideas, so looking for insights.

Two separate *cabled* networks in our company, call them "Corp" and "RD".

VirtualBox Setup:
Host: Windows 10
Guest: Xubuntu 16.04
Host-only networking (only this net adapter enabled!)

I seem to be losing host-only network access from guest to host when connecting to the "RD" network, but everything is OK with the "Corp" network connection

I've been looking at the routing tables and there are no real differences, apart from the actual changing networking addresses in the routing tables, of course. Routing metrics are the same and default routers are present as they should. I also tried dropping all outbound routes, when RD network cable is connected, and the routes are in fact dropped (I lost the Host OS internet connectivity), but the pinging still fails.

Also capturing with Wireshark and/or VirtualBox PCAP capture (See VBox Wiki: "Network_tips") only show that the ping replies stops when RD-cable is connected and resume when cable is disconnected. (Example from disconnecting cable attached).

It is odd that the ping for the host-only network interface stop, as logically it should be a dedicated subnet, and the Host OS should know how to route the replies back to the guest..

I tried pinging the Host-only setup DHCP server address and Host I/F address from both the Guest and Host OSes.
Detailed Ping testing results:

Disconnected:
Guest -> Hostonly DHCP: OK
Guest -> Hostonly I/F: OK

Corp cable connected:
Guest -> Hostonly DHCP: OK
Guest -> Hostonly I/F: OK


RD cable connected:
Guest -> Hostonly DHCP: OK
Guest -> Hostonly I/F: *NOK*
BUT:
Host -> Hostonly DHCP: OK
Host -> Guest I/F: OK


So, you can see that in the failing case the DHCP server replies to ping. BUT: the actual host interface IP address fails to respond.. And it is also notable the the ping WORKS still from HOST -> GUEST.

[mpack]

Your post doesn't make sense. The "only" in the "Host-Only" name means that this network mode is entirely virtual, there are no connections to any physical network. If there was then the DHCP servers would conflict.

If you want a VM to participate in a host network then the proper modes are NAT or Bridged, depending on what level of participation the VM requires (bridged is for full participation e.g. as a server, NAT is for simpler requirements, e.g. Internet browsing).

[Stradman]

Your post doesn't make sense. The "only" in the "Host-Only" name means that this network mode is entirely virtual, there are no connections to any physical network. If there was then the DHCP servers would conflict.

My sentiments exactly. With my "narrow" experience in IP networking I cannot make sense of this issue. And indeed, physically connecting the "RD" network cable brings down the communcation from Guest -> Host, with this "Host-Only" setup. I assume that it would be possible break the Host Only virtual network routing, if the Host-Only addressing overlap with the RD network, and the Ping replies would be routed wrong, to the outside network and not to Host-Only.

If you want a VM to participate in a host network then the proper modes are NAT or Bridged, depending on what level of participation the VM requires (bridged is for full participation e.g. as a server, NAT is for simpler requirements, e.g. Internet browsing).

I have some proprietary software running both on the Host and Guest, that need to be interconnected. And the RD network access would be needed for connecting and deploying the software to outside devices. Obviously, I can disconnect the cable whenever I don't need the RD-network access, but seems a bit.. ehm.. stupid.

Is there a tracing option to enable in VirtualBox to see what happens in the Host-Only interface in code?

[socratis]

Is there a tracing option to enable in VirtualBox to see what happens in the Host-Only interface in code?

Chapter 8.8.2 Networking Settings for setting up the VM. Note the "--" in front of your options:

VBoxManage modifyvm <uuid|vmname>
                    [--nictrace<1-N> on|off]
                    [--nictracefile<1-N> <filename>]

Chapter 8.13 VBoxManage controlvm for controlling a running VM. Note the lack of dashes:

VBoxManage controlvm <uuid|vmname>
                     nictrace<1-N> on|off |
                     nictracefile<1-N> <filename>

[Stradman]

I did already the NIC tracing, before posting the thread, but the PCAP trace did not reveal anything useful to me..

For further tracing I was asking if there are developer logs from the code, that I could check or provide..

[socratis]

No, there not more. But I'll agree and reiterate what mpack said: it doesn't make any sense, unless there's a conflict of network ranges. Let's see if our network guru-users have anything more to say on the matter. I can't even read PCAPs...

[scottgus1]

Not a network guru, but I'll take a whack...

As I understand it, the Host-only network with the Xubuntu guest works when your host PC is connected to the Corp network, but Host-only stops working when your host PC is connected to the RD network. Please try this:

Shut down your guest.
Connect your PC to Corp. Run "ipconfig /all" on the host. Start the guest. Let it stabilize then run "ifconfig" on the guest. Please post the outputs of these two commands, labeling each.

Shut down your guest again.
Connect your PC to RD. Run "ipconfig /all" on the host. Start the guest. Let it stabilize then run "ifconfig" on the guest. Please post the outputs of these two commands, labeling each.

Let's see if the IPs or masks reveal anything.

[fth0]

I have more knowledge about networks than about VirtualBox (at least I think so ). In addition to the info requested by scottgus1:

@Stradman:
Can you also provide PCAP files from the guest and from the host, capturing all network interfaces on the host simultaneously?

@socratis:
PCAP files can be relatively large. Any hints for the OP how to provide them depending on their size?

[Stradman]

@Stradman:
Can you also provide PCAP files from the guest and from the host, capturing all network interfaces on the host simultaneously?

I can try, hopefully I have time at the beginning of the week. I already did, actually, but I did not see anything too fishy-

There should not be any IP overlaps in the current setup, in the OP yuo can see what I have configured for the guest Host-Only network:

10.69.69.0/24
RD network has: 192.168.X.X/17 (NOTE: this *would* overlap with the VBox default settings for Host-Only: 192.168.X.X/16, which is a larger subnet block than /17 mask).


I am kind of inclined to think, that the problem might be in the RD network, as it is a bit "wild" environment.
I didn't do a pen-and-paper-exercise yet, but assume that there is a device that has 10.0.0.0/8 network and an IP assignment (say, 10.0.0.2), configured in the same broadcast-domain that I have with my Host-only: 10.69.69.0/24. Now the ARP-request (broadcast) would be picked up by that 10.0.0.2 device? And it would reply directly to the requesting interface, hence the ping reply would be sent to the wrong recipient, 10.0.0.2. I am not sure if this would be possible in real-life, since I have been lucky to have confirgured my neworks correctly in the past (eventually)..

This is why I am bit puzzled of thinking the Host-only -interface as "bridged but not quite": From the manual: "As with bridged networking, the virtual machines can talk to each other and the host as if they were connected through a physical Ethernet switch"
-> Hence I am thinking about the "broadcast domain"

[fth0]

@Stradman
We are thinking in the same direction. A Wireshark trace on the host capturing on all interfaces simultaneously, and a Wireshark trace on the guest at the same time would show if any packet is visible on an interface where it doesn't belong or isn't expected. I'm interested in anything related to ARP, DHCP, ICMP; if possible/allowed, do not filter the traces. Additionally, you can activate the "--nictrace" options you already know.

When issuing the "ipconfig /all" command, also issue a "route print" command to show the current routing table on the host.

[socratis]

PCAP files can be relatively large. Any hints for the OP how to provide them depending on their size?

If ZIPPING them doesn't get you down below the 128 KB limit, then an external site is your only option. For example, in the following site your file is available for 30 days, limit 5 GB, no registration required: https://uploadfiles.io/

[socratis]

@Stradman
We are thinking in the same direction. A Wireshark trace on the host capturing on all interfaces simultaneously, and a Wireshark trace on the guest at the same time would show if any packet is visible on an interface where it doesn't belong or isn't expected.

Before doing that 1st this morning, I just did plain and simple:

> ping 10.0.0.1

Pinging 10.0.0.1 with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=19ms TTL=254
Reply from 10.0.0.1: bytes=32 time=18ms TTL=254
Reply from 10.0.0.1: bytes=32 time=18ms TTL=254
Reply from 10.0.0.1: bytes=32 time=24ms TTL=254

AND: I am on a network that is:

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection (5) I219-LM
   Physical Address. . . . . . . . . : 8C-16-45-5A-BC-D4
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.119.12(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.224.0
   Lease Obtained. . . . . . . . . . : maanantai 19. elokuuta 2019 9.35.23
   Lease Expires . . . . . . . . . . : maanantai 19. elokuuta 2019 10.35.23
   Default Gateway . . . . . . . . . : 192.168.100.1

So OBVIOUSLY it is a rogue "something" configured in the same physical subnet. Otherwise I see my 5 years of university in networking protocols a bit of good luck

EDIT: a bit of Wiresharking and I find that the MAC-addess in the ping 10.0.0.1 reply shows it's coming from the default GW 192.168.100.1, when looking up the MAC-address from 'arp -a' output. So as such, I guess this network config is valid, but far from optimum. And also, missing a responsible admin..

[Stradman]

OK, I am officially giving up, until beign able to give some developer traces of the VirtualBox drivers / application related to the matter.

There is something fishy about connecting to this physical network, and I know it does not make sense as a "black box" investigation, if you look at it in the way that "it should work, it's only routing". I suspect that something now in this setup breaks the concept of Host-only -networking, which is something of a link/IP-layer hybrid, as I have understood.

My last attempt was to change the IP address block of host-only adapter to a one more different private IP-block, in the Host Network Manager:

• IPv4 address: 172.16.0.1
• IPV4 netmask: 255.240.0.0
  (DHCP server disabled)

Manual IP configuration in the Guest OS side:

• IP 172.16.0.101
• Mask:255.240.0.0

I still end up with the same situation:

• Host -> Guest ping: OK
• Guest -> Host ping: no reply

AND: disconnecting the network cable:
Guest -> Host ping: OK

The last thing I am able to see in the ping process is the ARP reply from 172.16.0.1 (host interface). After that: nothing, so no ICMP reply for the sent ICMP request, so link layer seems OK. But there is IP level routing problem *somewhere*.

[fth0]

So OBVIOUSLY it is a rogue "something" configured in the same physical subnet. Otherwise I see my 5 years of university in networking protocols a bit of good luck

I can understand that you want to solve the problem on your own (with only a little bit of our help). But here are some people with decades of experience that maybe would come to different conclusions than you (or interpret some tiny bits of information otherwise), if they had the full information available.

Up to now, I cannot verify several of your conclusions. For example, I do not understand your conclusion above, the problem could also be located in your host only. (Unless you overlooked the 224 in the subnet mask. )

If you like to have a 2nd opinion, you should deliver the information that you have been interpreting only yourself.

[socratis]

Yes, of course. What puzzles me still here that it works on the other cable, which is of course different IP network altogether... The other thing is that I am not quite sure about how much information I can share on specific details here from the corporation. And fundamentally the thing is, that those Wireshark traces really show nothing to interpret for the matter.. I see lots of other ARP messaging, but all I see on the ICMP level is the request from GUEST -> HOST, in the Host-only interface. Nothing on the other interfaces. Last thing is the ARP-request/reply, no ICMP reply. So somehow the Host-only adapter appears as "down" from GUEST -> HOST -side. But I can of course ping the same address on the HOST.

I might indeed be "overlooking the 224" in the subnet, and surely that would be an issue when attemting the default Host-only config, 192.168.. But I am not sure it is a factor after trying the other subnet configurations for the Host-Only configuration (10. and 172. IP-blocks).