Installare Proxmox VE su hardware privo di monitor e tastiera può sembrare una sfida, soprattutto quando si ha a che fare con server embedded, rack remoti o macchine industriali.

In questi scenari, la console seriale RS232 diventa uno strumento fondamentale per portare a termine l’installazione in modalità headless.

In questo articolo vedremo come installare Proxmox via seriale passo dopo passo, partendo dalla preparazione dell’installer fino alla configurazione corretta del bootloader e dell’accesso iniziale al sistema.

La guida è pensata per essere pratica e riproducibile, anche per chi non ha mai affrontato un’installazione Proxmox senza interfaccia grafica.

PREREQUISITI

Un secondo PC (Linux/macOS/Windows)

Una chiavetta USB (≥ 2–4 GB)

Cavo seriale:

• se il mini-PC ha DB9 RS232: ti serve un null-modem DB9DB9 (spesso) oppure un adattatore USBRS232 + null-modem
• se non sei sicuro: molti mini-PC vogliono null-modem (TX/RX incrociati)

ISO di Proxmox VE

DOWNLOAD DELLA ISO DI PROXMOX E PREPARAZIONE DELLA CHIAVETTA USB

Sul PC di supporto scaricare l’ISO dal sito di Proxmox.

Linux/macOS (dd)

ATTENZIONE: scegliere il disco giusto (/dev/sdX) o cancelli quello sbagliato.

sudo dd if=proxmox-ve_*.iso of=/dev/sdX bs=4M status=progress oflag=sync

Windows (Rufus)

Avviare Rufus

Selezionare la ISO di Proxmox

Scrivere su USB (impostazioni standard vanno bene)

COLLEGAMENTO DELLA SERIALE E APERTURA DELLA CONSOLE

Collegare la seriale mini-PC PC di supporto.

Linux

Trovare la porta con il comando:

dmesg | tail

Di solito è /dev/ttyUSB0 (USB-seriale) oppure /dev/ttyS0 (seriale nativa).

Aprire la console con il comando:

sudo screen /dev/ttyUSB0 115200

Per uscire da screen: Ctrl+A poi K poi Y

macOS

ls /dev/tty.usbserial*

screen /dev/tty.usbserial-XXXX 115200

Windows (PuTTY)

Connection type: Serial

Serial line: COM3 (o quella che vedi in Gestione Dispositivi)

Speed: 115200

Parametri: 115200 baud, 8 data bits, no parity, 1 stop bit (115200 8N1)

IMPOSTAZIONE DEL BIOS/UEFI PER OUTPUT SU SERIALE

Accedere al BIOS premendo il tasto corretto (solitamante TAB o DEL)

Dovremmo vedere la schermata del BIOS

Individuare nel BIOS la voce Serial Port Console Redirection

Abilitare la Console Redirection

Verificare che i parametri della Console Redirection siano quelli mostrati nell’immagine sovrastante e nell’immagine sottostante

Sopra la lista dei parametri della Console Redirection

Individuare quindi le voci relative alla Serial Port

Accertarsi che la seriale sia abilitata come mostrato nell’immagine sovrastante

Accertarsi che il parametro Redirection After BIOS POST sia attivo come mostrato nell’immagine sovrastante

Nella sezione Boot impostare la USB come primo device di boot

Dopo aver terminato la configurazione Salvare e Uscire dal BIOS

Se dopo l’accensione vedi testo sulla seriale (POST/BIOS) vuol dire che abbiamo fatto tutto correttamente

AVVIO DEL MINI-PC E APERTURA DEL BOOT MENU DI PROXMOX

Inserire la Chiavetta USB nel mini-PC quindi accendere il mini-PC

Aspettare 30–60 secondi

Selezionare l’opzione Install Proxmox VE (Terminal UI, Serial Console) quindi Invio

Cliccare su I Agree

Selezionare il disco dove si intende installare Proxmox quindi cliccare Next

Impostare le seguenti opzioni:

Country: Italy

Timezone: Europe/Rome

Keyboard: Italian

Quindi cliccare Next

Inserire la password e la mail di root quindi cliccare Next

Inserire la configurazione di rete scegliendo la scheda corretta quindi Next

Rivedere il riepilogo quindi cliccare Install

Attendere qualche istante fino al completamento dell’installazione

Rimuovere la chiavetta USB quindi attendere il riavvio

Se è andato tutto a buon fine da console dovremmo visualizzare la schermata mostrata nell’immagine sovrastante

A questo punto è possibile collegarsi a Proxmox via web da un qualsiasi browser

RENDERE LA SERIALE PERMANENTE

Una volta installato proxmox (da web o via SSH) rendere stabile la console seriale.

Modificare il grub con il comando:

nano /etc/default/grub

Cercare GRUB_CMDLINE_LINUX_DEFAULT o GRUB_CMDLINE_LINUX e impostare ad esempio:

GRUB_CMDLINE_LINUX_DEFAULT="quiet console=ttyS0,115200n8"

Aggiornare il grub con il comando:

update-grub

Quindi abilitare getty su seriale con i seguenti comandi:

systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service

Negli ambienti enterprise, l’evoluzione delle infrastrutture virtuali richiede spesso scelte architetturali che bilancino stabilità, prestazioni e semplicità di gestione.

Nei cluster Microsoft ospitati su VMware ESXi, una delle attività più delicate è la migrazione dello storage, in particolare quando si passa da dischi RDM (Raw Device Mapping) a dischi VMDK.

Questa transizione non è solo una questione tecnica, ma rappresenta un passaggio strategico per migliorare flessibilità, gestione dei backup, compatibilità con le funzionalità avanzate di VMware e riduzione della complessità operativa.

In questo articolo analizzeremo il contesto, le motivazioni e le best practice per affrontare in modo sicuro ed efficace la migrazione dello storage da RDM a VMDK in un cluster Microsoft virtualizzato.

OBBIETTIVI DELLA MIGRAZIONE

