Sophos Firewall v22 MR2：值得升级，还是新的风险？

Sophos Firewall v22 MR2已经发布。Build 546于2026年7月14日推出，带来一组规模不大但颇有意义的安全功能、身份验证变更、证书调整，以及超过50项问题修复。

从纸面看，这是一次典型的维护版本。但在实际环境中，它恰好包含了如今让我对Sophos更新格外谨慎的组合：新的IPS检测逻辑、改变的用户映射行为、新证书链，以及一长串kernel crash、HA问题、failsafe状态、VPN故障和reporting中断。

这并不完全是好消息。50多项修复一方面说明Sophos正在清理问题，另一方面也说明GA和MR1中仍有多少严重缺陷。我此前已经在Sophos Firewall：没有CVE，但仍有大量Bug（v21.5至v22）中批评过这种firmware质量。

我会立即在自己的一台Sophos Firewall上安装MR2。不是因为我在发布首日就盲目信任它，而是想确认Build 546能否终于稳定v22系列，还是会再次产生比修复更多的新bug。我尤其关注HA、logging、IPsec、WebAdmin响应速度、STAS，以及pattern update之后的稳定性。

与此同时，Sophos形成了一个奇怪的反差。Config Studio 2.6如今在官方firewall update中占据相当篇幅。这个外部browser tool获得了template merge、更好的搜索、multi-file diff、migration analysis和hardware compatibility data，而日常使用的firewall本体界面几乎没有任何显著变化。

因此，我认为MR2在技术上重要，在战略上却令人失望。security engine继续获得新功能，而现代化管理workflow又一次被转移到了Config Studio。

核心要点

SFOS 22.0 MR2的版本号为Build 546，接替MR1 Build 490。Sophos主要列出了七个方面：

• 检测和控制post-quantum cryptography
• 改善生成式AI application的分类
• 基于Manifest V3的新Chromebook User ID extension
• 修改STAS默认行为
• 提前通知SFOS 23.0将停止支持Novell eDirectory
• 新的Let’s Encrypt trust chain以及更好的email通知
• Config Studio 2.6新增多项analysis、migration和comparison功能

此外还有50多项问题修复。从运维角度看，其中一些比新功能更重要，因为它们涉及kernel crash、HA故障、failsafe状态、VPN错误和reporting性能问题。

我的简短判断如下：

• 已经运行v22 GA或MR1且受某项已列问题影响的环境，有明确理由安装MR2。
• 稳定运行21.5的环境，不应仅仅为了PQC或Config Studio而仓促升级。
• PQC signature应先以纯观察方式启用，不要立刻设为Drop。
• STAS环境必须在升级后确认Identity Probe期间如何处理未认证traffic。
• HA、IPsec、WAF、mail和reporting环境需要真正的功能测试，而不是只看绿色状态。
• Config Studio 2.6在技术上有用，但不能证明SFOS WebAdmin正在现代化。恰恰相反。

hardware边界依然重要：SFOS 22.0不再支持XG和SG hardware appliance。MR2适用于XGS、virtual、software和受支持的cloud installation。仍在使用XG hardware的组织，不能把MR2当作普通的下一步firmware升级。

检测和控制Post-Quantum Cryptography

技术上最有趣的新功能是对post-quantum cryptography（PQC）的控制。这并不意味着Sophos Firewall突然能够抵御quantum computer，而是针对现代key exchange机制。这些机制旨在更好地抵抗未来强大量子计算机的攻击。

MR2聚焦于ML-KEM。该机制在2024年被标准化为FIPS 203，其安全性依赖于Module Learning With Errors问题被认为难以解决。NIST定义了三个parameter set：

• ML-KEM-512：key和数据量最小
• ML-KEM-768：中等规格，也是目前较常见的variant
• ML-KEM-1024：security level更高，但计算和传输开销也更大

Sophos在MR2资料中只笼统提到基于ML-KEM的pure和hybrid key-exchange algorithm，并未公布具体parameter set、TLS group或signature ID。因此，不能假设每一种ML-KEM variant都能被检测。

KEM在技术上究竟做什么

ML-KEM并不直接加密整个data stream。简化来看，Key Encapsulation Mechanism由三项操作组成：

1. KeyGen生成encapsulation key以及对应的decapsulation key。
2. Encaps使用公开encapsulation key生成ciphertext object和shared secret。
3. Decaps在另一端用私有decapsulation key恢复相同的secret。

protocol随后从这个shared secret派生symmetric session key。真正的payload仍由AES或ChaCha20等高速symmetric algorithm保护。ML-KEM取代的是存在未来风险的非对称密钥协商部分，而不是整套TLS数据加密。

