Standardgateway per DHCP nicht zugewiesen

[pfeffis 11]

Hallo @ all!

 

Habe hier eine W2k Domäne. Der DC ist auch als DHCP Server konfiguriert. Alle Clients die intern eine Ip beziehen bekommen alle Infos vonm DHCP geliefert (IP, DNS Server, Standardgateway). Wenn ich nun it einem Klapprechner eine VPN Verbindung aufbaue (Sonicwall), bekommen die Clients auch "alle" Informationen zugewiesen, nur eben nicht das Standardgateway. Habt ihr Ideen hierzu?

Die Bereichsoptionen sind im DHCP Server richtig hinterlegt (siehe internes LAN). Im DHCP Log kann ich auch keine für mich relevanten Informationen sehen. Alles was mir aufgefallen ist, in den "vordefinierten DHCP Optionen" ist bei Router nichts hinterlegt (003). Weiß aber nicht wie dort was eingetragen wird und warum!? Vielleicht hilft euch das bzw. mir ;)

[IThome 10]

Poste erstmal IPCONFIG /ALL des Clients bei bestehender Verbindung. Wird die Verbindung mit einem speziellen Client hergestellt ? IPSec ? Warum soll er das Gateway der internen Clients bekommen, für das weitere Routing ist eigentlich das VPN-Gateway zuständig.

[pfeffis 11]

es geht darum, dass die user auch internet nutzen können und das dann natürlich über unserer Firmengateway. Autokonfiguration ist beim VPN Adapter (Software) auf nicht aktiviert ist mir soeben noch aufgefallen. Die IP Adressen sind für jeden Client per MAC fest reserviert (falls das auch noch wichtig ist).

 

ipconfig /all passt - einziger Unterschied ist eben das fehlende Gateway und oben beschriebene Punkte.

[IThome 10]

Wie schon gesagt, um das weitere Routing sollte sich der VPN-Terminator kümmern, nicht der Client (der schickt es nur zum VPN-Gateway). Wenn Du die Fragen nicht beantworten willst, kann ich Dir nicht helfen ...

[pfeffis 11]

Also, hier mal ipconfig /all von einem WinXP Klapprechner:

 

Ethernetadapter LAN-Verbindung:

 

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : Realtek RTL8139-Familie-PCI-Fast Eth

ernet-NIC

Physikalische Adresse . . . . . . : 00-C0-9F-CE-29-13

DHCP aktiviert. . . . . . . . . . : Ja

Autokonfiguration aktiviert . . . : Ja

IP-Adresse. . . . . . . . . . . . : 192.1.2.152

Subnetzmaske. . . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . . . : 192.1.2.249

192.1.2.253

DHCP-Server . . . . . . . . . . . : 192.1.2.210

DNS-Server. . . . . . . . . . . . : 192.1.2.210

192.1.2.220

Primärer WINS-Server. . . . . . . : 192.1.2.210

Sekundärer WINS-Server. . . . . . : 192.1.2.220

Lease erhalten. . . . . . . . . . : Freitag, 12. September 2008 10:15:18

 

Lease läuft ab. . . . . . . . . . : Sonntag, 14. September 2008 10:15:18

 

 

Ethernetadapter SonicWALL Virtual Adapter:

 

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : SonicWALL VPN Adapter

Physikalische Adresse . . . . . . : 00-60-73-E4-3F-E5

DHCP aktiviert. . . . . . . . . . : Ja

Autokonfiguration aktiviert . . . : Nein

IP-Adresse. . . . . . . . . . . . : 192.1.2.167

Subnetzmaske. . . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . . . :

DHCP-Server . . . . . . . . . . . : 192.1.2.210

DNS-Server. . . . . . . . . . . . : 192.1.2.210

192.1.2.220

Primärer WINS-Server. . . . . . . : 192.1.2.210

Sekundärer WINS-Server. . . . . . : 192.1.2.220

Lease erhalten. . . . . . . . . . : Freitag, 12. September 2008 10:07:18

 

Lease läuft ab. . . . . . . . . . : Sonntag, 14. September 2008 10:07:18

 

 

PPP-Adapter Vodafone Mobile Connect:

 

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : WAN (PPP/SLIP) Interface

Physikalische Adresse . . . . . . : 00-53-45-00-00-00

DHCP aktiviert. . . . . . . . . . : Nein

IP-Adresse. . . . . . . . . . . . : 77.25.144.180

Subnetzmaske. . . . . . . . . . . : 255.255.255.255

Standardgateway . . . . . . . . . : 77.25.144.180

DNS-Server. . . . . . . . . . . . : 139.7.30.125

139.7.30.126

Primärer WINS-Server. . . . . . . : 10.11.12.13

Sekundärer WINS-Server. . . . . . : 10.11.12.14