Eliminare la dipendenza dai dischi RDM
Semplificare la gestione dello storage
Migliorare portabilità, backup e manutenzione
Mantenere la piena compatibilità con Windows Failover Cluster

AMBITO E CONTESTO TECNOLOGICO

Hypervisor: VMware vSphere 8 e 7
Sistema Operativo: Windows Server minimo 2012 con Failover Cluster
Storage: VMFS 6.x

TIPOLOGIA DISCHI

Stato iniziale: RDM
Stato finale: VMDK condivisi (Clustered VMDK)

PREREQUISITI STORAGE/DATASTORE

Il datastore destinato a ospitare i dischi condivisi deve avere abilitata la funzionalità Clustered VMDK
Il datastore deve essere accessibile da tutti gli host ESXi del cluster

Spazio libero sufficiente per:
Nuovi dischi VMDK
Caratteristiche richieste del datastore:

File system: VMFS 6.x
Clustered VMDK: Enabled

PREREQUISITI LATO WINDOWS FAILOVER CLUSTER

Cluster funzionante e stabile
Stato cluster: Up
Tutte le risorse Online
Tutti i nodi del cluster spenti durante le fasi critiche

PREREQUISITI VMWARE

Compatibilità VMware vSphere 7.x / 8.x
Presenza di una Affinity Rule di tipo Separate Virtual Machines
Tutte le schede di rete configurate come vmxnet3

Tutte le VM del cluster devono:
Risiedere sullo stesso datastore condiviso
Avere un controller SCSI dedicato ai dischi di cluster

CONFIGURAZIONE CONTROLLER SCSI

Tipo: VMware LSI Logic SAS
SCSI Bus Sharing: Physical

NOTE IMPORTANTI

La migrazione NON è in-place
I dischi RDM non vengono convertiti direttamente
Si procede creando nuovi VMDK condivisi e migrando i dati
Il rollback è sempre possibile finché i dischi RDM non vengono rimossi

OPZIONALE

In questa fase è possibile migrare il quorum da disco a File Share Witness

ANALISI PRE-MIGRAZIONE

Identificare tutti i dischi RDM attualmente in uso, ad esempio:
Dati applicativi
Quorum
Log
Altri dischi di servizio

CREAZIONE DEL NUOVO CONTROLLER SCSI

Aggiungere un nuovo SCSI Controller

Configurare il controller come da immagine sovrastante

CREAZIONE DEI NUOVI DISCHI VMDK

Per ogni disco RDM:
Creare un nuovo VMDK sul datastore
Dimensione uguale o superiore al disco RDM originale

IMPOSTAZIONI DISCO

Disk Provisioning: Thick Provision Eager Zeroed
Sharing: No Sharing
Disk Mode: Dependent

Virtual Device Node:
Nuovo controller SCSI
Stesso ID su entrambi i nodi del cluster

Aggiugere un nuovo Hard Disk

Configurare il disco come da immagine sovrastante

Ripetere l’operazione per tutti i dischi necessari.

CREAZIONE DEL CONTROLLER SCSI SU TUTTI I NODI

Aggiungere un nuovo SCSI Controller

Configurare il controller come da immagine sovrastante

Collegare il VMDK a tutti i nodi del cluster utilizzando l’opzione Existing Hard Disk.

Il file VMDK si trova nel percorso della VM su cui è stato creato il disco.

CONFIGURAZIONE DISCHI SU WINDOWS

Avviare i nodi e accedere al nodo attivo con i dischi in carico.
Aprire la gestione dischi:

diskmgmt.msc

Impostare i nuovi dischi Online

Cliccare su Initialize Disk

Selezionare GPT quindi cliccare OK

Selezionare New Simple Volume

Assegnare la letterà all’unità

Cliccare Finish

ATTENZIONE: Ripetere la procedura per tutti i dischi

CONFIGURAZIONE DEL CLUSTER DI FAILOVER

Avviare Failover Cluster Manager e cliccare su Add Disk

Selezionare tutti i dischi disponibili quindi cliccare OK

Dovremmo visualizzare tutti i dischi aggiunti con la dicitura Storage Available

COPIA DEI DATI

Esempio di mapping delle unità:

F:\ → futuro E:\
H:\ → futuro K:\
G:\ → futuro J:\

Impostare lo stesso label del disco da dismettere sul nuovo disco.

COPIA DEI DATI CON ROBOCOPY

Da prompt dei comandi (CMD):

Creare la cartella per i log:

mkdir C:\Temp

Copia iniziale:

robocopy E:\ F:\ /E /COPY:DATS /R:2 /W:5 /LOG:C:\Temp\copy_E_to_F.log
robocopy K:\ H:\ /E /COPY:DATS /R:2 /W:5 /LOG:C:\Temp\copy_K_to_H.log
robocopy J:\ s:\ /E /COPY:DATS /R:2 /W:5 /LOG:C:\Temp\copy_J_to_s.log

Copia incrementale (solo differenze):

robocopy E:\ F:\ /MIR /COPY:DATS /R:1 /W:2 /LOG:C:\Temp\robocopy_E_to_F.log
robocopy K:\ H:\ /MIR /COPY:DATS /R:1 /W:2 /LOG:C:\Temp\robocopy_K_to_H.log
robocopy J:\ s:\ /MIR /COPY:DATS /R:1 /W:2 /LOG:C:\Temp\robocopy_J_to_s.log

RIMOZIONE DEI DISCHI RDM

Rimuovere i dischi RDM dal cluster

Rimuovere dai Roles

Riassegnare la lettera corretta ai nuovi dischi

ATTENZIONE: Ripetere la procedura per tutti i dischi

PULIZIA FINALE VMWARE

Rimuovere i dischi RDM

Rimuovere il controller SCSI associato ai vecchi dischi

Sull’ ultimo Nodo rimuovere i disci RDM cliccando su Remove device and data

Con il rilascio di Ubuntu Server 24.04 Netplan si conferma come lo strumento standard e consigliato per la gestione della rete segnando definitivamente il superamento del tradizionale file /etc/network/interfaces.

