Konfigurera och testa DHCP-relä på Sophos Firewall

Ett DHCP-relä vidarebefordrar DHCP-förfrågningar från ett klientnät till en server i ett annat nät. På Sophos Firewall öppnar man Network > DHCP, lägger till en agent under Relay för klientinterfacet och anger DHCP-serverns IP-adress.

Snabbt arbetsflöde: Välj klientinterfacet, ange DHCP-servern, kontrollera rätt scope och returväg på servern, förnya leasen och fånga utbytet med port 67 or port 68. Relay through IPsec aktiveras endast för policy-based IPsec, inte för route-based VPN. För route-based VPN måste man först reda ut den källkonflikt som beskrivs nedan och stödet för den exakta builden med Sophos Support; det snabba arbetsflödet innebär inget godkännande av denna konfiguration.

Exemplet använder klientnätet 10.20.0.0/24, reläinterfacet 10.20.0.1 och DHCP-servern 172.16.16.17. Detta är ett IPv4-exempel: anpassa alla adresser, klientinterfacet och namnet till det egna nätet. Ett scope är adressområdet med tillhörande nätparametrar som servern tilldelar leaser från. Gatewayen måste ligga i klientnätet och vara nåbar; en DNS-server måste vara nåbar från klienten. Säkerhetskopiera befintliga scopes, reläagenter och routes före ändringen och använd en testklient som hämtar adresser automatiskt via DHCP.

Krav och begränsningar

DHCP-servern måste ha ett scope för 10.20.0.0/24. Sophos Firewall utfärdar inte leasen själv, utan använder reläinterfacets adress så att servern väljer rätt scope.

Reläet behöver en route till servern och servern en returväg till 10.20.0.1.

Om brandväggen i stället ska tilldela adresser direkt i det anslutna klientnätet passar Konfigurera Sophos Firewall som DHCP-server. DHCP-alternativ konfigureras på servern som utfärdar leasen.

DHCPv4-server och relä kan också användas på samma Sophos Firewall:

• Servern lyssnar på ett annat interface.
• Accept client request via relay är aktiverat.
• Varje klientsubnät har ett eget serverscope med lämpligt leaseintervall, subnätmask, gateway och DNS.

Reläagenten använder respektive klientinterface och adressen till serverinterfacet som mål. Klienter i serverns subnät får fortfarande adresser direkt utan relä.

En DHCPv6-server och ett DHCPv6-relay kan inte vara aktiva samtidigt. Om brandväggen själv ska distribuera IPv6-adresser beskriver Konfigurera en DHCPv6-server på Sophos Firewall den separata proceduren med Router Advertisement, DUID och leasekontroll.

Följande begränsningar gäller:

• Reläinterfacet måste ligga i samma subnät som klienterna och får inte vara DHCP-serverns interface.
• Reläagenter kan använda fysiska och virtuella interface som VLAN, Wireless eller Bridge, men inte ett Interface Alias.
• Skapa ingen reläagent i DHCP-serverns subnät.
• Skapa en separat reläagent för varje klientsubnät.
• Varje reläagent kan innehålla upp till åtta DHCP-servrar. Förfrågan skickas till alla och klienten använder det första erbjudandet.
• En DHCPv4-server och ett DHCPv4-relä kan köras på samma brandvägg, men inte på samma interface.
• En DHCPv6-server och ett DHCPv6-relä kan inte vara aktiva samtidigt på samma brandvägg.
• Klienten och reläet använder UDP 67 och 68; reläet och servern kommunicerar via UDP 67. Servern behöver en returväg till relä-IP-adressen 10.20.0.1.

Flera relämål bör leverera konsekventa nätverksparametrar och alternativ till samma klient, men adressallokeringen måste samordnas genom serverfailover enligt serverdokumentationen eller använda icke-överlappande dynamiska tilldelningsintervall. Olika svar leder annars till ett beteende som är svårt att återskapa.

Konfigurera DHCP Relay utan VPN

1. Öppna Network > DHCP.
2. Klicka på Add under Relay.
3. Ange ett tydligt namn, till exempel relay-clients-vlan20.
4. Välj IPv4 under IP version för detta exempel. Använd inte IPv4-adresserna eller UDP-portarna från denna guide för IPv6.
5. Välj klientinterfacet VLAN20 - 10.20.0.1 under Interface.
6. Ange servern 172.16.16.17 under DHCP server IP, klicka på plusknappen för att lägga till adressen i listan och kontrollera att den visas där.
7. Låt Relay through IPsec vara avstängt och spara.

