---
title: "Obtaining External Connectivity in OpenStack"
source: "https://www.tigera.io/blog/obtaining-external-connectivity-in-openstack/"
---

[Technical Blog](https://www.tigera.io/category/technical-blog/)

# Obtaining External Connectivity in OpenStack

By [Cory Benfield](https://www.tigera.io/blog/author/corybenfield/) on Jan 23, 2015 • 4 min read

So you’ve pulled the trigger and obtained some computing resource on your cloud platform of choice. It’s super easy to get your frontend web servers to talk to your database servers: they’re all in the same cloud, so you just point them at each other’s IPs and they happily start chatting away. Now that your infrastructure is in place, you want to reveal your new project to the world. How do you get external traffic to your servers? This post will discuss doing just that, from the perspective of OpenStack. If you’re using another platform (something based on Linux Containers, for example), the general approach is the same, though some of the specifics may differ.

The OpenStack answer has traditionally been to use ‘floating IPs’. However, floating IPs require a fair bit of configuration inside OpenStack (in the form of network nodes to perform NAT) and by the user, and it’s not always easy to get that right.

However, floating IPs have a deeper problem: they conflate two separate notions. The first is ‘accessibility’: should this machine be reachable from outside the data center? The second doesn’t have a short-and-sweet name, but we call it ‘IP address mobility’: the ability to move an IP address between VMs. This second property is used to make life easier for people using the cloud: you can set up your DNS to point to a single IP address that will never change, and simply move around the machine to which that address points.

In Calico, we take advantage of our pure-L3 model to fundamentally question the floating IP approach by splitting out accessibility and address mobility. For inbound accessibility, we can throw NAT and network nodes out the window. If you want a VM to be reachable from outside the data center, you simply give it an IP address that is reachable from outside the data center. Because we have a completely routed infrastructure this doesn’t prevent the machine communicating directly with other VMs in the data center, but it enables machines outside the data center to contact it as well. Because there’s no NAT all traffic takes the most efficient path to the VM, without passing through other boxes on the way.

For all the other VMs in your deployment, the ones with the private IPs, there is a slightly different requirement. For them, it’s necessary to perform some kind of NAT: their addresses are not going to be routable from the wider network or the internet at large. In this case, the NAT gets performed at the gateway as the traffic leaves the data center. This model is exactly the same as the one used in all large private networks for the last decade, and it’s far and away the simplest. The gateway maintains the stateful NAT and runs BGP so as to know how to route inbound to datacenter VMs: every other box in the network ignores its existence. Simple.

So, how do we handle mobility? We have a few ideas, none of which are set in stone yet, but the most attractive one so far is to use IP Anycast. This is a technique that can only really be applied in pure L3 fabrics. I’m not going to go into too much detail in this post, but the basic principle is that multiple machines are assigned the same IP, and the routing fabric balances load across them. Think of it as something like Amazon’s Elastic Load Balancer, but handled entirely transparently by the Calico fabric. No need for bump-in-the-wire middleboxes, just standard IP routing.

So, if you’re deploying OpenStack with Calico providing its networking, here are the things to remember:

1. Don’t configure floating IPs or routers! They don’t do anything.

2. Instead, create a ‘public’ network with a subnet that your gateway is advertising routes for.

3. When a VM wants a public address, just give it an interface on the ‘public’ network.

4. Make sure your gateway is BGP peered with your Calico nodes.

5. Consult our [‘External Connectivity in OpenStack’ document](http://docs.projectcalico.org/en/latest/opens-external-conn.html) for more detail.

[Open Source](https://www.tigera.io/tags/open-source/)[Project Calico](https://www.tigera.io/tags/project-calico/)

## Related posts

[![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

[Company Blog](https://www.tigera.io/category/company-blog/)

#### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/)
on Jun 2, 2026

Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs...

[Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

[![Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/app/uploads/2026/05/Kubernetes-Operational-Maturity-Secure-and-Resilient-Cluster-Federation-with-Cluster-Mesh.png)](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/)

#### [Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/)
on May 25, 2026

Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled...

[Read more](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/)

[![What’s New in Calico v3.32](https://www.tigera.io/app/uploads/2026/05/Green-Please-use-a-different-background-color-alternately-1.png)](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)

#### [What’s New in Calico v3.32](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)

By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/)
on May 13, 2026

We’re excited to announce the release of Calico Open Source v3.32! 🎉 This release corresponds with Kubernetes v1.36 (Codename Haru) and it goes beyond just sharing a cat as the mascot of the release, it...

[Read more](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=6700 metric#misses=19 metric#hit-ratio=99.7 metric#bytes=2031151 metric#prefetches=421 metric#store-reads=32 metric#store-writes=17 metric#store-hits=428 metric#store-misses=8 metric#sql-queries=33 metric#ms-total=899.34 metric#ms-cache=20.27 metric#ms-cache-avg=0.4224 metric#ms-cache-ratio=2.3 sample#redis-hits=79297281 sample#redis-misses=9179884 sample#redis-hit-ratio=89.6 sample#redis-ops-per-sec=31 sample#redis-evicted-keys=0 sample#redis-used-memory=140131536 sample#redis-used-memory-rss=103694336 sample#redis-memory-fragmentation-ratio=0.7 sample#redis-connected-clients=2 sample#redis-tracking-clients=0 sample#redis-rejected-connections=0 sample#redis-keys=85525 -->
