infisical/docs/documentation/platform/gateways/networking.mdx

---
title: "Networking Requirements"
description: "Network configuration and firewall requirements for Infisical Gateways and Relays"
---

This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway and relay usage.

## Network Architecture

The gateway system uses SSH reverse tunnels to establish secure connections with end-to-end encryption:

1. **Gateway** connects outbound to **Relay Servers** using SSH over TCP
2. **Infisical platform** establishes mTLS connections with gateways for application traffic
3. **Relay Servers** route the doubly-encrypted traffic (mTLS payload within SSH tunnels) between the platform and gateways
4. **Double encryption** ensures relay servers cannot access application data - only the platform and gateway can decrypt traffic

## Gateway Network Requirements

### Outbound Connections (Required)

The gateway requires the following outbound connectivity:

| Protocol | Destination                          | Ports | Purpose                                    |
| -------- | ------------------------------------ | ----- | ------------------------------------------ |
| TCP      | Relay Servers                        | 2222  | SSH reverse tunnel establishment           |
| TCP      | app.infisical.com / eu.infisical.com | 443   | API communication and certificate requests |

### Relay Server Connectivity

**For Instance Relays (Infisical Cloud):** Your firewall must allow outbound connectivity to Infisical-managed relay servers.

**For Organization Relays:** Your firewall must allow outbound connectivity to your own relay server IP addresses or hostnames.

**For Self-hosted Instance Relays:** Your firewall must allow outbound connectivity to relay servers configured by your instance administrator.

<Tabs>
  <Tab title="Instance Relays (Infisical Cloud)">
    Infisical provides multiple managed relay servers with static IP addresses.
    You can whitelist these IPs ahead of time based on which relay server you
    choose to connect to. **Firewall requirements:** Allow outbound TCP
    connections to the desired relay server IP on port 2222.
  </Tab>
  <Tab title="Organization Relays">
    You control the relay server IP addresses or hostnames when deploying your
    own organization relays. **Firewall requirements:** Allow outbound TCP
    connections to your relay server IP or hostname on port 2222. For example,
    if your relay is at `203.0.113.100` or `relay.example.com`, allow TCP to
    `203.0.113.100:2222` or `relay.example.com:2222`.
  </Tab>
  <Tab title="Self-hosted Instance Relays">
    Contact your instance administrator for the relay server IP addresses or
    hostnames configured for your deployment. **Firewall requirements:** Allow
    outbound TCP connections to instance relay servers on port 2222.
  </Tab>
</Tabs>

## Relay Server Network Requirements

### Inbound Connections (Required)

The relay server must accept the following inbound connections:

| Protocol | Source             | Port | Purpose                          |
| -------- | ------------------ | ---- | -------------------------------- |
| TCP      | Gateways           | 2222 | SSH reverse tunnel establishment |
| TCP      | Infisical Platform | 8443 | Platform-to-relay communication  |

### Outbound Connections (Required)

The relay server requires outbound connectivity to:

| Protocol | Destination                          | Port | Purpose                                    |
| -------- | ------------------------------------ | ---- | ------------------------------------------ |
| TCP      | app.infisical.com / eu.infisical.com | 443  | API communication and certificate requests |

## Firewall Configuration

### Gateway Firewall Rules

Since gateways only make outbound connections, you only need simple outbound rules:

1. **Allow outbound TCP** to relay servers (IP addresses or hostnames) on port 2222
2. **Allow outbound HTTPS** to Infisical API endpoints on port 443
3. **No inbound rules required** - all connections are outbound only

### Relay Firewall Rules

Configure your firewall to allow:

1. **SSH on port 2222** - For gateway connections

   ```bash
   # Example iptables rule
   iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
   ```

2. **TCP with TLS on port 8443** - For platform connections

   ```bash
   # Example iptables rule
   iptables -A INPUT -p tcp --dport 8443 -j ACCEPT
   ```

3. **HTTPS to Infisical API** - For certificate requests and API communication
   ```bash
   # Example iptables rule
   iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT
   ```

## Cloud Provider Configuration

### AWS EC2

Configure security groups:

```json
{
  "SecurityGroupRules": [
    {
      "IpProtocol": "tcp",
      "FromPort": 2222,
      "ToPort": 2222,
      "CidrIpv4": "0.0.0.0/0",
      "Description": "SSH for gateway connections"
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 8443,
      "ToPort": 8443,
      "CidrIpv4": "0.0.0.0/0",
      "Description": "TCP with TLS for platform connections"
    }
  ]
}
```

### Google Cloud Platform

Configure firewall rules:

```bash
# Allow SSH from gateways
gcloud compute firewall-rules create allow-gateway-ssh \
  --allow tcp:2222 \
  --source-ranges 0.0.0.0/0 \
  --description "Allow SSH from gateways"

# Allow TCP with TLS from platform
gcloud compute firewall-rules create allow-platform-tls \
  --allow tcp:8443 \
  --source-ranges 0.0.0.0/0 \
  --description "Allow TCP with TLS from platform"
```

### Azure

Configure Network Security Groups:

```json
{
  "securityRules": [
    {
      "name": "AllowGatewaySSH",
      "properties": {
        "protocol": "Tcp",
        "sourcePortRange": "*",
        "destinationPortRange": "2222",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "*",
        "access": "Allow",
        "priority": 100,
        "direction": "Inbound"
      }
    },
    {
      "name": "AllowPlatformTLS",
      "properties": {
        "protocol": "Tcp",
        "sourcePortRange": "*",
        "destinationPortRange": "8443",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "*",
        "access": "Allow",
        "priority": 110,
        "direction": "Inbound"
      }
    }
  ]
}
```

