Select and troubleshoot SFP and SFP+ for Sophos Firewall

If an SFP port remains Unplugged, the link flaps, or it does not reach the expected speed, the cause is usually before the firewall rule: the port type, transceiver, fibre, peer, or link negotiation do not match.

The quickest check follows this order:

1. Identify the appliance model and hardware port: SFP, SFP+, QSFP, or Flexi Port.
2. Check the supported speed and transceiver compatibility for that exact port.
3. Match the transceiver, fibre or DAC, and the module at the peer.
4. Under Network > Interfaces, check Link Mode, Auto-Negotiation, and FEC.
5. If Sophos Support requests it, collect read-only Advanced Shell diagnostics.
6. Replace the fibre, module, and peer port one at a time with known working components.
7. Only investigate VLAN, LAG, IP configuration, routing, and firewall rules after the physical link is stable.

Select a matching port and transceiver

Distinguish SFP, SFP+, and dual-rate ports

SFP typically represents 1 GbE, while SFP+ represents 10 GbE. The plus sign therefore matters: a 10G SFP+ module does not work in a 1G-only SFP port. Conversely, not every SFP+ port automatically supports 1 Gbps SFP modules.

Some SFP+ ports or Flexi Port modules are dual-rate and support both 1 and 10 GbE. Only assume this for a specific port when the model manual or compatibility matrix confirms it. Larger appliances may also have QSFP, QSFP+, or breakout ports; their port mode, module, and speed must match as well.

Configure breakout interfaces on Sophos Firewall explains how to divide a supported QSFP or FleXi port into two or four members, restart the appliance, and verify the result.

The current model and transceiver matrix is available in Sophos Firewall Config Studio under Backup-restore compatibility. Before purchasing or changing hardware, check the appliance, Flexi Port module, port standard, and transceiver there. This dynamic matrix is more reliable than a static compatibility list in this article.

A third-party transceiver that is not listed may technically work, but that does not mean Sophos has tested or supports it. There is no general CLI command that enables an incompatible SFP. For production uplinks, use a verified module and keep a known working replacement available.

On SG and XG appliances, 1 Gbps operation in a 4-port 10G Flexi Port module is supported only with Intel-coded transceivers. Another third-party transceiver or active or passive DAC with similar coding may work, but Sophos has not tested that combination. A detected link therefore does not establish support.

For the documented SG and XG 40G combinations, QSFP+ modules with Cisco, generic, or other non-Intel coding are not supported. Sophos recommends QSFP+ fibre connections, and a 40G-to-4x10G breakout cable is not supported with the 2-port 40G Flexi Port module. The same no-breakout restriction and fibre recommendation apply to the documented XGS Appliance 40G combinations.

For a 100G optical connection, calculate the optical budget from the exact modules and fibre before connecting it. With the listed LR4 WDM unit, a direct connection may require attenuation on each fibre; never choose an attenuator without the module specifications and calculated or measured budget.

Match the optical path and peer

For fibre connections, both ends must use the same transmission standard. Before inserting the module, check:

• single-mode or multimode
• speed and standard, such as 1G-SX/LX or 10G-SR/LR
• wavelength and supported distance
• connector and matching patch fibre
• correct TX/RX polarity for duplex fibre
• the matching wavelength pair for BiDi modules
• a compatible module and matching port parameters at the peer

As a rough guide, SX and SR usually indicate short multimode links, while LX and LR usually indicate longer single-mode links. The specifications of the exact transceiver and peer remain authoritative.

A typical 10 Gbps example for a short connection uses compatible 10G-SR transceivers at both ends and multimode fibre suitable for the distance. A 10G-LR module at one end and a 10G-SR module at the other do not match despite using the same speed.

For DAC or AOC, the cable type, length, port standard, and both devices must be supported. A cable that fits mechanically does not guarantee a link.

⚠️ Laser safety: Never look directly into a powered transceiver or an open fibre end. Only remove protective caps when connecting the fibre, and clean contaminated connectors with suitable fibre-optic tools.

