Heat/Configuring-Floating-IPs

= Floating IPS =

Overview
Amazon Elastic IPs (resources `AWS::EC2::EIP` and `AWS::EC2::EIPAssociation`) under Heat use OpenStack's Floating IPs.

Initially, there aren't any IP addresses available so using a template that depends on Elastic IPs will fail. This guide shows how to set them up.

Security Group Policy
Allow ICMP, SSH and HTTP connections on the instances:

Add the following to the template: [SecurityGroup](https://github.com/openstack/heat/commit/0ee8db445941f24e07a3a93b91adc87c192b1c1f#diff-2)

Configuring OpenStack for floating IPs
OpenStack expects a default interface of eth0. If running Fedora or another operating system that renames the physical interface, it is necessary to reconfigure OpenStack.

sudo openstack-config --set /etc/nova/nova.conf DEFAULT public_interface em1 or wlan0 sudo systemctl restart openstack-nova-network.service

Allocate Address Space
Pick a pool of addresses you want to allocate to OpenStack. The following allocates the `10.1.0.125/28` subnet:

sudo nova-manage floating create 10.1.0.125/28 --interface=

sudo nova-manage floating list

This tool will print out something similar to the following:

None	10.34.30.113	None	nova	eth0 None	10.34.30.114	None	nova	eth0 None	10.34.30.115	None	nova	eth0 None	10.34.30.116	None	nova	eth0 None	10.34.30.117	None	nova	eth0 None	10.34.30.118	None	nova	eth0 None	10.34.30.119	None	nova	eth0 None	10.34.30.120	None	nova	eth0 None	10.34.30.121	None	nova	eth0 None	10.34.30.122	None	nova	eth0 None	10.34.30.123	None	nova	eth0 None	10.34.30.124	None	nova	eth0 None	10.34.30.125	None	nova	eth0 None	10.34.30.126	None	nova	eth0

Deallocate the floating IPs
sudo nova-manage floating delete 10.1.0.125/28

Troubleshooting floating IPs in a NAT environment
In a typical laptop, wireless runs on wlan0. Typically the wireless router takes care of NAT from external addresses and assigns the host an address of 192.168.1.x. Unfortunately openstack floating IPs are designed to run on routed networks, not NAT networks.

In a real deployment, ingress traffic would look like this:

ROUTED NETWORK -> HOST -> FLOAT NAT -> VM

In a laptop, ingress traffic looks like this:

NAT -> HOST -> FLOAT NAT -> VM

Since the Wireless NAT can't NAT IPs it hasn't assigned, the Linux kernel must do NAT translation for the HOST's wlan0. Unfortunately this is not possible because the floating IP has to be NAT translated first. From iptables man page:

This target is only valid in the nat table, in the POSTROUTING chain. It specifies that the source address of the packet should be modified (and all future packets in this connection will also  be  mangled, and rules **should cease being examined**.

Because the rules are not examined further, it is not possible to have back-to-back NATs. To work around this problem on Laptops, the following rule should do the trick:

iptables -t nat -I POSTROUTING 1 -s 10.0.0.0/8 -j MASQUERADE -o wlan0

If your nova-manage network is created on 10.0.0.0 and your floating is on 10.1.0.0, this rule will force masquerading over wlan0 for the 10.x.x.x network. Note if your internal network is already on 10.0.0.0, you will want to use a different network that isn't already being used in your routing tables (such as 11.x.x.x).

A **BIG** thank you to Fabio Di Nitto for helping sort out this issue.