Networking
Network configuration and firewall requirements for Infisical Gateway
The Infisical Gateway requires outbound network connectivity to establish secure communication with Infisical’s relay infrastructure. This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway usage.
Network Architecture
The gateway uses a relay-based architecture to establish secure connections:
- Gateway connects outbound to Relay Servers using UDP/QUIC protocol
- Relay Servers facilitate secure communication between Gateway and Infisical Cloud
- All traffic is end-to-end encrypted using mutual TLS over QUIC
Required Network Connectivity
Outbound Connections (Required)
The gateway requires the following outbound connectivity:
| Protocol | Destination | Ports | Purpose |
|---|---|---|---|
| UDP | Relay Servers | 49152-65535 | Allocated relay communication (TLS) |
| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and relay allocation |
Relay Server IP Addresses
Your firewall must allow outbound connectivity to the following Infisical relay servers on dynamically allocated ports.
Please contact your Infisical account manager for dedicated relay server IP addresses.
These IP addresses are static and managed by Infisical. Any changes will be communicated with 60-day advance notice.
Protocol Details
QUIC over UDP
The gateway uses QUIC (Quick UDP Internet Connections) for primary communication:
- Port 5349: STUN/TURN over TLS (secure relay communication)
- Built-in features: Connection migration, multiplexing, reduced latency
- Encryption: TLS 1.3 with certificate pinning
Understanding Firewall Behavior with UDP
Unlike TCP connections, UDP is a stateless protocol, and depending on your organization’s firewall configuration, you may need to adjust network rules accordingly. When the gateway sends UDP packets to a relay server, the return responses need to be allowed back through the firewall. Modern firewalls handle this through “connection tracking” (also called “stateful inspection”), but the behavior can vary depending on your firewall configuration.
Connection Tracking
Modern firewalls automatically track UDP connections and allow return responses. This is the preferred configuration as it:
- Automatically handles return responses
- Reduces firewall rule complexity
- Avoids the need for manual IP whitelisting
In the event that your firewall does not support connection tracking, you will need to whitelist the relay IPs to explicitly define return traffic manually.
Common Network Scenarios
Corporate Firewalls
For corporate environments with strict egress filtering:
- Whitelist relay IP addresses (listed above)
- Allow UDP port 5349 outbound
- Configure connection tracking for UDP return traffic
- Allow ephemeral port range 49152-65535 for return traffic if connection tracking is disabled
Cloud Environments (AWS/GCP/Azure)
Configure security groups to allow:
- Outbound UDP to relay IPs on port 5349
- Outbound HTTPS to app.infisical.com/eu.infisical.com on port 443
- Inbound UDP on ephemeral ports (if not using stateful rules)
Frequently Asked Questions
What happens if there is a network interruption?
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 every 5 seconds if the connection is lost
- Connection retry logic: Built-in retry mechanisms handle temporary network outages without manual intervention
- Multiple relay servers: If one relay server is unavailable, the gateway can connect to alternative relay servers
- Persistent sessions: Existing connections are maintained where possible during brief network interruptions
- 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 QUIC instead of TCP?
Why does the gateway use QUIC instead of TCP?
QUIC (Quick UDP Internet Connections) provides several advantages over traditional TCP for gateway communication:
- Faster connection establishment: QUIC combines transport and security handshakes, reducing connection setup time
- Built-in encryption: TLS 1.3 is integrated into the protocol, ensuring all traffic is encrypted by default
- Connection migration: QUIC connections can survive IP address changes (useful for NAT rebinding)
- Reduced head-of-line blocking: Multiple data streams can be multiplexed without blocking each other
- Better performance over unreliable networks: Advanced congestion control and packet loss recovery
- Lower latency: Optimized for real-time communication between gateway and cloud services
While TCP is stateful and easier for firewalls to track, QUIC’s performance benefits outweigh the additional firewall configuration requirements.
Do I need to open any inbound ports on my firewall?
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 UDP to relay servers on ports 49152-65535
- Outbound HTTPS to Infisical API endpoints
- Return responses are handled by connection tracking or explicit IP whitelisting
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 the required UDP ports?
What if my firewall blocks the required UDP ports?
If your firewall has strict UDP restrictions:
- Work with your network team to allow outbound UDP to the specific relay IP addresses
- Use explicit IP whitelisting if connection tracking is disabled
- Consider network policy exceptions for the gateway host
- Monitor firewall logs to identify which specific rules are blocking traffic
The gateway requires UDP connectivity to function - TCP-only configurations are not supported.
How many relay servers does the gateway connect to?
How many relay servers does the gateway connect to?
The gateway connects to one relay server at a time:
- Single active connection: Only one relay connection is established per gateway instance
- Automatic failover: If the current relay becomes unavailable, the gateway will connect to an alternative relay
- Load distribution: Different gateway instances may connect to different relay servers for load balancing
- No manual selection: The Infisical API automatically assigns the optimal relay server based on availability and proximity
You should whitelist all relay IP addresses to ensure proper failover functionality.
Can the relay servers decrypt traffic going through them?
Can the relay servers decrypt traffic going through them?
No, relay servers cannot decrypt any traffic passing through them:
- End-to-end encryption: All traffic between the gateway and Infisical Cloud is encrypted using mutual TLS with certificate pinning
- Relay acts as a tunnel: The relay server only forwards encrypted packets - it has no access to encryption keys
- No data storage: Relay servers do not store any traffic or network-identifiable information
- Certificate isolation: Each organization has its own private PKI system, ensuring complete tenant isolation
The relay infrastructure is designed as a secure forwarding mechanism, similar to a VPN tunnel, where the relay provider cannot see the contents of the traffic flowing through it.