Creare e gestire in sicurezza gli utenti guest su Sophos Firewall

Con i Guest users, Sophos Firewall crea account temporanei per persone prive di un account utente regolare. Questo modello è adatto, per esempio, a visitatori, tecnici esterni o partecipanti a un corso che devono autenticarsi tramite Captive Portal e ricevere soltanto un accesso Internet chiaramente limitato.

Il percorso rapido e sicuro è il seguente:

1. Preparare un gruppo guest restrittivo con le policy necessarie.
2. In Authentication > Guest user settings, definire prefisso, gruppo, password e pulizia.
3. Decidere se un amministratore deve creare account singoli o multipli oppure se la registrazione autonoma con SMS è davvero necessaria.
4. Impostare la validità su Immediately o After first login e consegnare le credenziali in modo protetto.
5. Testare Captive Portal, regola utente, segmentazione della rete, una destinazione consentita e una bloccata.
6. Disattivare o rimuovere l’account dopo la scadenza e verificare separatamente le sessioni esistenti e i log.

⚠️ Un account guest è soltanto un’identità. Non segmenta la rete e non apre un percorso dati. Gli ospiti devono trovarsi in una zona o VLAN dedicata e avere una regola firewall restrittiva con logging. Credenziali, stampe e SMS devono essere trattati come password.

Distinguere utenti guest, voucher e utenti normali

Un utente guest è un record utente locale temporaneo. Il firewall genera Username e password in base alle impostazioni globali degli utenti guest. Dopo l’accesso può associare il traffico a questa identità e applicare le policy del gruppo selezionato.

Gli altri modelli di accesso risolvono esigenze diverse:

• Utente locale o esterno normale: adatto a utenti abituali con un account permanente, una fonte utenti centrale o MFA. Creare e gestire utenti locali normali spiega il modello gestito direttamente sul firewall.
• Guest user: adatto a una persona che necessita di accesso temporaneo con un proprio account, validità individuale e controllo opzionale dell’utilizzo.
• Hotspot Voucher: è un codice per un Wireless Hotspot. Validità del voucher, tempo online, volume dati e numero di dispositivi sono gestiti nel modello Hotspot. La configurazione è descritta in Configurare un Hotspot Sophos Firewall con voucher o password giornaliera.
• Clientless User: associa un indirizzo IP fisso a un dispositivo senza che una persona effettui l’accesso. La procedura è descritta in Configurare i Clientless Users su Sophos Firewall.

Gli utenti guest non sono destinati al Remote Access SSL VPN o all’IPsec Remote Access. La policy SSL VPN attuale non consente Guest users o Guest groups come Policy members. Per il Remote Access si utilizza un utente normale proveniente da una fonte locale o esterna adeguata. La configurazione VPN completa è spiegata in Configurare SSL VPN Remote Access.

La pagina attuale della guida SFOS 23 Edit guest user elenca ancora i campi SSL VPN e IPsec Remote Access. Tuttavia, le pagine SFOS 23 dedicate alle policy SSL VPN e alle impostazioni IPsec escludono esplicitamente Guest users e Guest groups da questi due metodi di accesso remoto. È una contraddizione documentale irrisolta all’interno della stessa versione, non un cambiamento di versione dimostrato. Questi campi non provano che l’accesso VPN per gli ospiti sia supportato; per SSL VPN e IPsec resta consigliato un utente normale. Queste esclusioni non permettono di stabilire l’idoneità degli ospiti per Clientless SSL VPN, L2TP o PPTP; tali parti della pagina Edit restano da chiarire.

La stessa contraddizione esiste nelle pagine della guida SFOS 22. Le pagine Edit di entrambe le versioni descrivono anche segnalibri del browser per Clientless SSL VPN policy e indirizzi IP assegnati facoltativi per IPsec remote access, L2TP e PPTP. Queste descrizioni dei campi non autorizzano ad attivare tali metodi per gli ospiti. Per l’accesso Internet descritto qui non si aggiungono permessi di accesso remoto. Un’esigenza VPN separata viene soddisfatta con un utente normale e la procedura VPN appropriata; le opzioni guest non chiarite non vengono attivate sperimentalmente in produzione.

