Firewall troubleshooting

Start with the symptom closest to yours. Most answers come down to one of three things: the firewall's connection to ReadyView, a setting on the firewall itself, or a gap the feature can't cover by design.

#Connection and setup

#The firewall shows offline

ReadyView marks a firewall offline when it stops hearing from it. The firewall may still be passing traffic normally. Check, in order:

1. Internet on the firewall. Its WAN must be up and able to resolve DNS. On the firewall, Interfaces > Overview shows the WAN address and gateway.
2. The agent's status. On the firewall, open Services > ReadyView > Settings. The ReadyView connection table at the top shows Status (Connected, Not connected with the last error, or Not running), the Device ID (MAC), the broker, and the last publish. Not running means Enable is off.
3. Outbound access. An upstream firewall or ISP filter must allow TCP 8883 to mqtt.readylinks.io, plus DNS and NTP. See Firewall rules for cloud connectivity.
4. The clock. The connection uses TLS, which fails if the clock is far off. Check System > Settings > General and make sure NTP can reach its servers.
5. The agent log. Services > ReadyView > Log File on the firewall shows connection attempts and errors.

#The firewall appeared as a new device

The firewall is identified by the MAC address of its Identity interface (LAN by default). If someone changed Identity interface under Services > ReadyView > Settings, or the identity port's hardware was replaced, ReadyView sees a new device. Set Identity interface back, or claim the new ID and remove the old entry.

#A section is read-only

The section's note says which of these is missing:

• the area's Allow … changes from ReadyView setting on the firewall;
• ReadyView's command key in ReadyView command key on the firewall;
• permission to update firewalls in your ReadyView role;
• a new enough ReadyView agent on the firewall.

See How changes work. After you change a setting on the firewall, refresh the ReadyView page.

A section also stays read-only for a moment after it opens, while ReadyView shows the last copy it saw and waits for the firewall's current settings. Editing opens when the firewall answers.

#Some rules or objects can't be edited

That's by design. Automatically generated rules, rules made on the firewall's older pages, gateways, WAN interfaces, outbound NAT, and objects another ReadyView feature manages (for example the region filter's rules) can't be edited in the section you're looking at. Open the row's Details to see who set it. A rule a ReadyView feature keeps says "Managed by …, so it can only be changed there." with a link to open that feature. See What ReadyView never changes.

#A section is missing

Some sections need a newer ReadyView agent on the firewall. ReadyView hides a section, or says which version it needs, when the firewall's agent is older. Check the firewall's versions under Settings > Firmware and restarts. See Firmware, backups, and HA.

#Changes

#My change was put back

The firewall undoes a change when it can't reach ReadyView afterwards (automatic undo). The change itself was the cause in almost every case:

• a block rule above the rules that let the firewall's own traffic out;
• a region filter or blocklist that includes the cloud's addresses;
• an uplink, VLAN, or interface change that moves or drops the path to the internet;
• a speed limit too low for the management link.

Look at what the change would do to the firewall's own outbound traffic, adjust it, and save again.

#"The firewall didn't answer in time"

The firewall was slow to confirm. The change may still have been applied, so ReadyView reads the section again. Check what it shows before saving again. Large changes, such as threat protection rule sets, can take several minutes. ReadyView keeps re-reading those until they finish.

#Someone changed the firewall and I can't tell who

Check your organization's Logs. Every change made through ReadyView is there with the user and time. For rule changes, Activity > History on the firewall's page also lists each field that changed.

Changes made in the firewall's own web interface aren't in either. Use configuration backups to see who saved each version and compare versions.

#Monitoring

#WAN loss and latency are blank or "Not monitored"

The firewall only measures loss and latency for a gateway with monitoring on, and gateway monitoring is off by default. Turn it on for each uplink in Network > Uplinks. Until then:

• the gateway's rows and charts show Not monitored;
• gateway loss and latency alerts can't fire;
• the report's gateway outages stay at zero.

Past minutes aren't filled in after you turn monitoring on.

#WAN connectivity bars have small gaps

A thin grey gap means ReadyView has no statistics for that minute. The firewall sends one summary per minute, and a minute can be lost if the firewall was busy or its connection to ReadyView dropped. Isolated one-minute gaps aren't an outage. A long red stretch is.

#The speed test says Cloudflare is limiting tests

The speed test downloads from Cloudflare's speed test service, which limits large downloads per public address for about an hour after a burst of tests. Every device behind the same public address shares that limit, including people running browser speed tests. Wait the time ReadyView shows, or measure upload only.

#Uplinks and failover

#Failover didn't move traffic

Check these, in order:

1. Do both uplinks use the same upstream router? If both WAN ports get addresses from the same modem or router, with the same gateway address, the firewall can't route them separately and can't fail over between them. Give each uplink its own upstream device and gateway.
2. Was the right cable pulled? A test that unplugs a LAN port instead of a WAN port shows clients losing access while the WAN stays healthy.
3. Was the outage long enough? With the default thresholds, an uplink is marked down after about 15–20 seconds of lost probes. Shorter blips don't fail over. Unplugging the cable is detected faster, because the link goes down at once.
4. Are open connections pinned? Without the options to reset and move connections when an uplink fails, connections that were already open (a running ping, a video call) keep trying the failed uplink until they time out. New connections use the working uplink.

#Traffic moved to the other uplink when nothing failed

Saving Uplinks with a different main uplink moves traffic at once. That's a save, not a failover. Check your organization's Logs for an uplinks change at that time.

#Both uplinks went down together

Each uplink's monitor address must leave through that uplink. If an uplink's internet provider hands out the other uplink's monitor address (such as 8.8.8.8) as its DNS server, both monitors can end up measuring the same path. Use monitor addresses no provider hands out as DNS, such as 1.0.0.1 and 8.8.4.4, and avoid 1.1.1.1, 8.8.8.8, and 9.9.9.9. The firewall uses those three for its own internet checks.

#Security features

#The DNS filter isn't blocking a site

• Device uses another DNS server. Only devices that use the firewall for DNS are filtered, unless Stop devices from getting around the filter is on. That guard answers DNS sent to other servers itself and blocks the well-known DNS over HTTPS and DNS over TLS services. It needs plugin 1.14.
• Browser DNS over HTTPS. Firefox, Chrome, and others can send DNS over HTTPS to their own provider. The guard blocks the public services and tells Firefox to turn its DNS over HTTPS off, but a service the firewall doesn't know, or a VPN, still gets around it. Block the VPNs, proxies and DNS over HTTPS category to cover more.
• Cached answers. A device that looked up the site before it was blocked can keep using the cached address until it expires. Wait a few minutes, or clear the device's DNS cache.

#The region filter blocks nothing

The region filter needs a GeoIP database on the firewall to know which country an address belongs to. Without one, ReadyView says "This firewall has no GeoIP database yet… the region filter blocks nothing" and shows the steps to add one. In the firewall's web interface, open Firewall > Aliases > GeoIP settings, paste your GeoIP provider's download link into URL, and click Apply. ReadyView then shows how many networks the database holds.

Traffic through a VPN or proxy counts as the VPN or proxy's country.

#Threat protection lowered throughput

Alert and block inspects every packet on the interfaces it watches and can lower throughput. Watch fewer interfaces (usually WAN only), choose a lower How much to block level, or switch to Alert only. See Threat protection.

#Still stuck?

Collect these before contacting support:

• the firewall's name or Device ID (MAC) and site;
• the time the problem happened, with time zone;
• any message ReadyView showed, word for word;
• for connection problems, the Status line from Services > ReadyView > Settings and the last lines of Services > ReadyView > Log File.

Then see Contact support.