Networking

Network configuration and firewall requirements for Infisical Gateway

The Infisical Gateway requires outbound network connectivity to establish secure SSH reverse tunnels with proxy 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 Proxy Servers using SSH over TCP
2. Infisical platform establishes mTLS connections with gateways for application traffic
3. Proxy Servers route the doubly-encrypted traffic (mTLS payload within SSH tunnels) between the platform and gateways
4. Double encryption ensures proxy 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	Proxy Servers	2222	SSH reverse tunnel establishment
TCP	app.infisical.com / eu.infisical.com	443	API communication and certificate requests

Proxy Server Connectivity

For Instance Proxies (Infisical Cloud): Your firewall must allow outbound connectivity to Infisical-managed proxy servers.

For Organization Proxies: Your firewall must allow outbound connectivity to your own proxy server IP addresses.

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

Instance Proxies (Infisical Cloud)

Infisical provides multiple managed proxy servers with static IP addresses. You can whitelist these IPs ahead of time based on which proxy server you choose to connect to. Firewall requirements: Allow outbound TCP connections to the desired proxy server IP on port 2222.

Organization Proxies

You control the proxy server IP addresses when deploying your own organization proxies. Firewall requirements: Allow outbound TCP connections to your proxy server IP on port 2222. For example, if your proxy is at 203.0.113.100, allow TCP to 203.0.113.100:2222.

Self-hosted Instance Proxies

Contact your instance administrator for the proxy server IP addresses configured for your deployment. Firewall requirements: Allow outbound TCP connections to instance proxy servers on port 2222.

Protocol Details

SSH over TCP

The gateway uses SSH reverse tunnels for primary communication:

• Port 2222: SSH connection to proxy 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 proxy servers 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 proxy servers 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 proxy servers 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 proxy 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 proxy 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 proxy servers
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 proxy servers does the gateway connect to?

The gateway connects to one proxy server:

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

Can the proxy servers decrypt traffic going through them?

No, proxy servers cannot decrypt any traffic passing through them due to end-to-end encryption:

• Client-to-Gateway mTLS: Clients establish mTLS connections directly with gateways, encrypting all application traffic
• SSH tunnel encryption: The mTLS-encrypted traffic is then transmitted through SSH reverse tunnels to proxy servers
• Double encryption: Traffic is encrypted twice - once by client mTLS and again by SSH tunnels
• Proxy acts as a relay: The proxy server only routes the doubly-encrypted traffic without access to either encryption layer
• No data storage: Proxy servers do not store any traffic or sensitive information
• Certificate isolation: Each connection uses unique certificates, ensuring complete tenant isolation

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