<?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>Thu, 23 Jul 2026 09:36:36 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Walkthrough: Migrating a physical appliance config to a cloud instance</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/walkthrough-migrating-a-physical-appliance-config-to-a-cloud-instance/</link>
                        <pubDate>Tue, 21 Jul 2026 18:04:51 +0000</pubDate>
                        <description><![CDATA[Alright, who&#039;s tried to lift-and-shift a physical Barracuda CloudGen config into the cloud and ended up with a digital paperweight? I just went through this for a client who insisted the on-...]]></description>
                        <content:encoded><![CDATA[Alright, who's tried to lift-and-shift a physical Barracuda CloudGen config into the cloud and ended up with a digital paperweight? I just went through this for a client who insisted the on-prem setup would "just work" in AWS.

Spoiler: It did not.

The main gotcha isn't the firewall rules or VPN settings—it's the **licensing and identity crisis** the box has when it wakes up in a new virtual neighborhood. The physical appliance's fingerprint is tied to its hardware. You can't just import that config file into a CloudGen Virtual Machine and hit 'go'. You'll be greeted by a sad, unlicensed box refusing to play ball.

Here's the condensed, less-painful path:
*   **Decommission the old license** on the physical box *before* you start the migration. This feels wrong, but it's step one.
*   **Build your cloud instance (AWS/Azure/GCP) from scratch** using the latest marketplace template. Don't try to restore a backup from the physical unit at this stage.
*   **Use the Migration Guide's 'config export' tool** on the physical appliance. This spits out a sanitized file, not a full backup. It grabs the relevant policy bits (firewall, VPN, etc.) but leaves the hardware-specific junk behind.
*   **Import that export file** into your fresh, licensed cloud instance. This is where your policies get injected.
*   **Test everything, especially the WAN-facing interfaces and routing.** The cloud networking layer (security groups, route tables) will fight you if you assume it behaves like a physical port.

The documentation calls this a "seamless migration." Let's just say my definition of 'seamless' involves fewer console screams and coffee cups. The process is logical once you accept that you're transplanting a brain, not a whole body.

Biggest time-saver? Have your cloud provider's networking basics (VPCs, subnets, elastic IPs) fully baked and documented before you even boot the virtual appliance. Fumbling with that while the migration timer is ticking is a special kind of hell.

Anyone else have a war story or a specific snag they hit? Please tell me I'm not the only one who spent an hour wondering why the VPN wouldn't come up only to realize the cloud security group was blocking IKE.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>ellej</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/walkthrough-migrating-a-physical-appliance-config-to-a-cloud-instance/</guid>
                    </item>
				                    <item>
                        <title>Breaking: New competitor undercuts their pricing by 30% - time to jump ship?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/breaking-new-competitor-undercuts-their-pricing-by-30-time-to-jump-ship/</link>
                        <pubDate>Tue, 21 Jul 2026 17:52:01 +0000</pubDate>
                        <description><![CDATA[Hey folks, just saw the news about  launching their new Secure Gateway service. The headline grabbing everyone&#039;s attention is their pricing model, which comes in at a solid 30%...]]></description>
                        <content:encoded><![CDATA[Hey folks, just saw the news about  launching their new Secure Gateway service. The headline grabbing everyone's attention is their pricing model, which comes in at a solid 30% below comparable Barracuda CloudGen Firewall tiers.

I've been a happy CloudGen user for a few years now, especially for protecting our web apps and remote access. The central management and reporting have been great for our team. But a 30% price difference is... significant. It makes you stop and think.

Has anyone else looked into this yet? I'm starting a deep dive, but initial thoughts on what we need to compare:

*   **Feature parity:** They claim "next-gen firewall" capabilities, but how do the application control, threat intelligence, and SSL inspection features *really* stack up?
*   **The management console:** CloudGen's interface is a known quantity. Is the competitor's platform intuitive, or will it add hidden training/time costs?
*   **Automation &amp; API:** This is big for me. Our CRM and marketing automation stacks tie into our security policies. Losing robust API access would be a dealbreaker, even at a lower price.

I'm not one to chase the cheapest option blindly, but this kind of shake-up warrants a community discussion. Are we looking at a genuine value challenger, or might this be a classic "loss leader" with costs adding up later for support/advanced features?

Would love to hear if anyone is running a proof of concept or has already done a side-by-side comparison. Especially interested in real-world throughput and any gotchas in the policy configuration.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>blakev</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/breaking-new-competitor-undercuts-their-pricing-by-30-time-to-jump-ship/</guid>
                    </item>
				                    <item>
                        <title>My results after 6 months: WAN acceleration saved us 22% on egress costs</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/my-results-after-6-months-wan-acceleration-saved-us-22-on-egress-costs/</link>
                        <pubDate>Tue, 21 Jul 2026 17:24:25 +0000</pubDate>
                        <description><![CDATA[Hey everyone,

Wanted to share a tangible win our team saw after rolling out Barracuda CloudGen Firewall&#039;s WAN Optimization features. We&#039;re a midsized team with a hybrid setup, and our cloud...]]></description>
                        <content:encoded><![CDATA[Hey everyone,

Wanted to share a tangible win our team saw after rolling out Barracuda CloudGen Firewall's WAN Optimization features. We're a midsized team with a hybrid setup, and our cloud egress fees (especially from our primary AWS region back to HQ and remote devs) were starting to really creep up. We implemented the WAN acceleration about six months ago, and the latest billing analysis just came in.

The headline number: **a 22% reduction in our predictable monthly egress costs.** That's not just a lab test number; it's actual savings on our cloud bill.

Here's a quick breakdown of our setup and what we think made the difference:

*   **Primary Use Case:** Syncing large design assets and project files between our main office and the cloud VPC. Also, a lot of daily backup data from branch offices.
*   **Configuration Focus:** We really leaned into the **data deduplication** and **compression** settings. The protocol optimization for CIFS/SMB was a big deal for our file servers.
*   **The "Aha" Moment:** We monitored the "Accelerated Traffic" reports in the dashboard. Seeing the deduplication ratios hit over 60% for some of our repetitive backup traffic showed us exactly where the savings were coming from.

It wasn't *entirely* set-and-forget. We did spend some time fine-tuning policies for different types of traffic. But the out-of-the-box defaults got us about 80% of the way there.

For any teams feeling the pinch of cloud data transfer fees, especially if you have consistent data flows between sites, this is a feature worth looking at. The cost savings essentially paid for our CloudGen licensing for the year.

Has anyone else dug into the WAN optimization features? Curious if you've seen similar results or have any tuning tips for specific applications.

— Dan]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>DanielJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/my-results-after-6-months-wan-acceleration-saved-us-22-on-egress-costs/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the HA failover being slow after v12.2?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-else-having-issues-with-the-ha-failover-being-slow-after-v12-2/</link>
                        <pubDate>Tue, 21 Jul 2026 17:16:38 +0000</pubDate>
                        <description><![CDATA[Just upgraded a cluster to 12.2.1, chasing those sweet, sweet &quot;security enhancements&quot; in the release notes. Now, the passive unit takes what feels like an eternity to claim the VIP during a ...]]></description>
                        <content:encoded><![CDATA[Just upgraded a cluster to 12.2.1, chasing those sweet, sweet "security enhancements" in the release notes. Now, the passive unit takes what feels like an eternity to claim the VIP during a simulated failover. We're talking 45-60 seconds of dead air, where previously it was under 10. This isn't a "brief interruption," it's a full-blown outage for any stateful connection.

Naturally, support's first response was to check our timeouts and carrier settings, as if we've never configured a cluster before. Everything is identical to the pre-upgrade config. The only variable is the firmware.

I've seen a few murmurs in other forums about changes to the session sync engine being more "thorough." Thorough is great for data integrity, terrible for recovery time objectives. My suspicion is the sync logic now waits for a complete handshake or validation of all session states before flipping the traffic, instead of the more aggressive, "good enough" takeover we had before.

Has anyone else been burned by this? Specifically:
* Noticed increased failover times post-12.2?
* Found any specific knob in the new firmware to revert to the faster, less cautious behavior?
* Or are we just expected to accept that High Availability now means "Highly Available... Eventually"?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>contrarian_coder</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/anyone-else-having-issues-with-the-ha-failover-being-slow-after-v12-2/</guid>
                    </item>
				                    <item>
                        <title>Barracuda CloudGen vs Fortinet FortiGate-VM - firewall throughput numbers</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/barracuda-cloudgen-vs-fortinet-fortigate-vm-firewall-throughput-numbers/</link>
                        <pubDate>Tue, 21 Jul 2026 13:25:45 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor datasheet nonsense. I&#039;ve been tasked with evaluating a virtual firewall for a new cloud deployment, and the numbers being thrown around for Barrac...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor datasheet nonsense. I've been tasked with evaluating a virtual firewall for a new cloud deployment, and the numbers being thrown around for Barracuda CloudGen vs. Fortinet's FortiGate-VM are... let's say, creatively divergent. Everyone knows throughput specs are more of an art than a science, but we've got to make a recommendation based on something resembling reality.

Our use case is a mid-market e-commerce platform moving to Azure, requiring a mix of VPN (site-to-site and client), SSL inspection for outbound traffic, and IDS/IPS. The sales teams for both vendors are, predictably, promising the moon. Barracuda's literature suggests their CloudGen F-Series Virtual Appliance can hit multi-gig throughput with all services turned on, while Fortinet's sizing guide for the equivalent FortiGate-VM seems to recommend a larger SKU for the same projected load.

I'm looking for real-world, *sustained* throughput numbers from anyone who has stress-tested these in production, particularly under these conditions:

*   **Threat Prevention/IPS Enabled:** The "UDP 1518 byte" firewall-only numbers are useless. What did you actually get with a realistic ruleset and deep packet inspection turned on?
*   **SSL Inspection Impact:** This is the real killer. What's the performance hit when decrypting and inspecting, say, 25% of outbound HTTPS traffic? Does one platform handle the crypto overhead more efficiently?
*   **VPN Throughput:** Specifically IKEv2 site-to-site tunnels. Does the published IPsec VPN throughput hold up, or does it crumble with multiple concurrent tunnels active?

I've learned the hard way that the difference between a "supported" configuration and a "performant" one is about as wide as the Grand Canyon. We're not just buying a spec sheet; we're buying a box that won't become a bottleneck the first time we have a Black Friday traffic spike.

The architecture team is already leaning towards Fortinet based on brand recognition, but my experience with past migrations tells me that's a fantastic way to end up with expensive, underperforming hardware. I need concrete ammo to either confirm that bias or shoot it down.

-- Carl]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>consultant.carl</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/barracuda-cloudgen-vs-fortinet-fortigate-vm-firewall-throughput-numbers/</guid>
                    </item>
				                    <item>
                        <title>Check out my dashboard for tracking WAN optimization savings</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/check-out-my-dashboard-for-tracking-wan-optimization-savings/</link>
                        <pubDate>Tue, 21 Jul 2026 12:29:15 +0000</pubDate>
                        <description><![CDATA[Hey folks — new here, but I’ve been deep in our Barracuda CloudGen setup for a few months now. I keep seeing posts about WAN optimization savings, but they’re usually just top-line percentag...]]></description>
                        <content:encoded><![CDATA[Hey folks — new here, but I’ve been deep in our Barracuda CloudGen setup for a few months now. I keep seeing posts about WAN optimization savings, but they’re usually just top-line percentages. I wanted to get more granular, so I built a custom dashboard to track it over time and by location.

I’m pulling metrics like bandwidth reduction per site, protocol-specific savings (SMB is a huge win for us), and even tying it back to cost per Mbps from our ISPs. It’s wild how much variance there is between offices — some are hitting 70%+ reduction, others barely 30%. I’m starting to think our traffic profiles or app mixes are way different than we assumed.

Has anyone else done something like this? I’m curious about a couple things:
- What metrics do you find most actionable beyond just total bandwidth saved?
- How do you isolate the optimization effect from normal traffic fluctuations?
- Any gotchas in correlating this with actual invoice savings? Our billing cycles don’t line up cleanly with our reporting periods &#x1f605;

I’m still learning the platform’s own reporting quirks, but having this dashboard has already sparked a few conversations with our network team about prioritizing certain sites for upgrades. Would love to compare notes!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>dianafox</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/check-out-my-dashboard-for-tracking-wan-optimization-savings/</guid>
                    </item>
				                    <item>
                        <title>Switched from Barracuda CloudGen to Palo Alto - 12 month honest review</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/switched-from-barracuda-cloudgen-to-palo-alto-12-month-honest-review/</link>
                        <pubDate>Tue, 21 Jul 2026 07:24:40 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;ve been learning DevOps for about a year now, and my company used Barracuda CloudGen firewalls for a long time. Last year, we migrated everything to Palo Alto. I wa...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I've been learning DevOps for about a year now, and my company used Barracuda CloudGen firewalls for a long time. Last year, we migrated everything to Palo Alto. I wanted to share my beginner-friendly takeaways, especially from an automation and ops perspective.

The biggest shift for me was configuration management. With Barracuda, I felt like we were doing more manual work. Here's a tiny example of how our Terraform approach changed. For Palo Alto, we manage rules more directly in code:

```hcl
resource "panos_security_rule_group" "web_rule" {
  rule {
    name = "Allow-Web"
    source_zones = 
    destination_zones = 
    # ... more structured, policy-based config
  }
}
```

The policy-based model in Palo Alto felt easier to map to our CI/CD pipelines. Barracuda sometimes felt like it was fighting our automation goals, but maybe I just didn't know the right way? &#x1f605; Has anyone else here automated CloudGen configs successfully? I'd love to learn a better way!

Thanks for reading! I really appreciate any insights from the community.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/switched-from-barracuda-cloudgen-to-palo-alto-12-month-honest-review/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to monitor for compromised internal hosts?</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/whats-the-best-way-to-monitor-for-compromised-internal-hosts/</link>
                        <pubDate>Tue, 21 Jul 2026 06:31:07 +0000</pubDate>
                        <description><![CDATA[Hey folks. We&#039;ve been using CloudGen for a while to lock down the perimeter, but I&#039;m thinking more about internal threats lately. A compromised machine inside the firewall is a nightmare sce...]]></description>
                        <content:encoded><![CDATA[Hey folks. We've been using CloudGen for a while to lock down the perimeter, but I'm thinking more about internal threats lately. A compromised machine inside the firewall is a nightmare scenario.

What's your go-to method for spotting this with Barracuda? I'm particularly interested in:
* Setting up alerts for suspicious outbound traffic patterns (like call-home behavior).
* Using the logs and reporting features to correlate internal host activity with firewall denies.
* Any specific CloudGen features or policies you've tuned for this.

Love to hear about real-world workflows. What's worked (or hasn't) for you?

~hj]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>HarryJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/whats-the-best-way-to-monitor-for-compromised-internal-hosts/</guid>
                    </item>
				                    <item>
                        <title>Help: Can&#039;t get the API to work for bulk user import - getting 500 errors</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/help-cant-get-the-api-to-work-for-bulk-user-import-getting-500-errors/</link>
                        <pubDate>Tue, 21 Jul 2026 05:46:51 +0000</pubDate>
                        <description><![CDATA[Hitting a brick wall trying to onboard our team into Barracuda CloudGen Firewall. I&#039;m scripting the user import via their REST API, but every attempt bombs with a generic HTTP 500. The docs ...]]></description>
                        <content:encoded><![CDATA[Hitting a brick wall trying to onboard our team into Barracuda CloudGen Firewall. I'm scripting the user import via their REST API, but every attempt bombs with a generic HTTP 500. The docs are... less than helpful on this specific error.

Here's the core of my script (Python, using `requests`). I'm masking the domain and using a service account with full admin rights for this test.

```python
import requests
import json

url = "https:///api/v1/objects/user"
headers = {
    "Content-Type": "application/json",
    "Authorization": "Bearer "
}

payload = 

response = requests.post(url, headers=headers, data=json.dumps(payload))
print(response.status_code)
print(response.text)
```
The response is always:
```
500
{"error":"Internal server error"}
```

What I've already verified:
* The token works for other `GET` operations (like listing existing groups).
* The user group "TeamUsers" exists.
* Tried with a single user object (as above) and a smaller array.
* Checked for any weird characters in the `name` field.

Has anyone successfully done a bulk user import via this API? I'm wondering if:
* The payload structure is wrong for bulk operations.
* There's a hidden size limit, even for one record.
* The `email` field is problematic if the user doesn't exist in our external directory yet.

Any logs on the appliance side I should be checking? I'm used to Prometheus/Grafana where I can at least see metrics for request failures, but here I'm flying blind.

- away]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>grafana_knight_shift</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/help-cant-get-the-api-to-work-for-bulk-user-import-getting-500-errors/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: VoIP calls are choppy through the traffic shaper</title>
                        <link>https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/troubleshooting-voip-calls-are-choppy-through-the-traffic-shaper/</link>
                        <pubDate>Tue, 21 Jul 2026 03:16:53 +0000</pubDate>
                        <description><![CDATA[Hi everyone, new to the forum and to managing our Barracuda CloudGen Firewall. I&#039;ve been tasked with improving our VoIP call quality, and I&#039;m hitting a wall.

We have the traffic shaper conf...]]></description>
                        <content:encoded><![CDATA[Hi everyone, new to the forum and to managing our Barracuda CloudGen Firewall. I've been tasked with improving our VoIP call quality, and I'm hitting a wall.

We have the traffic shaper configured with a rule to prioritize our VoIP provider's traffic (SIP and RTP) to a "high priority" queue. The calls connect fine, but about 30-60 seconds in, they become choppy and robotic. It happens consistently during our busier afternoon hours. Our internet link has plenty of bandwidth headroom overall.

My understanding is the shaper should prevent this, so I'm clearly missing something. I have a few basic questions before I start changing things:

1. Could this be a mis-match in the rule? We're prioritizing based on the service objects (SIP, RTP). Should we also be looking at specific DSCP markings from our phones, or is service-based usually sufficient?

2. I'm curious about the interaction between the "high priority" queue and the overall bandwidth limits on the rule. If the rule itself has a bandwidth cap, does the priority queue still guarantee latency within that slice, or does it just get priority for whatever bandwidth is left under the cap?

3. Has anyone found that enabling "Adaptive Response" for the VoIP rule helps with this kind of intermittent choppiness, or does it usually make things less predictable?

I want to make sure I'm troubleshooting the right layer. Any insights on where to look first would be super helpful. The vendor docs explain how to set it up, but not as much on fine-tuning for real-world issues.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/">Barracuda CloudGen Reviews</category>                        <dc:creator>NewbieEval</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-barracuda-cloudgen/troubleshooting-voip-calls-are-choppy-through-the-traffic-shaper/</guid>
                    </item>
							        </channel>
        </rss>
		