How changes work

ReadyView changes a firewall only in the areas the firewall's administrator has opened to it, only for ReadyView users allowed to change firewalls, and only with changes the firewall can check and undo. This page explains each of those safeguards. When a section is read-only or a save fails, the reason is almost always one of them.

#Three things must line up

A change from ReadyView goes through only when all three of these are true:

1. The firewall allows that area. Every area has its own setting under Services > ReadyView > Settings on the firewall, and they're all off on a new firewall. See Settings on the firewall.
2. The firewall has ReadyView's command key. Every change is signed by ReadyView. The firewall refuses any change it can't verify with the key pasted in ReadyView command key. See Connect a firewall.
3. You may change firewalls. Your ReadyView role must include permission to update firewalls. Roles without it can view every section but not save. See Roles and permissions.

When one is missing, the section still shows the firewall's settings, read-only, with a note saying which one is missing. For a firewall that hasn't been set up yet, the note walks you through it and has a Show command key button with the key to paste.

#Settings on the firewall

Sign in to the firewall's web interface and open Services > ReadyView > Settings. The Changes from ReadyView group has one checkbox per area. Tick only the areas you want managed from ReadyView, then click Save.

#What ReadyView never changes

Even with an area turned on, ReadyView works only on its own objects and on the kinds of settings its forms understand. The rest stays read-only in ReadyView:

• Automatically generated rules (anti-lockout, the rules a feature adds for itself, and so on) are shown but can't be edited.
• Rules made on the firewall's older pages are shown but can only be changed on the firewall itself.
• Physical interfaces and interfaces with a gateway (your WANs) can't be changed by network changes. VLANs and their DHCP can.
• Gateways are read-only. Routes can use them but not change them.
• Outbound, one-to-one, and NPTv6 NAT are read-only. Only port forwards can be edited.
• Objects ReadyView makes for a feature are named after it, such as ReadyView DNS filter, ReadyView_site_VPN, RV_uplinks, or rules described ReadyView uplinks. Objects you made yourself with the same purpose stay as they are.
• Advanced settings that a ReadyView form can't represent are shown read-only with a note saying why. ReadyView never quietly rewrites them.

#Saving a change

How you save depends on the section:

• Firewall rules, Port forwards and NAT, and Aliases apply each action at once. Adding, editing, enabling, disabling, moving, or deleting a rule goes to the firewall when you click that action's button.
• Every other section edits a draft. Nothing reaches the firewall until you click the section's Save button (Turn on the first time, or Save changes in Dynamic routing). Discard throws the draft away.

Either way, when a change is sent:

1. ReadyView signs the change and sends it to the firewall.
2. The firewall checks it exactly as it would check the same change made in its own web interface. If anything is invalid, it rejects the whole change, and ReadyView shows the firewall's reason.
3. The firewall applies the change and reloads only what the change touches.
4. The firewall confirms that it can still reach ReadyView, then reports back. ReadyView re-reads the section so you see the result from the firewall.

While this happens ReadyView shows Applying…. Because the firewall keeps a change only after checking it can still reach ReadyView, this can take up to a minute. Threat protection changes that download new rule sets can take several minutes; ReadyView shows them as in progress and re-reads the section until they finish.

#What the result means

#Automatic undo

If a change cuts the firewall off from ReadyView, the firewall undoes it. After applying a change, the firewall waits for its connection to ReadyView. If the connection doesn't come back within about 45 seconds, it puts the previous settings back.

This covers the mistakes that would otherwise need someone on site, such as a rule that blocks the firewall's own traffic, an uplink change that drops the internet, or a speed limit too low for the management link. When it happens, the save fails in ReadyView and the firewall keeps its previous settings.

The undo protects the moment of the change. A setting that only causes trouble later, for example a region filter that blocks a country your internet provider later routes through, isn't undone by itself.

#Change history

Every change made from ReadyView is recorded with who made it, when, the firewall it went to, and how it ended. You can find it in two places:

• Your organization's Logs list every firewall change made from ReadyView, along with every other ReadyView change.
• Activity > History on the firewall's page lists that firewall's rule changes, with each field that changed. See History.

Changes made in the firewall's own web interface aren't in either. To track those:

• configuration backups record each new configuration version, with who saved it and what changed;
• the Changes outside ReadyView alert tells you when someone saves on the firewall itself;
• the security report counts changes from ReadyView, outside ReadyView, and put back by the firewall.