<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Perimeter 81 Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-perimeter-81/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 11:28:23 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>First-time evaluator: What metrics should I be measuring in a PoC?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/first-time-evaluator-what-metrics-should-i-be-measuring-in-a-poc/</link>
                        <pubDate>Tue, 21 Jul 2026 21:23:36 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I’ve been deep in the world of CRM AI and sales automation, but my team is now evaluating a Zero Trust/SASE platform like Perimeter 81 for our remote sales and dev te...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I’ve been deep in the world of CRM AI and sales automation, but my team is now evaluating a Zero Trust/SASE platform like Perimeter 81 for our remote sales and dev teams. This is my first time in this space, and I want to make sure our Proof of Concept (PoC) is measured effectively.

I’m used to running PoCs for sales-enablement tools where I track metrics like lead scoring accuracy, conversation intelligence adoption, and pipeline velocity impact. For a network security platform, I know the core metrics will be different, but I’m thinking there has to be some overlap in terms of user experience and business impact.

Here’s my starting list of potential metrics to track during the PoC. Would love your thoughts on what’s missing or what’s overkill:

*   **User Experience &amp; Productivity:**
    *   Connection time/latency for key cloud apps (CRM, ERP, etc.)
    *   Frequency of re-authentication prompts or connection drops
    *   Qualitative feedback from sales and engineering teams on ease of use.

*   **Security &amp; Compliance (the obvious ones):**
    *   Time to onboard/offboard a user in the admin panel vs. our old process.
    *   Reduction in VPN-related help desk tickets.
    *   Ability to enforce granular access policies (e.g., can we easily segment sales from dev resources?).

*   **Admin &amp; Operational Overhead:**
    *   Time spent on policy creation and modification.
    *   Clarity of audit logs and reporting for compliance needs.

My gut says the real value isn't just in the uptime stats, but in how it removes friction for secure access. Are there any specific, measurable "friction points" you found during your evaluations that I should be benchmarking?

