[Resolved] Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

This is for discussing general topics about how to use VirtualBox.

[Resolved] Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 24. Apr 2019, 20:20

Hello,

I have a machine with Ubuntu 16.04 and VirtualBox 6.0.6 (the host) and a virtual machine with Debian 9.4.0 (the guest).

There is an application server on the guest which I need to access from the host. When I configure the virtual network adapter as host-only, everything works fine.

Now, I would also like to access the application server on the guest from another machine with CentOS 7 that I will name the visitor (please note that it is a real machine, not a virtual one).

Host and visitor happen to be on the same LAN, so I think I should just configure the virtual network adapter for the guest as bridged and that should be it. When I do, the following occurs:

  • The guest correctly receives a valid IP address from the DHCP server and seems to be integrated in the LAN too.
  • The communication between host and guest works perfectly. I can still use the application server and if I ping either machine from the other one no packages are lost.
  • However, I can only access the application server on the guest from the visitor occasionally. Sometimes it does work, but most of the time it does not.
  • If I ping the guest from the visitor, the package loss is around 90 %, but some packages do arrive.
  • If I ping the visitor from the guest, no packages are lost.
  • If I ping the guest from the visitor while the visitor is sending ping packages to the guest, no packages are lost. In that case, I can use the application server running on the guest from the visitor and everything works fine.
Long story short, everything works fine as long as I keep sending ping packages from the guest to the visitor all day long. However, the minute I stop doing that, the connection between the visitor and the guest works irregularly and scarcely.

In case someone is wondering, no firewall is active in any of the three machines.

Any hints on how to fix it?

Thank you in advance!
Last edited by olavide on 29. Apr 2019, 12:36, edited 3 times in total.
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter

Postby socratis » 25. Apr 2019, 08:07

olavide wrote:Host and visitor happen to be on the same LAN, so I think I should just configure the virtual network adapter for the guest as bridged and that should be it.
Exactly. Configuring the VM with a Bridged mode is *the* way to go. There are other ways if that fails (NAT/NATservice with port-forwarding), but the Bridged mode is the most straight-forward solution.

olavide wrote:Sometimes it does work, but most of the time it does not.
Is the NIC attached to a Bridged-over-WiFi, or a Bridged-over-Ethernet? The former may or may not work and that would explain the symptoms that you're describing. Can you try with Bridged-over-Ethernet if possible/available?
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
socratis
Site Moderator
 
Posts: 25224
Joined: 22. Oct 2010, 11:03
Location: Greece
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5

Re: Networking: irregular behaviour with bridged adapter

Postby olavide » 25. Apr 2019, 08:19

Thanks a lot for answering. Sorry I forgot to include that information. Both real machines (host and visitor) are desktop computers connected via Ethernet. They do not even have a wireless card.

This is the output from lshw -class network:

Host
Code: Select all   Expand viewCollapse view
  *-network
       description: Ethernet interface
       product: 82579LM Gigabit Network Connection (Lewisville)
       vendor: Intel Corporation
       physical id: 19
       bus info: pci@0000:00:19.0
       logical name: eno1
       version: 05
       serial: 74:46:a0:ba:d2:b4
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.13-4 ip=192.168.1.242 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:34 memory:ef300000-ef31ffff memory:ef32d000-ef32dfff ioport:e040(size=32)

Visitor
Code: Select all   Expand viewCollapse view
  *-network                 
       description: Ethernet interface
       product: Ethernet Connection (2) I218-V
       vendor: Intel Corporation
       physical id: 19
       bus info: pci@0000:00:19.0
       logical name: eno1
       version: 05
       serial: d8:cb:8a:e7:f1:b3
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.1-4 ip=192.168.1.184 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:34 memory:fb400000-fb41ffff memory:fb438000-fb438fff ioport:f000(size=32)
Last edited by socratis on 25. Apr 2019, 10:54, edited 1 time in total.
Reason: Enclosed the information in [code] tag for better readability
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby scottgus1 » 25. Apr 2019, 16:29

