On Thu, Apr 05, 2007 at 11:55:30AM +0100, Daniel P. Berrange wrote:
On Thu, Apr 05, 2007 at 11:38:42AM +0100, Richard W.M. Jones wrote:
Type 1: Isolated virtual network --------------------------------
Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * vnet2 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet2 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
So the thinking here is that FORWARD will only apply to packets from DomU to the internet. Since this is an isolated network, all packets trying to go out should be rejected. I'm a bit confused as to what "vnet2" is here. It seems that any traffic to/from virbr0 should be rejected.
I should have explained that vnet2, vnet3 & virbr0 are all just the bridge devices associated with each virtual network. I actually had all 3 virtual networks running at once, which is wy each example uses a different NIC.
The rules above seem like they might match the DomU <-> DomU case (wouldn't these go through the FORWARD chain also?) If DomUs should be allowed to talk to each other (and that in itself is a policy decision) then perhaps adding a rule to allow when in = virbr0 & out = virbr0?
Hmm, that's a good question. I didn't test the DomU<->DomU case. I'll check up on that shortly & let you know about that. I suspect you are correct that this would accidentally block DomU<->DomU comms.
In scenario 1 we have net.bridge.bridge-nf-call-iptables = 0, so the DomU <-> DomU traffic is handled completely at the network briding layer, so iptables never gets involved at all. So we don't need any extra rules in this case to allow DomU <-> DomU.
Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 vnet3 0.0.0.0/0 192.168.200.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- vnet3 eth1 192.168.200.0/24 0.0.0.0/0 0 0 REJECT all -- * vnet3 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet3 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Seems OK, except for the DomU <-> DomU case as above.
Will investigate this too.
In this scenario 2, we net.bridge.bridge-nf-call-iptables = 1, so even though the DomU <-> DomU traffic is being bridged, it still enters the iptables PREROUTING, FORWARD & POSTROUTING chains. So, yes, we do need extra rule to allow DomU <-> DomU traffic here, match in=vnet3 & out=vnet3 The trace looks like: Out: NAT-PREROUTING IN=vnet3 OUT= PHYSIN=vif7.0 SRC=192.168.200.204 DST=192.168.200.242 FORWARD IN=vnet3 OUT=vnet3 PHYSIN=vif7.0 PHYSOUT=tap0 SRC=192.168.200.204 DST=192.168.200.242 NAT-POSTROUTING IN= OUT=vnet3 PHYSIN=vif7.0 PHYSOUT=tap0 SRC=192.168.200.204 DST=192.168.200.242 Back: FORWARD IN=vnet3 OUT=vnet3 PHYSIN=tap0 PHYSOUT=vif7.0 SRC=192.168.200.242 DST=192.168.200.204 I'm addressing this by adding an extra rule: Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 56 10899 ACCEPT all -- vnet3 vnet3 0.0.0.0/0 0.0.0.0/0 So with all this I've now tested: - Isolated network - Allowed SSH host -> guest - Allowed SSH guest -> host - Allowed SSH guest -> guest - Denied SSH guest -> world - Forwarding to specific NIC - Allowed SSH host -> guest - Allowed SSH guest -> host - Allowed SSH guest -> guest - Allowed SSH guest -> host on specific NIC - Denied SSH guest -> host on other NIC - Forwarding to world - Allowed SSH host -> guest - Allowed SSH guest -> host - Allowed SSH guest -> guest - Allowed SSH guest -> world regardless of active NIC Attaching the latest patch with this Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|