A stateful security rule maintains information about the state of an active network connection. Once a connection is permitted by a stateful rule, the corresponding return traffic is automatically allowed without requiring a separate rule for the return path.

In OCI Security Lists:

Stateless = No → Stateful Rule

xample: SSH Connection

Assume a Linux instance has SSH enabled on TCP port 22.

Ingress Rule:

The traffic flow is:

Laptop
   |
   | SSH Request → TCP/22
   ↓
Security List
   |
   | ALLOW
   ↓
OCI Linux Instance
   |
   | Return Traffic
   ↓
Laptop

Because the rule is stateful, OCI tracks the established connection and automatically permits the corresponding return traffic.

Key Point

Stateful = Connection tracking + Return traffic is automatically permitted.

A stateless security rule does not maintain connection state. Each packet is evaluated independently according to the applicable security rules.

Therefore, when using stateless rules, the required traffic must be explicitly permitted in the appropriate direction.

In OCI Security Lists:

Stateless = Yes → Stateless Rule

Example: SSH Connection

Ingress Rule:

The incoming SSH request may be permitted:

Laptop
   |
   | SSH Request → TCP/22
   ↓
OCI Linux Instance

The server's response travels in the opposite direction:

OCI Linux Instance
   |
   | TCP Response
   | Source Port: 22
   | Destination Port: Ephemeral
   ↓
Laptop

Because the original rule is stateless, OCI does not use connection tracking to automatically permit the response. An appropriate egress rule must therefore allow the return traffic.

Key Point

Stateless = No connection tracking + Required traffic must be explicitly permitted in each direction.

Assume the Linux server has:

Stateful SSH Rule

Ingress Security Rule:

Traffic flow:

Client
   |
   | TCP
   | Destination Port: 22
   ↓
Server
   |
   | Return Traffic
   ↓
Client

     ↳ Automatically permitted

OCI tracks the connection and permits the corresponding return traffic.

Stateless SSH Rule

Ingress Security Rule:

Traffic flow:

Client | | TCP | Destination Port: 22 ↓ Linux Server | | Return Traffic | Source Port: 22 | Destination Port: Ephemeral ↓ Client

 ↳ Appropriate EGRESS rule required

The return traffic must be explicitly permitted by an appropriate egress security rule.

Stateful rules are commonly used because they simplify security configuration.

For example, when an administrator connects to an OCI Linux instance:

ssh opc@

The connection involves traffic flowing in both directions.

With a stateful SSH rule, OCI tracks the connection and automatically permits the corresponding return traffic.

This reduces the number of rules that administrators need to configure and maintain.

Stateless rules are useful when administrators require explicit control over traffic in each direction.

They allow inbound and outbound traffic to be controlled independently through separate security rules.

This can provide more granular control over network communication, although it requires more careful configuration.

Question:

What is the difference between Stateful and Stateless Security Rules in OCI?

Professional Answer:

A stateful security rule tracks the state of a network connection. When an allowed connection is established, OCI automatically permits the corresponding return traffic. In OCI, Stateless = No represents a stateful rule.

A stateless security rule does not track connection state. Therefore, the required traffic must be explicitly permitted in the appropriate directions using ingress and egress rules. In OCI, Stateless = Yes represents a stateless rule.

Stateful

Think of a security guard who remembers you after checking you in.

You enter → Guard verifies you → Guard remembers you ↓ Return access permitted

The connection is tracked.

Stateless

Think of a security guard who checks you every time you pass.

Entering → Check required Returning → Check required

Each direction is evaluated independently.

Stateless = No 
     ↓
Connection Tracking 
     ↓ 
Return Traffic Automatically Allowed

Stateless

Stateless = Yes 
      ↓ 
No Connection Tracking 
      ↓ 
Traffic Must Be Explicitly Allowed 
      ↓ 
Appropriate Ingress + Egress Rules

Lab Objective

The objective of this lab is to understand the behavior and configuration differences between Stateful and Stateless Security List rules in Oracle Cloud Infrastructure (OCI).

