Setting Up and Troubleshooting Sophos SD-RED

A Sophos SD-RED can be used to connect remote offices, branches, or smaller home office locations to a Sophos Firewall. The RED establishes an encrypted tunnel to the firewall and provides a network at the remote location that is centrally managed through the firewall.

The practical advantage: On-site, there is usually no need for complex VPN configuration. The SD-RED connects to the internet, downloads its configuration via the Sophos RED Provisioning Service, and then establishes the tunnel to the Sophos Firewall. However, the tunnel alone does not solve everything. Zones, firewall rules, DHCP, VLANs, routing, DNS, and firmware status must also be correct.

The operation mode must be selected before the actual configuration. It determines DHCP, the gateway, the internet path, central control, and behavior during a tunnel outage. Choose the right Sophos RED operation mode explains the differences and decision criteria.

Planning and requirements

Context: SD-RED and Firewall-to-Firewall RED

RED has two current use cases that must be kept separate. This article covers a physical SD-RED 20 or SD-RED 60 at a branch site. SFOS 22 also continues to support a Site-to-Site RED tunnel between two Sophos Firewalls, with one firewall acting as Firewall RED server and the other as Firewall RED client.

The second use case does not require RED hardware. Set up Site-to-Site RED between two Sophos Firewalls explains the provisioning file, static routes without a selected interface, rules on both sides, and the RED service. SD-RED operation modes do not apply to that design.

Requirements at the Main Site

Before connecting the RED, the following points should be clear on the Sophos Firewall:

• RED Service is enabled on the firewall.
• Public IP address or DNS/DynDNS name of the firewall is reachable.
• RED connections to the firewall are allowed on the WAN side.
• RED is allowed under Administration > Device access for the appropriate WAN zone or specifically allowed via Local Service ACL.
• RED interface, zone, and IP configuration are planned.
• Firewall rules from the RED network to the target networks are provided.
• DHCP, DHCP Relay, or static addressing for clients behind the RED is clarified.
• RED Firmware Pattern on the firewall is up to date.
• Backup and firmware status of the firewall are documented before major changes.

For RED communication, TCP 3400, UDP 3410, and NTP 123 are particularly relevant. These connections must not be blocked by provider routers, upstream firewalls, or security gateways.

Requirements at the Remote Site

At the remote site, the SD-RED needs a stable internet connection. Not only bandwidth is crucial, but especially stability, latency, packet loss, and whether the provider allows the required connections.

Check:

• Internet connection is stable.
• WAN port of the RED receives an address via DHCP or has a correct static configuration.
• Default gateway is reachable.
• DNS works.
• NTP is reachable.
• TCP 3400, UDP 3410, and NTP 123 are not blocked.
• Provider router or upstream firewall does not perform unexpected filtering.
• For VLANs, it is clear which port operates as tagged, untagged, or hybrid.

For simple locations, a small connection is often sufficient. In practice, however, packet loss, unstable consumer routers, CGNAT, DNS issues, or restrictive provider firewalls are more often the cause than pure bandwidth.

Provisioning and commissioning

Provision Automatically Through the Sophos Provisioning Service

For standard online provisioning, the firewall and SD-RED need internet access. The SD-RED must obtain a WAN address through DHCP during its first startup so it can download its configuration. On the firewall, turn on the RED provisioning service under System services > RED, enter the contact information, and accept the Sophos terms of use.

Then create an interface under Network > Interfaces > Add interface > Add RED. Set Branch name, device type, Automatically via provisioning service, firewall address, uplink, operation mode, RED network, zone, and DHCP for the site. For a RED used for the first time, leave Unlock code blank. After saving, the firewall uploads the configuration to the provisioning service. The SD-RED retrieves it, opens the control channel on TCP 3400, and then establishes the Layer 2 tunnel on UDP 3410.

When the configuration is saved for the first time, the provisioning service generates a device-specific unlock code. It appears in WebAdmin and is sent to the email address configured under System services > RED. Store the code securely because it is required when moving the RED to another firewall. WebAdmin displays it again when the interface is deleted. If it is unavailable, contact Sophos Support.

Set Global RED Security Options Deliberately

During initial activation under System services > RED, SFOS creates a certificate for RED communication from Organization name, City, Country, and Email. Therefore, Organization name and City must not contain umlauts or special characters. The email address must remain reachable because Sophos sends new unlock codes to it.

