Beginner question: Do I need to open firewall ports for this to work?

This is an excellent foundational question that gets to the core of how Perimeter 81 operates, and it's a common point of confusion when transitioning from traditional on-premise network security models to a Zero Trust Network Access (ZTNA) framework. The short answer is **no, you typically do not need to open inbound firewall ports on your internal resources for Perimeter 81 to function.** In fact, a core benefit of the solution is the elimination of that very requirement.

To understand why, it's critical to contrast the traditional model with the ZTNA agent-initiated model Perimeter 81 employs.

**Traditional VPN/Port-Forwarding Model:**
* Internal servers (e.g., a database, CRM, file server) must have specific inbound ports (like 443, 22, 3389) opened on the corporate firewall.
* These open ports are continuously probed by malicious actors.
* The network perimeter is defined by this firewall, and once a user is VPN-connected, they are often trusted broadly within the network (the "castle-and-moat" problem).

**Perimeter 81 ZTNA Model:**
* Your internal resources **should not and do not** accept direct inbound connections from the internet. Their firewall rules should deny all inbound traffic from external IPs.
* Instead, the Perimeter 81 Connector (a lightweight service you install within your network, e.g., on a VM) establishes an **outbound, encrypted tunnel** to the Perimeter 81 cloud.
* User devices run the Perimeter 81 application. When a user requests access to a resource, their app connects to the Perimeter 81 cloud, which in turn brokers a connection through the pre-established tunnel from the Connector.
* The connection flow is always initiated from inside your network (the Connector) or by the user app to the cloud. No unsolicited inbound traffic reaches your servers.

Therefore, your firewall configuration for the servers hosting your internal applications should look something like this, effectively making them invisible to direct external access:

```yaml
# Example Ideal Firewall Rule Set for Internal Resource (Conceptual)
- Rule 1: DENY ALL INBOUND from 0.0.0.0/0 (Internet)
- Rule 2: ALLOW INBOUND from [Connector_IP_Range] on port [App_Port] # If Connector is on a separate host
- Rule 3: ALLOW INBOUND from [Same_Security_Group/Subnet] on port [App_Port] # For internal east-west traffic
```

The key configuration work shifts from managing static firewall port rules to defining **policies** within the Perimeter 81 platform. These policies specify:
* Which user identities (or groups) can access which applications.
* Under what context (device posture, location, time).
* The application is defined by its private IP and port, reachable by the Connector.

The only potential exception to the "no open ports" rule might be if you are using Perimeter 81 in a specific "Serverless" mode for a single publicly-hosted resource, but even that manages access at the application layer rather than the network layer. For the vast majority of use cases—securing private data centers, AWS/Azure VPCs, or internal SaaS tools—the agent-initiated tunnel model renders the act of opening inbound firewall ports obsolete and significantly reduces your attack surface.

— Amanda