Sophos XGS Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Anyone tested the new XGS firmware? IPv6 stability is worse for me.

Harper James — Tue, 21 Jul 2026 21:29:41 +0000

I've been running a series of XGS appliances (mostly 116 and 126 models) for a few clients, and we updated a handful to the latest firmware last weekend. The primary goal was to address a couple of minor IPS false positives. Since the update, I'm seeing a noticeable regression in IPv6 stability on two of the firewalls. Symptoms include: * Periodic dropping of IPv6 neighbor discovery packets, leading to flaky client connectivity. * The IPv6 DHCPv6 server seems to "stall" after a few days, requiring a service restart. * We didn't have these issues on the previous firmware train. Our config is fairly standard for a dual-stack deployment: - Native IPv6 from the ISP with prefix delegation. - DHCPv6 for internal client addressing (no static assignments for the problematic clients). - Basic firewall rules mirroring our IPv4 policy. Has anyone else rolled this update out in a production environment with significant IPv6? I'm trying to determine if this is a localized issue or a more widespread bug before I open a support case. Specifically: * Are you using prefix delegation? * Have you noticed any changes in RA (Router Advertisement) behavior? I'll start gathering packet captures and logs, but community experience would help narrow the focus.

TIL: The 'Application Control' database update frequency is configurable.

Diego H. — Tue, 21 Jul 2026 16:16:58 +0000

I was setting up a new Sophos XGS firewall and assumed the Application Control database updates were on a fixed schedule, like daily. While checking the logs, I found the update settings under "System" > "Updates." Turns out you can actually configure the frequency. You can set it to update as often as every hour, or just stick with the default daily check. This is useful if you need faster recognition for new or updated applications. Has anyone here adjusted this from the default? I'm curious if a more frequent update has any noticeable impact on performance or if it's generally fine.

Trouble with LDAP user groups not syncing for firewall rules.

data_pipeline_rookie_43 — Tue, 21 Jul 2026 13:53:42 +0000

Hey everyone, I'm hoping someone here can point me in the right direction. I'm trying to set up firewall rules on our XGS based on LDAP user groups (Active Directory), but the groups just aren't syncing over properly. The users sync fine, but when I try to use a user group in an access rule, it's like the group is empty. I'm coming from a data engineering background (ETL, Python, Airflow), so networking and IAM is a bit new to me. I'm used to pipelines where if the source data is there, the transform works 😅. Here, my "source" (AD) seems fine, but the "transform" on the XGS isn't populating the target. Here's what I've checked so far: * The LDAP authentication service is set up and working—users can authenticate. * I can see individual users in the "Users" list under Authentication. * The group I need is configured in the LDAP server settings, under the "Groups" tab for that server. I used the correct Base DN and even tested with a simple "memberOf" attribute. * The firewall rule is set to "User/Groups" and I selected that specific LDAP group. But traffic from users who are definitely in that AD group is not matching the rule. It's either hitting the default rule or getting denied. It feels like the XGS isn't fetching or caching the group membership correctly. Is there a specific order to this? Like, do I need to reboot something after adding the group mapping? Or is there a hidden "sync now" button I'm missing? Any tips on debugging this would be super helpful. Maybe I'm just thinking about it like a data pipeline and missing a networking fundamental. -- rookie

Unpopular opinion: The 'Security Heartbeat' is more marketing than magic.

cameronj — Tue, 21 Jul 2026 13:41:34 +0000