Configure the port in SFOS

In SFOS 22.0, edit the physical interface under Network > Interfaces and open Advanced settings > Port settings. Depending on the appliance, the following options appear:

• Link mode: speed and duplex
• Auto-negotiation for media type: automatic negotiation with the peer
• Forward Error Correction (FEC): error correction for supported high-speed ports
• Show recommended settings: display recommended values for the selected port mode
• Load recommended configuration: apply these values

Speed, duplex, Auto-Negotiation, and FEC must be compatible at both ends. A mismatch can cause link drops, errors, latency, or poor performance. For 25, 50, and 100 Gbps ports, save the Link Mode first, reopen the interface, and then load the recommended configuration.

On the 4-port SFP+ and 2+2 Flexi Port modules in the 1U XGS 2100, 2300, 3100, and 3300 appliances, all SFP+ ports on the module must operate at the same speed. This restriction does not generally apply to every fixed SFP+ port or every XGS Appliance model. When a listed transceiver that supports it operates below 10 Gbps, configure a fixed speed at both ends to avoid negotiation mismatches.

⚠️ Changing an uplink can immediately interrupt traffic and WebAdmin access. For a production WAN, core, or HA link, use a maintenance window and an alternative administration path. Record the original settings and cabling first. If the new settings do not establish a stable link, restore the original module or cable and the previous port settings through that alternative path, then verify traffic before ending the window.

After saving, check the hardware name and status under Network > Interfaces. Connected confirms the physical link, but not a correct VLAN, LAG, IP, or policy configuration. Plan Sophos Firewall zones and interfaces correctly explains how interfaces, zones, and rules work together.

Read the link and module through the CLI

Identify the hardware name

The following commands require the hardware name, not the freely assigned display name. It appears under Network > Interfaces and may be, for example, PortF1, PortA1, or Port1.

Alternatively, the Device Console displays the interfaces:

show network interfaces

The following ethtool and dmesg commands use Device Management > Advanced Shell, not Device Console. They are supplemental, read-only diagnostics rather than a documented, stable SFOS CLI interface. Run them only when Sophos Support requests them; command availability and output can vary by SFOS build, appliance, port driver, and module. Do not use their output as proof of support or compatibility. Manage Sophos Firewall over SSH explains the console context and SSH access.

Check the link, speed, and negotiation

Example for PortF1:

ethtool PortF1

The command does not change anything. An abbreviated output may look like this:

Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

In this example, a physical 10 Gbps full-duplex link exists. It does not yet confirm that the VLAN, IP configuration, routing, and firewall rules are correct. The most relevant values are:

• Link detected: yes for a detected physical link
• the expected speed, such as Speed: 10000Mb/s
• Duplex: Full
• supported and currently used link modes
• the Auto-Negotiation status

These values are indicators and must match the peer. Link detected: yes does not prove that the data path works. Conversely, Speed: Unknown! alone does not prove that a transceiver is defective, because the driver and port type can affect the output.

If a physical or LAG-based XGS Appliance 10G interface remains down with Auto-negotiation, Configure and test a LAG with LACP describes the still-listed issue NC-94073 and the official manual 10 Gbps workaround.

Read transceiver data and optical values

If supported by the module and driver, its EEPROM can be read as follows:

ethtool -m PortF1

The output may include:

• identifier and connector
• transceiver type and wavelength
• intended fibre length
• manufacturer, part number, and serial number
• temperature and voltage
• optical transmit and receive power
• alarm and warning thresholds

Only evaluate RX and TX power against the thresholds reported by the specific module or its data sheet. General dBm thresholds would be incorrect because the standard, distance, and optics vary.

Not every module provides Digital Diagnostic Monitoring. Empty output or Operation not supported therefore only means that EEPROM or diagnostic data is unavailable through this driver. It does not prove a defect. Conversely, readable module data does not prove a stable link.

The output may contain manufacturer and serial numbers. Redact device data that is not required before publishing a screenshot or attaching it to a ticket.

