[Libvir] Virtual network iptables rules
Daniel P. Berrange
berrange at redhat.com
Thu Apr 5 10:55:30 UTC 2007
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 -=|
More information about the libvir-list
mailing list