实际背景是Harvest now, decrypt later：攻击者今天记录加密traffic，希望几年后使用cryptographically relevant的quantum computer解密。对短期数据影响较小，但医疗数据、政府通信、知识产权和长期机密的企业数据，其保密期限可能长于新型攻击能力出现所需的时间。

Pure与hybrid并不相同

pure PQC key exchange的协商安全性只依赖新的post-quantum机制。hybrid exchange则将classic mechanism与ML-KEM结合。当前TLS实现中的真实例子是X25519MLKEM768：classic X25519和ML-KEM-768共同参与生成最终secret。

在迁移阶段，这种方式很合理。如果ML-KEM后来暴露实现错误或数学弱点，classic component仍然存在；如果足够强的quantum computer破解classic elliptic curve，ML-KEM部分仍提供保护。因此，hybrid是迁移桥梁，而不是多余的双重加密。

但必须说明：X25519MLKEM768只是当前TLS中的真实技术示例，不代表Sophos只检测或主要检测这个group。MR2资料没有这样表述。

IPS在其中做什么

Intrusion Prevention System获得用于检测pure与hybrid ML-KEM key exchange的新signature。管理员可以创建自己的IPS rule，并选择Allow、Drop或Reset等action。

firewall在技术上能够识别TLS handshake中提供和选定的key exchange，因为client在ClientHello中声明supported group与key share，server在ServerHello中确认选择。这发生在加密application stream开始之前，因此无需读取之后的HTTPS content也能检测。

不过，Sophos没有说明Snort或SFOS IPS pipeline在哪个位置分析这些字段、覆盖哪些TLS version，以及proxy、DPI与未解密FastPath traffic之间是否存在差异。release note确认了能力，却没有解释内部data path实现。因此production policy必须配合firewall和IPS log进行自行测试。

不同action会产生不同影响：

• Allow让连接继续，配合logging适合先做资产和使用情况统计。
• Drop静默丢弃匹配packet，client通常看到timeout或handshake中断。
• Reset主动终止TCP连接，错误出现更快，但在client与application log中的表现可能不同于silent drop。

新signature默认禁用，这是正确决定。PQC已不再只是实验室技术，大型browser、cloud service和web platform已经在测试或使用hybrid方式。若一律block，可能导致合法网站与application停止工作。

因此，合理的上线步骤应是：

1. 启用signature，但先允许并记录traffic。
2. 连续数天或数周分析哪些application和destination使用ML-KEM。
3. 检查内部cryptography policy是否禁止或明确要求某些机制。
4. 之后才有针对性地使用Drop或Reset。

第一轮community discussion中，有管理员在升级后用PQC、KEM或quantum搜索，却找不到相应IPS signature。可能是pattern update尚未到达，也可能是命名方式不同。发布数小时后的情况尚不能证明产品存在缺陷，但确实暴露了documentation问题：如果找不到signature名称、SID、category与log特征，功能就无法有效管理。

修改policy之前，我会具体检查：

• IPS是否启用，Network Protection subscription是否有效？
• 安装了哪个IPS pattern版本？
• 新signature以什么名称和SID出现？
• 检测记录是否出现在IPS log和central reporting中？
• 使用DPI exception、TLS Inspection和FastPath时，检测是否一致？
• 哪些browser、OS、cloud service和内部application会触发记录？

Web Protection在其中做什么

Sophos还表示，Web Protection会阻止web session协商不受支持的PQC algorithm。这与IPS signature是不同任务。IPS检测特定pattern并采取action；Web Protection介入受控的TLS与web workflow，避免连接采用firewall无法处理或policy不允许的机制。

这在TLS Inspection场景尤其重要。firewall会终止client的TLS session，并自行建立到destination server的第二个TLS session。因此存在两个独立handshake和两套session key。browser和web server可能支持PQC，但位于中间的inspection component未必能正确处理所提供的group。

缺少受控行为时，会出现难以理解的错误：client提供新group、firewall无法完整转发handshake、server选择意外variant，或fallback不按预期工作。MR2旨在阻止web session协商不受支持的PQC algorithm。

Sophos没有精确描述的内容也很重要：资料中没有Web Protection专用PQC policy matrix、supported group列表，也未说明不支持的offer会被删除、拒绝，还是通过classic fallback替代。不能把它与可配置的IPS action混为一谈。

该功能有价值，但不能替代cryptography strategy。组织仍需清楚哪些TLS连接被解密、哪里设置了exception，以及PQC只需观察还是必须强制执行。

提高生成式AI application的可见性

第二项security新功能是通过Synchronized Application Control改善生成式AI application分类。

基本原理并不新：Sophos Endpoint能看到哪个local process建立连接，并通过Security Heartbeat将application context传给firewall。即便仅凭port、destination IP和加密traffic无法明确识别，SFOS也能将session关联到某个program。

