Understanding INBOUND vs OUTBOUND Connections¶

Core Concepts¶

INBOUND Connection¶

Definition: Traffic coming FROM outside TO your server

External Client → YOUR Server

Characteristics: - Server is passive (listening/waiting) - Client initiates connection - Server must be reachable (requires public IP or port forwarding) - Firewall typically blocks by default

Example:

# Server side (YOUR machine)
python3 -m http.server 8080
# Server is now LISTENING on port 8080
# Waiting for INBOUND connections

# Client side (external machine)
curl http://YOUR_IP:8080
# Client initiates INBOUND connection to your server

Real-world analogy: - گھر میں بیٹھے ہیں - Doorbell کا انتظار کر رہے ہیں - کوئی آئے تو دروازہ کھولیں گے

OUTBOUND Connection¶

Definition: Traffic going FROM your server TO outside

YOUR Server → External Service

Characteristics: - Server is active (initiating) - Server initiates connection - No public IP needed - Firewall typically allows by default

Example:

# YOUR machine
curl https://google.com
# You initiated OUTBOUND connection
# Google responds through same connection

Real-world analogy: - آپ نے کسی کو phone کیا - آپ نے connection initiate کی - دوسری طرف والے کو آپ کا number نہیں چاہیے

Why This Matters for Tunnels¶

Traditional Setup (INBOUND)¶

Internet User
    ↓
Looks up: jenkins.ibtisam-iq.com
    ↓
Finds: 54.123.45.67 (your public IP)
    ↓
Connects TO: 54.123.45.67:443
    ↓
Your server (listening on 443)
    ↓
Accepts connection ← INBOUND

Requirements: - ✅ Public IP address - ✅ Port open in firewall - ✅ Service listening on port

Tunnel Setup (OUTBOUND)¶

Phase 1: Your server connects OUT

Your Server (no public IP)
    ↓
Connects TO: tunnel.cloudflare.com
    ↓
Says: "I'm jenkins-tunnel, keep me connected"
    ↓
Cloudflare: "OK, connection accepted"
    ↓
Connection ESTABLISHED ← OUTBOUND

Phase 2: Internet user visits your site

Internet User
    ↓
Looks up: jenkins.ibtisam-iq.com
    ↓
Finds: Cloudflare's IP
    ↓
Connects TO: Cloudflare
    ↓
Cloudflare: "jenkins-tunnel already connected!"
    ↓
Pushes request through existing OUTBOUND connection
    ↓
Your server receives it

Key insight: - User never connects directly to your server (no INBOUND) - Traffic flows through your existing OUTBOUND connection - TCP is bidirectional - once connected, data flows both ways

NAT and Firewalls¶

Default Firewall Rules¶

INBOUND (restricted):

iptables -P INPUT DROP  # Block all incoming by default

OUTBOUND (allowed):

iptables -P OUTPUT ACCEPT  # Allow all outgoing by default

Behind NAT (Network Address Translation)¶

Your situation in iximiuz:

Your Playground (10.0.5.123 - private IP)
    ↓
iximiuz NAT Gateway (185.123.45.67 - public IP)
    ↓
Internet

OUTBOUND works:

Your playground → NAT gateway → Internet ✅
NAT keeps track of your connection
Response comes back through same NAT

INBOUND doesn't work:

Internet → NAT gateway (185.123.45.67) → ???
Gateway doesn't know which internal IP to forward to ❌

TCP Connection States¶

Three-Way Handshake¶

Client initiates (OUTBOUND from client perspective):

1. Client → Server: SYN (I want to connect)
2. Server → Client: SYN-ACK (OK, I accept)
3. Client → Server: ACK (Great, connected!)

Once established:

Connection is BIDIRECTIONAL
Client ←→ Server (both can send data)

How Tunnels Exploit This¶

Normal:

Client initiates → Server accepts → Bidirectional

Tunnel:

Server initiates → Cloudflare accepts → Bidirectional!

Even though server initiated, once connected: - Cloudflare can send data TO server ✅ - Server can send data TO Cloudflare ✅ - Works exactly like normal connection!

Practical Examples¶

Example 1: Web Server (INBOUND)¶

# Start server
python3 -m http.server 8080

# Check listening
netstat -tlnp | grep 8080
# Output: tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN

# Server is waiting for INBOUND connections

Connection flow:

Client initiates → Server accepts (INBOUND) → Response

Example 2: Database Connection (OUTBOUND)¶

# Your application
mysql -h db.example.com -u user -p

# Your app connects OUT to database

Connection flow:

Your app initiates (OUTBOUND) → Database responds

Example 3: SSH (Can be either)¶

Normal SSH (INBOUND to server):

# From your laptop
ssh user@server-ip

# Your laptop → Server (INBOUND to server)

Reverse SSH Tunnel (OUTBOUND from server):

# On remote server
ssh -R 8080:localhost:8080 user@your-laptop

# Server → Your laptop (OUTBOUND from server)
# Then your laptop can access server's port 8080!

Port Forwarding vs Tunnels¶

Port Forwarding (Router/Gateway)¶

Internet (1.2.3.4:80)
    ↓
Your router forwards → Internal IP (192.168.1.100:80)

Requirements: - Control over router/gateway - Public IP on router - Manual configuration

Tunnel (No router control needed)¶

Your server (no public IP)
    ↓ [OUTBOUND]
Tunnel service (has public IP)
    ↓
Internet can reach tunnel service
    ↓
Traffic forwarded through existing connection

Advantages: - No router access needed - No public IP needed - Works behind NAT - Works behind firewall

Common Misconceptions¶

Misconception 1: "Tunnel creates a port forward"¶

Wrong: Tunnel doesn't open any ports on your machine

Right: Tunnel creates an OUTBOUND connection, traffic flows through it

Misconception 2: "I need public IP for tunnel"¶

Wrong: Public IP defeats the purpose

Right: Tunnel specifically designed for NO public IP scenarios

Misconception 3: "Tunnel is less secure"¶

Wrong: Tunnel can be more secure (encrypted, authenticated)

Right: Tunnel is encrypted end-to-end, plus authentication via credentials

Debugging Connection Direction¶

Check listening ports (INBOUND services)¶

# Linux
netstat -tlnp
sudo ss -tlnp

# Mac
netstat -an | grep LISTEN
lsof -i -P | grep LISTEN

Output shows services waiting for INBOUND connections:

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN  # Nginx
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN  # Jenkins

Check established connections¶

# See all connections
netstat -tunap

# See OUTBOUND connections you initiated
netstat -tunap | grep ESTABLISHED

Check if port accessible from outside (INBOUND test)¶

# From external machine
nc -zv YOUR_IP PORT
telnet YOUR_IP PORT
curl http://YOUR_IP:PORT

Summary¶

For Tunnels:¶

Traditional method needs: - INBOUND capability - Public IP - Open ports

Tunnel method needs: - OUTBOUND capability only - No public IP - No open ports

Tunnel works because: 1. You connect OUT first (allowed by firewall) 2. Connection stays open 3. TCP is bidirectional 4. Traffic flows both ways through same connection