Resolving Sophos SD-RED 20 internet connectivity problems

Troubleshooting Sophos SD-RED 20 internet connectivity issues

I had a Sophos SD-RED 20 that would not pass traffic to the internet, even though the WAN showed a static public IP. The useful bit is in the logs and the routes, not the pretty dashboard.

Error messages displayed

Look for the 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 for logs, send them. They are usually faster than guessing.

Connectivity status indicators

Check the 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 or disconnected
WAN IP: static address or 0.0.0.0
Uplink: link speed and duplex

If the device shows a static IP but still fails, the problem is usually routing, gateway, or something the ISP is doing at the far end.

Diagnostic tool outputs

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

From a LAN host:

```
ping 8.8.8.8
```
Expected: replies, for example 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=20 ms

Problem: Destination Host Unreachable or 100% packet loss
```
traceroute 8.8.8.8
```
Expected: the first hop is your gateway IP

Problem: it stops at the local gateway or shows no hops

From the device, or via SSH to the firewall side:

```
ip addr show
```
Expected: the WAN interface has the static public IP configured
```
ip route show
```
Expected: default via <ISP gateway> dev eth0

Problem: no default route or the wrong gateway

Collect the output before changing anything. Saves time and stops you chasing the wrong thing.

Where it happens

This usually shows up in two setups:

SD-RED 20 behind an ISP modem/router that is running in router, or NAT, mode.
SD-RED 20 connected directly to a fibre ONT or a bridged modem.

If the modem hands out a private IP on the WAN port, double NAT can break inbound rules and make static IP expectations look wrong.

ISP-related issues

ISPs sometimes require:

VLAN tagging on the WAN, which is common on fibre
PPPoE authentication instead of a plain 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 will not reach the internet even though the device shows an address.

Firewall configurations

Common causes inside the firewall:

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

A bad rule can make the device look healthy while blocking traffic underneath it.

Testing static IP configuration

Verify the static IP and gateway exactly.

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:

Ping the WAN gateway:
```
ping 198.51.100.1
```
Expected: replies

Failure means the gateway is not reachable from the SD-RED.
Test a plain HTTP request:
```
curl --interface <lan-ip> -I http://1.1.1.1
```
Expected: an HTTP status or an ICMP response

Failure means timeout or no route

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

Reviewing firewall rules

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

Allow rule: LAN -> Any, with SNAT to WAN
Deny rule that matches before the allow rule

Diagnostic check:

Add an explicit allow rule at the top: LAN -> Any, allow, log it.
Test ping and curl again. If it works, the issue was rule order.

Checking ISP settings

Ask the ISP to confirm:

The static IP and gateway they assigned
Whether VLAN tag or PPPoE is required
Whether anything blocks the management tunnel ports used by the SD-RED heartbeat

A good test is to plug a laptop directly into the ISP modem and set the same static IP and gateway. If the laptop still cannot reach the internet, the fault is on the ISP side.

Steps for reconfiguring settings

Confirm the WAN mode. If the ISP needs VLAN or PPPoE, set the SD-RED WAN for that.
Set the static IP and gateway exactly as provided by the ISP.

Add a default route if it is missing:

ip route add default via <ISP gateway> dev eth0

Set DNS to resolvers from the ISP or public DNS servers.

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

Troubleshooting network connections

Test the physical link: replace the cable and try another switch port.
Test a direct connection: put a laptop on the WAN port with the static IP.
Capture packets on the WAN side:
```
tcpdump -i eth0 host <ISP gateway>
```
Look for ARP requests and replies.

Expected: ARP replies from the gateway MAC.

Failure: unanswered ARP requests, which means there is no layer 2 reachability.

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

If NAT is missing:

Add SNAT for LAN -> WAN IP.
Check outbound connections from a laptop with a site such as ifconfig.me. The external IP should match the assigned static IP.

Verifying device firmware updates

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

Note the current version.
Read the release notes for known fixes.
Set a maintenance window.
Update and retest connectivity.

If support suspects firmware, capture logs and version info before updating so you can roll back if needed.

Confirming internet access

From a LAN host and from the SD-RED:

```
ping 8.8.8.8
```
Expected: less than 5% packet loss and sub-100 ms latency
```
curl -I https://example.com
```
Expected: 200 or 301 headers
Traceroute to a public IP.

Expected: the first hop is the ISP gateway

Also check NAT:

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

Monitoring connectivity stability

Watch the logs for a while after the fix:

```
tail -f /var/log/messages
```
Or use the 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

That gives you an immediate warning if it starts failing again.

Documenting changes made

Write a tight change log:

Date, change made, who approved it, exact commands, before and after outputs, rollback steps

Keep the exact errors you saw and the final verification outputs. It makes the next round of troubleshooting much less annoying.

Root cause and remediation

If the gateway is unreachable and ARP fails, the root cause is layer 2 or ISP configuration. Fix the VLAN or PPPoE setup, or get the ISP to route the static IP.
If the default route is missing, the root cause is the gateway config. Set the correct default route.
If firewall rules block traffic, the root cause is rule order or missing NAT. Add an explicit allow rule and configure SNAT.

I keep changes minimal and reversible. Change one thing at a time and capture the before and after output. That stops the guessing.