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

---
title: "Networking"
description: "Network configuration and firewall requirements for Infisical Gateway"
---

The Infisical Gateway requires outbound network connectivity to establish secure SSH reverse tunnels with relay servers.
This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway usage.

## Network Architecture

The gateway 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

## Required Network Connectivity

### 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>

## 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

## Firewall Configuration for SSH

The gateway uses standard SSH over TCP, making firewall configuration straightforward.

### 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

### Simplified Firewall Rules

Since SSH uses TCP, 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

## 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

## 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. 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>