简化后的data path如下：

1. 受保护endpoint上的application建立network连接。
2. Sophos Endpoint知道process名称、path与local application context。
3. Security Heartbeat将endpoint与firewall视角关联起来。
4. SFOS把原本未知或只能粗略识别的session映射到application。
5. application出现在Synchronized Application Control中并可分类。
6. Application Filter Policy允许、block或shape相应traffic。

在Connection List中，Resolve application info可以向endpoint请求未识别connection的信息。application列表可按名称、path、category或endpoint搜索。Sophos给出的管理上限是15,000个application。为节省memory，每个application与endpoint只保留最近五次记录。

MR2专门改善生成式AI application的归类。Sophos Endpoint应能更准确识别这些application，并把信息传给SFOS。Generative AI category可用于Application Filter和report。

对管理员而言有三个价值：

• 可见性： reporting更清楚地显示组织使用了哪些生成式AI application
• 规则： 对识别出的application更精确地允许、限制或block
• 资产清单： 为security与privacy团队区分获批和未获批AI service提供基础

这很有用，但不应夸大“检测生成式AI”这句话。Synchronized Application Control主要回答：哪个application创建了连接？ 它不会自动回答：

• 用户输入了什么prompt
• 上传了什么file
• 是否包含个人或机密数据
• browser session属于私人用途还是业务用途
• 允许的AI service是否在browser中调用了嵌入式功能

拥有明确process path的desktop client，比同一个browser process中的十个AI web service更容易识别。URL categorization、TLS Inspection与cloud-app detection可以补充信息，但在技术上属于不同检测层。

实际效果还依赖Sophos Endpoint、启用的Security Heartbeat和Synchronized Application Control，首次启用需要通过Sophos Central完成。只运行SFOS，或endpoint不在Heartbeat路径中的环境，无法自动获得同等检测深度。

正确预期应是：MR2改善application attribution，从而改善policy基础；它不能单独解决组织允许哪些AI service以及可在其中处理哪些数据的问题。

升级后不应立刻block整个Generative AI category。应先在report中区分记录来自endpoint context、firewall signature还是web categorization。否则可能在不了解真实用途的情况下，误停Microsoft 365、开发工具、browser或支持平台中的正常功能。

身份验证和用户映射变更

MR2包含三个相互独立的身份验证主题。两个需要具体准备，第三个是提前发出的migration warning。

基于Manifest V3的Chromebook User ID

Sophos Chromebook User ID Extension已迁移到Chrome当前的extension平台Manifest V3。

关键点是Sophos要求卸载旧extension并安装新版，不能只依赖旧extension的silent update。集中管理Chromebook的学校和企业，应通过Google Admin policy准备切换，先用test group验证，再广泛部署。

extension只是SSO路径的一部分。Sophos还要求：

• firewall上配置AD、LDAP或Google Secure LDAP server
• Chromebook位于SFOS保护的network中
• 用户地址属于注册的Google Workspace domain
• 用于加密通信的certificate及与其匹配的CN
• 默认Sophos通信port 65123
• 从SFOS导出并放入Google Workspace的JSON配置
• 能访问accounts.google.com、Google API host和Chrome Web Store

在Google Workspace中，需要从Devices > Chrome > Apps and extensions > Users and browsers分发新extension。production环境适合使用Force install，避免用户移除身份映射所需extension。另外，必须在API Controls中把Sophos User ID App设为trusted，否则OAuth可能失败。

切换后，不应只检查extension是否已安装，而应验证整条链路：

1. 用户登录Chromebook。
2. extension通过预定network和certificate访问firewall。
3. 用户出现在Live users中。
4. user-based rule确实匹配相应用户或group。
5. logout或设备切换后，映射正确消失。

没有新extension，未来update可能停止。根据身份验证设计，用户映射以及基于用户的firewall或web rule可能受到影响。学校环境很可能出现firewall、internet和Chromebook看似都“online”，但过滤已经失效的情况。

STAS默认不再在Identity Probe期间block traffic

在Sophos Transparent Authentication Suite中，MR2把Restrict client traffic during identity probe的默认值改为No。

STAS把IP address映射到Windows domain controller识别出的用户。流程虽然较早，但技术上很有意思：

1. 用户登录Windows domain。
2. domain controller写入Security Audit Event；较新的Windows通常是Event ID 4768。
3. STAS Agent从event中读取username和IP address。
4. agent默认通过TCP 5566把信息发送到collector。
5. collector通过UDP 6060把成功映射通知firewall。
6. SFOS发现未知IP的traffic时，可通过port 6677查询collector。
7. firewall从配置的AD server补充group membership，再应用user-based rule。

