Kill the VPN: A Pragmatic Guide to Zero-Trust Architecture in Norway (2023 Edition)

The Castle is Burning: Why Perimeter Defense Failed Us

I still remember the audit meeting in Oslo last winter. A mid-sized fintech client was boasting about their "impenetrable" firewall rules and their expensive corporate VPN. They had a hard perimeter. Inside? It was a free-for-all. Once a developer's laptop was compromised via a phishing email, the attacker had unrestricted access to the database, the CI/CD pipeline, and the backups. The "trusted" network was the vulnerability.

By September 2023, the concept of a "trusted network" should be considered professional negligence. Whether you are hosting in a massive datacenter or running a lean setup on a VPS in Norway, the assumption must be: the network is hostile.

Zero-Trust isn't a product you buy from a vendor; it's a blood-pact you sign with your infrastructure. It means verifying explicitly, using least privilege access, and assuming breach. Let's build this stack from the ground up, moving away from clunky VPN concentrators to identity-aware proxies and mutual TLS (mTLS), all while keeping Datatilsynet happy.

Phase 1: Identity is the New Firewall

In a Zero-Trust model, IP addresses are meaningless. Identities are everything. If you are still whitelisting IPs in /etc/hosts.allow or AWS Security Groups for user access, stop. We need to shift to Short-Lived SSH Certificates.

Static SSH keys are a nightmare. They don't expire, they get copied to Dropbox, and revoking them is a manual chore. Instead, we use a Certificate Authority (CA) to sign ephemeral keys.

Here is how you configure your CoolVDS instance to trust a CA for SSH access. This ensures that even if a developer's laptop is stolen, the key they have is useless after its TTL (Time To Live) expires.

Server Configuration (The Host)

# /etc/ssh/sshd_config
# Trust the CA public key
TrustedUserCAKeys /etc/ssh/user_ca.pub

# Revoked keys list (for emergencies)
RevokedKeys /etc/ssh/revoked_keys

# strict modes
AuthenticationMethods publickey
PermitRootLogin prohibit-password

On the client side, the developer authenticates against your Identity Provider (IdP)—think Keycloak or Dex running on a separate isolated instance—and receives a signed certificate valid for 8 hours.

# Signing a user key (via your internal CA script)
ssh-keygen -s user_ca -I user_id -n root,devops -V +8h id_rsa.pub

Pro Tip: Never run your IdP on the same failure domain as your production workload. I recommend deploying a dedicated, minimal KVM instance on CoolVDS solely for Keycloak. The isolation of KVM prevents neighbor-based side-channel attacks that can plague container-based hosting.

Phase 2: encryption in Transit (mTLS & WireGuard)

GDPR and Schrems II rulings have made one thing clear: you cannot trust US-controlled network hops with cleartext data. Encryption in transit is mandatory. But HTTPS isn't enough for service-to-service communication. You need Mutual TLS, where the client verifies the server, and the server verifies the client.

Nginx mTLS Configuration

If you are running a microservices architecture, putting Nginx as a sidecar or a gateway is standard. Here is the config to enforce client certificate verification. This blocks 99% of automated scanners because they can't complete the handshake.

server {
    listen 443 ssl http2;
    server_name internal-api.coolvds.local;

    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    # Verify the Client
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;

    location / {
        proxy_pass http://localhost:8080;
    }
}

The WireGuard Mesh

For connecting servers across different zones (e.g., your Oslo production node to your backup server in Trondheim), IPsec is too bloated. WireGuard is the 2023 standard: lean, kernel-space, and audit-friendly.

Unlike OpenVPN, which context-switches like crazy, WireGuard lives in the kernel. This is where the underlying virtualization technology matters. On cheap OpenVZ containers, you often can't load WireGuard modules. On CoolVDS, you have full kernel control via KVM.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
PublicKey = <Client_Public_Key>
AllowedIPs = 10.0.0.2/32

Phase 3: Micro-Segmentation with nftables

The old iptables is being phased out in favor of nftables in most modern distros (Debian 11/12, RHEL 9). nftables allows for atomic rule updates and better performance.

We don't just want to block ports; we want to bind specific interfaces. Your database should listen ONLY on the WireGuard interface, not the public WAN.

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Accept localhost
        iifname "lo" accept

        # Accept established/related
        ct state established,related accept

        # Accept SSH only from WireGuard interface (VPN)
        iifname "wg0" tcp dport 22 accept

        # Drop everything else on eth0 except HTTP/S for public web
        iifname "eth0" tcp dport { 80, 443 } accept
    }
}

This configuration ensures that even if someone finds a zero-day in OpenSSH, they can't exploit it unless they are already inside your WireGuard mesh. Layers matter.

The Compliance Angle: Norway & Data Sovereignty

Implementing Zero-Trust is also a legal shield. Under GDPR, you must demonstrate "state of the art" security measures. If you suffer a breach, the difference between a slap on the wrist and a massive fine from Datatilsynet often comes down to: "Did you take reasonable precautions?"

Using US-based cloud providers adds complexity regarding data transfer mechanisms. Hosting on Norwegian soil, with a Norwegian provider like CoolVDS, simplifies the jurisdiction significantly. But sovereignty requires control. You cannot have control if you are using a managed "Black Box" database service where you can't tune the SSL cipher suites.

Comparison: Managed vs. Self-Hosted Zero-Trust

Conclusion: Trust Nothing, Verify Everything

The days of the perimeter firewall are over. In 2023, security happens at the interface level, the identity level, and the application level. By combining SSH certificates, WireGuard meshing, and strict nftables policies, you create an environment where lateral movement is nearly impossible.

However, this architecture requires raw compute power and the freedom to modify the OS kernel—capabilities often stripped away in shared hosting environments. This is why I deploy my security stack on KVM-based VPS instances.

Don't wait for a ransomware attack to expose your flat network topology. Audit your access controls today.

Ready to harden your infrastructure? Spin up a CoolVDS NVMe instance in Oslo today—full root access, KVM isolation, and zero noisy neighbors. Secure your data where it belongs.