WireGuard su OPNsense: setup
OPNsense, fork di pfSense con cadenza di rilascio più rapida, integra WireGuard come plugin ufficiale (os-wireguard). L'interfaccia separa concetti Local (server) ed Endpoint (peer client) ed e particolarmente lineare per chi parte da zero.
Installazione plugin
OPNsense gestisce WireGuard via plugin scaricabile da System > Firmware > Plugins. Sono disponibili due implementazioni: wireguard-go (userland) e kernel module. Su FreeBSD 13 il kernel module e preferito per prestazioni e stabilita.
Procedura passo-passo
- Da System > Firmware > Plugins installa os-wireguard.
- Vai in VPN > WireGuard > Local e crea un'istanza con nome wg0, listen port 51820, tunnel address 10.30.30.1/24.
- Lascia generare automaticamente la coppia di chiavi e copiale per uso futuro.
- Crea Endpoints (peer) con public key del client, allowed IPs 10.30.30.X/32 e keepalive 25.
- Associa l'endpoint all'istanza Local nella scheda Peers dell'istanza.
- Abilita il servizio e vai in Interfaces > Assignments per associare wg0 come interfaccia.
- Configura regole firewall in Firewall > Rules > WireGuard per consentire il traffico desiderato.
Plugin os-wireguard vs kmod
OPNsense storicamente usava wireguard-go (userland), poi e arrivato il kernel module di FreeBSD 13 con performance native. Verifica nella scheda WireGuard > Settings quale backend e attivo. Il kernel module è raccomandato per produzione: throughput superiore, minore latenza, footprint memoria più basso. Migrazione tra i due e trasparente per la configurazione utente.
Integrazione con Unbound DNS
Una pratica utile in OPNsense e integrare il DNS Unbound con la rete WireGuard: abilita Unbound a rispondere sull'interfaccia wg0, e configura nei peer DNS = IP interno del tunnel. In questo modo i client VPN risolvono via DNS interno aziendale evitando leak verso resolver pubblici e beneficiano di cache DNS condivisa.
Sincronizzazione HA tra OPNsense
In setup HA (CARP), OPNsense può sincronizzare la configurazione WireGuard verso il nodo secondario tramite XMLRPC sync. Verifica che le chiavi siano sincronizzate ma non l'IP listen (e diverso per ciascun nodo). In caso di failover manuale, i client WireGuard riconnettono automaticamente grazie a keepalive. Documenta la procedura di failover anche se automatica.
Aliases per IP dinamici
Quando i client hanno IP dinamico o sono dietro CG-NAT, l'endpoint nel config del peer può essere lasciato vuoto: WireGuard usa il primo handshake per memorizzare l'IP corrente. Su OPNsense questo funziona se peer-config ha listen_port impostata: il client iniziera la connessione, il server impara l'IP, e il tunnel resta attivo. Documenta questa modalita per peer mobili.
Backup e config-as-code
OPNsense supporta export/import config XML completo. Per WireGuard, l'export include chiavi, peer, regole firewall e assignment interfacce. Versiona questo XML in Git (privato) per disaster recovery rapido. Strumenti come opnsense-config-bot e Ansible OPNsense collection abilitano IaC. Pianifica backup quotidiani automatici verso storage offsite.
Best practice di sicurezza
Indipendentemente dalla soluzione VPN scelta, alcune regole valgono sempre: usa chiavi e certificati robusti (RSA 2048+ o ECC P-256+, chiavi WireGuard generate con tool ufficiali), aggiorna regolarmente sia il software server sia i client, applica patch security non appena rilasciate, monitora i log per identificare attività anomale, ruota le credenziali periodicamente, segmenta la rete in modo che il tunnel non dia accesso indiscriminato a tutta la LAN aziendale, e formalizza una policy di disaster recovery con backup delle configurazioni. La VPN protegge il tunnel in transito ma non sostituisce hygiene di sicurezza degli endpoint: combina con MFA, EDR, patching aggressivo e formazione utenti per ottenere una postura di sicurezza completa.
Monitoring e osservabilita
Una VPN che non viene monitorata è una VPN che non sai se funziona. Raccogli metriche minime: numero di sessioni attive, latenza media end-to-end, percentuale di handshake riusciti vs falliti, throughput aggregato, geolocazione client. Strumenti come Prometheus + Grafana, Zabbix, PRTG o stack ELK forniscono dashboard utili. Configura alert proattivi su soglie critiche: tunnel down per oltre N minuti, picchi anomali di tentativi di autenticazione falliti, traffico fuori orario. In ambito aziendale integra con SIEM per correlazione cross-system e response automatica. Il monitoring continuo trasforma la VPN da componente passiva a infrastruttura osservabile e tunable nel tempo.
Documentazione e procedure operative
Documenta sempre l'architettura VPN come la documentereresti per un nuovo collega che la prende in carico domani: diagramma di rete, IP scheme, chiavi/certificati e dove sono custoditi, procedure di onboarding e revoca utenti, processi di rotazione chiavi, runbook per incidenti comuni (tunnel giu, latency anomala, certificato scaduto), responsabilità ownership. Conserva la documentazione in un wiki interno (Confluence, BookStack, GitBook) versionato e con backup. Quando un membro del team lascia, basta passare il riferimento alla documentazione: continuita operativa garantita anche con turnover.
Errori comuni e come risolverli
- Servizio non parte: verifica che il plugin sia attivo e che la porta UDP non sia in conflitto con altri tunnel.
- Peer non si connette: controlla l'ordine di Local e Endpoint: l'istanza locale deve avere l'endpoint nei suoi Peers.
- Outbound NAT mancante: in Firewall > NAT > Outbound aggiungi regola hybrid per la subnet WireGuard.
- Latenza alta dopo riavvio: abilita keepalive per garantire la riconnessione automatica dietro NAT.
Domande frequenti
D: Differenza con pfSense?
R: Funzionalmente equivalenti; OPNsense ha aggiornamenti più frequenti e UI più moderna.
D: Posso fare site-to-site verso un Linux?
R: Si, basta che le chiavi è gli endpoint pubblici siano configurati simmetricamente.
D: Posso usare IPv6?
R: Si, aggiungi indirizzi IPv6 nel tunnel e regole firewall corrispondenti.
Hai bisogno di aiuto?
Se vuoi configurare VPN aziendale con G Tech Group, scrivici tramite il modulo di contatto.