Networking

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.

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.

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

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.

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.

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.

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

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

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.