Ubiquiti Edge Router-X

[frakka]

"Pro" per ora ne vedo pochini e, purtroppo, schiacciati dai contro:

• Quando va, la gui web è piuttosto rapida a reagire
• Ha una dashboard con i grafici della banda utilizzata dalle singole porte;
• Ha un menù per l'analisi del traffico che può essere spento (per risparmiare risorse) e fornisce informazioni che potrebbero essere utili;
• Configurare a mano (anche tramite la GUI web, quando funziona!) permette la flessibilità che volevo. Rotte statiche e Port Forwarding non sono un problema e sembrano funzionare come atteso.
• E' possibile configurare un load balancing tra più connessioni WAN, se disponibili.
• Le 5 porte possono essere configurate come interfacce indipendenti o come membri di una interfaccia switch (quella su cui è attiva la GUI web e che mi sembra non si possa eliminare).
• La parte firewall permette di configurare degli oggetti che contengono diverse entità (IPs, reti, etc....) che poi possono essere richiamati nella configurazione delle regole stesse.

E ora vado a letto! Buonanotte!

[frakka]

Testardo come un mulo, alla fine ho temporaneamente messo il mio serverino direttamente su internet e ho staccato l'ubiquiti per maggiori test.

Ho eseguito l'ennesimo reset del router e sono ripartito da zero, evitando di configurare regole di firewall o ripristinare backup delle configurazioni. Effettivamente, in questo modo la GUI non si è più seduta neppure dopo una notte e un giorno (prima bastava molto meno) quindi una regola sbagliata finiva probabilmente per bloccare l'accesso al router stesso (web ed ssh) ma senza impedire il forwarding.

A questo punto, mi interessa capire se questo apparecchio è in grado di gestire una connessione gigabit oppure no, come sembrerebbe dagli speedtest fatti in precedenza: La risposta breve è no, non con la configurazione di default. Ma, fortunatamente, ci si può lavorare sopra.

[frakka]

Per valutare l'impatto di questo apparecchio su un flusso di dati, devo essere sicuro di quelle che sarebbero le prestazioni sia dell'endpoint che trasmette che di quello che riceve al massimo delle loro capacità.
Per queste valutazioni è difficile se non impossibile usare la rete internet, per ovvi motivi, mentre è molto più semplice ricostruire in locale un ambiente in cui effettuare una simulazione.

Ho realizzato quindi un collegamento di questo tipo:



La prova non è perfetta perchè sia sul pc che sul server ho usato schede di rete diverse per un percorso piuttosto che per l'altro ma non mi interessa ora fare misurazioni scientifiche. Il risultato è comunque interessante:

Percorso di destra, diretto pc/server.

[root@serverino netctl]# iperf3 -c 192.168.150.20 -B 192.168.150.1
Connecting to host 192.168.150.20, port 5201
[ 5] local 192.168.150.1 port 55355 connected to 192.168.150.20 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver

iperf Done.
[root@serverino netctl]# iperf3 -c 192.168.150.20 -B 192.168.150.1 -R
Connecting to host 192.168.150.20, port 5201
Reverse mode, remote host 192.168.150.20 is sending
[ 5] local 192.168.150.1 port 52057 connected to 192.168.150.20 port 5201
[ ID] Interval Transfer Bitrate
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 138 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver

iperf Done.

Bitrate misurato nei due sensi, cioè sia con il server su 192.168.150.1 che invia a 192.168.150.20 che viceversa.

A questo punto, a parità di macchine di destinazione metto in mezzo l'ubiquiti e ripeto il test.
Percorso di sinistra, ripetuto più volte per conferma:

[root@serverino netctl]# iperf3 -c 192.168.1.10 -B 192.168.17.1
Connecting to host 192.168.1.10, port 5201
[ 5] local 192.168.17.1 port 52063 connected to 192.168.1.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 267 MBytes 224 Mbits/sec 89 sender
[ 5] 0.00-10.00 sec 264 MBytes 221 Mbits/sec receiver

