Many of you networking gurus out there may not understand the need for such a post. As someone who is new to both OpenStack and networking this process was not clear for me.
The following diagram illustrates the setup I was using – On one windows 7 laptop I was running VMware workstation 10 and within this I had a self-contained Cloud Service Automation (CSA) vm. The network on this vm was bridged to my laptops interface allowing this vm to receive a DHCP address on my local network 192.168.1.0/24. The second system I was using was a DL360G7 which had Ubuntu 14.04 as the host operating system also attached to the 192.168.1.0/24 network. This DL360G7 was host to a virtual installation of Helion OpenStack v1.1 [this install process can be found in this earlier post].
Obviously there needs to be a route on the CSA windows 2k8 server host to the API endpoints of the HOS service that I wish to consume which are on a 192.0.2.0/24 network. This does not exist by default which can be seen when looking at the host routing table below.
ping 192.0.2.2 /t
The 192.0.2.0/24 network is virtualised on the DL360G7 and can only be accessed remotely through the physical interface on the DL360G7 which has an ip address of 192.168.1.13. This is called the gateway address.
Open a command prompt window on the CSA server: Start -> Run -> cmd
Enter a route to the HOS network using the following command
route add -p 192.0.2.0 mask 255.255.255.0 192.168.1.13
The network routes on the CSA host should now look something like this (we’re only concerned about the new addition of 192.0.2.0 – it’s likely there could be many other routes on your system).
Now when you ping a server on the 192.0.2.0/24 network you should see a response from the DL360G7 host server. Don’t panic! – Yes, it’s still not working but at least you can see that the correct host is now responding to your request.
ping 192.0.2.2 /t
If we look at the host interface now on the DL360G7 HOS host server we can see that the ping request is coming in, however it is not getting a response.
tcpdump -ni em1 icmp
tcpdump -c 10 -ni virbr0
There are no signs of any ping requests from the CSA host 192.168.1.12 getting this far.
So the problem is between the em1 interface and the virbr0 virtual interface – what’s between these interfaces? Iptables! also known as the host firewall.
A quick look at the iptables on the DL360G7 Ubuntu host reveals the final hurdle in the quest for a route between the systems – filters rejecting the external traffic.
iptables -t filter -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
iptables -t filter -D FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
tcpdump -ni virbr0