Merge branch 'main' into dev

manage/endpoints-and-pops.mdx

@@ -0,0 +1,62 @@
+---
+title: "Endpoints & Relays"
+icon: "network-wired"
+description: "Pangolin Cloud hostnames for firewall allowlists and network whitelisting"
+---
+
+import PangolinCloudTocCta from "/snippets/pangolin-cloud-toc-cta.mdx";
+
+<PangolinCloudTocCta />
+
+<Note>
+This page applies to [Pangolin Cloud](https://app.pangolin.net/auth/signup) only. If you self-host Pangolin, see [DNS & Networking](/self-host/dns-and-networking) for the hostnames and ports on your own deployment.
+</Note>
+
+Use this page when you need to allowlist Pangolin in a corporate firewall, proxy, or egress policy. Sites, clients, and browsers connect to two classes of infrastructure on Pangolin Cloud: the **control plane** and **points of presence** (also called relays).
+
+## Control Plane
+
+The control plane is the central Pangolin service that runs the dashboard, REST API, authentication, and configuration orchestration.
+
+| Hostname | Purpose |
+| --- | --- |
+| `app.pangolin.net` | Dashboard, API, authentication, and WebSocket configuration for sites and clients |
+
+Sites and clients use this hostname as their **endpoint**. For example, Sites connect here to register, receive policy, and maintain their control channel.
+
+## Points of Presence
+
+Points of presence (PoPs), also called relays, are the networking edge where sites and clients connect for data traffic.
+
+| Hostname |
+| --- |
+| `uranus.pop.pangolin.net` |
+| `mars.pop.pangolin.net` |
+| `earth.pop.pangolin.net` |
+| `jupiter.pop.pangolin.net` |
+| `saturn.pop.pangolin.net` |
+| `neptune.pop.pangolin.net` |
+| `pluto.pop.pangolin.net` |
+| `mercury.pop.pangolin.net` |
+
+### What PoPs Do
+
+- **Public resources** send all traffic through a PoP.
+- **Private resources** use PoPs to coordinate [NAT traversal](/manage/clients/nat-traversal) between a client and a site. If hole punching fails, traffic relays through the PoP instead.
+
+Pangolin sites and clients automatically select the most optimal PoP to connect to. You do not choose a PoP manually during normal operation.
+
+## Remote Nodes
+
+If you use [remote nodes](/manage/remote-node/understanding-nodes), the point of presence (relay) for your traffic is your self-hosted node, not the cloud PoPs listed above.
+
+The control plane endpoint for dashboard access, API calls, and authentication remains `app.pangolin.net`.
+
+## Whitelisting Checklist
+
+To allow Pangolin Cloud on an outbound firewall or proxy, permit traffic to:
+
+1. `app.pangolin.net` for the control plane
+2. All `*.pop.pangolin.net` hostnames listed above for site and client data traffic
+
+If you use remote nodes, also allow traffic to your remote node's public hostname or IP address.

manage/resources/private/alias.mdx

@@ -35,6 +35,10 @@ Wildcards allow you to define aliases that match multiple hostnames using specia
 
 If you use a wildcard such as `*.proxy.internal`, it will match any hostname that ends with `.proxy.internal` and has something before the dot—such as `host.proxy.internal`, `longerhost.proxy.internal`, or even `sub.host.proxy.internal`. However, the wildcard will not match the base domain itself (`autoco.internal` without anything before the dot).
 
+### .local TLD
+
+The `.local` TLD is reserved for local networking and multicast DNS (mDNS). mDNS is commonly used by Apple Bonjour, Linux zeroconf, and limited Windows features. Because of this, aliases that use `.local` may not resolve reliably across many devices. We recommend using a subdomain you control (for example, `alias.mywebsite.com`) or a private/internal domain such as `alias.internal` or `alias.corp`.
+
 ## Custom Upstream DNS
 
 Aliases work by overriding the DNS of your computer running the client so that all DNS requests are sent to the Pangolin client for resolution. That behavior is controlled by the Enable Aliases (Override DNS) preference; see [Configure Clients](/manage/clients/configure-client#enable-aliases-override-dns). The DNS server on your computer is typically `100.96.128.1` (the first address inside of your utility subnet on the org) when connected to the tunnel, which forwards requests to an upstream server. By default, we use `1.1.1.1`, but this upstream address can be configured in the CLI or in the client settings.