DHCP für mehrere Subnetze

[Webbrauser 10]

Hallo miteinander,

 

wie immer beginnt ein Thread mit dem Eingeständnis eines Problems - beinahe wie in einer Selbsthilfegruppe - ich möchte euch also bitten mir bei der Lösung des Problems zu helfen:

 

Infos zum Aufbau:

 

Es gibt aus logischen Gründen 6 verschiedene Subnetze

 

172.26.1.0 /24 (Server)

172.26.2.0 /24 (Clients)

172.26.3.0 /24 (Peripherie (Drucket etc.))

172.26.99.0 /24 (Netzwerkgeräte)

192.168.200.0 /24 (DMZ 1)

10.0.0.0 /24 (DMZ 2)

 

Es gibt ein für alle geltendes Gateway - dabei handelt es sich um eine Watchguard XTM 330

 

ETH0 - External \ static WAN IP

ETH1 - Trusted \ 172.26.1.254 \ .2.254 \ 3.254 \ 99.254

ETH2 - External \ Dynamic WAN IP

ETH3 - DMZ \ 192.168.200.254 \ 10.0.0.254

 

Was die mehreren Gateways auf einem Port angeht : Ich bin mir bewusst, dass das für jeden Sicherheitsverliebten Administrator eine Hölle sein muss diese Konfiguration zu sehen aber im ERSTEN Schritte ging es hier nur um eine logische Trennung - nichts weiter.

 

Wo wir beim nächsten Problem wären:

 

ETH1 geht an einen (layer-2) Switch ohne konfigurierte VLANs - Die Konfiguration hierfür steht noch (aufgrund eines Hyper-V-Clusters) noch aus ist aber für das vorherrschende Problem nicht relevant

 

DHCP Snooping etc. ist NICHT aktiv.

 

Problem:

 

Mein DHCP Server ist der 172.26.1.3 - über diesen möchte ich auch für die Clients in 172.26.2.0 Adressen verteilen.

 

Nun habe ich auf ETH1 der Watchguard "DHCP-Relay" aktiviert und die IP-Adresse des DHCP-Servers angegeben.

In Ordnung - ich bin dann nach ein paar Minuten von selbst darauf gekommen, dass ein Broadcast schlecht routbar ist.... .

 

Ich habe mir dann gedacht, dann nehme ich doch einfach meinen VPN-Server als DHCP-Relay. Dieser hat die 172.26.1.253 und dient mir momentan als einfache Bereitstellung eines PPTP-VPN.

Dort habe ich den EINZIGEN LAN-Adapter (!) als Schnittstelle des DHCP-Relays hinzugefügt und die IP-Adresse auf ETH1 der Watchguard dementsprechend geändert.

 

Siehe da - die Anfragen (welche auch immer) rasseln fröhlich ein werden aber gleichermaßen wieder gelöscht.

Blick in die Ereignisanzeige - der DHCP-Server kann nicht erreicht werden. OK.

Ich habe dann dem DHCP-Relay Agenten auch die IP des DHCP Servers mitgeteilt :o ... .

Dort kommen aber, aufgrund des dortig konfigurierten Scopes, leider keine Anfragen an, da er lediglich 172.26.2.99 - 172.26.2.115 (Alles nur tests...) als Scope hinterlegt hat.

 

Also dachte ich mir: Okay - dann leg eben noch eine zweite Zone an - nur um auszumerzen, dass es hier im Netz irgendeinen Switch gibt der die weitergeleiteten DHCPoffers killt.

172.26.1.66 - 172.26.1.68

 

Tada! Clients tauchen auf.

 

Gut nun habe ich fleißig rumgespielt und festgestellt, dass ich wieder am Anfang stehe.

 

Um erstmal zu verhindern, dass mir am Montag die Struktur um die Ohren fliegt habe ich die Watchguard als zentralen DHCP-Server konfiguriert und den auf dem Server deaktiviert. Klappt einwandfrei - Adressen aus 172.26.2.x werden wie konfiguriert verteilt.

 