For current SD-RED 20 and 60 appliances, TLS v1.2 (strict) and later is the sensible starting point. This selection only uses the TLS 1.2 ciphers recommended by Sophos. TLS v1.2 and later additionally includes ciphers Sophos doesn’t recommend and should not be selected without a verified compatibility requirement. After changing this setting, reconnect and test every production RED tunnel in a controlled manner.

Automatic device deauthorization prevents a RED that has been disconnected for a long time from remaining authorized indefinitely. The period must fit the organization’s incident and replacement process: The device isn’t deleted when the period expires, but the RED interface must be explicitly turned on again under Network > Interfaces. Monitoring and unlock-code documentation are therefore part of this safeguard.

Keep RED unified firmware turned on for SD-RED 20 and 60. A new RED firmware pattern is deliberately installed under Backup & firmware > Pattern updates and isn’t installed automatically. Plan a maintenance window and then test the tunnel and a client.

Connecting the SD-RED

Typical procedure:

1. Connect the WAN port of the SD-RED to the provider router or modem.
2. Connect the LAN port to a test client, switch, or local network.
3. Power the SD-RED.
4. Wait for the RED to start, check the gateway and internet, load the configuration, and establish the tunnel.
5. Check on the Sophos Firewall if the RED interface is active.
6. Connect a test client behind the RED and check IP, DNS, gateway, and target access.

If all relevant LEDs are green, the technical tunnel is established. Then the actual network check begins: zone, DHCP, firewall rules, return routing, DNS, and VLANs if needed.

Manual Provisioning with USB Stick

Usually, an SD-RED is provisioned through the Sophos RED Provisioning Service. Manual provisioning by USB stick is useful when the device is in a private or heavily restricted network, needs a static WAN configuration, or the automatic provisioning path is not reliable.

The process is more precise than just copying a provisioning file to USB:

1. On the firewall, go to Administration > Time, select Use custom NTP server, and add the firewall’s IP address as the NTP server. During manual setup, the RED must be able to obtain a valid time from the firewall over the planned path so that the TLS handshake works.
2. Under Network > Zones, create a dedicated zone for RED sites or use an existing zone such as VPN or WiFi. Avoid the LAN zone for RED so LAN rules don’t unintentionally apply to the remote site.
3. Under System services > RED, enable the RED Provisioning Service.
4. Under Network > Interfaces > Add interface > Add RED, create the RED interface.
5. For Device deployment, select Manually via USB stick.
6. Enter RED ID, Unlock Code, uplink, RED network settings, zone, DHCP, and VLANs for the site.
7. Download the generated provisioning file from the RED interface.
8. Copy the file to the root directory of the USB stick.
9. Turn off the RED, insert the USB stick, and turn the RED back on.
10. After startup, check interface, LEDs, client IP, DNS, firewall rule, and target access.

If the RED WAN side uses DHCP, a DHCP server must actually answer at the remote site. If the RED does not receive an address, it can enter a restart loop. With static WAN configuration, IP address, gateway, DNS, and NTP must be checked especially carefully.

Offline REDs still need valid time. Either the RED can reach the Sophos NTP servers, or a targeted Local service ACL exception rule is planned so the RED can talk from the WAN zone to the firewall. The source should only be the known RED IP, the destination is the firewall WAN port, the service in this scenario is HTTPS, and the action is Accept. This exception is not a replacement for opening RED broadly over WAN.

Status, updates, and migration

Understanding LED Status

The status LEDs are often the quickest entry point for RED troubleshooting, as they indicate where the startup process is stuck.

Legend:

• ⚫ off
• 🟢 solid green
• 🟢 blinking green
• 🔴 solid red
• 🔴 blinking red

Depending on the viewing angle, photo, or ambient light, an LED may appear yellowish or orange. For diagnosis, what matters is which LED is on or blinking and whether it is green or red.

Normal Boot Process

If all four LEDs are green but no traffic works, the problem is usually not with the tunnel setup. Then firewall rules, DHCP, VLANs, DNS, NAT, or routing are more likely.

Error Codes

3G/4G Failover

For SD-RED models with 3G/4G failover or corresponding module, additional patterns may occur.

Controlling Firmware Updates

If the LEDs blink together, the RED is currently installing firmware. During this phase, the device should not be turned off or disconnected from the internet. An update can take several minutes.

On the Sophos Firewall, you should also check:

Backup & firmware > Pattern updates

