Network Firewall vs Proxy Server vs Secure Web Gateway (SWG)

What Are These Devices?

Three different network security devices that control and inspect internet traffic, each operating at different layers and serving different purposes.

1. Network Firewall

Physical or virtual device at network perimeter that blocks/allows traffic based on IP, port, and protocol.

Key Characteristics

Layer: 3-4 (Network/Transport Layer)

Location: On-premises, between internal network and internet

Type: Physical appliance or virtual machine

Purpose: Control which connections are allowed

What It Checks

✓ Source IP address
✓ Destination IP address
✓ Port number (80, 443, 22, etc.)
✓ Protocol (TCP, UDP, ICMP)

✗ Cannot see HTTP headers
✗ Cannot see URLs
✗ Cannot see content

Example Decision

Rule: Allow port 443 (HTTPS) to any destination
Request: 192.168.1.100 → 203.0.113.50:443
Decision: ALLOW (port 443 is allowed)

Rule: Block port 22 (SSH) to internet
Request: 192.168.1.100 → 203.0.113.50:22
Decision: BLOCK (port 22 is blocked)

Common Products

• Palo Alto Networks PA-Series (physical appliance)
• Cisco ASA (physical appliance)
• Fortinet FortiGate (physical appliance)
• AWS Network Firewall (virtual/cloud)
• pfSense (software firewall)

Physical Deployment

[Internet]
    |
[Physical Firewall Appliance] ← Rack-mounted in data center
    |
[Internal Network Switch]
    |
[User Devices]

2. Proxy Server

Physical or virtual device that forwards HTTP/HTTPS requests, can inspect and modify content.

Key Characteristics

Layer: 7 (Application Layer)

Location: On-premises, in DMZ or internal network

Type: Physical appliance or software on server

Purpose: Forward requests, cache content, filter URLs, modify headers

What It Checks

