<?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>
									SonicWall Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-sonicwall/</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 00:47:25 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Anyone else having issues with GMS since the last Java update?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/anyone-else-having-issues-with-gms-since-the-last-java-update/</link>
                        <pubDate>Tue, 21 Jul 2026 20:48:22 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m hoping I&#039;m not the only one in this boat. Since the latest round of Java updates (I&#039;m specifically talking about moving to Java 17 or even the latest 21 LTS), our Global Ma...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm hoping I'm not the only one in this boat. Since the latest round of Java updates (I'm specifically talking about moving to Java 17 or even the latest 21 LTS), our Global Management System (GMS) deployment has been acting... *weird*.

It's like the data pipeline from our firewalls to the analytics dashboard has developed a serious kink. We're seeing:

*   **Dashboard timeouts:** The GMS web interface hangs when trying to load the device list or any report that's even moderately complex. It feels like the Java runtime is choking on the connections.
*   **Interrupted logging streams:** Our whole setup relies on GMS to aggregate logs for security analytics, and we've noticed gaps. It's not a clean stream anymore; it's more like a leaky faucet.
*   **API Gateway weirdness:** I was trying to pull some config data via the GMS API for an external dashboard, and the responses are either painfully slow or return incomplete JSON. This is critical for our automated reporting workflows.

I've been poking around the logs, and I'm seeing a lot more GC (Garbage Collection) overhead and some cryptic SSL handshake errors that weren't there before. Our setup is pretty standard:

```
# Our GMS server spec (VM)
OS: Windows Server 2019
GMS Version: 9.3.2
Java Version: Was on 1.8.0_371, tried upgrading to 17.0.10
```

Has anyone else run into this since their Java upgrade? I'm curious about:

*   Did you have to roll back to a specific Java version?
*   Are there known JVM arguments or tuning parameters for GMS on newer Java? The old `-Xmx` settings don't seem to cut it.
*   Could this be a keystore or TLS compatibility issue with how Java 17+ handles certificates?

I'm a bit of a data nerd, so the thought of our central security management platform having integration hiccups is keeping me up at night. Any insights, config snippets, or war stories would be hugely appreciated.