The RED Firmware Pattern must be up to date there. If a RED is stuck in a loop or does not start cleanly after a firewall update, an outdated RED Firmware Pattern is a sensible check. Configure and check Sophos Firewall pattern updates explains how the statuses, automatic download and deliberate installation work together.

A related operational request is described in Sophos Firewall Feature Request 2024: For RED and Access Point firmware updates, directly visible release notes are often missing in the backend. For productive environments, updates should therefore be planned consciously and not installed uncoordinated during critical operating times.

Checking RED Interface, Zone, and Rules

After a successful tunnel setup, the RED needs a clean firewall configuration.

Typical checkpoints:

• RED interface is active under Network > Interfaces.
• Interface is in the correct zone.
• DHCP Server or DHCP Relay is correctly set up.
• Clients receive IP address, gateway, and DNS.
• Firewall rules allow only the necessary targets.
• Return routing to the RED network works.
• NAT is only used if it is consciously planned.
• VLAN configuration matches the RED mode and the switch port.

For rule basics, see Understanding and Configuring Sophos Firewall Rules. If the tunnel is up but traffic does not flow, you should combine Log Viewer and Packet Capture.

The optional MAC filtering type can implement a device-limited allow or block list on the RED network, but it does not replace a firewall rule. Remote IP assignment is not a default setting either: It assigns an address to the bridge with the RED tunnel on the WAN side through DHCP or statically and is only investigated when devices behind the RED do not answer ARP requests. Do not enable either option as a generic performance or connectivity fix.

Upgrade and Migration Pitfalls

Do not confuse Site-to-Site RED with SD-RED

A firewall-to-firewall RED tunnel remains a supported, separate design under SFOS 22. It does not use any of the four SD-RED operation modes and is not defined through DHCP or the LAN ports of an SD-RED. During an upgrade, inventory both RED types and validate each one with its appropriate functional test.

For larger upgrade planning, see Properly Planning Sophos Firewall Firmware Updates. The complete firewall-to-firewall workflow is available under Set up Site-to-Site RED between two Sophos Firewalls.

Remove Legacy Firewall RED and Old RED Devices Before SFOS 22

SFOS 22.0 and later no longer support Firewall RED Server Legacy and Firewall RED Client Legacy. As long as such a UTM-to-SFOS configuration exists, upgrades, restores, and configuration imports to SFOS 22 are blocked. This does not affect the current Firewall RED server and Firewall RED client types. Before upgrading, replace all dependencies of the legacy interfaces, delete the interfaces, and then create a new configuration backup.

RED 15, RED 15w, and RED 50 are also end-of-life. Their tunnels no longer connect as of SFOS 20.0 MR1. After an upgrade or restore to SFOS 22, the old configuration remains visible but is not implemented and can only be deleted. It cannot be imported. Migrate these sites to SD-RED 20 or SD-RED 60 before the upgrade and test their actual data path.

RED System Hosts After SFOS 21.5 MR1

Since SFOS 21.5 MR1, RED system host objects receive the correct /32 subnet mask. If such automatically generated RED system objects were previously used in rules or other configurations for more than one host IP, traffic may match differently after the update.

After an upgrade, you should check:

• Are RED system hosts used in firewall rules?
• Does a rule mistakenly expect a network instead of a single host?
• Do IP Host or Network Host objects need to be replaced?
• Do rule matches in the Log Viewer still match?

RED and HA Failover

In HA environments, RED sites should be tested deliberately after a failover. Sophos notes that RED tunnels may not always reconnect immediately to the auxiliary device after an HA failover. The duration depends, among other things, on the number of interfaces and the configuration.

For critical sites, do not only check the firewall HA status. Also check:

• RED interface status after failover
• client access behind the RED
• relevant firewall rule matches
• DNS and DHCP behind the RED
• monitoring alerts for longer tunnel interruptions

Check RED Throughput and Performance

Sophos specifies a maximum tunnel throughput of 250 Mbit/s for SD-RED 20 and 850 Mbit/s for SD-RED 60. These are platform maximums, not a commitment for an individual SMB transfer, browser speed test, or single TCP stream. Endpoints, storage, TCP window, actual site-to-site latency, packet loss, the provider path, firewall load, and security profiles also affect the result.

A ping of, for example, 8 ms to a public speed test server does not necessarily describe the latency between the two RED sites. A speed test on each internet connection does not test the encrypted end-to-end path through the RED tunnel either. This question requires a test server in one LAN and a test client in the LAN at the other site.