Nun dachte ich mir ich probier einfach von zuhause weiter und schau mir das ganze mal mit Wireshark etc. an - connectiere mich und stelle fest.

Ich bekomme eine IP von meiner Watchguard, so wie es auch sein soll, komme aber nun an nichtsmehr dran. Ping auf IP\Name ergebnislos, rdp klappt nichtmehr.

 

Ich bin mir nun ziemlich sicher, dass ich, wenn ich den Scope auf 172.26.1.x umstelle wieder fröhlich in meinem Netz umherschippern könnte - gehe ich also recht in der Annahme, dass ich hier meinen VPN-Server mit einer zweiten NIC in das entsprechende Subnet stellen muss? (börks)

 

Nun zu meiner eigentlichen Frage:

 

Ich bin kein Freund davon ein Netzwerkgerät DHCP spielen zu lassen und würde gerne für den Scope 172.26.2.99 - 172.26.2.115 meinen ursprünglichen DHCP-Server 172.26.1.3 nutzen.

 

1) Wieso klappt das mit einem DHCP-Relay nicht?

2) Wie krieg ich es hin, dass es klappt?

bearbeitet 26. Februar 2012 von Webbrauser

[Webbrauser 10]

Danke für eure Hilfe :-)

[Webbrauser 10]

Ich glaube es hat etwas mit meinen multiplen Gateways und dem Anschluss der Watchguard zutun:

 

Die Watchguard hat einen Uplink auf einen 16 Slot Gigabit switch (für Server) (VLAN-Fähig)

Dieser Gigabit Swith widerum einen auf einen 16 Port 10/100 (für Clients) (Nicht VLAN-Fähig)

 

Wie soll nun also der auf der firewall aktive dhcp-relay agent erkennen aus welchem Netz die Anfrage stammt um dem dhcp-server mittels Unicast um eine IP-Adresse aus jenem Bereich bitten

 

Kann es sein, dass ich einen VLAN-fähigen Switch brauche?

 

Helft mir mal beim Brainstorming :(

[lefg 276]

Off-Topic:
Hallo,

schon heute Mittag stellte ich fest, bei der Beschreibung bekomme ich keinen Durchblick, sie ist mir zu unstrukturiert. Ich müssste zu viel vermuten, das hielt ich nicht für hilfreich.

Wird da zwischen physikalischen Teilnetzen geroutet?

Was mich interessiert, wozu soll diese logische Trennung gut sein, welchesind die logisvchen Gründe? Wiewiele Hosts welcher Art sind da im Netz? Ich bin solchen Kontrukten schon öfters begegnet und habe die nach Möglichkeit konsolidiert.

Gruß

Edgar

bearbeitet 26. Februar 2012 von lefg

[rakli 13]

Hallo,

 

mir fehlt auch etwas der Durchblick :D, aber vielleicht hilft das:

 

...Die DHCP-Relay-Agent-Komponente kann nicht auf einem Computer verwendet werden, auf dem der DHCP-Dienst, die NAT-Routingprotokollkomponente (Network Address Translation, Netzwerkadressübersetzung) mit aktivierter automatischer Adressierung oder die gemeinsame Nutzung der Internetverbindung (Internet Connection Sharing, ICS) ausgeführt wird....

Quelle: Konfigurieren des IPv4-DHCP-Relay-Agents

 

Vielleicht liegt auch ein grundlegender Fehler vor, schau mal hier:

Grundlegendes zu Relay-Agents

Fragen zum Entwurf von Relay-Agents

 

Rainer

[lefg 276]

Wie wäre es mit einer Zeichnung?

[Webbrauser 10]

Hallo ihr zwei - danke für die Anteilnahme und die Links. Die habe ich allerdings auch alle schon durch.

 

Vielleicht zu deiner Frage nach dem Grund:

 

Ich finde es einfach extrem schön für die unterschiedlichen Netzteilnehmer eigene Subnetze zu bilden - da könnte ich jetzt einige fadenscheinige Gründe aufzählen aber letztlich gehts mir darum auf einen Blick zu erkennen in welchem Netz sich nun etwas befindet. Davon ab ist es beliebig erweiterbar.

 

Ich habe aber gerade eben beim Spaziergang noch einen Gedanken gehabt:

 

Auf dem Gigabit Switch sind momentan NUR Server

Auf dem 10/100er Switch NUR Clients

Die DMZ hängt schon direkt auf der Firewall (.. logisch,was? :-) )

 