iperf Done.
[root@serverino netctl]# iperf3 -c 192.168.1.10 -B 192.168.17.1 -R
Connecting to host 192.168.1.10, port 5201
Reverse mode, remote host 192.168.1.10 is sending
[ 5] local 192.168.17.1 port 41113 connected to 192.168.1.10 port 5201
[ ID] Interval Transfer Bitrate
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 261 MBytes 219 Mbits/sec 78 sender
[ 5] 0.00-10.00 sec 258 MBytes 216 Mbits/sec receiver

iperf Done.

Il crollo della banda è drammatico e, a quanto sembra da internet, non è un problema del mio dispositivo ma è una cosa comune. La porta con IP 192.168.17.110 è la porta WAN in DHCP ma, anche invertendo il flusso e mettendo il server sull'altro dispositivo le cose non cambiano quindi non è un problema magari del firewall attivato dal wizard di configurazione (impostata anche una regola "allow all", sia mai).
Le specifiche del dispositivo parlano di un banda passante da 1Gbit (che, per un apparato con 5 porte non sono affatto molti) ma, per la miseria, qui ho appunto un solo flusso per volta che sta viaggiando all'interno del router. Fortunatamente però ho trovato un video su YouTube in cui suggeriscono di abilitare l'offloading in hardware del NAT sull'apparato.

Percorso di sinistra dopo aver abilitato l'offloading del nat:

[root@serverino netctl]# iperf3 -c 192.168.1.10 -B 192.168.17.1
Connecting to host 192.168.1.10, port 5201
[ 5] local 192.168.17.1 port 38553 connected to 192.168.1.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec 1843 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver

iperf Done.
[root@serverino netctl]# iperf3 -c 192.168.1.10 -B 192.168.17.1 -R
Connecting to host 192.168.1.10, port 5201
Reverse mode, remote host 192.168.1.10 is sending
[ 5] local 192.168.17.1 port 35469 connected to 192.168.1.10 port 5201
[ ID] Interval Transfer Bitrate
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec receiver

iperf Done.

Il video:

[frakka]

Ref: Link

L'hardware offloading è una tecnica che permette di sgravare la CPU di un computer da alcune operazioni connesse con la gestione della rete, delegandole direttamente al sottostante hardware (è presente anche in Windows, ad esempio, nella configurazione della scheda di rete) ma è una feature che non è sempre esente da problemi.
La guida di ubiquiti linkata sopra descrive esattamente il problema che ho incontrato e la soluzione proposta è proprio abilitare l'offloading, purtroppo però non spiega perchè questa opzione non sia abilitata di default.

EdgeOS prevedere diverse tipologie di offloading:


ma non tutte si applicano anche a questa piattaforma, seppure presenti nel firmware (come, d'altra parte, indicato anche nella guida):


Inoltre, delle due tipologie supportate, l'offloading ipsec ha ancora dei bug noti aperti:



Per ora le casistiche che hanno problemi non mi toccano quindi abilito tutto quello che serve e buonanotte.


La guida di ubiquiti suggerisce di abilitare solo gli offloading che servono ma dice che averceli abilitati e non usarli non dovrebbe portare a problemi di prestazioni quindi abilito sia hwnat che ipsec. Per farlo, a quanto mi risulta, l'unico modo è usare la cli del router:

configure

set system offload hwnat enable

set system offload ipsec enable

commit

save

exit
############

hwnat è immediatamente operativo senza necessità di riavviare, ipsec invece è attivo solo dopo il riavvio del router.




[EDIT:]
Sto continuando a cercare di capire come e perchè l'offloading tramite hwnat non sia abilitato di default.
Risposte esplicite non ne ho ancora trovate ma guardando le release note della versione corrente del firmware che ho in uso (2.08) sono stato piuttosto fortunato: La feature aveva diversi bug giusto fino alla versione precedente, al punto che in questa release è stato sostituito il driver utilizzato nelle versione 2.x con un port della versione in uso con il firmware 1,10.9
Vabbè: In soldoni, hwnat funziona alla grande ma potrebbero insorgere dei problemi quindi il funzionamento o l'usabilità della feature non sono garantiti.

[frakka]

Finalmente, dopo diversi tentativi, sono riuscito a venire a capo del problema che avevo col firewall e a creare almeno le regole di base.

Il problema che riscontravo, probabilmente un'ingenuità dovuta al fatto che non mi occupo normalmente di questi apparecchi, era dovuto a un'incomprensione di "verso" nell'interpretare quando il traffico è "IN" e quando è "OUT" per una regola di firewall.

Esempio:
Riprendo l'immagine postata in precedenza, che rappresenta come sto organizzando la mia rete di casa.



La rete ospiti deve rimanere isolata nel senso che il router gli deve fornire solo accesso ai servizi DHCP e DNS (o tramite il servizio di DNS forwarding con caching delle query offerto dal router o lasciando passare le query DNS verso internet, non ho ancora deciso) ed i client devono poter uscire (per ora) liberi verso internet. E' però necessario che i client registrati sulla rete ospiti non possano in alcun modo accedere all'interfaccia web del router stesso oppure ai pc/servizi presenti nella mia rete privata o nella rete del laboratorio.

Il so del router permette di configurare le regole di firewall solo all'interno di "ruleset" contenti le singole regole a cui deve essere associata almeno un'interfaccia di rete a cui applicare la regola ed il verso in cui la regola deve essere valutata (IN, OUT o LOCAL). Le policy del firewall diventano attive solo nel momento in cui viene loro associata almeno una interfaccia e una direzione, altrimenti le regole rimanono lì ma non sono operative.

Queste le "ruleset" che ho configurato finora:


E queste sono le rules configurate all'interno della ruleset WIFI-OSPITI_to_LAN



Per ottenere il risultato descritto in precedenza, configuravo una ruleset "WIFI-OSPITI_to_LOCAL" per i servizi DHCP e DNS assocìata all'interfaccia "eth3.120/local" e una ruleset "eth3.120/out" che aveva all'interno delle rules per bloccare il traffico in uscita dalla rete ospiti verso le reti da proteggere... Ecco: Questa regola è da creare sull'interfaccia eth3.120 ma con direzione "IN" e non "OUT" come la stavo facendo.

Ref.

IN traffic entering the router from an interface (and later exiting via another interface)
OUT traffic exiting the router to an interface (previously entered via another interface)
LOCAL traffic entering the router and destined to router itself

Quindi il verso in cui leggere le regole è, sostanzialmente, inverso rispetto a quello che stavo considerando io: Brutta cosa essere niubbi!


A questo link c'è un utile post nella community di ubiquiti che parla proprio del firewall su EdgeOS.

[frakka]

Per quanto la regola configurata per l'isolamento della rete ospiti funzioni bene, avere come azione predefinita "Allow all" su una regola di firewall non è propriamente il massimo. E' una questione di comodità, dato che non c'è la possibilità di creare una regola che permetta di accedere a tutte le rete IPv4 "tranne" alcune specifiche in una sola regola ma non è comunque bello.

Ho quindi pensato di modificare la regola per impostare come action predefinita un "Deny all" e permettere solo il traffico http/https/email dalla rete ospiti verso internet e bloccare il resto. La nuova regola, sempre applicata all'interfaccia eth3.120/IN e che quindi sostituisce la precedente (una ruleset può essere associata a più interfacce ma una interfaccia può essere associata a una ed una sola ruleset) diventa così:



Come prima cosa, autorizzo solo il traffico verso la porta 80 e 443 del mio serverino domestico (c'è una pagina web che uso per test di raggiungibilità e niente altro), poi inserisco due regole di DROP per impedire il traffico verso la mia rete privata e verso la rete del laboratorio. Segue poi una regola che autorizza il traffico DNS: Dato che viene dopo il "drop" presente per la mia rete locale, il client ospiti non potranno usare il DNS presente sul mio serverino ma solo server DNS da internet.
Chiudo poi con due regole (che potrebbero essere condensate in una) che permettono l'accesso a siti web e ai protocolli di posta che non siano già stati negati in precedenza.

Ho testo la regola con NMAP e sembra funzionare correttamente.

Con questa configurazione è possibile navigare internet, usare APP come Netflix e Infinity ed usare un client di posta per inviare e ricevere email o connettersi all'app di Fibaro per la domotica ma, ad esempio, ci si riesce a connettere alla APP di Foscam e ad un'altra applicazione di gestione di telecamere per videosorveglianza ma non al flusso video delle telecamere stesse che, evidentemente, gira su porte diverse.

Verificato che non è possibile raggiungere ne gli host sulle altre reti ne l'interfaccia web del router steso.
Per ora, va bene così.


TODO:
Capire se questo router mette a disposizione un log per capire quale traffico viene droppato dalle regole.

[frakka]

E' una cosa molto frequente nei sistemi unix-based: Per accedere in ssh alla consolle della macchina, invece che usare username e password si importa nel profilo dell'utente remoto la chiave pubblica di una coppia di chiavi ssh. In questo modo, si può accedere alla risorsa remota senza necessità di digitare la password, se si è in possesso della chiave privata.

[matteo@arch .ssh]$ ssh matteo@router
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

Linux EdgeRouter-X-5-Port 4.14.54-UBNT #1 SMP Wed Nov 20 11:30:55 UTC 2019 mips
Welcome to EdgeOS
Last login: Thu Jan 30 10:31:54 2020 from 192.168.1.254
matteo@EdgeRouter-X-5-Port:~$ configure 
[edit]
matteo@EdgeRouter-X-5-Port# loadkey matteo matteo@arch
Done
[edit]
matteo@EdgeRouter-X-5-Port# save
Saving configuration to '/config/config.boot'...
Done
[edit]
matteo@EdgeRouter-X-5-Port# exit
exit
matteo@EdgeRouter-X-5-Port:~$ exit
logout
Connection to router closed.

In questo caso, è necessario copiare sul router un file contenente la (o le) chiavi ssh da importare nel profilo dell'utente (effettivamente potrebbero essere più d'una e si possono importare in una volta sola) e, dalla shell di configurazione, digitare il comando:

 loadkey utente percorso/nomefile

Concludendo la procedura con "save;exit;exit" per salvare la conf e uscire.
Le chiavi inserite nel profilo in questo modo vengono esportate e ripristinate insieme al backup della configurazione del router.

Il file usato per importare le chiavi può adesso essere cancellato.

[Matty90]

E' una cosa molto frequente nei sistemi unix-based: Per accedere in ssh alla consolle della macchina, invece che usare username e password si importa nel profilo dell'utente remoto la chiave pubblica di una coppia di chiavi ssh. In questo modo, si può accedere alla risorsa remota senza necessità di digitare la password, se si è in possesso della chiave privata.

[matteo@arch .ssh]$ ssh matteo@router
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

Linux EdgeRouter-X-5-Port 4.14.54-UBNT #1 SMP Wed Nov 20 11:30:55 UTC 2019 mips
Welcome to EdgeOS
Last login: Thu Jan 30 10:31:54 2020 from 192.168.1.254
matteo@EdgeRouter-X-5-Port:~$ configure 
[edit]
matteo@EdgeRouter-X-5-Port# loadkey matteo matteo@arch
Done
[edit]
matteo@EdgeRouter-X-5-Port# save
Saving configuration to '/config/config.boot'...
Done
[edit]
matteo@EdgeRouter-X-5-Port# exit
exit
matteo@EdgeRouter-X-5-Port:~$ exit
logout
Connection to router closed.

In questo caso, è necessario copiare sul router un file contenente la (o le) chiavi ssh da importare nel profilo dell'utente (effettivamente potrebbero essere più d'una e si possono importare in una volta sola) e, dalla shell di configurazione, digitare il comando:

 loadkey utente percorso/nomefile