Configurazione di esempio e prerequisiti

L’esempio seguente usa una rete guest separata e un account per una visita di un giorno:

• Zona: Guest
• Rete: 10.30.40.0/24
• Nome del portale: login.example.com
• Gruppo guest: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 è una rete privata di esempio e va sostituita con la rete guest reale. login.example.com è un nome di documentazione. Va sostituito con un FQDN che, dalla rete guest, si risolva nell’indirizzo raggiungibile del firewall e sia coperto dal certificato del portale. Al gruppo vengono assegnate soltanto le policy realmente previste per questo accesso guest.

Prima della creazione devono essere soddisfatti questi prerequisiti:

1. Rete guest, DHCP, DNS, routing e NAT sono stati verificati con una regola di test temporanea e strettamente limitata. Questa regola viene rimossa prima del test di autenticazione; una regola DNS separata deve consentire solo il traffico necessario verso il resolver.
2. Le reti interne e i servizi di gestione sono bloccati dalla zona guest.
3. Il Captive Portal è raggiungibile solo dalla zona prevista.
4. Un gruppo dedicato riunisce Access Time, quote, Traffic Shaping e Sign-in Restriction.
5. Un accesso amministrativo e un percorso di gestione indipendente restano disponibili durante il test.
6. Consegna, scadenza, revoca e conservazione delle credenziali guest sono definite a livello organizzativo.

Definire le impostazioni globali degli utenti guest

Prima del primo account, aprire:

Authentication > Guest user settings

Questi valori fungono da modello per i nuovi account guest. Una modifica al modello va quindi verificata prima con un account di test.

Scegliere General settings sicure

In Guest user general settings si definiscono i campi seguenti:

1. Username prefix: nell’esempio guest-. Un prefisso neutro è preferibile a nomi di aziende, sedi o clienti che rivelano informazioni inutili.
2. Group: selezionare Guest_Internet. Gli utenti guest ereditano le policy di questo gruppo.
3. Password length: nell’esempio 16. Sophos consente al massimo 50 caratteri sia per lo Username sia per la password nel Captive Portal. La lunghezza deve essere abbastanza robusta e utilizzabile in modo affidabile attraverso il canale di consegna previsto.
4. Password complexity: scegliere l’opzione più forte compatibile con la consegna e il processo di accesso.
5. Disclaimer: questo testo viene stampato sotto le credenziali generate. Indicare brevi condizioni d’uso, responsabilità e un contatto. Non includere credenziali reali o dettagli tecnici interni. Configurare l’avviso di accesso e i messaggi su Sophos Firewall spiega la gestione globale dei testi di amministrazione, autenticazione, SMTP e SMS.
6. Auto purge on expiry: attivare solo se i record degli utenti guest scaduti devono essere rimossi automaticamente e la documentazione operativa è garantita altrove.
7. Salvare con Apply.

Auto purge on expiry elimina i dettagli dell’utente guest dopo la scadenza, non i log associati. Questo è importante per la protezione dei dati e il troubleshooting: la pulizia dell’account e la conservazione dei log sono due processi separati.

Gestire in sicurezza i gruppi di utenti su Sophos Firewall spiega come interagiscono group policies, Main Group e override dell’utente. Per gli ospiti, il gruppo predefinito non dovrebbe essere usato per comodità. Un gruppo restrittivo dedicato rende più chiari gli effetti delle impostazioni e le operazioni di rollback.

Per l’automazione tramite API: La documentazione API di SFOS 22 e 23 limita UserNamePrefix a 10 caratteri; guest- rispetta questo limite. È un vincolo documentato dell’API, non una prova della validazione in ogni versione dell’interfaccia grafica. La lunghezza della password consigliata resta 16. Prima di una modifica, leggere le impostazioni attuali e verificare con un solo account pilota le credenziali realmente generate, il gruppo e la validità.

