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. Per una VPN route-based, chiarire prima con Sophos Support le incongruenze tra le fonti descritte di seguito e il supporto della build esatta; la procedura rapida non costituisce un’approvazione di questa configurazione.

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. Si tratta di un esempio IPv4: adattare tutti gli indirizzi, l’interfaccia client e il nome alla propria rete. Lo scope è l’intervallo di indirizzi, insieme ai parametri di rete, da cui il server assegna i lease. Il gateway deve trovarsi nella rete client ed essere raggiungibile; un server DNS deve essere raggiungibile dal client. Prima della modifica, salvare gli scope, gli agenti relay e le route esistenti e utilizzare un client di prova che ottenga automaticamente gli indirizzi tramite DHCP.

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.

È possibile utilizzare un server DHCPv4 e un relay anche sullo stesso Sophos Firewall:

• Il server è in ascolto su un’altra interfaccia.
• Accept client request via relay è attivato.
• Ogni subnet client dispone di un proprio scope sul server con intervallo di lease, maschera di sottorete, gateway e DNS appropriati.

L’agente relay utilizza la rispettiva interfaccia client e, come destinazione, l’indirizzo dell’interfaccia server; per i client nella subnet del server rimane attiva l’assegnazione diretta senza relay.

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 parametri di rete e opzioni coerenti, ma con un’allocazione degli indirizzi coordinata tramite failover dei server secondo la relativa documentazione oppure con intervalli di allocazione dinamica non sovrapposti. Risposte con parametri di rete e opzioni 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, ad esempio relay-clients-vlan20.
4. Per questo esempio, selezionare IPv4 sotto IP version. Per IPv6, non utilizzare gli indirizzi IPv4 o le porte UDP di questa guida.
5. Sotto Interface, selezionare l’interfaccia client VLAN20 - 10.20.0.1.
6. Sotto DHCP server IP, inserire il server 172.16.16.17, aggiungerlo all’elenco con il pulsante più e verificare che compaia nell’elenco.
7. Lasciare Relay through IPsec disattivato 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.

API XML: identità e limite della validazione IPv6

Nell’automazione, la stessa configurazione appartiene all’oggetto DHCPRelay: Name identifica l’agente relay, Interface l’interfaccia client, IPFamily la famiglia scelta consapevolmente, IPv4 o IPv6, e DHCPServerIP l’elenco dei server. La documentazione Add/Edit di SFOS 22 e 23 indica questi quattro campi come obbligatori; il valore predefinito documentato per IPFamily è IPv4. DHCPServerIP è descritto come ARRAY con IPADDRESS e IPADDRESS6: sono ammessi più valori, i duplicati vengono ignorati e LINKLOCAL è escluso. Rimane quindi possibile utilizzare più destinazioni relay; il singolo campo segnaposto nell’esempio non dimostra né il formato di serializzazione dell’elenco né una codifica IPv6. Mantenere consapevolmente lo stato di Relay through IPsec appropriato alla variante VPN illustrata di seguito, senza dedurlo da un esempio API.

La tabella dei parametri indica contemporaneamente un massimo di 15 caratteri per DHCPServerIP. Questo limite non è generalmente compatibile con la rappresentazione degli indirizzi IPv6 consentita da IPADDRESS6: la documentazione è incoerente su questo punto e non dimostra come il validatore della build specifica gestisca IPv6. Non se ne può dedurre né che il prodotto non supporti DHCPv6 Relay, né una codifica alternativa, né la possibilità di accorciare gli indirizzi.

Per IPv6, utilizzare inizialmente la configurazione manuale nel WebAdmin e, prima di automatizzarla, chiarire con Sophos Support lo schema, la validazione degli indirizzi e il formato dell’elenco dei server per la versione e la build SFOS esatte. Una configurazione salvata nella GUI o un lease ottenuto correttamente da un client non confermano la validità di una richiesta XML IPv6. Restano necessari i controlli sui client e sul flusso dei pacchetti, nonché il rollback basato sullo stato precedente descritti di seguito; gli indirizzi IPv4 e le porte UDP di questo esempio non vanno riutilizzati per IPv6.

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 e SFOS 23 documenta DHCP Relay tramite XFRM verso un server DHCP esterno dietro il firewall centrale. La configurazione descritta utilizza un tunnel route-based Any-to-Any. I Traffic Selectors route-based non sono confermati per questa procedura.

⚠️ La guida ufficiale presenta indicazioni contraddittorie in SFOS 22 e SFOS 23: sia la panoramica DHCP sia Routing and NAT for IPsec tunnels escludono DHCP Relay tramite VPN route-based. Add a DHCP relay e la guida separata per route-based descrivono invece la seguente configurazione Any-to-Any. Non se ne può dedurre un supporto confermato del prodotto. Se i campi differiscono, non ripiegare sulle opzioni policy-based, ma chiarire la topologia e la build esatta con Sophos Support.

⚠️ Il supporto di questa architettura rimane da chiarire a causa del conflitto tra le fonti. 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.

La configurazione documentata prevede i seguenti prerequisiti. Finché non sono stati chiariti con Sophos Support, questi dettagli servono solo per la pianificazione; apportare modifiche alla configurazione solo dopo la conferma:

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 sede remota, l’interfaccia client viene configurata come agente relay; Relay through IPsec rimane disattivato.

La richiesta relay è traffico generato dal sistema e non richiede una regola firewall DHCP dedicata in quella sede.

Una route SD-WAN utilizza:

• Any come Source.
• L’host 172.16.16.17 come Destination.
• DHCP come Service.
• Il gateway XFRM remoto.

Nella sede centrale, la route di ritorno dal server DHCP all’IP relay 10.20.0.1 passa attraverso il gateway XFRM.

