Troubleshooting Sophos SD-RED 20 Internet Connectivity Issues

I had a Sophos SD-RED 20 that would not pass traffic to the internet despite the WAN showing a static public IP. This guide lists what to look for, how to test, and the precise fixes I use. I keep it hands-on and short. Run the commands I show and compare the expected output to what you actually get.

What you see

Error messages displayed

Look for exact log lines. Common ones are:

• “ICMP: Destination Host Unreachable”
• “Network is unreachable”
• “Default gateway not set”
• “RED device remote connection failed” (from Sophos Central/XG)

Copy the exact lines. If support asks, paste them. Logs are the fastest route to the root cause.

Connectivity status indicators

Check LEDs on the SD-RED 20. Green means link. Amber or off means no physical link. In the Sophos UI or Central, check:

• RED status: connected / disconnected
• WAN IP: shows static address or 0.0.0.0
• Uplink: link speed and duplex

If the device shows a static IP but still fails, it often means routing, gateway, or ISP side blocking.

Diagnostic tool outputs

Run these from a host on the LAN and from the SD-RED shell where possible.

From LAN host:

• ping 8.8.8.8
  • expected: replies, e.g. “64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=20 ms”
  • actual problem: “Destination Host Unreachable” or “100% packet loss”
• traceroute 8.8.8.8
  • expected: first hop is your gateway IP
  • actual: stops at local gateway or shows no hops

From device (or via SSH to the firewall side):

• ip addr show
  • expected: WAN interface has the static public IP configured
• ip route show
  • expected: “default via dev eth0″
  • actual problem: no default route or wrong gateway

Collect those exact outputs before changing anything.

Where it happens

Specific network environments

This usually appears in two setups:

• SD-RED 20 behind an ISP modem/router where the modem is in router (NAT) mode.
• SD-RED 20 connected directly to a fibre ONT or a bridged modem.

If the modem supplies a private IP on the WAN port, double NAT can break inbound rules and confuse static IP expectations.

ISP-related issues

ISPs sometimes require:

• VLAN tagging on the WAN (common on fibre)
• PPPoE authentication instead of simple static IP
• Route propagation for a public block

If the SD-RED has a static IP but the ISP expects PPPoE or a tagged VLAN, packets never hit the internet even though the device shows an address.

Firewall configurations

Common causes inside the firewall:

• No outbound firewall rule for the LAN to internet.
• Missing NAT (SNAT) for LAN traffic to the WAN IP.
• Explicit deny rules matched before allow rules.

A misapplied rule can appear to give the device connectivity while blocking traffic.

Find the cause

Testing static IP configuration

Verify the static IP and gateway precisely.

On the SD-RED or firewall CLI:

• ip addr show dev eth0
  • expected: inet 198.51.100.10/24
• ip route show
  • expected: default via 198.51.100.1

From a LAN host:

1. ping the WAN gateway: ping 198.51.100.1
   • expected: replies
   • actual failure means the gateway is not reachable from the SD-RED.
2. curl –interface -I http://1.1.1.1
   • expected: HTTP status or ICMP response
   • actual: timeout or no route

If gateway pings fail, either the static IP/gateway are wrong, the ISP has not routed the IP, or VLAN/PPPoE is required.

Reviewing firewall rules

List rules in the Sophos GUI or run a policy dump. Look for:

• Allow rule: LAN -> Any (SNAT to WAN)
• Deny rule that matches before the allow rule

Diagnostic checks:

• Temporarily add an explicit allow rule: LAN -> Any: Allow, log, position at top.
• Test ping/curl again. If it works, the issue was rule order.

Checking ISP settings

Call out the ISP checks to perform:

• Confirm the static IP and gateway the ISP assigned.
• Ask if VLAN tag or PPPoE is required.
• Confirm no port blocks that affect management tunnels (some SD-RED uses ports for heartbeats).

Practical test: plug a laptop directly into the ISP modem and configure the static IP and gateway. If the laptop cannot reach the internet with the same IP/gateway, the fault is ISP-side.

Fix

Steps for reconfiguring settings

1. Confirm the WAN mode. If ISP requires VLAN or PPPoE, set the SD-RED WAN accordingly.
2. Set the static IP and gateway exactly as provided by the ISP.
3. Add a default route if missing:
   • ip route add default via dev eth0
4. Ensure DNS is set to resolvers the ISP or public DNS provides.

Make one change at a time. Test after each change.

Troubleshooting network connections

1. Test physical link: replace cable and try another switch port.
2. Test direct connection: connect a laptop with the static IP to the WAN port.
3. Capture packets at the WAN side:
   • tcpdump -i eth0 host and watch for ARP requests/replies.
   • expected: ARP replies from gateway MAC.
   • actual failure: ARP requests unanswered means no layer 2 reachability.

If ARP fails, the ISP is not routing or the link has VLAN/PPPoE mismatch.

If NAT is missing:

• Add SNAT for LAN -> WAN IP.
• Verify outbound connections now have the WAN IP source with a site like ifconfig.me from a laptop.

Verifying device firmware updates

Check firmware in the Sophos Central or the SD-RED management page. Firmware bugs can break tunnels or routing. If an update is available:

• Note current version.
• Read the release notes for known fixes.
• Schedule an update window.
• Update and retest connectivity.

If support suspects firmware, produce logs and version info before updating so you can rollback if needed.

Check it’s fixed

Confirming internet access

From a LAN host and from the SD-RED:

• ping 8.8.8.8 — expected: <5% packet loss and sub-100 ms latency
• curl -I https://example.com — expected: 200 or 301 headers
• traceroute to public IP — expected: first hop is ISP gateway

Also confirm NAT:

• Visit ifconfig.me from a LAN host and confirm the external IP matches the assigned static IP.

Monitoring connectivity stability

Watch logs for a period after the fix:

• tail -f /var/log/messages (or Sophos log view)
• Look for repeated “remote connection failed” entries or interface flaps.

Set a short scripted check:

• while true; do ping -c1 8.8.8.8 || echo “$(date) ping failed”; sleep 60; done
  This gives immediate notice of intermittent failures.

Documenting changes made

Write a tight change log:

• Date, change made, who authorised, exact commands, before/after outputs, rollback steps.

Include the exact errors you saw and the final verification outputs. That makes future troubleshooting much faster.

Root cause and remediation

• If gateway unreachable and ARP fails, the root cause is layer 2/ISP configuration. Remediation: correct VLAN/PPPoE or get ISP to route the static IP.
• If default route missing, the root cause is misconfigured gateway. Remediation: set the correct default route.
• If firewall rules blocked traffic, the root cause is rule order or missing NAT. Remediation: add explicit allow and configure SNAT.

I keep changes minimal and reversible. Do one thing at a time and capture exact before/after outputs. That prevents chasing ghosts and speeds resolution.