firewall尚未映射某个IP时，该IP进入Learning Mode。此前默认在probe期间暂停或丢弃traffic。documented default时间为120秒。如果collector没有响应，该IP随后可能有一小时保持未认证状态，并套用未认证traffic规则。

MR1在这里存在真实运维问题。Sophos记录了NC-181885：当Restrict client traffic during identity probe = Yes时，反复Identity Probe可能导致间歇性中断，或阻止MR1 upgrade。MR2被列为修复版本，同时将默认值改为No。

设置为No后，client traffic在probe期间继续流动，减少了中断，但也改变了权衡：

• 用户受到的中断更少。
• probe进行时firewall可能尚无已确认身份。
• 这个过渡阶段的user-based rule和logging必须仔细验证。

这是availability与严格identity enforcement之间的典型trade-off。Yes会让collector通信故障block client；No可能让traffic在身份确认前流动。它会命中普通network rule、未认证rule，还是之后的user rule，必须在自己的ruleset中测试。

release note说明默认值改为No，但没有明确表示MR2会覆盖所有现有且有意设置的配置。因此升级后应检查实际值。

另外还应确认：

• firewall与collector之间的UDP 6060和6677是否开放？
• STAS Service是否运行并绑定到正确NIC？
• 是否将多个collector组成group以实现fault tolerance？
• printer、IoT及其他非domain设备是否使用Clientless User object？
• 用户在sleep、roaming、DHCP变化和logout之后是否正确映射？
• Learning Mode和未认证状态下的rule是否符合security design？

如果用户身份不仅用于reporting，而是真正的访问条件，这一点尤为重要。

Novell eDirectory将在SFOS 23.0中结束

MR2首次提前提示：Sophos将在SFOS 23.0中停止支持Novell eDirectory authentication server。

eDirectory在MR2中仍可运行。这是预警，而不是立即丧失功能。但仍在production中使用eDirectory的组织，应在安装SFOS 23.0前迁移到受支持的身份验证类型。

这类migration并不只是更换server entry。group、firewall rule、web policy、VPN access、user portal和reporting都可能依赖原有identity source。不同的Distinguished Name、nested group、search path和username format意味着LDAP test成功远不能证明policy migration成功。

此外，STAS一直不支持eDirectory的LDAP over SSL/TLS。因此Sophos在SFOS 23.0中完全移除它并非毫无征兆。替代architecture仍应作为独立项目处理，包括test account、并行group、已记录的rule reference和rollback plan。

Let’s Encrypt：新chain与更好的设备识别

Let’s Encrypt正逐步把证书基础设施迁移到新的root与intermediate certificate。MR2新增对YE Root、YE1、YE2、YR Root、YR1和YR2的支持。

Generation Y hierarchy包含两种不同key type的新Root CA：

• ISRG Root YE使用ECDSA P-384，是此前ECDSA hierarchy的后继路径。
• ISRG Root YR使用RSA 4096，是新的RSA root路径。
• YE1与YE2是ECDSA P-384 intermediate。
• YR1与YR2是RSA 2048 intermediate。

这些root由原有ISRG root进行cross-sign。因此，在browser和OS vendor把新root加入Trust Store的过程中，新chain仍可回溯到已广泛部署的trust anchor。YE1、YE2、YR1和YR2 intermediate在2026年开始对active issuance具有实际意义。

对SFOS而言，这主要是compatibility变更。firewall必须正确识别新issuer和chain，才能保证自动签发、renewal、WAF使用与validation在下一代Let’s Encrypt基础设施上继续运行。如果trust chain没有更新，即便domain、port 80和HTTP-01 validation配置正确，certificate operation也可能失败。

这在运维上很麻烦，因为ACME error很容易被误判为DNS、DNAT、port 80、WAF rule或Terms of Service问题，而真正原因可能是新CA chain。

SFOS仍使用HTTP-01。domain必须以FQDN指向选定的public WAN address，port 80必须能够到达firewall，同一address和port 80上的竞争DNAT rule可能阻止validation。MR2不改变这个基本原理，只扩展受支持的CA hierarchy。

Let’s Encrypt email通知现在还会包含firewall hostname和serial number。这看似很小，对MSP和大型环境却很实用。管理员终于可以快速把警告关联到正确设备，而不必从通用消息开始排查。

这是典型的quality-of-life改进。集中管理firewall生成的每封系统消息，本来就应至少包含hostname、serial number、model和firmware。backup email已经朝这个方向发展，Let’s Encrypt在MR2中跟上了。

Config Studio 2.6：逐项解释新功能

Sophos正式把Config Studio 2.6列入MR2 announcement，尽管它仍是独立的browser-based tool，而不是直接运行于SFOS中的新界面。此前文章Sophos Firewall Config Studio V2：不只是Viewer介绍了export、Entities.xml、comparison与editor的完整workflow。

