Rifiuto di geolocalizzazione del Firebox: trovate prima lo stadio di ingresso VPN

Qualcuno in un altro paese non riesce a connettersi, e il primo istinto è guardare la regola che concede l'accesso alle risorse interne. Quella regola viene eseguita dopo l'ammissione, quindi non può essere ciò che rifiuta il tunnel. Lo stadio che blocca si trova da qualche parte nel percorso di ingresso, e il Firebox ha più di un percorso di ingresso a seconda del servizio VPN. Eseguite i controlli in ordine e fermatevi non appena uno di essi spiega il rifiuto.

Controllo 1: nominare il servizio in ingresso

Per Mobile VPN con SSL, Access Portal e BOVPN su TLS, l'ingresso in entrata è la policy WatchGuard SSLVPN. Applicate lì la restrizione prevista, sul servizio realmente configurato, invece di dedurla da una regola di accesso utente che viene eseguita più tardi.

IPsec segue un altro percorso. La policy IPSec integrata consente il traffico IPsec esterno verso il Firebox per i servizi branch e VPN mobile applicabili, e ha la precedenza su una policy IPSec creata manualmente. Se il vostro client è IKEv2, siete su quel secondo percorso, e la policy SSLVPN è irrilevante.

Sbagliare qui è il pomeriggio più comunemente sprecato in questo ambito: modificare una policy che non vede mai il pacchetto, per poi concludere che la restrizione non funziona.

Controllo 2: leggete il rifiuto, non la teoria

Fate un tentativo consentito e controllato e correlate quattro cose: l'indirizzo sorgente pubblico del client, il servizio di ingresso raggiunto, la policy che ha corrisposto e qualsiasi motivo di rifiuto nel log. La guida alla risoluzione dei problemi IKEv2 di WatchGuard osserva che la geolocalizzazione e la gestione predefinita dei pacchetti possono rifiutare il traffico prima dell'ammissione della policy integrata, il che significa che il rifiuto che vedete può nominare uno stadio che non avevate considerato.

La classificazione del paese segue l'origine di rete osservata. Un utente in roaming, un NAT a monte o un diverso percorso approvato possono cambiare ciò che il Firebox vede, quindi confermate l'indirizzo e non la descrizione dell'utente su dove si trova. Chiedete l'indirizzo pubblico che il client vede e confrontatelo con l'origine nel log del Firebox. Quando differiscono, la classificazione segue un percorso che nessuno ha menzionato.

Controllo 3: la policy integrata è ancora il proprietario?

Se una policy IPSec manuale sembra ignorata, verificate se quella integrata è ancora abilitata. Una regola manuale oscurata da una regola integrata con priorità più alta e una regola manuale che è l'unica ammissione sono configurazioni diverse con un'interfaccia dall'aspetto identico.

Decidete quale deve possedere il percorso. Se è la policy manuale, quella integrata deve essere disabilitata per quel traffico, ed è lì che inizia il controllo successivo.

Controllo 4: pianificate la sostituzione prima di disabilitare

Disabilitare la policy IPSec integrata rimuove la sua ammissione per i servizi VPN interessati. Ciò include tunnel branch a cui forse non pensate mentre sistemate la connessione di un utente mobile.

Pianificate prima la sostituzione completa: quali servizi necessitano di ammissione, quali ambiti di origine ricevono e come gestirete l'appliance se la modifica va storta. Mantenete aperto un percorso di gestione e ripristino indipendente, perché un errore qui può rimuovere il tunnel che usereste per ripararlo. Annotate i passaggi di ripristino nel registro delle modifiche, incluso come raggiungere l'appliance se il percorso VPN è sparito. Poi provate il rinnovo, non solo la prima connessione.

La connettività attiva e la successiva rinegoziazione possono entrambe dipendere dall'ammissione. Una modifica che funziona per la sessione testata e fallisce al successivo cambio di chiave è un esito classico della sostituzione dell'ammissione senza testare il rinnovo.

Controllo 5: tenete separate identità e posizione

La geolocalizzazione aggiunge contesto a una decisione di ingresso. Non stabilisce chi è l'utente e non deve sostituire i controlli di identità del gateway, l'autorizzazione dell'account o l'MFA.

Se il requisito aziendale è solo utenti approvati da luoghi approvati, servono entrambi i controlli. Una regola di posizione che ammette un intero paese non sostituisce l'autenticazione, e un utente autenticato in un paese bloccato è una questione di policy, non un bug.

Controllo 6: annotatelo e verificate entrambi i percorsi

Annotate il servizio, la policy di ingresso, l'ambito di posizione previsto, le eccezioni e il responsabile del ripristino. Poi provate il percorso mobile e almeno un percorso di sede dopo la modifica, così che la restrizione resti legata al servizio per cui è stata progettata.

Infine, rileggete il rifiuto con cui avete iniziato. Se è passato da un rifiuto di posizione a un errore di autenticazione o autorizzazione, il problema di ingresso è risolto e ora se ne vede un altro. Guida WatchGuard sui rifiuti IKEv2 è il riferimento per l'ordine degli stadi descritto sopra.