Wireguard VPN su VPS OVH: collegare sedi aziendali senza firewall hardware
Nel giugno 2025 mi ha contattato il direttore operativo di un'azienda piemontese di logistica integrata per la grande distribuzione - sede centrale a Torino, magazzino principale a Chivasso, due magazzini satellite a Vercelli e Novara, 38 dipendenti totali, 4,6 milioni di euro di fatturato annuo. L'infrastruttura di rete aziendale era basata su una VPN site-to-site gestita dal loro ISP principale (un operatore italiano nazionale), con costo ricorrente di 800 euro al mese per i tre link fra sedi. La VPN funzionava ma aveva tre problemi operativi accumulati. Primo problema: latenza elevata (80-120ms fra sedi fisicamente distanti 40-80km), probabilmente dovuta a routing sub-ottimale attraverso infrastructure ISP. Secondo problema: downtime periodici misurati a 2-4 ore al trimestre, attribuibili a manutenzioni dell'ISP o problemi della centrale di Torino. Terzo problema: nessuna visibilità operativa - quando la VPN andava down, la sede interessata chiamava il supporto ISP e aspettava.
La proposta che ho fatto al direttore operativo è stata sostituire la VPN ISP con infrastruttura WireGuard self-hosted su un VPS dedicato OVH, con costi ricorrenti di circa 12 euro al mese (VPS 2 vCPU, 4 GB RAM, 40 GB SSD, banda illimitata) - riduzione del 98,5% rispetto alla bolletta ISP precedente. In tre giornate distribuite in due settimane ho configurato il VPS concentrator, installato WireGuard nei firewall router esistenti delle quattro sedi (pfSense su hardware commodity in ciascuna sede), configurato routing e DNS per funzionalità trasparente. Dopo la migrazione, la latenza media fra sedi è scesa a 10-18 ms (dall'80-120 ms precedente) grazie al routing diretto via internet standard e non attraverso infrastruttura ISP. L'uptime misurato nei sei mesi post-go-live è stato del 99,97% - zero downtime attribuibili alla VPN stessa, tutti gli episodi di disconnessione erano dovuti a problemi ISP delle sedi singole. Costo consulenziale dell'intervento: 2.400 euro. Risparmio operativo annuale: circa 9.400 euro (800 euro × 12 mesi meno 12 euro × 12 mesi). ROI sulla prima annualità: oltre 3x considerando solo il risparmio diretto.
Questo articolo descrive il pattern di implementazione WireGuard come VPN site-to-site per PMI italiane, basato sull'esperienza di circa 20 progetti simili negli ultimi quattro anni (logistica multi-sede, retail distribuito, servizi professionali con uffici distaccati, aziende manifatturiere con stabilimenti separati). Il principio guida è uno: nel 2026, per la stragrande maggioranza delle PMI italiane con connettività multi-sede, WireGuard su VPS cloud è architetturalmente e economicamente superiore alle VPN hardware ISP tradizionali.
Perché WireGuard è il cambio di paradigma VPN che le PMI italiane stanno perdendo
WireGuard è un protocollo VPN di ultima generazione sviluppato da Jason Donenfeld e rilasciato come progetto open source nel 2015, incluso nel kernel Linux mainline dal 2020 (versione 5.6). Tecnicamente è la terza generazione di VPN dopo IPsec (anni '90) e OpenVPN (anni 2000), con tre vantaggi strutturali decisivi sui predecessori.
Primo vantaggio: semplicità del codice. WireGuard ha circa 4.000 righe di codice kernel, contro le 100.000+ di OpenVPN e 600.000+ di IPsec. Questa semplicità si traduce in superficie di attacco minima, facilità di audit di sicurezza, affidabilità in produzione. La documentazione ufficiale di WireGuard sul sito wireguard.com è eccellente e espone chiaramente il protocollo.
Secondo vantaggio: crittografia moderna di default. WireGuard usa ChaCha20 per cifratura, Poly1305 per authentication, Curve25519 per key exchange, BLAKE2s per hashing - tutti algoritmi moderni e considerati state-of-the-art. Nessuna configurazione richiesta, nessun downgrade a cipher deboli per compatibility, nessuna negoziazione complessa.
Terzo vantaggio: performance nativo. WireGuard gira nel kernel, non in user space - significa throughput estremamente alto (saturazione di link 1 Gbps facilmente raggiungibile), latenza minima (overhead sub-millisecondo su hardware moderno), efficienza CPU enorme. OpenVPN tipicamente consuma 5-10x più CPU per stesso throughput.
Il risultato pratico di questi vantaggi è che configurare una VPN site-to-site con WireGuard richiede minuti di lavoro, non giorni come IPsec. La configurazione è compatta (40-60 righe di testo per una topologia multi-site), leggibile, debuggabile.
Se gestisci un'azienda PMI con multiple sedi e paghi per VPN hardware gestita da ISP, nel mio profilo professionale trovi il dettaglio degli interventi di razionalizzazione infrastruttura network che ho condotto su PMI italiane, con focus su riduzione dei costi operativi ricorrenti senza compromettere sicurezza o performance.
Architettura hub-and-spoke: VPS concentrator + router per sede
Il pattern architetturale più appropriato per PMI con multiple sedi è hub-and-spoke: un singolo VPS concentrator su cloud pubblico al centro, router WireGuard in ciascuna sede che si connette al concentrator. Il traffico fra sedi passa sempre attraverso il concentrator. Alternative mesh full (ogni sede connessa a ogni altra direttamente) sono tecnicamente possibili ma producono complessità di configurazione O(N²) - per 4 sedi servirebbero 6 tunnel gestiti, per 5 sedi 10 tunnel, e così via. Hub-and-spoke mantiene complessità lineare O(N).
Il VPS concentrator per il cliente piemontese è un OVH VPS Starter - 2 vCPU, 4 GB RAM, 40 GB NVMe, banda illimitata, costo 12 euro/mese. Collocazione a Gravelines (Francia), vicino geograficamente all'Italia per latenza ottimale. Su questo VPS gira esclusivamente WireGuard (e qualche tool di monitoring) - è dedicato alla funzione VPN, senza altre applicazioni che potrebbero introdurre vulnerabilità o consumare risorse.
Ogni sede aziendale ha un router con capability WireGuard. Nel caso del cliente, abbiamo usato pfSense - firewall/router open source girante su hardware commodity mini-PC (costo 200-400 euro hardware per sede, acquistato una tantum). pfSense supporta WireGuard nativamente tramite package dedicato. Alternative commerciali equivalenti includono Ubiquiti Edge Router, MikroTik RouterOS, Fortinet FortiGate - tutti con WireGuard support nativo o plugin.
La configurazione di rete segue il pattern:
- Sede 1 (Torino): LAN 192.168.10.0/24, router wireguard peer IP 10.99.0.1/24
- Sede 2 (Chivasso): LAN 192.168.11.0/24, router wireguard peer IP 10.99.0.2/24
- Sede 3 (Vercelli): LAN 192.168.12.0/24, router wireguard peer IP 10.99.0.3/24
- Sede 4 (Novara): LAN 192.168.13.0/24, router wireguard peer IP 10.99.0.4/24
- VPS concentrator: 10.99.0.254/24, IP pubblico VPS
Ogni sede annuncia al concentrator il suo prefisso LAN locale. Il concentrator gestisce il routing fra sedi: il traffico da LAN 192.168.10.0/24 destinato a 192.168.11.0/24 viene instradato via WireGuard tunnel al concentrator, poi dal concentrator via WireGuard tunnel alla sede 2.
La configurazione del VPS concentrator
Sul VPS OVH, la configurazione WireGuard è un file /etc/wireguard/wg0.conf semplice:
[Interface]
Address = 10.99.0.254/24
ListenPort = 51820
PrivateKey = <chiave privata generata>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT
[Peer]
# Sede Torino
PublicKey = <chiave pubblica del router Torino>
AllowedIPs = 10.99.0.1/32, 192.168.10.0/24
[Peer]
# Sede Chivasso
PublicKey = <chiave pubblica del router Chivasso>
AllowedIPs = 10.99.0.2/32, 192.168.11.0/24
[Peer]
# Sede Vercelli
PublicKey = <chiave pubblica del router Vercelli>
AllowedIPs = 10.99.0.3/32, 192.168.12.0/24
[Peer]
# Sede Novara
PublicKey = <chiave pubblica del router Novara>
AllowedIPs = 10.99.0.4/32, 192.168.13.0/24La configurazione è dichiarativa: una sezione [Interface] per l'interfaccia WireGuard locale, una sezione [Peer] per ogni sede remota. Le AllowedIPs definiscono quali IP il concentrator accetta di ricevere da quella peer (validazione anti-spoofing) e a quali IP il concentrator instrada traffico destinato a quella peer.
Attivazione: systemctl enable --now wg-quick@wg0. L'interfaccia è pronta. Il VPS non ha bisogno di sincronizzare stato con clients - WireGuard è stateless al layer configurazione, le peer possono iniziare a connettersi in qualsiasi momento.
La configurazione dei router delle sedi (pfSense)
Sulla sede Torino, la configurazione nel router pfSense (via UI web o file /var/etc/wireguard/wg0.conf) è:
[Interface]
Address = 10.99.0.1/24
PrivateKey = <chiave privata del router Torino>
ListenPort = 51820
[Peer]
# VPS concentrator
PublicKey = <chiave pubblica del VPS>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.99.0.0/24, 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24
PersistentKeepalive = 25Il router Torino ha un solo peer (il concentrator) perché tutto il traffico verso altre sedi passa attraverso il concentrator. Le AllowedIPs includono: 10.99.0.0/24 (la rete VPN stessa per management), e le LAN delle altre tre sedi (192.168.11/12/13) - il concentrator è responsabile di instradare questo traffico verso le peer appropriate.
Il parametro PersistentKeepalive = 25 invia un keepalive ogni 25 secondi anche quando non c'è traffico - serve a mantenere aperta la NAT translation sul firewall ISP che altrimenti chiuderebbe la connessione dopo un po' di idle, costringendo a rinegoziazione al primo pacchetto utile.
Routing e DNS: farlo funzionare trasparentemente per gli utenti
Una VPN site-to-site è trasparente per gli utenti solo se il routing e il DNS sono configurati correttamente. Il pattern che applico è duplice.
Per il routing: su ogni router di sede, una route statica aggiuntiva che dirige il traffico destinato alle LAN delle altre sedi attraverso l'interfaccia WireGuard. pfSense configura questo automaticamente quando si definiscono le AllowedIPs. Su hardware Linux puro (es. Ubuntu server come router), la route si aggiunge con ip route add 192.168.11.0/24 dev wg0.
Per il DNS: ho configurato un DNS server interno (BIND9 su una VM piccola nella sede centrale Torino) con zone interne per i domini aziendali (*.corp.example.com) che risolve IP delle risorse interne distribuite fra le sedi. Ogni router di sede distribuisce via DHCP l'IP del DNS interno come primary DNS. I dipendenti possono accedere a risorse come fileserver.corp.example.com indipendentemente dalla loro sede di lavoro - il DNS risolve all'IP interno corretto, il routing VPN instrada il traffico.
Monitoring e alert: sapere se la VPN sta funzionando davvero
Una VPN site-to-site silente è fragile. Se una sede perde connettività VPN, gli utenti si lamentano del fatto che "non funzionano le stampanti di rete" o "il gestionale è lento" - segnali indiretti che mascherano la causa reale. Il pattern di monitoring che applico include tre elementi.
Primo elemento: monitoring del VPS concentrator. Su OVH, uso il monitoring integrato di OVH più Netdata self-hosted sul VPS. Metriche chiave: uptime del VPS, traffico WireGuard (bytes in/out per peer), handshake time per peer, status dell'interfaccia wg0. Alert automatici per: VPS down, nessun handshake da una peer per più di 5 minuti, traffico anomalo (possibile DoS).
Secondo elemento: ping check periodico fra sedi. Script cron che ogni minuto esegue ping da ciascuna sede alle altre tre sedi tramite tunnel VPN, registra latency e packet loss. Dati aggregati su Grafana per visibilità real-time.
Terzo elemento: alert Slack per eventi critici - sede disconnessa oltre 2 minuti, latency superiore a 50ms per più di 5 minuti, packet loss sopra 1%. Questo permette al team IT di reagire rapidamente e di contattare l'ISP della sede interessata (se il problema è connettività locale) prima che gli utenti si rendano conto di problemi.
Il pattern si integra con i principi di monitoring che ho descritto nel mio articolo sul benchmark reale fra Hetzner Cloud, Contabo e OVH per PMI italiane - la visibilità operativa continua è critica per stabilità long-term dell'infrastruttura.
Sicurezza: chi può accedere e con quale privileges
La sicurezza di un'architettura WireGuard site-to-site richiede attenzione a tre aspetti.
Primo aspetto: protezione del VPS concentrator. Essendo esposto su internet, il VPS è target di attacco. Le difese che applico: UFW che blocca tutto tranne porta 51820 UDP (WireGuard) e SSH da IP statici dei sysadmin, SSH hardening come ho descritto nel mio articolo sull'hardening SSH avanzato, nessun altro servizio esposto, aggiornamenti automatici di sicurezza via unattended-upgrades.
Secondo aspetto: gestione delle chiavi WireGuard. Ogni peer ha una propria chiave privata che non deve mai lasciare il router. Le chiavi pubbliche sono distribuite e non sensibili. Il pattern di rotazione chiavi è trimestrale - non obbligatorio ma best practice. Il processo di rotazione può essere gestito con deployment coordinato via Ansible come descritto nel mio articolo su Ansible per PMI senza DevOps dedicato.
Terzo aspetto: segmentazione di rete. Il fatto che le sedi siano connesse via VPN non significa che qualsiasi utente di una sede possa raggiungere qualsiasi risorsa di un'altra. Il pattern di firewall aziendale include rules specifiche - tipicamente le sedi operative possono accedere al gestionale centrale e file server della sede Torino, ma non si parlano direttamente fra loro senza motivo business. Questa segmentazione richiede configurazione firewall aggiuntiva sui router di sede.
Confronto economico e tecnico con VPN ISP tradizionali
Il confronto fra WireGuard self-hosted su VPS cloud e VPN ISP gestita è netto su praticamente ogni dimensione rilevante per PMI italiane.
Costo: WireGuard su OVH 12-25€/mese, VPN ISP Italy tipicamente 400-2.000€/mese per multi-site medi. Risparmio 95-99%.
Performance: WireGuard via cloud in data center europeo 10-30 ms latency fra sedi italiane, VPN ISP tipicamente 50-150 ms. Miglioramento 3-5x.
Flessibilità: WireGuard aggiungere una sede = 30 minuti di lavoro (configurazione router + peer nel concentrator). VPN ISP aggiungere una sede = richiesta commerciale, contratto, intervento tecnico ISP, tempi di 2-6 settimane.
Visibilità: WireGuard offre monitoring completo self-hosted. VPN ISP tipicamente offre solo report mensile generico, nessun accesso real-time.
Affidabilità: WireGuard su VPS cloud maturo (OVH, Hetzner, Digital Ocean) ha uptime 99,95-99,99%. VPN ISP in Italia ha uptime tipicamente comparabile ma con incidenti concentrati in finestre manutenzione programmata.
Lock-in: WireGuard portable (si può cambiare VPS provider in 1-2 ore). VPN ISP lock-in contrattuale con penali e procedure di uscita.
Il pattern rollout graduale per migrazione da VPN ISP a WireGuard che applico tipicamente è: implementare WireGuard in parallelo, testare per 2-4 settimane con subset di traffico, monitorare e confermare stabilità, eseguire cutover definitivo con disattivazione VPN ISP al termine del ciclo contrattuale. Questo approccio minimizza il rischio di transizione e non lascia gap di connettività.
Il risultato finale del cliente piemontese a dodici mesi dalla migrazione è stato il seguente. Risparmio operativo annuale confermato: 9.400 euro. Uptime misurato della VPN: 99,97% (zero downtime attribuibile alla VPN stessa). Latency media fra sedi: 14 ms mediana, 22 ms p95 (miglioramento 5-6x rispetto alla VPN ISP precedente). Zero problemi di scalabilità - la capacità del VPS OVH da 12 euro è largamente sufficiente per il traffico aggregato di 38 dipendenti. Tempo di gestione operativa VPN: circa 30 minuti al mese per review dei log e verifica aggiornamenti.
Se gestisci un'azienda PMI italiana con multiple sedi connesse via VPN ISP tradizionale e non hai mai valutato alternative self-hosted, la combinazione di WireGuard su VPS cloud è quasi sempre superiore tecnicamente ed economicamente. Il rollout è contenuto in poche giornate di lavoro consulenziale e il ROI è visibile già dal primo mese dopo il go-live. Se vuoi confrontarti sul tuo caso specifico con una valutazione tecnica ed economica della migrazione, contattami per una consulenza preliminare: in una sessione di analisi guidata valutiamo insieme la tua topologia di rete attuale, i costi ricorrenti della tua VPN ISP, e produciamo un piano di migrazione a WireGuard con stime realistiche di tempi, costi e risparmio atteso calibrato sulla tua realtà specifica.