Per molti amministratori di sistema però questa transizione può risultare poco immediata soprattutto in ambienti server dove stabilità e prevedibilità della configurazione di rete sono fondamentali.

Questa guida nasce con l’obiettivo di accompagnarti passo dopo passo nella migrazione da /etc/network/interfaces a Netplan chiarendo le differenze concettuali tra i due approcci e mostrando esempi pratici di configurazione per i casi più comuni.

Che tu stia gestendo un server con indirizzi IP statici, DHCP, bonding o VLAN, troverai indicazioni utili per effettuare il passaggio in modo sicuro e consapevole, riducendo al minimo il rischio di interruzioni di servizio.

Al termine dell’articolo avrai una visione chiara di come funziona Netplan in Ubuntu Server 24.04 e sarai in grado di adottarlo con sicurezza anche in ambienti di produzione.

VERIFICA DELLA CONFIGURAZIONE ATTIVA

Verificare le schede attive con il comando:

ip -br a

Dovremmo visualizzare un output simile al seguente:

lo UNKNOWN 127.0.0.1/8 ::1/128
ens160 UP 192.168.100.247/24 fe80::20c:29ff:fe65:5f45/64

Visualizzare la tabella di routing del sistema con il comando:

ip r

Dovremmo visualizzare un output simile al seguente:

default via 192.168.100.1 dev ens160 onlink
169.254.0.0/16 dev ens160 scope link metric 1000
192.168.100.0/24 dev ens160 proto kernel scope link src 192.168.100.247

Visualizzare il contenuto del file di configurazione di rete tradizionale dei sistemi Linux con il comando:

sudo cat /etc/network/interfaces

Dovremmo visualizzare un output simile al seguente:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens160
iface ens160 inet static
address 192.168.100.247
netmask 255.255.255.0
gateway 192.168.100.1
dns-nameserver 192.168.100.1 8.8.8.8
dns-nameservers 192.168.100.1 8.8.8.8 8.8.4.4
dns-domain testlab.prv

CREAZIONE DEL FILE DI CONFIGURAZIONE NETPLAN

A questo punto creare il file Netplan (senza disabilitare ancora la vecchia config)

Verificare se esistono già dei file di configurazione con il comando:

ls -l /etc/netplan/

Dovremmo visualizzare un output simile al seguente:

Output: totale 0

Creare uno nuovo file di configurazione denominato 01-netcfg.yaml con il comando:

sudo nano /etc/netplan/01-netcfg.yaml

Quindi incollare all’interno del file il seguente output:

network:
ethernets:
ens160:
addresses: ['192.168.100.247/24']
nameservers:
addresses: [192.168.100.1, 8.8.8.8]
search: [testlab.prv]
routes:
- to: default
via: 192.168.100.1
version: 2

Salvare e chiudere il file di configurazione

Applicare i permessi al file di configurazione appena creato con i comandi:

sudo chmod 600 /etc/netplan/01-netcfg.yaml

sudo chown root:root /etc/netplan/01-netcfg.yaml

VALIDAZIONE DELLA CONFIGURAZIONE NETPLAN

Procedere con una validazione soft (ancora non tocchiamo ifupdown)

Controllare la sintassi del file col seguente comando:

sudo netplan generate

Se non dà errori procedere con la prova eseguendo il comando:

sudo netplan try

Dovremmo vedere il seguente output:

Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 109 seconds

Premere Invio per applicare la configurazione

NOTA BENE: Questo comando applica temporaneamente e chiede conferma. Se si perde la rete dopo ~120s torna indietro da solo.

DISATTIVAZIONE DELLA VECCHIA CONFIGURAZIONE

Adesso procedere con la cancellazione della vecchia gestione in modo pulito

Dato che stiamo utilizzando ifupdown (/etc/network/interfaces) eseguire un backup con i seguenti comandi:

sudo cp -a /etc/network/interfaces /etc/network/interfaces.backup.$(date +%F)

sudo cp -a /etc/network/interfaces.d /etc/network/interfaces.d.backup.$(date +%F) 2>/dev/null || true

Evitare che la vecchia configurazione venga applicata: la strada più semplice è svuotare o commentare la configurazione lasciando solo source se serve (oppure rinominare il file)

Rinominare il file con il comando:

sudo mv /etc/network/interfaces /etc/network/interfaces.disabled

Se il pacchetto ifupdown è installato e non ti serve più disinstallarlo con il comando:

dpkg -l ifupdown

Dovremmo visualizzare un output simile al seguente:

Voluto=U (non noto)/I (installato)/R (rimosso)/P (rimosso totale)/H (in attesa)
| Stato=Non/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(nessuno)/R (reinstallazione richiesta) (Stato,Err: maiuscolo=grave)
||/ Nome Versione Architettura Descrizione
+++-==============-=============-============-=================================>
ii ifupdown 0.8.41ubuntu1 amd64 high level tools to configure net>
lines 1-6/6 (END)

Quindi eseguire il comando:

sudo apt purge -y ifupdown

APPLICAZIONE DEFINITIVA DELLA CONFIGURAZIONE NETPLAN

Applicare definitivamente la configurazione con il comando:

sudo netplan apply

Quindi verificare che sia tutto ok con i seguenti comandi:

ip -br a

Dovremmo visualizzare un output simile al seguente:

lo UNKNOWN 127.0.0.1/8 ::1/128
ens160 UP 192.168.100.247/24 fe80::20c:29ff:fe65:5f45/64

Quindi visualizzare la tabella di routing del sistema con il comando:

ip r

Dovremmo visualizzare un output simile al seguente:

default via 192.168.100.1 dev ens160 onlink
169.254.0.0/16 dev ens160 scope link metric 1000
192.168.100.0/24 dev ens160 proto kernel scope link src 192.168.100.247

Visualizzare lo stato della risoluzione DNS del sistema con il comando:

resolvectl status | head -n 80

