Set Up Link Aggregation (LAG) on Sophos Firewall

A Link Aggregation Group (LAG) bundles two to four physical ports of Sophos Firewall into one logical interface. This either increases the available bandwidth to the switch or provides redundancy if a port or cable fails. Depending on the vendor, LAG is also called trunking, NIC teaming, NIC bonding, or EtherChannel.

Configure Zones and Interfaces on Sophos Firewall already places LAG alongside VLAN, bridge, and RED at a planning level and explains when a LAG makes more sense than a single trunk port. This article goes one step further: it shows the concrete WebAdmin configuration, the required switch side, the Xmit Hash Policy, and how to properly test a LAG after setup.

When a LAG makes sense

A LAG is worthwhile especially when:

• the core switch needs redundant connectivity so a single port failure or a defective cable doesn’t interrupt the whole connection,
• multiple VLANs run over the same uplink and individual ports are reaching their capacity limits,
• the firewall needs more throughput between the firewall and the switch than a single physical port can deliver,
• an existing zone and VLAN structure should stay unchanged, but the physical connection needs to become more robust.

For small environments with a single, cleanly configured trunk port, a LAG is often unnecessary. A LAG also doesn’t replace clean zoning: in the end, the LAG interface remains a single interface that’s assigned a zone and on which VLAN interfaces can be built.

Prerequisites

• Two to four physical interfaces that are not already bound elsewhere, for example not already part of a bridge, a VLAN, or another LAG.
• All member interfaces must be of the same type and support the same speed and full duplex.
• A managed switch with LACP support, if 802.3ad should be used.
• Physical or planned access to the switch to configure the other side correctly.
• A maintenance window, because creating a LAG temporarily detaches the involved physical ports from their previous zone and configuration.

⚠️ PPPoE, cellular WAN, and WLAN interfaces can’t be used as LAG members. Only unbound physical interfaces are available as members.

1. Choose a bonding mode

Sophos Firewall supports two bonding modes:

• Active-Backup: One member link is active, the rest remain on standby. If the active link fails, a standby link takes over. This mode is simple, requires no special switch configuration, and is mainly suited for redundancy.
• 802.3ad (LACP): Multiple links are used in parallel for load distribution. LACP must be enabled on both sides, all member interfaces must be of the same type and speed, and all links must operate in full duplex.

For pure redundancy without extra bandwidth, Active-Backup is the simpler path. If you need real additional throughput between the firewall and the switch, choose 802.3ad, but you also have to configure the switch side correctly.

2. Create the LAG in WebAdmin

1. Open Network > Interfaces.
2. Select Add interface, then Add LAG.
3. Under Name, give it a descriptive name, for example LAG_Core_Uplink.
4. Under Hardware name, set a short technical name, maximum 10 characters, alphanumeric and underscores only. This name can’t be changed after creation and must not use a reserved system name such as all, gre, eth, or WLAN.
5. Under Member interface, add two to four suitable physical interfaces.
6. Under Bonding mode, choose Active-Backup or 802.3ad.
7. For 802.3ad, also set the Xmit Hash Policy: Layer2, Layer2+3, or Layer3+4.
8. Assign a Zone, matching the intended purpose, for example LAN or a dedicated core zone.
9. Choose IP assignment: static or DHCP, including an IPv4 or IPv6 address for static assignment.
10. Optionally adjust the MTU, if the network uses jumbo frames or other non-standard values.
11. Optionally, under MAC address, set a custom address instead of using the first member port’s.
12. Select Save.

After saving, the LAG interface, for example lag0, is available as a standalone interface. You can then create VLAN interfaces on it just as you would on a physical port. The procedure for VLAN interfaces on a LAG is identical to VLAN on a physical interface and is described in Set Up and Test VLAN on Sophos Firewall.

Choosing the Xmit Hash Policy correctly

The Xmit Hash Policy only matters for 802.3ad; it determines how incoming traffic is distributed across the member links. It doesn’t affect whether the LAG works, only how evenly the load is spread across the member ports.