Gli esempi API non sono del tutto coerenti: PasswordComplexity usa valori simbolici nell’esempio, ma una definizione di tipo intero nella tabella degli attributi; AutoPurgeOnExpiry riporta Enable/Disable nell’esempio, ma soltanto Enable nella tabella. Non indovinare questi valori. Prima di una scrittura tramite API, chiarire lo schema supportato dalla versione specifica del firewall; altrimenti utilizzare i campi documentati dell’interfaccia grafica. I valori predefiniti e i vincoli sul numero di cifre dell’API non definiscono valori predefiniti o limiti di validità universali per l’interfaccia grafica.

Attivare la registrazione autonoma solo se realmente necessaria

In Guest user registration settings si può attivare la registrazione autonoma. È più complessa della consegna controllata da parte di un amministratore o della reception e richiede un processo SMS affidabile:

• Enable guest users registration: attivare solo se gli ospiti devono registrarsi autonomamente.
• SMS gateway: selezionare il provider testato in precedenza.
• Guest username: usare il numero di cellulare oppure generare il nome dallo Username prefix.
• User validity: definire la validità massima per gli account autoregistrati in giorni.
• Default country code: scegliere un valore adeguato agli utenti reali. Questo valore predefinito viene visualizzato accanto al campo del numero di cellulare nella pagina di registrazione degli ospiti.
• CAPTCHA verification: lasciare attivo per ostacolare le registrazioni automatizzate.
• Salvare con Apply.

Il firewall supporta gateway SMS basati su HTTP e HTTPS. Consigliamo HTTPS affinché credenziali e parametri del provider non siano trasmessi senza cifratura. URL, metodo HTTP, formato del numero di cellulare, parametri della richiesta e formato della risposta devono corrispondere esattamente alla documentazione del proprio provider SMS. Gli URL di esempio di una guida non devono essere copiati in produzione.

Test connection invia un messaggio di prova a un numero di cellulare. Secondo Sophos, con un gateway SMS privato che usa un indirizzo IP interno questo test può fallire anche se il flusso reale funziona. In quel caso non si presume semplicemente il successo, ma si verifica l’intera registrazione con un dispositivo mobile, il log del provider e l’SMS effettivamente ricevuto.

Mappare correttamente i parametri del gateway SMS

In Authentication > Guest user settings > SMS gateway > Add, inserire Name, URL, HTTP method con Get o Post, Cell number format ed eventualmente Use country code with mobile phone number e Number prefix. La guida dell’interfaccia grafica descrive Number prefix come compatibile con caratteri alfanumerici e speciali ASCII. Non è una garanzia generale per l’API: il suo campo CellNumberPreFix esclude esplicitamente le virgole.

Ogni parametro della richiesta contiene Name e Value; SFOS sostituisce {mobileno} e {msg} con il numero di cellulare e il messaggio. Per la risposta, associare Parameter index e Name al Response format. I nomi dei parametri non sono definiti da SFOS e devono corrispondere esattamente al provider. Questo schema utilizza esclusivamente valori di esempio riservati:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

Sostituire sms.example.net, mobile, message e status con i valori del provider SMS reale. Get richiede la risorsa indicata; Post invia dati da elaborare. Il metodo si sceglie in base all’API del provider, non a una preferenza generale. I caratteri speciali nei valori URL richiesti dal provider devono essere codificati percentualmente, ad esempio @ come %40. Le credenziali nell’URL o nella richiesta sono segreti e non devono comparire in screenshot, ticket o log. Se il provider le richiede, utilizzare esclusivamente HTTPS e documentarne la scadenza.

Response format descrive soltanto come interpretare la risposta. Nell’esempio della documentazione, una risposta come status=302&message=Limit Exceeded indica il superamento di un limite, non l’invio riuscito dell’SMS. Verificare lo stato di successo o errore secondo la documentazione del provider e controllare la ricezione effettiva. Salvare prima il gateway con Save, quindi eseguire Test connection con un numero di cellulare controllato.

