On Thu, Apr 05, 2007 at 11:38:42AM +0100, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > [...] > > >Scenario 2: Virtual network > >=========================== > > > > net.bridge.bridge-nf-call-iptables = 1 > > As far as I could tell, this case is exactly the same as scenario 1, > except PHYSIN is available. Yep, that is correct. The net.bridge.bridge-nf-call-iptables has a much more significant impact on scenario 4 with shared physical NICs, because with bridging to the physical NIC you'd ordinarily not hit iptables at all in many cases. > >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. > >Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) > > pkts bytes target prot opt in out source > > destination > > 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:53 > > 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:53 > > 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:67 > > 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:67 > > So we have ACCEPT rules on a chain whose default policy is ACCEPT? Is > there a later catch-all REJECT rule which I'm not seeing? Basically assume the policy of the chain could be anything. I just happened to have it as ACCEPT, but the user may well have other rules added by the OS tools (eg system-config-securitylevel) which would otherwise block our traffic. So in coming up with the rules I tried to be as explicit as possible about what to ACCEPT/REJECT. > >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. > > >Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) > > pkts bytes target prot opt in out source > > destination > > 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:53 > > 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:53 > > 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:67 > > 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:67 > > Again I don't understand ACCEPT rules on a chain with default policy ACCEPT. As above - its a 'just in case'. 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 -=|