## Protocol Details

### SSH over TCP

The gateway uses SSH reverse tunnels for primary communication:

- **Port 2222**: SSH connection to relay servers
- **Built-in features**: Automatic reconnection, certificate-based authentication, encrypted tunneling
- **Encryption**: SSH with certificate-based authentication and key exchange

### TCP Connection Handling

SSH connections over TCP are stateful and handled seamlessly by all modern firewalls:

- **Established connections** are automatically tracked
- **Return traffic** is allowed for established outbound connections
- **No special configuration** needed for connection tracking
- **Standard SSH protocol** that enterprise firewalls handle well

## Common Network Scenarios

### Corporate Firewalls

For corporate environments with strict egress filtering:

1. **Allow outbound TCP** to relay servers (IP addresses or hostnames) on port 2222
2. **Allow outbound HTTPS** to the Infisical API server on port 443
3. **No inbound rules required** - all connections are outbound only
4. **Standard TCP rules** - simple and straightforward configuration

### Cloud Environments (AWS/GCP/Azure)

Configure security groups to allow:

- **Outbound TCP** to relay servers (IP addresses or hostnames) on port 2222
- **Outbound HTTPS** to app.infisical.com/eu.infisical.com on port 443
- **No inbound rules required** - SSH reverse tunnels are outbound only

## Performance Considerations

### Network Optimization

- **Deploy close to gateways** - Reduce latency by placing relay servers geographically close to your gateways
- **Use high-bandwidth connections** - Ensure adequate bandwidth for encrypted traffic
- **Monitor network performance** - Track latency and throughput metrics
- **Consider multiple relays** - Deploy multiple relay servers for redundancy and load distribution

## Frequently Asked Questions

<Accordion title="What happens if there is a network interruption?">
The gateway is designed to handle network interruptions gracefully:

- **Automatic reconnection**: The gateway will automatically attempt to reconnect to relay servers if the SSH connection is lost
- **Connection retry logic**: Built-in retry mechanisms handle temporary network outages without manual intervention
- **Persistent SSH tunnels**: SSH connections are automatically re-established when connectivity is restored
- **Certificate rotation**: The gateway handles certificate renewal automatically during reconnection
- **Graceful degradation**: The gateway logs connection issues and continues attempting to restore connectivity

No manual intervention is typically required during network interruptions.

</Accordion>

<Accordion title="Why does the gateway use SSH over TCP?">
SSH over TCP provides several advantages for enterprise gateway communication:

- **Firewall-friendly**: TCP is stateful and handled seamlessly by all enterprise firewalls
- **Standard protocol**: SSH is a well-established protocol that network teams are familiar with
- **Certificate-based security**: Uses SSH certificates for strong authentication without shared secrets
- **Automatic tunneling**: SSH reverse tunnels handle all the complexity of secure communication
- **Enterprise compatibility**: Works reliably across all enterprise network configurations

TCP's reliability and firewall compatibility make it ideal for enterprise environments where network policies are strictly managed.

</Accordion>

<Accordion title="Do I need to open any inbound ports on my firewall?">
No inbound ports need to be opened for gateways. The gateway only makes outbound connections:

- **Outbound SSH** to relay servers on port 2222
- **Outbound HTTPS** to Infisical API endpoints on port 443
- **SSH reverse tunnels** handle all communication - no return traffic configuration needed

This design maintains security by avoiding the need for inbound firewall rules that could expose your network to external threats.

</Accordion>

<Accordion title="What if my firewall blocks SSH connections?">
If your firewall has strict outbound restrictions:

1. **Work with your network team** to allow outbound TCP connections on port 2222 to relay servers (IP addresses or hostnames)
2. **Allow standard SSH traffic** - most enterprises already have SSH policies in place
3. **Consider network policy exceptions** for the gateway host if needed
4. **Monitor firewall logs** to identify which specific rules are blocking traffic

</Accordion>

<Accordion title="How many relay servers does the gateway connect to?">
The gateway connects to **one relay server**:

- **Single SSH connection**: Each gateway establishes one SSH reverse tunnel to its assigned relay server
- **Named relay assignment**: Gateways connect to the specific relay server specified by `--relay`
- **Automatic reconnection**: If the relay connection is lost, the gateway automatically reconnects to the same relay
- **Certificate-based authentication**: Each connection uses SSH certificates issued by Infisical for secure authentication

</Accordion>

<Accordion title="Can the relay servers decrypt traffic going through them?">
No, relay servers cannot decrypt any traffic passing through them due to end-to-end encryption:

- **Client-to-Gateway mTLS (via TLS-pinned tunnel)**: Clients connect via a proxy that establishes a TLS-pinned tunnel to the gateway; mTLS between the client and gateway is negotiated inside this tunnel, encrypting all application traffic
- **SSH tunnel encryption**: The mTLS-encrypted traffic is then transmitted through SSH reverse tunnels to relay servers
- **Double encryption**: Traffic is encrypted twice - once by client mTLS and again by SSH tunnels
- **Relay only routes traffic**: The relay server only routes the doubly-encrypted traffic without access to either encryption layer
- **No data storage**: Relay servers do not store any traffic or sensitive information
- **Certificate isolation**: Each connection uses unique certificates, ensuring complete tenant isolation

The relay infrastructure is designed as a secure routing mechanism where only the client and gateway can decrypt the actual application traffic.

</Accordion>