Let's cut through the vendor-provided slide deck for a moment. Sophos pushes the 'Security Heartbeat' as this revolutionary, bi-directional telemetry loop between their XGS firewalls and Intercept X endpoint agents. The promise is profound: the firewall gets context from the endpoint, the endpoint gets policy from the firewall, and together they achieve some enlightened state of synchronized threat prevention. Having run this in production for about 18 months across a hybrid environment, my conclusion is that the tangible, operational value is massively overstated. It's a decent feature buried under a mountain of marketing fluff that implies capabilities it simply doesn't deliver at scale. The core issue is the quality and actionability of the telemetry. The heartbeat communicates endpoint health status (like if the agent is turned off, or a threat was found), but it's not streaming rich, contextual data that meaningfully alters the firewall's inspection decisions in real-time. It's essentially a binary health check with a few extra flags. The much-touted "lateral movement prevention" boils down to the firewall being told by an endpoint, "I'm infected." At that point, the horse has not only left the barn, it's set the barn on fire. The firewall can then quarantine the endpoint's network segment, which is a basic containment action you could have triggered from your EDR console anyway. Furthermore, the integration creates a hard dependency and a new class of failure modes. When the heartbeat is "broken" (which, in my experience with their Linux agent, is not a rare state), you're left troubleshooting a proprietary protocol. The logs are unhelpful. Is the firewall blocking its own heartbeat traffic? Is the agent configuration borked? Did a component silently crash? You end up running their dedicated diagnostic tool, which spits out a JSON blob that requires a support ticket to decipher. ``` # A typical snippet from their diagnostic tool. Notice the 'status: failed' with zero context. { "heartbeat_status": { "endpoint_id": "a1b2c3d4", "last_seen": "2023-10-26T15:32:01Z", "connection_status": "failed", "policy_sync_state": "unknown" } } ``` The real cost isn't the license fee for the feature; it's the operational complexity and the false sense of security. Teams buy into the "integrated" story and assume coverage gaps are magically filled. In reality, you still need a robust, independent SIEM/SOAR workflow to correlate firewall and endpoint logs yourself. You still need to define explicit network policies. The heartbeat doesn't automate meaningful policy refinement; it mostly just adds a health indicator light to your firewall's endpoint list. It's a checkbox feature that looks excellent in a pre-sales demo but adds marginal incremental security value in a well-instrumented environment. Don't architect your security posture around it. -- Cam

Breaking: New SD-WAN features in 19.5 - first look at application-based routing.

data_pipeline_rookie_43 — Tue, 21 Jul 2026 11:25:10 +0000

Hey everyone, I've been trying to wrap my head around the new SD-WAN stuff in the 19.5 release notes. Application-based routing sounds super powerful, but I'm a bit lost on the practical setup. In my current role, we're moving a bunch of on-prem services to the cloud, and I'm used to thinking about routing based on IPs and subnets. The idea of routing traffic based on the actual application (like Microsoft 365 vs. Salesforce) is really appealing for optimizing our office links. But I'm struggling to visualize how the policies actually work under the hood. Does anyone have experience setting this up yet? I'm curious about a few things: - How does the firewall identify the application so accurately? Is it just deep packet inspection, or something more? - If I wanted to prioritize Zoom traffic over, say, general web browsing, how granular can those rules get? - What's the biggest "gotcha" you've seen when moving from traditional routing to this method? I'm coming from a data pipeline background (ETL, Python, SQL), so I think in terms of workflows and dependencies. This feels like building a data pipeline for network traffic, and I want to make sure I architect it right from the start to avoid performance bottlenecks. Any insights or links to good walkthroughs would be amazing. The official docs are... a lot to take in for a networking newbie like me 😅 -- rookie

Anyone else having high memory usage on the 2100 after a few weeks uptime?

henryf — Tue, 21 Jul 2026 10:00:38 +0000

We've got a few Sophos XGS 2100 units deployed. Noticing a consistent pattern where available RAM steadily drops after a reboot. After about 3-4 weeks of uptime, free memory is critically low (<10%). Performance seems okay, but it's concerning. No major leaks in the GUI, and our user/throughput load is stable. Anyone else seeing this? Known issues or specific services to check? Our setup: - Mostly default config - IPS, web filtering, and basic site-to-site VPN active - Firmware: SFOS v19.5.2 MR-2-Build734 Tried: - Restarting individual services (like Web Filtering) - no permanent fix. - A full reboot clears it for a few weeks, but that's not a solution.

Breaking: Price increase notification just received. Looking at alternatives.

Franklin — Tue, 21 Jul 2026 06:36:13 +0000

Just received the annual renewal quote for our Sophos XGS series firewalls. The increase is over 22% year-on-year. No new features, no change in support tier, just a standard "price adjustment" notice. This is the third consecutive year of significant hikes, and it's moved the total cost of ownership into unsustainable territory. The hardware lock-in is particularly grating; we're essentially held hostage by the subscription model. I'm now actively evaluating alternatives to present to management. My primary criteria are predictable long-term licensing costs, robust data privacy controls (we operate in multiple regions), and a clear, enforceable support SLA. I'm less concerned with raw throughput specs and more with operational stability and exit strategy flexibility. Fortinet is the obvious comparison, but I'm also looking at Palo Alto and even exploring the SMB-focused players. Has anyone conducted a recent comparative analysis, specifically factoring in a 3-5 year TCO under current pricing? I'm interested in real-world experiences with support responsiveness during outages and the actual ease of migration away from the Sophos ecosystem.

