Which mechanism prevents public exposure when floating IPs are attached to permissive security groups?

Answer to the question

OpenStack Neutron does not provide a stateless subnet‑level filter that automatically blocks traffic to a floating IP. The only built‑in guardrail is the default deny‑all rule that every instance’s security group carries. When a floating IP is attached, the Neutron router forwards the packet to the instance, and the forwarded packet bypasses any security group that is attached to the router’s external port. Therefore, if the instance’s security group contains a permissive rule (e.g., 0.0.0.0/0 for SSH), the traffic will reach the instance regardless of the router’s external port security group.

Confirmed facts (OpenStack 2024‑style releases)

• Every instance inherits a default security group that contains a single rule denying all inbound traffic.
• Security group rules are evaluated before any provider‑network ACLs.
• Router forwarding to a floating IP does not apply the external port’s security group rules.
• No native subnet‑level ACL exists in Neutron; provider ACLs or firewall extensions (e.g., Neutron Firewall‑as‑a‑Service) are required for global filtering.

Practical verification steps

1. Check the instance’s security group:

   openstack security group rule list SG_NAME
   

2. Verify that the default deny‑all rule is present and that there are no permissive rules covering the port you want to protect.

3. Test connectivity from an external host to the floating IP on a port that should be blocked:

   nc -vz FLOATING_IP PORT
   

4. Inspect the router’s external port security group (if any) to confirm it doesn’t influence forwarded traffic:

   openstack port show ROUTER_EXT_PORT_ID
   

5. If you rely on provider ACLs, list them:

   openstack network show NETWORK_ID --long
   

Missing diagnostic detail that could change the recommendation

Do you have any provider‑network ACLs or firewall‑as‑a‑service extensions configured for the tenant network? If so, what rules do they contain? Knowing this will determine whether an external ACL can act as a guardrail in addition to the security group.

Takeaway

In a standard OpenStack Neutron deployment, preventing public exposure of a floating IP that is attached to a permissive security group relies entirely on correctly configuring the instance’s security group. If you need a global, stateless filter, you must deploy provider ACLs or a Neutron firewall extension; otherwise, the default security group deny rule is the only native safeguard.