Förnya sedan en lease från en testklient. Reläförfrågningar är systemgenererad trafik, så proceduren behöver ingen separat brandväggsregel på reläbrandväggen. Enheter mellan reläet och servern måste ändå tillåta UDP 67 i båda riktningarna; klientsegmentet använder UDP 67/68. Om klienten inte får någon adress kontrollerar man först att servern har ett scope för 10.20.0.0/24 och känner till en route till reläinterfacet. Vid VLAN-problem, se Konfigurera ett VLAN-interface på Sophos Firewall.

XML-API: identitet och gränsen för IPv6-validering

Vid automatisering hör samma konfiguration till objektet DHCPRelay: Name anger reläagentens namn, Interface klientinterfacet, IPFamily den uttryckligen valda adressfamiljen IPv4 eller IPv6 och DHCPServerIP serverlistan. Dokumentationen för Add/Edit i SFOS 22 och 23 markerar dessa fyra fält som obligatoriska; det dokumenterade standardvärdet för IPFamily är IPv4. DHCPServerIP beskrivs som en ARRAY med IPADDRESS och IPADDRESS6: flera värden är tillåtna, dubbletter ignoreras och LINKLOCAL är uteslutet. Därmed är flera relämål fortfarande möjliga; det enda platshållarfältet i exemplet visar varken hur listan serialiseras eller hur IPv6 kodas. Behåll medvetet rätt tillstånd för Relay through IPsec utifrån den VPN-variant som förklaras nedan, och härled det inte från ett API-exempel.

Parametertabellen anger samtidigt högst 15 tecken för DHCPServerIP. Den uppgiften är inte generellt förenlig med den tillåtna representationen av IPv6-adresser med IPADDRESS6: dokumentationen är inkonsekvent på denna punkt och visar inte hur validatorn i den aktuella builden hanterar IPv6. Detta innebär varken att DHCPv6-relä inte stöds i produkten, att en alternativ kodning ska användas eller att adresser får kortas ned.

För IPv6 ska man först använda manuell konfiguration i WebAdmin och, före IPv6-automatisering, klargöra schemat, adressvalideringen och serverlistans format för den exakta SFOS-versionen och builden med Sophos Support. En sparad GUI-konfiguration eller en lyckad klientlease bekräftar inte att en IPv6-XML-begäran är giltig. Kontrollerna av klienten och paketflödet samt återställningen utifrån det tidigare tillståndet som beskrivs nedan krävs fortfarande; IPv4-adresserna och UDP-portarna i detta exempel ska inte användas för IPv6.

Ändra Relay-uppdateringsintervallet endast avsiktligt

Device Console visar det globala intervallet för DHCP Relay-uppdateringspaket med:

system dhcp dhcp-relay-refresh-interval show

Det dokumenterade standardvärdet är 10 sekunder. Sophos anger två olika övre gränser på samma SFOS 22-sida: syntaxen visar 10000, medan alternativbeskrivningen anger 1000 sekunder. Använd därför inte ett värde över 1000 enbart baserat på syntaxraden. Bekräfta först eventuella undantagsbehov med Sophos Support.

Ändringen använder följande mall:

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

Ersätt platshållaren med ett verifierat värde. Ändra inte intervallet som allmän tuning; det löser inte ett saknat serverscope, routing, IPsec eller brandväggsregler. Dokumentera först aktuellt värde, använd sedan show, hämta en ny klientlease och kontrollera UDP 67/68-paketflödet. Rollback återställer det tidigare lästa värdet.

DHCP Relay via route-based IPsec

Hjälpen för SFOS 22 och SFOS 23 dokumenterar DHCP Relay via XFRM till en extern DHCP-server bakom den centrala brandväggen. Den beskrivna konfigurationen använder en route-based Any-to-Any-tunnel. Route-based Traffic Selectors är inte bekräftade för detta arbetsflöde.

⚠️ Den officiella hjälpen är motsägelsefull i SFOS 22 och SFOS 23: både översikten DHCP och Routing and NAT for IPsec tunnels anger att DHCP Relay inte kan användas via route-based VPN. Add a DHCP relay och den separata route-based-guiden beskriver däremot följande Any-to-Any-konfiguration. Detta räcker inte för att fastställa att produkten stöder konfigurationen. Om fälten skiljer sig åt ska man inte använda policy-based-alternativ som ersättning, utan reda ut topologin och den exakta builden med Sophos Support.