Vincoli API e parametri duplicati: Per SFOS 22 e 23, l’API documenta un massimo di 100 caratteri senza virgole per il Name del gateway e un massimo di 255 caratteri per ResponseFormat. Questi vincoli riguardano l’API e non vanno trasferiti automaticamente all’interfaccia grafica. Le voci duplicate di ParameterName e ParameterValue negli elenchi di richiesta e risposta non vengono ignorate. Controllare ogni coppia nome/valore per individuare duplicazioni accidentali; mantenere ripetizioni intenzionali solo se richieste dal provider. Questo non stabilisce come il provider le interpreti né implica l’invio automatico di più SMS. La tabella URL dell’API cita anche FTP e indirizzi IPv4, mentre la guida dell’interfaccia grafica descrive HTTP/HTTPS. Ciò non estende questa guida a FTP o al trasporto non cifrato: per i segreti utilizzare esclusivamente HTTPS. Uno stato di operazione API 200 non sostituisce la ricezione effettiva dell’SMS né un test completo di registrazione. Utilizzare un numero di prova controllato con consenso; sono possibili costi del provider.

In Administration > Messages > SMS customization, selezionare Edit, inserire un messaggio conforme al template accettato dal provider e salvarlo con Apply. Per il testo del messaggio sono disponibili {username}, {password} e {expirydate}. Questo passaggio salva il messaggio separatamente. Un template non conforme può causare il rifiuto del messaggio da parte del provider e il fallimento di Test connection.

Il test del provider è solo una verifica parziale: nel pilot un ospite si connette al Wi-Fi guest, apre Register for internet access, compila il modulo, completa il CAPTCHA e salva con Save. Dopo una registrazione riuscita viene visualizzata la pagina di accesso. L’SMS effettivamente ricevuto deve contenere Username e password; l’ospite accede con queste credenziali. Il record deve quindi comparire in Authentication > Guest users e l’accesso in Current activities > Live users. Il traffico deve essere registrato con l’utente previsto e la Firewall Rule ID. Una regola ampia con Any non sostituisce questa prova.

Se non sono disponibili un gateway SMS, un referente responsabile o una protezione adeguata della pagina di registrazione, la registrazione autonoma resta disattivata. Una persona incaricata crea quindi gli account in modo controllato.

Creare account guest singoli o multipli

Creare un account singolo con nome ed e-mail

Per un visitatore specifico, aprire Authentication > Guest users > Add single:

1. In Name, inserire per esempio Visitor Zurich 2026-08-11. Questo campo è il nome del record, non il futuro Username.
2. Inserire l’indirizzo e-mail del responsabile. Il campo non invia le credenziali; a tale scopo Sophos documenta Add and print oppure l’SMS.
3. Impostare Validity period sul periodo necessario, nell’esempio 1 day.
4. Scegliere consapevolmente Validity start.
5. Salvare con Add oppure salvare e stampare le credenziali con Add and print.

Immediately avvia la validità al momento della creazione. È adatto quando le credenziali vengono consegnate e utilizzate immediatamente. After first login avvia il periodo al primo accesso riuscito. Questa variante è in genere migliore per gli account preparati in anticipo, perché la validità non scade prima dell’arrivo del visitatore.

Dopo la creazione, l’elenco mostra lo Username generato. Al momento della consegna, utilizzare questo valore e non il nome del record.

Generare più account per un evento

In Authentication > Guest users > Add multiple si definiscono Number of users, Validity period e Validity start. Add crea gli account senza stampare. Add and print genera gli account e le relative stampe.

Quando si creano account tramite API: SFOS 22 e 23 documentano l’intervallo 1–100 per NoOfUsers per richiesta. Non è un massimo verificato per Add multiple nell’interfaccia grafica. Suddividere le emissioni più grandi in batch API dimensionati consapevolmente. Prima, registrare il numero previsto, il modello globale e l’inizio della validità, e verificare un singolo account. Dopo ogni richiesta, confrontare gli Username realmente creati con le stampe; in caso di risposta incerta, leggere l’elenco degli account prima di ripetere alla cieca la richiesta di creazione. L’esempio API omette NoOfUsers benché la tabella lo indichi come obbligatorio e non spiega i valori 1/2/3 di Expirty Period type. Non ricavarne una richiesta completa né una corrispondenza dei valori di scadenza; chiarire prima lo schema della versione. Non reinterpretare Name come Username; consegnare le credenziali generate in modo controllato.