技术和privacy层面很重要的一点是：Sophos表示parsing、analysis与report生成在endpoint的browser中local完成，配置不会发送到Sophos或其他server。完整firewall配置中的Entities.xml可能包含internal network、object、rule、VPN definition、certificate reference和组织名称。

local处理也不等于自动没有风险。browser仍从internet加载application。高度敏感环境还要考虑code version、browser cache、offline使用、endpoint hardening以及export的安全保存。Entities.xml不应不受控制地出现在Downloads、ticket或普通cloud synchronization中。

Config Studio 2.6如今覆盖五个工作区：

• 带Policy Test、analysis和global search的Configuration Report
• 比较两个或更多configuration
• 带bulk editing以及XML、API或curl输出的visual editor
• 从Sophos UTM、SonicWall、FortiGate和Palo Alto Networks进行migration
• backup restore、Flexi Port、transceiver和model compatibility

合并Template

Merge Templates可以把baseline configuration与行业专用template结合。MSP例如可以把logging、DNS、admin access和standard object的技术baseline，与诊所、学校或分支机构template合并。

复用避免每台firewall都从零开始，但conflict处理仍然关键：

• 名称相同、值不同的object会怎样处理？
• UUID、reference与rule order能否一致解析？
• 哪些interface或zone reference不适用于target model？
• merge是否产生duplicate或overlap rule？
• 原有严格object是否会被更宽泛的template值替换？

merge之后，Duplicate Analysis、Shadow Rule Analysis、Usage References和完整Policy Test都是必需步骤。技术上成功的merge不能证明最终policy安全。

改进的global search

global search能更快找到configuration object并直接跳转。对于大型ruleset，这比听起来更重要，因为一个host object可能被firewall、NAT、TLS、web或VPN配置引用。根据data type，value、path与referenced element也可能有用。遇到Server、LAN_Network或多年形成的host group等通用名称时，直接跳转尤其有价值。

search并不等于Usage Reference。search回答“这个object或value在哪里？”，Usage Reference回答“哪些其他配置依赖它？”。安全变更需要两种视角。而这种功能其实也迫切需要直接出现在firewall界面中。

信息更完整的configuration report

report现在不仅在firewall、NAT和TLS rule中显示reference名称，还会显示对应object的值与细节。reviewer不只看到Webserver-Gruppe，还能直接确认其中有哪些host或network。一个看似规范的名称，内部仍可能包含Any、过宽network或早已遗忘的entry。

report也支持Policy Test与analysis。Policy Test检查指定source与destination会匹配哪条rule或route。analysis可查找shadowing和duplicate等问题。由于SFOS从上到下评估firewall rule，并在第一个match处停止，顺序是security logic的一部分，而不只是显示方式。

Config Studio 2.6：Migration、Comparison与Export

带成功率的migration analysis

Config Studio显示migration和conversion信息，包括成功迁移的比例。percentage是快速指标，不是验收报告。

Sophos区分以下状态：

• Supported：自动迁移且不改变实际内容
• Partial：带缺失项迁移，需要补充
• Manual：必须在Sophos Firewall上手动重建
• Not supported：不会迁移
• Action required：export前需要明确决定

即使95%的配置完成conversion，缺少的5%也可能正是certificate、password、VPN、NAT或特殊routing。因此真正有价值的不是绿色percentage，而是未支持、部分支持和自动解析element的详细列表。

不同vendor logic确实存在差异。FortiGate rule可能更偏向interface，而SFOS使用zone；Palo Alto还采用不同的object、zone与policy model。Config Studio能转换syntax和许多structure，但不能自动证明security model在语义上完全相同。

Multi-File Configuration Diff

Multi-File Diff可以上传两个或更多configuration，在多个时间点之间比较。Config Studio按file modification date排列，并在field level显示added、removed或changed。

可使用Side-by-Side、Unified与Semantic view。semantic comparison尤其重要，因为纯XML text diff容易被顺序、ID或formatting制造大量噪声。entity与field level diff试图呈现真正的configuration变更。

这对change reconstruction和troubleshooting很有用。如果问题不是在单个维护窗口后立即出现，可以比较多个export，找出rule、object或setting究竟何时改变。

但前提是定期保存configuration、可靠timestamp以及安全处理敏感export。下载或复制file的修改日期未必等于firewall配置变更时间。可靠历史应把file名称、export时间、firewall hostname、serial number、firmware和相关change ticket一起记录。

没有版本纪律，Multi-File Diff也无法凭空产生历史。若该功能直接集成到Central并具备不可篡改的Audit History，会比手动file upload强大得多。

Backup restore、Flexi Port与速率参考

Config Studio可以检查不同Sophos Firewall model之间的backup restore compatibility与port layout，并显示Flexi Port module以及最高25、40或100 Gbit/s的port speed和standard信息。

