WireGuard VPN

This means the handshake never completed — the tunnel is listening but not connected. Fix:

1. In the DevMonk dashboard → VPN Peers → click Config / QR on your peer
2. Download the .conf file again (fresh copy)
3. In the WireGuard app on your device: delete the existing tunnel
4. Import the freshly downloaded config
5. Activate the tunnel — run wg show on the server and confirm you see latest handshake

The WireGuard interface is up but no peers are registered. This means the agent hasn't synced the peer to the WireGuard config yet.

Try restarting the agent: systemctl restart devmonk-agent
Then check the VPN page in the dashboard — the peer should still be listed. Try re-adding it if it's gone.

Most cloud providers have a separate firewall / security group that sits in front of your server, before ufw ever sees the traffic. Even if ufw shows port 51820 as open, the cloud firewall can be silently dropping packets.

Fix — add an inbound rule in your cloud console:

• Hetzner: Project → Firewalls → Add Rule → Inbound, Protocol: UDP, Port: 51820, Source: 0.0.0.0/0
• DigitalOcean: Networking → Firewalls → Inbound Rules → UDP 51820 → All IPv4
• AWS: EC2 → Security Groups → Inbound Rules → Custom UDP, Port 51820, 0.0.0.0/0
• Oracle Cloud: Networking → VCN → Security Lists → Ingress Rules → UDP 51820

After adding the rule, activate the WireGuard tunnel on your device — you should see latest handshake within seconds.

Your VPN is working perfectly. ICMP (ping) is blocked by the server firewall — this is normal and harmless. Use curl http://10.100.0.1:7474/api/health to verify connectivity instead of ping.

macOS requires a manual permission for WireGuard's network extension:

System Settings → Privacy & Security → scroll to the bottom → click Allow next to "WireGuard" → enter your Mac password → try activating the tunnel again.

This is a confirmed Windows 11 24H2 bug. Microsoft's 24H2 update disables the Virtual Machine Platform feature, which WireGuard's kernel tunnel driver (wintun) depends on for packet routing. The fix is to re-enable it.

Fix 1 — Enable Virtual Machine Platform (recommended)

1. Press Win + R, type optionalfeatures, press Enter
2. Scroll down and check Virtual Machine Platform
3. Click OK — Windows will download the feature
4. Reboot your machine
5. Re-activate the WireGuard tunnel — traffic should now flow

Alternatively via PowerShell (Admin):
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Then reboot.

Fix 2 — Remove client IP from AllowedIPs

If you cannot enable VMP, edit the tunnel config in the WireGuard app:

1. Open WireGuard → click Edit on your tunnel
2. In the [Peer] section, change AllowedIPs to only include the server's VPN subnet, e.g. 10.100.0.0/24
3. Remove any entry that matches your own client IP (e.g. remove 10.100.0.2/32 from AllowedIPs)
4. Save and re-activate the tunnel

Fix 3 — Add a Windows Defender Firewall rule for UDP 51820

The 24H2 update can also reset firewall rules. Run this in an Admin PowerShell:
New-NetFirewallRule -DisplayName "WireGuard UDP 51820" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

If all else fails, reboot the machine hosting the WireGuard server as well.

A missing handshake means the WireGuard UDP packets are never reaching the server. Work through these in order:

1. Windows Defender Firewall is blocking outbound UDP
Temporarily disable the firewall (Start → Windows Security → Firewall → turn off for Private network) and try the tunnel. If it works, re-enable the firewall and add an explicit allow rule:
New-NetFirewallRule -DisplayName "WireGuard Out" -Direction Outbound -Protocol UDP -RemotePort 51820 -Action Allow

2. Your ISP/router is blocking UDP 51820
Some routers block non-standard UDP. Test by changing the server's WireGuard listen port to 443 or 53 (update your peer config's Endpoint to match), then re-import the config on your Windows device.

3. Server is behind NAT without port forwarding
If your server has a private/ISP-assigned IP (e.g. 192.168.x.x), your cloud/ISP router is not forwarding UDP 51820 to it. Add a port forward rule: Protocol UDP, external port 51820 → server's private IP, port 51820.

4. Keys are mismatched
The server's peer config must use your client's public key, and your client config must use the server's public key. Re-download the config from the DevMonk dashboard and re-import it to ensure the keys are correct.

5. Enable PersistentKeepalive on the client
Edit the tunnel config and add to the [Peer] section:
PersistentKeepalive = 25
This prevents NAT mappings from expiring and keeps the handshake alive.

This is a routing conflict. On Windows 11, if your client config's AllowedIPs includes your own VPN IP as a /32 (e.g. AllowedIPs = 10.100.0.0/24, 10.100.0.2/32), it can create a routing loop — packets destined for the tunnel get routed back through themselves.

Fix:
1. Open WireGuard → Edit the tunnel
2. In [Peer] → AllowedIPs, remove your own client IP (/32 entry) — keep only the server subnet, e.g. AllowedIPs = 10.100.0.0/24
3. In [Interface], your Address should still be your full VPN IP: Address = 10.100.0.2/24
4. Save and re-activate

The /32 in AllowedIPs tells WireGuard to route only that single host through the tunnel. Using it for your own client IP on Windows 11 is known to cause routing failures — use the full subnet CIDR instead.

Verify the routing table:
Run route print in Command Prompt after activating the tunnel. You should see a route for 10.100.0.0 with the WireGuard interface (listed as the adapter with the VPN gateway). If you see duplicate or conflicting routes, deactivate the tunnel, run route delete 10.100.0.0, then reactivate.

By default, Windows allows outbound connections, so WireGuard clients can initiate tunnels without changes. However, if you are running the WireGuard server on Windows, or if a Windows update has tightened rules, you may need to add these:

Run all commands in Admin PowerShell:

Allow WireGuard handshake port inbound (server role):
New-NetFirewallRule -DisplayName "WireGuard UDP In 51820" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

Allow ICMP (ping) over the VPN interface (optional but useful for testing):
New-NetFirewallRule -DisplayName "WireGuard Ping In" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -InterfaceAlias wg0 -Action Allow

Set the WireGuard interface to the Private profile (prevents "public network" restrictions):
Set-NetConnectionProfile -InterfaceAlias wg0 -NetworkCategory Private

To allow RDP or SSH only over the VPN tunnel (not the public internet):
New-NetFirewallRule -DisplayName "RDP via WireGuard" -Direction Inbound -Protocol TCP -LocalPort 3389 -InterfaceAlias wg0 -Action Allow
New-NetFirewallRule -DisplayName "SSH via WireGuard" -Direction Inbound -Protocol TCP -LocalPort 22 -InterfaceAlias wg0 -Action Allow

Note: replace wg0 with the actual interface alias shown in the WireGuard app if it differs.

Your device's VPN IP is shown in the DevMonk dashboard → VPN Peers → in the IP Address column next to your peer name. The server is always 10.100.0.1. Devices are assigned starting from 10.100.0.2.

No — DevMonk uses split-tunnel mode by default. Only traffic to 10.100.0.0/24 goes through the VPN tunnel. Your normal internet traffic (browsing, streaming) uses your regular connection unaffected.