Bridge VLAN to Wifi

I’m trying to make my Windows VM, hosted on Fedora 34, accessible to my LAN, which is wifi only (my router doesn’t even have an Ethernet jack on it). Network Manager doesn’t seem to support this. How shall I proceed?

Hi,

Which virtualization software are using, boxes, vmware or virtualbox?

Thanks Tom.

Plain old ordinary libvirt Virtual Machine Manager. I suppose I could try Boxes, or shell out the money for VMware; though my previous experiences with Virtual Box are not all that positive.

I think it is possible to allow the lan to access the VM on another host.

What I have done is:

  1. Set up the VM with bridging.
  2. Set up the gateway router so that it has a fixed route that directs lan traffic destined for that VM to the vm host.
  3. Make sure the firewall on the vm host allows incoming traffic directed to the VM.

Everything then works for LAN access to my VM (also using libvirt).

Hi,

KVM doesn’t support bridging with wireless. I’ve found and tested this work around:

Had to set a static ip for this to work:

IP:192.168.1.180
Mask: 255.255.255.224
GW: 192.168.1.161

So for additional devices, you will need to set a static ip on the guest and update the arp command at the end of the article (You will need to change wlan0, to the correct interface).

Limited to 30 Guests.

Thanks Tom.

1 Like

Using virt-manager, I believe you can create a network in routed mode. The default setup is typically NAT which will allow you to send and receive packets through the hypervisors network, but can’t be reached from other machines on the LAN.

A routed mode network will allow access from other machines on the LAN provided you set up the correct routes on your router or gateway devices so that the reply packets can reach the hypervisor.

Cheers

Right, libvirt IME does not allow direct bridging via wifi but does by using the default virbr0 interface to the host. The host then forwards traffic both ways via its wifi interface to the LAN. The host performs the NAT for outbound traffic originating from the VM, but also allows direct access to the virbr0 interface inbound. Mine uses an IP in the 192.168.122.0/24 subnet for all the VMs I am hosting.

On the VM side I see

enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:55:38:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.60/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0
       valid_lft 3202sec preferred_lft 3202sec
    inet6 fe80::5f4d:982c:26b6:e9f/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

and on the host side I see

  virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:d1:c6:2a brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

With the gateway router set to forward all traffic for the VMs IP, in this case the 192.168.122.60 address, to the host then all the devices on the LAN can access the host. The VM is set in direct bridging mode using virbr0. The host uses wifi to the LAN.

I do not try this out myself.

One possibility is:

Create a Bonding Interface, with the only Wifi connection as slave. Then create a Bridge interface to the Bonding Interface for the VM guests.

Hi,

Sounds like both methods will work. Could you please clarify what you mean by the gateway router? Is that that Lan router or the 192.168.122.1 router?

If that’s the lan router, I’m guessing being as only offers wifi; setting up forwards may not be in the gui. Just a guess but ISP routers can quite often be locked down.

Thanks Tom.

The gateway router is your gateway to the internet, quite often the LAN router. In recent times (at least the past 10 years) I have not seen the ISP router locked down, although it certainly has been in the past, depending upon who your ISP was.

If the gateway router is locked down, you can achieve the same thing with a little more effort by adding a route on each machine needing access to the VM to direct the traffic for the VM to its host.

Hi,

Okay so static routes rather than a forward then. Sorry got to say, I prefer my suggestion as it only requires configuration on the host PC for the guests.

Thanks Tom.

A configuration on the host pc will not help other machines on the lan to access the vm on that host. The other machines need to be able to have their packets directed to the host and on to the vm, but that can only be done with port forwarding or routing.

Since the 192.168.122.0/24 subnet is a private address the gateway router cannot forward it unless you give it a static route for that subnet. Any other machine that also uses the default (for fedora) virbr0 bridge address will already have an internal route to that subnet and cannot connect to the VM host remotely using that subnet (or any other private subnet) without a static route.

The host machine will have no problems, but others on the LAN will.

Hi,

I tested my suggestion and other hosts on my lan could access the guest, I wouldn’t have suggested it as a fix otherwise. Its done through the arp publication, which is advertised to other devices on the lan, when requested:

arp -i wlan0 -Ds 192.168.1.180 wlan0 pub

The host has never had a problem accessing the guest, the route is setup when the virtual network is added with gnome boxes or virt-machine.

Thanks Tom.

Hello Jeff, one question here.

I think forward rules is another thing right?
I can’t find “routing table” anywhere.
I tried 192.168.124.78 here in forward rules but it does not accept that IP since it is not the same 192.168.1.0

My configuration is really quite simple

Host 2 ( IP 192.168.4.110) sends an ssh connect request to the VM at 192.168.124.132.
The router has a routing entry that redirects all traffic for 192.168.124.132 to host 1 at IP 192.168.4.120
Host 1 receives the connection request and since 192.168.124.132 is local to host 1 via virbr0 it is automatically passed to the VM for connection.

You can see all the interfaces and local addresses on host 1 using ip address show and the same for the addresses on the VM.
The only routing needed is to add the one entry to the gateway router to direct all traffic for the VM directly to host 1 network IP. It an also be added to the routing table on host 2 if you only have a couple of hosts to set up that way.

Since your image appears to be from the router I think the location you need is either under LAN or WLAN for the routing. I do not have that router so cannot speak to where the routing tables may be hidden in that menu.

This appears to be very simple from what I have read.
But I don’t know exactly on my router if I have this option to edit the tables.



Hello Jeff, how are you?

Can you provide me an screenshot of your router config that I can see your router entry?

Thank you.

Instead of using a linux bridge use openvswitch.

dnf install NetworkManager-ovs
systemctl enable --now openvswitch.service

nmcli connection down enp0s31f6
nmcli connection del enp0s31f6
nmcli connection add type ovs-bridge con-name bl0 conn.interface bl0
nmcli connection add type ovs-port con-name sw0 conn.interface sw0 master bl0
nmcli connection add type ethernet con-name enp0s31f6 conn.interface enp0s31f6 master sw0
nmcli connection add type ovs-port con-name sw1 conn.interface sw1 master bl0
nmcli connection add type ovs-interface con-name ho0 conn.interface ho0 master sw1 ipv4.method auto

ovs-vsctl show
nmcli device
nmcli connection




#NetworkManager.conf
#[main]
#no-auto-default=*

mac=$(nmcli --get-values GENERAL.HWADDR d show enp0s31f6)
nmcli c down enp0s31f6
nmcli c del enp0s31f6
nmcli c add type ovs-bridge    con-name sw0   conn.interface sw0
nmcli c add type ovs-port      con-name sw0p0 conn.interface sw0p0 master sw0
nmcli c add type ethernet      con-name up0   conn.interface enp0s31f6 master sw0p0 connection.autoconnect no
nmcli c add type ovs-port      con-name sw0p1 conn.interface sw0p1 master sw0
nmcli c add type ovs-interface con-name ho0   conn.interface ho0 master sw0p1 802-3-ethernet.cloned-mac-address $mac ipv4.method auto ipv4.dhcp-timeout 2147483647 ipv6.method auto ipv6.dhcp-timeout 2147483647
nmcli c add type ovs-port      con-name sw0p2 conn.interface sw0p2 master sw0
nmcli c add type tun           con-name vm0   conn.interface tap0 mode tap owner $(id -u <username>) master sw0p2