Virtualbox Bridged normally stays connected all the time, if the host PC is working fine. I have had Bridged guests stay connected for weeks (the office domain controller I IT'd for several years was a Virtualbox guest, Bridged.) This sort of unusual behavior not normally reported on the forums indicates the problem may be just with your host PC.

First thought, since your host OS is Ubuntu, do you have the Ubuntu fork of Virtualbox installed? If so, try uninstalling it then installing from the official Virtualbox. I saw the command in one of Socratis' posts to type in the Ubuntu terminal to find out, don't know where the post is... We would only know what official Virtualbox may do, so we ask for it to be installed instead of the Linux distro's fork.

Second, can you update the computer's network card drivers? Maybe they're old? Had a network dropout glitch once on the office domain controller's host when transferring large files. Host network card driver update solved it.
Human government is like that crazy uncle who hides a quarter in his fist behind his back, then asks you to guess which fist the quarter is in...
No matter which side you choose, Left or Right, both Sides are empty.
scottgus1
 
Posts: 4262
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Win7

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 26. Apr 2019, 09:14

I was not aware that there exists an Ubuntu fork, but I am pretty sure I am not using it, because I downloaded the Ubuntu package from https://www.virtualbox.org/wiki/Linux_Downloads. I have not found Socratis' post with the command to check either, but I have opened a log from the VM and searched for the the word Ubuntu. Only two matches were found:
Code: Select all   Expand viewCollapse view
00:00:00.196111 OS Version: #172-Ubuntu SMP Wed Apr 3 09:00:08 UTC 2019
00:00:00.196238 Package type: LINUX_64BITS_UBUNTU_16_04

Also, the very first line of the log is this:
Code: Select all   Expand viewCollapse view
00:00:00.468371 VirtualBox VM 6.0.6 r130049 linux.amd64 (Apr 16 2019 10:37:08) release log

However, I might be using a Debian fork of the guest-utils on the guest. Searching for Debian in the log file returns seven matches:
Code: Select all   Expand viewCollapse view
00:00:00.250501 Guest OS type: 'Debian_64'
00:00:00.266904 File system of '~/Downloads/debian-9.4.0-amd64-netinst.iso' (DVD) is ext4
00:00:00.299325   Path      <string>  = "~/Downloads/debian-9.4.0-amd64-netinst.iso" (cb=54)
00:00:12.696341 VMMDev: Guest Additions information report: Version 5.2.10 r121806 '5.2.10_Debian'
00:00:15.141585 VMMDev: Guest Log: VBoxService 5.2.10_Debian r121806 (verbosity: 0) linux.amd64 (Apr 26 2018 08:56:30) release log
00:00:15.141900 VMMDev: Guest Log: 00:00:00.000586 main     OS Version: #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
00:00:15.152930 VMMDev: Guest Log: 00:00:00.011579 main     5.2.10_Debian r121806 started. Verbose level = 0

And apt list *virtualbox-guest* on the guest returns the following:
Code: Select all   Expand viewCollapse view
Listing...
virtualbox-guest-additions-iso/stretch-backports 5.2.24-1~bpo9+2 all
virtualbox-guest-dkms/stretch-backports 5.2.24-dfsg-4~bpo9+1 all [upgradable from: 5.2.10-dfsg-6~bpo9+1]
virtualbox-guest-source/stretch-backports 5.2.24-dfsg-4~bpo9+1 all
virtualbox-guest-utils/stretch-backports 5.2.24-dfsg-4~bpo9+1 amd64 [upgradable from: 5.2.10-dfsg-6~bpo9+1]
virtualbox-guest-x11/stretch-backports 5.2.24-dfsg-4~bpo9+1 amd64

Which at the very least suggests I should upgrade the couple of packages that are indeed installed. Actually, I do not need the guest-utils anymore (I installed them back in the day to transfer files, but that is over), so I might as well just purge them. I have checked the /etc/apt/sources.list files and the one on the host does contain deb https://download.virtualbox.org/virtualbox/debian xenial contrib, but the one on the guest does not contain deb https://download.virtualbox.org/virtualbox/debian stretch contrib (or anything from virtualbox.org for that matter).

What do you recommend doing? My gut feeling is to just purge the guest-utils, but I'd rather ask first. Once we are done with that, I will update the network card drivers as you suggested.

Thank you and sorry for the long post!
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 26. Apr 2019, 13:58

I need to rectify on something: I have been doing some further tests and it turns out that not everything works perfectly even when I am sending ping packets from the guest to the visitor. There is indeed some package loss and the response is irregular. However, it remains true that the success rate is much higher under those circumstances than otherwise.

Maybe more importantly, I have tried connecting guest and visitor directly, with a physical cable linking the network cards. In this case, I use static IPs for all three machines, whereas I was using DHCP for all of them when both host and visitor were connected to the same LAN. Everything works perfectly in that configuration.

The guest happened to have the same hostname as another machine in the LAN, which I thought could we causing the problem. However, I have changed it and the result is still exactly the same. Any idea about what might be going on?
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby scottgus1 » 26. Apr 2019, 16:25

Unfortunately Linux isn't my shtick, so I wouldn't be aware of what command to make. As far as I am aware, the Guest Additions don't do anything to the guest's networking. But something may have gone wrong.

Using static IPs makes the guest/other-PC communication good, whereas DHCP is faulty? However, "communication between host and guest works perfectly", from your first post. Sounds like that guest OS is wonky.

I would go back to DHCP on the host and other PC. Then try a fresh new Ubuntu guest with no modifications in the guest settings, just let the wizard have its way, and see if the new Ubuntu has issues networking to the host and/or the networked PC.
Human government is like that crazy uncle who hides a quarter in his fist behind his back, then asks you to guess which fist the quarter is in...
No matter which side you choose, Left or Right, both Sides are empty.
scottgus1
 
Posts: 4262
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Win7

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 26. Apr 2019, 21:09

Yes, communication between host and guest has been perfect in all scenarios I have tried. The exact same thing can be said about the communication between host and visitor. It is always the communication between guest and visitor that is troublesome.

I highly doubt that the OS on the guest is wonky. It is a very simple Debian install without even a display server or anything. All I have installed are the guest-utils and the application server I mentioned before, which is very simple software, installed in a user's home folder and not run as a service, but rather executed manually by that user. It has not been running at the time of these tests. I will nonetheless try with another OS and report, but I do not expect that to solve the problem.
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 27. Apr 2019, 02:18

I happened to have another VM with Point Linux 3.2 and MATE, instead of Debian without display server. I have just tested it and the behaviour is exactly the same, so I think the guest OS is not the problem.

By the way, both VMs were created with VirtualBox 5.2 and are now being used with VirtualBox 6.0, but that should never be the issue, right?
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby scottgus1 » 27. Apr 2019, 14:34

Different guest, same network trouble, definitely not a guest OS issue then. Good test!

However, glitchy Virtualbox Bridge activity is not a well-known issue on these forums, the vast majority have no issues. (Unless they are Bridging to a Wi-fi adapter. Wi-fi doesnt technically know how to Bridge, and it is a dice toss whether Bridging will work with Wi-fi.) You're using wired Ethernet, so the wi-fi warning doesn't apply.

There must be something unusual about your host PC that is causing this. You did install the official Virtualbox, but I seem to remember that Ubuntu comes with their fork of VB already installed. You may now have both installed and they may be corrupted or fighting each other. I do remember the advice given when the Ubuntu fork is present is to uninstall it first. Try looking in the Linux Hosts subforum for that command, and/or uninstall both, reboot, then re-install Official VB. Your guests will remain ready to use.
Human government is like that crazy uncle who hides a quarter in his fist behind his back, then asks you to guess which fist the quarter is in...
No matter which side you choose, Left or Right, both Sides are empty.
scottgus1
 
Posts: 4262
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Win7

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 28. Apr 2019, 16:51

Well, actually the host is running LXDE, which is basically a tweaked version of Lubuntu. As far as I know, it does not come with VirtualBox installed by default. At the moment there is only one version installed:
Code: Select all   Expand viewCollapse view
$ apt list *virtualbox* | grep -v guest
Listing...
unity-scope-virtualbox/xenial,xenial 0.1+13.10.20130723-0ubuntu1 all
virtualbox/xenial-updates 5.1.38-dfsg-0ubuntu1.16.04.3 amd64
virtualbox-5.0/unknown 5.0.40-115130~Ubuntu~xenial amd64
virtualbox-5.1/unknown 5.1.38-122592~Ubuntu~xenial amd64
virtualbox-5.2/unknown 5.2.28-130011~Ubuntu~xenial amd64
virtualbox-6.0/unknown,now 6.0.6-130049~Ubuntu~xenial amd64 [installed]
virtualbox-dbg/xenial-updates 5.0.18-dfsg-2ubuntu1 amd64
virtualbox-dkms/xenial-updates,xenial-updates 5.1.38-dfsg-0ubuntu1.16.04.3 all
virtualbox-ext-pack/xenial-updates,xenial-updates 5.1.38-0ubuntu1.16.04.1 all
virtualbox-qt/xenial-updates 5.1.38-dfsg-0ubuntu1.16.04.3 amd64
virtualbox-source/xenial-updates,xenial-updates 5.1.38-dfsg-0ubuntu1.16.04.3 all

The one which is installed is actually from Oracle:
Code: Select all   Expand viewCollapse view
$ apt show virtualbox-6.0
Package: virtualbox-6.0
Version: 6.0.6-130049~Ubuntu~xenial
Priority: optional
Section: contrib/misc
Maintainer: Oracle Corporation <info@virtualbox.org>
Installed-Size: 256 MB
Provides: virtualbox
Pre-Depends: debconf (>= 1.1) | debconf-2.0
Depends: libc6 (>= 2.15), libcurl3 (>= 7.16.2), libdevmapper1.02.1 (>= 2:1.02.97), libfontconfig1 (>= 2.11.94), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.4), libgl1-mesa-glx | libgl1, libglib2.0-0 (>= 2.12.0), libice6 (>= 1:1.0.0), libopus0 (>= 1.1), libpng12-0 (>= 1.2.13-4), libsdl1.2debian (>= 1.2.11), libsm6, libssl1.0.0 (>= 1.0.1), libstdc++6 (>= 5.2), libvpx3 (>= 1.5.0), libx11-6, libx11-xcb1, libxcb1 (>= 1.8), libxcursor1 (>> 1.1.2), libxext6, libxml2 (>= 2.7.4), libxmu6, libxrender1, libxt6, zlib1g (>= 1:1.1.4), psmisc, adduser
Recommends: libasound2, libpulse0, libsdl-ttf2.0-0, kmod | kldutils | module-init-tools, linux-headers-generic | linux-headers-generic-pae | linux-headers-686-pae | linux-headers-amd64 | linux-headers-2.6-686 | linux-headers-2.6-amd64 | linux-headers, linux-image, gcc, make | build-essential | dpkg-dev, binutils, pdf-viewer, libgl1
Conflicts: virtualbox, virtualbox-guest-additions-iso, virtualbox-ose, virtualbox-qt
Replaces: virtualbox
Python-Version: 2.7
Download-Size: 114 MB
APT-Manual-Installed: yes
APT-Sources: https://download.virtualbox.org/virtualbox/debian xenial/contrib amd64 Packages
Description: Oracle VM VirtualBox
 VirtualBox is a powerful PC virtualization solution allowing you to run a
 wide range of PC operating systems on your Linux system. This includes
 Windows, Linux, FreeBSD, DOS, OpenBSD and others. VirtualBox comes with a broad
 feature set and excellent performance, making it the premier virtualization
 software solution on the market.

