Firewall Troubleshooting

Most firewall issues fall into one of four categories: a legitimate request is being blocked (false positive), Extended Protection has stopped loading, a configuration change has not taken effect, or the firewall is not blocking attacks that you can clearly see in your logs. This article walks through each.

In This Article

• False positives
• Extended Protection broken
• Configuration changes not taking effect
• Firewall not blocking attacks
• Last resort: reverting and reinstalling

False positives

A false positive is a legitimate request that the firewall has blocked. The most common source is custom code that sends data shaped like an attack — for example, an admin page that posts SQL fragments to a custom plugin, or a builder that posts JavaScript snippets to a content editor.

To handle a false positive:

1. Open VMP Security → Tools → Live Traffic.
2. Find the blocked request. Live Traffic shows blocks in red with the rule that matched.
3. Click the request to expand it. Confirm that the request is something you actually wanted to allow (do not allowlist requests you cannot identify).
4. Click Add to allowlist. The dialog lets you scope the allowlist entry to the specific URL and parameter that triggered, rather than waiving the rule everywhere.

If false positives are frequent enough that you find yourself allowlisting them on every visit, work through them in batches from Tools → Live Traffic instead of one at a time — you can keep the page open and add allowlist entries as the blocks come in.

Visitor sees a 403 page when they shouldn’t

VMP Security’s 403 page identifies itself by name and gives a reason for the block. If a visitor is seeing a generic Apache or NGINX 403 instead, the block is coming from somewhere else in your stack — usually mod_security on the host, a CDN WAF, or an .htaccess rule. Check your server error log and any other security layer before assuming it is the firewall.

Extended Protection broken

Extended Protection requires the loader file (vmp-waf.php) at the WordPress root and a matching auto_prepend_file directive in .htaccess. If either piece is missing or out of sync, you will see one of:

• A PHP fatal error: Failed opening required '/path/to/vmp-waf.php'.
• The protection level silently dropping back to Basic.
• A warning at the top of the WordPress admin saying the firewall configuration needs repair.

The most common cause is that the site has been migrated to a new server (or a new path on the same server) without reverting Extended Protection first. The old prepend directive points at a file path that no longer exists, and PHP errors out trying to load it.

To fix:

1. If WordPress still loads, open Firewall → Firewall Options and click REMOVE EXTENDED PROTECTION, then re-run OPTIMIZE THE VMP FIREWALL. This regenerates both the loader and the .htaccess directive at the current path.
2. If you cannot reach WordPress because of the PHP fatal error, edit .htaccess over SFTP and remove the auto_prepend_file line that mentions vmp-waf.php. WordPress will load again, you can sign in, and you can re-run the optimizer from a working state.
3. If .htaccess looks fine but the loader file is missing, restore it from the wp-content/vmpfence-backups/ folder if you kept a backup, or simply remove the auto_prepend_file line and re-run the optimizer.

Configuration changes not taking effect

If you change a firewall option, save it, but the new behavior does not appear, the cause is almost always caching. Three layers are worth checking, in order:

• OPcache. If your host has OPcache without file-change validation, PHP will keep using the previous version of the firewall’s config files. Restart PHP-FPM or wait for the OPcache TTL to expire.
• Object cache. WordPress object caches can hold stale option values. Flush the object cache if you have one (Redis, Memcached, or a plugin’s built-in flush button).
• Page cache. If you are testing whether visitor traffic gets blocked, check that the page cache is not serving the cached pre-block response. Bypass the cache or load the page in an incognito window.

None of these affect the firewall itself; they just hide the change from your test traffic.

Firewall not blocking attacks

Sometimes log analysis turns up an attack that clearly should have been blocked, but was not. A few things to check:

• Status. Is the Web Application Firewall Status set to Disabled? Disabled firewalls do not block. Open Firewall → Firewall Options and confirm the status is set to Enabled and Protecting.
• WAF rules. Is the relevant rule still enabled on the Firewall → WAF Rules page? Individual rules can be disabled there; if the rule that should have caught the attack is off, it will not fire.
• Allowlist. Is there an allowlist entry on Firewall Options that matches the attack pattern? An overly broad entry can wave through requests that should be blocked. Look for entries whose URL or parameter matches the attacked endpoint.
• Visitor IP. If the firewall thinks every request comes from a CDN or proxy IP, per-IP defenses (rate limits, country blocking, IP blocklist) cannot work correctly. Verify the visitor-IP setting on the All Options page.

Last resort: reverting and reinstalling

If none of the above resolves the problem and you suspect a corrupted firewall installation, you can reset:

1. Revert Extended Protection (from the Firewall Options page, or manually if needed).
2. Deactivate the VMP Security plugin.
3. Delete the plugin from the WordPress plugins page.
4. Reinstall the latest version from the WordPress plugin directory.
5. Re-run the optimization wizard.

This preserves your VMP Security license and your option settings (which are stored in the WordPress database, not in the plugin files), so you do not have to reconfigure from scratch. If you want a true clean slate, see the Remove or Reset article.