⚠️ Konflikten mellan källorna är fortfarande olöst; stödet för designen måste klarläggas för den aktuella SFOS-builden. Före införandet måste Sophos Support klargöra stödet för den exakta SFOS-builden och Any-to-Any-topologin med en extern DHCP-server. Den bekräftelsen är ett förhandskrav. Gör inga route-based konfigurationsändringar enligt den här proceduren förrän frågan är klargjord.

Den dokumenterade konfigurationen omfattar följande förutsättningar. Tills frågan har retts ut med Sophos Support ska detaljerna endast användas för planering; konfigurationsändringar görs först efter bekräftelse:

1. Any-to-Any-IPsec-anslutningar på båda brandväggarna.
2. Adresserade XFRM-interface med gateway.
3. Statiska, SD-WAN- eller dynamiska routes på båda brandväggarna: från reläet till DHCP-servern och för svaret tillbaka till relä-IP-adressen 10.20.0.1.
4. Tillåten IPsec-åtkomst under Administration > Device access för de berörda WAN-interfacen.
5. En regel på huvudkontoret från VPN till serverzonen med Source 10.20.0.1, Destination 172.16.16.17 och Service DHCP.

På filialen anges klientinterfacet för reläagenten; Relay through IPsec förblir avstängt. Reläförfrågan är systemgenererad trafik där och behöver ingen egen DHCP-brandväggsregel.

En SD-WAN-route använder:

• Source: Any.
• Destination: värden 172.16.16.17.
• Service: DHCP.
• Den fjärranslutna XFRM-gatewayen.

På den centrala platsen går returvägen från DHCP-servern till relä-IP-adressen 10.20.0.1 via XFRM-gatewayen.

Om man vill förhindra att denna trafik tar vägen via en annan gateway när tunneln går ned aktiverar man Route only through specified gateways i båda de dedikerade SD-WAN-routesen.

För de dedikerade SD-WAN-routesen gör man följande efter bekräftelsen:

1. Öppna Routing > SD-WAN routes.
2. Välj IPv4 > Add och ange ett tydligt namn.
3. Under Link selection settings, välj Primary and backup gateways.
4. Under Primary gateway, ange rätt XFRM-gateway för respektive brandvägg.
5. Spara sedan.

Brandväggsregeln på den centrala platsen skapas under Rules and policies > Firewall rules > Add firewall rule > New firewall rule med de värdar och den tjänst som anges ovan.

Destination zone motsvarar det faktiska servernätet, till exempel DMZ, och är inte automatiskt LAN.

Fail-closed-alternativet förhindrar alternativ routing, men innebär också att inga nya leaser kan hämtas via denna väg om tunneln går ned.

De allmänna VPN-reglerna för Any-to-Any-tunneln måste också finnas. Konfigurera Site-to-Site IPsec på Sophos Firewall beskriver konfigurationen av tunneln och XFRM-routes i detalj.

⚠️ Den här route-based-proceduren gäller för en extern DHCP-server bakom huvudkontorets brandvägg. Ett Sophos Firewall-interface konfigurerat som central DHCP-server stöds inte i den här designen.

DHCP Relay via policy-based IPsec

Vid policy-based IPsec aktiveras Relay through IPsec på filialen. IPsec-anslutningens lokala subnät och fjärrsubnät måste omfatta reläinterfacet och DHCP-servern.

Om en extern DHCP-server finns bakom den centrala brandväggen behövs två regler där. En befintlig, fungerande tunnel är en förutsättning.

Om tunneln först måste skapas görs det under Site-to-site VPN > IPsec > IPsec connections > Add med Connection type: Policy-based:

• På filialen: Gateway type: Initiate the connection.
• På den centrala platsen: Respond only.
• Listening interface är det egna WAN-interfacet på respektive sida.
• Gateway address är motpartens WAN-adress.

Autentisering och Preshared key måste stämma överens. Lokala nät och fjärrnät speglas på motparten. För exemplet med en extern server är dessa 10.20.0.0/24 och det servernät som faktiskt används.

Tillåt IPsec-åtkomst från WAN under Administration > Device access.

På filialen behöver den systemgenererade relätrafiken ingen automatiskt skapad brandväggsregel. På den centrala platsen kan de automatiskt skapade reglerna begränsas till de DHCP-värdar, zoner och tjänster som anges nedan.

