Member Avatar for JySysAdmin

I have created a Virtual Machine of CentOS in virt-manager and cannot ssh to it. I get no route to host, even though:

  • The VM is in bridged mode
  • SSHD is started
  • The firewall on the Virtual Machine allows traffic on port 22

Does virt-manager have another firewall for virtual machines, is there a bug, or am I doing something wrong?

  • 4 Contributors
  • 16 Replies
  • 2K Views
  • 2 Weeks Discussion Span
  • Latest Post Latest Post by JamiePetreno

Dani AI

Generated

Based on the outputs posted, you are not on a classic Linux bridge at all. The host shows a macvtap interface (macvtap0). In virt-manager that means the NIC was set to a direct (macvtap) attachment, not to a host bridge like br0. With macvtap, guests can talk to the LAN, but the host and guest cannot talk to each other by design. That exactly matches your test where another physical box could SSH/HTTP in, but the host could not. It is not an sshd or firewall issue. Red Hat explains this behavior and the recommended workarounds and the libvirt wiki has the same guidance. (docs.redhat.com)

Fix options:

  • Switch to a real bridge. Create br0 on the host, put eth0 into it, then attach the VM to br0 in virt-manager (NIC source: Bridge br0). On CentOS/RHEL 6 the minimal ifcfg files look like:
# /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BRIDGE=br0

Restart networking and reconnect the VM to br0. This restores host<->guest reachability. RHEL docs cover bridged setup on EL6/7. (linuxtopia.org)

  • Keep macvtap but add a second NIC on an isolated/libvirt network (for example, the default NAT network). Use that IP for host<->guest admin, and keep the macvtap NIC for LAN access. This is the documented workaround when you must stay on macvtap. (docs.redhat.com)

One more note: your earlier test with macvtap “passthrough” explains the identical MAC you observed; passthrough can temporarily program the host NIC with the VM’s MAC, which can confuse DHCP and neighbors. Use it only with a dedicated NIC. (spinics.net)

Nice instincts ; this was a network type issue, not sshd.

Recommended Answers

All 16 Replies

Member Avatar for CimmerianX

Does the VM have an IP on the Host OS's physical LAN subnet?

Member Avatar for JySysAdmin

It did before, now I can't get it to start, I messed up networking settings trying to diagnose this :(

Member Avatar for CimmerianX

Without an IP on the bridged interface, how would this work? It won't.

Member Avatar for JySysAdmin

Before it broke it had an IP on the bridged network, but still coudln't connect

Member Avatar for CimmerianX

Well, before you can troubleshoot the connectivity, you need to fix the networking and get an IP assigned to that virtual host.

Member Avatar for JySysAdmin

I have the machine booted again with an IP in the same range as the host. Still cannot connect.

As an additional test I started HTTPD and cannot connect to it from by browser on the host machine, workd perfectly on the VM to localhost.

Member Avatar for CimmerianX

Alright then. Lets start with the host OS.

Is there a firewall enabled on either host? If yes, disable for a test.
Can host OS ping the guest OS using that bridged IP?
Can we see ipconfig /all or ifconfig for each host...
Can we also get a route list for the host os.

Member Avatar for JySysAdmin

