[Bug 227837] Re: [Hardy] overzealous masquerading affects vm to vm traffic

[Martin Pitt]

Accepted libvirt into hardy-proposed, the package will build now and be
available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!

** Tags added: verification-needed

-- 
[Hardy] overzealous masquerading affects vm to vm traffic
https://bugs.launchpad.net/bugs/227837
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.

Status in “libvirt” package in Ubuntu: Fix Released
Status in “libvirt” source package in Hardy: Fix Committed

Bug description:
The default masquerade rule appears to be:

iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -j MASQUERADE

but this causes all internally routed guest to guest traffic to be masqueraded too (breaking such things as redhat cluster dlm connections in my case).

replacing the rule with the following seems to be a good solution:

iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -d ! 192.168.122.0/24 -j MASQUERADE

[Impact]
Causes inappropriate masquerading of internally routed traffic, which makes it difficult to test virtual clusters (among other things)

[How Addressed in Development]
This patch is a cherrypick from upstream's git tree.  This fix is already in the version carried in Jaunty today.

[Patch]
Attached is a minimal patch fixing the issue, taken from git upstream.

[Reproduction]
Set up two kvm machines.  Ping the first from the second, and run tcpdump on the second; in the tcpdump output, you *should* see that the pings come from the ip address of the first kvm machine, but instead (with the bug) you'll see they come from the ip address associated with virbr0, the bridge device on the host.

[Regression Potential]
It is hard to imagine a situation where it would desirable that all traffic from other machines on the internal bridged network appear to come from the single ip address of the host.   That said, users with a pre-existing network of guests may have developed workarounds on the guests to compensate for the bug, in which case applying this fix may require them to reconfigure their guests to remove those workarounds.