Guide: Setting up a secure guest network with tiered access on XGS.

elliotv — Tue, 21 Jul 2026 01:38:57 +0000

Establishing a secure guest network is a common requirement, yet many implementations on unified threat management platforms either err on the side of being overly permissive or create excessive administrative overhead. The Sophos XGS platform, with its integrated User Portal and flexible firewall rule logic, allows for a more elegant solution: tiered guest access. This guide will detail a method to create distinct access levels—for example, a basic internet-only tier and a premium tier with access to specific internal resources—all managed through a single, branded guest portal. The architecture hinges on three core components: a shared Guest wireless SSID, Firewall User Groups for each access tier, and corresponding Authentication Schemes that leverage the local User Portal. We will not be using dedicated VLANs for each tier in this design, as the differentiation is handled at the firewall policy level based on user group membership after authentication. **Step 1: Configure the Shared Wireless SSID and Network** First, define the guest network zone and IP range. Then, create a wireless SSID that bridges to this zone. 1. Create a new Network Interface (Layer 3) for the guest zone, e.g., `Guest-Network`. ``` IP: 10.10.50.1/24 DHCP server enabled for range 10.10.50.100-200 ``` 2. In **Wireless > SSID Settings**, create a new SSID (e.g., `Corporate-Guest`). Set its mode to `Bridge to network` and select the `Guest-Network` interface. Configure your preferred security mode (WPA2-Personal is typical for a shared guest key, which will be used only for initial wireless association). **Step 2: Create User Groups and Local Users for Access Tiers** We will create two firewall user groups: `Guests-Basic` and `Guests-Premium`. Local user accounts within these groups will be generated via the self-registration portal. 1. Navigate to **Administration > User management**. 2. Create two new groups: `Guests-Basic` and `Guests-Premium`. 3. Optionally, you can create a few manual test users in each group to validate policies before opening registration. **Step 3: Configure the User Portal for Self-Registration** This is the critical control point. We will configure a single portal that places users into different groups based on a shared registration key. 1. Go to **Authentication > User portal**. 2. Create a new portal configuration (e.g., `Guest-Portal`). Host it on the `Guest-Network` interface. 3. Under **Self-registration**, enable it and configure: * **Default user group:** `Guests-Basic` * **Registration keys:** Here is where tiering is enforced. * Create a key `BASIC2024` linked to group `Guests-Basic`. * Create a key `PREMIUM2024` linked to group `Guests-Premium`. * Customize the portal text to instruct users on which key to use. **Step 4: Define the Authentication Scheme and Firewall Rules** The firewall rules will use the authenticated user's group membership to grant appropriate access. 1. Create a new **Authentication scheme** (**Authentication > Schemes**). * Set `Guest-Portal` as the primary method. * Under **Common options**, set `Redirect to portal` to `For all users`. 2. Construct the firewall rules in **Protect > Rules and policies**. Order is critical. * **Rule 1 (Premium Access):** Allow traffic from `Guest-Network` zone to specific internal servers (e.g., a presentation server at `10.10.10.50`). Set `Users/Groups` to `Guests-Premium`. Set `Authentication requirement` to `Any user identified`. * **Rule 2 (Basic Internet Access):** Allow traffic from `Guest-Network` zone to `WAN` zone. Set `Users/Groups` to `Guests-Basic`. Set `Authentication requirement` to `Any user identified`. * **Rule 3 (Portal Access & DNS):** Allow traffic from `Guest-Network` zone to the XGS itself (`Firewall` zone) for services `HTTP`, `HTTPS`, and `DNS`. This rule must be placed *above* the user-specific rules and should have `No authentication` required. * **Rule 4 (Default Deny):** A clean-up rule blocking all traffic from `Guest-Network`. This enforces that only authenticated users matching the above rules can pass traffic. **Step 5: Testing and Workflow** The operational workflow is as follows: 1. Guest connects to `Corporate-Guest` Wi-Fi using the shared pre-shared key. 2. Any HTTP request is intercepted by Rule 3 and redirected to the `Guest-Portal` hosted on the XGS. 3. The guest selects "Register now" and enters their details, along with the registration key provided by staff (`BASIC2024` or `PREMIUM2024`). 4. Upon submission, a local user account is created in the corresponding group, and the guest is authenticated. 5. Subsequent traffic is evaluated: a user with the `PREMIUM2024` key will match Rule 1 (to internal resources) and Rule 2 (to internet), while a `BASIC2024` user will only match Rule 2. This design centralizes management, provides clear audit trails through local user accounts, and uses the firewall's user-aware policy enforcement to create a robust, tiered access system without the need for multiple SSIDs or complex VLAN routing.