With both firewalls off the two machines cannot ping each other :(

Host
eth0      Link encap:Ethernet  HWaddr 84:2B:2B:86:CB:2F  
          inet addr:192.168.1.119  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::862b:2bff:fe86:cb2f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:262682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:339884162 (324.1 MiB)  TX bytes:16849489 (16.0 MiB)
          Interrupt:18 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:73946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73946 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:29884873 (28.5 MiB)  TX bytes:29884873 (28.5 MiB)

macvtap0  Link encap:Ethernet  HWaddr 52:54:00:FA:74:0E  
          inet6 addr: fe80::5054:ff:fefa:740e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:167406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47051 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:247031486 (235.5 MiB)  TX bytes:3322229 (3.1 MiB)

virbr0    Link encap:Ethernet  HWaddr 52:54:00:A7:AE:B6  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Guest
eth0      Link encap:Ethernet  HWaddr 52:54:00:FA:74:0E  
          inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fefa:740e/64 Scope:Link               
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1              
          RX packets:83720 errors:0 dropped:0 overruns:0 frame:0          
          TX packets:47044 errors:0 dropped:0 overruns:0 carrier:0        
          collisions:0 txqueuelen:1000                                    
          RX bytes:123519699 (117.7 MiB)  TX bytes:3321719 (3.1 MiB)      

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host     
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:103 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:26852 (26.2 KiB)  TX bytes:26852 (26.2 KiB)

virbr0    Link encap:Ethernet  HWaddr 52:54:00:11:FC:B8
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
Edited by JySysAdmin
Member Avatar for CimmerianX

Can each machine ping itself at their own addresses (192.168.1.119 and .110)?

Can each machine ping the gateway at 192.168.1.1?

Can you show the arp table from each host after the ping attempt?

On the guest, run a tcpdump -v and then ping it from the host. The tcpdump should show the inbound packets at least. I'd like to see that as well.

Member Avatar for JySysAdmin

Yes they can ping themselves and the GW. If I even enter the IP of the gateway into a browser, the web interface comes up.

I PMed you the tcpdump.

## Before Ping (Host)
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1              ether   00:18:39:c5:83:c1   C                     eth0

## After Ping (Host)
Address                  HWtype  HWaddress           Flags Mask            Iface
virtvm                           (incomplete)                              eth0
192.168.1.1              ether   00:18:39:c5:83:c1   C                     eth0

## VM before and after ping
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1              ether   00:18:39:c5:83:c1   C                     eth0

It seems the host and guest have the same Mac Address. Dunno if that's how it's supposed to be setup, when I do bridged networking in VirtualBox the VM has a different Mac Address.

Edited by JySysAdmin
Member Avatar for CimmerianX

It seems the host and guest have the same Mac Address

Ya that's going to be a problem... Normal flow for this is to ARP for the MAC belonging to an IP address via broadcast. Owner of the IP will respond back and the local ARP table will be updated. If 2 IPs share a mac, I'm not sure how the traffic will react to that.

However in this case, I only see the following:
16:43:31.834932 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.110 tell 192.168.1.1, length 46
16:43:31.834970 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.110 is-at 52:54:00:fa:74:0e (oui Unknown), length 28

I never see an ARP request for 192.168.1.119 for the HOST OS IP. Was this tcpdump taken from the guest? If yes, can we get the same thing done from the host OS.

Can you have each host ping the other host while TCPDUMP is running on each. Then print the arp tables from each.

Bottom line, if both hosts share a MAC, then you need to correct that somehow.

Member Avatar for JySysAdmin

I think the Mac Issue was because of "Passthrough" mode (I was trying different options to see if I could get better results). The host IP used to be 192.168.1.136 (not 192.168.1.119) before I started fiddling around with the bridged networking here. I don't know if somehow the Mac Addresses changed causing the DHCP to assign a different IP...

Also funny thing, I was able to SSH and connect to the webserver from the browser of a separate physical machine.

Member Avatar for CimmerianX

MAC addresses do not change on on physical hardware. Nor should they change on the fly with DHCP.

Member Avatar for rubberman

Even with a valid local network address, you need to edit the /etc/ssh/sshd_config file on the server end and set the needed options for ssh connectivity from external machines. Also, make sure that the sshd service is started: sudo service sshd status

Member Avatar for JySysAdmin

Indded the number hard coded to the hardware can't change, but the address the card is using could be different, causing DHCP to think it's a different adatper and therefore assign a different IP.

And the SSH server is working fine, I can SSH to localhost and from another physical box, just not from the host.

Member Avatar for JamiePetreno

Before you can repair the connection, you need to fix the social media and get an IP allocated to that exclusive variety . . . . . . .

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.