[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Virtual network iptables rules



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  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]