AI Assist VPNs with a static internal address

[n8chavez]

Do you know of any VPNs that feature static internal addresses that users receive after Wireguard key handshake. Usually that address changes every time users get a new key which could be several times a day. That might sound odd, but I do know there are a couple that offer it. AirVPN offers a static 10.x.x.x address that users can find in their member page, and ProtonVPN offers 10.2.0.2. This is important because having this static address will allow me to create firewall rules allowing only to and from that address, creating another de-facto killswitch. Are there any other, other than those two?

 

[Bot]

Do you know of any VPNs that feature static internal addresses that users receive after Wireguard key handshake. Usually that address changes every time users get a new key which could be several times a day. That might sound odd, but I do know there are a couple that offer it. AirVPN offers a static 10.x.x.x address that users can find in their member page, and ProtonVPN offers 10.2.0.2. This is important because having this static address will allow me to create firewall rules allowing only to and from that address, creating another de-facto killswitch. Are there any other, other than those two?

In WireGuard, the tunnel “Address” should not change just because of the handshake. What normally changes it is generating a new WireGuard keypair / downloading a new config (some apps can do this automatically). Session keys rotate silently, but your WireGuard public key can stay the same for months, and the tunnel IP will usually stay the same for that key.

How most VPNs handle “static” WireGuard internal IPs

Most providers that support WireGuard assign the internal tunnel IP to a specific WireGuard public key (“device”). In that model:

• The internal 10.x/172.x address is stable as long as you keep using the same WireGuard key/config.
• If you rotate/regenerate the WireGuard key, the provider typically assigns a different internal IP (by design).

So if you’re seeing changes “several times a day,” it’s very likely your client is rotating/regenerating WireGuard keys/configs that often (not something WireGuard itself requires).

Providers I know that commonly provide a fixed tunnel IP per WireGuard key

Beyond AirVPN and ProtonVPN, these are widely known to assign a consistent internal tunnel IP tied to the WireGuard public key (i.e., stable unless you create a new key):

• Mullvad (internal tunnel IP is tied to the WireGuard key; if you keep the same key, it stays the same)
• IVPN (same general model: per-WireGuard-key tunnel IP, stable until the key is replaced)

I’m not confident naming additional providers beyond that without double-checking their current WireGuard provisioning behavior, because this varies and providers change implementations.

A more robust “de-facto kill switch” than depending on the tunnel IP

Relying on the internal tunnel IP can work, but an interface-based kill switch is usually more reliable and doesn’t break if the provider changes addressing:

• Allow outbound traffic only via the WireGuard interface (wg0 / “WireGuard Tunnel” interface)
• Allow only the VPN handshake traffic outside the tunnel (UDP to the VPN endpoint IPort)
• Block everything else outbound on non-VPN interfaces

That approach remains effective even if the tunnel IP changes, and it’s generally the standard way to build a hard kill switch with WireGuard.

Conclusion: if your main goal is firewall enforcement, you’ll usually get the best long-term result by binding rules to the WireGuard interface (plus endpoint exceptions), and if you specifically want a stable tunnel IP, providers that tie it to a persistent WireGuard key (like Mullvad/IVPN) are typically the next place to look after AirVPN/Proton.

 

[n8chavez]

Great post. I was under the impression that the internal address for Mullvad was not static, thus eliminating the ability for firewall rules. I'll try Mullvad again to verify. How would I create the rules you suggested with Windows' firewall? To my knowledge it does not allow for adapter rules, and t has to be windows' because third party ones suck.

 

[Bot]

Great post. I was under the impression that the internal address for Mullvad was not static, thus eliminating the ability for firewall rules. I'll try Mullvad again to verify. How would I create the rules you suggested with Windows' firewall? To my knowledge it does not allow for adapter rules, and t has to be windows' because third party ones suck.

Windows Defender Firewall (WFAS) can do this, but the “per-adapter” control is limited in the GUI. The most reliable way is to use PowerShell, because it supports targeting a specific interface by alias (adapter name). This lets you build a true WireGuard kill switch without depending on a static 10.x tunnel IP.

Important notes before you start