Più account dovrebbero essere generati solo per un evento specifico. Le stampe vengono contate, conservate in modo protetto e consegnate a un responsabile. Gli account non distribuiti o scaduti vengono disattivati o rimossi. Una grande scorta di credenziali non assegnate indebolisce il limite tecnico.

Verificare gruppo, policy e limiti di accesso

Un nuovo account guest eredita innanzitutto il gruppo selezionato in Guest user settings. In Authentication > Guest users > Edit si possono controllare nome, password, numero di cellulare, e-mail, gruppo e singole policy, quindi salvare con Save.

Le policy specifiche dell’utente hanno priorità sulle group policies. Un override è quindi sensato solo per un’eccezione documentata. Per un modello guest uniforme, Access Time, Surfing Quota, Network Traffic, Traffic Shaping e Sign-in Restriction restano normalmente raggruppati in Guest_Internet. Traffic shaping associa all’utente una policy QoS che può definire l’associazione delle policy, la priorità e limiti separati di upload e download.

Per l’esempio valgono questi limiti:

• Sign-in restriction:User group nodes eredita la limitazione del gruppo guest. Per un’eccezione individuale, limitare Selected nodes o Node range alle origini realmente necessarie. Any node è adatto solo se gli accessi da tutte le reti sono intenzionali e protetti separatamente.
• Simultaneous sign-ins: 1, finché un account guest non viene esplicitamente autorizzato per più dispositivi. Limita le sessioni simultanee; si può ereditare il valore globale o specificarne uno individuale.
• MAC binding: normalmente disattivato per gli ospiti temporanei. Il firewall non associa comunque gli utenti Remote Access VPN tramite indirizzi MAC. Quando è attivo, l’accesso è consentito solo dai dispositivi specificati; i relativi indirizzi MAC devono essere inseriti in MAC address list.
• Quarantine digest: attivare solo se l’account usa realmente Mail Protection e un processo di quarantena definito. Il digest invia l’elenco delle e-mail trattenute alla casella di posta in arrivo dell’utente.
• Remote access policies: non pianificare l’accesso VPN per gli utenti guest.

La validità dell’account risolve un compito diverso dalle policy temporali e di consumo:

• Validity period determina per quanto tempo l’account guest può essere utilizzato.
• Access Time consente o blocca l’accesso Internet in finestre temporali ricorrenti.
• Surfing Quota e Network Traffic Quota limitano il tempo online o il volume di dati.
• Una regola firewall determina quali zone, destinazioni e servizi sono effettivamente raggiungibili.

Questi livelli non si sostituiscono tra loro. Un account valido non deve raggiungere un server interno se la regola firewall non lo consente esplicitamente.

Collegare Captive Portal e percorso dati

Gli utenti guest normalmente accedono tramite Captive Portal. Device Access, DNS, HTTPS, regola utente e metodo di autenticazione selezionato devono quindi essere coerenti. Il portale, da solo, non consente ancora l’accesso Internet.

Configurare separatamente DNS e regola utente

In Rules and policies > Firewall rules, selezionare il protocollo IP appropriato e Add firewall rule > New firewall rule. La guida SMS di esempio utilizza due regole da WiFi a WAN: una per DNS, l’altra per il traffico utente con Any. Per la rete guest reale, restringere questi valori di esempio troppo ampi:

1. Impostare la regola DNS con Action: Accept, Source zones: Guest e la rete 10.30.40.0/24 in Source networks and devices. In Destination networks, selezionare solo i resolver previsti e, in Services, solo DNS. Destination zones deve corrispondere alla posizione effettiva dei resolver; WAN è corretto soltanto per resolver esterni. Per questa necessaria risoluzione dei nomi non si richiede un precedente accesso utente.
2. Impostare anche la regola utente con Action: Accept, la stessa zona guest e rete sorgente, Destination zones: WAN e soltanto le destinazioni e i servizi Internet previsti. Attivare Match known users, selezionare Guest_Internet in Users or groups e attivare Use web authentication for unknown users. Le pagine della guida SMS di SFOS 22 e 23 chiamano ancora quest’ultima opzione Show captive portal to unknown users; le pagine attuali delle regole firewall di entrambe le versioni utilizzano Use web authentication for unknown users. La diversa denominazione non dimostra un comportamento diverso.
3. Attivare Log firewall traffic e salvare ogni regola con Save. Verificarne la posizione affinché una regola precedente troppo permissiva non aggiri il controllo utente e restino efficaci i blocchi delle reti interne e dei servizi di gestione. NAT e accesso al portale vengono comunque verificati separatamente. Prima dell’accesso, una connessione non deve avere libero accesso a Internet oltre ai servizi preautenticazione espressamente necessari.

Guest e 10.30.40.0/24 rappresentano la zona preparata e la sua rete reale. Resolver, destinazioni e servizi Internet si scelgono in base alle esigenze degli ospiti, senza impostare tutto su Any. Se il firewall stesso funge da resolver DNS, si tratta di un servizio locale: consentire l’accesso DNS in Administration > Device access solo dalla zona guest, invece di copiare una regola DNS verso WAN.

Verificare accesso e restrizioni

Eseguire un test positivo e negativo completo dalla rete guest:

1. Il client riceve indirizzo, gateway e DNS dalla rete guest.
2. https://login.example.com:8090 è raggiungibile e presenta un certificato adeguato.
3. Una normale richiesta web porta al portale.
4. Un account guest valido può effettuare l’accesso.
5. In Current activities > Live users compaiono Username e indirizzo sorgente.
6. Il test Internet consentito corrisponde alla regola utente prevista e alla Firewall Rule ID.
7. Una destinazione interna e un servizio non consentito restano bloccati.
8. Un account scaduto, disattivato o inserito deliberatamente in modo errato viene rifiutato.

In una rete guest dual stack, verificare questa procedura separatamente per IPv4 e IPv6, perché SFOS gestisce separatamente l’autenticazione web per le destinazioni IPv4 e IPv6. Inoltre, in Authentication > Web authentication > Sign out user, definire e testare quando termina la sessione. Never non è adatto a un accesso guest a tempo.

La procedura completa per regola, Device Access e HTTPS è descritta in Configurare e testare Captive Portal su Sophos Firewall. Il manuale dei portali distingue User Portal, VPN Portal e Captive Portal.

Consegnare le credenziali e gestire gli account

In Authentication > Guest users sono disponibili diverse azioni operative:

• Print: selezionare gli utenti previsti nell’elenco e consegnare le loro credenziali in modo controllato.
• Resend credentials: inviare nuovamente le credenziali tramite il gateway SMS configurato.
• Change status: attivare o disattivare l’account.
• Change password: assegnare una nuova password in caso di perdita o sospetto.
• View usage: controllare l’utilizzo di Internet e lo stato delle quote.
• Reset user accounting: azzerare i contatori di consumo e riavviare la Network Traffic Quota.

Reset user accounting è una modifica dello stato. Prima vanno documentati account, consumo corrente, ora e motivo. Il reset non deve essere usato come primo passo di troubleshooting, perché modifica le prove e può assegnare nuovamente quota all’ospite.

Durante l’offboarding, disattivare prima l’account. In Current activities > Live users, selezionare la sessione attiva e terminarla con Disconnect; eseguire quindi test negativi per un nuovo accesso e per il percorso dati. Controllare poi stampe inutilizzate, accesso SMS ed eventuali override specifici dell’utente. Solo quando non rimane alcuna dipendenza, il record viene eliminato o rimosso da Auto purge on expiry.