• Layer2: Distribution by source and destination MAC address. Simple, but often uneven with few communication partners.
• Layer2+3: Distribution additionally by IP address. Usually a good default setting for mixed network traffic.
• Layer3+4: Distribution additionally by port number. Can deliver better distribution with many parallel connections between the same hosts, but doesn’t work equally well for every traffic type, for example heavily fragmented or non-classic TCP/UDP traffic.

The chosen policy must match between the firewall and the switch so both sides distribute traffic consistently. A mismatch doesn’t necessarily cause a complete outage, but it can lead to uneven load on individual links.

3. Configure the switch side

A LAG only works reliably if the switch side is configured to match. The firewall and switch must agree on the same bonding mode.

With Active-Backup, many switches only need a simple port configuration without special trunk grouping, because only one link carries active traffic at any time. Still, check whether Spanning Tree or port security on the switch is configured in a way that unnecessarily delays a switch of the active link.

With 802.3ad (LACP), the involved switch ports must:

• be in the same link aggregation group, for example a port channel on Cisco switches or a LAG group on other vendors,
• actively use LACP, not just static bonding without a protocol,
• use the same speed and duplex mode as the firewall side,
• be configured in the same VLAN trunking mode that matches the planned VLAN structure on the firewall.

If a LAG is created only on the firewall while the switch continues to run independent, individual ports, hard-to-diagnose problems often follow: partial packet loss, asymmetric behavior, or a LAG that shows as active but doesn’t deliver the expected throughput.

4. Test the LAG after setup

A newly created LAG shouldn’t just be checked for a green status; it should be tested under real failure and load conditions.

Useful tests:

1. Normal-operation connectivity test: Check throughput and reachability over the LAG before simulating a failure.
2. Disconnect a single member link: Unplug one member port’s cable and check whether the connection continues without noticeable interruption.
3. Reconnect the second member link: Check that the link is cleanly rejoined into the LAG without requiring manual intervention.
4. Distribute load across multiple connections: With 802.3ad, generate several parallel connections with different source/destination combinations and check whether traffic actually runs across multiple member ports.
5. Check switch-side status: On the switch, confirm the port channel or LACP group shows all expected ports as active.

For checking interface status on the firewall, the general approach from Configure Zones and Interfaces on Sophos Firewall applies. If management access, DNS, or authentication are affected after the change, Fix Sophos Firewall ARP Issues After Migration also helps if multiple interfaces are involved in the same subnet.

Common mistakes

• Member interfaces with different speed or duplex: 802.3ad doesn’t work reliably or at all. All member ports must be configured identically.
• Switch not switched to LACP: The firewall may show the LAG as active, but in reality only one link runs cleanly or traffic is unstable. Check the switch-side port channel or LACP configuration.
• Interface already bound elsewhere: An interface that’s already part of a bridge or a VLAN isn’t available as a LAG member. Resolve the existing binding first.
• PPPoE, cellular, or WLAN interface chosen as a member: These interface types aren’t supported as LAG members on Sophos Firewall.
• Xmit Hash Policy differs between firewall and switch: The LAG runs, but load distributes unevenly across individual links. Align the policy on both sides.
• Trying to change the hardware name afterward: Not possible. If the name was chosen incorrectly, the LAG must be recreated.
• No failover test performed: A LAG that was never tested under real failure can behave differently in an actual incident. Perform a cable-pull test before production use.
• Zone and firewall rules not adjusted: After moving ports into a LAG, old rules may still reference the wrong interfaces. Check zone and rule assignment after the migration.

Checklist

• Two to four suitable, unbound physical interfaces identified.
• Bonding mode chosen deliberately: Active-Backup for redundancy, 802.3ad for load distribution.
• Switch side configured with a matching port channel or LACP.
• Xmit Hash Policy aligned between firewall and switch, if 802.3ad is used.
• Zone, IP assignment, and MTU set to match the intended purpose.
• Failover tested by pulling a cable.
• Load distribution with 802.3ad checked using multiple parallel connections.
• Firewall rules and zone assignment checked after the migration.
• Maintenance window planned for setup, since existing ports are temporarily disconnected.

FAQ