Open Stack

Hi Mark,

That part I understand :) Consider these rules (nabbed from forum posting
here<http://www.zeroshell.net/eng/forum/viewtopic.php?p=655&sid=76f8a08777176b9f939642734f2b23d0#655>
):

iptables -t nat -A prerouting_rule -d WAN_IP -p tcp --dport 80 -j DNAT --to
> 192.168.0.10
> iptables -A forwarding_rule -p tcp --dport 80 -d 192.168.0.10 -j ACCEPT
> iptables -t nat -A postrouting_rule -s 192.168.0.0/24 -p tcp --dport 80 -d
> 192.168.0.10 -j MASQUERADE


Some pretty "basic" iptables based router distro's like pfSense etc call
this hairpin NAT or NAT reflection.. And, I'm wondering if a
similar technique is possible with the rules OS generates?

(I've quite literally never used NAT with iptables, except indirectly via
Vyatta's config system, so I'm hoping someone more familiar with iptables
NAT can chime in!)

Thanks,
Kiall


On Mon, Oct 10, 2011 at 12:16 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> Hi Kiall,
>
> On Sun, 2011-10-09 at 22:41 +0100, Kiall Mac Innes wrote:
> > Hiya,
> >
> > I'm looking to find out if there is any way to access an instance via its
> > public (floating ip) from within the same instance.
> >
> > The docs mention that this is not possible here:
> >
> http://docs.openstack.org/diablo/openstack-compute/admin/content/associating-public-ip.html
> >
> > My question is this: is this a physical impossibility, or a limitation of
> > the current nova-network implementation?
>
> Floating IPs are implemented by nova-network using NAT - incoming
> packets in the host destined for the floating IP have their destination
> changed to the fixed IP and vice versa.
>
> i.e. from within the VM, you basically have no knowledge of your
> floating IP apart by looking at e.g. the public-ipv4 property from the
> EC2 metadata API or using the likes of www.whatismyip.com
>
> It's pretty much the same situation as being behind any NAT
>
> Cheers,
> Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111010/f567655b/attachment.html>