I have CentOS 7 host. Two guests on bridge network setup by GUI and virt-manager. 1 CentOS 8 guest 1 Win 10 guest Both cannot access the host. They can other machines on the network. Guests can access the internet just not the host.
I used virt-manager GUi to set up everything. Selected the eth0:macvtap and Bridge. I "desire" bridge network.
If I select something else I get access to host - but of course machine is not on the main network.
Thoughts ?
Jerry
Am 01.04.2020 um 14:53 schrieb Jerry Geis:
I have CentOS 7 host. Two guests on bridge network setup by GUI and virt-manager. 1 CentOS 8 guest 1 Win 10 guest Both cannot access the host. They can other machines on the network. Guests can access the internet just not the host.
I used virt-manager GUi to set up everything. Selected the eth0:macvtap and Bridge. I "desire" bridge network.
If I select something else I get access to host - but of course machine is not on the main network.
Thoughts ?
Jerry
WORKSFORME
What have you checked so far?
On the host:
# brctl show virbr1 bridge name bridge id STP enabled interfaces virbr1 8000.525400698fd5 yes virbr1-nic vnet0 vnet1 vnet2 vnet3 vnet4 vnet5
# ip a s virbr1 3: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:54:0069:8f:d5 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global virbr1 valid_lft forever preferred_lft forever
# cat /proc/sys/net/ipv4/ip_forward 1
# iptables -L FORWARD -v -n | egrep '(policy|virbr1)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 20337 14M ACCEPT all -- eno1 virbr1 0.0.0.0/0 192.168.10.0/24 ctstate RELATED,ESTABLISHED 29512 3243K ACCEPT all -- virbr1 eno1 192.168.10.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr1 virbr1 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr1 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Alexander
Thanks for the info.
brctl show virbr0 bridge name bridge id STP enabled interfaces virbr0 8000.525400fc34af yes virbr0-nic
brctl show virbr1 bridge name bridge id STP enabled interfaces virbr1 8000.5254009c3902 yes virbr1-nic
ip a s virbr0 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:fc:34:af 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
ip a s virbr1 5: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:9c:39:02 brd ff:ff:ff:ff:ff:ff inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1 valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv4/ip_forward 1
iptables -L FORWARD -v -n | egrep '(policy|virbr1)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
iptables -L FORWARD -v -n | egrep '(policy|virbr0)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
So looks like my IPTables is not correct.
What commands do you run for that ? Thanks,
Jerry
Am 01.04.2020 um 21:56 schrieb Jerry Geis:
Thanks for the info.
brctl show virbr0 bridge name bridge id STP enabled interfaces virbr0 8000.525400fc34af yes virbr0-nic
brctl show virbr1 bridge name bridge id STP enabled interfaces virbr1 8000.5254009c3902 yes virbr1-nic
Why is no VM started?
ip a s virbr0 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:fc:34:af 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
ip a s virbr1 5: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:9c:39:02 brd ff:ff:ff:ff:ff:ff inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1 valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv4/ip_forward 1
iptables -L FORWARD -v -n | egrep '(policy|virbr1)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
iptables -L FORWARD -v -n | egrep '(policy|virbr0)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Is that different when the VMs are up?
So looks like my IPTables is not correct.
What commands do you run for that ?
Simply firewalld. Docker acts by itself.
Thanks,
Jerry
Alexander
Am 01.04.2020 um 22:07 schrieb Alexander Dalloz:
So looks like my IPTables is not correct.
What commands do you run for that ?
Simply firewalld. Docker acts by itself.
Sorry, have to correct myself. Had to much to do today on OpenShift. There is no Docker involved in what we discuss. The firewall rules for the host bridge devices get created by libvirtd.
Alexander
Sorry, have to correct myself. Had to much to do today on OpenShift. There is no Docker involved in what we discuss. The firewall rules for the host bridge devices get created by libvirtd.
Thanks I was using iptables and not converted to firewalld. I am doing so now. Will I need to delete the VM and re-add it ? I am rebooting first.
Jerry
OK I rebooted. I changed the NIC from Bridge to Passthrough, hit apply, then changed it to bridge and hit apply, then booted the VM.
My firewall looks better but still not working. iptables -L FORWARD -v -n | egrep '(policy|virbr1)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 0 0 ACCEPT all -- eth0 virbr1 0.0.0.0/0 192.168.100.0/24 ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr1 eth0 192.168.100.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr1 virbr1 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr1 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
iptables -L FORWARD -v -n | egrep '(policy|virbr0)' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Now what? Thanks.
Jerry
This is unfortunate. https://wiki.libvirt.org/page/TroubleshootMacvtapHostFail
To the "normal" user - BRIDGE means guest is on the same network and has access to the host.
Bummer.
Jerry
Wow, thanks for sharing, I'd have never dreamed it.
________________________________ From: CentOS centos-bounces@centos.org on behalf of Jerry Geis jerry.geis@gmail.com Sent: Thursday, April 2, 2020 9:10 AM To: CentOS mailing list centos@centos.org Subject: [EXTERNAL] Re: [CentOS] CentOS 7 host with guests as bridge cannot access host
This is unfortunate. https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwiki.libvirt.org%2fpage%...
To the "normal" user - BRIDGE means guest is on the same network and has access to the host.
Bummer.
Jerry _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Harriscomputer
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
Am 02.04.2020 um 16:10 schrieb Jerry Geis:
This is unfortunate. https://wiki.libvirt.org/page/TroubleshootMacvtapHostFail
To the "normal" user - BRIDGE means guest is on the same network and has access to the host.
Bummer.
Jerry
You were not telling us that you were using Macvtap.
Alexander
-
Alexander Dalloz -
Jerry Geis -
Leroy Tennison