CMS v2.23.0 SAL Panel v1.0.364 SAL
Mail Support
Login

Connect the probe to the CMS over WireGuard

The probe that detects Cloudflare blocks must be able to talk to your MuseDock CMS precisely when Cloudflare fails. If the probe reaches your CMS over the internet and your own CMS's Cloudflare IP is blocked, the probe cannot report. The recommended way to avoid this is to link the probe and the CMS server with a private WireGuard VPN. This guide explains how, step by step.

Why WireGuard

  • It does not depend on Cloudflare: the probe reaches your server on its real IP, through an encrypted tunnel.
  • It is private: the probe's calls (IP list and reports) never cross the internet in the clear.
  • It works even if the probe sits behind a router (office, home, NAT): the probe is the one that opens the tunnel.
  • It is lightweight: it is part of the Linux kernel and uses hardly any resources.

Before you start

  • Root access to the CMS server and to the probe machine (Debian or Ubuntu in the examples).
  • The CMS server's real public IP. Not Cloudflare's: the server's. Get it with curl -4 https://api.ipify.org on the server itself.
  • A free UDP port on the CMS server (51820 in the examples).
  • A private network you do not use yet. In the examples: 10.66.0.0/24, with the server on 10.66.0.1 and the probe on 10.66.0.2.

If your servers are already linked by WireGuard (for example, in a cluster), you do not need another VPN: add the probe to the existing one and use the CMS server's private IP.

1. Install WireGuard on both machines

apt install wireguard

2. Create the keys

On each machine, create its key pair. The private key never leaves that machine; only public keys are exchanged.

umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
cat /etc/wireguard/public.key   # this is the one you give to the other machine

3. Configure the CMS server

Create /etc/wireguard/wg0.conf:

[Interface]
Address    = 10.66.0.1/24
ListenPort = 51820
PrivateKey = (contents of the server's /etc/wireguard/private.key)

[Peer]
# The probe
PublicKey  = (the probe's public key)
AllowedIPs = 10.66.0.2/32

Open the UDP port on the server's firewall. If you can, open it only to the probe's public IP:

ufw allow 51820/udp
# or, only for the probe:  ufw allow from PROBE_PUBLIC_IP to any port 51820 proto udp

4. Configure the probe

Create /etc/wireguard/wg0.conf on the probe machine:

[Interface]
Address    = 10.66.0.2/24
PrivateKey = (contents of the probe's /etc/wireguard/private.key)

[Peer]
# The CMS server
PublicKey           = (the server's public key)
Endpoint            = SERVER_REAL_PUBLIC_IP:51820
AllowedIPs          = 10.66.0.1/32
PersistentKeepalive = 25
Important: on the probe, AllowedIPs must be only the server's private IP (10.66.0.1/32). Never use 0.0.0.0/0: all the probe's traffic would go out through the server (which may be in another country) and the probe would stop seeing your providers' blocks.

5. Start and check

On both machines:

systemctl enable --now wg-quick@wg0
wg show

From the probe, check that you reach the server through the VPN:

ping -c 3 10.66.0.1
curl -s -o /dev/null -w "%{http_code}\n" --resolve your-cms.example:443:10.66.0.1 https://your-cms.example/api/v1/edge-guard/targets

If the last command answers 401, all is well: you reached the CMS API through the VPN and only the token is missing. If it answers 000, the web server is not listening on the VPN IP or the firewall blocks it: make sure your web server (Caddy, Nginx…) listens on all interfaces and the firewall allows port 443 from 10.66.0.0/24.

6. Tell the probe to use the VPN

In /etc/musedock-edge-probe.conf, add the server's private IP:

URL=https://your-cms.example
TOKEN_FILE=/etc/musedock-edge-probe.token
RESOLVE=10.66.0.1

The probe keeps using your CMS's name (so the certificate is valid) but connects through the VPN. Test it with:

python3 -I /usr/local/bin/musedock-edge-probe.py -v

It should end with "Informe entregado al CMS" (report delivered). Tests of Cloudflare IPs still go out through your providers (the PATHS interfaces), not through the VPN.

Troubleshooting

SymptomLikely cause and fix
wg show shows no "latest handshake"The tunnel is not up. Check that Endpoint is the server's real IP (not Cloudflare's), that the UDP port is open and that the public keys are crossed (each machine has the other's).
ping 10.66.0.1 gets no replyCheck AllowedIPs on both sides and that the private network does not clash with one you already use.
The curl to the API gives 000The web server does not listen on the VPN IP, or the firewall blocks 443 on the wg0 interface.
The probe says "HTTP 401"The tunnel works; the token is wrong or was revoked. Create the probe again in Settings → Cloudflare blocks.
The probe no longer detects blocksThe probe's AllowedIPs is probably 0.0.0.0/0 and everything goes out through the server. Set it to the server's private IP only.

Frequently asked questions

Is WireGuard mandatory?

No. The probe works over the internet without RESOLVE. But if your own CMS's Cloudflare IP gets blocked, the probe will not be able to deliver its reports exactly when they matter most. WireGuard removes that risk.

Can I use another VPN?

Yes. Any VPN or private network that lets the probe reach the CMS server on a private IP will do: RESOLVE only needs that IP.

Several probes?

Add one [Peer] block per probe on the server, each with its own IP (10.66.0.3/32, 10.66.0.4/32…), and create a separate token for each one in the CMS.