Enable Network Communications/Traffic Forwarding for Virtual Machines

There are various possible reasons why communication may not work with other systems. This guide now reviews some of the most likely problems, and how they can be handled.

Cannot communicate with farther NICs
Example Scenario

If using a TUN/TAP device, then the layout of network communications may look something like this:

virtual machine
192.0.2.2
< - > internal NIC
192.0.2.1
< - > external NIC
198.51.100.2
< - > Modem-or-ISP
198.51.100.1
Identifying the pieces

In this diagram, the term “virtual machine” refers to a NIC which is part of the virtual machine. If you log into the virtual machine, and look at the list of NICs, then this NIC would show up.

In this diagram, the “internal NIC” may be some software running on the “physical” machine, such as a “TUN/TAP” device that communicates with the virtual machine. This NIC might have a name like tun144 or tap2, depending on things like what operating system is being used.

The “external NIC” may be another network interface that is part of the “physical” machine that is running the “virtual machine” software.

The “Modem-or-ISP” is typically a different piece of hardware, such as a “DSL modem” or a “cable modem”. So it is not typically part of the same physical device as the computer that runs the “virtual machine” software.

Now, in this layout, the following scenario may frequently be encountered.

Findings described Verifying Test
  • the virtual machine may be able to communicate with the IP address on the “internal NIC” on the physical machine,
  On the virtual machine:
ping 192.0.2.1
works.
  • but may be unable to communicate with the IP address on the “external NIC”,
  However, if the virtual machine tries
ping 198.51.100.2
then that fails.
    • nor (can the virtual machine communicate with) any network that involves going through the external NIC.
  And, given that finding, it is less surprising that
ping 198.51.100.2
also fails from the virtual machine.
  • However, the physical machine can seemingly communicate with the internal NIC and the modem/ISP.
 

However, the physical machine can reach all of these addresses, without problem.

virtual machine
192.0.2.2
< - > internal NIC
192.0.2.1
< - > external NIC
198.51.100.2
< - > Modem-or-ISP
198.51.100.1

These findings can often be verified by performing various ping tests.

So, the question being looked at is: why won't the virtual machine communicate with the external NIC?

Solution

Enable forwarding.

OpenBSD guide
Back up data

First, on the machine that isn't forwarding the traffic (which is the “physical” machine that is running the “virtual machine” sofwtare), let's create a snapshot/backup of the /etc/sysctl.conf file.

Note: This should be done on the machine that needs to route traffic between the interfaces. (With the sample diagram that was just shown, this means that the steps need to be done on the “physical” machine, not the “virtual machine”. It is the system that has the “internal NIC”, which may be a TUN/TAP interface.)

export FILETOBK=/etc/sysctl.conf

Then, follow these instructions to create a snapshot/backup of the file.

Then, the remaining steps are currently part of another set of documented instructions. (You can skip the part of those instructions that back up a file, becausae the prior instructions just backed up the /etc/sysctl.conf file.)

  • Follow the Implementations (how to forward traffic). (Note that those instructions are not part of this tutorial, so remember to return to this tutorial after implementing the action of forwarding traffic.)

This should resolve that problem. (The virtual machine might not be able to have bidirectional conversations with the modem/ISP, but it can now reach the external device.)

If problems remain after completing this guide, also check out: enable net traffic handling, which refers to this possible solution as well as some other problems and solutions.