Configurare e testare DHCP Relay su Sophos Firewall

Un DHCP Relay inoltra le richieste DHCP da una rete client a un server in un’altra rete. Su Sophos Firewall si apre Network > DHCP, si crea sotto Relay un agente per l’interfaccia client e si inserisce l’indirizzo IP del server DHCP.

Procedura rapida: selezionare l’interfaccia client, inserire il server DHCP, verificare sul server lo scope corretto e il percorso di ritorno, rinnovare il lease e acquisire lo scambio con port 67 or port 68. Relay through IPsec si attiva solo con IPsec policy-based, non con una VPN route-based.

L’esempio utilizza la rete client 10.20.0.0/24, l’interfaccia relay 10.20.0.1 e il server DHCP 172.16.16.17.

Prerequisiti e limiti

Il server DHCP deve disporre di uno scope per 10.20.0.0/24. Sophos Firewall non distribuisce direttamente il lease, ma utilizza l’indirizzo dell’interfaccia relay affinché il server scelga lo scope corretto. Il relay necessita di una route verso il server e il server di un percorso di ritorno verso 10.20.0.1. Se invece il firewall deve distribuire gli indirizzi direttamente nella rete client collegata, è più adatta la guida Configurare Sophos Firewall come server DHCP. Le opzioni DHCP vengono configurate sul server che assegna il lease.

Un server DHCPv6 e un DHCPv6 Relay non possono essere attivi contemporaneamente. Se il firewall deve distribuire direttamente gli indirizzi IPv6, Configurare un server DHCPv6 su Sophos Firewall spiega la procedura separata con Router Advertisement, DUID e verifica del lease.

Per la configurazione valgono questi limiti:

• L’interfaccia relay deve trovarsi nella stessa subnet dei client e non può essere l’interfaccia del server DHCP.
• Gli agenti relay possono essere configurati su interfacce fisiche e virtuali come VLAN, Wireless o Bridge, ma non su un Interface Alias.
• Nella subnet del server DHCP non si configura alcun agente relay.
• Per ogni subnet client si crea un agente relay separato.
• Per ogni agente relay si possono configurare fino a otto server DHCP. La richiesta viene inviata a tutti e il client utilizza il primo Offer.
• Server DHCPv4 e DHCPv4 Relay possono essere attivi contemporaneamente sullo stesso firewall, ma non sulla stessa interfaccia.
• Server DHCPv6 e DHCPv6 Relay non possono essere attivi contemporaneamente sullo stesso firewall.
• Tra client e relay sono necessarie le porte UDP 67 e 68; relay e server comunicano tramite UDP 67. Il server deve disporre di un percorso di ritorno verso l’IP relay 10.20.0.1.

Più destinazioni relay dovrebbero fornire allo stesso client scope e opzioni identici. Risposte differenti causano altrimenti un comportamento difficile da riprodurre.

Configurare DHCP Relay senza VPN

1. Aprire Network > DHCP.
2. Sotto Relay, fare clic su Add.
3. Inserire un nome univoco come relay-clients-vlan20.
4. Selezionare IP version.
5. Sotto Interface, scegliere l’interfaccia client VLAN20 - 10.20.0.1.
6. Sotto DHCP server IP, inserire 172.16.16.17, fare clic sul pulsante più per aggiungerlo all’elenco e verificare che compaia.
7. Lasciare disattivato Relay through IPsec e salvare.

Rinnovare quindi un lease con un client di test. Le richieste relay sono traffico generato dal sistema, quindi questa procedura non richiede una regola firewall dedicata sul firewall relay. I dispositivi tra relay e server devono comunque consentire UDP 67 in entrambe le direzioni; il segmento client utilizza UDP 67/68. Se il client non riceve un indirizzo, verificare prima che il server disponga di uno scope per 10.20.0.0/24 e conosca una route verso l’interfaccia relay. Per i problemi VLAN è utile configurare l’interfaccia VLAN di Sophos Firewall.

Modificare l’intervallo di refresh del Relay solo in modo mirato

La Device Console mostra l’intervallo globale dei pacchetti di refresh DHCP Relay con:

system dhcp dhcp-relay-refresh-interval show

Il valore predefinito documentato è 10 secondi. Sophos indica due limiti superiori diversi nella stessa pagina di SFOS 22: la sintassi mostra 10000, mentre la descrizione dell’opzione indica 1000 secondi. Non utilizzare un valore superiore a 1000 basandosi solo sulla riga di sintassi. Verificare prima qualsiasi esigenza eccezionale con Sophos Support.

La modifica utilizza questo modello:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

Sostituire il segnaposto con un valore verificato. L’intervallo non va modificato come tuning generale e non risolve uno scope server mancante, il routing, IPsec o le regole firewall. Prima registrare il valore corrente, poi utilizzare show, ottenere un nuovo lease client e controllare il flusso UDP 67/68. Il rollback ripristina il valore letto in precedenza.

