Unable to ping internal interface on KVM

General support questions
Post Reply
ASTONE
Posts: 14
Joined: 2020/05/25 04:08:41

Unable to ping internal interface on KVM

Post by ASTONE » 2020/07/07 19:31:45

Setup:

Host: Linux Centos 7.8 Server with QEMU-KVM / VNC Server / Gnome
Guest: Windows 10 VM

What works:

1. CentOS 7 Server is up and I can ping from my workstation to the the public interface of the CentOS Server
2. Windows 10 VM is up and I can connect from my workstation to the it, but only via the console from within an RDP session to Host
3. I can ping FROM the CentOS 7 Server to the Internal Interface (Gateway of the internal LAN / virbr0)
4. I can ping FROM the CentOS 7 Server to the Windows 10 Machine

What doesn't work:

1. I cannot ping from my workstation to the the Internal Virtual Interface of the CentOS 7 Server (name: virbr0)
2. I cannot ping from the my workstation to the Windows 10 machine

I believe I'm close to a solution but would welcome any suggestions to push the ball over the goal line.

ip address of workstation run PuTTy = "A.B.C.D"

[root@localhost /]# sudo firewall-cmd --zone=public --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eno1
sources:
services: dhcpv6-client ssh vnc-server
ports: 5902/tcp 5905/tcp 5904-5905/tcp 3389/tcp 5901/tcp 5901-5902/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

[root@localhost zones]# cat public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="dhcpv6-client"/>
<service name="vnc-server"/>
<service name="ssh"/>
<port protocol="tcp" port="5902"/>
<port protocol="tcp" port="5905"/>
<port protocol="tcp" port="5904-5905"/>
<port protocol="tcp" port="3389"/>
<port protocol="tcp" port="5901"/>
<port protocol="tcp" port="5901-5902"/>
<masquerade/>
</zone>

[root@localhost /]# sudo firewall-cmd --zone=trusted --list-all
trusted (active)
target: ACCEPT
icmp-block-inversion: no
interfaces: virbr0
sources:
services: rdp
ports: 3389/tcp
protocols: rdp
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

[root@localhost zones]# cat trusted.xml
<?xml version="1.0" encoding="utf-8"?>
<zone target="ACCEPT">
<short>Trusted</short>
<description>All network connections are accepted.</description>
<interface name="virbr0"/>
<service name="rdp"/>
<port protocol="tcp" port="3389"/>
<protocol value="rdp"/>
</zone>

[root@localhost /]# cat /etc/firewalld/direct.xml
<?xml version="1.0" encoding="utf-8"?>
<direct>
<rule priority="0" table="filter" ipv="ipv4" chain="INPUT"> -p icmp -m icmp --icmp-type 8 -s A.B.C.D -j ACCEPT</rule>
</direct>
[root@localhost /]#
Last edited by ASTONE on 2020/07/07 19:49:15, edited 2 times in total.

User avatar
TrevorH
Site Admin
Posts: 33219
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Unable to ping internal interface on KVM

Post by TrevorH » 2020/07/07 19:37:54

If you run firewalld then it already enables icmp echo out of the box. Are you sure you have your KVM network type set correctly?
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

ASTONE
Posts: 14
Joined: 2020/05/25 04:08:41

Re: Unable to ping internal interface on KVM

Post by ASTONE » 2020/07/08 02:31:17

Thank you for your response.

I'm pretty sure I've got it configured correctly in every way except for this one process. As you can see above, everything else works. I can get to the public interface. I can get to the VMM and VM through an RDP connection to the public interface of the KVM server. I just can't pass traffic from that public zone to the trusted zone and then out to the hosted vm.

In any case, here is a screen shot of my virtual network configuration:



astone
Attachments
KVM Network Configuration.JPG
KVM Network Configuration.JPG (44.07 KiB) Viewed 1615 times

User avatar
jlehtone
Posts: 4530
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Unable to ping internal interface on KVM

Post by jlehtone » 2020/07/08 07:42:43

ASTONE wrote:
2020/07/07 19:31:45
What doesn't work:

1. I cannot ping from my workstation to the the Internal Virtual Interface of the CentOS 7 Server (name: virbr0)
2. I cannot ping from the my workstation to the Windows 10 machine
ASTONE wrote:
2020/07/08 02:31:17
In any case, here is a screen shot of my virtual network configuration:
The default configuration created by libvirt: network "default". Routed with NAT.

Lets look at analogous case:
* You have your home router
- It has public IP address on its WAN interface and private IP address on LAN interface
- It does NAT all outgoing traffic
* When your workstation contacts forums.centos.org, centos.org sees only the public IP of your router
* centos.org cannot ping any of your LAN addresses, neither your workstation's nor your router's, for it does
not know that they are behind the public IP address of the router
* Even if centos.org would know that, the firewall in your router blocks new, incoming connections
* ... unless you configure port forwarding in your router

Your KVM host server is a router.
Your workstation and public interface of the server are on the "WAN" network.
Your server and the guest VM are on the 192.168.123.0/24 "LAN".

Does your workstation know that the public interface of the server is the gateway to 192.168.123.0/24?
I bet not.
Besides, the gateway does NAT, so the existence of 192.168.123.0/24 should not be known anyway.

Run on server:

Code: Select all

iptables -S
iptables -t nat -S
Those will probably reveal that libvirtd has injected rules concerning traffic from and to 192.168.123.0/24 that are before rules set by firewalld. Before zones. Before direct rules. Maybe not now, but most likely after server reboot they will be.


If you could have the VM on the "public network", then you would not need port forwarding at all.
Bridged.

Post Reply