Ta inte bort befintliga regler för annan VPN-trafik.

• VPN till serverzonen: relänätet till DHCP-servern, Service DHCP.
• Serverzonen till VPN: DHCP-servern till klientnätet, Service DHCP.

För det dokumenterade policy-based-arbetsflödet måste källadressen för den systemgenererade relätrafiken sättas till relä-IP-adressen med sys-traffic-nat.

Följande kommandon körs i Device Console efter SSH-inloggning.

Den särskilda Routing/NAT-hjälpen för SFOS 22 och 23 skiljer mellan vidarebefordrad och systemgenererad trafik: för den senare behövs ingen ytterligare system ipsec_route. Den allmänna DHCP-översikten anger däremot fortfarande ett steg för en IPsec-route.

Denna skillnad är inget skäl att rutinmässigt lägga till en extra route: kontrollera först den befintliga routen och paketflödet och kontakta Sophos Support om builden beter sig annorlunda.

• NAT ersätter inte en route.
• destination förblir serveradressen.
• snatip är reläets källadress, inte serveradressen.
• En vanlig WAN-MASQ-regel ersätter inte sys-traffic-nat.

Spara det aktuella tillståndet före ändringen:

show advanced-firewall

⚠️ sys-traffic-nat add ändrar den globala NAT-konfigurationen för systemgenererad trafik. Destinationen och källadressen måste stämma med IPsec-tunneln och returvägen.

I exemplet anges reläinterfacets adress som källadress mot DHCP-servern:

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

Kör sedan show advanced-firewall igen och kontrollera att exakt den här posten finns. Servern måste kunna nå 10.20.0.1 genom tunneln. Om samma post fanns före ändringen ingår den inte i procedurens återställning.

För en post som skapats med den här proceduren är återställningen:

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

Skapa en IPsec Route på Sophos Firewall förklarar ytterligare policy-based routingfall och procedurer för äldre SFOS-versioner.

När huvudkontorets brandvägg är DHCP-server

Endast i det här policy-based-scenariot, där Sophos Firewall på huvudkontoret själv är DHCP-server, ska Create firewall rule lämnas avmarkerat i IPsec-anslutningarna på båda brandväggarna. DHCP-kommunikation med servern som körs på brandväggen är inte samma sak som vidarebefordran till en extern server; huvudkontorets vidarebefordringsregler som beskrivs ovan hör till scenariot med extern server. Behåll IPsec-åtkomst från WAN under Administration > Device access och de regler som behövs för annan VPN-användartrafik.

Om den centrala Sophos Firewall själv fungerar som DHCP-server vid policy-based IPsec skapar eller redigerar man ett serverscope under Network > DHCP > Server.

• Aktivera Accept client request via relay.
• Ange ett leaseintervall från 10.20.0.0/24.
• Sätt 10.20.0.1 som gateway.

På reläagenten anges den centrala brandväggens serverinterface som DHCP server IP. I det föregående NAT-exemplet ersätter dess adress på motsvarande sätt 172.16.16.17.

Ett anpassningsbart exempel för Dynamic IP lease är 10.20.0.10 till 10.20.0.30 med subnätmasken 255.255.255.0. Gatewayen 10.20.0.1 och fasta infrastrukturadresser hålls utanför poolen.

Välj poolen utifrån antalet klienter och redan reserverade adresser. Använd Use device’s DNS settings endast om DNS-servrarna som anges där är nåbara från filialen.

För denna brandväggsinterna server använder de policy-based-selektorerna på den centrala platsen serverinterfacets adress och klientnätet. På filialen gäller den omvända tilldelningen.

⚠️ Kontrollera versionen före en global ändring: Följande aktiveringsprocedur gäller endast det dokumenterade SFOS 22-scenariot. De tillgängliga hjälpsidorna för SFOS 23 motsäger varandra: HO firewall as DHCP server and BO firewall as relay agent beskriver DHCP-leases via IPsec som aktiverade som standard utan ytterligare konfiguration; DHCP-översikten anger fortfarande att de ska aktiveras via CLI. Konflikten är fortfarande olöst. Den bekräftar varken det faktiska tillståndet efter en uppgradering eller att kommandot har tagits bort. Aktivera inte den globala inställningen rutinmässigt på SFOS 23: dokumentera exakt build och aktuellt tillstånd och be först Sophos Support bekräfta om en ändring behövs. Om tillståndet är oklart eller statuskommandot inte är tillgängligt, stoppa före en ändring.