Using the existing Bastion Server and Target Server, we will establish SSH connectivity, modify the security rules from Stateful to Stateless, observe the resulting connectivity behavior, and then configure the required return-traffic rules to restore SSH connectivity.

• Verify SSH connectivity using Stateful Security List rules.
• Convert the SSH rules to Stateless.
• Test SSH connectivity and analyze the failure.
• Configure explicit return-traffic rules.
• Re-test SSH connectivity.
• Understand TCP source and destination ports during an SSH session.
• Compare Stateful and Stateless security behavior in OCI.

OCI Console → Networking → VCN → asus_sl → Security Rules → Ingress Rules

SSH Ingress Rule

Explanation

In OCI:

Stateless = No ↓ Stateful Security Rule

The rule permits TCP traffic destined for port 22 from the Bastion subnet.

Because the rule is Stateful, OCI maintains connection state and automatically permits the corresponding return traffic for the established SSH connection.

Verification

Confirm that:

Stateless = No

This verifies that the SSH ingress rule is Stateful.

Navigate to:

OCI Console → Networking → VCN → hub_publicsub_sl → Security Rules → Egress Rules

Locate the SSH egress rule.

SSH Egress Rule

This rule permits the Bastion Server to initiate SSH traffic toward the Target Server.

Because the rule is Stateful, OCI automatically permits the corresponding return traffic associated with the established connection.

Verification

Confirm that:

Stateless = No

From the Bastion Server, initiate an SSH connection to the Target Server:

ssh opc@<TARGET_PRIVATE_IP>

Expected Result SSH Login Successful

Successful authentication confirms that SSH connectivity between the Bastion Server and Target Server is functioning correctly with Stateful Security List rules.

Verify the Target Server

After logging in, verify the server identity:

hostname

Optionally, verify the assigned IP address:

hostname -I

After completing the verification, exit the Target Server:

exit

Navigate to asus_sl → Ingress Rules → TCP/22 Rule → Edit

Update:

Stateless: No → Yes

Keep all other values unchanged.

Click Save Changes.

✅ Target Server ingress rule updated.

Navigate to hub_publicsub_sl → Egress Rules → TCP/22 Rule → Edit

Update:

Stateless: No → Yes

Keep all other values unchanged.

Click Save Changes.

✅ Bastion egress rule updated.

From the Bastion Server:

ssh opc@<TARGET_PRIVATE_IP>

Expected Result:

Connection fails with Connection timed out.

Why does it fail?

• Request: Bastion → Target (Destination Port: 22)

• Response: Target → Bastion (Source Port: 22 → Destination Port: Ephemeral)

• Stateless rules do not automatically track connection state.

• Return traffic must be explicitly allowed.

Navigate to asus_sl → Security Rules → Egress Rules → Add Egress Rule

Configure:

Destination CIDR: 10.0.0.0/25

Protocol: TCP

Source Port Range: 22

Destination Port Range: 1024–65535

Stateless: Yes

Click Add Egress Rule.

✅ Return traffic rule added on Target.

Navigate to hub_publicsub_sl → Security Rules → Ingress Rules → Add Ingress Rule

Configure:

Source CIDR: 10.0.1.0/26

Protocol: TCP

Source Port Range: 22

Destination Port Range: 1024–65535

Stateless: Yes

Click Add Ingress Rule.

✅ Return traffic rule added on Bastion.

• Port 22 → SSH server port.

• 1024–65535 → Ephemeral client port range.

• SSH Request: Bastion → Target (Ephemeral → 22)

• SSH Response: Target → Bastion (22 → Ephemeral)

📌 Easy memory trick:

• 22 = SSH Server Port

• 1024–65535 = Client Ephemeral Port Range

From the Bastion Server:

ssh opc@<TARGET_PRIVATE_IP>

ssh -i ~/keys/privkey.pem [email protected]

Expected Result:

✅ SSH Login Successful

Traffic in both directions explicitly permitted.