Dovremmo visualizzare un output simile al seguente:

Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens33)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.100.1
DNS Servers: 192.168.100.1 8.8.8.8
DNS Domain: testlab.prv

A questo punto il network del nostro server Ubuntu verrà gestito con Netplan

PRO DELLA MIGRAZIONE A NETPLAN

1. Standard moderno (Ubuntu)

Netplan è lo standard ufficiale su Ubuntu ≥ 18.04

Meglio integrato con:

• systemd
• cloud-init
• installer moderni

2. Configurazione dichiarativa (YAML)

Configurazione più leggibile e strutturata

Separazione chiara tra:

• IP
• gateway
• DNS
• routing

3. Supporto nativo a backend diversi

Netplan è solo un frontend che genera config per:

• systemd-networkd (server)
• NetworkManager (desktop)

4. Migliore gestione avanzata

Netplan gestisce nativamente:

• VLAN
• Bonding
• Bridge
• Routing policy
• Multiple interfacce / IP

Con ifupdown spesso servivano:

• script custom
• hack in /etc/network/if-up.d

5. Più sicuro da remoto

• rollback automatico
• riduce il rischio di lockout SSH

Con /etc/network/interfaces non esiste un equivalente nativo.

CONTRO DELLA MIGRAZIONE A NETPLAN

1. YAML è sensibile agli spazi

Errori di indentazione = rete KO

Più facile sbagliare rispetto a sintassi “lineare”

2. Meno immediato per vecchi admin

Chi viene da ifup/ifdown può trovarlo:

meno intuitivo

meno “diretto”

3. Debug meno trasparente

Netplan genera file temporanei: /run/systemd/network/

Non sempre è chiaro dove finisce la config

Con ifupdown: il file è la config

4. Dipendenza da systemd

Netplan richiede systemd

Non adatto a:

• sistemi minimal
• ambienti embedded legacy

5. Cambiamenti operativi

Comandi diversi:

• ifdown eth0
• netplan apply

Alcuni tool storici non si integrano più

Negli scenari di rete moderni, la continuità del servizio e l’affidabilità della connettività Internet sono requisiti fondamentali, soprattutto in ambito aziendale o professionale.

Una delle soluzioni più efficaci per garantire alta disponibilità è l’utilizzo di una configurazione Multi-WAN, che consente di sfruttare più collegamenti Internet con ruoli differenti.

In questo articolo vedremo come configurare pfSense in modalità Multi-WAN utilizzando una linea Tier 1 come collegamento primario e una linea Tier 2 come backup, affrontando anche un caso spesso sottovalutato ma molto comune: la presenza di Double-NAT.

Analizzeremo i principi di funzionamento, le scelte architetturali e le impostazioni necessarie per ottenere un failover affidabile, minimizzando disservizi e problemi di routing in un contesto reale.

SCENARIO

COLLEGAMENTO FISICO E ASSEGNAZIONE DELLE INTERFACCE DI RETE

Collega ADSL1 a una porta WAN (es. WAN).

Collega ADSL2 a un’altra porta (es. OPT1).

Vai su Interfaces → Assignments

Assicurati che WAN sia la primaria

Cliccare su Add per aggiungere OPT1

Se è tutto OK dovremmo visualizzare la nuova interfaccia aggiunta. Cliccare su OPT1 per modificare il nome dell’interfaccia

Rinominare l’interfaccia in WAN2 e abilitarla.

Cliccare Save

Cliccare su Apply Changes

Se abbiamo fatto tutto correttamen te dovremmo visualizzare un schermata come quella sovrastante

Vai su Interfaces → WAN e Interfaces → WAN2

Enable

Imposta il tipo corretto:

Se il modem fa PPPoE: seleziona PPPoE e inserisci user/pass

Se il modem fa routing/NAT e pfSense prende IP via modem: DHCP

Salva e Apply Changes

NOTA BENE: se i modem sono in router mode (fanno NAT), funziona lo stesso per il failover, ma alcune cose (port forward, VPN) diventano più delicate.

CONFIGURAZIONE DELLE WAN CON IP STATICO

Configura le WAN con IP statico

WAN1

Interfaces → WAN

IPv4 Configuration Type: Static IPv4

IP Address: 192.168.1.50/24

Gateway: 192.168.1.1 (router ADSL1)

Cliccare su Save

WAN2

Interfaces → WAN2

IPv4 Configuration Type: Static IPv4

IP Address: 192.168.2.50/24

Gateway: 192.168.2.1 (router ADSL2)

Cliccare su Save

CONFIGURAZIONE DEL DNS

Fondamentale con double-NAT.

System → General Setup

Deselezionare:

Allow DNS server list to be overridden by DHCP/PPP on WAN or remote OpenVPN server

Cosa fa quando è abilitata:

pfSense userà i server DNS ricevuti automaticamente dal provider (via DHCP/PPP sulla WAN o da un server OpenVPN remoto, se configurato).

Questi DNS saranno usati da pfSense stesso, ad esempio per risolvere nomi durante aggiornament e/o per funzionalità del DNS Resolver / Forwarder

Cosa non fa:

Non passa questi DNS automaticamente ai client DHCP nella rete LAN.

I client riceveranno i DNS che hai configurato manualmente sotto Services > DHCP Server, oppure pfSense stesso come DNS (es. 192.168.10.1).

Quando abilitarla?

Se vuoi che pfSense usi i DNS del tuo ISP o VPN remota, ma mantieni il controllo sui DNS dei client.

Utile in ambienti dove i DNS per la rete interna devono essere fissi (es. Cloudflare, Google DNS, DNS filtranti come OpenDNS) ma vuoi comunque che pfSense possa risolvere tramite quelli assegnati dinamicamente.

MONITOR IP: NON UTILIZZARE IL GATEWAY DEL ROUTER

ATTENZIONE: Qui è il punto critico.

Se metti come monitor:

192.168.1.1

pfSense penserà che la WAN è OK anche se Internet è down.

La soluzione corretta è quella di utilizzare IP Pubblici diversi per le due WAN