Concludendo la procedura con "save;exit;exit" per salvare la conf e uscire.
Le chiavi inserite nel profilo in questo modo vengono esportate e ripristinate insieme al backup della configurazione del router.

Il file usato per importare le chiavi può adesso essere cancellato.

Comodo, ma non mi é mai piaciuto più di tanto.

A proposito di autenticazione, io sto provando ad associarlo ad un server radius. Per ora non sembra funzionare, ma la battaglia é appena iniziata

Inviato dal mio CLT-L29 utilizzando Tapatalk

[frakka]

A proposito di autenticazione, io sto provando ad associarlo ad un server radius. Per ora non sembra funzionare, ma la battaglia é appena iniziata

Credo che il radius sia previsto solo per l'autenticazione degli utenti VPN ma non ho approfondito.

[frakka]

Il wol è quella feature che permette di risvegliare da remoto un computer che è stato spento, cosa indispensabile per me visto che il PC lab sta in cantina e mi capita spesso di doverlo accendere dall'ufficio.

Il "Wake On Lan" prevede l'invio di un pacchetto di rete ad hoc, tipicamente sulla porta 9 UDP, destinato al MAC address della scheda di rete da risvegliare. La scheda di rete del computer "dormiente" rimane di fatto accesa, annuncia il proprio MAC alle porte dello switch a cui è collegata e rimane in ascolto, in attesa di ricevere il "magic packet".

