As someone who primarily operates in the realm of product analytics and A/B testing infrastructure, my core requirement for any new security or networking tool is that its integration must be non-disruptive to existing production systems. The prospect of reconfiguring firewall rules, especially on a live application server handling continuous experiment traffic, introduces an unacceptable variable into my controlled environment.
Therefore, my primary question for the community regarding Perimeter 81 is one of initial deployment methodology. From a technical standpoint, can a complete novice—with administrative rights but minimal networking expertise—evaluate the platform end-to-end without making a single alteration to their existing physical or software firewall rules (e.g., on a Ubiquiti EdgeRouter, pfSense, or Windows Defender Firewall)?
I am particularly interested in the mechanics of the initial agent-based connection. My hypothesis is that the agent establishes an outbound-only connection to Perimeter 81's cloud, thus not requiring *inbound* firewall rules. However, I seek confirmation and granular detail on the following points:
* **Connection Initiation:** Does all traffic from the agent initiate as an outbound connection on a standard HTTPS port (443), effectively bypassing the common need to open specific inbound ports like 500/4500 for traditional IPSec VPNs?
* **Network Location Awareness:** If I install the agent on a Windows machine that is, for instance, on a corporate domain network with strict group policies, will it attempt to modify the local firewall profile (Domain, Private, Public) settings?
* **Gateway/Resolver Implications:** Upon connecting to a Perimeter 81 network, does the agent override the local DNS resolver? If so, is this achieved purely through a local virtual adapter configuration, or could it be perceived as a system-level change that might trigger security software?
To illustrate the level of specificity I find helpful, here is a comparison of the initial connectivity model versus a traditional VPN setup that I have documented:
| Aspect | Traditional Site-to-Site VPN (IPSec) | Hypothesized Perimeter 81 Agent Model |
| :--- | :--- | :--- |
| **Firewall Changes** | Requires inbound rules for IKE (UDP 500) & ESP (IP Proto 50). | Requires only outbound HTTPS (TCP 443). |
| **Connection Dir.** | Bidirectional; firewall must permit inbound initiation. | Unidirectional outbound; all sessions initiated from client. |
| **Local Interface** | Often creates a physical or virtual tunnel interface. | Creates a virtual network adapter for routing. |
| **DNS Handling** | Typically pushes DNS server IPs via DHCP, which may conflict with local resolvers. | Likely uses a local DNS resolver (e.g., 127.0.0.1:53) to intercept and forward queries. |
I am looking for empirical, workflow-based reviews from users who have deployed the agent in a monitored environment. Did you observe any automatic firewall rule generation, either at the OS level or on your perimeter device? Logs or configuration snippets from a trial run would be immensely valuable to assess the actual footprint before committing to a broader organizational rollout.
— Amanda
Data > opinions
Your hypothesis about outbound-only connections is correct for the initial agent evaluation. The client software initiates a persistent TLS tunnel (often over TCP 443 or 443/udp for WireGuard) to their cloud gateways. No inbound rules on your local firewall should be needed.
Where I'd add a caveat is that while you don't modify rules, the agent's virtual network adapter still changes the local routing table. For your A/B testing traffic, you must verify split-tunneling configuration immediately. If it's misconfigured for full tunnel, all your analytics traffic, including critical experiment payloads, could get routed through their cloud for inspection, adding latency and a new point of failure. Test with a traceroute to your analytics endpoint before and after agent installation.
Also, the "no firewall changes" claim holds only for the client agent on a single host. If you later explore their network gateway appliance for site-to-site, that's a full inbound/outbound rule rewrite.
Data over dogma
You've nailed the core premise - it's designed to work outbound-only, so no inbound firewall rule changes are needed. Your hypothesis is correct.
The key detail you're asking about is spot on. The agent initiates that connection over standard ports like 443, so any sane outbound firewall rule set will already allow it. It looks like normal HTTPS traffic to the firewall.
The real nuance, which you hinted at, is the *implicit* rule the agent creates. While you're not editing the firewall, the agent's virtual adapter becomes a new, higher-priority route. That's where the risk to your A/B traffic lies, not in the rule set. Have you considered testing the agent on a non-production replica of your analytics environment first, just to trace the exact route your payloads would take?
Keep it civil, keep it real
You're correct on the outbound-only connection. The agent initiates everything.
Your granular question about the initial packet: yes, it's a clienthello. The agent acts like a browser starting a TLS session to an IP owned by Perimeter 81.
The crucial detail is the agent installs a virtual network adapter. This changes the routing table, not firewall rules. Your traffic may take a different path even though the firewall is untouched. Test with a non-production host first.
Confirm your split-tunneling config. If it's a full tunnel, all your A/B test data will route through their cloud. That's latency and a new failure domain you didn't have before.
Five nines? Prove it.