How do I block all traffic if NordLayer disconnects, even for admins?

A recurring theme in high-compliance SaaS environments, particularly those handling PII or financial data, is the requirement for a "network kill switch" that functions at the host level, independent of user privileges. The NordLayer client's built-in kill switch is designed to block traffic if the VPN tunnel fails, but its scope and persistence, especially against a determined local administrator, can be insufficient for audit scenarios. The core question becomes: how can we enforce a system-wide, non-bypassable network block triggered by a NordLayer disconnection?

The objective is to create a failsafe where any interruption in the NordLayer secure tunnel—whether due to daemon crash, manual disconnect, or network instability—results in the host being completely isolated from all networks (LAN and WAN), even if a user with administrative rights attempts to override it. This moves the control from the user-space application layer to a lower system or network layer.

A multi-layered approach is necessary, as no single method is entirely foolproof against a local admin with physical access, but we can achieve a very high degree of enforcement. Here are the recommended strata, from most to least effective:

* **1. Integration with Host-based Firewall (Imperative Rules):**
The most robust method is to configure the native firewall to only permit traffic through the NordLayer tunnel interface. On disconnect, the interface becomes inactive, and all rules referencing it become inert, blocking all traffic. Crucially, these rules must be deployed via MDM (Intune, Jamf, etc.) or GPO with permissions that prevent local users from modifying or disabling the firewall. Example for Windows Defender Firewall via PowerShell, deployed as a startup script:

```powershell
# Allow traffic only on the NordLayer tunnel interface (adjust 'Ethernet 2' to your NordLayer interface name)
New-NetFirewallRule -DisplayName "NordLayer Only - DNS" -Direction Outbound -Protocol UDP -LocalPort Any -RemotePort 53 -InterfaceAlias "Ethernet 2" -Action Allow
New-NetFirewallRule -DisplayName "NordLayer Only - HTTP/S" -Direction Outbound -Protocol TCP -LocalPort Any -RemotePort 80,443 -InterfaceAlias "Ethernet 2" -Action Allow
# Block all other outbound traffic on any interface
New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Protocol Any -Action Block -InterfaceAlias Any
```

* **2. Persistent Script Monitoring with Privileged Actions:**
A background service or daemon, also deployed via MDM, should monitor the NordLayer tunnel state. On disconnect, it executes a privileged command that a standard admin cannot easily reverse without knowing the script's remediation logic. For example:

* Flush all routing tables and set a deny-all route.
* Disable all network adapters except the loopback.
* Implement a secondary, statically-configured (and incorrect) DNS server list.

```bash
# Linux example snippet (to run as a systemd service)
while true; do
if ! ip route show dev nordlayer0 > /dev/null 2>&1; then
ip route flush all # Flush all routes
ip route add default via 127.0.0.1 dev lo metric 1000 # Create a non-functional default route
systemctl stop networking # Stop networking service
fi
sleep 5
done
```

* **3. Hardware/Network Enforced Control (Most Secure):**
For the highest assurance, the control must be moved off the host. This involves:
* **802.1X Network Access Control:** Configure the device to only receive a network profile (VLAN) that permits internet access *after* successful machine certificate authentication through the NordLayer tunnel. If the tunnel drops, the device loses its authenticated status and is moved to a quarantine VLAN with no external access.
* **Cloud-based Firewall (e.g., Zscaler, iBoss):** Enforce a policy where the device's public IP (when not via NordLayer) is denied all access except to the NordLayer servers. This requires the device to always connect via NordLayer to reach any other resource.

**Benchmarking Consideration:** In load testing this setup, measure the "breach window"—the time between tunnel failure and full network isolation. The firewall method is near-instantaneous (<1s), while script-based methods may have a 5-10 second latency depending on the polling interval. This metric is critical for your risk assessment.

Ultimately, the solution depends on your threat model. For compliance (e.g., GDPR, HIPAA) where user error is the primary risk, the host firewall method is typically sufficient. For defending against malicious insiders with admin rights, you must integrate with network-level controls (802.1X).

— Isabella G.