Re: iptables masquerade rule overexpansive

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

 



On Thu, Mar 27, 2008 at 01:23:25PM -0500, Charles Duffy wrote:
> On my system, libvirt-0.4.0-2ubuntu6 added the following rule to allow 
> my virtual hosts NATted access to the outside world:
> 
> >Chain POSTROUTING (policy ACCEPT 33904 packets, 2146K bytes)
> > pkts bytes target     prot opt in     out     source               
> > destination
> >  779  102K MASQUERADE  all  --  *      *       192.168.65.0/24      
> >  0.0.0.0/0
> 
> This resulted in *all* traffic being masqueraded, even between two 
> different VMs -- preventing hostbased authentication between these VMs. 
> To temporarily resolve this, I added an additional rule, as follows:
> 
> >Chain POSTROUTING (policy ACCEPT 34049 packets, 2160K bytes)
> > pkts bytes target     prot opt in     out     source               
> > destination
> >  156  9752 ACCEPT     all  --  *      *       192.168.65.0/24      
> >  192.168.65.0/24
> >  865  109K MASQUERADE  all  --  *      *       192.168.65.0/24      
> >  0.0.0.0/0
> 
> The network definition being used was as follows:
> 
> ><network>
> >  <name>default</name>
> >  <uuid>a7c5b18c-9d38-40ed-9b12-8b1a27013b85</uuid>
> >  <bridge name="virbr%d" />
> >  <forward/>
> >  <ip address="192.168.65.253" netmask="255.255.255.0"/>
> ></network>
> 
> I'm frankly unclear on why the packets attempted to forward through .253 
> in any event -- the routing tables on both VMs refer to 192.168.65.0/24 
> as part of the local network, so my expectation is that no attempt to 
> route through the default gateway should have occurred.

This is probably a result of the sysctl settings in the host. I imagine
you have

  net.bridge.bridge-nf-call-iptables = 1

which will cause bridged traffic to be passed into iptables even though
it is doing link layer bridging which would ordinarily only hit the
ebtables filters. 

> In any event, having libvirt extend the MASQUERADE rule to avoid 
> impacting traffic between hosts on the virtual network -- or adding a 
> paired ACCEPT, as I did above -- would probably be a Good Thing.

Instead of having the separate ACCEPT rule I think it would be sufficient
to replace  the 0.0.0.0/0 target with  ! 192.168.65.0/24, eg

iptables -t nat -A POSTROUTING
                --source 192.168.65.0/24 
                --destination ! 192.168.65.0/24
                -j MASQUERADE

so it will masquerade traffic which is leaving the ip range of the virtual
network only, and leave ip traffic between the VMs & VM<->host alone.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]