DHCP Relay tramite IPsec route-based

La guida di SFOS 22 documenta DHCP Relay tramite XFRM verso un server DHCP esterno dietro il firewall centrale. L’architettura documentata utilizza un tunnel route-based Any-to-Any. I Traffic Selector route-based non sono confermati per questa procedura.

⚠️ La guida ufficiale è contraddittoria: la panoramica DHCP afferma che al momento non è possibile creare relay tramite VPN route-based. Le pagine Add a DHCP relay e la procedura route-based dedicata descrivono invece l’architettura seguente. Non estendere quindi questa indicazione ad altre architetture route-based. Se i campi differiscono nel build SFOS 22 in uso, non sostituirli con opzioni policy-based; verificare il comportamento del build con Sophos Support.

⚠️ Il conflitto tra le fonti rimane irrisolto; l’architettura è documentata, ma non è stata confermata o testata come capacità del prodotto. Prima di implementarla, Sophos Support deve chiarire il supporto per il build SFOS esatto e la topologia Any-to-Any con un server DHCP esterno. Questa conferma è un prerequisito, non una prova già disponibile qui. Finché il punto non viene chiarito, non apportare modifiche alla configurazione route-based seguendo questa procedura.

Sono necessari:

1. Connessioni IPsec Any-to-Any su entrambi i firewall.
2. Interfacce XFRM indirizzate con gateway.
3. Route statiche, SD-WAN o dinamiche su entrambi i firewall: dal relay al server DHCP e, per la risposta, all’IP relay 10.20.0.1.
4. Accesso IPsec consentito sotto Administration > Device access per le interfacce WAN interessate.
5. Una regola nella sede centrale da VPN alla zona del server con Source 10.20.0.1, Destination 172.16.16.17 e Service DHCP.

Nella filiale si configura l’interfaccia client come agente relay; Relay through IPsec rimane disattivato. La richiesta è traffico generato dal sistema e non richiede una regola DHCP dedicata sul firewall della filiale. Una route SD-WAN utilizza Source Any, l’host 172.16.16.17 come Destination, Service DHCP e il gateway XFRM remoto. Nella sede centrale, la route di ritorno invia il traffico dal server DHCP all’IP relay 10.20.0.1 tramite il gateway XFRM. Per impedire il passaggio a un altro gateway quando il tunnel non è disponibile, attivare Route only through specified gateways in entrambe le route SD-WAN dedicate.

Devono essere presenti anche le regole VPN generali del tunnel Any-to-Any. La configurazione del tunnel e delle route XFRM è descritta in dettaglio in Configurare IPsec Site-to-Site su Sophos Firewall.

⚠️ Questa procedura route-based vale per un server DHCP esterno dietro il firewall centrale. Un’interfaccia di Sophos Firewall configurata come server DHCP centrale non è supportata in questo scenario.

DHCP Relay tramite IPsec policy-based

Con IPsec policy-based si attiva Relay through IPsec nella filiale. Le subnet locali e remote della connessione IPsec devono includere l’interfaccia relay e il server DHCP. Se un server DHCP esterno si trova dietro il firewall centrale, sono necessarie due regole:

• Da VPN alla zona del server: rete relay verso server DHCP, Service DHCP.
• Dalla zona del server a VPN: server DHCP verso rete client, Service DHCP.

Per la procedura policy-based documentata, l’indirizzo sorgente del traffico relay generato dal sistema deve essere impostato sull’IP relay con sys-traffic-nat. I comandi seguenti vengono eseguiti nella Device Console dopo l’accesso SSH. In SFOS 22.0 non è necessaria alcuna system ipsec_route aggiuntiva per questo traffico generato dal sistema.

Prima della modifica, salvare lo stato attuale:

show advanced-firewall

⚠️ sys-traffic-nat add modifica la configurazione NAT globale per il traffico generato dal sistema. Destination e indirizzo sorgente devono corrispondere al tunnel IPsec e al percorso di ritorno.

Nell’esempio, l’indirizzo sorgente dell’interfaccia relay viene impostato per il traffico verso il server DHCP:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Eseguire quindi nuovamente show advanced-firewall e verificare che sia presente esattamente questa voce. Il server deve poter raggiungere 10.20.0.1 attraverso il tunnel. Se la stessa voce esisteva prima della modifica, non fa parte del rollback di questa procedura.

Per una voce creata da questa procedura, il rollback è:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Altri casi particolari di routing policy-based e le procedure delle versioni SFOS precedenti sono descritti in Creare una IPsec Route su Sophos Firewall.

Quando la sede centrale è il server DHCP

Solo in questo scenario policy-based, in cui Sophos Firewall nella sede centrale è esso stesso il server DHCP, lasciare deselezionato Create firewall rule nelle connessioni IPsec di entrambi i firewall. La comunicazione DHCP con il server interno al firewall non equivale all’inoltro verso un server esterno; le regole di inoltro della sede centrale descritte sopra appartengono allo scenario con server esterno. Mantenere l’accesso IPsec da WAN in Administration > Device access e le regole necessarie per il restante traffico degli utenti VPN.