Test the RED Tunnel with iPerf3 in Both Directions

Before testing the tunnel, create a local baseline with the same wired endpoints. Then run iPerf3 through the RED tunnel, first with one TCP stream, then in the reverse direction, and finally with four parallel streams:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 is only an example address and must be replaced with the IP address of the iPerf3 server in the remote LAN. The test deliberately generates load and belongs in an appropriate maintenance window. Test Sophos Firewall performance correctly with iPerf3 explains installation, the temporary firewall rule, UDP tests, and complete result analysis.

The three results answer different questions:

• If the local baseline is already slow, check endpoints, NICs, drivers, cables, switches, and storage first.
• If one stream is significantly slower than -P 4, latency, the TCP window, or the individual application flow is more likely to be limiting. This does not yet prove a RED limit.
• If one and four streams stop at the same limit in both directions, investigate physical links, the provider path, packet loss, RED configuration, and firewall load.
• If only one direction is slow, compare the relevant upload rates, interface counters, errors, drops, and return path.

A typical real-world pattern would be around 400 Mbit/s with one stream and between 700 Mbit/s and 800 Mbit/s with -P 4. This suggests that the path can carry significantly more aggregate capacity, while a single TCP or SMB flow cannot use all of it. It does not guarantee that every application will reach the same multi-stream result.

During every run, document the actual round-trip time and packet loss between the sites, iPerf retransmissions, Firewall Rule ID, security profiles, firewall CPU, and counters on the participating ports. WAN and LAN links must actually operate at 1 Gbit/s, full duplex, without rising error or drop counters. Leave speed and duplex on auto-negotiation at both ends instead of forcing only one side to gigabit.

Do not disable IPS or other security profiles broadly. For an A/B test, at most use a narrow temporary rule for the specific test source, test destination, and iPerf3 service, then remove it immediately. If the result does not change without IPS, IPS is less likely to be the cause for this exact test path.

Actually Turn Off 802.3az or EEE

For optimal performance, Sophos recommends turning off 802.3az on switches connected to an SD-RED 20 or SD-RED 60. This means Energy Efficient Ethernet, or EEE. EEE puts parts of the Ethernet PHY into Lower Power Idle when link utilization is low, saving energy. It is not the same as PoE or 802.3x Flow Control.

The setting is not in Sophos Firewall WebAdmin or CLI, nor in a documented SD-RED screen. It is changed on the directly connected switch port. This applies to LAN links in use on the RED and, if a managed switch or router is involved there, also to the physical WAN link. On other vendors’ devices, the option may be named EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az, or Power Saving. There is no universal CLI for it.

On a Sophos Switch, use the Port settings page:

1. Select the port connected directly to the SD-RED.
2. Open Edit.
3. Set EEE status to Off.
4. Save with Apply.
5. Check link status, negotiated speed, duplex, and error counters, then repeat the same iPerf3 test.

On a current Sophos Switch, the status can be displayed read-only in the CLI:

show eee

For example port 0/1, turn off EEE as follows:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

Replace 0/1 with the port actually connected to the RED. no eee changes the port configuration. If the switch is reachable only through this RED path, use a maintenance window and local or alternative management access. Depending on the switch and firmware, the change may trigger link renegotiation.

To roll back on a Sophos Switch, use eee instead of no eee in the same Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Turning off EEE disables neither Ethernet nor gigabit. The trade-off is that the PHY no longer saves the same amount of energy during idle periods, so the port consumes slightly more power and may generate more heat. There is no guarantee of a specific throughput increase. The reproducible before-and-after test is what matters. An unmanaged switch without an EEE option cannot be changed reliably; bypass it for the test or temporarily use a managed switch.

Change Tunnel Compression and MTU Only in a Controlled Test

Edit the RED interface under Network > Interfaces. The settings include Tunnel compression and MTU. Sophos describes Tunnel compression as a way to compress RED traffic and increase throughput, especially on slow connections. Data that is already compressed or encrypted can hardly be reduced further, while compression adds processing work. Therefore, one setting is not correct for every site.

For an A/B test, first document the initial state and measurements. Then change only Tunnel compression, save, and repeat exactly the same iPerf3 series. Restore the initial state afterward or deliberately document the demonstrably better option. Saving may briefly interrupt the RED tunnel, so a maintenance window and alternative access are sensible.

