Unable to use Eucalyptus' iptables-preload feature with UEC

Bug #579868 reported by Carlos Perelló Marín
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
eucalyptus (Ubuntu)
New
Low
Unassigned

Bug Description

We are using UEC cloud controller in a server that also runs regular KVM servers with libvirt and bridge interface.

Everything is working more or less as expected, however, UEC configures iptable to use NAT for all traffic that is forwarded, even if it's not for the cloud itself. This causes that when we connect from an outside machine to any of the regular KVM machines, we are seen as coming always from the UEC cloud and KVM host.

That's not a big problem, given that is easy to solve adding this rule to iptables on that machine:

iptables -t nat -A POSTROUTING -d 10.82.0.0/22 -s 10.82.0.0/22 -j ACCEPT (where 10.82.0.0/22 is our local net), the problem comes on how to inject it in a way that UEC doesn't drop that rule on boot.

From Eucalyptus documentation (http://open.eucalyptus.com/wiki/EucalyptusNetworking_v1.6), we are able to put it on /var/run/eucalyptus/net/iptables-preload with the iptables-save command, however, that location is not valid for Ubuntu, because it's on a ram disk and thus, discarded with every reboot.

UEC should have a way to put that file in some other persistent place or a way to inject that file on boot time, any of those solutions would be valid for us.

Revision history for this message
Carlos Perelló Marín (carlos) wrote :

I forgot to mention that I'm talking about Ubuntu 10.04

Revision history for this message
Dave Walker (davewalker) wrote :

Generally, on a Ubuntu system ufw is recommended as a wrapper around iptables. Can i suggest you add the iptables line to /usr/share/ufw/iptables/before.rules which should ensure the rule is persistent across reboot.

If that solves the issue, then please report back here; otherwise we need to investigate why eucalyptus is dropping existing rules.

Thanks.

Changed in eucalyptus (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Carlos Perelló Marín (carlos) wrote :

I know about ufw, the problem is that eucalyptus is not aware of ufw (at least from what I saw in the source code) and the cloud controller resets the iptables rules EVERY TIME it's restarted, not just on reboot. The only documented way to "prevent" it from clear your custom rules is to use the iptables-preload file I talked about.

I know that the ideal solution would be that Eucalyptus use ufw, however I'm not sure that would be a trivial task so, until then, I just want to be able to use the official way to get it working instead of a hack I had to add so the file is copied there after each reboot.

Changed in eucalyptus (Ubuntu):
status: Incomplete → New
Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

This bug is affecting me too.

A scenario where the iptables-preload feature would be needed is one where the NC are in a separate private network (where the CC would have its VNET_PRIVINTERFACE). If you wish to NAT traffic between the private NC network and the public one (where the Walrus presumably service reside) through the CC, you would need the iptables-preload feature.

Technically, inthis topology, it would be possible to use another gateway between the private NC network and the outside, bu the CC is naturally positioned to provide this service.

Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

Please disregard the previous command. Looking again, it seems like the iptables rules eucalyptus-cc set up are sufficient to NAT connection from NC to the outside world, so the private NC network topology is not made impossible by this bug.

Still, iptables-preload sounds like a useful feature. It's a bummer it does not work on UEC due to /var/run being a tmpfs. We should change the location of the iptables-preload file so that it persist through reboot. Perhaps there is a compile-time option for this? Otherwise, I guess we could patch the path wherever it is hard-coded in the source.

Revision history for this message
Tony Maro (tonymaro) wrote :

Eitenne Goyer: Really? I just installed 10.10 RC and it does not add any MASQ rules for the private node network when in managed-novlan mode. I have yet to figure out how to give my nodes access to the Internet so I can download updates and access DNS.

I even tried scripting at boot to place the file in /var/run but then after Eucalyptus starts I have an empty iptables.

Revision history for this message
Luca Invernizzi (invernizzi) wrote :

I second Tony Maro: 10.10 does not add any masquerading for the node controllers.
A quick workaround that works for me is adding in /etc/rc.local:

iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o eth1 -j MASQUERADE
iptables-save> /var/run/eucalyptus/net/iptables-preload

Here, my node controllers are in the .42.0/24 private network, using the CC as gateway (CC is connected to the network via eth0).
Eth1 of the CC is connected to the outside word.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.