Andare su System → Routing → Gateways

Per ogni gateway:

WAN1_GW

Monitor IP: 1.1.1.1

WAN2_GW

Monitor IP: 8.8.8.8

ATTENZIONE: Utilizzare IP pubblici e diversi per le due WAN

Salvare la configurazione

GATEWAY GROUP (FAILOVER PURO)

A questo punto procedere con la configurazione del Gateway Groups

Andare su System → Routing → Gateway Groups quindi cliccare Add

Impostazioni:

Nome: FAILOVER_ADSL

WAN1_GW → Tier 1

WAN2_GW → Tier 2

Keep Failover States: Keep states on gateway Recovery

Trigger Level: Member Down (failover solo se Internet è KO)

Cliccare su Save

Cos’è Keep Failover States

È un’impostazione dei Gateway Groups che decide cosa succede alle connessioni già aperte quando:

• un gateway primario torna UP
• dopo che il traffico era passato su un gateway secondario

Non riguarda il firewall in sé, ma gli stati delle connessioni (state table).

Keep states on gateway recovery

Cosa fa

Quando il gateway primario torna disponibile

Le connessioni aperte sul gateway di backup continuano a usare il backup

Le nuove connessioni useranno il primario

Esempio pratico:

WAN_FIBRA (Tier 1) → cade

WAN_LTE (Tier 2) → prende il traffico

WAN_FIBRA torna UP

Download, VPN, call non si interrompono

Solo le nuove connessioni tornano su fibra

MASSIMA continuità

Uso più lento finché le sessioni finiscono

Scelta ideale per:

• VPN
• VoIP
• RDP
• Streaming
• Servizi “stateful”

Kill states on gateway recovery

Cosa fa

Quando il gateway primario torna UP

pfSense termina forzatamente le connessioni che stavano usando il backup

Tutto il traffico torna subito sul primario

Esempio pratico:

Fibra giù → traffico su LTE

Fibra torna UP

pfSense chiude le connessioni LTE

Browser ricarica, VPN si riconnette

Ripristino immediato delle prestazioni

Micro-interruzioni

Scelta ideale per:

• Linee LTE costose
• Ambienti dove la velocità è prioritaria
• Traffico web “stateless”

REGOLE LAN: ATTIVAZIONE DEL FAILOVER

A questo punto bisogna modificare la regola della LAN assegnandoli il nuovo gateway

Andare in Firewall → Rules → LAN

Quindi modificare la regola IPv4 Default allow LAN to any rule cliccando sulla matita

Cliccare su Display Advanced

Andare al fondo della pagina e individuare l’impostazione Gateway

Quindi selezionare FAILOVER_ADSL

Save → Apply Changes

Se è tutto corretto dovremmo vedere una schermata come quella sovrastante

ATTENZIONE: Senza questo passaggio NON scatterà MAI il failover.

OUTBOUND NAT

A questo punto è necessario configurare l’Outbound NAT

Andare su Firewall → NAT → Outbound

Selezionare l’opzione Hybrid Outbound NAT e salvare.

Controllare che nelle Automatic Rules esistano le regole come da immagine sovrastante

LAN net → WAN address
LAN net → WAN2 address

ATTENZIONE: Se mancano aggiungerle manualmente.

CONFIGURAZIONE LOAD BALANCING E GATEWAY MONITORING

In pfSense, l’impostazione Load Balancing → Use sticky connections serve a mantenere la coerenza delle connessioni quando usi più gateway WAN in bilanciamento.

Andare su System → Advanced → Miscellaneous

Quindi abilitare l’opzione Load Balancing – Use stickly connections

Andare verso il fondo della pagine ed individuare l’impostazione Gateway Monitoring

Nella sezione State Killing on Gateway Failure configurare Flush all stetes on gateway failure

Nella sezione Skip rules when gateway is down abilitare l’opzione Do not create rules when gateway is down

Save → Apply Changes

CONFIGURAZIONE DEL DEFAULT GATEWAY

L’ultimo step da fare è quello di configurare come Default Gateway il Gateway Group

Selezionare dal menù a tendina il Gateway Group FAILOVER_ADSL creato in precedenza.

Save → Apply Changes

TEST DI FUNZIONAMENTO

Da un PC in LAN:

ping 1.1.1.1 -t

Spegnere o scollegare il Router ADSL1

Dopo 5–10 secondi:

qualche timeout

poi il ping riprende via ADSL2

Riaccendere ADSL1:

pfSense tornerà sulla primaria

Controllare il Gateway Primario in: Status → Gateways

LIMITAZIONI NORMALI (non errori)

Con router davanti a pfSense:

Le connessioni attive cadono durante lo switch

Port forwarding complicato (doppio NAT)

VPN in ingresso più complessa

Navigazione, mail, update → OK

Failover → OK

MIGLIORIE CONSIGLIATE (se puoi)

Se i router lo permettono:

Mettili in DMZ verso pfSense

Oppure in bridge (ideale)

Eseguire l’upgrade di Veeam Backup & Replication dalla versione 12 alla versione 13 non è solo un aggiornamento di routine, ma un passaggio strategico per migliorare sicurezza, prestazioni e affidabilità dell’infrastruttura di backup.

Con la nuova release, Veeam introduce funzionalità avanzate pensate per rispondere alle crescenti esigenze di protezione dei dati, alla complessità degli ambienti ibridi e alle minacce sempre più sofisticate come ransomware e attacchi mirati ai sistemi di backup.

In questo articolo vedremo perché è importante pianificare correttamente l’upgrade, quali benefici concreti offre la versione 13 e quali aspetti valutare prima di procedere, per garantire una transizione fluida e senza impatti sui processi di business.

PREREQUISITI

Server Windows con Veeam Backup & Replication 12 installato

Immagine ISO di Veeam Backup & Replication 13

ATTENZIONE: è possibile eseguire l’aggiornamento alla versione 13 solo se si ha la versione 12.3.2 installata

PROCEDURA DI AGGIORNAMENTO