✓ URLs (https://api.example.com/data)
✓ HTTP headers (Authorization, Content-Type)
✓ Request/response content
✓ Can cache static content
✓ Can modify headers

Requires: Client configuration (explicit proxy setting)

Example Actions

Request: GET https://api.example.com/data
Proxy checks:
1. Is this URL allowed? ✓
2. Is content cached? ✗
3. Forward to server
4. Receive response with CORS headers
5. Apply policy: Remove Access-Control-Allow-Origin
6. Forward modified response to client

Common Products

• Squid (software on Linux server)
• Blue Coat ProxySG (physical appliance)
• Nginx (software proxy)
• HAProxy (software proxy)
• Microsoft Forefront TMG (software)

Physical Deployment

[Internet]
    |
[Firewall]
    |
[Proxy Server] ← Physical server or VM in DMZ
    |
[Internal Network]
    |
[User Devices]

Client Configuration Required

Browser settings:

HTTP Proxy: proxy.company.com:8080
HTTPS Proxy: proxy.company.com:8080

Or PAC file:

Automatic proxy configuration URL:
http://proxy.company.com/proxy.pac

3. Secure Web Gateway (SWG)

Cloud-based service that provides advanced security inspection, DLP, and threat protection.

Key Characteristics

Layer: 7 (Application Layer)

Location: Cloud (vendor’s data center)

Type: Cloud service (SaaS) - NOT a physical device

Purpose: Security inspection, DLP, malware protection, header filtering

What It Checks

✓ Everything proxy does
✓ SSL/TLS inspection (always enabled)
✓ Malware scanning
✓ Data Loss Prevention (DLP)
✓ Advanced threat detection
✓ Header modification based on security policy
✓ Content filtering
✓ Shadow IT detection

No client configuration needed (transparent)

Example Actions

Request: GET https://api.example.com/data
SWG inspects:
1. Decrypt HTTPS (SSL inspection)
2. Check URL against threat database
3. Scan for malware
4. Check DLP policies (sensitive data?)
5. Forward to server
6. Receive response
7. Scan response for threats
8. Apply security policy: Remove CORS headers
9. Re-encrypt with corporate certificate
10. Forward to client

Common Products

• Zscaler Internet Access (ZIA)
• Cisco Umbrella
• Palo Alto Prisma Access
• Netskope
• Forcepoint Web Security

Deployment (No Physical Device)

[User Device with Agent]
    |
[Local Network]
    |
[Internet]
    |
[SWG Cloud Service] ← Vendor's cloud infrastructure
    |
[Destination Server]

Deployment Methods

Method 1: Agent-Based

1. Install Zscaler/Cisco agent on laptop
2. Agent intercepts all HTTP/HTTPS traffic
3. Agent tunnels traffic to SWG cloud
4. SWG inspects and forwards
5. Response comes back through SWG

Method 2: PAC File

1. Browser configured with PAC file URL
2. PAC file JavaScript decides routing
3. Browser sends traffic to SWG cloud
4. SWG inspects and forwards

Method 3: GRE Tunnel

1. On-premises firewall creates GRE tunnel to SWG
2. All outbound traffic routed through tunnel
3. SWG receives, inspects, forwards
4. Transparent to end users

Comparison Table

Traffic Flow Examples

Scenario 1: Traditional Enterprise (Firewall + Proxy)

User's Laptop
    ↓
1. Network Firewall
   - Layer 3-4 check
   - Is port 443 allowed? ✓
   - Allow connection
    ↓
2. Proxy Server
   - Layer 7 inspection
   - Check URL: api.example.com/data
   - Forward to internet
    ↓
3. Internet
    ↓
4. Destination Server (api.example.com)
   - Processes request
   - Returns: HTTP/1.1 200 OK
   - Access-Control-Allow-Origin: https://mysite.com
    ↓
5. Response back through proxy
    ↓
6. Proxy Server
   - Applies policy
   - Removes: Access-Control-Allow-Origin
   - Forwards modified response
    ↓
7. Network Firewall
   - Allows return traffic
    ↓
8. User's Laptop
   - Receives: HTTP/1.1 200 OK (no CORS headers)
   - Browser: CORS error!

Scenario 2: Modern Enterprise (Firewall + SWG)

User's Laptop (with SWG agent)
    ↓
1. Network Firewall
   - Layer 3-4 check
   - Allow port 443
    ↓
2. SWG Agent
   - Intercepts traffic
   - Tunnels to SWG cloud
    ↓
3. Internet → SWG Cloud Service
   - SSL Inspection (decrypt HTTPS)
   - Malware scanning
   - DLP check
   - URL filtering
   - Header modification
    ↓
4. SWG → Destination Server
   - Forwards request
    ↓
5. Server Response → SWG
   - HTTP/1.1 200 OK
   - Access-Control-Allow-Origin: https://mysite.com
    ↓
6. SWG Inspection
   - Scans for malware
   - Checks DLP policies
   - Applies security policy
   - Removes: Access-Control-Allow-Origin
   - Re-encrypts with corporate certificate
    ↓
7. SWG → User's Laptop
   - Modified response (no CORS headers)
    ↓
8. User's Laptop
   - Browser: CORS error!

Scenario 3: Full Stack (Firewall + Proxy + SWG)

User's Laptop
    ↓
1. Network Firewall (perimeter)
   - Layer 3-4: Allow port 443
    ↓
2. On-Premises Proxy (legacy)
   - Basic URL filtering
   - Forwards to SWG
    ↓
3. Internet → SWG Cloud
   - Advanced security inspection
   - SSL decryption
   - Malware/DLP scanning
   - Header modification
    ↓
4. SWG → Destination Server
    ↓
5. Response Path (reverse order)
   Server → SWG → Proxy → Firewall → Laptop
   
Each layer can modify/inspect the response

Which Device Removes CORS Headers?

Network Firewall

Can remove CORS headers? ❌ No

Reason: Operates at Layer 3-4
Cannot see HTTP headers
Only sees IP addresses and ports

Proxy Server

Can remove CORS headers? ✅ Yes

Condition: If SSL inspection is enabled
How common: Uncommon (usually not configured to strip CORS)
Configuration: Manual rules required

Secure Web Gateway

Can remove CORS headers? ✅ Yes

Condition: Always (SSL inspection always enabled)
How common: Very common (default security policy)
Configuration: Policy-driven, often automatic

Why SWG Removes CORS Headers

1. Prevent Data Exfiltration

Scenario: Malicious site tries to steal corporate data

Without SWG:
evil.com → fetch('https://internal-api.company.com/secrets')
         ← Access-Control-Allow-Origin: *
         ← {"secret": "confidential data"}
         → Data stolen!

With SWG:
evil.com → fetch('https://internal-api.company.com/secrets')
         → SWG strips CORS headers
         ← No Access-Control-Allow-Origin
         → Browser blocks access ✓

2. Enforce Security Policy

Corporate policy: "Only approved origins can make API calls"

SWG implementation:
- Whitelist: console.aws.amazon.com, portal.azure.com
- All other origins: Strip CORS headers
- Result: Browser enforces same-origin policy

3. Compliance Requirements

Regulation: "Prevent unauthorized cross-origin data access"

SWG enforcement:
- Remove CORS headers by default
- Require explicit approval for exceptions
- Audit all cross-origin requests

How to Detect Which Device is Blocking

1. Check Certificate

# In browser, click padlock icon → View certificate

If you see:
Issued by: Zscaler Root CA → SWG is inspecting
Issued by: Cisco Umbrella → SWG is inspecting
Issued by: Company Proxy CA → Proxy is inspecting
Issued by: Let's Encrypt → No inspection (direct connection)

2. Test with curl

# Direct connection (bypasses proxy/SWG if not configured)
curl -v https://api.example.com

# Check response headers
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: https://mysite.com

# If curl shows header but browser doesn't
# → Proxy or SWG is stripping it

3. Test Outside Corporate Network

Inside corporate network:
- Browser: CORS error
- Network tab: No Access-Control-Allow-Origin

Outside corporate network (home WiFi):
- Browser: Success
- Network tab: Access-Control-Allow-Origin present

→ Corporate proxy/SWG is the cause

4. Check Network Configuration

# macOS
System Settings → Network → Advanced → Proxies

# Windows  
Settings → Network & Internet → Proxy

# Look for:
Web Proxy (HTTP): proxy.company.com:8080 → Explicit proxy
Automatic proxy configuration: http://pac.company.com/proxy.pac → PAC file

Physical vs Cloud Deployment

Network Firewall

Type: Physical appliance or VM
Location: On-premises data center
Deployment: Rack-mounted hardware or hypervisor
Management: On-site or remote admin

Proxy Server

Type: Physical server, VM, or software
Location: On-premises (DMZ or internal network)
Deployment: Server hardware or virtual machine
Management: On-site or remote admin

Secure Web Gateway

Type: Cloud service (SaaS)
Location: Vendor's cloud infrastructure (globally distributed)
Deployment: No physical device at customer site
Management: Web-based portal

Modern Trend

Companies are replacing on-premises proxy with cloud SWG:

Old Architecture

User → Firewall → Proxy Server → Internet
       (on-prem)  (on-prem)

New Architecture

User → Firewall → SWG Cloud → Internet
       (on-prem)  (cloud service)

Benefits

• No hardware to maintain
• Global presence (low latency)
• Always up-to-date threat intelligence
• Scales automatically
• Works for remote users (no VPN needed)

Technical Terms

• Layer 3-4 (Network/Transport): IP addresses, TCP/UDP ports, protocols
• Layer 7 (Application): HTTP, HTTPS, URLs, headers, content
• DMZ (Demilitarized Zone): Network segment between internet and internal network
• SSL/TLS Inspection: Decrypt HTTPS traffic to inspect content
• SSL Termination: Proxy decrypts HTTPS, inspects, re-encrypts
• PAC File (Proxy Auto-Config): JavaScript file that routes traffic to proxy
• GRE Tunnel: Generic Routing Encapsulation - encrypted tunnel between networks
• Agent-Based: Software installed on endpoint device to route traffic
• Transparent Proxy: Traffic automatically redirected without user configuration
• Explicit Proxy: User must configure proxy settings in browser/OS
• DLP (Data Loss Prevention): Prevent sensitive data from leaving network
• SaaS (Software as a Service): Cloud-based software accessed via internet

Key Takeaways

1. Network Firewall operates at Layer 3-4, cannot see or modify HTTP headers
2. Proxy Server operates at Layer 7, can modify headers if SSL inspection enabled
3. SWG operates at Layer 7 in the cloud, always inspects and commonly removes CORS headers
4. Traffic order: User → Firewall → Proxy/SWG → Internet → Server
5. Physical devices: Firewall and Proxy are on-premises, SWG is cloud service
6. CORS header removal: Only Proxy and SWG can do this, SWG does it most commonly
7. Modern trend: Moving from on-premises proxy to cloud SWG for better security
8. Detection: Check certificate issuer, test with curl, compare inside/outside corporate network