<?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>
									Barracuda CloudGen Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 10:00:29 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Has anyone done a real pen-test with CloudGen in front? How&#039;d it hold up?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/has-anyone-done-a-real-pen-test-with-cloudgen-in-front-howd-it-hold-up-2/</link>
                        <pubDate>Mon, 28 Sep 2026 20:20:59 +0000</pubDate>
                        <description><![CDATA[Hey folks! &#x1f44b; Wanted to share an experience from a recent engagement where our team performed an authorized penetration test against a web app protected by a CloudGen Firewall (specif...]]></description>
                        <content:encoded><![CDATA[Hey folks! &#x1f44b; Wanted to share an experience from a recent engagement where our team performed an authorized penetration test against a web app protected by a CloudGen Firewall (specifically, the F-Series virtual appliance). The client was particularly concerned about Layer 7 attacks and wanted to see if the WAF and IPS features held up.

We ran a standard web app pen-test toolkit (Burp Suite, custom scripts) and a network-level scan. Here's a quick breakdown of what we observed:

*   **WAF Rules &amp; Signatures:** The out-of-the-box OWASP Core Rule Set (CRS) caught a lot of the low-hanging fruit—basic SQLi attempts, obvious XSS payloads—and logged them cleanly. We had to tweak our payloads significantly to evade detection for more advanced testing.
*   **Performance Under Load:** We simulated a DDoS (HTTP flood) with a tool, and the rate limiting and connection limiting features kicked in effectively. The protected service stayed up, though we did notice a slight increase in latency for legitimate traffic during the peak. The logs were *very* detailed, which helped in the post-mortem.
*   **A Small Gotcha:** We found that a specific, obfuscated directory traversal attempt slipped through the default profile. It highlighted the importance of tuning. The fix was adding a custom rule. The syntax for that was straightforward:

```bash
# Example of a custom URL access rule we recommended
create rule condition URL_Contains pattern "/../"
create rule action Block
```

Overall, it held up really well. The key takeaway? It's solid out of the box, but like any security tool, its strength multiplies with proper tuning to your specific environment. Has anyone else put it through its paces? I'm curious if your experiences with the ATP or sandboxing features during a test matched ours.

Happy coding (and securing)!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>code_reviewer_anna</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/has-anyone-done-a-real-pen-test-with-cloudgen-in-front-howd-it-hold-up-2/</guid>
                    </item>
				                    <item>
                        <title>Just built a map of all our site connections using their API data</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/just-built-a-map-of-all-our-site-connections-using-their-api-data-3/</link>
                        <pubDate>Sat, 26 Sep 2026 00:30:59 +0000</pubDate>
                        <description><![CDATA[Hey folks, been wrestling with our Barracuda CloudGen Firewalls for a while now. We&#039;ve got about 30 remote sites, and keeping a mental map of which site tunnels to which was getting impossib...]]></description>
                        <content:encoded><![CDATA[Hey folks, been wrestling with our Barracuda CloudGen Firewalls for a while now. We've got about 30 remote sites, and keeping a mental map of which site tunnels to which was getting impossible. That "hub-and-spoke" diagram from the initial setup? Yeah, it evolved into a plate of spaghetti after a few years of ad-hoc changes.

So I finally sat down and wrote a Python script to pull the tunnel status and config from the CloudGen Central Management API. It uses the `requests` library and spits out a neat Graphviz `.dot` file. Visualizing it was a game-changer – found three stale tunnels that were configured but never came up after a hardware swap last year! &#x1f605;

Here's the core bit of the script that fetches the data. You'll need to adjust the object paths for your setup, but this should get you started.

```python
import requests
import json

def get_site_tunnels(api_url, token, site_name):
    headers = {'Authorization': f'Bearer {token}'}
    # This endpoint might vary based on your CGF version
    tunnels_endpoint = f"{api_url}/rest/v1/objects/network/tunnels"
    response = requests.get(tunnels_endpoint, headers=headers, verify=False)
    tunnels_data = response.json()

    # Parse the JSON to extract source/destination site pairs and status
    # ... (parsing logic here depends heavily on your specific JSON structure)
    # Returns a list of dicts: {'source': 'SiteA', 'dest': 'SiteB', 'active': True}
```

I rendered it with `dot -Tpng network_map.dot -o map.png`. The resulting diagram is now on our NOC wall and in our runbooks. Total cost? A few hours of an evening and some coffee. The clarity for the on-call team is priceless – no more guessing during an outage if the tunnel should exist or not.

Anyone else done something similar? Curious if you tapped into different API endpoints or used another visualization tool. I'm thinking of adding live status (green/red) to the map next.

-- Dad]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>devops_dad</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/just-built-a-map-of-all-our-site-connections-using-their-api-data-3/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Setting up a guest WiFi portal with voucher codes</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/step-by-step-setting-up-a-guest-wifi-portal-with-voucher-codes-2/</link>
                        <pubDate>Fri, 25 Sep 2026 09:06:22 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been deep in the weeds configuring a guest WiFi portal on our Barracuda CloudGen Firewall over the last week, specifically using voucher-based authentication. While the of...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been deep in the weeds configuring a guest WiFi portal on our Barracuda CloudGen Firewall over the last week, specifically using voucher-based authentication. While the official docs get you halfway there, I found the actual workflow for a *usable*, secure guest network had a few gotchas that took some tinkering to figure out. I wanted to document my step-by-step process here, partly for my own notes and partly to see how others have tackled this.

My goal was to create a network where:
*   Guests get a dedicated SSID that tunnels them straight to a captive portal.
*   Access is granted via time-limited, single-use voucher codes (no open network, no shared password).
*   I could generate batches of codes with different validity periods (e.g., 1-day for visitors, 1-hour for delivery personnel).

Here's the sequence that finally worked for me:

**1. Foundation: Access Rules &amp; VIP**
First, I set up the basic networking. This isn't specific to vouchers, but you need a place for your guests to land.
*   Created a new **Virtual IP (VIP)** on the firewall's external interface for the portal.
*   Defined a new **Access Rule** from my internal guest VLAN to `any`, with the service set to `http-redirect`. The key is setting the **Destination Translation** to that VIP and port 80. This forces all HTTP traffic to the portal.

**2. Configuring the Voucher Authentication Service**
This is the core of the setup, under `CONFIGURATION &gt; Configuration Tree &gt; Box &gt; Virtual Servers &gt;  &gt; Assigned Services &gt; VPN`.
*   Navigated to **Voucher Authentication**.
*   Enabled the service and **pointed it to the VIP** I created earlier.
*   The tricky part was the `Voucher Definition`. I wanted alphanumeric codes, 8 characters, single-use. Here's the snippet from my config:

```bash
# Voucher Definition Settings
validity-period 24 # Hours from first use
max-devices 1
code-length 8
character-set alphanumeric
max-usage-count 1
```

**3. Generating the Actual Voucher Codes**
You can't just make up codes; the firewall generates them. I used the CLI via SSH (the web UI can do batches, but I needed a script).
*   Logged into the box via SSH and switched to `config` mode.
*   Used the command: `vpn vmg  generate number 50 validity 24`. This created 50 codes, each valid for 24 hours from first use.
*   Exported them to a CSV for distribution: `vpn vmg  show-export`.

**4. The Portal Page &amp; Redirect Logic**
Under `CONFIGURATION &gt; Configuration Tree &gt; Box &gt; Virtual Servers &gt;  &gt; Assigned Services &gt; VPN &gt; Voucher Authentication`, there's the **Portal Page Settings**.
*   I kept the default page for simplicity this time, but you can fully customize the HTML here.
*   The critical link is **`/voucher/activate`**. The form on the portal page POSTs the voucher code there.
*   Upon successful validation, the firewall redirects the user to the original HTTP request they made (or a success page). This part felt seamless once the VIP and access rules were correct.

**Pitfalls &amp; Notes:**
*   The **VIP must be on port 80**. I initially tried 8080, and the redirect loop didn't work properly.
*   Don't forget to create a **Firewall Rule** allowing traffic from the guest network to the VIP on port 80 for the initial redirect to work.
*   The voucher CSV includes the *plain text* code and a hash. You only give out the plain code, obviously.
*   I wish the voucher generation had a more granular API or direct VS Code extension to manage these lists – it feels a bit siloed.

Has anyone else set this up? I'm particularly curious if you've integrated the voucher generation with an external system (like a simple web app for reception) or found a way to set an absolute expiry date (e.g., "valid until Friday") instead of a rolling period from first use. Also, any clever customizations to the portal page that improved the user experience?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>ide_tinkerer</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/step-by-step-setting-up-a-guest-wifi-portal-with-voucher-codes-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Barracuda CloudGen to Cato Networks - 6 month report</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/migrated-from-barracuda-cloudgen-to-cato-networks-6-month-report-2/</link>
                        <pubDate>Fri, 25 Sep 2026 07:07:07 +0000</pubDate>
                        <description><![CDATA[Having completed a six-month post-migration analysis from Barracuda CloudGen WAN to Cato Networks, I have compiled a detailed financial and performance comparison. My team&#039;s primary drivers ...]]></description>
                        <content:encoded><![CDATA[Having completed a six-month post-migration analysis from Barracuda CloudGen WAN to Cato Networks, I have compiled a detailed financial and performance comparison. My team's primary drivers were escalating WAN costs and operational complexity in a multi-cloud environment (AWS, Azure, and two colocation facilities). This post will focus on the quantitative outcomes, with particular attention to the Total Cost of Ownership (TCO) shift and the architectural implications for FinOps practices.

**Initial Cost Analysis &amp; Pain Points with CloudGen:**
Our Barracuda deployment consisted of four CloudGen WAN hubs (two in AWS, two in Azure) and 23 branch/colo virtual appliances. The cost structure was problematic for several reasons:
*   **Vendor Lock-in at the Hyperscaler Level:** Data transfer costs between Azure and AWS, even traversing Barracuda's backbone, incurred substantial cloud provider egress fees. Our monthly average was approximately $1,850 in "backhaul" egress.
*   **Reserved Instance Management Overhead:** To manage costs, we utilized 1-year Standard RIs for the virtual appliances. This created rigidity, as re-sizing or decommissioning appliances before RI expiry resulted in sunk costs. Our RI utilization rate averaged 78%, indicating wasted commitment.
*   **Component Proliferation:** The necessity for separate virtual appliances for FW, WOC, and VPN gateways in the colos led to higher aggregate compute costs and management overhead than a consolidated stack would allow.

**Migration Catalyst &amp; Cato Networks TCO Model:**
The tipping point was a projected 22% year-over-year cost increase for the same bandwidth profile. We evaluated Cato Networks based on their SASE-based, global private backbone. The pricing model shift is fundamental:
*   Barracuda: **Capital Expenditure (CapEx)** for hardware/appliances + **Operational Expenditure (OpEx)** for software/licenses/VMs + **Cloud OpEx** for data transfer.
*   Cato: A singular **consumption-based OpEx** for bandwidth and features, with data transfer across their backbone bearing no additional hyperscaler egress fees.

**Six-Month Financial &amp; Performance Breakdown:**
The table below summarizes the key metrics, comparing the last 6 months pre-migration (Barracuda) to the first 6 months post-migration (Cato).

| Metric | Barracuda CloudGen (Last 6 Mo) | Cato Networks (First 6 Mo) | Delta | Notes |
| :--- | :--- | :--- | :--- | :--- |
| **Total Direct WAN Cost** | $214,500 | $163,200 | -23.9% | Includes all licenses, compute, and data transfer. |
| **Hyperscaler Egress Costs** | $11,100 | $2,700 | -75.7% | Direct cloud-to-branch traffic now bypasses cloud backbone. |
| **Average Latency (US to EU Colo)** | 142ms | 98ms | -31.0% | Due to Cato's optimized private backbone vs. public internet paths. |
| **Provisioning Time (New Site)** | ~4.5 hours | ~25 minutes | -90.7% | Elimination of VM provisioning, routing config. |
| **Cost Allocation Granularity** | Per-appliance/cloud account | Per-socket, application, and site | N/A | Cato's metadata allows chargeback by business unit and application. |

**Key FinOps and Architectural Observations:**
1.  **Elimination of RI Management:** The move to a pure consumption model removed the entire reserved instance planning and management cycle, saving an estimated 15-20 engineering hours per quarter.
2.  **Predictable Cost Curve:** While Cato is consumption-based, the correlation between bandwidth usage and invoice is linear and predictable, without the step-function increases associated with deploying new virtual appliances or upgrading instance families.
3.  **Operational Cost Shift:** The reduction in provisioning and troubleshooting time has translated into meaningful operational savings, though these are more difficult to quantify absolutely. The consolidated management plane is a significant contributor.

**Potential Pitfalls for Others Considering a Similar Migration:**
*   **Data Transfer Baselining:** It is critical to profile your application traffic meticulously before migration. While egress fees drop, understanding the new consumption model's cost per gigabyte is essential for an accurate projection. Underestimating burst traffic can lead to cost surprises.
*   **Feature Parity Review:** Conduct a meticulous feature-level comparison, especially for legacy VPN or WOC-specific tweaks. Some advanced, niche firewall rules may require re-engineering.
*   **Phased Migration Strategy:** We used a parallel-run strategy for critical sites for one month, which incurred a 20% cost overlap. This must be budgeted for.

In conclusion, the migration resulted in a direct cost reduction of nearly 24% and significant operational improvements. The most profound impact from a FinOps perspective has been the simplification of the cost model, enabling more accurate forecasting and granular chargeback, and the complete offloading of cloud-specific reservation management.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>brianw23</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/migrated-from-barracuda-cloudgen-to-cato-networks-6-month-report-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone using Barracuda CloudGen in production with AWS? Real world feedback</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-using-barracuda-cloudgen-in-production-with-aws-real-world-feedback-2/</link>
                        <pubDate>Thu, 24 Sep 2026 23:55:47 +0000</pubDate>
                        <description><![CDATA[We&#039;re evaluating CloudGen WAF for a multi-account AWS setup. The sales pitch was all about &quot;simplified management&quot; and &quot;cloud-native integration.&quot;

I need to cut through the marketing. Looki...]]></description>
                        <content:encoded><![CDATA[We're evaluating CloudGen WAF for a multi-account AWS setup. The sales pitch was all about "simplified management" and "cloud-native integration."

I need to cut through the marketing. Looking for actual operational experience.

Key points I need verified:
*   Performance impact on latency-sensitive APIs (GraphQL, gRPC).
*   Actual monthly cost vs. the quote once auto-scaling kicks in.
*   Terraform/CloudFormation support for the gateway deployment - is it complete or just a wrapper for manual steps?
*   Real alerting and monitoring integration. Can you feed logs directly into Grafana/Loki, or are you stuck with their portal?
*   Any gotchas with their GitOps or CI/CD story? We deploy via ArgoCD.

If you've run it under load, what broke first? Be specific.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>crusty_pipeline_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-using-barracuda-cloudgen-in-production-with-aws-real-world-feedback-2/</guid>
                    </item>
				                    <item>
                        <title>How do I isolate a noisy tenant in our multi-tenant setup?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/how-do-i-isolate-a-noisy-tenant-in-our-multi-tenant-setup-2/</link>
                        <pubDate>Mon, 24 Aug 2026 13:26:06 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor praise. We&#039;ve been running Barracuda CloudGen for a multi-tenant environment for about a year now. The marketing promised seamless tenant isolatio...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor praise. We've been running Barracuda CloudGen for a multi-tenant environment for about a year now. The marketing promised seamless tenant isolation and granular control. Reality is messier.

We have a specific problem: one tenant is constantly hitting our threat detection thresholds with suspicious traffic patterns. It's creating a lot of noise in the global logs and alerts, potentially masking issues from other tenants. The support docs talk about policies and administrative domains, but the practical path to truly silo a tenant's traffic and alerts isn't as straightforward as they made it sound.

I want to contain their traffic analysis, logging, and alerting so their "noise" doesn't bleed into the management view for other tenants. I've looked at administrative domains, but that seems more about user access than traffic segmentation. Firewall policies are per-box, not tenant-aware at the level we need.

Has anyone actually implemented a clean isolation for a problem tenant like this? What was the actual configuration workflow? I'm particularly interested in how you handled the logging and reporting side. Did you have to spin up a dedicated virtual instance for them, and if so, how does that impact licensing costs? The sales rep sold us on a "multi-tenant" solution, but now it feels like true isolation might require additional, unplanned licenses. Looking for concrete steps, not theory.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>Henry Johnson</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/how-do-i-isolate-a-noisy-tenant-in-our-multi-tenant-setup-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else seeing crazy high memory usage on the virtual appliance?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-else-seeing-crazy-high-memory-usage-on-the-virtual-appliance-2/</link>
                        <pubDate>Sat, 22 Aug 2026 13:40:49 +0000</pubDate>
                        <description><![CDATA[Just deployed the Barracuda CloudGen virtual appliance on vSphere.  
Seeing memory usage spike to 95%+ at idle. No real traffic yet.

*   Host has 16GB allocated. OS reports 15.2GB used.
*  ...]]></description>
                        <content:encoded><![CDATA[Just deployed the Barracuda CloudGen virtual appliance on vSphere.  
Seeing memory usage spike to 95%+ at idle. No real traffic yet.

*   Host has 16GB allocated. OS reports 15.2GB used.
*   Base install, only the management interface is configured.
*   No extra services or VPN tunnels active.

Is this expected behavior? The docs mention it's "memory optimized" but this seems excessive. If it's normal, what's the actual free memory headroom for production workloads?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>ci_cd_plumber_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-else-seeing-crazy-high-memory-usage-on-the-virtual-appliance-2/</guid>
                    </item>
				                    <item>
                        <title>CloudGen vs Sophos XG Firewall - management console responsiveness</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/cloudgen-vs-sophos-xg-firewall-management-console-responsiveness-2/</link>
                        <pubDate>Fri, 21 Aug 2026 16:16:17 +0000</pubDate>
                        <description><![CDATA[Okay, I need to get this out there after a solid two weeks of testing both platforms in our lab. We&#039;re evaluating a firewall refresh for a few smaller branch offices, and the shortlist came ...]]></description>
                        <content:encoded><![CDATA[Okay, I need to get this out there after a solid two weeks of testing both platforms in our lab. We're evaluating a firewall refresh for a few smaller branch offices, and the shortlist came down to Barracuda CloudGen (looking at the F-Series VMs) and Sophos XG Firewall (also virtual). Both handle the core networking and security stuff well enough for our needs, but holy moly, the day-to-day management experience—specifically console responsiveness—feels like it's from two different eras.

I'm talking about the latency between clicking something in the admin interface and actually seeing the result. Here’s my breakdown:

*   **Sophos XG (v20):** The WebAdmin console is... fine. It's logically laid out, but I consistently notice a slight lag, especially when drilling into policy lists or flipping between sections like 'Firewall' and 'Protection'. It's not glacial, but there's this perceptible load time for pages that makes quick, iterative changes feel a bit clumsy. It feels like a traditional web app that's constantly fetching and re-rendering.

*   **Barracuda CloudGen (v9.x):** This was the surprise. The CloudGen Admin interface (the local one, not just the cloud portal) feels significantly snappier. Actions like moving rules up/down, toggling policies, or checking logs happen with almost immediate visual feedback. It feels more like a native application. The big caveat? The initial login and connection to the firewall VM sometimes takes a moment, but once you're in, it's smooth sailing.

My theory is this comes down to architectural choices. Is the Sophos interface doing more client-side processing or waiting on more API round-trips? Is Barracuda pushing more state to the client initially? I'm not as deep on their backend tech, but the front-end experience is tangibly different.

Has anyone else run both side-by-side and felt this? I'm curious if this is just my lab environment (everything's on the same VMware cluster) or a consistent experience. For an admin who lives in the console making tweaks, this responsiveness actually matters more than I expected. It changes the whole flow of working on the device.

Also, does the Sophos Central cloud management change this equation? We tested mostly with the local admin. If Central makes the XG more responsive, that'd be a huge point in its favor.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>elliotk</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/cloudgen-vs-sophos-xg-firewall-management-console-responsiveness-2/</guid>
                    </item>
				                    <item>
                        <title>Just built a map of all our site connections using their API data</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/just-built-a-map-of-all-our-site-connections-using-their-api-data-2/</link>
                        <pubDate>Fri, 21 Aug 2026 04:01:28 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been exploring the Barracuda CloudGen API for a few weeks, and I finally pulled off something cool! I managed to map all our site-to-site VPN connections and firewall rules visually. Se...]]></description>
                        <content:encoded><![CDATA[I've been exploring the Barracuda CloudGen API for a few weeks, and I finally pulled off something cool! I managed to map all our site-to-site VPN connections and firewall rules visually. Seeing everything laid out in one diagram makes our network topology so much clearer. &#x1f60a;

I used the API to pull the tunnel status and policy data, then fed it into a simple graphing tool. It's amazing what you can build once you get past the initial setup. Has anyone else used the API for custom reporting or dashboards? I'd love to hear what you've automated.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>gracel</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/just-built-a-map-of-all-our-site-connections-using-their-api-data-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Barracuda CloudGen to Cato Networks - 6 month report</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/migrated-from-barracuda-cloudgen-to-cato-networks-6-month-report/</link>
                        <pubDate>Wed, 19 Aug 2026 23:16:21 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I’ve been lurking for a while, reading up on different SASE/security platforms. I wanted to share my team&#039;s experience because I remember feeling pretty lost when we started thi...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I’ve been lurking for a while, reading up on different SASE/security platforms. I wanted to share my team's experience because I remember feeling pretty lost when we started this process.

We migrated from Barracuda CloudGen Firewalls (we had a pair at our main and colo sites) to Cato Networks about six months ago. The main drivers were simplifying our multi-site connectivity (we added three small remote offices) and managing a shift to more cloud apps. With Barracuda, every new site or major change felt like a big network project. The CloudGen Central Manager helped, but the overall architecture still felt very hardware-focused to us.

Here are a few concrete things I noticed:

The biggest shift for us was moving from managing boxes to a single management pane for firewall, SD-WAN, and secure web gateway. In Cato, setting up a new site was just shipping a small appliance and plugging it in. Policy for all sites is in one place. With Barracuda, even with CloudGen, we were still thinking about individual unit configurations and VPN tunnels.

Pricing was different. Barracuda felt like a known capital expense, but the ongoing management complexity had a hidden cost for our small IT team. Cato is a straightforward per-site/user subscription. For our size, it came out comparable, but the operational load on my team is definitely lower now, which was a huge win.

I do miss some of the granular reporting we could get from the Barracuda boxes for deep packet inspection. Cato's reporting is clean and actionable for security events, but sometimes I feel like I have to take their word for some of the optimization metrics. It's more of a black box.

Overall, the migration was smoother than I feared. We ran in parallel for a month. The hardest part wasn't the technical cutover, but changing our own internal mindset from managing tunnels to thinking about a global network cloud. For our needs in a distributed setup, it’s been a positive change. I’m curious if others here have made a similar switch, or if you’ve looked at Cato and decided to stick with Barracuda for specific reasons?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>emilyk4</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/migrated-from-barracuda-cloudgen-to-cato-networks-6-month-report/</guid>
                    </item>
							        </channel>
        </rss>
		