hardware migration之前，可以更好地判断：

• backup原则上是否可以restore
• 有多少physical port
• 现有Flexi Port module是否compatible
• 支持哪些interface standard和speed

它仍不能代替migration design。LAG、VLAN、bridge、HA、port名称、zone与具体interface mapping仍需规划并在restore后检查。

更广泛的backup restore compatibility适用于SFOS 20.0 MR2及以上target。根据source version与target platform，Backup-Restore Assistant会用于interface mapping。physical port可重新映射；VLAN和alias跟随parent interface；LAG或bridge依据已映射port重新建立。

对于Flexi Port，仅问“module能否物理插入”远远不够。model generation、form factor、transceiver、supported standard、port speed、breakout行为和可用SFOS version必须一起验证。Config Studio让查询更快，但不能代替migration之后的link与failover test。

Dark Mode

正式release note还提到Dark Mode。这只是很小的usability改进，不是firewall功能。但它几乎具有象征意义：就连Dark Mode也先进入外部Config Studio，而local WebAdmin console的外观与ergonomics多年来进展缓慢。

Editor在技术上能输出什么

editor可以import或新建configuration，执行Bulk Changes，并在export前把结果显示为Import XML、API Request或curl。也可以下载XML或TAR archive，再通过Backup & firmware > Import export导入SFOS。

这种能力也扩大了管理员责任。生成的API request不会自动具有idempotent特性。import成功不代表Rule Order、object使用、NAT、VPN和Security Policy在功能上正确。production应用之前，应把输出放入change ticket、review diff，并在真实data path上测试结果。

50多项Fix才是安装MR2的真正理由

Sophos列出50多项reliability、stability和security修复。并非每项都影响所有环境，但其中多个问题在运维上非常严重。

HA与failsafe并非边缘问题

多项修复影响的不是单一功能，而是appliance能否正常运行：

• NC-181331：configuration partition已满可能让firewall进入Failsafe Mode。
• NC-180110：primary上的Logging Daemon无法启动，使HA device进入failsafe。
• NC-177441：升级v22 GA后，Postgres问题可能让原primary进入failsafe。
• NC-178906：RED Server Service无法启动，并触发failsafe状态。
• NC-177467：大量并行未认证SSH连接尝试可能导致auxiliary无法正常启动。

原因不同，运维结果相同：firewall丢失service、进入保护mode，或HA peer不像此前绿色cluster画面所暗示的那样可用。升级后只看HA status: Active-Passive不够，必须测试同步、service status、failover与真实traffic。

IPsec Fix深入data path

• NC-180433：VPN tunnel中的multicast traffic可能反复触发firewall crash。
• NC-171719：在SD-WAN场景中，ESP traffic走了错误routing。
• NC-180520：启用IPsec Acceleration时，如果tunnel绑定alias IP且ESP从另一WAN port进入，升级后XFRM gateway可能一直不可用。
• NC-176855：route-based IPsec的IPv6 throughput受影响。
• NC-178121：drag-and-drop可能把Failover Group中的site-to-site IPsec connection移动到错误位置。

面对这些问题，tunnel status显示Active并不能证明正常。route-based VPN应分别测试XFRM interface、Routing Table、SD-WAN decision、ESP path、MTU、IPv4与IPv6。Failover Group还需验证顺序和切换是否符合documented priority。

Logging与reporting本身可能造成中断

NC-155252尤其令人不安：reporting的高disk I/O load会造成CPU spike和最长一分钟的间歇性internet outage。也就是说，analysis subsystem影响了production data path。

NC-178745描述HA device因Logging Framework out-of-memory而自动restart；NC-181520改善Log Viewer性能。这些问题说明SFOS logging不是无害的附加功能。storage、database、Garner、Log Viewer与Central Reporting在运维上比界面显示的更接近核心system。

升级MR2后，不应只确认出现了新log line，还要检查：

• firewall、IPS、WAF、authentication与VPN event是否完整？
• timeline是否有gap？
• external syslog collector是否继续收到data？
• 正常load下CPU、RAM与disk I/O是否稳定？
• report生成是否不再影响data path？

Central Fix暴露“Single Pane of Glass”的边界

NC-181175会让Sophos Central下发的Group Policy一直处于Pending。NC-180513涉及升级MR1后从Central View进行configuration import。NC-181904则导致无法通过Central释放quarantine mail。

共同点是：central interface可以接受或显示一项操作，却不代表firewall真正执行了它。Group Policy push后，必须在target device上确认object、rule、order与timestamp是否实际到达。Central中关闭的success dialog不是技术上的commit证明。