And the one that comes from the Ubuntu repository (not installed) is indeed a fork:
Code: Select all   Expand viewCollapse view
$ apt show virtualbox
Package: virtualbox
Version: 5.1.38-dfsg-0ubuntu1.16.04.3
Priority: optional
Section: multiverse/misc
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian Virtualbox Team <pkg-virtualbox-devel@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 72,1 MB
Depends: adduser, iproute2, procps, virtualbox-dkms (>= 5.1.38-dfsg-0ubuntu1.16.04.3) | virtualbox-source (>= 5.1.38-dfsg-0ubuntu1.16.04.3) | virtualbox-modules, init-system-helpers (>= 1.18~), python3 (<< 3.6), python3 (>= 3.5~), python3.5, libc6 (>= 2.15), libcurl3-gnutls (>= 7.16.2), libdevmapper1.02.1 (>= 2:1.02.97), libgcc1 (>= 1:3.0), libgsoap8, libpng12-0 (>= 1.2.13-4), libpython3.5 (>= 3.5.0~b1), libsdl1.2debian (>= 1.2.11), libssl1.0.0 (>= 1.0.0), libstdc++6 (>= 5.2), libvncserver1 (>= 0.9.10), libvpx3 (>= 1.5.0), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxml2 (>= 2.7.4), libxmu6, libxt6, zlib1g (>= 1:1.1.4)
Recommends: virtualbox-qt (= 5.1.38-dfsg-0ubuntu1.16.04.3), libgl1-mesa-glx | libgl1, libqt5core5a (>= 5.0.2), libqt5opengl5 (>= 5.0.2) | libqt5opengl5-gles (>= 5.0.2), libqt5widgets5 (>= 5.0.2)
Suggests: vde2, virtualbox-guest-additions-iso
Conflicts: virtualbox-2.0, virtualbox-2.1, virtualbox-2.2, virtualbox-3.0, virtualbox-3.1, virtualbox-3.2, virtualbox-4.0, virtualbox-4.1, virtualbox-4.2, virtualbox-4.3, virtualbox-5.0, virtualbox-5.1
Homepage: http://www.virtualbox.org/
Download-Size: 15,8 MB
APT-Sources: http://es.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages
Description: x86 virtualization solution - base binaries
 VirtualBox is a free x86 virtualization solution allowing a wide range
 of x86 operating systems such as Windows, DOS, BSD or Linux to run on a
 Linux system.
 .
 This package provides the binaries for VirtualBox. Either the virtualbox-dkms
 or the virtualbox-source package is also required in order to compile the
 kernel modules needed for virtualbox. A graphical user interface for
 VirtualBox is provided by the package virtualbox-qt.

