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:
- Identify the appliance model and hardware port: SFP, SFP+, QSFP, or Flexi Port.
- Check the supported speed and transceiver compatibility for that exact port.
- Match the transceiver, fibre or DAC, and the module at the peer.
- Under
Network > Interfaces, check Link Mode, Auto-Negotiation, and FEC. - Read the link and module data with
ethtool. - Replace the fibre, module, and peer port one at a time with known working components.
- 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.
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 view is preferable to a static list in this article because supported models and modules can change.
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.
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
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 Flexi Port modules in XGS 2100, 2300, 3100, and 3300, all SFP+ ports on the same module must be configured with the same speed. This restriction does not generally apply to every fixed SFP+ port or every XGS model.
⚠️ Changing an uplink can immediately interrupt the link and therefore WebAdmin access. Production WAN, core, or HA links require a maintenance window, an alternative administration path, and the previous values as a rollback path.
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
For ethtool, switch to Device Management > Advanced Shell. The consoles and SSH access are explained in Manage Sophos Firewall over SSH.
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: yesfor 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 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
dmesgfor 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.
Swisscom XGS-PON GBIC on XGS Rev. 2
The current Sophos Known Issues List records a specific Swiss case under NC-168210 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.