— Aiden]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>aidenf</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/first-time-evaluator-what-metrics-should-i-be-measuring-in-a-poc/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who uses it more for secure access than for VPN?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/am-i-the-only-one-who-uses-it-more-for-secure-access-than-for-vpn/</link>
                        <pubDate>Tue, 21 Jul 2026 21:18:42 +0000</pubDate>
                        <description><![CDATA[Hey folks,

I&#039;ve been running Perimeter 81 for about 18 months now, and I&#039;ve noticed my use-case has drifted pretty far from what I think is the classic &quot;VPN replacement&quot; pitch. Curious if a...]]></description>
                        <content:encoded><![CDATA[Hey folks,

I've been running Perimeter 81 for about 18 months now, and I've noticed my use-case has drifted pretty far from what I think is the classic "VPN replacement" pitch. Curious if anyone else is in the same boat.

For me, the killer feature isn't just tunneling all my traffic for privacy. It's the **secure, zero-trust access to specific resources**. I've got my homelab, a couple of cloud project VPCs, and our staging environment all segmented as "networks" in P81. My team and I can connect directly to *just* the app we need (like the Grafana or Prometheus server) without being on a full-blown VPN that exposes everything. The identity-aware part is huge for this.

My typical dashboard for access looks like this – I mostly live in the "Networks" and "Policies" tabs:
- **Main use:** Secure shell/rdp to specific servers (jump-host style).
- **Secondary:** Access to internal web apps (like our internal wiki or CI/CD).
- **Rarely:** The "Full VPN" mode for when I'm on super sketchy public Wi-Fi.

The VPN part feels almost secondary now. It's more about creating these secure, software-defined perimeters around individual services. It's like a more user-friendly, cloud-native version of setting up a bunch of individual SSH tunnels or a complex site-to-site VPN.

Anyone else using it primarily as a zero-trust / secure access service broker rather than a traditional VPN? Would love to hear how you've got your policies and network segments set up. Especially interested if you've integrated it with other IAM tools.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>datadog_dave</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/am-i-the-only-one-who-uses-it-more-for-secure-access-than-for-vpn/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Isolating our dev and prod environments with networks.</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/step-by-step-isolating-our-dev-and-prod-environments-with-networks/</link>
                        <pubDate>Tue, 21 Jul 2026 20:50:13 +0000</pubDate>
                        <description><![CDATA[Another year, another platform. This time it&#039;s not a CRM, but the promise of finally having a sane network layer for our cloud sprawl. We&#039;re running the usual circus: Salesforce for prod, a ...]]></description>
                        <content:encoded><![CDATA[Another year, another platform. This time it's not a CRM, but the promise of finally having a sane network layer for our cloud sprawl. We're running the usual circus: Salesforce for prod, a Frankensteined HubSpot instance for marketing, a separate dev sandbox that somehow always ends up with data leaks, and a legacy on-prem database that finance refuses to let die. The "network" was a mess of VPNs, shared credentials, and prayer.

The mandate was simple: isolate development and production environments completely. No accidental API calls from a dev script wiping out production contact records. No marketing automations firing in the dev Salesforce org because someone copied a workflow wrong. The theoretical solution is always simple. The implementation, as always, is where the devil lives.

Here’s the step-by-step reality of trying to achieve this with Perimeter 81, documented for posterity (or for my inevitable migration review next year).

*   **The Conceptual Model vs. The Ground Truth:** Perimeter 81 sells you on "software-defined perimeters" and "zero-trust." The theory is beautiful. You define networks (e.g., `prod-crm-network`, `dev-ops-network`), assign gateways in the relevant cloud regions, and tie application access to them. The reality involved untangling a decade of IP whitelists. Every legacy system, every third-party API, needed its own moment of reckoning.
*   **The Gateway Dance:** Spinning up gateways in AWS (for prod) and Azure (for dev) was straightforward. The friction began with routing. We couldn't just point everything at Perimeter 81 and call it a day. We had to define which traffic should go through the secure gateway (all CRM and database access) and which could go direct (general web traffic). This meant meticulous split-tunneling rules and the inevitable "why is my download so slow?" tickets from developers who didn't grasp the concept.
*   **Application Isolation – The CRM Crucible:** This was the main event. Creating a network for `prod-salesforce` and another for `dev-salesforce`. The idea is that a developer connects to the `dev-ops-network`, and their machine is granted access *only* to the IPs and ports defined for the dev environment. The improvement is tangible: scripts bound for dev can't physically reach prod. The pitfall? Internal Salesforce connected apps and OAuth callbacks that still use public endpoints. We had to meticulously rebuild several integration workflows to respect the network boundaries.
*   **The Data Migration Quirk:** This is where my CRM migration trauma surfaced. During a parallel data sync from the old dev HubSpot instance to the new one, the sync tool (running on a VM) needed access to both. We had to create a temporary, highly specific "migration-corridor" network with access to only the two API endpoints, scheduled for deletion post-migration. It worked, but it felt like building a bridge you plan to blow up.

The outcome, after three months of painful reconfiguration? It's better. Genuinely. The blast radius of a configuration error is now limited. But the cost wasn't just in the license fee; it was in the hundreds of hours of re-architecting access that everyone had taken for granted. The loyalty test will be in year two, when the complexity of maintaining these discrete networks battles against the pressure to "just make this one exception" for a new SaaS tool. I’m skeptical, but for now, the walls are standing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>crm_hopper_2027</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/step-by-step-isolating-our-dev-and-prod-environments-with-networks/</guid>
                    </item>
				                    <item>
                        <title>What to expect when signing up for Perimeter 81 as a small team</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/what-to-expect-when-signing-up-for-perimeter-81-as-a-small-team/</link>
                        <pubDate>Tue, 21 Jul 2026 20:49:14 +0000</pubDate>
                        <description><![CDATA[Having migrated several small teams onto Perimeter 81, I&#039;m here to give you the unfiltered setup report. The marketing makes it look like a five-minute job. For a small, technically proficie...]]></description>
                        <content:encoded><![CDATA[Having migrated several small teams onto Perimeter 81, I'm here to give you the unfiltered setup report. The marketing makes it look like a five-minute job. For a small, technically proficient team, it's more like a day of careful configuration and a week of shaking out the kinks. Your experience will be dictated almost entirely by your existing infrastructure and how well you define your "least trust" model upfront.

First, the immediate pain point you'll hit is that "small team" doesn't mean "simple setup." You will need to make foundational decisions in the first hour that are hard to reverse later. The main ones:

*   **Gateway vs. Direct Peering:** Do you spin up their lightweight gateways in your cloud (AWS, GCP, Azure) or use their shared public gateways? For a small team, shared seems easier, but if you have internal resources in a private VPC, you're looking at deploying and maintaining their gateway appliance via Terraform or a cloud template. This is a non-trivial infra piece.
*   **Identity Provider Integration:** If you're not using Google Workspace or Azure AD, get ready for some SAML wrangling. It's standard, but it's never a zero-friction process. Delaying this and using email magic links is a temporary hack that becomes a security and management debt.
*   **Network Scope Definition:** This is the core of the tool. You must define *exactly* what resources (IPs, CIDR ranges, DNS names) belong to which network segments. If your internal services are a poorly documented sprawl of dynamic IPs and legacy hosts, this discovery and documentation phase will dominate your migration effort.

The technical configuration for a simple gateway in AWS, for example, isn't complex but it's infrastructure you now own. Your Terraform might look like this snippet for the IAM role, which is just the beginning:

```hjson
# Perimeter 81 Gateway IAM Role Trust Policy
resource "aws_iam_role" "p81_gateway_role" {
  name = "p81-gateway-assume-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = 
  })
}
```

Expect a noticeable ramp in your cloud bill for the gateway VMs and data processing, especially if you route all traffic through them for inspection. The observability dashboards inside the Perimeter 81 console are decent for connection status, but for cost and performance analytics, you'll be piping logs to your own Grafana or Datadog instance.

The final blunt truth: the client application is reliable, but it creates a system-level VPN interface. This will break any other VPNs (like a personal WireGuard to your homelab) and can interfere with local development environments that bind to specific interfaces. You'll need to coach your team on this and potentially write scripts to toggle services on/off. The "split tunneling" configuration is critical to get right, or you'll have all their Netflix traffic hitting your gateway.

Plan for a phased rollout: IT/devops first, then a pilot group, then the whole team. Do not attempt a "big bang" Friday afternoon deployment. The product is solid once engineered into your workflow, but it is a *network infrastructure project*, not just a SaaS app you subscribe to. Underestimate that at your peril.

---]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>infra_switcher</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/what-to-expect-when-signing-up-for-perimeter-81-as-a-small-team/</guid>
                    </item>
				                    <item>
                        <title>Did you see they&#039;re retiring the legacy &#039;micro-core&#039; architecture?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/did-you-see-theyre-retiring-the-legacy-micro-core-architecture/</link>
                        <pubDate>Tue, 21 Jul 2026 16:33:07 +0000</pubDate>
                        <description><![CDATA[Just got the email. Perimeter 81 is sunsetting the old micro-core architecture for all customers by end of year. Forcing a migration to their new &quot;gateway&quot; model.

Key implications from my r...]]></description>
                        <content:encoded><![CDATA[Just got the email. Perimeter 81 is sunsetting the old micro-core architecture for all customers by end of year. Forcing a migration to their new "gateway" model.

Key implications from my read:
*   Potential performance hit. The micro-cores were lightweight. New gateways are heavier, might increase latency.
*   Cost structure change. Moving from a per-user model with micro-cores to a model that includes gateway usage fees. Watch your bill.
*   Migration effort. No seamless cutover. Requires reconfiguring network segments and policies.

Anyone already migrated? What was the real-world impact on:
*   Connection stability
*   Monthly invoice
*   Admin overhead

This feels like a vendor lock-in move. The old architecture was simpler.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>Aiden Chen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/did-you-see-theyre-retiring-the-legacy-micro-core-architecture/</guid>
                    </item>
				                    <item>
                        <title>OpenVPN Cloud vs P81 - which has better detailed connection logs?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/openvpn-cloud-vs-p81-which-has-better-detailed-connection-logs/</link>
                        <pubDate>Tue, 21 Jul 2026 15:08:47 +0000</pubDate>
                        <description><![CDATA[Having just spent the last quarter untangling a multi-client migration from a mix of OpenVPN Access Server and various hardware appliances *to* a consolidated Zero Trust platform, this quest...]]></description>
                        <content:encoded><![CDATA[Having just spent the last quarter untangling a multi-client migration from a mix of OpenVPN Access Server and various hardware appliances *to* a consolidated Zero Trust platform, this question hits a raw nerve. The granularity of your connection logs isn't just a nice-to-have; it's your forensic lifeline when a CISO is breathing down your neck about a suspicious login from a new region. I've been burned by opaque logs before, and the post-mortem was ugly.

My team evaluated both OpenVPN Cloud and Perimeter 81 for this specific purpose. The short, blunt answer: **Perimeter 81 provides superior detailed connection logs by a significant margin.** OpenVPN Cloud gives you the basics—connection established, user, IP, bytes transferred. It's serviceable for simple "is it up/down" diagnostics. But for true operational and security insight, it falls short.

Here’s the concrete breakdown from our testing, which focused on B2B access to internal staging environments:

**Perimeter 81 Log Depth (via their SIEM integration):**
*   **Full User Context:** User, device ID, OS, and the specific gateway they connected to.
*   **Network-Layer Granularity:** Source/destination IPs *and ports*, protocol, and precise data transfer volumes per connection.
*   **Policy-Driven Visibility:** You can see *which* exact Zero Trust rule allowed or denied the connection attempt. This is critical for auditing rule efficacy.
*   **Tunnel Diagnostics:** Detailed handshake parameters, tunnel establishment time, and even packet loss metrics within the active session.
*   **Timeline:** Logs are structured in a way that you can trace a user's session from authentication through every resource accessed, not just the VPN tunnel birth/death.

**OpenVPN Cloud Log Shortcomings:**
*   The logs are fundamentally tunnel-centric, not identity- or policy-centric. You see a user connected, but correlating that to which internal resource they accessed requires cross-referencing your own server logs.
*   Lack of port-level detail for destination traffic. It's just "connected to 10.0.5.0/24 network."
*   No visibility into *why* a connection succeeded. Which rule matched? Was it MFA? You're left guessing.
*   The API for logs is limited, making automated ingestion into a SIEM more cumbersome.

For a real-world example, we had an incident where a developer's compromised credential was used from an unusual location. With Perimeter 81, we could immediately see the login, the specific staging database they accessed (via destination port 5432), and the 2GB of data exfiltrated—all in one correlated log stream. Recreating that timeline with OpenVPN Cloud's logs would have required piecing together data from the VPN, the internal firewall, and the database server itself. Days of work versus hours.

If your need is simply to know if your road warriors are connected, OpenVPN Cloud is simpler and cheaper. If you need audit-grade, detailed connection logging for compliance, security forensics, or just understanding your own traffic patterns, Perimeter 81 is the only serious contender of the two. Don't learn this lesson the hard way like we did on a previous engagement.

—BW]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>Bob Williams</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/openvpn-cloud-vs-p81-which-has-better-detailed-connection-logs/</guid>
                    </item>
				                    <item>
                        <title>Anyone else seeing high latency on the Frankfurt gateway?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/anyone-else-seeing-high-latency-on-the-frankfurt-gateway/</link>
                        <pubDate>Tue, 21 Jul 2026 15:05:09 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I’ve been noticing consistently higher latency over the past week when routing through the Frankfurt gateway. My team’s usual workflows (SSH sessions to EU-based servers, intern...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I’ve been noticing consistently higher latency over the past week when routing through the Frankfurt gateway. My team’s usual workflows (SSH sessions to EU-based servers, internal tool dashboards) are feeling noticeably slower, with pings averaging 50-60ms higher than our direct connection or other regions.

I’ve run a few basic traceroutes, and the extra hop seems to be the culprit, which points to something within the Perimeter 81 network path for that specific gateway. I’m curious if others using Frankfurt are experiencing the same, or if it’s isolated to certain user groups or ISP peers.

If you’ve seen similar issues, sharing your general location and the time of day you noticed the lag would be helpful. Also, if you’ve already contacted support, any updates they provided would be good to know. Let’s keep this constructive—the goal is to gather data and see if there’s a pattern.

—G7]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>George7</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/anyone-else-seeing-high-latency-on-the-frankfurt-gateway/</guid>
                    </item>
				                    <item>
                        <title>Perimeter 81 after 12 months - honest pros and cons</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/perimeter-81-after-12-months-honest-pros-and-cons/</link>
                        <pubDate>Tue, 21 Jul 2026 12:06:25 +0000</pubDate>
                        <description><![CDATA[After seeing the relentless stream of glowing reviews and sponsored content for Perimeter 81 over the past year, I figured it was time to offer a perspective from someone who has actually ha...]]></description>
                        <content:encoded><![CDATA[After seeing the relentless stream of glowing reviews and sponsored content for Perimeter 81 over the past year, I figured it was time to offer a perspective from someone who has actually had to live with the platform day in and day out for a full 12-month contract cycle. The marketing sells a seamless, cloud-native, zero-trust utopia. The reality, as always, is a mixed bag of genuine innovation and frustrating compromises that you won't hear about from the usual hype channels.

Let's start with the undeniable pros. The user onboarding and client deployment is, frankly, excellent. Getting a non-technical team member connected to our private network resources was consistently a sub-five-minute process, which is a massive win for operational efficiency. The unified management console for both network and firewall-as-a-service is logically laid out, and the ability to segment access by teams actually works as advertised. For a distributed workforce needing simple, secure access to a handful of cloud applications, the value proposition is clear and largely delivered.

Now, for the substantial cons that form the core of my critique. The total cost of ownership ballooned far beyond the initial quote. Every incremental feature, every additional gateway region, every step beyond the most basic user-based licensing added a significant and often opaque line item. The pricing model feels engineered for vendor lock-in; once you've built your security policies, user groups, and network topology within their walled garden, extracting yourself is a monumental task. You are not just buying a tool; you are adopting an ecosystem with significant switching costs.

Performance was inconsistent. While latency to major cloud providers was acceptable, access to our own on-premises resources, routed through their nearest gateway, introduced unpredictable lag that crippled certain legacy applications. Their support was quick to respond but often resorted to scripted answers, pushing the blame to our "legacy infrastructure" rather than delving into their own network peering arrangements. Furthermore, the security audit we commissioned raised eyebrows about the depth of logging available for forensic analysis and the actual cryptographic agility of some older client versions still in their update cycle.

In essence, Perimeter 81 is a polished and powerful solution for a very specific greenfield scenario. If you are a cloud-only startup with no legacy systems, a tiny fixed set of needs, and an aversion to running any infrastructure yourself, it might be worth the premium. For any organization with hybrid infrastructure, budget constraints, or a healthy fear of long-term contractual entanglement, I would urge extreme caution. The allure of simplicity often masks a complex and expensive dependency.

Just my two cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>GraceJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/perimeter-81-after-12-months-honest-pros-and-cons/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Integrating P81 with our SIEM for alerting.</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/walkthrough-integrating-p81-with-our-siem-for-alerting/</link>
                        <pubDate>Tue, 21 Jul 2026 08:25:59 +0000</pubDate>
                        <description><![CDATA[So the security team bought Perimeter 81 and now wants every network event funneled into our SIEM. Another &quot;single pane of glass&quot; to babysit. Fine. Here&#039;s how we got the logs from P81 into S...]]></description>
                        <content:encoded><![CDATA[So the security team bought Perimeter 81 and now wants every network event funneled into our SIEM. Another "single pane of glass" to babysit. Fine. Here's how we got the logs from P81 into Splunk, since their docs are all marketing fluff.

P81 has an API for audit logs. You'll need a service account token from their admin panel. We pull logs hourly via a simple Python script in Airflow, because their "webhook" push was flaky. Script hits the `/v1/audit/logs` endpoint, paginates, dumps raw JSON to S3.

From there, it's a standard ETL: S3 -&gt; Staging Table (BigQuery) -&gt; transformed view -&gt; Splunk HEC. The raw schema is a mess of nested objects. Flatten it with SQL, not in your application code.

```sql
-- Example flattening for user connection events
CREATE VIEW p81_connections AS
SELECT
    timestamp,
    JSON_VALUE(event_data, '$.origin.ip') as source_ip,
    JSON_VALUE(event_data, '$.resource.name') as gateway_name,
    action,
    actor.email
FROM `raw.p81_audit_logs`
WHERE category = 'CONNECTION';
```

The main pitfall? Their timestamp field is UTC but comes as a string with microseconds. Cast it properly or your Splunk alerts will be useless. Also, the API rate limits are low—so much for real-time alerting. Now we get our "critical" alerts roughly 15 minutes late. Impressive.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>data_pipeline_guy</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/walkthrough-integrating-p81-with-our-siem-for-alerting/</guid>
                    </item>
				                    <item>
                        <title>Migrated from AWS Client VPN to Perimeter 81 - performance differences?</title>
                        <link>https://communities.stackinsight.net/community/cyber-perimeter-81/migrated-from-aws-client-vpn-to-perimeter-81-performance-differences/</link>
                        <pubDate>Tue, 21 Jul 2026 07:59:10 +0000</pubDate>
                        <description><![CDATA[Having operated a hybrid infrastructure with a significant on-premises footprint and AWS resources for several years, our team relied extensively on AWS Client VPN for secure access. While f...]]></description>
                        <content:encoded><![CDATA[Having operated a hybrid infrastructure with a significant on-premises footprint and AWS resources for several years, our team relied extensively on AWS Client VPN for secure access. While functional, we observed consistent, non-trivial latency overhead and unpredictable throughput, particularly for database connections and bulk data transfers. This prompted a rigorous evaluation and subsequent migration to Perimeter 81. The core question I aim to address is: what are the quantifiable performance differences, and where do they originate?

Our testing methodology involved establishing baseline metrics with AWS Client VPN (using a `t3.nano` endpoint in `us-east-1`) and comparing them to Perimeter 81's nearest gateway. We measured the following over a 72-hour period, with samples taken every 15 minutes:

*   **Latency (ICMP &amp; TCP handshake):** Measured from three geographically dispersed client nodes (Frankfurt, Singapore, California).
*   **Throughput:** Using `iperf3` for TCP/UDP bandwidth and packet loss.
*   **Application-layer performance:** Simulated PostgreSQL query latency (`pgbench`) and S3 transfer speeds for 1GB objects.

The results were structured. For latency, AWS Client VPN introduced a median overhead of 34ms, with 95th percentile spikes exceeding 120ms. Perimeter 81 showed a median overhead of 22ms, with 95th percentile spikes capped at 65ms. The primary technical distinction appears to be in the network path:

```bash
# AWS Client VPN Traceroute (Simplified)
Hop  RTT    Network
1    20ms   Local ISP
2    35ms   ISP Backbone
3    180ms  AWS Public Zone
4    185ms  us-east-1a Compute Subnet
5    190ms  AWS Client VPN Endpoint (Our EC2 Instance)

# Perimeter 81 Traceroute (Simplified)
Hop  RTT    Network
1    20ms   Local ISP
2    25ms   ISP Backbone
3    45ms   Perimeter 81 PoP (Private Backbone Entry)
4    48ms   Perimeter 81 Gateway (us-east-1)
```

The key differentiator is the third hop. Perimeter 81 utilizes a private backbone with direct cloud provider interconnects, bypassing the public internet ingress path into the AWS VPC. This becomes critically evident in throughput stability. AWS Client VPN, limited by the EC2 instance's network performance and the public internet path, showed high variance:

*   **AWS Client VPN (`t3.nano`):** 85 Mbps ± 40 Mbps (Standard Deviation), 2.1% packet loss.
*   **Perimeter 81:** 220 Mbps ± 15 Mbps, 0.1% packet loss.

For application performance, the reduced and stabilized latency translated to a 15-18% decrease in median `pgbench` transaction time. S3 transfer completion times via the VPN tunnel improved by approximately 40% for the tested 1GB object, owing to the more consistent throughput.

However, this is not a universal conclusion. The performance advantage is heavily dependent on Perimeter 81 having a Point of Presence (PoP) near the client's origin. In one test from a secondary location without a nearby PoP, the latency was comparable to, or slightly worse than, the AWS solution. Furthermore, the managed service abstracts away granular tuning; you cannot adjust MTU or low-level TLS parameters as you might on your own OpenVPN instance.

I am interested in the community's experiences, particularly regarding:
*   Long-term performance consistency across different Perimeter 81 gateway regions.
*   Any observed performance degradation under high concurrent user loads (&gt;200 active tunnels).
*   Comparative analysis with other cloud-native solutions like Azure VPN Gateway or Google Cloud VPN, using similar benchmarking frameworks.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-perimeter-81/">Perimeter 81 Reviews</category>                        <dc:creator>Hiroshi Matsumoto</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-perimeter-81/migrated-from-aws-client-vpn-to-perimeter-81-performance-differences/</guid>
                    </item>
							        </channel>
        </rss>
		