@@ -122,3 +122,48 @@ originate. Using these internal addresses is much more likely to result in a
122122successful direct connection.
123123
124124![ Diagram of a workspace agent and client over VPN] ( ../images/networking/stun3.png )
125+
126+ ##Hard NAT
127+
128+ Some NATs are known to use a different port when forwarding requests to the STUN
129+ server and when forwarding probe packets to peers. In that case, the address a
130+ peer discovers over the STUN protocol will have the correct IP address, but the
131+ wrong port. Tailscale refers to this as "hard" NAT in
132+ [ How NAT traversal works (tailscale.com)] ( https://tailscale.com/blog/how-nat-traversal-works ) .
133+
134+ It can block direct connections if the other peer is also behind a "hard" NAT or
135+ is running a firewall (including Windows Defender Firewall). Peers fallback to
136+ DERP connections if they cannot establish a direct connection.
137+
138+ If your workspaces are behind a "hard" NAT, you can:
139+
140+ 1 . Ensure clients are not also behind a "hard" NAT. (You may have limited
141+ ability to control this if end users connect from their homes.
142+ 2 . Ensure firewalls on client devices (e.g. Windows Defender Firewall) have an
143+ inbound policy allowing all UDP ports either to the` coder ` or` coder.exe `
144+ CLI binary, or from the IP address(es) of your workspace NAT(s).
145+ 3 . Reconfigure your workspace network's NAT connection to the public internet to
146+ be an "easy" NAT. See below for specific examples.
147+
148+ ###AWS NAT Gateway
149+
150+ The
151+ [ AWS NAT Gateway] ( https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html )
152+ is a known "hard" NAT. You can use a
153+ [ NAT Instance] ( https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html )
154+ instead of a NAT Gateway, and configure it to use the same port assignment for
155+ all UDP traffic from a particular source IP: port combination (Tailscale calls
156+ this "easy" NAT). Linux` MASQUERADE ` rules work well for this.
157+
158+ ###AWS Elastic Kubernetes Service (EKS)
159+
160+ The default configuration of AWS Elastic Kubernetes Service (EKS) includes the
161+ [ Amazon VPC CNI Driver] ( https://github.com/aws/amazon-vpc-cni-k8s ) , which by
162+ default randomizes the public port for different outgoing UDP connections,
163+ making it also act as a "hard" NAT, even if the EKS nodes are on a public subnet
164+ (and thus do not need to use the AWS NAT Gateway to reach the Internet). This
165+ behavior can be disabled by setting the environment variable
166+ ` AWS_VPC_K8S_CNI_RANDOMIZESNAT=none ` in the` aws-node ` DaemonSet. Note, however,
167+ if your nodes are on a private subnet, they will still need NAT to reach the
168+ public Internet, meaning that issues with the
169+ [ AWS NAT Gateway] ( #aws-nat-gateway ) might affect you.