Ma dato che il computer in stato dormiente è effettivamente spento, la sua scheda di rete non ha un IP assegnato: Perchè possa ricevere comunque il magic packet o si mette in mezzo un dispositivo che sa a quale porta dello switch inviare il pacchetto anche se il computer ricevente è spento (tipicamente una cache dei MAC address visti su una determinata porta) oppure si può inviare il pacchetto all'indirizzo di broadcast di una rete in modo che venga ricevuto da tutti i computer collegati a quella network.

Quindi, quando tutti i computer fanno parte della stessa rete il discorso è relativamente semplice: E' sufficiente inviare il pacchetto corretto all'indirizzo di broadcast della rete (che quindi viene distribuito verso tutti gli IP della rete) e, se il pc ricevente è configurato in modo acconcio, dovrebbe accendersi. Questa è la configurazione che avevo nella vecchia topografia di rete perchè il pc del laboratorio aveva una zampa anche nella rete di casa (e comunque era il serverino stesso il gateway tra le due reti) quindi dal serverino potevo risvegliare ogni pc che si trovasse in una delle due reti semplicemente inviando il magic packet all'indirizzo di broacast corrispondente.

Nella nuova topografia questa zampa non c'è più e già da diversi anni la maggior parte dei router non effettua più il forwarding dei pacchetti agli indirizzi di broacast perchè questa pratica si presta a facili attacchi DoS. Quindi non posso dal serverino inviare un magic packet all'indirizzo di broadcast del laboratorio perchè, essendo su una rete diversa, il router non ne farebbe il forwarding.
Potrei inviare il magic packet direttamente dal router collegandomi in ssh ma non mi pare che abbia un software wol disponibile (da quello che ho visto in alcune guide si potrebbe anche installare).


La soluzione, in questo caso, è configurare delle entry statiche nel router per cui al MAC address del pc da risvegliare si assegna un indirizzo IP (anche e preferibilmente inutilizzato) sulla stessa rete.

ES:
La rete del laboratorio è la 192.168.100.0/24 (il suo indirizzo di broadcast sarebbe quindi 192.168.100.255).
Ammettiamo che in questa rete ci sia un server DHCP che distribuisce gli IP da 192.168.100.101 a 192.168.100.200: Gli IP da .1 a .100 e quelli da .201 a .254 sono quindi disponibili per l'assegnazione di IP statici. Nel mio caso, uso le reservation DHCP per fare in modo che alle schede di rete siano assegnati sempre gli stessi IP, in particolare quelli da 101 e 105, ma non è strettamente necessario per il funzionamento del WOL.
Dal menù "Config tree / protocols / static / arp : Static ARP translation" posso impostare nel router un'associazione permanente tra indirizzo IP e uno specifico MAC address. Io ho usato l'IP "vero" da associare al MAC perchè so non essere assegnabile ad altre schede di rete in quanto riservato ma, in generarle, avrei potuto associarlo a qualunque indirizzo IP non utilizzato nel range da .1 a .100 e da .201 a .254 citati in precedenza.



