[Feature request] an event that fires whenever the Network Lock (re)applies its firewall rules

[jeberlo 2]

Feature request: an event that fires whenever the Network Lock (re)applies its firewall rules

This is a feature request for Eddie — VPN Tunnel (Desktop edition), repo AirVPN/Eddie.

Summary

Add a new Eddie event (visible in Preferences → Events) that fires whenever the Network Lock finishes applying or re-applying its firewall rules — in any scenario, including mid-session recoveries of the elevated service that do not involve a full tunnel reconnection.

The goal is to let users run a custom hook after the Network Lock is settled (for example /etc/ufw/after.init) to restore firewall rules that the Network Lock overwrote, such as outbound NAT for Docker containers.

Environment

• Eddie 2.26.2 (eddie-ui), GNU/Linux (Linux Mint), OpenVPN over tun0.
• Network Lock mode: linux_iptables_legacy (see ~/.config/eddie/Recovery.xml😞

<Recovery>
  <netlock mode="linux_iptables_legacy" />
</Recovery>

Problem

Eddie's Network Lock works by writing strict firewall rules (on Linux it can use nftables / iptables-nft / iptables-legacy). Those rules replace/clean part of the existing chains. If an application (e.g. Docker) or the user has inserted its own NAT/FORWARD rules on top of the Network Lock, a later re-application of the lock silently removes them.

The existing events do not cover every moment the lock is (re)applied:

Event	When it fires (from the source)	Does it run after the lock is settled?
app start / app end	Engine start / shutdown (Engine.cs, RunEventCommand("app.start" / "app.stop"))	No
session start / session end	Beginning of the connect flow / end of session (Engine.SessionStart() → OnSessionStart() → RunEventCommand("session.start"), before the tunnel exists)	No
vpn pre	Just before launching the tunnel (Session.cs, before m_connection.OnStart())	No
vpn up	Tunnel fully established, after NetworkLockManager.OnVpnEstablished() and Provider.OnVpnEstablished(), right before SetConnected(true) (Session.ConnectedStep())	Yes, but only on a normal connect
vpn down	Tunnel down detected (Session.cs, RunEventCommand("vpn.down"))	Not relevant

The gap: the vpn up event only fires during a normal connection flow. When the elevated service (eddie-cli-elevated mode=service) crashes and recovers mid-session — Eddie writes a Recovery.xml and re-applies the Network Lock without a tunnel reconnection — no event fires at all. Any custom rules the user had layered on top of the lock are wiped and are not restored.

Real-world impact

Concrete case observed (Eddie 2.26.2, Linux):

• A host runs Docker containers. Outbound connectivity for containers relies on user firewall rules (/etc/ufw/after.init, chains SETUP-FW-* in iptables/iptables-legacy/nft) applied after the Network Lock is active.
• The vpn up event was configured to re-apply those rules on every normal connect, and that worked.
• After a recovery of the elevated service (a Recovery.xml appeared with a timestamp between the VPN connect and the failure), the containers lost outbound Internet with no event having fired. Only a manual sudo /etc/ufw/after.init start restored connectivity.
• Result: a container running an application that calls an external HTTPS API could not reach that endpoint; HTTP requests hung until the reverse proxy timed out. Zero bytes were returned to the client.

Proposed solution

Add a new built-in event, for example netlock.up (UI label suggestion: "Network Lock applied"), that is executed after the Network Lock has finished (re)applying its rules in ANY of these situations:

1. Normal connect (as vpn up today, after NetworkLockManager.OnVpnEstablished()).
2. Manual toggle of the Network Lock on/off.
3. Settings/allow-list changes that re-apply the lock (NetworkLockManager.OnUpdateIps() and similar).
4. Recovery of the elevated service that re-applies the lock mid-session (Recovery.cs / Recovery.xml), with or without a tunnel reconnection.

It should be exposed through the existing event mechanism so users can configure it in Preferences → Events with event.<name>.filename, event.<name>.arguments, event.<name>.waitend (see ProfileOptions.cs, method EnsureDefaultsEvent).

An acceptable alternative would be to re-fire vpn up after a recovery that re-applies the Network Lock while the session stays connected.

Implementation hints (based on reading the master branch)

• src/Lib.Core/ProfileOptions.cs — EnsureDefaultsEvent(name) already registers the three per-event options; a new event name would only need to be registered there (and exposed in the Events UI).
• src/Lib.Core/Engine.cs — RunEventCommand(name) reads event.<name>.* and runs SystemExec.ExecForUserEvent(filename, arguments, waitEnd).
• Where the rules are actually (re)applied: src/Lib.Core/NetworkLockManager.cs (Activation/Deactivation, OnVpnEstablished, OnUpdateIps) and the Linux platform plugins (src/Lib.Platform.Linux*), plus the elevated-service recovery path. Firing the event right after the rules are written, from a single choke point, would make the event reliable.
• The docs for Network Lock already warn: "if you change firewall rules yourself after activating Network Lock, Eddie will not detect that." A user-hook-friendly event is the natural companion to that behavior.

Thank you very much in advance.