The Qemu VM can be connected to LAN mainly in two ways: type=user or type=tap. The user mode completely isolate the VM in private network, which is sNATed to host main network stack. The use of tap is more complicated, it needs a virtual bridge to become a master of a physical interface (eth0) and virtual interface (tap0). The tap0 is like a pipe for data flowing from outside the world and host to the VM. I spent lot of hours while trying to regulate the network traffic on the tap0 interface with host side iptables/nftables to redirect for example all http requests to some internal ip address, but no success. All advice, forums, and wiki recommends plenty of solutions, which cannot work, because of the main reason: The packets from the VM guest never come to host kernel network stack. They choose their way on the bridge level and do not meet any firewall rule tuned up by any chains of packet filter, if the IP host address is not their target. You can try it simply by setting the host global policy to DROP (with host XYtables), and you can see: the host networking is completely dead, but the guest can continue to send and receive packets over the net.

Well, the question: Is there some other way, how to virtually connect the VM guest to a host virtual network interface? For better understanding the graphs follow:

     General virtual connections for host/VM guest
    |    +-----------------------------+          |
    |    |    iptables    host kernel  |          |
    |    |    nftables   network stack |          |
    |    +-------+---------------------+          |
    |            |                                |
    |    +-------+---------+      +-----------+   |
---eth0--+    virtual      |      |    VM     |   |
    |    |    bridge       +-tap-eth0 guest   |   |
---eth1--+      br0        |      |           |   |
    |    +-----------------+      +-----------+   |

       Host became a router for VM guest
    |    +----------------+  +---------+  |
---eth0-->  host kernel   |  |    VM   |  |
    |    |                <-vppp guest |  |
---eth1-->  network stack |  |         |  |
    |    +----------------+  +---------+  |

To solve my problem there must be find either a way how to control (with nftables e.g.) the traffic of the virtual bridge itself, either how to connect the VM guest network interface though a virtual wire to a virtual network interface of the host. Something like a PPPoE networking.

But the ultimate and the most clear way is to add some more parameters to the Qemu user mode networking to be able to force redirect some port(services) to chosen target address, the host loop-back included. Yes I sent such wishes to the Qemu team, and got an answer: it is not the top most necessary feature.


1 Answer 1


There are two possible solutions:

  • Use nftables bridge family and do filtering below layer 3.
  • Use the host as a router.

The first solution is the more efficient option, but limits you to filtering on properties of the Ethernet frames. You can’t filter on IP addresses or ports, or anything else at layer 3 or higher, because the bridge does not process any of that data.

The second solution is more likely to allow you to do what you want here. This is actually very simple for two specific reasons:

  • You can assign an IP address on a bridge interface directly, just like with any other network device type.
  • You don’t need to have any physical network devices connected to a bridge interface.

Give this, the ‘normal’ setup for what you want to do is:

  1. Set up a bridge interface on the host system. Assign a static IP to it, but do not connect it to any physical interfaces.
  2. Configure nftables so that the system handles routing between the bridge interface from step 1 and any external interfaces.
  3. When starting a VM, attach it to the bridge interface from step 1.

Then, you just filter things in nftables no differently from if the system were acting as a perimeter firewall. You can make this even easier by setting up a DHCP server and caching DNS resolver on the host system so that you don’t need to give the VM static networking configuration.

  • Quite correct, that was the key information: the bridge (iproute2 vbr0 type bridge) is virtual interface to bridge (virtual ethernet HUB) subsystem. The vbr0 has implicit connection to kernel, even if the kernel does not use it. There is plenty of picture describing the packet flow through ip/nf chains, but I did not find any for the bridge/tun/tap virtual interfaces.
    – schweik
    Commented Feb 18, 2023 at 10:52

You must log in to answer this question.

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