Per impedire che questo traffico venga instradato attraverso un altro gateway in caso di interruzione del tunnel, attivare Route only through specified gateways in entrambe le route SD-WAN dedicate.

Per configurare le route SD-WAN dedicate, dopo la conferma:

1. Aprire Routing > SD-WAN routes, selezionare IPv4 > Add e assegnare un nome univoco.
2. Sotto Link selection settings, selezionare Primary and backup gateways.
3. Sotto Primary gateway, inserire il gateway XFRM appropriato del rispettivo firewall; quindi salvare.

Creare la regola firewall nella sede centrale sotto Rules and policies > Firewall rules > Add firewall rule > New firewall rule con gli host e il Service indicati sopra.

La Destination zone corrisponde alla rete effettiva del server, ad esempio DMZ, e non è automaticamente LAN.

L’opzione Fail-closed impedisce l’instradamento alternativo, ma in caso di interruzione del tunnel comporta anche l’impossibilità di ottenere nuovi lease attraverso questo percorso.

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, attivare Relay through IPsec nella sede remota. 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, in quella sede sono necessarie due regole.

Un tunnel esistente e funzionante è un prerequisito. Se deve ancora essere creato, configurarlo sotto Site-to-site VPN > IPsec > IPsec connections > Add con Connection type: Policy-based:

• Nella sede remota impostare Gateway type: Initiate the connection, nella sede centrale Respond only.
• Listening interface è l’interfaccia WAN locale di ciascuna sede, mentre Gateway address è l’indirizzo WAN della controparte.
• L’autenticazione e il Preshared key devono coincidere.
• Le reti locali e remote devono essere invertite sulla controparte. Per l’esempio con server esterno, si tratta di 10.20.0.0/24 e della rete server effettivamente utilizzata.

Consentire l’accesso IPsec dalla WAN sotto Administration > Device access.

Nella sede remota, il traffico relay generato dal sistema non richiede una regola firewall generata automaticamente; nella sede centrale, le regole generate automaticamente possono essere limitate agli host, alle zone e ai Services DHCP indicati di seguito.

Non rimuovere le regole esistenti per altro traffico VPN.

• 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 tramite sys-traffic-nat.

I seguenti comandi vengono eseguiti nella Device Console dopo l’accesso SSH.

La guida specifica Routing/NAT per SFOS 22 e 23 distingue il traffico inoltrato da quello generato dal sistema: per quest’ultimo non è necessaria un’ulteriore system ipsec_route.

La panoramica generale DHCP indica invece ancora un passaggio per la route IPsec.

Questa differenza non giustifica la creazione sistematica di un’ulteriore route: verificare prima la route esistente e il flusso dei pacchetti e, se il comportamento della build differisce, coinvolgere Sophos Support.

Il NAT non sostituisce una route.

• destination rimane l’indirizzo del server.
• snatip è l’indirizzo sorgente del relay, non l’indirizzo del server.

Una normale regola WAN-MASQ non sostituisce sys-traffic-nat.

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, Sophos Firewall nella sede centrale funge direttamente da server DHCP:

1. Creare o modificare uno scope server sotto Network > DHCP > Server.
2. Attivare Accept client request via relay, inserire un intervallo di lease appartenente a 10.20.0.0/24 e impostare 10.20.0.1 come gateway.
3. Nell’agente relay, inserire l’interfaccia server del firewall centrale come DHCP server IP; nell’esempio NAT precedente, il relativo indirizzo sostituisce quindi 172.16.16.17.

Un esempio adattabile per Dynamic IP lease è da 10.20.0.10 a 10.20.0.30 con maschera di sottorete 255.255.255.0; il gateway 10.20.0.1 e gli indirizzi fissi dell’infrastruttura rimangono fuori dal pool.

Scegliere il pool in base al numero di client e agli indirizzi già riservati.

Utilizzare Use device’s DNS settings solo se i server DNS configurati in quelle impostazioni sono raggiungibili dalla filiale.

Per questo server interno al firewall, i selettori policy-based nella sede centrale utilizzano l’indirizzo dell’interfaccia server e la rete client; nella filiale si applica l’associazione inversa.

⚠️ 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 dovrebbero essere visibili, in sequenza:

1. La richiesta del client.
2. La richiesta inoltrata.
3. L’Offer del server.
4. Il percorso di ritorno.

Le colonne In interface, Out interface, Source IP, Destination IP, Ports [src, dst] e Status mostrano in quale punto si interrompe lo scambio.

I pacchetti relay possono comparire come Generated o Forwarded. In caso di Violation, Reason fornisce l’indicazione per il controllo successivo.

L’utilizzo e i campi sono spiegati in Packet Capture nel WebAdmin di Sophos Firewall.

Un Offer da solo non basta: il client deve richiedere l’indirizzo e ricevere un ACK.

Successivamente, verificare sul client l’indirizzo IP del pool previsto, la maschera di sottorete, il gateway e il DNS, quindi controllare la voce del lease sul server che lo ha assegnato.

Una risposta ping del server non dimostra né la raggiungibilità UDP né il completamento dello scambio DHCP.

Questi controlli devono essere eseguiti dall’amministratore.

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 la route di ritorno, le regole firewall centrali, le subnet IPsec e la voce NAT.
• Il client riceve una configurazione errata: individuare quale server risponde per primo e confrontare gli scope e le opzioni DHCP su tutte le destinazioni relay.
• Policy rule denied con Source 0.0.0.0: un client senza indirizzo inizia con questo indirizzo sorgente. Verificare se un server DHCP o un relay gestisce le richieste sull’interfaccia client corretta; non creare una regola Allow generica per 0.0.0.0 o Any per nascondere il sintomo. La panoramica descrive il Drop in assenza di un server; nello scenario relay, verificare il percorso effettivo dei pacchetti anziché dedurne un blocco generale del 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