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.

Exemplet använder klientnätet 10.20.0.0/24, reläinterfacet 10.20.0.1 och DHCP-servern 172.16.16.17.

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.

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 identiska scopes och alternativ till samma klient. 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 IP version.
5. Välj klientinterfacet VLAN20 - 10.20.0.1 under Interface.
6. Ange 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 konfigurationen.

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.

Ä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

SFOS 22-hjälpen dokumenterar DHCP Relay via XFRM till en extern DHCP-server bakom huvudkontorets brandvägg. Den dokumenterade designen använder en route-based Any-to-Any-tunnel. Route-based Traffic Selectors är inte bekräftade för den här proceduren.

⚠️ Den officiella hjälpen motsäger sig själv här: DHCP-översikten anger att reläagenter för närvarande inte kan skapas via route-based VPN. Add a DHCP relay och den särskilda route-based-proceduren beskriver däremot följande design. Utvidga därför inte stödpåståendet till andra route-based-designer. Om fälten skiljer sig i den SFOS 22-build som används ska de inte ersättas med policy-based-alternativ; be Sophos Support bekräfta buildens beteende.

⚠️ Konflikten mellan källorna är fortfarande olöst; designen är dokumenterad, inte bekräftad eller testad som en produktfunktion. 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, inte ett bevis som redan finns här. Gör inga route-based konfigurationsändringar enligt den här proceduren förrän frågan är klargjord.

Följande krävs:

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 konfigureras klientinterfacet som reläagent och Relay through IPsec lämnas avstängt. Förfrågan är systemgenererad trafik och behöver ingen egen DHCP-brandväggsregel där. En SD-WAN-route använder Source Any, värden 172.16.16.17 som Destination, Service DHCP och fjärrsidans XFRM-gateway. På huvudkontoret skickar returrouten trafik från DHCP-servern till relä-IP-adressen 10.20.0.1 via XFRM-gatewayen. Aktivera Route only through specified gateways i båda de särskilda SD-WAN-routterna om trafiken inte ska växla till en annan gateway när tunneln ligger nere.

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

För 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 huvudkontorets brandvägg behövs två regler där:

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

För den dokumenterade policy-based-proceduren måste sys-traffic-nat ange relä-IP-adressen som källadress för den systemgenererade relätrafiken. Följande kommandon körs i Device Console efter inloggning via SSH. I SFOS 22.0 behöver den här systemgenererade trafiken ingen ytterligare system ipsec_route.

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 Sophos Firewall på huvudkontoret själv är DHCP-server via 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 och ställ in 10.20.0.1 som gateway. På reläagenten anges serverinterfacet på huvudkontorets brandvägg under DHCP server IP; dess adress ersätter då 172.16.16.17 i föregående NAT-exempel.

⚠️ 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

Paketflödet bör i tur och ordning visa klientförfrågan, den vidarebefordrade förfrågan, serverns erbjudande och returvägen. Kolumnerna In interface, Out interface, Source IP, Destination IP, Ports [src, dst] och Status visar var utbytet stannar. Reläpaket kan visas som Generated eller Forwarded. Vid Violation ger Reason nästa felsökningsledtråd. Packet Capture i Sophos Firewall WebAdmin förklarar kontrollerna och fälten.

Följande kontroller avgränsar vanliga fel:

• Ingen klientförfrågan syns: Kontrollera VLAN, switchport, klientinterface eller lokal DHCP-klient.
• Förfrågan når brandväggen men vidarebefordras inte: Kontrollera reläinterface, server-IP, route och Relay through IPsec för policy-based IPsec.
• Servern tar emot förfrågan men svarar inte: Kontrollera scope för reläsubnätet, serverauktorisering och serverns lokala brandvägg.
• Erbjudandet når huvudkontoret men inte klienten: Kontrollera returrouten, huvudkontorets brandväggsregler, IPsec-subnät och NAT-post.
• Klienten får en felaktig konfiguration: Identifiera vilken server som svarar först och jämför scopes och DHCP-alternativ på alla relämål.

Å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