Firewall Failures

Firewall, NAT, and Routing Issues

Twingate is designed to work without any inbound firewall rules - a major security advantage. However, it has specific outbound connectivity requirements, and its performance is highly dependent on the nature of the Network Address Translation (NAT) in front of both the Client and the Connector.

The difference between a faster, lower-latency connection and a slow one often comes down to one thing: whether the connection is Peer-to-Peer (P2P) or Relay-based. A P2P connection is a direct, encrypted tunnel between the Client and the Connector. A relayed connection means the traffic is being routed through Twingate’s public Relay infrastructure because a direct connection couldn’t be established. While secure and reliable, a relayed connection will sometimes have higher latency than a direct one. Diagnosing performance issues is therefore a process of diagnosing why a P2P connection is failing.

Common Symptoms:

• Users report that accessing Resources over Twingate is “slow” or “laggy.”
• In the Admin Console, the connection details for a Connector show that most or all connections are “Relayed.”
• The Client or Connector fails to connect to the Twingate network entirely.

How to Identify and Troubleshoot:

• Verify Outbound Firewall Rules: Both Clients and Connectors must be able to make outbound connections. Ensure that firewalls on both the user’s network and the Connector’s network allow outbound traffic to:
  • *.twingate.com on TCP port 443 (for communication with the Controller and Relays).
  • Twingate’s Relay infrastructure on TCP ports 30000-31000. This is the fallback for relayed connections.
  • All destinations on UDP. This is the most critical requirement for P2P connections and NAT traversal. Overzealous firewalls that block outbound UDP are the #1 cause of relayed connections and performance issues.
• Troubleshoot NAT Traversal Failures: If connections are being relayed, it’s because P2P failed.
  • Check for Blocked UDP/QUIC: The first suspect is always a firewall blocking outbound UDP. You can test this from the Connector host using a tool like nmap against a public test port.
  • Check for Incompatible NAT: NAT traversal requires a specific type of NAT known as “endpoint-independent NAT.” Most consumer routers use this, but some enterprise-grade firewalls or certain cloud NAT configurations can be incompatible (“symmetric NAT”). A “double NAT” scenario (where a device is behind two layers of routers) can also break P2P connections.
  • AWS NAT Gateway: The standard AWS NAT Gateway product is known to be incompatible with the requirements for robust NAT traversal in some situations. For deployments in AWS where P2P performance is critical, Twingate recommends using an alternative, such as a self-hosted NAT instance on an EC2 virtual machine or a third-party NAT product from the AWS Marketplace.
  • Confirm in the Admin Console: The Connector details page will indicate if STUN Discovery is “Available,” which is a prerequisite for P2P. If it shows an error or as unavailable then check outbound traffic rules and make sure UDP port 3478 is not blocked.

For more details on troubleshooting peer-to-peer issues, see our guide on How to troubleshoot peer-to-peer connections.

If the network path is clear and connections are performant, but users report strange conflicts with local devices, the issue is likely related to split tunneling.