Sophos UTM DHCP-Relay - Requests über Transfernetz

Mitglied: Sideshow88

Sideshow88 (Level 1) - Jetzt verbinden

18.02.2021, aktualisiert 17:30 Uhr, 909 Aufrufe, 15 Kommentare, 2 Danke

Hallo IT-Kollegen,

ich wende mich nun mit meinem aktuellen Problem an euch, in der Hoffnung, dass ihr mir eine Idee oder den korrekten Weg aufzeigen könnt.

Ich versuche seit Tagen das DHCP-Relay unserer Sophos UTM (9.705-3) zum laufen zu bringen - leider ohne Erfolg.

Hier die aktuelle Struktur, um die es geht:
sophs_mvz - Klicke auf das Bild, um es zu vergrößern

Mein Ziel ist es, die Clients aus dem Remotenetz aus der Zweigstelle - wenn möglich - über unsere internen DHCP-Server aus dem Server-VLAN zu "betanken".

Die Verbindung eines Testclients über die Sophos RED60 bis hin zu den Client- und Server-VLANs funktioniert ohne Probleme, wenn ich dem Remote-Client eine fixe IP aus dem 172.Y.Y.0-Netz vergebe (getestet mit Ping-Anforderungen und RDP-Sitzungen). Firewallregeln und Einstellungen der Sophos und der RED im Bezug auf den Tunnel scheinen also erst einmal korrekt konfiguriert zu sein.

Nächster Schritt war also DHCP. Auf der Sophos habe ich folgendes im DHCP-Relay-Tab konfiguriert:
dhcp-relay1 - Klicke auf das Bild, um es zu vergrößern
Sophos verlangt hier wohl zusätzlich zum Ziel auch alle Interfaces, über die DHCP-Requests versendet/empfangen werden.
Leider erstellt der DHCP-Server, der vorher natürlich einen entsprechenden Scope (172.Y.Y.0/24) konfiguriert hat, keine Lease.
Ein tcpdump auf der Sophos zeigt folgendes:

Interface MVZ-K... (reds1):
tcpdump_reds1 - Klicke auf das Bild, um es zu vergrößern

Interface Internal LAN (eth0):
tcpdump_eth0 - Klicke auf das Bild, um es zu vergrößern

Keine entsprechenden Pakete verlassen das interne Interface.

Ich dachte mir nun, dass es mit Sicherheit daran liegt, dass der DHCP-Server in der Relay-Konfiguration der Sophos UTM in keinem Netz der beiden Interfaces liegt und deshalb das Relay seinen Dienst von vornherein verweigert.
Was ich schwachsinnig empfinden würde, weil warum sollte man nicht auch einen "entfernten" DHCP-Server als Ziel nehmen können, wenn doch der Unicast-Traffic ab dem Relay doch auch geroutet werden kann. Egal.

Meine Idee war nun, anstatt den DHCP-Server, der nicht in den gleichen Netzen erreichbar ist, wie die Interfaces, den Cisco-Core-Switch als Ziel des Relays zu nehmen und dann mit der ip-helper-address auf dem Core auf den DHCP-Server weiter zu verweisen. Mittlerweile denke ich, dass das nicht funktionieren wird, da der Core eigentlich den DHCP-Payload (also Relay-IP-Adresse) durch seinen eigenen austauschen müsste.
Unabhängig davon funktioniert das aber leider exakt genauso wenig. Keine Pakete verlassen das Interface eth0 obwohl das vorher von mir genannte für die Sophos ja keine Rolle spielen sollte. Forwarden müsste sie die Pakte ja trotzdem und in Richtung des Cores senden.

Gibt es hier weitere Möglichkeiten des Fehler einzugrenzen? Erstellt die Sophos Logfiles explizit für das Relay? Wenn ja, wo finde ich diese? Das DHCP-Log der Sophos zeigt auf jeden Fall nichts an. Das wird daran liegen, dass die Sophos auch nicht als DHCP-Server fungiert.