这也是我不只根据feature list长度评价maintenance release的原因。如果firewall会因为logging、Postgres、SD-WAN或multicast进入failsafe或restart，修复这些问题比新dashboard tile更有价值。

与此同时，fix数量也不是质量证书。它说明问题被修复，也说明早期build存在多少严重问题。critical HA、VPN或WAF环境既不应因为恐惧而永远停在旧build，也不应在首日不经测试就全面部署MR2。

升级前应检查什么

Sophos建议为了security、stability与performance fix及时安装MR2。原则上可以理解，但在production中，“及时”并不意味着“盲目”。

Bridge上的Legacy VLAN Tagging会阻止MR2

MR2新增一项硬性upgrade block：bridge interface上的旧CLI-based VLAN tagging。如果配置仍使用legacy方式system vlan-tag，firewall不能升级到SFOS 22.0 MR2或更高版本。

必须在升级前清理或migration。此外，包含这种legacy配置的backup也无法restore到SFOS 22.0 GA或更高版本。对于多年演进、曾通过CLI修改的环境尤其重要。

以前的v22障碍仍然存在

• Legacy Remote Access IPsec必须在MR1或MR2之前删除或migration。
• SFOS 22需要更多storage；某些desktop、virtual或software appliance需提前调整。
• policy-based IPsec VPN的行为自GA起发生变化，相关tunnel必须验证。
• XG和SG hardware不支持SFOS 22。
• RED 15、RED 15w与RED 50自v21.5起不再支持。

我的升级流程

对于production firewall，我至少会这样做：

1. 创建当前backup并保存在外部。
2. 检查support、license status与批准的upgrade path。
3. 排除Legacy Remote Access IPsec和bridge上的CLI VLAN tagging。
4. 查看Control Center中的Disk Space warning。
5. 对HA检查两个node的状态、同步与可用firmware。
6. 记录critical VPN、WAF发布、mail flow、SD-WAN rule与身份验证。
7. 先在有代表性的test appliance或较低关键度设备上安装MR2。
8. 升级后测试log、pattern、HA、routing、DNS、VPN、WebAdmin、reporting及central policy push。

对于修复众多的release，清晰的before/after test尤其重要。否则只能知道firmware更新了，却不知道关键data path是否仍完全按计划工作。

SFOS从version 20开始，在升级期间configuration migration失败时可automatic firmware rollback。这降低了用Factory Configuration启动的风险，但不覆盖所有场景，例如unsupported upgrade path或某些Setup Assistant流程。自动rollback后应分析migration.log与migrationhash.log。

automatic rollback不能替代外部backup、Secure Storage Master Key与可用的console access。它主要防止configuration migration失败，并不能证明技术上成功升级后，WAF、VPN、HA或reporting在功能上正确。

在我的直接MR2测试中，我会在升级前后测量或主动触发相同项目：

• reboot以及所有service完整启动
• WebAdmin login与大型rule list的响应速度
• local和external log flow
• IPsec traffic、rekey与failover
• 在firewall端验证Central Policy Push
• IPS与Application Control的pattern update
• STAS重新登录和未知client IP的行为
• 如果test system是cluster，则检查HA同步与受控role change

完成这些之后，我才能说明MR2在自己的环境中是否真的更好。安装成功与绿色Control Center远远不够。

第一批Community反馈说明了什么

feedback thread与MR2在同一天建立。在撰写本文时，它只有几个小时历史。因此既不能据此判定MR2稳定，也不能判定它有问题。

仍有两项讨论值得注意：

• 一位XGS 5500 Active-Passive HA运维者特别询问了测试深度，因为NC-177467在MR1期间困扰了他数月。Sophos将该问题列为MR2已修复，涉及大量并发未认证SSH连接尝试导致auxiliary无法启动。
• 关于PQC signature，一位Sophos员工说明其有意默认禁用。随着PQC TLS在browser和application中增加，立即启用可能产生大量告警。建议先Allow并logging，之后确有必要时才改为block action。

这是新release早期的合理讨论方式：具体test、case ID与可重现反馈，而不是笼统地说“能运行”或“坏了”。我会继续关注该thread，尤其是HA、IPsec、WAF、STAS与reporting方面。

Config Studio正在成为旧界面的零件仓库

现在谈谈令人不舒服的部分。

Config Studio 2.6是个好工具。合并template、搜索object、解析report中的reference、比较多个configuration版本和准备hardware migration，都是真正的管理员功能。我批评的不是Sophos开发这些功能，而是它在哪里开发。

Sophos如今直接在firewall release note与官方MR2 announcement中列出Config Studio。它越来越像一个战略答案，用来处理本应在WebAdmin或Sophos Central中解决的问题。