Accedere al server Windows e montare la ISO Veeam Backup & Replication 13

Cliccare Upgrade

Cliccare OK

Attendere qualche secondo

Cliccare su Upgrade Veeam Backup & Replication

Cliccare I Accept

Abilitare l’opzione Update license automatically quindi cliccare Next

Attendere qualche istante per la ricerca delle features mancanti

Per proseguire cliccare Next

Selezionare l’opzione Update remote components automatically quindi cliccare Upgrade

Attendere che finisca gli steps

Cliccare Finish per terminare l’installazione

Cliccare Yes per riavviare il server

A questo punto avviare il programma cliccando sull’icona presente sul dekstop

Cliccare su Connect

Alla prima connessione ci verrà chiesto di trustare il certificato del server cliccando Yes

Cliccare su Sign in as Current User oppure inserire le credenziali di accesso

Se è andato tutto a buon fine dovremmo visualizzare la nuova interfaccia di Veeam 13 con tutte le relative configurazioni e personalizzazioni presenti sulla versione precedente.

Negli articoli precedenti di questa serie è stato mostrato come configurare HaAProxy per servire da bastione SSH e come configurare i templates della Windows Enterprise CA per distribuire i certificati dei clients mediante Active Directory.

In questo articolo verranno mostrati i passaggi per configurare i propri clients per collegarsi ai server in SSH passando da bastione ed autenticandosi con i certificati forniti dalla Enterprise CA.

Verrà proposta una configurazione cross-platform che sfrutta OpenSSL che però abbiamo riscontrato avere delle pessime performance su Windows, perciò verrà anche analizzata una configurazione più prestante sul sistema operativo di Microsoft che utilizza il software Stunnel.

REQUISITI

Al fine di poter procedere è necessario essere in possesso di una coppia di chiavi rilasciate dalla CA considerata attendibile da HAProxy per l’autenticazione mediante mTLS.

Se si ha seguito l’articolo precedente si dovrebbe essere in possesso di un certificato valido e la relativa chiave privata nel proprio Trust Store, nei prossimi passaggi verrà mostrato come entrarre la coppia di chiavi per utilizzarle per l’autenticazione con HAProxy.

Linux e MacOS vengono distribuiti con il comando ssh ed il comando openssl pronti all’uso, su Windows, invece, potrebbe essere necessario installare del software aggiuntivo.

Inoltre, per l’utilizzo di Stunnel è necessario installare il relativo pacchetto ed il software ncat, oltre che essere in possesso di una copia del certificato della CA, utilizzata su HAProxy per la validazione dei certificati dei clients, in formato PEM.

Infine si consiglia la lettura del seguente articolo al fine di comprendere meglio il funzionamento della configurazione del client SSH.

Configurazione del client SSH per superare i firewall su Windows, Linux e MacOS

INSTALLAZIONE SSH SU WINDOWS

Il client SSH è una Windows Capability a partire da Windows 10 ed è possibile abilitarlo mediante PowerShell.

Per verificare se la funzionalità è già attiva eseguire il seguente comando in una PowerShell amministrativa:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Client*'

Se il client è abilitato l’output mostrato dovrebbe essere simile al seguente:

Name : OpenSSH.Client~~~~0.0.1.0
State : Installed

Altrimenti, è possibile installarlo con il seguente comando:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

INSTALLAZIONE OPENSSL SU WINDOWS

Mediante PowerShell è possibile verificare se “openssl” è presente sulla propria macchina, per farlo eseguire in una PowerShell con il proprio utente (non da ) il seguente comando:

Get-Command openssl

Se è installata la versione nativa per Windows di OpenSSL l’output dovrebbe essere simile al seguente:

CommandType Name Version Source
----------- ---- ------- ------
Application openssl.exe 3.6.0.0 C:\Program Files\OpenSSL-Win64\bin\openssl.exe

È possibile che si stia utilizzando un eseguibile fornito insieme a msys64, in questo caso è possibile installare la versione nativa e modificare il PATH di sistema per puntare alla versione appena installata.

Per installare OpenSSL mediante Chocolatey è possibile eseguire il seguente comando in una PowerShell amministrativa:

choco install -y openssl

In alternativa il programma di installazione è disponibile sul sito di Shining Light Productions

Al termine dell’installazione potrebbe essere necessario chiudere la PowerShell e riaprirla prima di poter utilizzare openssl.

ESPORTAZIONE DI UN CERTIFICATO CON CHIAVE PRIVATA DAL PERSONAL TRUST STORE

Nel precedente articolo di questa serie è stato mostrato come richiedere un certificato dallo snap-in certmgr.msc ed importarlo nel Personal Trust Store.

Per poterlo utilizzare dal browser sarebbe sufficiente, tuttavia non è lo stesso caso per il protocollo SSH, perciò necessitiamo di esportarlo.

Per esportare un certificato e la relativa chiave privata è necessario selezionarlo, effettuare click destro, navigare con il mouse su All Tasks e selezionare Export:

Procedere cliccando su Next:

Selezionare Yes, export the private key e cliccare su Next:

Selezionare Export all extended properties e procedere cliccando su Next:

Abilitare Password, sceglierne una e scriverla due volte, modificare l’agoritmo di criptografia in AES256-SHA256 e cliccare su Next:

Cliccare su Browse, selezionare il percorso in cui si vuole esportare il file, poi procedere cliccando su Next:

Concludere la procedura cliccando su Finish:

Infine, confermare cliccando su OK:

ESTRAZIONE DI UNA COPPIA DI CHIAVI DA UN FILE PFX

L’esportazione di una coppia di chiavi (certificato + chiave privata) dallo snap-in di Windows richiede che venga configurata una password o che vengano configurate delle ACL e che il formato dell’output sia PFX.

Per poter utilizzare il mTLS mediante OpenSSL o Stunnel è necessario essere in possesso di due files in formato PEM, perciò bisogna procedere all’estrazione del certificato e della chiave privata dal file PFX.