• Do this from local/physical access (not over RDP), because you can lock yourself out.
• Export your current firewall policy first so you can roll back quickly.
• This approach assumes you know the WireGuard server IP/port you connect to (so the tunnel can come up even while everything else is blocked).

1) Backup current firewall rules

Open PowerShell as Administrator:

netsh advfirewall export "$env:USERPROFILE\Desktop\wf-backup.wfw"

(If you need to restore later: `netsh advfirewall import "path\wf-backup.wfw"`.)

2) Identify your interface aliases (names)

Run:

Get-NetAdapter | Sort-Object -Property Status,Name | Format-Table -Auto Name,InterfaceDescription,Status

You’re looking for:

• Your WireGuard tunnel adapter alias (often something like “WireGuard Tunnel”, “Mullvad”, “wg-mullvad”, etc.)
• Your non-VPN interfaces (usually “Wi-Fi” and/or “Ethernet”)

For the examples below, I’ll assume:

• WireGuard tunnel alias: WireGuard Tunnel
• Non-VPN aliases: Wi-Fi and Ethernet

Replace those with what you actually have.

3) Create “allow all outbound via WireGuard interface”

This allows normal traffic only if it’s going out through the WireGuard adapter:

New-NetFirewallRule -DisplayName "WG - Allow outbound on WireGuard interface" `
  -Direction Outbound -Action Allow -Enabled True -Profile Any `
  -InterfaceAlias "WireGuard Tunnel"

4) Block outbound traffic on non-VPN interfaces (the kill switch)

Because Windows Firewall doesn’t easily do “block everything except this interface”, you typically create explicit block rules on the interfaces you want to prevent leaks on:

New-NetFirewallRule -DisplayName "WG KillSwitch - Block outbound on Wi-Fi" `
  -Direction Outbound -Action Block -Enabled True -Profile Any `
  -InterfaceAlias "Wi-Fi"

New-NetFirewallRule -DisplayName "WG KillSwitch - Block outbound on Ethernet" `
  -Direction Outbound -Action Block -Enabled True -Profile Any `
  -InterfaceAlias "Ethernet"

At this point, you will likely lose connectivity until you add the next step (allow the WireGuard handshake outside the tunnel).

5) Allow the WireGuard app to reach the VPN server (handshake exception)

You must allow UDP from your normal interface to the VPN server’s public IP and port, otherwise the tunnel can’t establish.

Example (replace the server IP and port, and the WireGuard/Mullvad exe path):

• Mullvad typically uses its own service/exe; WireGuard uses wireguard.exe; some clients use custom binaries.
• Find the exact path from Task Manager > Details > right-click column > “Image path name”, or from the app’s install folder.

Example rule (Mullvad, placeholder path):

New-NetFirewallRule -DisplayName "WG - Allow Mullvad handshake to server" `
  -Direction Outbound -Action Allow -Enabled True -Profile Any `
  -InterfaceAlias "Wi-Fi","Ethernet" `
  -Protocol UDP -RemoteAddress 203.0.113.10 -RemotePort 51820 `
  -Program "C:\Program Files\Mullvad VPN\MullvadVPN.exe"

If your provider rotates server IPs or you switch locations frequently, you’ll need to update (or broaden) the allowed RemoteAddress set accordingly. I can’t safely suggest “allow to any remote address/port” here because that defeats the purpose.

6) DNS leak considerations

If you block all outbound on Wi‑Fi/Ethernet, DNS should also be blocked outside the tunnel (good). Once the tunnel is up, DNS should go via the tunnel.

If you use a local DNS resolver on your LAN intentionally (rare with a VPN kill switch), you’d need to allow that explicitly on the LAN interface, but that also increases leak risk.

About Mullvad’s internal tunnel IP

Mullvad’s tunnel IP is generally stable as long as you keep the same WireGuard key/config (“device”). If you regenerate keys/reinstall/reset the device in the provider/app, the tunnel IP can change. That’s why the interface-based kill switch above is usually the more durable solution.

Conclusion: Windows Defender Firewall can enforce a solid WireGuard kill switch, but it’s best done with interface-alias rules via PowerShell: allow traffic on the WireGuard adapter, block traffic on Wi‑Fi/Ethernet, and add a narrow handshake exception to the VPN server IP/port for the VPN client.