All my machines run Linux, but they are connected to a company Windows network. I have just realized that a colleague of mine who uses Windows has a copy of the guest (the one with Debian) because he wanted to use the same application server I was using. I will ask him to set the guest's virtual network adapter to bridged mode on his computer and I will report the result.
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby bbender-v » 28. Apr 2019, 21:22

olavide wrote:All my machines run Linux, but they are connected to a company Windows network.

Kind of a long-shot here... Not that it's a _Windows_ network, but possibly that it's a managed network. Are you plugged directly into a wall-jack, straight to the company's switch? (if not, ignore the following <g>) Sometimes they are set up to only allow one MAC per port, so the last seen outgoing packet could "own" the port until a different one (host vs. guest) sent out a packet. Your host and guest could be trading the port back & forth, with the other temporarily being blackholed.

A way to test this would be to plug your host into a local unmanaged/consumer switch (which is connected up to the company network itself) and something else (as your "visitor") also into the local switch, and see if this visitor can reliably talk to both your host and guest. If you aren't allowed to plug a switch into the corp. network, use a broadband router and plug host and visitor both into its LAN ports...

If that all works reliably, you'll need to ask your IT folks about the switch config, and whether they need to configure your switch port to allow multiple MACs. If they won't, you're pretty much stuck using NAT with port-forwarding.
bbender-v
 