Se con IPsec policy-based il firewall Sophos centrale opera come server DHCP, sotto Network > DHCP > Server si crea o modifica uno scope del server. Attivare Accept client request via relay, inserire un intervallo di lease da 10.20.0.0/24 e impostare 10.20.0.1 come gateway. Nell’agente relay, come DHCP server IP si inserisce l’interfaccia server del firewall centrale; nel precedente esempio NAT il suo indirizzo sostituisce quindi 172.16.16.17.

⚠️ Verificare la versione prima di una modifica globale: La seguente procedura di attivazione vale solo per lo scenario documentato di SFOS 22. Le pagine della guida di SFOS 23 disponibili sono contraddittorie: HO firewall as DHCP server and BO firewall as relay agent descrive i lease DHCP tramite IPsec come attivi per impostazione predefinita, senza configurazione aggiuntiva; la panoramica DHCP indica ancora di attivarli tramite CLI. Il conflitto rimane irrisolto. Non conferma lo stato effettivo dopo un aggiornamento né dimostra che il comando sia stato rimosso. Su SFOS 23, non attivare abitualmente l’impostazione globale: registrare il build esatto e lo stato corrente e verificare prima con Sophos Support se occorre una modifica. Se lo stato non è chiaro o il comando di stato non è disponibile, fermarsi prima di apportare modifiche.

Annotare il build SFOS esatto e, prima di qualsiasi modifica, visualizzare e salvare lo stato corrente nella Device Console del firewall centrale che assegna i lease:

system dhcp lease-over-IPSec show

⚠️ L’impostazione seguente agisce globalmente sui lease DHCP tramite IPsec. Attivarla solo sul firewall che assegna direttamente i lease. Annotare lo stato iniziale visualizzato, affinché il rollback non disattivi una configurazione preesistente.

Solo su SFOS 22, se lo stato registrato è disattivato, attivare e verificare quindi con il precedente comando show. Se è già attivo, non apportare modifiche:

system dhcp lease-over-IPSec enable

Solo se la funzione era disattivata sul firewall centrale che assegna i lease ed è stata effettivamente attivata durante la procedura autorizzata, eseguire il rollback con:

system dhcp lease-over-IPSec disable

Se era già attiva, lasciarla attiva. In entrambi i casi, system dhcp lease-over-IPSec show conferma lo stato ripristinato.

Testare il funzionamento e risolvere i problemi

Un agente relay salvato non dimostra che la configurazione funzioni. Rinnovare il lease su un client di test e impostare sotto Diagnostics > Packet capture > Configure un filtro ristretto nel campo Enter BPF string:

port 67 or port 68

Nel flusso dei pacchetti devono essere visibili in sequenza la richiesta del client, la richiesta inoltrata, il Server Offer e il percorso di ritorno. Le colonne In interface, Out interface, Source IP, Destination IP, Ports [src, dst] e Status mostrano dove si interrompe lo scambio. I pacchetti relay possono comparire come Generated o Forwarded. In caso di Violation, Reason indica il controllo successivo. La procedura e i campi sono descritti in Packet Capture nel WebAdmin di Sophos Firewall.

Gli errori tipici si possono circoscrivere così:

• Nessuna richiesta client visibile: verificare VLAN, porta dello switch, interfaccia client o client DHCP locale.
• La richiesta raggiunge il firewall ma non viene inoltrata: verificare interfaccia relay, IP del server, route e, con IPsec policy-based, Relay through IPsec.
• Il server riceve la richiesta ma non risponde: verificare lo scope per la subnet relay, l’autorizzazione del server e il firewall locale del server.
• L’Offer raggiunge la sede centrale ma non il client: verificare route di ritorno, regole del firewall centrale, subnet IPsec e voce NAT.
• Il client riceve una configurazione errata: determinare quale server risponde per primo e confrontare scope e opzioni DHCP su tutte le destinazioni relay.

Annullare la configurazione

Per un rollback pianificato, verificare prima che i client possano raggiungere un altro server DHCP. Eliminare quindi l’agente relay in Network > DHCP > Relay. Rimuovere route, oggetti host e regole dedicati solo quando Packet Capture non mostra più richieste relay; conservare gli oggetti condivisi con altro traffico VPN. Con IPsec policy-based, eliminare inoltre solo la voce sys-traffic-nat creata da questa procedura. Ripristinare lease-over-IPSec solo sul firewall centrale che assegna direttamente i lease e solo se il suo stato è stato effettivamente modificato durante la procedura autorizzata; ripristinare lo stato annotato in precedenza. Questa operazione non fa parte del rollback di un relay verso un server DHCP esterno né di uno stato rimasto invariato.

Domande frequenti