Search the kernel buffer for link flaps

For brief interruptions, a read-only search in the Advanced Shell helps:

dmesg | grep PortF1

Repeated link-up and link-down messages are consistent with fibre, module, peer, or negotiation problems. dmesg only contains the current kernel buffer and does not replace long-term monitoring.

State-changing or disruptive variants such as ethtool -s, ethtool -r, or EEPROM changes do not belong in normal diagnostics. They can alter the link, administration access, or module state.

Isolate a missing or unstable link

Follow up the results as follows:

• Interface remains Unplugged: Check the port type, supported speed, module compatibility, transceiver seating, fibre, TX/RX polarity, and peer port.
• Module data is readable, but the link remains down: Ensure that both ends use the same standard and speed; compare Auto-Negotiation and FEC. Then replace the fibre and modules one at a time with known working components.
• Link only comes up intermittently: Clean the connectors, check bend radius and temperature, compare RX/TX values with the module thresholds, and inspect dmesg for flaps.
• Link is up but slow or unreliable: Check the negotiated speed and duplex, switch counters, optical values, and FEC. Test performance with a second device before treating the firewall as the cause.
• Link is stable, but no traffic flows: Now check VLAN tagging, LAG, zone, IP address, gateway, routing, and firewall rules. For VLANs, see Configure and test a VLAN on Sophos Firewall.

Replace only one component at a time and document the result. This keeps it clear whether the module, fibre, firewall port, or peer caused the problem.

If a compatible module and known working fibre still do not produce a stable link on a correctly configured port, collect the outputs, timestamps, SFOS version, appliance model, and part numbers. Check a Sophos appliance for a hardware defect explains the next support and RMA steps.

At the time of review, SFOS 22.0 MR2 Build 546 was the latest listed version. For the current firmware status and issue review, see Plan and perform a Sophos Firewall firmware update. The following issue details reflect that review snapshot. A version shown on an issue identifies the build assigned by Sophos; it does not prove that only that build is affected or that later builds contain a fix.

Cisco Nexus 9000 with XGS 5500 to 8500

Sophos lists a specific hardware combination under NC-164102: On the built-in 10 Gbps ports of the XGS 5500, 6500, 7500, and 8500, the connection to a switch in the Cisco Nexus 9000 series may be lost or repeatedly go up and down. Sophos specifies neither an affected SFOS version nor a confirmed cause or fix.

The entry says only “10Gbit baseboard ports” on those 2U appliances. It does not identify individual port labels or include other port types, so do not extend its scope to QSFP ports or Flexi Port modules.

If the environment matches this combination exactly, first rule out the usual causes using the checks described above. For further analysis, document the appliance model, SFOS build, affected hardware port, Nexus model, NX-OS version, switch port, and the vendor and part number of the transceivers or DAC. Collect ethtool, ethtool -m, and dmesg output only if Sophos Support requests it, together with timestamped switch-port link events and error counters. Refer to NC-164102 in the support case.

As a possible workaround, Sophos suggests a 4-port 10 Gbps Flexi Port module instead of the built-in 10G ports. This is not a guaranteed fix. Before the change, verify appliance, module, and transceiver compatibility in Config Studio and prepare a maintenance window and alternative administrative access. Save the existing port configuration and cabling plan; if the replacement path is not stable, reconnect the original baseboard port, restore its settings, and verify traffic.

Swisscom XGS-PON GBIC on XGS Rev. 2

NC-168210 records a specific Swiss case for SFOS 21.5 GA Build 171: the Swisscom module ALL-BM410-XGSPON-GBIC is not supported in the 1 Gbps SFP ports of XGS Rev. 2 appliances.

Sophos identifies a 10 Gbps SFP+ port as a possible alternative, but also states that the module has not been tested internally in that port. Operation is therefore not guaranteed. A production connection requires confirmed port compatibility, a maintenance window, and an alternative provider connection in the plan.

This case illustrates the important distinction: a module may establish a link and still not be a tested, supported combination.