Posts: 10
Joined: 19. Apr 2013, 04:12

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 29. Apr 2019, 09:59

Yes, the network seems to be the issue, because I have tried running the guest on my colleague's computer (the Windows host) and the result is exactly the same.

About the exact explanation, the one thing that does not seem to fit is the following: when the host is not making use of the application server running on the guest, the host should not be using that particular port at all. Yet, the visitor, who is the only one attempting to use that port, cannot (most of the time) connect to the guest.

I'll probably leave it at that because I can afford to connect the host and visitor directly, which works fine, but if I end up testing any further and/or solving the issue I will surely report.

Thank you everyone for your kind support!
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby olavide » 29. Apr 2019, 12:35

Well, that was pretty much it. It turns out that the MAC I was using for the guest was already present in the network. As soon as I changed the MAC, everything started working perfectly. Thank you very much.

In fact, if I keep the same (duplicated) MAC, this is what happens:

- The host and guest communicate perfectly (as I had written before).
- The host and visitor communicate perfectly (as I had written before).
- The visitor and guest communicate poorly (as I had written before).
- The host and the other computer with the same MAC as the guest communicate poorly (I did not know this).

Out of curiosity, I wonder why the host prioritizes the guest and the visitor prioritizes the other computer. Might there be a way to have both working? In any case, my problem is already solved and therefore I have added a "[SOLVED]" tag before the thread title. Thank you!
olavide
 
Posts: 9
Joined: 24. Apr 2019, 19:39

Re: Networking: irregular behaviour with bridged adapter (Bridged-over-Ethernet)

Postby bbender-v » 30. Apr 2019, 02:14

olavide wrote:About the exact explanation, the one thing that does not seem to fit is the following: when the host is not making use of the application server running on the guest, the host should not be using that particular port at all. Yet, the visitor, who is the only one attempting to use that port, cannot (most of the time) connect to the guest.

For the record, I didn't mean TCP port -- I was referring to the actual port in the corporate switch that your host was plugged into. But the duplicate MAC certainly explains the weirdness, too -- your guest and whatever other machine was using the same MAC were having an ARP fight. Trying to make sense of why the behavior was slightly different between different hosts isn't really useful, as it's a completely invalid situation to have a duplicate MAC on the same ethernet segment / broadcast domain (outside of a couple special circumstances, anyway). You fixed it, nothing more to wonder about. :)
bbender-v
 
Posts: 10
Joined: 19. Apr 2013, 04:12


Return to Using VirtualBox

Who is online

Users browsing this forum: No registered users and 6 guests