Ich weiß nicht ob ich gerade vor lauter Bäumen den Wald nicht mehr sehe, oder einfach nur einen Denkfehler habe, wäre aber wirklich sehr dankbar, wenn sich jemand das Szenario einmal anschauen und bewerten könnte. Evtl. habe ich es auch mit einem Bug in der Sophos FW zu tun. Vielleicht kann hier jemand von ähnlichen Problemen mit der gleichen Sophos-Version berichten?

Letzte Möglichkeit wäre, wenn keine Schritte zum Erfolg führen:
- Sophos Support kontaktieren (ich denke jeder weiß, was mich da nun erwartet)
- für das Remote-Netz die Sophos UTM als DHCP-Server fungieren lassen. Das möchte ich vermeiden, da ich eine zentrales Management doch bevorzuge.

Vielen Dank schon Mal für eure Zeit.


LG

Niko
Mitglied: Doskias
18.02.2021 um 16:53 Uhr
Moin,
Bevor du den Support kontaktierst, schau mal ob du dich hieran orientiert hast:
https://utm-shop.de/information/anleitungen/sophos-firewall-os-version-1 ...

Gruß
Doskias
Bitte warten ..
Mitglied: Sideshow88
18.02.2021, aktualisiert um 17:18 Uhr
Hallo,

danke für den link.
Wenn, dann habe ich mich hieran orientiert.
UTMshop - Hilfe
Viel mehr ist die Konfiguration eigentlich nicht.

Dein Link verweist auf eine andere Software.
Bitte warten ..
Mitglied: Doskias
18.02.2021 um 18:06 Uhr
Dein Link verweißt auf UTM Online, meiner nicht. hast du denn Online? davon steht oben nichts.

In meinem link steht zum Beispiel die IP-Sec funktion beschrieben, wie man sie konfiguriert bzw:
Hier werden DHCP-Meldungen über einen IPSec-VPN-Tunnel weitergeleitet.

Die Option fehlt bei deinem Link zum beispiel, aber soweit ich mich erinnere baut die Sophos Red immer einen IPSec-VPN-Tunnel auf. Vielleicht ist das schon der Knackpunkt?
Bitte warten ..
Mitglied: Sideshow88
18.02.2021, aktualisiert um 18:35 Uhr
Hi Doskias,

in deinem Link habe ich die beschriebenen Menüs gar nicht. Die in meinem schon, weshalb ich den verlinkt habe.

Der Tunnel sollte eigentlich nicht das Problem sein, da die DHCP-Requests ja sauber beim Interface der UTM ankommen (siehe tcpdump). Oder habe ich hier etwas übersehen?

Vielen Dank und VG
Bitte warten ..
Mitglied: Xaero1982
18.02.2021 um 19:28 Uhr
Moin,

wie immer: Wireshark auf dem DHCP Server und schauen, ob was ankommt. Dann gehts weiter.

Grüße
Bitte warten ..
Mitglied: aqui
18.02.2021, aktualisiert um 20:01 Uhr
Du bist mit deiner Erklärung des DHCP Relays schon auf dem richtigen Weg....
Die Funktion ist das die DHCP Broadcasts im lokalen LAN vom Router (bzw. Firewall in deinem Falle), aufgenommen werden. Der Relay Agent (Firewall) ersetzt dann die Absender IP mit seiner eigenen Interface IP, also bei dir dann die des internen LAN Interfaces und forwardet das als Unicast Frame an den DHCP Server. In dem so einfach zu routenden DHCP Paket steht dann als Absender IP die lokale LAN IP der Sophos und als Ziel IP die des DHCP Servers. Und ja...es wird dann rein per simplen IP Routing zum Ziel DHCP Server geforwardet.