Die Peripheriegeräte lass ich jetzt mal aussen vor und die Netzwerkgeräte brauchen keine DHCP-Adressen..

 

Ich könnte nun also meine Doppelten Gateways auf einem FW-Port überdenken und nochmal splitten bzw. dedizieren

 

kurzum sagen

 

ETH1 - Trusted - 172.26.1.254 /24

ETH4 - Trusted - 172.26.2.254 /24

 

So müsste dann ja der Watchguard-Eigene DHCP-Relay (auf beiden IFs einzustellen) funktionieren denn:

Die Broadcastanfrage erreicht letztlich nur das jeweilige Gateway des Subnetzes- kann nun also in das an den DHCP-Server weitergeleitete Unicast Paket die GIADDR so setzen, dass es aus dem Subnetz 26.1 oder eben 26.2 kommt und so die jeweilige Antwort anfordern.

Dafür müssten nur die jeweiligen Scopes am DHCP-Server vorgehalten werden damit für das jeweilige Subnetz ein DHCPOFFER erstellt wird... .

 

Soweit die Theorie.

 

Vielleicht habe ich euch mit dem vielen text auch einfach verwirrt - grundlegend ist meine Anforderung einfach:

 

Ich möchte, dass der DHCP-Relay der Firewall die Anfragen aus allen daran angeschlossenen Netzen an den DHCP-Server (den einen) ausliefert und aus den daran unterschiedlichen Subnetzen ( 26.1 , 26.2 , 26.3 , 26.4 --- und so weiter) antworten bzw. leases liefert.

 

Ich glaube aber, dass das Problem einfach darin gelagert ist, dass die Firewall momentan nicht erkennt aus welchem Netz die anfrage nun wirklich kommt da es keinen echte Terminierung in einem Subnet gibt weil alles momentan auf einem Port liegt.

 

Ausserdem sind die Switche momentan "in Reihe" gesteckt.

Also

 

Aus sicht vom Client:

 

Client->Switch->Gigabit Switch->Firewall ETH1 (172.26.1.254 , 172.26.2.254 , 172.26.3.254 )

 

Aus Sicht vom Server

 

Server -> Gigabit Switch -> Firewall ETH1 (172.26.1.254 , 172.26.2.254 , 172.26.3.254 )

 

Wenn ich es zukünftig nun so mache:

 

Server-> Gigabit Switch -> Firewall ETH1 - 172.26.1.0 /24

Client -> Switch -> Firewall ETH4 -> 172.26.2.0 /24

 

Dann sollte der Relay Agent doch auch raffen aus welchem Subnetz nun die Anfrage kam.

 

 

Agree?

 

Danke für eure Gedanken :-)

[varnik 10]

...Dann sollte der Relay Agent doch auch raffen aus welchem Subnetz nun die Anfrage kam.

 

...

Hi,

dein Problem liegt genau daran. Der Relay Agent kann nicht herausfinden, aus welchem logischen Netz die Anfrage stammt, da diese auf Ethernet-Ebene kommt.

[Webbrauser 10]

dacht ich es mir doch.

 

Vielen Dank für die Rückmeldung.

 

Ich werde meinerseits das ganze am Wochenende wie geschrieben umpatchen - momentan ist Produktivbetrieb - und dann hier schreiben ob nun alles so funktioniert wie es soll :-)

[Webbrauser 10]

Tadaa - kurzes Feedback.

 

Nachdem das Interface dediziert dem Subnet zugeordnet werden konnte klappts auch mit dem relay ;-) ...

Leases leben länger mit calgooon ... (...)