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=<public_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.
