Firewall Conflict Resolver

The Firewall Conflict Resolver is a layer on top of the Settings → Security → Firewall Rules tab that classifies every active firewall rule by provider, detects when QuickBox-managed rules are fighting third-party rules, and offers a guided resolution for each conflict — either a one-click action chain that uses the provider’s official CLI to stand the conflict down, or a one-click dismissal for advisory items that don’t need any change.

It exists to solve a class of problem that, until now, looked like a generic “VPN doesn’t work” symptom — but actually traced back to two firewall rule sets quietly cancelling each other out at the kernel level.

What it does

Why it matters

Modern Linux servers can end up running several firewall managers at once. QuickBox Pro manages its own chains, the Geo-Block system writes its own rules, fail2ban writes ban entries, Docker injects forward rules for containers, and a third-party VPN daemon may install a full kill-switch on top of all of that.

Each system on its own is correct. The trouble starts when two of them disagree about who owns the default route or who is allowed to reject outbound traffic.

A representative example surfaced from a beta tester recently:

• The user was running PIA’s official Linux daemon (piavpn.service).
• The user also had QuickBox-managed WireGuard up, using a PIA-issued peer config, and had used the VPN Control page to route qBittorrent through that WireGuard peer.
• PIA’s daemon installs a kill-switch chain (piavpn.r.100.blockAll) that REJECTs anything the daemon doesn’t recognise.
• That chain silently dropped QuickBox’s WireGuard underlay UDP traffic. The WireGuard peer never came up, the per-app routing namespace never had a working tunnel, and the dashboard simply reported the peer as “Inactive” with no error pointing at PIA.

Two correct systems, one broken outcome. The Firewall Conflict Resolver finds this exact class of conflict, names it in plain English, and offers to take down whichever side the user picks.

What you will see

The detected-conflicts list

When the resolver finds one or more conflicts, a Detected firewall conflicts list appears directly above the firewall rules viewer. Each row shows:

• A severity badge (Critical, Warning, or Info) with a matching icon.
• A one-line summary of what the conflict is.
• A small label for the conflict type (for example, “QuickBox WireGuard underlay blocked” or “Catch-all REJECT in third-party OUTPUT chain”).
• The number of firewall rules involved, and up to a few interface chips with a “+N more” overflow when many interfaces are touched.
• A right-side action — Open resolver for chains you can apply, or Open advisory for informational rows that only need acknowledgement.

Rows are sorted by severity (critical → warning → info) with a stable secondary sort, so the list does not shuffle when the page refreshes in the background. Clicking any row opens its resolution modal directly. If the resolver finds no conflicts, the list section is hidden entirely and the firewall rules viewer reads the same as before — just with the new origin labels.

The resolution modal

The modal explains, in user-facing language, what the two sides of the conflict are and which one is winning. It then presents one or more resolution chains — each chain represents a coherent, dependency-aware change. You pick a chain.

Picking a chain does not apply it. Apply is gated behind a dry-run preview.

A typical chain might combine:

• Stopping a third-party daemon (e.g. piavpn.service).
• Removing the chain that daemon installed.
• Removing the policy routes the daemon added.
• Removing the DNS push the daemon set.

You accept or decline each chain as a single unit. Each chain card lists its individual action steps before you preview, so you can read exactly what will run.

Standalone advisory conflicts

Some conflicts are informational — a third-party provider has installed a catch-all OUTPUT REJECT, but nothing QuickBox manages is currently colliding with it. These rows appear with an Info severity badge plus an outline Advisory pill, and the right-side action reads Open advisory instead of Open resolver.

Opening an advisory shows the same modal, but with two options:

1. A recommended action chain that disables the third-party provider. Where the provider ships an official CLI — piactl for PIA, nordvpn for NordVPN, mullvad for Mullvad, protonvpn-cli for Proton VPN, tailscale for Tailscale, ivpn for IVPN — the chain bundles the appropriate “disconnect / kill-switch off / stop service” steps in order, then stops the systemd unit so the provider can’t immediately reinstall its chain. For OpenVPN and other providers without a CLI surface, the chain falls back to stopping the service unit only. The chain runs through the same dry-run gate as any other resolution.
2. Acknowledge — leave foreign rules alone. Keep the third-party rule in place and dismiss the advisory.