In questo modo, il serverino invia il magic packet per risvegliare la scheda di rete "b4:2e:99:3b:54:d4" all'indirizzo 192.168.100.101. Il pacchetto arriva al router ubiquiti in quanto gateway della rete del serverino verso 192.168.100.0/24 e che, non essendo il pacchetto destinato a un IP di broadcast, lo tratta come un normale pacchetto di rete in ingresso, girandolo verso la porta che guarda al laboratorio.
A quel punto, essendo arrivato il pacchetto su una porta corrispondente alla stessa network dell'IP di destinazione, deve poter essere destinato ad uno specifico MAC address: Quando i computer sono accessi, questa associazione avviene tramite tabelle dinamiche che i computer e gli apparati di rete si tengono in pancia ma essendo il computer spento ecco che entra in gioco l'associazione statica creata prima. Il router sa che all'IP 192.168.100.101 corrisponde il MAC "b4:2e:99:3b:54:d4" quindi invia il pacchetto allo switch che lo smista sulla porta in cui il MAC b4:2e:99:3b:54:d4 si annuncia.

Facile, no?


Il giochino tipicamente si rompe se il pc "dormiente" si disalimenta del tutto (in questo caso, solitamente anche quando torna la corrente la scheda di rete non rimane più in attesa del magic packet fino al successivo power cycle) oppure se particolari funzionalità avanzate (Es: risparmio energetico) interferiscono con il mantenere la scheda di rete in ascolto.

Il WakeOnLan quindi deve essere abilitato sicuramente a livello di sistema operativo nel driver della scheda di rete e nel bios della scheda madre, se prevedono queste possibilità, Nel mio caso, avendo il lab due sistemi operativi diversi, entrambi devono avere il wol abilitato sulla scheda di rete.

Prima prova: Invio il magic packet e non succede nulla. Sgrunt.
Seconda prova: Ricontrolla la logica, le regole di firewall sul router e creane una ad hoc che conti i pacchetti che sono passati, per vedere se effettivamente fanno il giro giusto. Lo fanno, doppio sgrunt.
Terza prova: Da Linux, TCPDUMP sul computer del lab, invio i magic packet e li vedo entrare correttamente. Spengo il PC, rimando il magic packet e si accende. UAO! Perchè non andava prima?
Quarta prova: Il pc si è riavviato in Windows, spengo il PC, rimando il magic packet e niente... Bestemmia.

Il giro effettivamente funziona ma se il computer si spegne da Windows il wol non funziona più mentre se spengo il PC da Linux tutto bene.

Un pomeriggio brigare tra impostazione dei driver, risparmio energetico e Google, per poi scoprire che il problema è l'opzione "Avvio rapido" configurata nelle impostazioni del profilo energetico. Sapevo che poteva essere un problema (forse non con hw perfettamente UEFI compliant ma la mia scheda video è vecchia e funziona solo con il CSM abilitato) ed infatti nel bios lo avevo disabilitato ma c'è un'opzione stupida anche nei meandri di Windows...

Nello specifico, per trovarla il percorso è questo:
"Pannello di controllo\Tutti gli elementi del Pannello di controllo\Opzioni risparmio energia" -> Dai link sulla sinistra "Specifica cosa avviene quando si preme il pulsante di alimentazione -> Modifica le impostazioni attualmente non disponibili" (che adesso passano da essere sgrigiate a essere selezionabili) e TOGLIERE la spunta da "Attiva avvio rapido".
Questa opzione non è però sempre disponibile...



Ad esempio, sul mio computer di casa con scheda madre ASUS non c'è mentre nel pc LAB sempre con Windows 10 ma mobo Gigabyte è presente.

Disattivata quella, il wol ha preso a funzionare come atteso!