Notera exakt SFOS-build och visa och spara det aktuella tillståndet före varje ändring i Device Console på huvudkontorets brandvägg som utfärdar leaserna:

system dhcp lease-over-IPSec show

⚠️ Följande inställning gäller globalt för DHCP-leases via IPsec. Aktivera den endast på brandväggen som själv utfärdar leaserna. Notera det visade ursprungsläget så att återställningen inte stänger av en befintlig konfiguration.

Endast på SFOS 22, om det dokumenterade tillståndet är avstängt, aktivera inställningen och verifiera den sedan med föregående show-kommando. Ändra inget om den redan är aktiverad:

system dhcp lease-over-IPSec enable

Endast om funktionen tidigare var avstängd på huvudkontorets brandvägg som utfärdar leaserna och faktiskt aktiverades under den auktoriserade proceduren återställs den med:

system dhcp lease-over-IPSec disable

Om funktionen redan var aktiverad ska den lämnas aktiverad. I båda fallen bekräftar system dhcp lease-over-IPSec show det återställda tillståndet.

Testa konfigurationen och felsök fel

En sparad reläagent bevisar inte i sig att konfigurationen fungerar. Förnya leasen från en testklient och ange sedan ett snävt filter under Diagnostics > Packet capture > Configure i fältet Enter BPF string:

port 67 or port 68

I paketflödet bör följande synas i tur och ordning:

1. Klientförfrågan.
2. Den vidarebefordrade förfrågan.
3. Serverns Offer.
4. Returvägen.

Kolumnerna In interface, Out interface, Source IP, Destination IP, Ports [src, dst] och Status visar var utbytet slutar.

Reläpaket kan visas som Generated eller Forwarded. Vid Violation ger Reason en ledtråd om vad man ska kontrollera härnäst.

Användningen och fälten förklaras i Packet Capture i Sophos Firewall WebAdmin.

Ett Offer räcker inte: klienten måste begära adressen och få ett ACK. Kontrollera därefter:

• På klienten: att IP-adressen kommer från den avsedda poolen och att subnätmask, gateway och DNS stämmer.
• På servern som utfärdar leasen: leaseposten.

Ett pingsvar från servern bevisar varken nåbarhet via UDP eller ett lyckat DHCP-utbyte.

Dessa kontroller ska utföras av administratören.

Följande kontroller avgränsar vanliga fel:

• Ingen klientförfrågan syns: Kontrollera VLAN, switchport, klientinterface eller den lokala DHCP-klienten.
• Förfrågan når brandväggen men vidarebefordras inte: Kontrollera reläinterface, server-IP, route och vid policy-based IPsec Relay through IPsec.
• Servern får förfrågan men svarar inte: Kontrollera scopet för reläsubnätet, serverauktoriseringen och serverns lokala brandvägg.
• Offer når den centrala platsen men inte klienten: Kontrollera returväg, centrala brandväggsregler, IPsec-subnät och NAT-post.
• Klienten får fel konfiguration: Ta reda på vilken server som svarar först och jämför scopes och DHCP-alternativ på alla relämål.
• Policy rule denied med Source 0.0.0.0: En klient utan adress börjar med denna källadress. Kontrollera att en DHCP-server eller ett relä hanterar förfrågningar på rätt klientinterface; skapa inte en generell Allow-regel för 0.0.0.0 eller Any för att dölja symtomet. Översikten beskriver att DHCP-förfrågningarna kasseras när ingen DHCP-server är konfigurerad; i reläscenariot ska man kontrollera den faktiska paketvägen i stället för att dra slutsatsen att det finns en generell reläspärr.

Återställ konfigurationen

Kontrollera före en planerad återställning att klienterna kan nå en annan DHCP-server. Ta sedan bort reläagenten under Network > DHCP > Relay. Ta inte bort särskilda routes, värdobjekt och regler förrän Packet Capture inte längre visar reläförfrågningar; behåll objekt som delas med annan VPN-trafik. För policy-based IPsec tar man dessutom endast bort den sys-traffic-nat-post som skapades med den här proceduren. Återställ lease-over-IPSec endast på huvudkontorets brandvägg som själv utfärdar leaserna, och endast om tillståndet faktiskt ändrades under den auktoriserade proceduren; återställ då det tidigare noterade tillståndet. Detta ingår inte i återställningen för relä till en extern DHCP-server eller för ett oförändrat tillstånd.

Vanliga frågor