Dismettere un gateway SMS in sicurezza: Prima, registrare il nome esatto del profilo esistente, la selezione in Guest user registration settings e le necessità di Resend credentials. Documentare la configurazione senza segreti e conservare separatamente e in modo protetto i segreti necessari per preparare una ricreazione manuale; questo non rende reversibile l’eliminazione. Finché servono la registrazione o il reinvio delle credenziali, selezionare prima un sostituto e verificare ricezione dell’SMS, registrazione completa, accesso e reinvio con un account pilota controllato. Se si abbandona la registrazione autonoma, disattivarla prima di rimuovere il profilo; questo da solo non risolve gli obblighi di reinvio. Conservare il vecchio profilo se un percorso SMS necessario non può essere verificato.

Un’eliminazione autorizzata tramite API richiede il Name esatto del vecchio profilo; non inviare un’eliminazione senza un obiettivo preciso. L’operazione documentata non dimostra né l’esistenza di uno specifico pulsante di eliminazione nell’interfaccia grafica né controlli automatici delle dipendenze. Dopo la modifica, rileggere l’elenco dei profili e la selezione del gateway e verificare i percorsi di registrazione e invio ancora necessari.

Prima del pilot, documentare impostazioni globali, gateway SMS, gruppo e regola. Per il rollback, ripristinare i singoli valori modificati; in alternativa, disattivare la registrazione autonoma e la regola del pilot. Il ripristino completo di un backup non è un annullamento rapido: sostituisce la configurazione attuale e riavvia il firewall; in HA, anche il ripristino sul Primary causa un’interruzione. Va riservato alla procedura di emergenza documentata.

Circoscrivere sistematicamente gli errori

Il nome del record non funziona come Username

Con Add single, Name è soltanto la denominazione del record utente. Lo Username effettivo viene generato dalle Guest user settings ed è riportato nell’elenco o nella stampa delle credenziali. Usare esattamente questo valore insieme alla password generata o modificata.

L’account è valido subito oppure non lo è ancora

Controllare Validity start e Validity period. Con Immediately, il tempo decorre dalla creazione; con After first login, dal primo accesso riuscito. Verificare inoltre ora e fuso orario del firewall. Un account scaduto non si ripara ampliando una regola firewall.

La registrazione autonoma non invia SMS

Verificare che Enable guest users registration sia attivo, che sia selezionato il giusto SMS gateway e che numero di cellulare, Country code, URL, metodo HTTP, parametri della richiesta e formato della risposta corrispondano al provider. Controllare quindi il log del provider e la ricezione effettiva dell’SMS.

Un Test connection riuscito non dimostra ancora l’intero flusso di registrazione e Captive Portal. Al contrario, secondo Sophos, un test fallito con un gateway interno privato non dimostra automaticamente che il percorso SMS sia guasto. In entrambi i casi si verifica con un account pilota reale.

L’accesso funziona, ma Internet no

In Current activities > Live users, controllare se l’ospite è visibile con l’indirizzo sorgente previsto. Verificare quindi gruppo, override specifici dell’utente, validità, Access Time e quote. Nel Log Viewer, il traffico di test deve corrispondere alla regola utente prevista e alla Firewall Rule ID.

Se l’utente non compare in Live users, verificare prima il percorso di login con access_server.log e l’ora documentata del test. Se l’utente è visibile, il passo successivo riguarda regola, routing, NAT, DNS o protection policy. Risolvere sistematicamente gli errori di autenticazione separa queste fasi di errore.

L’account guest non può essere selezionato per SSL VPN

È il comportamento previsto del prodotto. Guest users e Guest groups non sono Policy members validi per Remote Access SSL VPN o IPsec Remote Access. Per un tecnico esterno che necessita di una VPN, utilizzare un utente normale con privilegi limitati, MFA adeguata e una policy Remote Access appropriata.

Controllo finale

• L’ospite raggiunge solo le destinazioni previste; reti interne e servizi di gestione restano bloccati.
• Validità, Access Time, quote e override corrispondono al processo di consegna.
• La registrazione autonoma resta disattivata finché il pilot SMS e CAPTCHA non è stato superato.
• Live users, ID della regola e test positivi e negativi confermano l’associazione prevista.
• L’offboarding disconnette le sessioni attive ed elimina credenziali e stampe non più necessarie.
• Reset user accounting viene eseguito solo con un motivo documentato.

Domande frequenti