Da dein Regelwerk ja so eingestellt ist das alle lokalen LAN IPs das Zielnetz des DHCP Servers über den Tunnel erreichen können gibts da ja scheinbar auch keinen Hinterdungsgrund, es sei denn du filterst irgendwo dediziert UDP 67 und 68 Frames ?!
Dieser Thread hier erklärt dir inklusive kommentierter Wireshark Sniffer Traces noch einmal die genau DHCP Relay Funktion im Detail:
https://administrator.de/forum/probleme-dhcp-relay-firewalls-643448.html

Was bei dir auffällt ist das die Client DHCP Request im Segment "MVZ-K... (reds1)" zu sehen sind wo sie eigentlich rein gar nichts zu suchen haben. Wenn überhaupt, sollten sie aus dem lokalen LAN kommen aber nie und nimmer nicht aus dem Transfer Segment.
Das legt den bösen Verdacht nahe das es hier ggf. eine falsche Port- oder VLAN Zuweisung gibt, denn das darf eigentlich niemals so sein das diese Frames dort so zu sehen sind !
In den Transfer Netzen solltest du immer schon den Unicast sehen die also eine dedizierte Absender und Ziel IP haben aber niemals den original Client Request den du immer daran erkennst das er als Absender 0.0.0.0 und Ziel einen All Net Broadcast 255.255.255.255 hat.
Der Relay hat immer nur rein das Interface konfiguriert wo der Relay wirken soll und die DHCP Server IP. Der Rest wird geroutet und es ist unsinnig da alle IP Netze zu definieren die dazwischen sind. Vergiss das also.
Wichtig ist nur das diese Frames nirgendwo auf ihrem Weg zum Ziel durch ein FW Regelwerk gefiltert werden. Das gilt auch für die Rückantwort !

Hier macht es also durchaus Sinn einmal mit dem Wireshark anzusetzen und dort zu checken ob vom DHCP Relay diese entsprechenden Unicast Frames kommen und ganz besonders ob diese Unicasts auch direkt am DHCP Server ankommen.
Wenn das der Fall ist sähe man Antwort Frames vom Server. Wenn nicht kommen die gar nicht erst am Server an und das Problem liegt davor ! Das hier ein Konfig Fehler vorliegt ist klar.
Wie Kollege @Xaero1982 schon absolut richtig sagt: Wireshark ist hier dein bester Freund !! ;-) face-wink
Bitte warten ..
Mitglied: lcer00
18.02.2021 um 21:08 Uhr
Hallo,

ganz doofe Frage. Du hast den DHCP Server offenbar als FQDN angegeben. Funktioniert das DNS?

Hast Du mal versucht, statt des Relay den DHCP-Server versucht? Das würde die Funktionalität des Eingangsinterfaces bestätigen.

Grüße

lcer
Bitte warten ..
Mitglied: chgorges
18.02.2021 um 22:06 Uhr
Moin,

das Setup ist noch etwas unklar, was genau macht die RED im Branch Office? Gateway des Branch-Office ist ja offensichtlich die UTM.

Der Cisco 9500 ist das Gateway des DHCP-Servers? Wenn ja, brauchst du im Transfernetz auf jeden Fall den IP Helper, sonst schickt der Cisco gar nichts Richtung Branch-Office.

VG
Bitte warten ..
Mitglied: Sideshow88
19.02.2021, aktualisiert um 08:34 Uhr
Hi Leute,

vielen Dank für eure Antworten.

Xaero1982 (Level 4) - Jetzt verbinden
18.02.2021 um 19:28 Uhr
Moin,
wie immer: Wireshark auf dem DHCP Server und schauen, ob was ankommt. Dann gehts weiter.

Tut mir Leid, das habe ich nicht erwähnt. Ich habe bereits Wireshark mit dem Mitschnittfilter für DHCP-Pakete (Port 67 und 68) auf dem DHCP-Server laufen lassen und es kommen keine entsprechenden Anfragen an. Aus den anderen, internen VLANs kommen die Anfragen ganz normal über die ip-helper-Eintragungen im Core an.