I comandi mostrati in questo paragrafo sono compatibili con Linux e MacOS.

Il file PFX utilizzato per esempio si chiama user.pfx, è necessario sostituire il nome opportunamente nei propri comandi; inoltre, si assume che la PowerShell o il CMD venga aperto nella directory in cui è stato salvato il file PFX.

Per estrarre il certificato eseguire con il proprio utente in una PowerShell o in un CMD:

openssl pkcs12 -in user.pfx -clcerts -nokeys -out user.crt

Inserire la password che si è scelta durante l’esportazione.

Per estrarre la chiave privata eseguire con il proprio utente in una PowerShell o in un CMD:

openssl pkcs12 -in user.pfx -nocerts -nodes -out user.key

Inserire la password scelta durante l’esportazione.

CONFIGURAZIONE DEL TUNNEL CON OPENSSL

Per configurare un client per utilizzare il bastione per connettersi ad un server è sufficiente aggiungere una direttiva al proprio file ~/.ssh/config.

Se non esiste la directory .ssh nella propria HOME (tipicamente su Linux /home/<username> e su Windows C:\Users\<username>) è necesario crearla ed assicurarsi che solo il proprio utente ci possa accedere.

Su Windows si consiglia fortemente di disabilitare l’ereditarietà dei permessi su quella folder e di assegnare solamente tre ACL Full control al proprio utente, a SYSTEM e agli Administrators.

Nella directory .ssh creare, se non già esiste, un file di testo (senza estensione) chiamato config, in questo file è possibile configurare le connessioni SSH verso i propri servers.

Aggiungere o modificare nel file config l’host a cui ci si vuole collegare mediante il bastione aggiungendo la direttiva ProxyCommand, in seguito viene riportato un esempio:

Host local-srv01 alias01
HostName local-srv01.pizza.local
User root
ProxyCommand openssl s_client -servername local-srv01.pizza.local -connect 192.168.1.100:22 -cert ~/.ssl/user.crt -key ~/.ssl/user.key -quiet -verify_quiet

Le informazioni da modificare dall’esempio precedente sono le seguenti:

• local-srv01 alias01 sostituire con i nomi che si vogliono utilizzare per collegarsi dal client ssh (eg. ssh alias01)
• local-srv01.pizza.local sostituire con l’FQDN del server a cui ci si vuole collegare, vicino ad HostName si può inserire anche solo l’hostname, oppure un alias
• root sostituire con l’utenza con cui ci si vuole autenticare
• 192.168.1.100 sostituire con l’IP o il nome DNS del VIP di HAProxy o dell’IP esposto mediante NAT
• ~/.ssl/user.crt sostituire con il percorso del certificato del client
• ~/.ssl/user.key sostituire con il percorso della chiave privata del client

Se tutto è stato configurato correttamente è possibile collegarsi al server remoto da un terminale eseguendo:

ssh <hostname>

Ad esempio:

ssh local-srv01

INSTALLAZIONE DEL SOFTWARE AGGIUNTIVO PER STUNNEL

Abbiamo riscontrato che il tunnel effettuato con OpenSSL su Windows ha delle pessime performace e che questo causa dei fastidiosi rallentamenti quando vengono lanciati dei comandi nella sessione SSH.

Per ovviare a questa problematica è possibile implementare il tunner mediante altri software che facciano utilizzo del provider di criptografia nativo di Windows, un esempio di questi software è Stunnel.

Un amministratore, mediante dei files di configurazione, può impostare le connessioni da utilizzare come tunnels e gli utenti possono avviarli da interfaccia grafica, per poi connettersi in SSH come farebbero con il tunnel OpenSSL.

Affinché sia possibile instradare le connessioni SSH verso il tunnel è necessario un software aggiuntivo, ne esistono diversi che svolgono questo ruolo, noi abbiamo testato ncat.

Il software ncat è incluso con l’installazione per Windows di Nmap, tuttavia se non si volesse installare anche Nmap sarebbe possibile effettuare il download dell’eseguibile statico dal sito ufficiale https://nmap.org/ncat/

L’installazione di Nmap mediante Chocolatey necessita di AutoHotkey ed a volte per questo motivo non funziona correttamente, in questi casi si consiglia di utilizzare l’installer ufficale preso dal sito web.

Per installare Nmap con Chocolatey eseguire in una PowerShell amministrativa il seguente comando:

choco install -y nmap

L’installazione di Stunnel mediante Chocolatey funziona correttamente, però è comunque possibile effettuarla con un software di installazione ufficiale scaricabile dal sito ufficiale https://www.stunnel.org/downloads.html

Per installare Stunel con Chocolatey eseguire in una PowerShell amministrativa il seguente comando:

choco install -y stunnel

CONFIGURAZIONE DI STUNNEL

Prima di partire con la configurazione di Stunnel è necessario copiarsi in una cartella a piacere il certificato della CA ed il certificato e la chiave privata del client, tutti in formato PEM.

La procedura di esportazione del certificato dell’utente è stata mostrata nei paragrafi precedenti, invece il certificato della CA è stato utilizzato nel primo articolo di questa serie, quando è stata mostrata la configurazione di HAProxy.

Per aprire la configurazione di Stunnel è possibile eseguire Edit stunnel.conf dal menù Start:

Oppure, in alternativa, è possibile aprire il file C:\Program Files (x86)\stunnel\config\stunnel.conf con un editor di testo con privilegi amministrativi.

Nel file di configurazione decommentare la seguente riga:

include = conf.d

Inoltre, nello stesso file, commentare tutti gli esempi di default, come ad esempio:

;[gmail-pop3]
;client = yes
;accept = 127.0.0.1:110
;connect = pop.gmail.com:995
;verifyChain = yes
;CAfile = ca-certs.pem
;checkHost = pop.gmail.com
;OCSPaia = yes

Nella cartella C:\Program Files (x86)\stunnel\config\conf.d è possibile aggiungere i files di configurazione dei tunnels.

