15
Sophos UTM DHCP-Relay - Requests über Transfernetz
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:
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:
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):
Interface Internal LAN (eth0):
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
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:
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:
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):
Interface Internal LAN (eth0):
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 653480
Url: https://administrator.de/contentid/653480
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
15 Kommentare
Neuester Kommentar
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
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
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.
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.
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:
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?
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?
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
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
Moin,
wie immer: Wireshark auf dem DHCP Server und schauen, ob was ankommt. Dann gehts weiter.
Grüße
wie immer: Wireshark auf dem DHCP Server und schauen, ob was ankommt. Dann gehts weiter.
Grüße
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:
Probleme mit DHCP Relay und Firewalls
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 !!
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:
Probleme mit DHCP Relay und Firewalls
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 !!
1
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
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
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
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
Hi Leute,
vielen Dank für eure Antworten.
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.
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?
Schaue ich mir auf jeden Fall nochmal an, glaube aber nicht, dass wir diese nochmal gesondert filtern.
Schaue ich mir auch nochmal an. Vielleicht habe ich wirklich irgendwas dummes übersehen.
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
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
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.
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 !
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 ?
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:
Probleme mit DHCP Relay und Firewalls
Probleme mit DHCP Relay und Firewalls
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?
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,
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.
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
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:
Jetzt weiß ich zumindest, dass ich im Netzwerk nach dem Problem suchen muss.
Ich halte euch auf dem Laufenden
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:
Jetzt weiß ich zumindest, dass ich im Netzwerk nach dem Problem suchen muss.
Ich halte euch auf dem Laufenden
Hallo,
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
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
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 !
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 !
Hallo,
Grüße
lcer
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."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 !
Grüße
lcer
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.
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.
👏 Glückwunsch !
1
