Learn OpenStack - Neutron Routers, Floating IPs & Security Groups

#Introduction

In episode 6, you created virtual networks that were still isolated. Episode 7 answers the most fundamental question after that: how do instances inside that network reach the internet, and how does the outside world reach those instances? The answer lies in three Neutron mechanisms: virtual routers, floating IPs, and security groups.

These three topics work in sequence in real scenarios. The router opens the outbound path via SNAT. The floating IP opens the inbound path via DNAT. And the security group guards the door — making sure only the traffic you allow passes through. This episode covers all three with hands-on practice.

#Virtual Routers

#Connecting the Tenant Network to the Provider Network

A virtual router in Neutron is an object that connects two networks: the internal side (tenant/self-service) and the external side (provider/public). This router is implemented by the L3 Agent — in DevStack, a network namespace on the network node.

openstack router create router-utama
openstack router set --external-gateway public router-utama
openstack router add subnet router-utama subnet-aplikasi

The openstack router add subnet router-utama subnet-aplikasi command attaches the internal subnet to the router. After this, instances on subnet-aplikasi have a path to the router as their gateway.

#SNAT for Outbound Traffic

SNAT (Source NAT) lets instances with private IPs reach the internet. The router rewrites the packet's source address to an IP from the external network, then forwards the responses back. This means instances can apt-get update, curl, and access the internet even without a public IP.

openstack network agent list --type l3

The output of openstack network agent list --type l3 shows the running router agents and their status. If an agent is dead, all internal-external routing stops — this is one of the failure points we'll discuss in episode 19.

#DNAT for Inbound Traffic

The opposite of SNAT, DNAT (Destination NAT) directs traffic from outside to a specific instance. The most common application of DNAT is the floating IP — a public IP routed to an instance's private IP.

#Floating IPs

#The Floating IP Concept

A floating IP is an IP from an external pool that can be assigned to and unassigned from instances dynamically. Unlike a fixed IP (the private IP on an instance's port), a floating IP is essentially borrowed — an instance can switch floating IPs, or one floating IP can move to another instance during maintenance.

openstack floating ip create public
openstack floating ip list

openstack floating ip create public takes one IP from the external pool. Note the floating_ip_address column in the output — that's the IP you'll connect to the instance.

#Associating a Floating IP with an Instance

openstack server add floating ip ubuntu-nginx 172.24.4.10
openstack server show ubuntu-nginx -c addresses

After openstack server add floating ip, the instance can be accessed from outside using the floating IP. Verify SSH connectivity from your machine:

ssh -i mykey.pem ubuntu@172.24.4.10

To detach and move it to another instance, use openstack server remove floating ip then add it to the target instance. This concept is widely used in production: floating IPs are moved between instances during failover.

#Security Groups

#Stateful Firewall per Instance

A security group is a collection of stateful firewall rules — meaning the responses to already-allowed traffic are automatically permitted without a separate rule. The default policy of every security group:

• Default deny all inbound — incoming traffic is blocked until a rule allows it.
• Default allow all outbound — instances are free to go out.

openstack security group list
openstack security group show default

The output of openstack security group show default shows the default rules that only allow SSH from within the same network and all outbound traffic.

#Adding Rules

Create a dedicated security group for the web server and add its rules:

openstack security group create sg-web
openstack security group rule create --proto tcp --dst-port 22 sg-web
openstack security group rule create --proto tcp --dst-port 80 --remote-ip 0.0.0.0/0 sg-web
openstack security group rule create --proto icmp --remote-ip 0.0.0.0/0 sg-web

The openstack security group rule create --proto tcp --dst-port 80 --remote-ip 0.0.0.0/0 command allows HTTP from all IPs. To restrict it to specific IPs only, replace 0.0.0.0/0 with your office CIDR.

#Attaching a Security Group to an Instance

openstack server create --image ubuntu-jammy --flavor m1.small \
  --network net-aplikasi --key-name mykey \
  --security-group sg-web ubuntu-web

openstack server create --security-group sg-web attaches the firewall the moment the instance is born. Security groups can also be added to or removed from already-running instances:

openstack server add security group ubuntu-web sg-web
openstack server remove security group ubuntu-web default

#Summary

Episode 7 makes your network truly alive: the virtual router opens the outbound path via SNAT and the inbound path via DNAT, floating IPs provide public addresses that can be moved around dynamically, and security groups keep things secure with a default-deny-all-inbound policy.

Key takeaways:

• Routers connect tenant networks to the provider network as the gateway.
• SNAT provides outbound internet access; DNAT provides inbound access.
• Floating IPs are assigned to and unassigned from instances dynamically.
• Security groups are stateful: deny inbound by default, allow outbound.
• Security group rules target protocol, port, and remote IP/CIDR.
• The router + floating IP + security group combination is the standard pattern for instance access.

In episode 8, we'll cover Cinder (Block Storage Service) and Persistent Volumes — understanding volumes as persistent virtual hard disks, creating and attaching volumes to instances, snapshots and backups for recovery, and choosing backend drivers from LVM to Ceph RBD for production.