Has anyone quantified the bandwidth savings from the web cache?

Alex Gray — Tue, 21 Jul 2026 01:06:54 +0000

I'm evaluating the Sophos XGS series for a potential edge deployment across several branch offices, and the vendor documentation heavily promotes the integrated web cache as a key feature for WAN optimization. The marketing claims are predictably vague, focusing on "reduced bandwidth consumption" and "improved user experience" without providing tangible, quantifiable metrics. Before I consider architecting around this feature, I need to see empirical data. Has anyone conducted a controlled analysis to measure the actual bandwidth savings in a production environment? I am particularly interested in: * **Methodology:** How did you structure the test? Was it A/B testing with cache enabled/disabled on identical traffic profiles, or longitudinal analysis over weeks/months? * **Traffic Profile:** What is the composition of your outbound web traffic? Percentages for static content (JS, CSS, images, video) versus dynamic API calls would be crucial. * **Cache Hit Ratio:** What sustained cache hit ratio did you observe? The Sophos CLI should provide this. ```bash # Example commands to query cache stats > ssh admin@xgs XGS> show web-filter cache statistics ``` * **Quantitative Results:** What was the measured reduction in upstream bandwidth? Please provide it as a percentage of total HTTP/HTTPS traffic and, if possible, in absolute Mbps/GB per day. * **TLS/HTTPS Overhead:** Given that most traffic is now encrypted, how does the cache handle TLS? Is it performing MITM decryption, and if so, how are the compute overhead and certificate management costs factored into the total savings? Anecdotal claims of "it feels faster" are not actionable for capacity planning. I am looking for data that can be modeled, such as: "With a workforce of 200 generating approximately 150 GB of daily web traffic with a 40% static content ratio, the cache achieved a 65% hit rate, yielding a net WAN bandwidth saving of 39 GB per day." Without this level of granularity, it's impossible to perform a credible ROI calculation versus alternative strategies like explicit forward proxies or even increased bandwidth commitments. -- alex

Just made a script to auto-purge old firewall logs. Storage crisis averted.

cost_cutter_99 — Mon, 20 Jul 2026 21:38:46 +0000

Just hit a storage wall with our Sophos XGS 2300's logging. The internal disk was 95% full, mostly from firewall logs going back over a year. Support's immediate suggestion was, of course, "add a storage license." But before we spent on more GBs, I wondered: do we really need logs from 2022 for a compliance window that's only 90 days? Turns out, the built-in log maintenance is a bit blunt. I wanted something more surgical—keeping all threat/IPS/WAF logs forever (archived to our S3 bucket), but aggressively purging the basic firewall/flow logs after 90 days. Couldn't find a clean built-in way, so I wrote a script that uses the SFTP backup method. It runs weekly via cron and does this: * Connects to the XGS SFTP backup location. * Identifies firewall log files (`fwlog*.tar.gz`) older than our threshold. * Moves those files to a temporary holding folder. * Deletes them from the appliance, then cleans up. The result? Freed up 68GB instantly. The script is lightweight and only deals with the rotated archive files, so zero risk to the active database. Key configuration bits on the XGS side: * Logging > Log Settings: Set "Log file backup frequency" to Daily. * Logging > Backup: Enable SFTP backup to a dedicated path. * (Crucial) Under each log category (Firewall, Threat, etc.), set the "Send to Backup" checkbox appropriately. For us, only Firewall/Flow are *not* sent to backup, as we purge them. This approach keeps our critical security logs forever in S3 (via the backup), while ensuring the appliance itself doesn't choke on ancient flow data. Saved us from buying the storage license upgrade, at least for another year. Has anyone else tackled this differently? I'm curious if there's a more elegant method using the built-in SQL database cleanup commands, but I was hesitant to touch the live DB directly.