Per creare la cartella e le configurazioni è possibile utilizzare lo stesso blocco note che si stava utilizzando per modificare il file stunnel.conf, per farlo aprire un nuovo tab cliccando sul simbolo + in alto:

Incollare il seguente contenuto:

[local-srv01]
client = yes
verifyChain = yes
accept = 127.0.0.1:22100
connect = 192.168.1.100:22
sni = local-srv01.pizza.local
checkHost = local-srv01.pizza.local
CAfile = C:\SSL\MyLocalCA.crt
cert = C:\SSL\user.crt
key = C:\SSL\user.key

Le informazioni da modificare dall’esempio precedente sono le seguenti:

• 22100 sostituire con la porta che deve essere dedicata al tunnel, su cui Stunnel si deve mettere in ascolto
• local-srv01.pizza.local sostituire con l’FQDN del server a cui ci si vuole collegare
• 192.168.1.100 sostituire con l’IP o il nome DNS del VIP di HAProxy o dell’IP esposto mediante NAT
• C:\SSL\MyLocalCA.crt sostituire con il percorso del certificato della CA
• C:\SSL\user.crt sostituire con il percorso del certificato del client
• C:\SSL\user.key sostituire con il percorso della chiave privata del client

È possibile specificare più di un tunnel nello stesso file a patto che il nome tra le parentesi quadrate sia univoco, per ogni server protetto dal bastione bisogna configurare un tunnel dedicato che utilizzi una porta su cui mettersi in ascolto univoca (in questo caso la 22100).

Cliccare su File e poi su Save with name:

Navigare al percorso C:\Program Files (x86)\stunnel\config, creare la folder conf.d cliccando su New folder e navigarci all’interno:

Nella folder conf.d salvare il file con un nome a piacere che abbia l’estensione .conf:

Per avviare i tunnels è possibile eseguire stunnel GUI Start dal menù Start:

In caso di problemi di configurazione viene aperta una finestra simile alla seguente in cui è indicato l’errore:

In questi casi correggere l’errore, cliccare su Configuration nella UI di Stunnel e poi su Reload Configuration:

Mentre Stunnel è in esecuzione è possibile visualizzare la sua interfaccia grafica cliccando sulla sua icona in basso a destra:

Per fermare i tunnels è possibile eseguire stunnel GUI Stop dal menù Start:

CONFIGURAZIONE DEL TUNNEL CON STUNNEL

Dopo aver configurato Stunnel è possibile impostare il client SSH per instradare le connessioni verso di esso.

Per farlo, analogamente a come è stato descritto nel paragrafo CONFIGURAZIONE DEL TUNNEL CON OPENSSL è necessario aggiungere una direttiva al proprio file ~/.ssh/config.

Se non si ha già creato il file ~/.ssh/config seguire i primi passaggi del paragrafo CONFIGURAZIONE DEL TUNNEL CON OPENSSL per crearlo.

Aggiungere o modificare nel file config l’host a cui ci si vuole collegare mediante il bastione aggiungendo la direttiva ProxyCommand, in seguito viene riportato un esempio:

Host local-srv01 alias01
HostName local-srv01.pizza.local
User root
ProxyCommand ncat.exe 127.0.0.1 22100

Le informazioni da modificare dall’esempio precedente sono le seguenti:

• local-srv01 alias01 sostituire con i nomi che si vogliono utilizzare per collegarsi dal client ssh (eg. ssh alias01)
• local-srv01.pizza.local sostituire con l’FQDN, l’hostname o un alias del server a cui ci si vuole collegare
• root sostituire con l’utenza con cui ci si vuole autenticare
• 22100 sostituire con la porta del tunnel configurata su Stunnel per quello specifico server

Se tutto è stato configurato correttamente è possibile collegarsi al server remoto da un terminale eseguendo:

ssh <hostname>

Ad esempio:

ssh local-srv01

Se viene mostrato un errore simile al seguente:

CreateProcessW failed error:2
posix_spawnp: No such file or directory

Potrebbe essere causato dal fatto che ncat.exe non è ancora disponibile sul PATH, in questi casi si consiglia di disconnettere la sessione di Windows ed accedere nuovamente.

Se invece l’errore mostrato è simile al seguente:

Ncat: No connection could be made because the target machine actively refused it. .

Significa che probabilmente non è stato avviato correttamente Stunnel.

TROUBLESHOOTING ERRORI DI CONNESSIONE DAI LOGS DI HAPROXY

Se viene mostrato un errore simile al seguente durante la connessione:

Connection closed by UNKNOWN port 65535

È possibile che stiano avvenendo degli errori durante il TLS handshake e per verificarlo è possibile controllare i logs di HAProxy.

Collegarsi al nodo primario di HAProxy come root ed eseguire il seguente comando per visualizzare i logs:

journalctl -f -u haproxy.service

Se l’handshake fallisce a causa di uno SNI non supportato da HAProxy (ad esempio a causa del dominio del server errato), l’errore nei logs è simile al seguente:

Dec 26 19:24:34 haproxy01 haproxy[332609]: 192.168.1.10:59921 [26/Dec/2025:19:24:34.553] fe_ssh/1: SSL handshake failure (error:0A0000EA:SSL routines::callback failed)

Se, invece, l’handshake fallisce a causa di errore di autorizzazione l’errore nei logs è simile al seguente:

Jan 07 00:57:20 haproxy01 haproxy[1444]: 172.31.67.12:39484 [07/Jan/2026:00:57:18.747] fe_ssh~ be_ssh_all/<NOSRV> -1/-1/+2017 +0 PR 1/1/0/0/0 0/0 dstIP="-" dstName="my-local-server.pizza.local" dn="/DC=local/DC=pizza/OU=Admins/CN=VALLE Marco/emailAddress=marco.valle@pizza.com" emails=[marco.valle@pizza.com]

Mediante le informazioni contenute nel log è possibile verificare la DN e l’email del certificato del client, per poi controllare in seguito che l’utente sia autorizzato dalle ACL di HAProxy.