local firewall UI在日常使用中仍然老旧，大型配置下通常很慢。bulk变更能力不足。object使用位置、真正的global search、清晰diff、NAT cloning、rule conflict和现代change workflow，在管理员每天工作的地方仍然缺失。Central只填补了一部分空白。

这不仅是design问题。现代firewall interface应有可靠的change process：

• Candidate Configuration，而不是立即分散执行单项变更
• commit前完整的before/after diff
• 横跨object、rule、NAT、VPN与TLS的dependency check
• atomic commit或清晰的transaction status
• 回到最后已知状态的validated rollback
• Audit Trail中真实的用户、时间与来源归属
• 带preview与conflict check的Bulk Operations
• 用于可重现change的一致API output

Config Studio在system外重建了其中一部分。它分析export、生成XML或API request并帮助diff。但offline view与firewall active runtime state之间仍有缺口。session、dynamic routing、HA状态、current pattern、certificate status与实际加载的configuration，并不等于本地打开的Entities.xml。

仅凭一次release announcement，就断言Sophos永远不会彻底现代化SFOS界面，显然过度。没有得到确认的官方表态。但信号仍然不好：在usability、search、comparison与configuration工作方面最明显的进步，又一次落在实际management interface之外。

workflow仍然割裂：

1. 从firewall导出configuration。
2. 解压archive并找到Entities.xml。
3. 把file加载到独立browser tool。
4. 在其中分析、比较或编辑。
5. 再export结果，通过XML、API或curl送回。

用于audit尚可，但对现代、安全、可追踪的管理而言，这是绕路。更令人不安的是，Config Studio不只覆盖一个特殊场景；它获得的恰好是Sophos管理员多年来期待的low-hanging fruit。

如果Sophos已经把Config Studio当作正常firewall release note中的重点，就不能再说它只是小型辅助工具。Sophos明显把它纳入admin strategy，因此也应解释哪些功能会长期集成进WebAdmin或Central，哪些永久留在browser tool。

没有roadmap，就会形成这种印象：老旧、缓慢，并在大型配置中越来越不友好的界面会原样保留，管理员要使用现代workflow就必须转向Config Studio。这不是得到确认的Sophos计划，却是产品当前传递的方向。

为什么这让UniFi轻松获得机会

UniFi并不能完整替代每一台Sophos Firewall。根据license和architecture，Sophos提供更深入的security功能、IPS、Web Protection、WAF、endpoint integration、MDR/XDR集成以及classic enterprise能力。公平比较不能抹去这些差异。

但用户每天通过操作体验来感知产品质量。

Ubiquiti明显投资于design、mobile app、一致navigation、topology、简单device onboarding，以及无需多年产品经验也能理解的界面。并非每项UniFi功能在技术上都更深入，但产品感觉更现代，而这对采购决策的影响远超传统firewall vendor愿意承认的程度。

小型IT team不会只看IPS datasheet，还会看：

• 多快能找到device、rule或client？
• 能否通过smartphone合理检查环境？
• 没有专门知识能否理解warning与dependency？
• 日常变更需要多少click？
• 产品像统一platform，还是像多个并排工具？

Sophos在这里不必要地给了Ubiquiti等vendor轻松机会。从security角度，Sophos Firewall能做得更多，对许多SMB环境仍是更合理的方案。但如果modern search、diff、template和bulk change必须打开独立Config Studio，而core interface仍然老旧迟缓，Sophos会在最显眼的层面失去信任。

良好的security不只需要强大的engine，还需要让人能理解rule、识别错误并安全执行change的界面。因此usability不是装饰，而是operational security的一部分。

结论：安装MR2，但产品问题依然存在

SFOS 22.0 MR2不是大型feature release，而是包含合理改进的重要maintenance release。

PQC控制来得正是时候，但应先以观察方式上线。生成式AI application检测改善了可见性与policy，却不能替代DLP或AI governance。Chromebook管理员必须主动部署Manifest V3 extension。STAS应减少中断，但需要有意识地验证identity rule。Let’s Encrypt已为下一代certificate chain做好准备。大量fix也解决了可能在production环境中造成真实中断的问题。

我会在backup与preflight之后立即安装MR2，并测试这些具体data path。受已列HA、VPN、reporting、Central或failsafe问题影响的环境，有充分理由更新。但Build 546最终会更稳定，还是带来新regression，在发布当天无法负责任地回答。

我的批评仍很明确：Config Studio 2.6很有用，但它在firewall release中的突出角色，加强了Sophos把现代管理转移到side tool的印象。这不代表Sophos已确认放弃新的SFOS界面，却是一个战略warning sign。

Sophos拥有强大的firewall基础。它应最终给管理员提供与这套技术基础匹配的management experience。否则，现代platform获胜未必因为security更好，而是因为它更认真对待屏幕前的人。

下次再见，
Joe

FAQ