MTU is not a general speed control. Investigate it only when small packets work but larger transfers stall, fragmentation is visible, or iPerf3 shows many retransmissions. Check Sophos Firewall MTU and MSS for VPN problems explains the safe DF test, packet sizes, and rollback. Without a reproducible MTU finding, keep the documented initial value.

Troubleshooting

RED IP Can’t Be Changed in SFOS 22.0 MR2

On SFOS 22.0 MR2 Build 546, changing the IP address of an existing RED interface can produce the message Failed to update RED interface. The tricky part is that WebAdmin may already show the new IP even though the firewall continues to use the old address internally. The displayed IP alone therefore does not prove that the change succeeded.

The workaround documented by Sophos also changes the branch name and saves the interface again:

1. Document the current RED IP, netmask, Branch Name, and any existing RED DHCP range.
2. Under Network > Interfaces, open the affected RED interface and enter the required IP address.
3. If Failed to update RED interface appears, open the interface again.
4. Actually change Branch Name, for example from Branch-Zurich to Branch-Zurich-01, and save again with Save.
5. In 5. Device Management > 3. Advanced Shell, use the read-only command ifconfig to check whether the new address is active on the RED interface:

ifconfig

The interface name depends on the configuration and can be identified by comparing it with the entry under Network > Interfaces. Restarting the firewall or a service, or deleting the RED interface, is not part of this workaround.

If the new RED IP is in a different network from the previous RED DHCP range, SFOS turns off the RED DHCP server. This is normal product behavior and is independent of the error message. Under Network > DHCP, the existing server must then be adapted to the new network or a new DHCP server must be created. The lease range, static MAC mappings, gateway, and DNS must match the new addressing.

Finally, renew the DHCP lease on a client behind the RED and check the IP address, gateway, DNS, tunnel status, and intended access. In Log Viewer, the traffic should again match the expected firewall rule. If the backend IP remains unchanged after saving again, no released production fix is currently documented for NC-184971. Dependent rules or interfaces should not be deleted on suspicion; instead, the configuration should be backed up and Sophos Support involved.

RED Does Not Receive an IP Address

If the RED gets stuck at the router step or the error code points to DHCP or gateway, the cause is usually at the remote site.

Check:

• Does the provider router issue an IP address via DHCP?
• Is the network cable correctly plugged into the WAN port?
• Is the default gateway reachable?
• Was a static IP address fully entered?
• Do IP address, subnet mask, gateway, and DNS match?
• Does an upstream device block the traffic?

If DHCP does not work at the remote site, the RED can end up in a restart loop.

RED Does Not Reach the Internet

If the router or gateway is reachable but the internet LED does not turn solid green, the problem is usually behind the local router.

Check:

• Does the internet connection work with a normal client?
• Does DNS work?
• Is NTP reachable?
• Are TCP 3400, UDP 3410, or NTP 123 blocked?
• Is there a proxy or firewall between RED and the internet?
• Is the provider connection stable enough?

For RED provisioning, the RED must reach the Sophos Provisioning Service. Sophos documents *.astaro.com over TCP 3400 and UDP 3410; the other vendor destinations and validation boundaries are in Check Sophos Firewall outbound services and ports.

RED Does Not Reach the Sophos Firewall

If the internet is reachable but the tunnel is not established, check the firewall side.

Check:

• Is the RED Service enabled on the Sophos Firewall?
• Is the RED correctly set up?
• Do RED ID and Unlock Code match?
• Is the public IP or FQDN of the firewall reachable?
• Is Administration > Device access for RED allowed in the appropriate WAN zone?
• Does a Local Service ACL allow access from the remote site?
• Do TCP 3400 and UDP 3410 reach the firewall?
• Does the RED time fit the TLS handshake during manual provisioning?
• Can an offline RED reach NTP or the planned Local Service ACL exception?

In the Advanced Shell, you can check if RED traffic arrives:

tcpdump -ni any port 3400 or port 3410

If nothing arrives, the problem is usually before the firewall: provider router, NAT, upstream firewall, incorrect public IP, FQDN, or port blockade.

RED Keeps Restarting

A restart loop can have several causes:

• unstable power supply
• defective power supply unit
• no IP address via DHCP
• incorrect static IP configuration
• blocked ports
• outdated RED Firmware Pattern
• incorrect Unlock Code
• corrupted or incorrect RED configuration

First, check power supply, cables, and DHCP. Then check RED Firmware Pattern, port reachability, and configuration. If the RED is newly set up or reset, RED ID and Unlock Code must be documented beforehand.