aqui (Level 5) - Verbunden
18.02.2021, aktualisiert um 20:01 Uhr
Was bei dir auffällt ist das die Client DHCP Request im Segment "MVZ-K... (reds1)" zu sehen sind wo sie eigentlich rein gar nichts zu suchen
haben. Wenn überhaupt, sollten sie aus dem lokalen LAN kommen aber nie und nimmer nicht aus dem Transfer Segment.
Das legt den bösen Verdacht nahe das es hier ggf. eine falsche Port- oder VLAN Zuweisung gibt, denn das darf eigentlich niemals so sein das > diese Frames dort so zu sehen sind !

Die Requests werden ja von den Clients aus dem Remote-LAN "MVZ-K...." erstellt und gelangen dann via Broadcast zur Sophos UTM auf dem Interface "MVZ-K...", welches in diesem Netz angeschlossen ist. Dann muss ich diese doch via tcpdump auf dem Interface sehen?
Gleichzeitig müsste ich doch, wenn das Relay richtig funktioniert, den DHCP-Verkehr (also Port 67 und 68) auf dem ausgehenden Interface eth0 sehen? Ich meine, tcpdump ist ja quasi Wireshark auf der Sophos.
Ich bin mir ehrlich gesagt nicht sicher, was du meinst^^, oder hast du evtl. etwas missverstanden?

Da dein Regelwerk ja so eingestellt ist das alle lokalen LAN IPs das Zielnetz des DHCP Servers über den Tunnel erreichen können gibts da ja
scheinbar auch keinen Hinterdungsgrund, es sei denn du filterst irgendwo dediziert UDP 67 und 68 Frames ?

Schaue ich mir auf jeden Fall nochmal an, glaube aber nicht, dass wir diese nochmal gesondert filtern.

Dieser Thread hier erklärt dir inklusive kommentierter Wireshark Sniffer Traces noch einmal die genau DHCP Relay Funktion im Detail:
https://administrator.de/forum/probleme-dhcp-relay-firewalls-643448.html

Schaue ich mir auch nochmal an. Vielleicht habe ich wirklich irgendwas dummes übersehen.

lcer00 (Level 2) - Jetzt verbinden
18.02.2021 um 21:08 Uhr
Hallo,

ganz doofe Frage. Du hast den DHCP Server offenbar als FQDN angegeben. Funktioniert das DNS?

Das sind nur Objektnamen in der Sophos. Die Sophos verwendet hier die von mir manuell hinterlegte IP-Adresse.

Ich gehe nochmal alles durch und gebe euch eine Rückmeldung.
Vielen Dank schon mal für eure Hilfe!


EDIT 19.02.2021 - 08:29

chgorges (Level 2) - Jetzt verbinden
18.02.2021 um 22:06 Uhr
Moin,

das Setup ist noch etwas unklar, was genau macht die RED im Branch Office? Gateway des Branch-Office ist ja offensichtlich die UTM.
Der Cisco 9500 ist das Gateway des DHCP-Servers? Wenn ja, brauchst du im Transfernetz auf jeden Fall den IP Helper, sonst schickt der
Cisco gar nichts Richtung Branch-Office.

Sorry, Chgorges, habe irgendwie dein Kommentar überlesen. Deshalb der Edit.

Ich habe da nicht viel konfiguriert. IP-Adresse der UTM eingetragen, Modus auf Standard/unified gesetzt und sich selbst über DHCP eine Adresse vom DSL-Router geben lassen. Funktioniert!

Der 9500er Core ist der GW des DHCP-Server und hat in jedem VLAN den entsprechenden ip-helper-Eintrag.

VG
Niko
Bitte warten ..
Mitglied: Sideshow88
19.02.2021 um 08:26 Uhr
Oh mein Gott. Neue Erkenntnis....
Scheinbar stimmte die ganze Zeit was nicht mit der Syntax von meinem tcpdump, weshalb er mir auf dem eth0 nichts mehr angezeigt hat. Mach ich die "and"-Verknüpfung beim Dump auf dem eth0 weg, sehe ich die Pakete. Komisch ist, dass er die Pakte auf dem anderen Interface auch mit der "and"-Verknüpfung zeigt. Das muss ich mir also auch mal für die Zukunft nochmal anschauen.
Die Pakete verlassen also doch richtiger Weise das Interface eth0, wurden mir nur nicht angezeigt, weshalb ich jetzt die ganze Zeit komplett auf der falschen Spur war und bei der Sophos das Problem gesucht habe. Verdammt ärgerlich....

