[Internal as draft, then public] Peer-to-peer Connection Troubleshooting

Last updated: April 3, 2026

Applicable to:
  • Twingate Component: Data Transport -- Client | Connector

Overview

Twingate has two data transport connection methods, Peer-to-Peer and Relay.

While the former is our preferred method, it is not always possible to establish due to various reasons, ranging from blocked ports to incompatible NAT layers. In those cases, the Client will use Twingate's Relay infrastructure to establish data connectivity to the Connectors.

This article will provide what to look for in terms of firewall and NAT components that can cause peer-to-peer connections to not be negotiated.

Disclaimer - Given the nature of networking infrastructure, there are any number of factors that can affect the execution of peer-to-peer processes and so while we attempt to cover core components that can affect peer-to-peer connections, we cannot make any guarantees. 

 

Prerequisites

For both the Client and Connector(s):

Firewall Rules

    • Any local OS, local OS level security software, upstream firewall, or upstream network inspection/filtering needs to allow outbound connections for ANY UDP port to ANY public IP.
    • No filtering of P2P or QUIC should occur on the either of these levels:
      - OS level firewall
      - any security software that performs network inspection or filtering
      - modem/router L7 filtering
      - upstream security like ISP level filtering
    • Complete firewall rules can be found at...

NAT

  • No double NAT
  • NAT that's using Endpoint Independent Mapping (EIM NAT). When using an EIM NAT, the same external IP and port are utilized for all connections originating from a host, provided that the host employs the same internal port. This setup facilitates peer-to-peer connectivity, allowing data to reach its intended endpoint seamlessly without the NAT IP and port changing. Refer to the Further Reading section below, for more information. 
  • Hairpin NAT Devices. Likely required when a Client + Connector are on the same local network.
  • Non-AWS Nat Gateway
    • AWS NAT Gateway currently doesn't support NAT traversal, meaning peer-to-peer connections cannot be established when connectors are deployed behind them.
    • Instead, Twingate connectors should be placed in public subnets, behind an Internet Gateway. More information around AWS Internet Gateways can be found in the User Guide > Internet Gateways section of their Amazon VPC docs.

Further Reading

Good resources for learning about NAT Traversal include the Network address translation wikipedia page and the Tailscale How NAT traversal works blog post. As SEs/Bren on Tailscale link. It's a great resource, just kind of weird with competitor. Dmitry and Bren write their own?

*STUN learning article

 

Determining NAT Type

Third party tool - pystun3

There are open source free tools available, such as pystun3 https://github.com/talkiq/pystun3, for determining NAT type.

The only prerequisite for the tool is having python3 installed on the system. After which pystun3 can be installed with:

pip install pystun3

Once run, it will output the NAT type and IP/Port info like so:

> pystun3
NAT Type: Full Cone
External IP: x.x.x.x
External Port: 54320

A Full Cone NAT types use EIM and so are peer-to-peer friendly. Refer to the Further Reading section above, for more information.

Remember that the NATs in front of the Client and the Connector have to have peer-to-peer friendly for a direct connection to be established.

Note about how STUN will test to see if the IP and port mappings are detected. If the external port changes, the NAT type won't be returned as EIM. verbiage here is ehhh cause aaron

 

### insert what TG Connector and Client logs look like with notes they may not log continuously.