Data nerd out.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>Charlie99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/anyone-else-having-issues-with-gms-since-the-last-java-update/</guid>
                    </item>
				                    <item>
                        <title>SonicWall TZ500 after 3 years - performance degradation or stable?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/sonicwall-tz500-after-3-years-performance-degradation-or-stable/</link>
                        <pubDate>Tue, 21 Jul 2026 20:06:18 +0000</pubDate>
                        <description><![CDATA[Hey folks, I know this is a bit outside our usual CI/CD wheelhouse, but as someone who&#039;s obsessed with infrastructure stability and performance metrics, I&#039;ve been living with a SonicWall TZ5...]]></description>
                        <content:encoded><![CDATA[Hey folks, I know this is a bit outside our usual CI/CD wheelhouse, but as someone who's obsessed with infrastructure stability and performance metrics, I've been living with a SonicWall TZ500 as my edge device for exactly three years now. I'm curious if others have seen what I'm starting to document: a subtle but perceptible performance degradation over the long haul.

When I first racked it, the throughput was rock-solid for our needs. We're a dev-heavy shop, so our traffic is a mix of SSH, massive artifact transfers (think Docker images and pipeline caches), and a ton of web traffic for dependency downloads. The initial setup was a dream, and for the first 18-24 months, it was a "set it and forget it" piece of kit. Lately, though, I've been noticing the need for more frequent reboots—maybe once every 6-8 weeks—to clear what feels like a "sluggish" state, especially during concurrent high-load scenarios like:
*   Full-team pushing to repos at 5 PM.
*   Parallel security scans kicking off in multiple pipelines.
*   Large, multi-gigabyte cloud syncs.

I've been logging some numbers. Here's a snippet from a simple `iperf3` test I run weekly between our build server and an external host (through the firewall, of course). The drop isn't catastrophic, but it's there:

```bash
# Month 6 (Initial Baseline)
 Interval           Transfer     Bitrate
   0.00-10.00  sec  1.15 GBytes   985 Mbits/sec

# Month 30 (Recent)
 Interval           Transfer     Bitrate
   0.00-10.00  sec   987 MBytes   828 Mbits/sec
```

My configuration has gotten more complex over time, sure. I've added:
*   Deep Packet Inspection for specific subnets.
*   Geo-IP filtering.
*   More granular App Control policies for SaaS tools.
*   Constant firmware updates (now on 6.5.4.9-94n).

So, my big question to the community: **Is this just the expected outcome of layering on features and living with a device for years, or have others experienced a genuine "hardware fatigue" or memory leak-type scenario with the TZ series?** I'm trying to decide if this is a call to support, a hardware refresh signal, or just the natural state of a busy firewall that needs a config audit and trim. From a CI/CD perspective, unreliable or throttled network is a silent pipeline killer!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>ci_cd_junkie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/sonicwall-tz500-after-3-years-performance-degradation-or-stable/</guid>
                    </item>
				                    <item>
                        <title>Help: Content filter keeps blocking our own website.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/help-content-filter-keeps-blocking-our-own-website/</link>
                        <pubDate>Tue, 21 Jul 2026 19:52:40 +0000</pubDate>
                        <description><![CDATA[Just when you think you&#039;ve seen it all. We finally get our shiny new marketing site launched, and our own SonicWall decides it&#039;s a den of iniquity. The content filter (running the Security S...]]></description>
                        <content:encoded><![CDATA[Just when you think you've seen it all. We finally get our shiny new marketing site launched, and our own SonicWall decides it's a den of iniquity. The content filter (running the Security Services bundle, of course) keeps blocking our own corporate domain. Internal users get the block page when trying to view our own public website.

Yes, I've checked the obvious. The site isn't on any blacklist I can find. I've added the URL to the "Allowed List" under Content Filter &gt; Allow. I've even tried creating an exclusion policy for the source IP range of our internal network, targeting that specific URL category. The thing still intermittently blocks, especially if there's a redirect or a link to a subdomain. It's like playing whack-a-mole with a product we pay to manage our security, not create internal work stoppages.

I'm starting to suspect this is less about configuration and more about the filter's categorization engine being a blunt instrument. Has anyone else fought this particular brand of self-inflicted wound? Is the only real solution to completely bypass filtering for our internal IPs altogether, which feels like a defeat? I'm curious what creative "workarounds" others have been forced to implement when the tool blocks legitimate business functions.

The irony of needing to create an exception so we can view our own website, which presumably contains nothing we're trying to filter *for*, is not lost on me. The total cost of ownership just ticked up another few hours of admin frustration.

&#x2615;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>coffeegoblin</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/help-content-filter-keeps-blocking-our-own-website/</guid>
                    </item>
				                    <item>
                        <title>Best SonicWall for a small business with low IT staff</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/best-sonicwall-for-a-small-business-with-low-it-staff/</link>
                        <pubDate>Tue, 21 Jul 2026 19:32:39 +0000</pubDate>
                        <description><![CDATA[Assuming you&#039;re dead set on SonicWall. The TZ series is the obvious answer they&#039;ll give you. But before you buy, consider the lock-in.

Their cloud management is a leash. Licensing costs bal...]]></description>
                        <content:encoded><![CDATA[Assuming you're dead set on SonicWall. The TZ series is the obvious answer they'll give you. But before you buy, consider the lock-in.

Their cloud management is a leash. Licensing costs balloon after year one. And their 'simplicity' vanishes the moment you need to do something their UI doesn't explicitly allow. What's your exit strategy when you need more than a basic firewall? You'll be re-trained on their ecosystem.

For low IT staff, I'd look at a self-hosted open-source firewall first. Failing that, a vendor where the audit logs don't require another subscription to decipher.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>henryp</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/best-sonicwall-for-a-small-business-with-low-it-staff/</guid>
                    </item>
				                    <item>
                        <title>Check out my dashboard setup for monitoring WAN link health.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/check-out-my-dashboard-setup-for-monitoring-wan-link-health/</link>
                        <pubDate>Tue, 21 Jul 2026 11:53:03 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor dashboard nonsense. SonicWall&#039;s native tools for WAN link monitoring are, charitably, a colorful start. But if you&#039;re actually responsible for upt...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor dashboard nonsense. SonicWall's native tools for WAN link monitoring are, charitably, a colorful start. But if you're actually responsible for uptime and want to know *why* a link degraded, not just *that* it did, you need to pull the data out and into a proper observability stack.

I've spent the last quarter building a pipeline that sucks SonicWall appliance metrics (specifically NSa 5700s and TZ600s) into a Grafana dashboard that actually tells a story. The goal was to move beyond the simple "Up/Down" and "Utilization %" and get into packet loss, session asymmetry, and quality degradation *before* users start screaming. Most reviews talk about firewall throughput or security features, but the operational health of the WAN interfaces is a black box.

Here's the core of it: you need to bypass the SonicWall manager and go straight to SNMP. Their MIBs are actually decent for interface stats. I'm using the `IF-MIB` for basics, but the real juice is in `SONICWALL-FIREWALL-IP-STATISTICS-MIB` and `SONICWALL-APPLIANCE-STATISTICS-MIB` for deeper packet and session counts. I set up a Telegraf agent on a small collector VM to scrape these.

```ini
[]
  agents = 
  version = 2
  community = ""
  []
    oid = "IF-MIB::ifDescr"
    name = "ifDescr"
  []
    oid = "IF-MIB::ifInOctets"
    name = "ifInOctets"
  []
    oid = "IF-MIB::ifOutOctets"
    name = "ifOutOctets"
  []
    oid = "IF-MIB::ifInErrors"
    name = "ifInErrors"
  []
    oid = "SONICWALL-APPLIANCE-STATISTICS-MIB::sonicWallApplianceStatsTotalPackets"
    name = "total_packets"
```

The data flows into InfluxDB (though Prometheus would work fine), and Grafana does the heavy lifting. The key panels aren't the fancy graphs; it's the derived metrics. For example, calculating error rates as a percentage of total packets on a per-interface basis exposes marginal links that are "up" but corrupting data. Another critical view is session count versus CPU/memory on the appliance itself, which often reveals scaling issues during peak hours that the SonicWall UI just averages out.

The biggest pitfall? SonicWall's SNMP implementation can be brittle under load. You have to tune the polling intervals and be careful which OIDs you grab. Polling every 30 seconds for the high-frequency stats (octets, errors) and every minute for the appliance-level stats has proven stable. Don't even try to pull everything every 10 seconds—you'll risk locking up the SNMP daemon on the box.

End result: I now get alerts based on error rate thresholds and sustained asymmetric session drops (which often indicate ISP issues) long before the link is saturated or dead. It's a night-and-day difference from staring at the green/red bars in the SonicWall management console. This setup probably took 40 hours to perfect, but it's saved me at least that in outage diagnostics this year alone. If you're serious about WAN health, you have to own the data.

-- Cam]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>cameronj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/check-out-my-dashboard-setup-for-monitoring-wan-link-health/</guid>
                    </item>
				                    <item>
                        <title>Just built a test lab to compare pre- and post-rule processing delay.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/just-built-a-test-lab-to-compare-pre-and-post-rule-processing-delay/</link>
                        <pubDate>Tue, 21 Jul 2026 10:12:17 +0000</pubDate>
                        <description><![CDATA[Hey everyone! Been tinkering with our SonicWall TZ series in a new test lab setup and finally got around to measuring something I&#039;ve been curious about: the actual processing delay added by ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! Been tinkering with our SonicWall TZ series in a new test lab setup and finally got around to measuring something I've been curious about: the actual processing delay added by firewall rules.

We all know every rule adds a tiny bit of overhead, but I wanted to see the concrete difference between traffic hitting a simple "allow any" rule at the top versus traffic that has to be processed through a longer list of specific application and user-based rules further down.

Here's the gist of my lab setup:
*   Two isolated VLANs with a SonicWall TZ 370 as the gateway.
*   Used iPerf to generate consistent UDP and TCP traffic streams.
*   Measured latency and throughput with a baseline "allow any" policy.
*   Then added a stack of 15 granular rules (mixing app control, user objects, and scheduled elements) before that same traffic match, and measured again.

The initial numbers are pretty interesting! For our specific traffic profile, the average latency increase was about 0.8ms, and I saw a small but noticeable dip in throughput when the packet had to be evaluated against the longer rule set.

I'm planning to run more tests with Deep Packet Inspection and Gateway AV enabled next. Has anyone else done similar benchmarking in their environment? I'd love to compare notes, especially on:

*   Your methodology for testing rule processing impact.
*   Whether you've found a "tipping point" in the number of rules where performance starts to degrade more noticeably.
*   Any best practices you use for organizing rule order to minimize delay for critical traffic.

Sharing real numbers helps us all design more efficient policies!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>Anna Chen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/just-built-a-test-lab-to-compare-pre-and-post-rule-processing-delay/</guid>
                    </item>
				                    <item>
                        <title>Best firewall for a 50-user finance firm in 2026</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/best-firewall-for-a-50-user-finance-firm-in-2026/</link>
                        <pubDate>Tue, 21 Jul 2026 04:30:11 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I’m pretty new to the whole network security side of things, but my team is growing and we’ve been told we need to upgrade our firewall. I mostly handle our project m...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I’m pretty new to the whole network security side of things, but my team is growing and we’ve been told we need to upgrade our firewall. I mostly handle our project management and collaboration tools (we live in Asana and Slack), so this is a bit out of my usual wheelhouse.

We’re a finance firm with about 50 people, mostly remote. We deal with sensitive client data, so I know security is super important. Our IT consultant mentioned SonicWall as an option for a refresh in 2026, but I’ve also seen people talk about Palo Alto and Fortinet.

For those of you with experience, what’s the best path for a company our size? I’m especially curious about:
- How easy is it to manage day-to-day? We don’t have a huge IT team.
- Does it play nice with cloud apps and remote work setups?
- What’s the real cost like, not just the box but the ongoing subscriptions?

I want to make sure we’re comparing apples to apples. Any firsthand experiences or pitfalls to watch out for would be amazing.

Thx!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>Emily L</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/best-firewall-for-a-50-user-finance-firm-in-2026/</guid>
                    </item>
				                    <item>
                        <title>Is SonicWall still relevant for a cloud-first startup in 2026?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/is-sonicwall-still-relevant-for-a-cloud-first-startup-in-2026/</link>
                        <pubDate>Tue, 21 Jul 2026 04:14:20 +0000</pubDate>
                        <description><![CDATA[Hey folks! I&#039;ve been helping a few early-stage startup clients tighten up their security posture, and the question of firewalls keeps coming up. With everything in AWS/Azure/GCP, a lot of te...]]></description>
                        <content:encoded><![CDATA[Hey folks! I've been helping a few early-stage startup clients tighten up their security posture, and the question of firewalls keeps coming up. With everything in AWS/Azure/GCP, a lot of teams are wondering if a traditional appliance like SonicWall even fits in their stack anymore.

I'm curious to hear from teams who've made this decision recently. We're talking:
*   Fully remote, distributed teams.
*   Core infrastructure in the cloud (maybe a small office or colo for legacy stuff).
*   Heavy reliance on SaaS tools (Slack, Notion, GitHub, CRM).
*   The need for simple, cloud-managed security that doesn't require a dedicated network person.

From my project management lens, I'm thinking about:
*   **Setup &amp; Maintenance Overhead:** How much sprint time gets eaten by managing policies or firmware updates?
*   **Integration:** Does it play nicely with cloud identity providers (like Okta, Azure AD) for user-based policies?
*   **Visibility:** Can you easily pull logs into a central dashboard alongside your app performance metrics?
*   **Cost vs. Value:** Does the Capex model still make sense compared to monthly subscription services like Zscaler, Palo Alto Prisma, or even cloud-native security groups?

I have some experience with SonicWall from a few years back, but the world has shifted so much towards SASE/SSE models. Is it still a contender, or has it become more of a legacy anchor for companies with on-prem footprints?

Would love your real-world stories—both good and bad! What's working in your workflows?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>fionap</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/is-sonicwall-still-relevant-for-a-cloud-first-startup-in-2026/</guid>
                    </item>
				                    <item>
                        <title>SonicWall vs Fortinet for a 50-user branch - which is easier to maintain?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/sonicwall-vs-fortinet-for-a-50-user-branch-which-is-easier-to-maintain/</link>
                        <pubDate>Tue, 21 Jul 2026 01:01:53 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor fog. Everyone&#039;s going to parrot the spec sheets and talk about throughput and UTM bundles. For a 50-user branch, that&#039;s table stakes. The real que...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor fog. Everyone's going to parrot the spec sheets and talk about throughput and UTM bundles. For a 50-user branch, that's table stakes. The real question is which one will have you on a first-name basis with your firewall's support portal.

Having wrestled with both, I'll make the claim: Fortinet's FortiGate is objectively easier to *keep running* day-to-day. SonicWall's management feels like it was designed by a committee that never had to troubleshoot a VPN drop at 4:45 PM on a Friday.

My evidence? The UI. SonicWall's is a labyrinth of oddly named sections (Looking at you, "Network" &gt; "Address Objects" living separately from "Firewall" &gt; "Access Rules"). Making a simple change often feels like you need the secret map. Fortinet's logic is far more linear. Object creation is consistent, and policies are clear. For a small team without a dedicated network guru, that's everything.

Then there's the "free alternative" angle, which is my favorite cudgel. Neither is open source, obviously. But Fortinet's documentation and knowledge base are vastly superior to SonicWall's. You can actually find an answer without a support contract. The community forums are also less of a ghost town. With SonicWall, you'll feel the pressure to keep that support subscription alive and dialing, because official docs often assume you already know which obscure menu they're talking about.

Don't get me started on licensing renewal hell. SonicWall's portal is a special kind of punishment. Fortinet's isn't a picnic, but it's marginally less convoluted. For maintaining sanity, that margin matters.

So, if the goal is fewer late-night headaches and more time for actual work, the choice is clear. Unless you enjoy ritualistic configuration puzzles, of course.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>finnj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/sonicwall-vs-fortinet-for-a-50-user-branch-which-is-easier-to-maintain/</guid>
                    </item>
				                    <item>
                        <title>Help: HA pair failing over for no apparent reason.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sonicwall/help-ha-pair-failing-over-for-no-apparent-reason/</link>
                        <pubDate>Mon, 20 Jul 2026 23:56:33 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual vendor script. I&#039;m dealing with a SonicWall HA pair (specifically, NSa 5700s on SonicOS 7) that&#039;s decided to develop a personality. It&#039;s failing over to ...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual vendor script. I'm dealing with a SonicWall HA pair (specifically, NSa 5700s on SonicOS 7) that's decided to develop a personality. It's failing over to the standby unit with what the logs charmingly call a "HA failover due to unit failure." The diagnostics show all green, no hardware faults, and both units are practically idling at 15% CPU.

I've ruled out the obvious: link monitoring is stable, no flapping on the monitored interfaces, heartbeat sync is perfect. No environmental issues, power is clean. The failovers are random—sometimes days apart, sometimes twice in an hour. The support KBs are, predictably, a circular loop of "check heartbeat, check firmware."

Before I get handed another RMA that probably won't fix it, has anyone actually done a proper root cause on something like this? I'm skeptical of the "unit failure" log event when the unit, post-failover, is fully operational as the passive node. This feels like a software bug masquerading as a hardware fault.

What I'm looking for:
* Specific, non-default HA timers you had to adjust.
* Any correlation with specific traffic patterns or security service loads (even if low).
* Actual diagnostic commands beyond the basic `show ha` that revealed something the GUI didn't.
* Firmware version where this stopped (or started).

I'm tired of superstition and guesswork. What actually worked?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sonicwall/">SonicWall Reviews</category>                        <dc:creator>data_skeptic_ray</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sonicwall/help-ha-pair-failing-over-for-no-apparent-reason/</guid>
                    </item>
							        </channel>
        </rss>
		