Beide Fenster zeigen den Verlauf gleichzeitig an:
tcpdump_kombi1 - Klicke auf das Bild, um es zu vergrößern
tcpdump_kombi2 - Klicke auf das Bild, um es zu vergrößern

Jetzt weiß ich zumindest, dass ich im Netzwerk nach dem Problem suchen muss.

Ich halte euch auf dem Laufenden :-) face-smile
Bitte warten ..
Mitglied: lcer00
LÖSUNG 19.02.2021 um 09:18 Uhr
Hallo,


Zitat von @Sideshow88:

Jetzt weiß ich zumindest, dass ich im Netzwerk nach dem Problem suchen muss.


OK. Das Relay funktioniert also.

Ich würde erst mal das Szenario ohne IP Helper im Cisco versuchen. Dazu solltest Du die Routen zum Server hin überprüfen.

Bei dem Cisco sollte es eine Option geben, DHCP nur von bestimmten Ports aus zu akzeptieren. Bei meinen SG350Xs unter "DHCP Snooping Trusted Interfaces". Schau nach, nicht dass da die Pakete gefiltert werden.

Grüße

lcer
Bitte warten ..
Mitglied: aqui
LÖSUNG 19.02.2021, aktualisiert um 10:52 Uhr
IP Helper im Cisco sind einzig nur dann erforderlich wenn dort auch DHCP Clients in anderen IP Segmenten (VLANs) sind die IPs vom zentralen DHCP Server beziehen.
Für die weitergelieteten Unicast Pakete des Sophos Relays ist das logischerweise nicht erforderlich da diese Pakete, wie der TO schon richtig vermutet, als Unicast ganz normal geroutet werden.
"DHCP Snooping Trusted Interfaces" sind dort auch einzig und allein nur relevant wenn der TO dort aus Sicherheitsgründen DHCP Snooping aktiviert hat. Hat er das nicht global aktiviert ist das irrelevant !
Bitte warten ..
Mitglied: lcer00
19.02.2021 um 11:09 Uhr
Hallo,
Zitat von @aqui:

"DHCP Snooping Trusted Interfaces" sind dort auch einzig und allein nur relevant wenn der TO dort aus Sicherheitsgründen DHCP Snooping aktiviert hat. Hat er das nicht global aktiviert ist das irrelevant !
Nun, das wissen wir ja nicht.

Grüße

lcer
Bitte warten ..
Mitglied: Sideshow88
22.02.2021 um 13:28 Uhr
Hi Leute,

nochmal vielen Dank an alle für eure Hilfe. Das Forum hier mit der angebotenen Hilfe ist Spitze!

Ich habe heute Morgen herausgefunden wo dran es gelegen hat.
Und zwar hat unser Dienstleister bei Aufbau der neuen Netzwerkstruktur vor 2 Jahren korrekterweise DHCP-Snooping global und für alle VLANs aktiviert. Somit waren die trusted Interfaces natürlich nur für die vorhandene DHCP-Struktur und nicht auch für diese Erweiterung um das zusätzliche DHCP-Relay der Sophos konfiguriert. Also habe ich die entsprechenden trunk-Ports als trust konfiguriert und siehe da.... es funktioniert.

Da ich nicht täglich Netze designe (bin "normaler" Server- und Netzwerkadministrator), war mir diese Funktion leider nicht in solchem Umfang bekannt, weshalb ich euch hierzu nicht mehr Infos geben konnte. Aber man lernt bekanntlich nie aus, was vor allem in unserem Beruf einfach toll ist!