Tunnel is Green, but No Traffic Flows

This case is particularly common. The RED is connected, but clients cannot reach internal systems or the internet.

Possible causes:

• Firewall rule is missing or too low.
• RED interface is in the wrong zone.
• DHCP distributes incorrect gateway or DNS servers.
• Return routing to the RED network is missing.
• NAT translates traffic unexpectedly.
• VLAN tagging does not match.
• Security feature blocks the traffic.

Check sequence:

1. Check client IP, gateway, and DNS.
2. Filter Log Viewer on the source IP of the RED client.
3. Check firewall rule match.
4. Perform Packet Capture on RED interface and target interface.
5. Check return path from the target system or target network.
6. Check NAT and routing.

For unclear rule matches, see Testing Firewall Rules with Log Viewer, Policy Test, and Packet Capture.

VLAN Traffic Does Not Work

With SD-RED 60, VLAN scenarios are possible, but port mode, VLAN ID, and RED mode must match.

Check:

• VLAN IDs match on firewall, RED, and switch.
• RED port is configured as Access, Hybrid, or Tagged Trunk appropriately.
• Switch port at the remote site is correctly tagged or untagged.
• DHCP and DNS are planned per VLAN.
• Firewall rules exist for the respective VLAN networks.
• The chosen RED mode supports the desired VLAN scenario.

For troubleshooting, a simple untagged test network is helpful. If this works, the cause is usually with VLAN ID, tagging, port mode, or switch configuration.

RED Access Points Remain Inactive

If RED Access Points or Wi-Fi functions in VLAN scenarios remain inactive, DHCP Option 234 may be relevant. This mainly affects cases where RED or Access Point communication runs over VLAN interfaces.

This option should only be set if the specific scenario fits and it is clear which firewall interface IP the devices should reach. For general RED connection problems, DHCP Option 234 is not the first step.

Offline Provisioning is Overwritten

If a RED was first provisioned online and later provisioned offline via USB, an old online configuration may remain on the Sophos Provisioning Server. If the RED does not reach the firewall, it may provision online again and overwrite the USB configuration.

Then the RED must be provisioned offline again. Additionally, the old online configuration should be removed via Sophos Support.

Diagnostics and operational check

Diagnostic Points on the Sophos Firewall

For RED issues, these points are helpful:

• Network > Interfaces for RED interface and status
• Administration > Device access for RED service permissions
• Rules and policies > Firewall rules for traffic from the RED network
• Diagnostics > Packet capture for path checking
• Log viewer with RED, firewall, and system events
• Backup & firmware > Pattern updates for RED Firmware Pattern
• Advanced Shell with tcpdump

A successful connection can also be confirmed in the device-specific logs. /log/red.log shows a message such as New connection from ... with ID <RED ID>. /log/red-<RED ID>.log then includes connected OK, pushing config and, after a reconnection, is now re-connected. These lines confirm the connection and configuration transfer, but not a working production traffic path. The complete device-specific log can contain provisioning and configuration data and must be sanitized before sharing.

For log files and service assignment, see Sophos Firewall Troubleshooting: Services and Logs.

If instead the entire firewall starts in failsafe mode with Failed to start Red server service, this is not an ordinary RED tunnel issue. The failsafe runbook explains the build distinction and how to preserve evidence before recovery.

Operational Checklist

Before rollout:

• RED ID and Unlock Code documented.
• Public firewall address or FQDN checked.
• TCP 3400, UDP 3410, and NTP 123 checked.
• RED Service and Device Access planned on the firewall.
• Zone, DHCP, routing, and firewall rules defined.
• VLAN mode tested in advance if needed.

After connecting:

• LEDs indicate successful tunnel setup.
• RED interface is active.
• Client receives IP, gateway, and DNS.
• Log Viewer shows expected firewall rule.
• Internal target systems and internet path work as planned.
• Firmware Pattern is up to date.

In operation:

• Regularly check RED firmware pattern.
• Test site connections after firewall upgrades.
• Test firewall-to-firewall RED tunnels separately from physical SD-RED sites.
• Check RED system hosts for /32 impacts after SFOS 21.5 MR1.
• Compare RED throughput using a local baseline, one and four iPerf3 streams, and both directions.
• Keep 802.3az or EEE turned off on directly connected switch ports and check it again after switch replacements.
• Change Tunnel compression and MTU only with a documented before-and-after test.
• Include RED sites in monitoring, backup, and emergency planning.

FAQ