I client VPN dell’ASA prendono indirizzi dal pool DHCP sbagliato

Leggi dhcp-server e dhcp-network-scope dell’ASA come due campi distinti, imposta lo scope su un indirizzo instradabile fuori dal pool, poi verifica la rotta.

I client AnyConnect compaiono sulla sottorete sbagliata, oppure il server DHCP rifiuta di consegnare qualsiasi cosa, mentre il criterio di gruppo sembra corretto a prima vista. Su un ASA ci sono due campi in due punti che suonano entrambi come «da dove arrivano gli indirizzi», e impostare quello sbagliato produce esattamente questo. Il profilo di connessione nomina il server DHCP; il criterio di gruppo nomina una sottorete da cui quel server deve scegliere. Nessuno dei due crea un pool.

Tre oggetti, tre domande

Separa prima il modello di assegnazione dal pool, perché i due modelli non condividono la configurazione. Se è l’ASA a distribuire gli indirizzi, definisci un pool locale e indirizzi il criterio di gruppo verso di esso. Se li distribuisce un server DHCP esterno, il profilo di connessione nomina quel server e il criterio di gruppo fornisce un suggerimento di scope. Mescolare i due è la ragione abituale per cui un indirizzo non compare mai.

IntentObjects involved
ASA allocates from its own poolip local pool plus the group policy's address-pool
External DHCP allocatesdhcp-server on the tunnel group, dhcp-network-scope on the group policy

Leggi i valori effettivi prima di cambiarne uno

Una riga omessa non è la stessa cosa di un none esplicito. La configurazione in esecuzione mostra ciò che hai digitato; show run all group-policy mostra a cosa si risolve davvero il criterio, compresi i valori predefiniti ereditati. Controlla entrambi prima di decidere che lo scope è sbagliato, perché un criterio di gruppo che eredita da un criterio predefinito può fornire un valore che non compare mai nell’elenco breve.

show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
 dhcp-network-scope ?

? vale la pena leggerlo sulla versione installata, perché i valori accettati e il loro testo di aiuto differiscono tra versioni. Il riferimento Cisco ASA 9.24 per il criterio di gruppo documenta l’attributo come un indirizzo instradabile sulla sottorete desiderata, fuori dal pool di assegnazione, con preferenza per un indirizzo di interfaccia. Non è l’intervallo del pool e non è il numero di rete.

Imposta lo scope su un indirizzo, non su un intervallo

Supponi che il pool che vuoi far usare al server sia 10.50.30.50 fino a 10.50.30.200 su una /24, e che l’interfaccia dell’ASA su quel segmento sia 10.50.30.1. Il valore dello scope è 10.50.30.1. Scrivere 10.50.30.0 fallisce perché è il numero di rete, e scrivere l’intervallo fallisce perché l’attributo accetta un solo indirizzo. Se l’indirizzo che scegli non è un indirizzo di interfaccia, ha bisogno di una rotta statica perché la risposta del server DHCP possa raggiungerlo.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Questo frammento fa una sola cosa. Non configura il server DHCP, non crea un pool lì e non trasforma un profilo di accesso remoto parziale in uno funzionante. Il comportamento documentato qui è solo IPv4; non aspettarti che piloti DHCPv6 o la delega di prefisso.

Modificalo con un punto di ripristino

Fai prima uno snapshot, così il ripristino è un comando e non una ricostruzione. Salva la configurazione pertinente in un file prima di modificare, e sappi cosa no ripristina sulla tua versione: riporta l’attributo al suo valore predefinito o ereditato, che può essere none invece del criterio sovrastante.

copy running-config flash:pre-dhcp-scope.cfg
conf t
 group-policy RemoteStaff attributes
  no dhcp-network-scope
  dhcp-network-scope 10.50.30.1
 end
write memory

Rimuovere l’attributo è anche un passo diagnostico. Senza scope definito, il server DHCP cerca nei propri pool un indirizzo non assegnato, quindi il client può finire in un posto inatteso ma almeno si connette. Quel risultato dice che il percorso della richiesta funziona e che è la selezione del pool a fallire.

Verifica l’indirizzo, la rotta e i permessi

Leggi l’assegnazione dalla tabella delle sessioni e non dalla finestra del client, poi conferma che l’indirizzo è instradabile verso il tunnel e che i filtri del criterio di gruppo consentono il traffico atteso. Una decisione di assegnazione non è una decisione di instradamento, e un client che riceve un indirizzo dal pool giusto può comunque fallire a ogni richiesta.

show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source inside

Se la sessione mostra l’indirizzo voluto ma il traffico muore, lo scope è escluso come sospetto. Guarda la rotta di ritorno, le impostazioni di split-tunnel o i filtri del criterio di gruppo, e se lo scope DHCP si trova su un segmento verso cui l’ASA instrada davvero.

Articoli correlati