Die Antworten von den Kollegen Icer00 und Aqui waren also demnach hier definitiv die richtigen! (Auch wenn ich diese zum Thema Snooping erst jetzt bei Erstellung dieser Antwort gelesen habe :P)

PS:
Noch zu den tcpdumps der Sophos:
Mein Fehler war hier, dass ich die beiden DHCP-Ports, also 67 und 68 mit "and" verknüpft habe, was natürlich nur die Pakte angezeigt hat, die auch beide enthalten. Das war Blödsinn und hätte mit "or" verknüpft werden müssen. Lustigerweise: Beim Wireshark auf dem DHCP-Server hatte ich es mit "or" verknüpft... Ich habe also wirklich den Wald vor lauter Bäumen nicht mehr gesehen. Dadurch habe ich mich leider selbst zuerst auf eine falsche Fährt gesetzt.


Also nochmal vielen Dank an alle für die Zeit und Hilfe.
Bitte warten ..
Mitglied: aqui
22.02.2021 um 13:34 Uhr
👏 Glückwunsch !
Bitte warten ..
Heiß diskutierte Inhalte
LAN, WAN, Wireless
Unterschiedliche IP-Adressbereiche im Netzwerk
achkleinVor 1 TagFrageLAN, WAN, Wireless17 Kommentare

Hallo, ich stehe vor einem Problem mit der WLAN-Verbindung zum Router (Fritzbox Cable 6490). Das verbundene Notebook hat die Adresse 192.168.0.164, Gateway ist 192.168.0.149: ...

Off Topic
Microsoft und der (leidige) Datenschutz
Franz-Josef-IIVor 1 TagAllgemeinOff Topic18 Kommentare

Hello Ich möchte vorausschicken, daß ich rein prinzipiell nichts gegen Microsoft habe, eher gegen die US-amerikanische Politik 😊 Microsoft bietet die Datenverarbeitung in der ...

Off Topic
32 bit Problem
brammerVor 1 TagAllgemeinOff Topic9 Kommentare

Hallo, also das ist mal ein Problem das ich auch haben möchte eine Aktie ist mehr Wert als das die Börsensoftware darstellen kann. brammer

Hardware
Thin- oder Zero-Client für RDP und Dual-Monitor im LAN gesucht
FestplattenaufzieherVor 1 TagFrageHardware9 Kommentare

Hallo, Kurzfassung meiner Frage: Ich suche Thin/Zero-Clients (4 Stück) mit Dual-Monitor-Unterstützung für den RDP-Zugriff auf PCs in einem LAN - idealerweise lautlos und relativ ...

Windows Server
Lizenzen für Virtualisierungshost
TakworianVor 10 StundenFrageWindows Server15 Kommentare

Hallo, ich werde demnächst einen HA-Cluster aus 3 x HP DL580 in Betrieb nehmen. Der Cluster wird unter Proxmox betrieben und es sollen diverse ...

Windows 10
Windows 10 2021-04 end of life?
gelöst Paedi12Vor 1 TagFrageWindows 103 Kommentare

Hi Leute! Ich bin gerade auf der Suche, wie lange die Windows Version 2021-04 unterstützt wird. Kann aber nichts finden. Hat jemand eine Ahnung, ...

Switche und Hubs
Netgear Switch Problem bei VLAN Konfiguration
gelöst meltersVor 1 TagFrageSwitche und Hubs15 Kommentare

Hallo, ich habe einen Netgear XS716T Switch zum Testen in Betrieb genommen, komme aber mit der VLAN Konfiguration nicht so ganz klar. Bislang habe ...

Router & Routing
Suche Tipps für Selfmade-Load-Balancing-Router auf HP MicroServer Gen10+
gelöst MagicChris86Vor 1 TagFrageRouter & Routing7 Kommentare

Hi Leute, ich habe einen HP MicroServer Gen10+ Performance übrig, der bei einer Kundin rausgeflogen ist, weil sie mehr Power brauchte für Desktopvirtualisierung für ...