LAB 56 ‐ Stateless vs Statefull Security List - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

OCI Security Lists: Stateful vs Stateless

Overview

In Oracle Cloud Infrastructure (OCI), a Security List acts as a virtual firewall for the resources in a subnet.

It controls:

  • Ingress traffic — Incoming traffic
  • Egress traffic — Outgoing traffic

Security List rules can be configured as:

  • Stateful
  • Stateless

The primary difference lies in how OCI handles the return traffic of an established connection.

1. Stateful Security Rules

A stateful rule tracks the state of an established network connection.

If traffic is allowed by a stateful rule, OCI automatically permits the return traffic for that connection.

Example Configuration

Suppose we have a web server:

Client | | TCP Port 80 v Web Server

We configure the following stateful ingress rule:

  • Source CIDR: 0.0.0.0/0
  • Protocol: TCP
  • Destination Port: 80
  • Stateful: Yes (Stateless box unchecked)

This allows clients to connect to the web server on port 80. When the web server sends a response back to the client, OCI automatically allows the return traffic because the connection is statefully tracked.

Stateful Traffic Flow

Client | | TCP 80 Request v Web Server | | Response v Client

Stateful Rule ↓ Return traffic is automatically allowed

Key Point

With a stateful rule:

Client -> Web Server (Request) -> Allowed Web Server -> Client (Response) -> Automatically Allowed

OCI remembers the connection and automatically allows the return traffic.

2. Stateless Security Rules

A stateless rule does not track the state of a network connection. Each direction of traffic is evaluated independently.

Therefore, when using stateless rules, the required traffic in the opposite direction must also be explicitly allowed through an egress rule.

Example Configuration

Suppose we have:

Client | | TCP Port 80 v Web Server

We configure an ingress stateless rule:

  • Source CIDR: 0.0.0.0/0
  • Protocol: TCP
  • Destination Port: 80
  • Stateful: No (Stateless box checked)

This allows the client to send traffic to the web server on port 80. However, because the rule is stateless, OCI does not track the connection. The required return traffic must also be explicitly handled through an appropriate egress rule (typically using client ephemeral ports 32768-65535).

Stateless Traffic Flow

Client | | Request v Web Server | | Response v Client

Stateless Rule ↓ Each direction is evaluated separately

3. Stateful vs Stateless: Quick Comparison

Feature Stateful Rules Stateless Rules
Connection Tracking Yes No
Return Traffic Automatically allowed Must be explicitly allowed
Configuration Simpler More rules required (Ingress + Egress)
Traffic Handling Connection-aware Direction-based (Independent packets)
Common Use Cases General application traffic, SSH, Databases High-throughput workloads, Big Data, Load Balancers

4. Real-World OCI Example: Load Balancer to App Server

Consider a standard architecture:

Internet | v Load Balancer | v Application Server

Suppose the Load Balancer communicates with the Application Server on TCP port 80.

Stateful Configuration

On the Application subnet, configure:

  • Ingress Rule:
    • Source: Web/LB Subnet CIDR
    • Protocol: TCP
    • Destination Port: 80
    • Stateful: Yes

The Application Server accepts the request from the Load Balancer. When the Application Server sends the response back, OCI automatically allows the return traffic because the connection is statefully tracked.

Load Balancer | | TCP 80 Request v Application Server | | Response v Load Balancer

Stateful ↓ Return traffic is automatically allowed

5. Stateless Implementation of the Real-World Example

Now suppose the same ingress rule is configured as stateless:

  • Ingress Rule:
    • Source: Web/LB Subnet CIDR
    • Protocol: TCP
    • Destination Port: 80
    • Stateful: No (Stateless: Checked)

The incoming request is allowed. However, OCI does not automatically allow the response traffic based on the established connection.

Therefore, the required return traffic must also be explicitly handled through an appropriate egress rule:

  • Egress Rule (Mandatory for return path):
    • Destination: Web/LB Subnet CIDR
    • Protocol: TCP
    • Source Port: 80
    • Destination Port Range: Ephemeral Ports (e.g., 32768-65535)
    • Stateful: No (Stateless: Checked)

Load Balancer | | Request v Application Server | | Response v Load Balancer

Stateless ↓ Each direction is evaluated separately

6. HTTP Web Server: Stateful Rule Breakdown

To allow inbound HTTP traffic to a web server statefully:

Security List Rule

  • Direction: Ingress
  • Source CIDR: 0.0.0.0/0
  • Protocol: TCP
  • Destination Port: 80
  • Stateful: Yes

Traffic Flow

Internet | | HTTP Request (TCP 80) v Web Server | | HTTP Response v Internet

Because the rule is stateful, the return traffic for the established connection is automatically allowed without requiring an egress rule.

7. HTTP Web Server: Stateless Rule Breakdown

Changing the rule to stateless requires explicit two-way management:

Ingress Rule

  • Direction: Ingress
  • Source CIDR: 0.0.0.0/0
  • Protocol: TCP
  • Destination Port: 80
  • Stateful: No

The request is allowed: Client -> Web Server (TCP 80) -> Allowed

OCI does not track the connection. Therefore, return traffic must be explicitly allowed with an appropriate egress rule:

Client -> Web Server: Request -> Allowed Web Server -> Client: Response -> Explicitly handle return traffic (Egress Rule)

8. Important OCI Console Detail

In OCI Security Lists, the stateful/stateless property is configured per individual rule using a checkbox:

  • Checkbox Unchecked (Default): The rule is Stateful (connection-aware).
  • Checkbox Checked ("Stateless"): The rule is Stateless (connection tracking is disabled, and bidirectional rules are required).

9. Interview-Ready Explanation

Question

What is the difference between stateful and stateless rules in OCI Security Lists?

Answer

In OCI Security Lists, a stateful rule tracks the connection state in memory. When traffic is permitted in one direction, OCI automatically allows the response/return traffic for that established session.

In a stateless rule, OCI does not maintain connection tracking tables. Every packet in each direction is evaluated independently against the security list. To allow complete communication using stateless rules, explicit rules must be defined for both ingress (request) and egress (response, usually covering dynamic/ephemeral ports).

10. Summary Cheat Sheet

Stateful

  • Request -> Allowed
  • Response -> Automatically Allowed (Connection is tracked)

Stateless

  • Request -> Allowed
  • Response -> Must be explicitly handled (Connection is not tracked)

One-Line Definition

  • Stateful: OCI tracks the connection and automatically allows the return traffic.
  • Stateless: OCI does not track the connection, so each direction of traffic must be explicitly handled.