Hallo, eine Hardware hat sich per VPN verbunden und hat somit eine IP in meinem Lokalen LAN. Kann nun ein Teilnehmer in lokalem LAN diese VPN-IP als Gateway adresse benutzen? Mir kommt es so vor als würde die Fritzbox dies verhindern. Für die Ziel-IP wurde eine Route über die VPN-IP eingetragen.
Umleitung schrieb: > Kann nun ein Teilnehmer in lokalem LAN diese VPN-IP als Gateway adresse > benutzen? ja > Mir kommt es so vor als würde die Fritzbox dies verhindern. kann sie gar nicht. Sie hat darauf keinen Einfluss.
Ein tracert zur Zieladresse dürfte mir demnach keine öffentliche IP ausspucken, tut er aber. Und zwar 217.5.98.16 das ist nicht die öffentliche ip der Fritzbox, und auch sonst hab ich die nirgends gefunden.
Umleitung schrieb: > Ein tracert zur Zieladresse dürfte mir demnach keine öffentliche IP > ausspucken, tut er aber. > > Und zwar 217.5.98.16 das ist nicht die öffentliche ip der Fritzbox, und > auch sonst hab ich die nirgends gefunden. dann routet wohl der VPN Gateway ohne VPN zur Fritzbox
Umleitung schrieb: > Teilnehmer in lokalem LAN diese VPN-IP als Gateway adresse > benutzen Warum sollte er das tun? Das ist eine lokale Adresse. Da braucht man kein Gateway!
Um die Frage beantworten zu können müßte man schon etwas mehr über Deine Einstellungen wissen als nur 'Kann nun ein Teilnehmer [...]diese VPN-IP als Gateway adresse benutzen' Wie siehr es denn auf der Gegenseite aus? Kennt das Ziel denn auch den Rückweg über das VPN? Die Routingeinträge müssen in beide Richtungen funktionieren, sie müssen nicht gleich sein aber der Weg muß vorhanden sein.
Ja die Gegenseite hat die Route richtig eingetragen. Das problem beginnt auf der Seite mit der Fritzbox schon beim ersten hop mit tracert. Daher meine Vermutung im ersten Post.
Umleitung schrieb: > Das problem beginnt auf der Seite mit der Fritzbox schon beim ersten hop > mit tracert. Daher meine Vermutung im ersten Post. dann zeige doch mal die Routing Tabelle und den Trace.
Sorry, ich denke du kannst zur Lösung nicht helfen, da du den Aufbau oder einen ähnlichen selber noch nicht hattest. Routing Tabelle und trace wurde schon beantwortet.
Umleitung schrieb: > Routing Tabelle und trace wurde schon beantwortet. Ich sehe keins von beiden (???)
Routing Tabellen sind korrekt. Trace Antwort beim ersten Hop bereits gepostet. Ein "ich will es aber selber sehen" hilft hier nicht weiter.
Umleitung schrieb: > Routing Tabellen sind korrekt. > Trace Antwort beim ersten Hop bereits gepostet. > > Ein "ich will es aber selber sehen" hilft hier nicht weiter. Warum fragst du dann überhaupt das Forum, wenn du der Meinung bist, nichts zeigen zu wollen, weil (deiner Meinung nach) alles völlig korrekt ist?
Umleitung schrieb: > Mir kommt es so vor als würde die Fritzbox dies verhindern. Deswegen. Falls nun du den selben Aufbau schonmal versucht hättest würdes du auf das gleiche Problem stoßen und falls du es lösen konntest könntest du eine Lösung beiragen :)
Huh schrieb: > alles völlig korrekt Ich sagte nicht alles korrekt, Routing Tabelle ist korrekt. Trace Anwort wurde bereits gepostet. Bitte keine verallgemeinerungen.
Umleitung schrieb: > Sorry, ich denke du kannst zur Lösung nicht helfen, da du den Aufbau > oder einen ähnlichen selber noch nicht hattest. Routing Tabelle und > trace wurde schon beantwortet. warum glaubst du das? Ich hatte schon einige größere Netzte mit mehre Routern und VPN-Gateways administriert. Ich behaupte einfach du hast etwas falsch gemacht. Wir können dir aber nicht helfen in dem du nur eine IP postet wo keiner sieht wie sie entsteht. Wenn die Routingtabelle und der Trace so geheim ist, das du es nicht zeigen kannst musst du dich wohl weiter selber mit dem Problem auseinander setzen.
Umleitung schrieb: > Huh schrieb: >> alles völlig korrekt > > Ich sagte nicht alles korrekt, Routing Tabelle ist korrekt. Trace Anwort > wurde bereits gepostet. > Bitte keine verallgemeinerungen. Viel Spaß noch beim Rätseln :-) Ciao...
Ja dann sollte es ja für dich kein Problem sein:
1 | C:\Users\administrator>ping 10.0.0.202 -t |
2 | |
3 | Ping wird ausgeführt für 10.0.0.202 mit 32 Bytes Daten: |
4 | Antwort von 10.0.0.202: Bytes=32 Zeit=19ms TTL=63 |
5 | Antwort von 10.0.0.202: Bytes=32 Zeit=22ms TTL=63 |
6 | Antwort von 10.0.0.202: Bytes=32 Zeit=20ms TTL=63 |
1 | IPv4-Routentabelle |
2 | ===========================================================================
|
3 | Aktive Routen: |
4 | Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik |
5 | 0.0.0.0 0.0.0.0 10.1.1.1 10.1.1.10 266 |
6 | 10.0.0.0 255.0.0.0 Auf Verbindung 10.1.1.10 266 |
7 | 10.1.1.10 255.255.255.255 Auf Verbindung 10.1.1.10 266 |
8 | 10.255.255.255 255.255.255.255 Auf Verbindung 10.1.1.10 266 |
9 | 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306 |
10 | 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306 |
11 | 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 |
12 | 169.254.0.0 255.255.0.0 Auf Verbindung 169.254.201.133 276 |
13 | 169.254.201.133 255.255.255.255 Auf Verbindung 169.254.201.133 276 |
14 | 169.254.255.255 255.255.255.255 Auf Verbindung 169.254.201.133 276 |
15 | 192.168.2.27 255.255.255.255 10.0.0.202 10.1.1.10 11 |
16 | 192.168.235.0 255.255.255.0 Auf Verbindung 192.168.235.1 276 |
17 | 192.168.235.1 255.255.255.255 Auf Verbindung 192.168.235.1 276 |
18 | 192.168.235.255 255.255.255.255 Auf Verbindung 192.168.235.1 276 |
19 | 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306 |
20 | 224.0.0.0 240.0.0.0 Auf Verbindung 10.1.1.10 266 |
21 | 224.0.0.0 240.0.0.0 Auf Verbindung 169.254.201.133 276 |
22 | 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.235.1 276 |
23 | 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 |
24 | 255.255.255.255 255.255.255.255 Auf Verbindung 10.1.1.10 266 |
25 | 255.255.255.255 255.255.255.255 Auf Verbindung 169.254.201.133 276 |
26 | 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.235.1 276 |
27 | ===========================================================================
|
28 | Ständige Routen: |
29 | Netzwerkadresse Netzmaske Gatewayadresse Metrik |
30 | 0.0.0.0 0.0.0.0 10.1.1.1 Standard |
31 | ===========================================================================
|
1 | C:\Users\administrator>tracert 192.168.2.27 |
2 | |
3 | Routenverfolgung zu 192.168.2.27 über maximal 30 Abschnitte |
4 | |
5 | 1 <1 ms <1 ms <1 ms fritz.box [10.1.1.1] |
6 | 2 7 ms 7 ms 7 ms 217.5.98.16 |
7 | 3 * * * Zeitüberschreitung der Anforderung. |
8 | 4 * * * Zeitüberschreitung der Anforderung. |
9 | 5 * * * Zeitüberschreitung der Anforderung. |
10 | 6 * * * Zeitüberschreitung der Anforderung. |
11 | 7 * * * Zeitüberschreitung der Anforderung. |
12 | 8 * * * Zeitüberschreitung der Anforderung. |
13 | ...
|
Umleitung schrieb: > Ja dann sollte es ja für dich kein Problem sein: jetzt hätte ich zumindest eine Möglichkeit zu helfen, jedes Problem lösen kann ich noch lange nicht. Ich kann zumindest keinen Fehler in der Konfiguration feststellen. Ist das richtig das du auf dem Host eine Netzwerk mit 10.1.1.10 und der Netzwerkmaske 255.0.0.0 hast? Bekommst du die gleiche Routingtabelle, nach dem den Trace ausgeführt hast? (Falls dein VPN ein Redirekt schickt, wird in deiner Tabelle dynamisch ein Eintrag hinzugefügt. )
Peter II schrieb: > Ist das richtig das du auf dem Host eine Netzwerk mit 10.1.1.10 und der > Netzwerkmaske 255.0.0.0 hast? Ja. Peter II schrieb: > Bekommst du die gleiche Routingtabelle, nach dem den Trace ausgeführt > hast? Auch Ja.
Wenn im Tracert die Pakete ins Internet wandern, dann schickt die
FritzBox diese nicht in den Tunnel.
Das liegt daran dass in der VPN Tunnel Konfig der Host 192.168.2.27
nicht eingetragen ist als Remote Netz/Host
lade doch mal die .cfg herunter und schaue dort nach:
hier müsstest du die Parameter ändern. sowohl in der config für die
Fritz.box als auch am Client (Deiner "Hardware")
ipnet {
ipaddr = 192.168.178.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipaddr = 192.168.178.201;
}
Viel Glück
unbek. schrieb: > Das liegt daran dass in der VPN Tunnel Konfig der Host 192.168.2.27 > nicht eingetragen ist als Remote Netz/Host die FritzBox soll ja gar nicht tunnel, dafür hat er ja einen VPN-Gateway (10.0.0.202)
Das habe ich anders verstanden. Ich habe verstanden, dass eine Hardware (Was auch immer) sich auf die FritzBox einwählt und die IP 10.0.0.202 bekommt. Über diese möchte er zusätzlich noch ein weiteres Netz/Host (192.168.2.27) erreichen das hinter der "Hardware" hängt. Daher der Routing Eintrag. In diesem Fall muss die FritzBox natürlich schon das Netz kennen. Schade sind die spärlichen Informationen, so fischen wir alle etwas im Trüben.
Peter II schrieb: > die FritzBox soll ja gar nicht tunnel, dafür hat er ja einen VPN-Gateway > (10.0.0.202) Ist das so? Bei den Informationen würde ich nicht mein Hand dafür ins Feuer legen. Ich habe das Gefühl der TS hat uns (absichtlich?) nur mit der Routingtable von irgendeinem Windowsrechner beglückt. Ich habe da so einen Verdacht ... Also: Wer hat die 10.0.0.202? Wie sieht ein traceroute (kein ping) mit -d (keine Namensauflösung) nach 10.0.0.202 aus? Nur zur Kontrolle, was liefert ein rDNS von der Fritz!Box für 10.0.0.202? Was sagt arp -a 10.0.0.202 ? Was sagt arp -a 10.1.1.10 ? Warum wird kein Wireshark verwendet? Unser großer Umleitungs-Held scheint da eine Lücke in seinem Werkzeugkasten zu haben ... Wie sieht das DHCP aus? Dann: Wie sieht das Routing / Forwarding auf der Fritz!Box aus? (Wie man das herausfindet überlassen wir mal unserem TS. Er ist nicht der einzige der unvollständige Informationen geben kann :))
Jay schrieb: > Ist das so? Bei den Informationen würde ich nicht mein Hand dafür ins > Feuer legen. ich schon. > Wer hat die 10.0.0.202? ein anderes Geräte, zumindest nicht die Fritzbox. > Wie sieht ein traceroute (kein ping) mit -d (keine Namensauflösung) nach > 10.0.0.202 aus? wird nichts liefern, weil im gleichen SubNetz - damit auch kein Routing > Wie sieht das DHCP aus? was soll das für eine Rolle spielen? > Wie sieht das Routing / Forwarding auf der Fritz!Box aus? spielt auch keine Rolle, weil das packet dort gar nicht ankommen soll.
Nein, ganz so einfach ist das bei VPN nicht. Zumindest nicht bei L3. Da das entfernte Gerät (hier 10.0.0.202) im lokalen Netz (10.0.0.0/8) selber keine physikalische Präsenz, also kein eigenes physikalisches Interface, hat muss irgendjemand diese Rolle übernehmen. D.h. irgendjemand muss im lokalen Netz auf einen arp-Request für 10.0.0.202 antworten und eine MAC-Adresse liefern. Wer/was kann das wohl sein? Bei L3 VPN muss das das ominöse VPN-Gateway, welches den Tunnelendpunkt zum entfernten Gerät hat, machen. Wenn es die Fritz!Box ist, was ich glaube, dann antwortet die auf einen arp-Request mit ihrer LAN MAC-Adresse. Daher die Frage nach arp für 10.0.0.202 und 10.1.1.10. Sind die gleich ist die FB das ominöse VPN-Gateway. Dafür spricht, dass bei dem tracert
1 | C:\Users\administrator>tracert 192.168.2.27 |
2 | |
3 | Routenverfolgung zu 192.168.2.27 über maximal 30 Abschnitte |
4 | |
5 | 1 <1 ms <1 ms <1 ms fritz.box [10.1.1.1] |
6 | 2 7 ms 7 ms 7 ms 217.5.98.16 |
zuerst die FB auftaucht. Deshalb ist es weiter interessant, wie die FB eine Reverse-Namensauflösung für 10.0.0.202 macht. Was auch noch merkwürdig ist ist, dass das Gateway in der Routing-Tabelle immer 10.1.1.10 ist, in dem Tracerout die FB aber mit 10.1.1.1 steht. Entweder wissen wir immer noch nicht alles über die Netzwerktopologie (Netzwerkplan, was ist das?), wir haben falschen Ausgaben bekommen, die FB trickst und hat ein paar Macken. DHCP ist deshalb interessant, weil die FB zwar per Default 192.168.178.20 bis .199 für lokale DHCP-Adressen verwendet, wir aber nicht wissen auf was sie momentan eingestellt ist (außer vermutlich das LAN mit 10.0.0.0/8), und ob 10.0.0.202 nicht eventuell im DHCP-Bereich liegt. Die FB mag es gar nicht, wenn sich statische und dynamische IP-Adressen überschneiden und sie kann keine IP-Adressen per DHCP an entfernte Geräte im VPN vergeben. Noch was zur Namensauflösung. Natürlich werden Namen auch im lokalen Netz aufgelöst. Die FB hat sogar einen eigenen DNS Server / Proxy und kann Reverse-DNS. Als Daten verwendet sie die Rechnernamen unter "Heimnetz", die sowohl die dynamischen (für DHCP), als auch statische Hostnamen enthält. Der Trick, das FB LAN-IPs zu "fritz.box" und umgekehrt aufgelöst werden können (wie in dem tracert vermutlich geschehen) ist ebenfalls im lokalen (r)DNS der FB implementiert.
Jay schrieb: > Da das entfernte Gerät (hier 10.0.0.202) im lokalen Netz (10.0.0.0/8) > selber keine physikalische Präsenz, also kein eigenes physikalisches > Interface, hat muss irgendjemand diese Rolle übernehmen. D.h. > irgendjemand muss im lokalen Netz auf einen arp-Request für 10.0.0.202 > antworten und eine MAC-Adresse liefern. ok, ich habe es so gelesen das es ein zusätzliches VPN-Gerät im Lokalen netz gibt, welches die IP hat. Wenn 10.0.0.202 selber im Netzt nicht existiert, dann ändert das natürlich einiges. Meine VPNs, waren bis jetzt immer sauber nach Subnetzten getrennt und nicht über Proxy-Arp eingebunden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.