NetBIOS über TCP/IP . . . . . . . : Deaktiviert

 

 

Dieses ist soeben einmal über LAN und einmal über VPN (UMTS) verbunden, damit man beide NICS sehen kann. Ich hoffe das hilft dir erstmal weiter!?

Bitte nicht vom 192.1.0.0 Netz irritieren lassen. Wurde vor Jahren mal von einer Consulting Firma ein gerichtet, die anscheinend nicht den Unterschied zwischen privater IP Adressbereich und öffentlichen kannte :)

[IThome 10]

Ich sehe da auf den ersten Blick schon 2 Merkwürdigkeiten: Ist die Verbindung des Rechners, dessen IPCONFIG Du gepostet hast, nicht von aussen hergestellt worden (weil die Adressbereiche und der DHCP-Server derselbe ist) ? Weiterhin hat der Client 2 Default Gateways (Fehlertoleranz oder wofür soll das gut sein ?). Was ist auf der Sonicwall konfiguriert, welche Netze der Client durch den Tunnel (IPSec ?) erreichen darf ? Kann der Client Geräte (Server oder was auch immer) jenseits des VPN-Gateways erreichen, wenn er von aussen kommt ?

edit: ups, habe den letzten Teil mit dem LAN und UMTS überlesen. Die NIC ist erstmal uninteressant, da sie sich von aussen ja nicht in diesem IP-Bereich befindet. Aber wenn der Zugriff auf die internen Server funktioniert, ist es keine Frage des nicht übermittelten Gateways, sondern eine Konfigurationsfrage des VPNs an sich ...

[pfeffis 11]

also zugriffe funktionieren (interne Netz soll durch VPN Clients erreicht werden), da DNS Server ja übermittelt werden, nur komischerweise nicht das Standardgateway und dieses ist auf dem DHCP Server (003) eingetragen und wird ja intern auch vom DHCP Server an die Clients verteilt. Ich verstehe eben nur nicht warum das intern übertragen wird und extern nicht!? Ich meine wenn die Informationen wie IP Adresse und DNS, WINS, etc. übertragen werden können dann muss doch auch die Option (003) übertragen werden, oder!?

[IThome 10]

Nein, muss es nicht, weil der Client (je nach Konfiguration des IPSec-Tunnels) den Weg in die entsprechenden Netze via IPSec-Client findet, was von der Konfiguration des Tunnels abhängt und der Routing-Konfiguration des VPN-Gateways. Er würde den Weg ja auch ohne virtuellen Adapter finden, der in der Regel optional ist. Er findet ja die internen Server auch ohne explizit angegebenes Gateway, er schickt die Pakete, die für das 192.168.1.x Netz bestimmt sind, durch den Tunnel zum VPN-Gateway und das liefert es weiter aus. Ich denke, dass der Client wegen der Konfiguration nur Pakete mit dem Ziel 192.168.1.x/24 in den Tunnel schickt und alles andere am Tunnel vorbei geht. Er müsste bei verbundenem IPSec-Tunnel 0.0.0.0 (Strict Tunneling) in den Tunnel schicken, dann würde alles rüber gehen ...

[pfeffis 11]

Mhh, da kann ich gerade mal nicht folgen.

Der Client verbindet sich per VPN mit dem Gateway, dieses leitet dann ip Adressanfragen an den internen DHCP Server, dieser gibt alle DHCP Optionen an den Client und somit steht die Verbindung, oder!? Ich meine eine Kommunikation zwischen DHCP Server und Client findet ja statt, ansonsten hätte er ja nicht mal eine IP. Und das er dieses übermittelt bekommt sollte er doch auch die Option Standardgateway bekommen!? :confused:

[IThome 10]

Ist das ein IPSec-Tunnel ? Kann man den IPSec-Client ohne virtuellen Adapter benutzen ? Wie ist die Konfiguration für diesen Tunnel auf dem VPN-Gateway oder dem IPSec-Client ? Was ist dort als Zielnetz eingetragen ?

[pfeffis 11]

läuft über Pre Shared Key Verfahren. Habe nun noch eine Einstellung bei der Sonicwall gefunden "default LAN Gateway". Nun funktioniert es zwar, aber ich verstehe noch immer nicht warum der Client nicht die Info vom DHCP Server bekommt und unter ipconfig /all habe ich nun als Standardgateway die gleiche IP Adresse zu (192.1.2.167) stehen wie der Client an sich hat. Über tracert geht der Client aber über das richtige Gateway (192.1.2.249) raus. Inet etc. funktioniert nun. Sehr komisch ...

[IThome 10]

Wenn er das Gateway vom DHCP bekommen würde, würde keinerlei Kommunikation mit dem Zielnetz möglich sein ...