Clicking Dismiss advisory on the modal hides the row from the conflicts list and persists the dismissal in your browser, so it stays hidden across page reloads. If the underlying conflict shape changes (the provider is reconfigured, the rule signature changes), the dismissal expires automatically and a fresh advisory will surface.

The dry-run requirement

The preview reports:

• Each individual action that would run (service stops, chain flushes, rule deletions, route removals).
• Any lockout warning — for example, “this change would remove the OUTPUT rule that lets your current IP reach the dashboard.”
• Any dependency warning — for example, “this change would also affect a different app’s routing namespace.”

If the preview surfaces a lockout warning, you have an inline opportunity to add your current IP to the dashboard whitelist before the change applies.

A successful preview returns a one-time apply token with roughly a 10-minute TTL. Apply must complete before the token expires; if you pause past it, the token is rejected and you re-run Preview to mint a fresh one. The chain card shows a countdown so you know how long is left.

Snapshot and restore

Every successful apply takes a snapshot of the full firewall state before the change runs, using iptables-save. Snapshots are kept on the server and managed automatically — no install-time setup required.

• Snapshots are written to /opt/v4-dashboard/var/firewall-snapshots/. The dashboard service user owns the parent path.
• The most recent 10 snapshots are retained. When the eleventh apply happens, the oldest snapshot is dropped.
• A Restore Previous Rules panel lists them with a timestamp and a one-line summary of what change they preceded.
• Restore is gated by the same dry-run flow as a resolution chain: click Preview on the row, review the diff, then Restore within the apply-token TTL.
• Restoring a snapshot replays the saved rules into the kernel. It is reversible — restoring also takes a fresh snapshot first.

This is the recovery path for the “I picked the wrong chain” or “the daemon re-asserted its rules” cases. You do not need shell access to recover.

The current-IP whitelist offer

If a resolution chain would close off the route between your browser and the dashboard, the dry-run preview surfaces an inline toggle:

Add my current IP to the dashboard whitelist before applying.

This mirrors the existing self-protection pattern on the Geo-Lock and Geo-Block tabs, where the system warns you before you block your own country.

Limitations

The resolver is designed for the apply-and-confirm path. There are a few behaviours worth knowing about up front.

Third-party daemons can re-assert their rules

Some VPN providers and firewall daemons re-install their chains every time their service starts or restarts. The most prominent example today is the official PIA Linux daemon — running systemctl restart piavpn will re-create the piavpn.r.100.blockAll chain even if you removed it five seconds earlier through the resolver.

If this happens, the recovery path is Restore Previous Rules. There is no automated re-application of a resolution in the current release; you decide whether to live with the daemon’s chain or stop the daemon. The actionable advisory chain (which calls the provider’s CLI to disable its kill-switch and then stops the service unit) is the cleanest way to keep the daemon from reinstalling its chains.

Apply tokens expire

The one-time apply token returned by Preview is valid for roughly 10 minutes. If you wander away from the modal and come back later, click Preview again to mint a fresh token before clicking Apply.

Dismissals are browser-local

Dismissing an advisory hides it for the current browser only. Other admins (or the same admin in a different browser) will still see the row. If you want a server-side acknowledgement, the resolver does not currently provide one — surface to the QuickBox community if your team needs it.

Read carefully before applying

The resolver’s job is to bundle dependent artifacts into one chain. It is not a magic “fix everything” button. Read the chain summary in the modal before you apply — especially if the chain proposes stopping a third-party service. Stopping a daemon may have effects beyond the firewall (routing, DNS, app traffic) that the resolver names in the preview but cannot decide for you.

Supported providers

The resolver classifies and resolves conflicts for the following providers. Each is detected from a combination of chain naming, interface naming, comment markers, and (where relevant) the presence of a corresponding service unit, process, or active interface.

The QuickBox built-in classifications were already in place before the resolver shipped — they continue to surface with their existing role labels, just with the new severity field added and the unified per-provider chip row above the rules viewer.

Conflict types detected

The resolver classifies conflicts into six categories. Each one has a specific detection trigger and its own resolution chain template.

When to use the resolver

Best practices

FAQ

Related pages