TIM HUB+ Huawei DN8245X6-8X: il range DHCP condiziona l'accesso a Internet

La sostituzione di un router in una rete già esistente dovrebbe essere, almeno in teoria, un'operazione abbastanza semplice: si assegna al nuovo apparato lo stesso indirizzo LAN del precedente, si replica la configurazione DHCP e si collegano gli switch.

Con il TIM HUB+ Huawei DN8245X6-8X, tuttavia, ci siamo imbattuti in un comportamento piuttosto poco intuitivo che può creare parecchia confusione in reti dove convivono client DHCP e dispositivi con indirizzo IP statico.

Il problema, una volta individuato, è facile da aggirare. Capire cosa stesse succedendo lo è stato molto meno.

 

Configurazione di partenza

La rete utilizzava:

• LAN: 192.168.1.0/24
• Gateway: 192.168.1.1
• DHCP: 192.168.1.20 - 192.168.1.90

Alcuni dispositivi, soprattutto server e altre macchine che devono mantenere un indirizzo noto, utilizzavano invece IP statici al di fuori del pool DHCP, per esempio:

• 192.168.1.99
• 192.168.1.253

È una configurazione del tutto comune. Normalmente ci si aspetta che il pool DHCP determini semplicemente quali indirizzi il router può assegnare automaticamente, mentre il NAT verso Internet venga applicato all'intera rete 192.168.1.0/24.

Sul DN8245X6-8X provato, però, le cose non sono andate così.

TIM documenta la possibilità di configurare il server DHCP e di creare associazioni statiche tra nome, MAC address e indirizzo IP, ma la documentazione pubblica non chiarisce il comportamento della voce Intervallo IP NAT presente nell'interfaccia del router.

 

Il sintomo

Dopo aver sostituito il precedente gateway con il nuovo Huawei, alcuni computer navigavano normalmente, mentre altri no.

La situazione era apparentemente contraddittoria:

• 192.168.1.29 → Internet OK
• 192.168.1.99 → Internet KO
• 192.168.1.253 → Internet KO

Gli host problematici riuscivano però a raggiungere perfettamente il router:

• ping 192.168.1.1 OK
• ping 8.8.8.8 KO

Quindi:

• Ethernet funzionava;
• ARP funzionava;
• la subnet era corretta;
• il gateway era raggiungibile;
• il problema non era DNS, dato che falliva anche il ping diretto ad un indirizzo IP pubblico.

Il traffico si fermava sostanzialmente al router.

 

L'indizio decisivo

C'era una correlazione molto sospetta:

• Pool DHCP: 192.168.1.20 - 192.168.1.90
• 192.168.1.29 → dentro il pool → Internet OK
• 192.168.1.99 → fuori dal pool → Internet KO
• 192.168.1.253 → fuori dal pool → Internet KO

L'interfaccia del router contiene inoltre una sezione denominata Intervallo IP NAT, i cui limiti risultano vincolati all'intervallo DHCP impostato.

In generale una policy NAT può certamente essere limitata in funzione dell'indirizzo IP sorgente: Huawei documenta esplicitamente NAT policy che selezionano o escludono determinati indirizzi e intervalli. Il punto insolito non è quindi la possibilità tecnica di farlo, ma il modo in cui tale comportamento viene esposto e collegato alla configurazione DHCP in questo firmware.

Per eliminare ogni possibile interferenza della rete aziendale, abbiamo isolato completamente il nuovo router.

Collegando direttamente un notebook via Ethernet e gli abbiamo assegnato:

• IP: 192.168.1.99
• Mask: 255.255.255.0
• Gateway: 192.168.1.1
• DNS: 8.8.8.8

Risultato:

• ping 192.168.1.1 OK
• ping 8.8.8.8 KO
• navigazione KO

Abbiamo quindi modificato soltanto l'indirizzo IP del notebook a 192.168.1.89, lasciando invariati mask, gateway, DNS, cavo ed ogni altra impostazione.

Risultato:

• ping 192.168.1.1 OK
• ping 8.8.8.8 OK
• navigazione OK

192.168.1.89 apparteneva al range DHCP .20-.90; .99 no. A quel punto il comportamento era sufficientemente isolato da escludere switch, server DHCP esterni, cablaggio, DNS e configurazioni della precedente infrastruttura.

 

La soluzione

Abbiamo esteso il range configurato sul router a 192.168.1.2 - 192.168.1.254 ed utilizzato la funzione di IP statico/prenotazione MAC-IP del per gli apparati che devono conservare un indirizzo preciso.

Per esempio:

• SERVER → 192.168.1.250
• altro PC → 192.168.1.99

TIM documenta ufficialmente questa possibilità nella sezione: Avanzate → LAN → IP statico dove è possibile associare nome, MAC address e IP.

Dopo l'estensione dell'intervallo e la creazione delle relative prenotazioni, anche un host con IP configurato manualmente ha iniziato a navigare normalmente.

La configurazione finale deve quindi essere inequivocabile:

Anche l'opzione Inoltro DHCP del Huawei va normalmente lasciata disabilitata quando il router stesso serve direttamente i client della medesima subnet.

 

Perché questo comportamento è sorprendente?

DHCP e NAT sono normalmente due funzioni concettualmente indipendenti.

Il DHCP risponde alla domanda "Quali indirizzi IP posso assegnare automaticamente ai client?". Il NAT risponde invece a "Quale traffico proveniente dalla LAN devo tradurre verso l'indirizzo pubblico?"

In una comune LAN 192.168.1.0/24 è perfettamente normale utilizzare:

• 192.168.1.20 - .90 DHCP
• 192.168.1.100 - .254 indirizzi statici

aspettandosi che entrambi i gruppi possano raggiungere Internet.

Le piattaforme Huawei possono tecnicamente applicare NAT in funzione dell'indirizzo sorgente, quindi non c'è nulla di scorretto nel meccanismo in sé.

Ciò che consideriamo poco intuitivo nel firmware TIM provato è piuttosto:

• la relazione tra range DHCP e host ammessi al NAT;
• il vincolo dell'"Intervallo IP NAT" al range DHCP;
• la scarsa spiegazione di questo comportamento nella documentazione pubblica;
• il fatto che un host fuori range continui a raggiungere perfettamente il router, facendo inizialmente pensare a problemi completamente diversi.

Il TIM HUB+ Huawei DN8245X6-8X si è rivelato, una volta configurato correttamente, perfettamente utilizzabile anche in una LAN preesistente con server e altri dispositivi ad indirizzo fisso.

L'incubo della condivisione file su Windows 11: quando un SID duplicato manda tutto in tilt

Può sembrare un'operazione banale: due PC sulla stessa rete, una cartella condivisa, qualche clic e via. 

Eppure, a volte Windows decide che la semplicità è sopravvalutata. Di recente ci siamo trovati intrappolati in una situazione paradossale: due macchine Windows 11 perfettamente configurate che, nonostante tutto, rifiutavano di autenticarsi fra loro.

La soluzione era nascosta in un dettaglio invisibile, ereditato da un'installazione clonata troppo in fretta.

Rimbalzo continuo fra errori incomprensibili

L'ambiente era lineare: due PC con nomi diversi, IP diversi e condivisioni SMB configurate con attenzione. Eppure Windows insisteva con lo scoraggiante messaggio: "Il nome utente o la password non sono corretti".

Richieste di credenziali ripetute all'infinito, come se qualunque password fosse sbagliata per definizione.

Controllati firewall, credenziali, servizi di rete; resettato quel che poteva essere resettato. Nulla.

La rete funzionava: i PC si vedevano, ma l'autenticazione era un muro.

Scavare nei log è uno sporco lavoro... che ripaga

La svolta è arrivata guardando dove Windows parla senza filtri: nel Visualizzatore Eventi.
Sotto `Log di Windows → Sistema` è spuntato l'indizio decisivo: un evento 6167 del servizio `LsaSrv`.

Il messaggio era tecnico ma rivelatore:

"Il fornitore di supporto sicurezza Kerberos ha rilevato una parziale corrispondenza nell'ID macchina… Ciò può verificarsi se l'immagine del sistema operativo di destinazione è stata clonata…"

Quelle due parole, parziale corrispondenza, erano tutto ciò che serviva per capire che il problema non era la rete, ma l'identità delle macchine.

Il colpevole

Tutto risaliva ad una vecchia immagine disco che qualcuno aveva clonato per velocizzare l'installazione (saltando però un passaggio importante, usare `sysprep /generalize`, che rigenera il SID, cioè l'identificatore univoco del sistema).

Il risultato? Le due macchine erano, dal punto di vista di Windows, indistinguibili.

Per anni questo non era stato un problema: Windows tendeva a chiudere un occhio. Ma con gli aggiornamenti di sicurezza rilasciati dopo l'agosto 2025, il controllo è diventato molto più rigoroso. Ora due PC con la stessa identità non vengono più autenticati, neanche in una semplice rete domestica.

Di fatto, ciascun PC diceva all’altro: "Non posso autenticarti, perché… sembri me".

La soluzione è un dilemma

Il modo "ufficiale" per risolvere un SID duplicato è eseguire sysprep /generalize su almeno uno dei sistemi, facendo rigenerare l'identità al PC. Il rovescio della medaglia è che `sysprep` ripristina vari aspetti del sistema e richiede una riconfigurazione quasi completa.

Per evitare questo reset esistono strumenti di terze parti, come SIDCHG, che tentano di modificare il SID. Funzionano ma non sono riconosciuti da Microsoft... quindi bisogna usarli con consapevolezza (qualsiasi cosa significhi :).

Gli errori fatti in fase di installazione possono restare silenziosi per anni, salvo poi riemergere al momento meno opportuno. A volte il vero bug non è in Windows ma in ciò che abbiamo fatto noi molto tempo prima.