On 03/20/2016 08:51 PM, Devin Reade wrote: > In a CentOS 7 test HA cluster I'm building I want both traditional > services running on the cluster and VMs running on both nodes On a purely subjective note: I think that's a bad design. One of the primary benefits of virtualization and other containers is isolating the applications you run from the base OS. Putting services other than virtualization into the system that runs virtualization just makes upgrade more difficult later. > A given VM will be assigned a single network interface, either in > the DMZ, on vlan2, or on vlan3. Default routes for each of those > networks are essentially different gateways. What do you mean by "essentially"? > On the DMZ side, the physical interface is eno1 on which is layered > bridge br0. ... > On the other network side, the physical interface is enp1s0, on > which is layered bridge br2, on which is layered VLAN devices > enp1s0.2 and enp1s0.3. That doesn't make any sense at all. In what way are enp1s0.2 and enp1s0.3 layered on top of the bridge device? Look at the output of "brctl show". Are those two devices slaves of br2, like enp1s0 is? If so, you're bridging the network segments. You should have individual bridges for enp1s0, enp1s0.2 and enp1s0.3. If there were any IP addresses needed by the KVM hosts, those would be on the bridge devices, just like on br0. > VMs that are supposed to be on vlan2 and vlan3 are assigned > either enp1s0.2 or enp1s0.3, respectively, as their underlying network > device. How? Are you using macvtap for those? I'd suggest sticking with one of either bridged networking or macvtap. > The 'dmz' zone contains br0, br2, eno1, enp1s0, enp1s0.2, and enp1s0.3. > It looks like default that firewall rules aren't applied to bridge > devices so we can ignore those. Correct: /usr/lib/sysctl.d/00-system.conf:# Disable netfilter on bridges. /usr/lib/sysctl.d/00-system.conf:net.bridge.bridge-nf-call-ip6tables = 0 /usr/lib/sysctl.d/00-system.conf:net.bridge.bridge-nf-call-iptables = 0 /usr/lib/sysctl.d/00-system.conf:net.bridge.bridge-nf-call-arptables = 0 > enp1s0 is an expected interface for > that zone. Where it gets muddy is enp1s0, enp1s0.2 and enp1s0.3. Since > the host shouldn't have any IPs on those interfaces, what is the > relevence of having them in the DMZ zone or another zone? Interfaces are part of some zone, whether an address is assigned or not. In terms of implementation, that means that filtering is set up before addresses. If you set up addresses and then filtering, there's a *very* brief window where traffic isn't filtered, and that is bad. > By having > them in the 'dmz' zone, does this mean that host firewall rules > will impact VMs? Not unless you change the net.bridge.bridge-nf-call-* settings. > I understand that for bridging and vlans to work that I likely need > these forwardings active No, you don't. It's active because libvirtd defines a NAT network by default, and that one requires IP forwarding. > , but am I opening things up so that (for > example) a maliciously crafted packet seen on the enp1s0.2 interface > could jump onto the dmz subnet on eno1? Not in the default firewalld rule set. > I have to admit, the firewall-config GUI seems more like it's oriented > to either the local machine or other machines behind NAT, rather than > a router. (I don't want the host nodes generally acting as routers, > but how can I tell if they are doing so inadvertently?) Examine the output of "iptables -L -nv" and check all of the ACCEPT rules.