5:55 a.m.
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 -=|