Sophos Firewall DHCP Relay instellen en testen
Een DHCP Relay stuurt DHCP-verzoeken uit een clientnetwerk door naar een server in een ander netwerk. Op de Sophos Firewall opent men Network > DHCP, maakt men onder Relay een agent voor de clientinterface en voert men het IP-adres van de DHCP-server in.
Korte procedure: clientinterface selecteren, DHCP-server invoeren, de juiste scope en het retourpad op de server controleren, de lease vernieuwen en de uitwisseling vastleggen met port 67 or port 68. Relay through IPsec wordt alleen bij policy-based IPsec ingeschakeld, niet bij een route-based VPN. Voor een route-based VPN moet men eerst de hieronder beschreven tegenstrijdige bronnen en de ondersteuning van de exacte build met Sophos Support bespreken; de korte procedure is geen goedkeuring voor deze opzet.
In het voorbeeld worden het clientnetwerk 10.20.0.0/24, de relay-interface 10.20.0.1 en de DHCP-server 172.16.16.17 gebruikt. Dit is een IPv4-voorbeeld: pas alle adressen, de clientinterface en de naam aan het eigen netwerk aan. De scope is het adresbereik inclusief netwerkparameters waaruit de server leases uitgeeft. De gateway moet zich in het clientnetwerk bevinden en bereikbaar zijn; een DNS-server moet vanuit de client bereikbaar zijn. Maak vóór de overstap een back-up van bestaande scopes, relay agents en routes en gebruik een testclient die automatisch adressen via DHCP ontvangt.
Voorwaarden en beperkingen
De DHCP-server moet een scope voor 10.20.0.0/24 hebben. De Sophos Firewall deelt de lease niet zelf uit, maar gebruikt het adres van de relay-interface zodat de server de juiste scope selecteert.
De relay heeft een route naar de server nodig en de server een retourpad naar 10.20.0.1.
Als de firewall adressen rechtstreeks in het aangesloten clientnetwerk moet uitdelen, is Sophos Firewall als DHCP-server configureren de passende handleiding. DHCP-opties worden geconfigureerd op de server die de lease uitgeeft.
Ook op dezelfde Sophos Firewall kunnen een DHCPv4-server en relay worden gebruikt:
- De server luistert op een andere interface.
- Accept client request via relay is ingeschakeld.
- Voor elk clientsubnet is er een eigen serverscope met een passend leasebereik, subnetmasker, gateway en DNS.
De relay agent gebruikt de betreffende clientinterface en als doel het adres van de serverinterface. Voor clients in het serversubnet blijft de rechtstreekse uitgifte zonder relay behouden.
Een DHCPv6-server en DHCPv6-relay kunnen niet tegelijk actief zijn. Als de firewall zelf IPv6-adressen moet distribueren, beschrijft Een DHCPv6-server op Sophos Firewall configureren de afzonderlijke procedure met Router Advertisement, DUID en leasecontrole.
Voor de configuratie gelden deze beperkingen:
- De relay-interface bevindt zich in hetzelfde subnet als de clients en mag niet de interface van de DHCP-server zijn.
- Relay agents zijn mogelijk op fysieke en virtuele interfaces zoals VLAN, Wireless of Bridge, maar niet op een Interface Alias.
- In het subnet van de DHCP-server wordt geen relay agent aangemaakt.
- Voor elk clientsubnet wordt een afzonderlijke relay agent aangemaakt.
- Per relay agent kunnen maximaal acht DHCP-servers worden opgegeven. Het verzoek gaat naar alle servers; de client gebruikt het eerste Offer.
- Een DHCPv4-server en DHCPv4 Relay kunnen tegelijkertijd op dezelfde firewall actief zijn, maar niet op dezelfde interface.
- Een DHCPv6-server en DHCPv6 Relay kunnen niet tegelijkertijd op dezelfde firewall actief zijn.
- Tussen client en relay zijn UDP
67en68nodig; relay en server communiceren via UDP67. De server moet een retourpad naar het relay-IP10.20.0.1hebben.
Meerdere relay-doelen moeten voor dezelfde client consistente netwerkparameters en opties leveren, maar met gecoördineerde adrestoewijzing (serverfailover volgens de serverdocumentatie) of niet-overlappende dynamische toewijzingsbereiken. Verschillende antwoorden veroorzaken anders gedrag dat moeilijk te reproduceren is.
DHCP Relay zonder VPN instellen
- Open
Network > DHCP. - Klik onder Relay op Add.
- Voer een unieke naam in, zoals
relay-clients-vlan20. - Selecteer voor dit voorbeeld onder IP version IPv4. Neem voor IPv6 niet de IPv4-adressen of UDP-poorten uit deze handleiding over.
- Selecteer onder Interface de clientinterface
VLAN20 - 10.20.0.1. - Voer onder DHCP server IP de server
172.16.16.17in, voeg deze met de plusknop aan de lijst toe en controleer of deze daar verschijnt. - Laat Relay through IPsec uitgeschakeld en sla op.
Vernieuw daarna een lease met een testclient. Relay-verzoeken zijn systeemgegenereerd verkeer, zodat deze procedure geen eigen firewallregel op de relay-firewall nodig heeft. Apparaten tussen de relay en de server moeten UDP 67 wel in beide richtingen toestaan; het clientsegment gebruikt UDP 67/68. Als de client geen adres krijgt, controleer dan eerst of de server een scope voor 10.20.0.0/24 heeft en een route naar de relay-interface kent. Bij VLAN-problemen helpt Sophos Firewall VLAN-interface configureren.
XML-API: identiteit en IPv6-validatiegrens
Bij automatisering hoort dezelfde configuratie bij het object DHCPRelay: Name duidt de relay agent aan, Interface de clientinterface, IPFamily de bewust gekozen adresfamilie IPv4 of IPv6 en DHCPServerIP de serverlijst. De Add/Edit-documentatie voor SFOS 22 en 23 markeert deze vier velden als verplicht; de gedocumenteerde standaardwaarde voor IPFamily is IPv4. DHCPServerIP wordt beschreven als ARRAY met IPADDRESS en IPADDRESS6: meerdere waarden zijn toegestaan, dubbele waarden worden genegeerd en LINKLOCAL is uitgesloten. Meerdere relay-doelen blijven dus mogelijk; het enkele tijdelijke-aanduidingsveld in het voorbeeld toont noch de serialisatie van de lijst, noch een IPv6-codering aan. Behoud bewust de instelling van Relay through IPsec die past bij de hieronder toegelichte VPN-variant; leid deze niet af uit een API-voorbeeld.
De parametertabel vermeldt voor DHCPServerIP tegelijkertijd maximaal 15 tekens. Die limiet is niet algemeen verenigbaar met de toegestane IPv6-adresnotatie met IPADDRESS6: de documentatie is hier inconsistent en toont niet aan hoe de validator van de specifieke build IPv6 verwerkt. Hieruit volgt niet dat DHCPv6 Relay in het product niet wordt ondersteund, en evenmin dat een alternatieve codering bestaat of dat adressen mogen worden ingekort.
Gebruik voor IPv6 eerst de handmatige configuratie in WebAdmin en bespreek vóór IPv6-automatisering met Sophos Support het schema, de adresvalidatie en het formaat van de serverlijst voor de exacte SFOS-versie en build. Een opgeslagen GUI-configuratie of een geslaagde clientlease bevestigt niet dat een IPv6-XML-aanvraag geldig is. De hieronder beschreven client- en pakketstroomcontroles en het terugdraaien op basis van de vooraf vastgelegde status blijven noodzakelijk; de IPv4-adressen en UDP-poorten uit dit voorbeeld worden niet overgenomen voor IPv6.
Het Relay-refreshinterval alleen gericht wijzigen
Device Console toont het globale interval voor DHCP Relay-refreshpakketten met:
system dhcp dhcp-relay-refresh-interval show
De gedocumenteerde standaardwaarde is 10 seconden. Sophos noemt op dezelfde SFOS 22-pagina twee verschillende bovengrenzen: de syntaxis toont 10000, terwijl de optiebeschrijving 1000 seconden vermeldt. Gebruik daarom niet alleen op basis van de syntaxisregel een waarde boven 1000. Stem een uitzonderlijke behoefte eerst af met Sophos Support.
De wijziging gebruikt deze sjabloon:
system dhcp dhcp-relay-refresh-interval set seconds <seconds>
Vervang de tijdelijke aanduiding door een geverifieerde waarde. Wijzig het interval niet als algemene tuning; het herstelt geen ontbrekende serverscope, routing, IPsec of firewallregels. Leg eerst de huidige waarde vast, gebruik daarna show, verkrijg een nieuwe clientlease en controleer de UDP 67/68-pakketstroom. Rollback herstelt de eerder gelezen waarde.
DHCP Relay via route-based IPsec
De helpdocumentatie voor SFOS 22 en SFOS 23 beschrijft DHCP Relay via XFRM naar een externe DHCP-server achter de centrale firewall. De beschreven opzet gebruikt een route-based Any-to-Any-tunnel. Route-based Traffic Selectors zijn voor deze procedure niet bevestigd.
⚠️ De officiële helpdocumentatie is in SFOS 22 en SFOS 23 tegenstrijdig: zowel het DHCP-overzicht als Routing and NAT for IPsec tunnels stelt dat DHCP Relay via een route-based VPN niet mogelijk is. Add a DHCP relay en de afzonderlijke route-based handleiding beschrijven daarentegen de volgende Any-to-Any-opzet. Hieruit kan geen bevestigde productondersteuning worden afgeleid. Wijk bij afwijkende velden niet uit naar policy-based opties, maar bespreek de topologie en de exacte build met Sophos Support.
⚠️ Het bronconflict blijft onopgelost; bevestig ondersteuning van deze opzet voor de geïnstalleerde versie voordat zij wordt toegepast. Vóór de uitvoering moet Sophos Support de ondersteuning voor de exacte SFOS-build en de Any-to-Any-topologie met een externe DHCP-server verduidelijken. Die bevestiging is een voorwaarde, geen bewijs dat hier al beschikbaar is. Voer zolang dit niet is opgehelderd geen route-based configuratiewijzigingen uit volgens deze procedure.
Voor de gedocumenteerde opzet gelden de volgende voorwaarden. Totdat dit met Sophos Support is opgehelderd, dienen de details alleen voor de planning; configuratiewijzigingen worden pas na bevestiging uitgevoerd:
- Any-to-Any-IPsec-verbindingen op beide firewalls.
- Geadresseerde XFRM-interfaces met gateway.
- Statische, SD-WAN- of dynamische routes op beide firewalls: van de relay naar de DHCP-server en voor het antwoord terug naar het relay-IP
10.20.0.1. - Toegestane IPsec-toegang onder
Administration > Device accessvoor de betrokken WAN-interfaces. - Een regel op de centrale locatie van
VPNnaar de serverzone met Source10.20.0.1, Destination172.16.16.17en ServiceDHCP.
Op de nevenlocatie wordt de clientinterface als relay agent ingesteld; Relay through IPsec blijft uitgeschakeld. Het relay-verzoek is daar systeemgegenereerd verkeer en heeft geen eigen DHCP-firewallregel nodig.
Een SD-WAN-route gebruikt:
- Als Source
Any. - Als Destination de host
172.16.16.17. - Als Service
DHCP. - De externe XFRM-gateway.
Op de centrale locatie loopt de retourroute van de DHCP-server naar het relay-IP 10.20.0.1 via de XFRM-gateway.
Als men wil voorkomen dat dit verkeer bij het uitvallen van de tunnel via een andere gateway wordt gerouteerd, schakelt men in beide specifieke SD-WAN-routes Route only through specified gateways in.
Voor de specifieke SD-WAN-routes:
- Open na bevestiging
Routing > SD-WAN routes. - Selecteer IPv4 > Add en voer een unieke naam in.
- Selecteer onder Link selection settings de optie Primary and backup gateways.
- Voer onder Primary gateway de passende XFRM-gateway van de betreffende firewall in.
- Sla op.
De firewallregel op de centrale locatie wordt onder Rules and policies > Firewall rules > Add firewall rule > New firewall rule aangemaakt met de hierboven genoemde hosts en service.
De Destination zone komt overeen met het werkelijke servernetwerk, bijvoorbeeld DMZ, en is niet automatisch LAN.
De fail-closed-optie voorkomt routering via een alternatief pad, maar betekent bij het uitvallen van de tunnel ook dat er via dit pad geen nieuwe leases kunnen worden verkregen.
De algemene VPN-regels voor de Any-to-Any-tunnel moeten eveneens bestaan. De configuratie van de tunnel en XFRM-routes wordt uitgebreid beschreven in Site-to-Site IPsec op Sophos Firewall instellen.
⚠️ Deze route-based procedure geldt voor een externe DHCP-server achter de centrale firewall. Een interface van Sophos Firewall als centrale DHCP-server wordt in deze opzet niet ondersteund.
DHCP Relay via policy-based IPsec
Bij policy-based IPsec wordt op de nevenlocatie Relay through IPsec ingeschakeld. De lokale en externe subnetten van de IPsec-verbinding moeten de relay-interface en DHCP-server omvatten.
Als er een externe DHCP-server achter de centrale firewall staat, zijn daar twee regels nodig.
Een bestaande, werkende tunnel is een voorwaarde. Als deze nog moet worden aangemaakt, gebeurt dat onder Site-to-site VPN > IPsec > IPsec connections > Add met Connection type: Policy-based:
- Op de nevenlocatie: Gateway type: Initiate the connection.
- Op de centrale locatie: Respond only.
- Listening interface is telkens de eigen WAN-interface.
- Gateway address is het WAN-adres van de andere kant.
De authenticatie en Preshared key moeten overeenkomen. De lokale en externe netwerken worden aan de andere kant omgekeerd ingesteld. Voor het voorbeeld met de externe server zijn dit 10.20.0.0/24 en het daadwerkelijk gebruikte servernetwerk.
Sta IPsec-toegang vanaf WAN toe onder Administration > Device access.
Op de nevenlocatie heeft het systeemgegenereerde relay-verkeer geen automatisch aangemaakte firewallregel nodig. Op de centrale locatie kunnen de automatisch aangemaakte regels worden beperkt tot de hieronder genoemde DHCP-hosts, zones en services.
Verwijder bestaande regels voor ander VPN-verkeer niet.
- Van
VPNnaar de serverzone: relay-netwerk naar DHCP-server, ServiceDHCP. - Van de serverzone naar
VPN: DHCP-server naar clientnetwerk, ServiceDHCP.
Voor de gedocumenteerde policy-based procedure moet het bronadres van het systeemgegenereerde relay-verkeer met sys-traffic-nat op het relay-IP worden ingesteld.
De volgende opdrachten worden na het inloggen via SSH in de Device Console uitgevoerd.
De specifieke Routing/NAT-helpdocumentatie voor SFOS 22 en 23 maakt onderscheid tussen doorgestuurd en systeemgegenereerd verkeer: voor dat laatste is geen aanvullende system ipsec_route nodig. Het algemene DHCP-overzicht noemt daarentegen nog een stap voor een IPsec-route.
Dit verschil is geen reden om standaard een extra route aan te maken: controleer eerst de bestaande route en de pakketstroom en schakel Sophos Support in als de build afwijkend gedrag vertoont.
- NAT vervangt geen route.
- destination blijft het serveradres.
- snatip is het relay-bronadres, niet het serveradres.
- Een gewone WAN-MASQ-regel is geen vervanging voor
sys-traffic-nat.
Leg vóór de wijziging de huidige status vast:
show advanced-firewall
⚠️
sys-traffic-nat addwijzigt de globale NAT-configuratie voor systeemgegenereerd verkeer. Destination en bronadres moeten bij de IPsec-tunnel en het retourpad passen.
In het voorbeeld wordt het bronadres van de relay-interface voor verkeer naar de DHCP-server vastgelegd:
set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1
Voer daarna opnieuw show advanced-firewall uit en controleer of precies deze vermelding aanwezig is. De server moet 10.20.0.1 via de tunnel kunnen bereiken. Als dezelfde vermelding al vóór de wijziging bestond, hoort die niet bij de rollback van deze procedure.
Voor een vermelding die met deze procedure is gemaakt, is de rollback:
set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1
Andere policy-based routingsituaties en oudere SFOS-procedures worden uitgelegd in IPsec-route op Sophos Firewall maken.
Als de centrale locatie zelf DHCP-server is
Alleen in dit policy-based scenario, waarin de Sophos Firewall op de centrale locatie zelf de DHCP-server is, blijft Create firewall rule uitgevinkt in de IPsec-verbindingen op beide firewalls. DHCP-communicatie met de firewallinterne server is niet hetzelfde als verkeer doorsturen naar een externe server; de eerder beschreven doorstuurregels op de centrale locatie horen bij het scenario met een externe server. Behoud IPsec-toegang vanaf WAN onder Administration > Device access en de regels die voor ander VPN-gebruikersverkeer nodig zijn.
Als de centrale Sophos Firewall bij policy-based IPsec zelf als DHCP-server werkt, wordt onder Network > DHCP > Server een serverscope aangemaakt of bewerkt.
- Schakel Accept client request via relay in.
- Voer een leasebereik uit
10.20.0.0/24in. - Stel
10.20.0.1als gateway in.
Bij de relay agent wordt als DHCP server IP de serverinterface van de centrale firewall ingevoerd. In het voorgaande NAT-voorbeeld vervangt het adres daarvan dus 172.16.16.17.
Een aanpasbaar voorbeeld voor Dynamic IP lease is 10.20.0.10 tot 10.20.0.30 met subnetmasker 255.255.255.0. Gateway 10.20.0.1 en vaste infrastructuuradressen blijven buiten de pool.
Kies de pool op basis van het aantal clients en de al gereserveerde adressen. Gebruik Use device’s DNS settings alleen als de daar ingestelde DNS-servers vanuit de nevenlocatie bereikbaar zijn.
Voor deze firewallinterne server gebruiken de policy-based selectors op de centrale locatie het serverinterface-adres en het clientnetwerk. Op de nevenlocatie geldt de omgekeerde toewijzing.
⚠️ Controleer de versie vóór een globale wijziging: De volgende activeringsprocedure geldt alleen voor het gedocumenteerde SFOS 22-scenario. De beschikbare SFOS 23-helppagina’s spreken elkaar tegen: HO firewall as DHCP server and BO firewall as relay agent beschrijft DHCP-leases via IPsec als standaard ingeschakeld zonder aanvullende configuratie; het DHCP-overzicht schrijft nog steeds inschakelen via de CLI voor. Dit conflict blijft onopgelost. Het bevestigt noch de werkelijke status na een upgrade, noch dat de opdracht is verwijderd. Schakel op SFOS 23 de globale instelling niet routinematig in: leg de exacte build en huidige status vast en laat eerst door Sophos Support bevestigen of een wijziging nodig is. Stop vóór een wijziging als de status onduidelijk is of de statusopdracht niet beschikbaar is.
Noteer de exacte SFOS-build en toon en bewaar vóór elke wijziging de huidige status in de Device Console op de centrale firewall die de leases uitgeeft:
system dhcp lease-over-IPSec show
⚠️ De volgende instelling werkt globaal voor DHCP-leases via IPsec. Schakel deze alleen in op de firewall die zelf de leases uitgeeft. Noteer de getoonde beginstatus, zodat rollback geen bestaande configuratie uitschakelt.
Alleen op SFOS 22, als de vastgelegde status uitgeschakeld is, schakel de instelling in en controleer deze daarna met de voorgaande show-opdracht. Wijzig niets als deze al ingeschakeld is:
system dhcp lease-over-IPSec enable
Alleen als de functie op de centrale firewall die de leases uitgeeft eerder uitgeschakeld was en tijdens de geautoriseerde procedure daadwerkelijk is ingeschakeld, is de rollback:
system dhcp lease-over-IPSec disable
Was de functie al ingeschakeld, laat haar dan ingeschakeld. In beide gevallen bevestigt system dhcp lease-over-IPSec show de herstelde status.
Werking testen en problemen oplossen
Een opgeslagen relay agent bewijst niet dat de configuratie werkt. Vernieuw met een testclient de lease en stel onder Diagnostics > Packet capture > Configure in het veld Enter BPF string een beperkt filter in:
port 67 or port 68
In de pakketstroom moeten achtereenvolgens zichtbaar zijn:
- Het clientverzoek.
- Het doorgestuurde verzoek.
- Het Offer van de server.
- Het retourpad.
De kolommen In interface, Out interface, Source IP, Destination IP, Ports [src, dst] en Status laten zien waar de uitwisseling stopt.
Relay-pakketten kunnen daarbij als Generated of Forwarded verschijnen. Bij Violation geeft Reason een aanwijzing voor de volgende controle.
De bediening en velden worden uitgelegd in Packet Capture in Sophos Firewall WebAdmin.
Alleen een Offer is niet voldoende: de client moet het adres aanvragen en een ACK ontvangen.
Controleer daarna:
- Op de client: het IP-adres uit de bedoelde pool, het subnetmasker, de gateway en DNS.
- Op de server die de lease uitgeeft: de leasevermelding.
Een pingantwoord van de server bewijst niet dat UDP bereikbaar is of dat de DHCP-uitwisseling is geslaagd.
Deze controles moeten door de beheerder worden uitgevoerd.
Typische fouten kunnen als volgt worden afgebakend:
- Geen clientverzoek zichtbaar: controleer VLAN, switchpoort, clientinterface of lokale DHCP-client.
- Verzoek bereikt de firewall, maar wordt niet doorgestuurd: controleer de relay-interface, het server-IP, de route en bij policy-based IPsec Relay through IPsec.
- Server ontvangt het verzoek, maar antwoordt niet: controleer de scope voor het relay-subnet, de serverautorisatie en de lokale serverfirewall.
- Offer bereikt de centrale locatie, maar niet de client: controleer de retourroute, centrale firewallregels, IPsec-subnetten en NAT-vermelding.
- Client ontvangt een verkeerde configuratie: bepaal welke server als eerste antwoordt en vergelijk de scopes en DHCP-opties op alle relay-doelen.
- Policy rule denied bij Source
0.0.0.0: een client zonder adres begint met dit bronadres. Controleer of op de juiste clientinterface een DHCP-server of relay verantwoordelijk is; maak geen algemene Allow-regel voor0.0.0.0ofAnyaan om het symptoom te verbergen. Het overzicht beschrijft het droppen bij een ontbrekende server; controleer in het relay-scenario het daadwerkelijke pakketpad in plaats van daaruit een algemene relay-blokkade af te leiden.
De configuratie terugdraaien
Controleer voor een geplande rollback eerst of clients een andere DHCP-server kunnen bereiken. Verwijder daarna de relay agent onder Network > DHCP > Relay. Verwijder speciale routes, hostobjecten en regels pas wanneer Packet Capture geen relay-verzoeken meer toont; behoud objecten die met ander VPN-verkeer worden gedeeld. Verwijder bij policy-based IPsec daarnaast alleen de sys-traffic-nat-vermelding die met deze procedure is gemaakt. Herstel lease-over-IPSec alleen op de centrale firewall die zelf de leases uitgeeft, en alleen als de status tijdens de geautoriseerde procedure daadwerkelijk is gewijzigd; herstel daarbij de vooraf genoteerde status. Dit hoort niet bij de rollback van een relay naar een externe DHCP-server of van een ongewijzigde status.
Veelgestelde vragen
Moet Relay through IPsec bij elke VPN worden ingeschakeld?
Waar worden DHCP-opties bij een relay geconfigureerd?
Waarom krijgt de client ondanks een bereikbare DHCP-server geen lease?
67/68.