08.08.2015, aktualisiert am 19.09.2015

33219

VPN Verbindung shrew zu Fritzbox: Routing Problem

Hallo zusammen!

Ich möchte eine VPN-Verbindung unter Win10 mittels shrew zu einer Fritz!Box aufbauen.

Der Tunnel selbst wird erfolgreich aufgebaut, jedoch kommen keine Pakete vom Zielrechner, der sich im Netz der Fritz!Box befindet bei mir an.
Bisher wurde die Verbindung mittels der Software fritz!Fernzugang realisiert, die unter Win10 aber nicht läuft.

Die Netzwerkkonfiguration lautet wie folgt:

Lokales Netz:
192.168.12.0 255.255.255.0

Entferntes Netz:
192.168.100.0 255.255.255.0

Zugeordnete IP für den Client im Netz der FB:
192.168.112.201 255.255.255.0

Die Konfigurationsdatei der Fritzbox lautet hinsichtlich der Netzwerkeinstellungen wie folgt:

virtualip = 192.168.112.201

phase2localid {
ipaddr = 192.168.112.201;

phase2remoteid {
ipnet {
ipaddr = 192.168.100.254;
mask = 255.255.255.255;

accesslist = "permit ip any 192.168.100.254 255.255.255.255",

unter shrew lautet die Einstellung "Remote Network Resource"
192.168.100.254 255.255.255.255

Ich bekomme zwar den Tunnel etabliert, aber keinen Ping auf ein Ziel im Netz 192.168.100.0

Wenn ich die obige Konstellation in Win7 mit Fritz!Fernzugang und shrew parallel einrichte, dann funktioniert es mit Fritz!Fernzugang aber nicht mit shrew.
Anscheinend routet die Fritz-Software die Pakete vom Netz 192.168.100.0 zu 192.168.112.0?

Ich habe versucht, unter Windows Routen anzulegen, ich habe versucht, die Netze zu shrew unter "Remote Network Resource" hinzuzufügen - aber es kommt einfach kein Ping an (kein Firewallproblem, mit Fritz!Fernzugang funktioniert es).

Ich bin völlig ratlos. Das Problem scheint mir die virtual IP zu sein, die sich nicht im Zielnetz befindet. Aber bekomme es nicht hin.

Ich bin dankbar für Vorschläge.

Beste Grüße
tillixx07

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 279626

Url: https://administrator.de/contentid/279626

Ausgedruckt am: 23.11.2024 um 20:11 Uhr

88 Kommentare

Neuester Kommentar

Hallo,

die Anleitung von AVM dazu kennst Du schon?
Man kann ja noch einmal selber drüber schauen ob alles stimmt.

Gruß
Dobby

Ja, diese Anleitung kenne ich. Der Tunnel wird ja auch aufgebaut - nur die Pakete aus dem entfernten Netz kommen nicht an.

In der Anleitung von AVM ist leider auch die virtuelle IP Teil des entfernten Netzes. Dies ist aber in meinem Fall anders.

Der Aufbau zu einer anderen Fritzbox, die grundsätzlich der IP-Konfiguration in dieser Anleitung entspricht, funktioniert ebenfalls. Es muss ein Routingproblem sein.

Edit:
Der Unterschied meiner Konfiguration zu derjenigen in der Anleitung ist folgender:

Anleitung:
Entferntes Netz: 192.168.100.0 255.255.255.0
Remote IP 192.168.100.201

Mein Fall:
Entferntes Netz: 192.168.100.254 255.255.255.255
Remote IP 192.168.112.201

Also zum einen kein 24er Netz und zum anderen ist die Remote-IP nicht Teil des Netzes der entfernten FB.

Anleitung:
Entferntes Netz: 192.168.100.0 255.255.255.0
Remote IP 192.168.100.201

Mein Fall:
Entferntes Netz: 192.168.100.254 255.255.255.255

Entferntes Netz 192.168.100.0 255.255.255.0

Remote IP 192.168.112.201

Remote IP 192.168.100.201

Also zum einen kein 24er Netz und zum anderen ist die Remote-IP nicht
Teil des Netzes der entfernten FB.

Na dann wirst Du das wohl ändern müssen, oder nicht?
Ist doch dann zweifelsohne klar woran es scheitert.

Gruß
Dobby

Die Einstellungen der entfernten FB zu ändern ist keine Option.

Und mit der Software von AVM funktioniert es ja. Das heißt, die Pakete müssen nur den "richtigen" Weg finden. Dafür reichen meine Netzwerkfähigkeiten aber nicht aus.

Die Einstellungen der entfernten FB zu ändern ist keine Option.

Na dann musst Du wohl Deine Einstellungen anpassen.

Und mit der Software von AVM funktioniert es ja.

???

Mein Fall:
Entferntes Netz: 192.168.100.254 255.255.255.255

Es ist eben kein richtiges entferntes Netz, das endet immer mit einer Null! (192.168.100.0)

Remote IP 192.168.112.201

192.168.100.201 255.255.255.255

Gruß
Dobby

"Na dann musst Du wohl Deine Einstellungen anpassen."

Tja, deswegen stelle ich hier diese Frage.

"???"
Die Antwort dazu steht doch in meinem Eingangspost. In Win7 funktioniert die software - in Win10 nicht.

"Es ist eben kein richtiges entferntes Netz, das endet immer mit einer Null! (192.168.100.0)"
Es ist ein 32er "Netz" - eine einzelne IP in dem Fall. Was aber dem Grunde nach keine Rolle spielen sollte, ob ich nun eine IP in dem Netz habe oder 254.
Und genau deswegen schrieb ich, dass es mit der Software von AVM funktioniert. Weil diese vermutlich die Pakete routet. Und das einzige, das ich gerne wissen würde ist, wie ich diese Funktion "manuell" abbilde.
Dem Grunde nach ist die Konfiguration funktionsfähig - nur fehlen bei shrew anscheinend Einstellungen, bzw, die Einstellungen weisen einen Fehler auf.
Nur habe ich schon alles, worauf ich selbst gekommen bin, versucht.

Die Anleitung hier im Forum kennst du auch ?
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Hallo Aqui,

ja, die habe ich auch gelesen - so wie so ziemlich alles, was ich auf seiten von AVM, shrew und in diversen Foren so fand.

Die Einstellung "local host" im shrew client ist bei mir auf "obtain automatically" - womit die von der entfernten FB zugewiesene IP auch übernommen wird (die kann ich auch pingen, sobald die Verbindung steht). Gleiches passiert auf dem Win7-System mit der Software von AVM. Soweit alles im grünen Bereich.

Doch dann komme ich nicht weiter. Von meiner lokalen IP zu der von der entfernten FB zugewiesenen IP ist noch alles gut - doch dann zu dem entfernten Netz findet kein Transport der Pakete mehr statt.

Der Unterschied zu der "Standardkonfiguration", die sonst überall beschrieben ist, ist die zugewiesene IP aus einem Netz, das nicht dem Netz der entfernten FB entspricht (was aber laut Anleitung Seitens AVM kein grundsätzliches Problem ist und was mit der Software von AVM auch blendend funktioniert) und der Umstand, dass es sich beim entfernten Netz um eine einzelne IP handelt - was aber auch kein Problem sein sollte, weil auch hier die Lösung von AVM konfigurationsfrei funktioniert.

Ich vermute, dass der Fehler darin liegt, dass zwischen der zugewiesenen IP (192.168.112.201) und dem fremden Netz (192.168.100.0 oder 192.168.100.254) kein Routing statt findet.

Probiert habe ich unter "Policy" in shrew:
192.168.100.254 255.255.255.255
192.168.100.0 255.255.255.0
192.168.112.0 255.255.255.0
sowie Kombinationen daraus. Ich habe shrew mit Adminrechten gestartet - aber alles vergeblich.

Ich habe diverse Routen angelegt - aber bloßes "try and error" hat nicht funktioniert.

Es ist auch definitiv kein Firewallproblem, da es in Win7 mit der Software von AVM funktioniert und wenn die Verbindung mit shrew aufgebaut wird, funktioniert es nicht. "Route print" sagt in beiden Fällen das selbe - so dass ich vermute, dass die Software von AVM die Pakete routet.
Nur kann das doch kein Hexenwerk sein?

Edit:
Mit der Einstellung
virtualip = 192.168.112.201

phase2localid {
ipaddr = 192.168.112.201;

phase2remoteid {
ipnet {
ipaddr = 192.168.100.254;
mask = 255.255.255.255;

accesslist = "permit ip any 192.168.100.254 255.255.255.255",

kann ich - wenn die Software von AVM verwendet wird - z.B das Ziel 192.168.100.20 pingen, wie auch 192.168.100.254.

Edit 2:
Mit einer anderen FB - bei der die zugewiesene IP im Netz der FB liegt, funktioniert es auch mit shrew.

Von meiner lokalen IP zu der von der entfernten FB zugewiesenen IP ist noch alles gut - doch dann zu dem entfernten Netz findet kein Transport der Pakete mehr statt.

Das besagt ja erstmal das die Pakete durch den VPN Tunnel auf die entfernte FB, sprich den VPN Server fehlerfrei transportiert werden !
Erstmal ein gutes Zeichen und besagt ja das der Tunnel an sich sauber funktioniert !
Kannst du auch die LAN IP der entfernten FB anpingen ?? Wenn ja zeigt das das generell das remote LAN durch den Tunnel erreichbar ist und damit wie bereits gesagt der VPN Tunnel an sich klappt.

Wenn du andere Rechner im remoten LAN nicht anpingen kannst hat das in der Regel 2 Gründe:

Diese Rechner haben ein anderes Default Gateway konfiguriert als die LAN IP deiner entfernten FB. Kann das sein oder ist die Gateway IP dieser Rechner und die der remoten FB identisch ?? Sollte das nicht der Fall sein hast du ein Routing Problem und es wäre klar das dann nichts klappt.
Die entfernten Rechner haben eine aktive Firewall die im Default alles blockt was eine fremde IP Adresse hat ! Damit werden deine Pings übers VPN dort entsprechend blockiert, denn du hast ja eine IP fremde Absender IP als das dortige lokale Netzwerk, logisch ! Bedenke auch das ICMP (Ping) generell in den Default Einstellungen der Windows Firewall geblockt ist ! Wie man das wieder aktiviert ist hier: http://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen genau beschrieben.

Hast du das alles bedacht ?
Generell funktioniert der Zugriff mit dem Shrew Client auf FritzBox VPNs absolut fehlerfrei. Irgendwo hast du also selber einen Kincken eingebaut bei dir.

Genau, der Tunnel wird fehlerfrei etabliert. Es findet ja auch ein Handshake statt und der lokale Rechner bekommt von der FB erfolgreich die IP zugewiesen.

Pingen kann ich in dem entfernten Netz leider gar nichts. Alles, was sich im im Netz 192.168.100.0 befindet, antwortet nicht.

Wie gesagt, sobald ich die Verbindung mit der Software von AVM aufbaue, funktioniert es. Auch der Ping. Auch hier bekommt der Client keine andere IP zugewiesen, so dass es kein Firewallproblem sein kann.

Außer der Windowsfirewall läuft keine andere Software mit diesbezüglicher Funktionalität - und die habe ich sogar deaktiviert. Auf beiden Rechnern.

Grundsätzlich komme ich mit shrew auch klar - auch in Verbindung mit einer FB. Und allzu viel kann man bezüglich der Netzwerke ja auch nicht konfigurieren.
Wie gesagt, ich denke, dass die Pakete nicht geroutet werden, wenn ich shrew benutze. Aber das muss doch manuell lösbar sein?

Edit:
IP der entfernten Rechner und IP der entfernten FB sind nicht identisch. Die FB ist korrekt als GW eingetragen.

Ich wäre auch dankbar über Tipps zur Fehlersuche.

-> Tunnel wird aufgebaut
-> Firewall kann ausgeschlossen werden

-> Das Problem liegt damit doch aller Wahrscheinlichkeit darin, dass zwischen den Netzen 192.168.112.0 / 192.168.100.0 / 192.168.12.0 nicht geroutet wird. Zwischen 192.168.112.0 / 192.168.12.0 findet das Routing statt, die IP 192.168.112.221 kann vom Netz 192.168.12.0 gepingt werden.

Alles, was sich im im Netz 192.168.100.0 befindet, antwortet nicht.

Wie bereits mehrfach gesagt deshalb die Frage:

Ist das Gateway dieser angepingten Geräte auch die FB ?
Hast du deren lokale Firewall entsprend im Setup angepasst das die diese Paket erlauben und das auch ICMP erlaubt ist ?

Leider keine klare Antwort dazu...

IP der entfernten Rechner und IP der entfernten FB sind nicht identisch. Die FB ist korrekt als GW eingetragen.

Ist etwas verwirrend... Was meinst du damit genau. Es sollte klar sein das IPs unterschiedlich sind aber gemeinsam im remote benutzen IP Netz wobei die GW IP des Clients auf die FB IP zeigen muss.
Es sieht zu 98% so aus also ob dort irgendwo eine Firewall zuschlägt ! Beachte auch das bei deinem Client ein virtuelles Interface erzeugt wird für den IPsec Client (kannst du mit ipconfig -all sehen) auch hier greift wieder die lokale Firewall des Clients !
Das muss entsprechend zusätzlich customized werden.

Wie gesagt, ich denke, dass die Pakete nicht geroutet werden, wenn ich shrew benutze.

Das kannst du mit route print sehen ! Vermutlich schlägt aber da die Client Firewall auf dem virtuellen IPsec Adapter zu ?!

Ich wäre auch dankbar über Tipps zur Fehlersuche.

Traceroute ! Wo bleiben die Pkate an welchem Hop hängen ?

Firewall kann ausgeschlossen werden

Oha...das beteuern alle hier und dann ist es ein Amok laufender Kaspersky oder anderer zusätzlicher FW Mist oder Reste davon. Besser du nutzt etwas OHNE lokale Firewall wie lokale Netzwerk Printer usw. zum Anpingen um auf Nummer sicher zu gehen.

dass zwischen den Netzen 192.168.112.0 / 192.168.100.0 / 192.168.12.0 nicht geroutet wird.

Ähhh, wieso 3 Netze ? Bei einer Client to LAN VPN Kopplung sind eigentlich immer nur 2 IP Netze involviert ?!
Wo kommt das 100er Netz her, oder hast du 3 Locations ??
Wie bereits gesagt oben: Führe ein route print aus auf dem Client und sieh dir die Routing Tabelle an, dort müssen alle 3 Netze angezeigt werden wenn das Routing korrekt konfiguriert ist.
Ebenso in den Routing Tabellen der beteiligten Router !

Ist das Gateway dieser angepingten Geräte auch die FB ?

Ja.

Hast du deren lokale Firewall entsprend im Setup angepasst das die diese Paket erlauben und das auch ICMP erlaubt ist ?

Leider keine klare Antwort dazu...
Die Firewall ist AUSGESCHALTET. Zudem funktioniert das Setup, wenn die Software von AVM den Tunnel etabliert. Zudem pinge ich auch die FB an.
Bitte glaube mir es kann kein Firewallproblem sein. Wenn irgendwo irgend ein Firewall dazwischen funken würde, würde auch über den Tunnel der AVM-Software kein Ping funktionieren. Das GW aht auch keinen Firewall. Und entsprechende Software war nie auf den Clients installiert. Das weiß ich, weil die Installation der OS genau 3 Tage alt ist.

Beachte auch das bei deinem Client ein virtuelles Interface erzeugt wird für den IPsec Client

Genau. Das ist das "dritte" Netz.

Wie bereits gesagt oben: Führe ein route print aus auf dem Client und sieh dir die Routing Tabelle an, dort müssen alle 3 Netze angezeigt werden wenn das Routing korrekt konfiguriert ist.

Das "route print" verändert sich aber nicht, wenn der Tunnel etabliert ist. Auch werden die beteiligten Netze nicht angezeigt - und zar auch nicht in er funktionierenden Konfiguration mit der AVM-Software.

Noch einmal:
Mein lokales Netz lautet: 192.168.12.0 255.255.255.0

Das entfernte Netz lautet 192.168.100.254 255.255.255.255

Die IP des virtuellen Interface lautet 192.168.112.221 255.255.255.0

Insgesamt sind damit 3 Netze beteiligt, ein lokales, ein virtuelles und ein entferntes. Die Route zum entfernten scheitert.
In "route print" steht nichts davon drin (außer dem lokalen Netz natürlich)

Tracerroute bleibt beim 2. Hop - nach meinem GW - hängen.

Anbei der Ablauf innerhalb einer virtuellen Maschine (zwecks Fehlersuche erstellt), daher andere IPs.

Installiert: Fritz!Fernzugang, shrew

Vor Aufbau des Tunnels

Ständige Routen:
Keine

ipconfig /all

IP-Adresse. . . . . . . . . . . . : 10.0.2.15
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.0.2.2
DHCP-Server . . . . . . . . . . . : 10.0.2.2

Aufbau des Tunnels mittels Fritz!Fernzugang

Ständige Routen:
Keine

IP-Adresse. . . . . . . . . . . . : 10.0.2.15
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.0.2.2
DHCP-Server . . . . . . . . . . . : 10.0.2.2

Ping wird ausgeführt für 192.168.100.50 mit 32 Bytes Daten:

Antwort von 192.168.100.50: Bytes=32 Zeit=45ms TTL=127
Antwort von 192.168.100.50: Bytes=32 Zeit=44ms TTL=127
Antwort von 192.168.100.50: Bytes=32 Zeit=46ms TTL=127
Antwort von 192.168.100.50: Bytes=32 Zeit=45ms TTL=127

Ping-Statistik für 192.168.100.50:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 44ms, Maximum = 46ms, Mittelwert = 45ms

Routenverfolgung zu 192.168.100.50 über maximal 30 Abschnitte

1 42 ms 42 ms 44 ms 192.168.100.50
2 46 ms 42 ms 42 ms 192.168.100.50

Ablaufverfolgung beendet.

Aufbau des Tunnels mittels shrew

Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 20
10.0.2.0 255.255.255.0 10.0.2.15 10.0.2.15 20
10.0.2.15 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 20
[öff. IP] 255.255.255.255 10.0.2.2 10.0.2.15 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.100.254 255.255.255.255 192.168.112.201 192.168.112.201 1
192.168.112.0 255.255.255.0 192.168.112.201 192.168.112.201 30
192.168.112.201 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.112.255 255.255.255.255 192.168.112.201 192.168.112.201 30
224.0.0.0 240.0.0.0 10.0.2.15 10.0.2.15 20
224.0.0.0 240.0.0.0 192.168.112.201 192.168.112.201 30
255.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 1
255.255.255.255 255.255.255.255 192.168.112.201 192.168.112.201 1
Standardgateway: 10.0.2.2

Ständige Routen:
Keine

ping 192.168.100.50

Ping wird ausgeführt für 192.168.100.50 mit 32 Bytes Daten:

Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.100.50:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

tracert 192.168.100.50

Routenverfolgung zu 192.168.100.50 über maximal 30 Abschnitte

1 <1 ms <1 ms <1 ms 10.0.2.2
2 1 ms 1 ms 1 ms fritz.box [192.168.12.xx]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.

Es sind mehr Routen mit shrew - aber warum fehlen all die Routen beim Fritz!Fernzugang? Wie werden da die Pakete geroutet?

Das ist definitiv ein Fehler ! Das darf so nie sein, denn sonst sind diese Netze ja nicht erreichbar. Es ist möglich das die FB Software ein Redirect des Default gateways macht wenn du das so konfiguriert hast, also das ALLES in den Tunnel geroutet wird.
Dann würde sich aber die Default Gate IP in route print ändern.
Die Routing Tabelle des Clients ist essentiell wichtig für das Forwarding der Pakete.
Ist ist auch möglich, das du den Client mit fehlenden User Rechten startest, so das eine Routing Table Änderung schlicht nicht ausgeführt wird. Zum Ändern der Routing Tabelle bei Winblows sind Admin rechte erforderlich minimal temporäre Admin Rechte.

Der Traceroute 1 ms 1 ms 1 ms fritz.box [192.168.12.xx] zeigt ja das das Paket bis 192.168.12.xx (was auch immer das ist)
Dort an dieser IP Adresse ist die Routing Tabelle unvollständig und vermutlich kein Eintrag für das Zielnetz vorhanden, deshalb geht es dort nicht weiter.
Der Shrew Client zeigt wenigstens die korrekte Routing Tabelle an wie es sein soll.
Wenn es kein Firewall Problem ist dann kann es fast nur ein rechteproblem sein.
Genau diese Konstellation rennt hier mit einer pfSense und Shrew fehlerlos. Am Shrew liegt es also de facto nicht.

Das ist definitiv ein Fehler ! Das darf so nie sein, denn sonst sind diese Netze ja nicht erreichbar.

Das ist ja auch mein Gedanke. Nur bringt der mich leider nicht weiter.

Es ist möglich das die FB Software ein Redirect des Default gateways macht wenn du das so konfiguriert hast, also das ALLES in den Tunnel geroutet wird.

Die FB-Software routet nicht alles durch den Tunnel. Wenn ich z.B. die externe IP prüfe, dann sehe ich meine, nicht die des Ziels. Geroutet werden nur Pakete an das Zielnetz.

Ist ist auch möglich, das du den Client mit fehlenden User Rechten startest,

Leider auch nein. Das habe ich auch schon ausgeschlossen. Gleich als zweites, nachdem ich die Firewall als Fehlerquelle ausgeschlossen hatte. Es werden ja auch Routen angelegt - nur anscheinend nicht die richtigen.

was auch immer das ist

Mein Gateway

Dort an dieser IP Adresse ist die Routing Tabelle unvollständig und vermutlich kein Eintrag für das Zielnetz vorhanden, deshalb geht es dort nicht weiter.

Vermutlich. Doch hier kann ich nur herumprobieren, was leide nichts genützt hat. Ich habe schon manuelle Routes angelegt. Aebr hier bräuchte ich leider etwas Hilfe in der Form der korrekten Route.

Mich wundert folgendes:
Die Software von AVM legt keine neuen Routen an - und trotzdem werden die Pakete transportiert. Warum??

Shrew legt Routen an - aber offensichtlich die falschen. Wahrscheinlich kann shrew entweder die Konfiguration nicht abbilden oder ich habe einen Fehler bei den Netzwerkeinträgen gemacht. Nur kann mn da gar nicht so viel falsch machen.

Wenn Du auch shrew einsetzt: Ist die virtuelle IP Teil des Zielnetzes (also bei einem Zielnetz 192.168.10.0 z.B. die 192.168.10.100)?

Edit:
Mal ganz konkret:

Folgendes Beispiel:

Die IP des lokalen Rechners lautet: 192.168.10.1
Das Gateway dazu: 192.168.10.2
Wenn ich eine VPN-Verbindung aufbaue, wird mir eine virtuelle IP zugewiesen: 192.168.20.1
Der Zielrechner hat die IP: 192.168.30.1
Das Gateway des Zielnetzes hat die IP: 192.168.30.2
Und der Vollständigkeit halber die externe IP des Zielsystems: 100.100.100.100

Wie müssen die Routen lauten, damit Pakete
von 192.168.30.1
über 192.168.30.2
über 100.100.100.100
über 192.168.20.1
nach 192.168.10.1
kommen können? Das Problem scheint zu sein, dass die virtuelle IP quasi "dazwischen" liegt. Wenn die virtuelle IP Teil des Zielnetzes ist, klappt das auch mit shrew problemlos.

Geroutet werden nur Pakete an das Zielnetz.

Wiese DAS Zielnetz ? Normal wäre ja auch nur "DAS Zielnetz", denn man hat ja nur ein einziges bei einer remoten Location. Du hast aber 2 Zielnetze wenn man es richtig interpretiert oben. Folglich hast du also 2 IP Subnetze an der remoten Location wo dein Traffic hinsoll.
Diese beiden Subnetze MUSS der VPN Server, sprich die FB beim IPsec Tunnelaufbau an den Client negotiaten.
Der Client trägt dann folgerichtig diese Routen auch in seine zentrale Routing Table ein. So weiss er das Pakte an diese beiden netze eben via VPN Tunnel Interface geroutet werden und NICHT über das LAN Interface.
Logischer Standard dem alle VPN Clients egal welches OS folgen.
Der Shrew bekommt wie man sieht ja beide IP Netze mit dem virtuellen Tunnel Interface als Gateway...also alles richtig !

Shrew legt Routen an - aber offensichtlich die falschen.

Nein, denn wenn man sieht zeigen die als next Hop auf den Tunneladapter was absolut richtig ist.
Warum AVM keine Routzen in der Table hat ist schleierhaft. Vermutlich nutzen die irgendwas Proprietäres

Achtung hier:
Du darfst niemals beide IPsec Clients also den AVM Client und den Shrew Client parallel betreiben. Das funktioniert nicht. Bei IPsec Clients gilt der eiserne Highlander Grundsatz: "Es kann nur einen geben !"
Du musst also den einen oder anderen Client vollständig deinstallieren und das System rebooten. Das sollte dir hoffentlich klar sein !

Ist die virtuelle IP Teil des Zielnetzes (also bei einem Zielnetz 192.168.10.0 z.B. die 192.168.10.100)?

Ja, guckst du hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Wenn ich eine VPN-Verbindung aufbaue, wird mir eine virtuelle IP zugewiesen: 192.168.20.1 Der Zielrechner hat die IP: 192.168.30.1

Das kann nicht sein ! Sicher das du die richtigen Subnetzmasken gesetzt hast und nicht einem eine 16 Bit Maske statt 24 verwendet hast ?

Wie müssen die Routen lauten, damit Pakete

von 192.168.30.1 über 192.168.30.2
Eine Route wäre hier ziemlicher Blödsinn. Warum sollte ich was ins 30.0er Netz routen über ein Gateway im selben IP Netz...das ist Unsinn !

über 100.100.100.100

Ist auch Unsinn, denn das ist ja nur die externe IP, sprich die des Tunnelendpunktes die der Client erreichen muss. Ein route print auf dem Client zeigt dir doch welches Gateway der Client benutzt um auf die 100.100.100.100 zu kommen.
Wenn keine explizite Route für die 100.100.100.100 eingetragen ist dann nimmt er die Default Route um dahin zu kommen !

über 192.168.20.1

Das könnte man routen. Für welches Betriebssystem brauchst du die Syntax ?
Bei Winblows ist das route add 192.168.30.0 mask 255.255.255.0 192.168.20.1. Das routet dann ALLE Pakete zum .30.0er Netz über die Gateway IP .20.1
Willst du einzig nur die Host Zieladresse .30.1 darüber routen dann musst du einen Hostroute mit einer 32 Bit maske setzen: route add 192.168.30.0 mask 255.255.255.255 192.168.20.1.

nach 192.168.10.1

Das ist dann analog
route add 192.168.10.0 mask 255.255.255.0 192.168.20.1
Ein -p am Ende macht die Route permanent, sprich sie verschwindet nicht nach dem nächsten Reboot. Zum Testen ist es besser man lässt erstmal das -p so hat man die Routing Tabelle nach einem Reboot wieder jungfräulich

Du darfst niemals beide IPsec Clients also den AVM Client und den Shrew Client parallel betreiben. Das funktioniert nicht. Bei IPsec Clients gilt der eiserne Highlander Grundsatz: "Es kann nur einen geben !"
Du musst also den einen oder anderen Client vollständig deinstallieren und das System rebooten. Das sollte dir hoffentlich klar sein !

Grundsätzlich schon richtig - aber die beiden kommen zusammen klar. Mir macht nur diese eine Konfiguration Probleme - zu anderen Zielen (auch zu anderen Fritzboxen) bauen beide clients eine Verbindung auf - WENN die virtuelle IP Teil des fremden Netzes ist.

Das kann nicht sein !

Warum nicht? Vielleicht liegt ja hier der Fehler. Was genau kann da nicht sein?

Eine Route wäre hier ziemlicher Blödsinn. Warum sollte ich was ins 30.0er Netz routen über ein Gateway im selben IP Netz...das ist Unsinn !

Stimmt schon, blödes Beispiel.

Bei Winblows ist das route add 192.168.30.0 mask 255.255.255.0 192.168.20.1. Das routet dann ALLE Pakete zum .30.0er Netz über die Gateway IP .20.1
Willst du einzig nur die Host Zieladresse .30.1 darüber routen dann musst du einen Hostroute mit einer 32 Bit maske setzen: route add 192.168.30.0 mask 255.255.255.255 192.168.20.1.

Genau das habe ich schon durch. aber ich versuche es nochmal.

Edit:
Ich denke, das Problem liegt an einer der beiden folgen "Besonderheiten" dieser Verbindung, die sie von den anderen - die funktionieren - unterscheidet:

1. Das Zielnetz lautet 192.168.100.254 255.255.255.255 statt zB. 192.168.100.1 255.255.255.0 -> laut Anleitung von AVM aber grundsätzlich kein Problem
2. Die virtuelle IP, die dem client zugewiesen wird, liegt NICHT im Subnet der fremden FB. -> auch hier laut der Hilfe von AVM dem Grunde nach eine legitime Einstellung.

Willst du einzig nur die Host Zieladresse .30.1 darüber routen dann musst du einen Hostroute mit einer 32 Bit maske setzen: route add 192.168.30.0 mask 255.255.255.255 192.168.20.1.

Du meinst route add 192.168.30.1 mask 255.255.255.255 192.168.20.1. oder?

Hallo tillix!

Bin gerade durch einen Hinweis von aqui nach meinem Urlaub auf deinen Beitrag gestossen und bei dem Thema kribbelts...

Hast Du es gelöst?

Wenn nicht, bin ich gerne bereit, deine Konfig mit dem virtuellen Subnetz in der FB mal bei mir auszutesten. Mit der PfSense habe ich das jedenfalls problemlos im Einsatz, aber das nützt hier ja zugegeben nix...
Wo ist von AVM die Anleitung, dass das so geht? Ein Link wäre nett.
Welche FB, welche Firmware?

Bitte poste mal deine vpn.cfg

Besonders den Bereich
localip = ;
local_virtualip = ;
remoteip = ;
remote_virtualip = ;

Da liegt m.E. der Hase im Pfeffer, denn wenn Du mit virtuellen IP's arbeitest, müssen doch mindestens die der FB "local" (192.168.112.201 und die des Clients "remote" (192.168.112.x) im selben Netz liegen. Ist das sicher der Fall?

Da macht die FB das Routing nicht und wenn die nicht zwischen virtuellem Netz und ihrem LAN routet kann das doch nix werden, egal, was du auf Clientseite einträgst...

Wenn gelöst, wäre ich für die Lösung sehr dankbar, die FB's und das VPN sind immer lustig.

Gruß
Buc

Hallo Buc,

danke für Deine Antwort.

Hast Du es gelöst?

Ehrlich gesagt, habe ich das "Projekt" aufgegeben, weil der Aufwand in keinem sinnvollen Verhältnis zum Nutzen mehr stand und ich einfach kein bisschen weiter gekommen. Aber da Du geantwortet hast und ich grundsätzlich gerne wissen würde, woran es liegt, greife ich das noch mal auf.

Mit der PfSense habe ich das jedenfalls problemlos im Einsatz, aber das nützt hier ja zugegeben nix...

Na ja, da es in meinen Augen ein reines Routigproblem ist, vielleicht schon.

Wo ist von AVM die Anleitung, dass das so geht? Ein Link wäre nett.

http://avm.de/service/vpn/praxis-tipps/schritt-fuer-schritt-anleitung-f ...
Dort steht: "Die IP-Adresse kann im IP-Netzwerk der FRITZ!Box liegen. In diesem Fall ist darauf zu achten, dass die Adresse nicht schon an ein Gerät im Netz vergeben ist."
Das bedeutet, dass die Standardvorgabe eine IP außerhalb des Netzwerkes der FB ist und nur optional eine Adresse im Netz der FB möglich ist.

Bitte poste mal deine vpn.cfg

targets {
policies {
name = "öffentliche IP der Gegenstelle";
connect_on_channelup = no;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
virtualip = 192.168.112.201;
remoteip = 0.0.0.0;
remotehostname = "öffentliche IP der Gegenstelle";
localid {
user_fqdn = "xxxxx";
}
mode = mode_aggressive;
phase1ss = "all/all/all";
keytype = keytype_pre_shared;
key = "xxxxxx";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipaddr = 192.168.112.201;
}
phase2remoteid {
ipnet {
ipaddr = 192.168.100.1;
mask = 255.255.255.255;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.100.1 255.255.255.255",
"reject udp any any eq 53",
"reject udp any any eq 500",
"reject udp any any eq 4500",
"permit ip any any";
wakeupremote = no;
}
}

policybindings {
}

// EOF

denn wenn Du mit virtuellen IP's arbeitest, müssen doch mindestens die der FB "local" (192.168.112.201 und die des Clients "remote" (192.168.112.x) im selben Netz liegen. Ist das sicher der Fall?

Gerade nicht. Die Software von AVM routet entsprechend. Leider ist das nicht transparent.

Da macht die FB das Routing nicht und wenn die nicht zwischen virtuellem Netz und ihrem LAN routet kann das doch nix werden, egal, was du auf Clientseite einträgst...

Auf Clientseite routet auch nicht die entfernte FB, sondern die Clientsoftware von AVM.

Wenn gelöst, wäre ich für die Lösung sehr dankbar, die FB's und das VPN sind immer lustig.

Grundsätzlich funktioniert das problemlos. Auch mit Fremdsoftware. Nur eben nicht, wenn die Remote-IP nicht im Netz der Remote-FB ist. Nur ist das im vorliegenden Fall keine Option.

weil der Aufwand in keinem sinnvollen Verhältnis zum Nutzen mehr stand

komisch...eigentlich in 10 Minuten erledigt ?! Was meinst du denn mit "Aufwand" ?!

tsts, nie die flinte ins korn werfen...wir kämen sonst zu den wichtigen dingen im leben...

was ich meinte, war, dass doch auf der seite des einwahlclients, also dem shrew, eine ip aus dem range 192.168.112.0 vergeben sein muss, denn die fb nimmt für sich diese ip 192.168.112.201 nunmal und routet dann ins lan.
das kann ich bisher in den konfigurationen nirgends herauslesen.

wo ist denn definiert, welche virtuelle ip dem einwählenden client zugewiesen wird?

bitte setze mal testweise unter

localip = 0.0.0.0;
virtualip = 192.168.112.201;
remoteip = 0.0.0.0;

noch
remote_virtualip = 192.168.112.202;

setze im shrew unter policy policy generation level: unique und definiere unter "remote network resource" das lan (oder den client) hinter der fb.

und kontrolliere, ob der shrew adapter diese ip erhält.

erst dann kann doch ein routing zwischen den lokalen netzen über das virtuelle netz mittels des adapters erfolgen.

der von dir gepostete link enthält leider keinerlei weitere informationen zu diesen "inoffiziellen" spezialkonfigurationen...
wenn ein entwickler von avm hier dabei ist, sollte der sich doch mal outen. ich befürchte, die haben das nicht mal intern ordentlich dokumentiert...

kennst du dieses dokument? http://www.lobotomo.com/products/IPSecuritas/howto/AVM%20Fritz!Box%20HO ...

die arbeiten mit virtuellen ip's. es ist das einzige, das ich gefunden habe.

was soll

"reject udp any any eq 53",
"reject udp any any eq 500",
"reject udp any any eq 4500",

bewirken? Das blockt nach meinem naiven verständnis gerade die benötigten sachen... wo ist das so beschrieben?
lösch das mal raus. bei mir werden die ipsec ports jedenfalls nie nirgends geblockt.

auch dns möchte man meist über vpn nutzen können...

@aqui: hat man mit deiner zeitrechnung mehr oder weniger zeit auf dem planeten?

ich kämpfe jetzt seit 1 jahr mit einer fb, die sich nur reconnected, wenn ich ihr nen freundlichen schubs gebe...

gruß vom
buck

edit: ausserdem habe ich noch das hier gefunden: http://www.wehavemorefun.de/fritzbox/Talk:Versteckte_Features

an sich aktuell nicht relevant, aber schau dir mal die erläuterung zu use_cfgmode = yes an. wäre einen versuch wert. müsste man aber nochmal irgendwo verifizieren...

was ich meinte, war, dass doch auf der seite des einwahlclients, also dem shrew, eine ip aus dem range 192.168.112.0 vergeben sein muss

Die bekommt shrew automatisch (nämlich von der entfernten FB). Diese IP kann ich nach dem Aufbau des Tunnels auch pingen. Deswegen weiß ich auch, dass der Tunnel korrekt etabliert wird und dass das Problem nur am Routing liegt.

wo ist denn definiert, welche virtuelle ip dem einwählenden client zugewiesen wird?

ipaddr = 192.168.112.201

bitte setze mal testweise unter

Ich kann die Einstellung der entfernten FB nicht ändern.

und kontrolliere, ob der shrew adapter diese ip erhält.

Dieser Adapter erhält die 192.168.112.201

der von dir gepostete link enthält leider keinerlei weitere informationen zu diesen "inoffiziellen" spezialkonfigurationen...

Na doch. Die Standarkonfig ist die, dass eine virtuelle IP aus einem anderen netz als dem, in dem sich die entfernte FB befindet, zugewiesen wird. Man kann aber eine IP aus dem Netz der FB vergeben, muss dann aber (logischerweise) darauf achten, keine IP zu vergeben, die schon in diesem Netz verwendet wird.

was soll
"reject udp any any eq 53",
"reject udp any any eq 500",
"reject udp any any eq 4500",

bewirken?

Keine Ahnung. Das ist aber die Standardkonfiguration, wenn man die VPN-Verbindung mit den Bordmitteln von AVM einrichtet. Vermutlich ist das die Einstellung, mit der darüber bestimmt wird, welche Pakete über den tunnel geroutet werden und welche nicht.

Wie gesagt:
- die Einstellungen an der entfernten FB zu bearbeiten, ist keine Option.
- Mit der Software von AVM funktioniert es sofort einwandfrei.
- Der Tunnel wird erfolgreich etabliert. Der virtuelle Adapter bekommt die korrekte IP.

-> ich empfange "nur" keine Pakete aus dem entfernten Netz.

komisch...eigentlich in 10 Minuten erledigt ?! Was meinst du denn mit "Aufwand" ?!

Ich weiß nicht so recht, was ich von diesem Beitrag halten soll. Es werden ja nach wie vor keine Pakete geroutet. Und ein wenig mehr als 10 Minuten habe ich auch investiert.

nun denn, hier beginnt der philosophische part.

denn ich interpretiere die ip 192.168.112.201 als die der fritzbox von ihr selbst für sich selbst zugewiesene virtuelle ip. diese adresse kann der shrew nicht zugewiesen bekommen, denn sie ist identisch mit dem eintrag local_ip der fritzbox!

wofür könnte der eintrag remote_virtual_ip stehen?

was sagt denn ein ipconfig /all bzgl. des shrew adapters? der KANN nicht die 192.168.112.201 haben.
welche ip hat der denn wirklich?

der beitrag mit den 10 min. besagt in unnachahmlicher knappheit, dass du dich irgendwo in einem denkfehler verheddert hast und diesen knoten nicht gelöst bekommst. es ist kein technisches problem.

der shrew hat einen prima debug-modus. (unter programme-->shrew...) was sagen da die logs?

nun denn, hier beginnt der philosophische part.

Nicht unbedingt.

Ich habe mit dem AVM Tool, mit dem man für die FB eine VPN-Verbindung generieren kann, versucht, diese Konfigurationseinstellungen "nachzubauen", um zu verstehen, welche IPs wofür verwendet werden. Gerade weil die Bezeichnungen in der Konfigfile missverständlich klingen.
Und das klappt auch. Ich kann diese Konfiguration mit diesen Einstellungen nachbauen.

was sagt denn ein ipconfig /all bzgl. des shrew adapters? der KANN nicht die 192.168.112.201 haben.
welche ip hat der denn wirklich?

Sie hat wirklich - ich verspreche es hoch und heilig, gerne mit Unterschrift - diese besagte IP. Geprüft mittels ipconfig. Nach Aufbau des Tunnels auch pingbar.
Der Tunnel wird aufgebaut und der virtuelle Adapter, der von shrew erzeugt wird, erhält von der entfernten FB die Adresse 192.168.112.201 zugewiesen.

Folgende Netze / IPs finden Verwendung:

Lokales Netz: 192.168.12.0 255.255.255.0
Lokales Gateway: 192.168.12.1
Lokaler Rechner: 192.168.12.2
Entferntes Netz: 192.168.100.0 255.255.255.0
Entferntes Gateway (FB): 192.168.100.1
Entfernte Ressource, auf die ich zugreifen möchte: 192.168.100.2
Virtuelle IP shrew: 192.168.112.201

Die Einstellungen in der Software "Fernzugang einrichten" von AVM lauten denn wie folgt:
- Haken bei "anderes IP Netzwerk verwenden"
- IP Netzwerk: 192.168.100.1 Subnetzmaske: 32 - 255.255.255.255 (vielleicht liegt auch hier das Problem? Weil als Netz nur die IP des entfernten GW eingetragen ist?)
- IP-Adresse des Benutzers im Netz der FB: 192.168.112.201
- Haken bei "alle Daten über den VPN-Tunnel senden"

Damit erzeuge ich eine Konfigfile mit den besagten Einstellungen. Das ist also insoweit "Standard".

In Shrew ist unter "Address Method" eingestellt: "Use a virtual adapter and assigned address" und "obtain automatically". Dadurch wird dem Virtuellen Adapter eben die Adresse 192.168.112.201 zugewiesen. Das ist ein recht sicherer Indikator dafür, dass der Tunnel korrekt etabliert wurde, denn sonst bekäme der lokale virtuelle Adapter von der entfernten FB keine Adresse zugewiesen.

Soweit funktioniert alles wie "gewollt". Der Tunnel wird etabliert und shrew erhält die richtige IP für das Netz der entfernten FB. Dass diese IP nicht Teil des Netzes der entfernten FB ist, ist hier der Knackpunkt. Hier fehlt in meinen Augen einfach eine Route, die die Pakete von 192.168.100.0 zu 192.168.12.0 bringt.

Folgende Routen habe ich angelegt (wildes raten):
route add 192.168.100.0 192.168.100.1 mask 255.255.255.0
route add 192.168.100.0 192.168.12.1 mask 255.255.255.0
route add 192.168.100.1 192.168.100.1 mask 255.255.255.255
route add 192.168.100.1 192.168.12.1 mask 255.255.255.255

Aber nach wir vor kein ping. Tracert 192.168.100.2 geht bis zu meinem GW und endet dann.

Und ich möchte nochmals darauf hinweisen, dass es mit der Software von AVM funktioniert. Hier routet ganz offenbar diese Software. Nur leider "versteckt".

Edit:
Die Anleitung stammt von: http://avm.de/service/vpn/tipps-tricks/vpn-verbindung-mit-shrew-soft-vp ...
und im Reiter "Policy" des shrew clients habe ich sowohl die remote network ressource 192.168.100.0 255.255.255.0 als auch 192.168.100.1 255.255.255.255 als auch beides versucht.

so. erstes missverständnis aufgeklärt. ich meinte immer die vpn_cfg der fritzbox. du sprachst vom client, der natürlich auch so eine datei erzeugt...

somit ist natürlich die.201 richtig und korrekt. (und sorum betrachtet natürlich auch "lokal".

bitte schaue doch trotzdem in das vpn trace utility des shrew... es wird dir wahrscheinlich sagen, dass es ein problem mit der phase 2 gibt, obwohl die verbindung als aufgebaut angezeigt wird.

ich habe das eben mal testweise auf einer entfernten fritzbox so nachgebaut, weils gejuckt hat und das rennt (fast) auf anhieb mit den von dir initial beschriebenen einstellungen, ohne irgendwelche routen zu adden.

erstelle die verbindung im shrew doch nochmal (ja, ich weiss...) neu und achte auf die settings der phase 1 (3600 s, aes 256, aggressive, group 2) und besonders der phase 2 (esp-aes 256, sha1, group2, 3600 s) und unter policy unique und "remote network resource" 192.168.100.0 255.255.255.0 bzw. analog zu avm 192.168.100.254 255.255.255.255 (das könnte in der fritzbox auf die eine adresse festgelegt sein!!!)

ich hatte eben erst den gleichen fehler und es lag an den settings der fritzbox für die netzwerke in der phase 2. da der avm-client das bei dir ja aber kann, bleibt doch sonst nichts mehr. (clientseite ist bei mir win8 mit aktuellem shrew)

das MUSS gehen. (kann der shrew unter win10 denn zu anderen hosts connecten?)

viel erfolg
buc

bitte schaue doch trotzdem in das vpn trace utility des shrew... es wird dir wahrscheinlich sagen, dass es ein problem mit der phase 2 gibt, obwohl die verbindung als aufgebaut angezeigt wird.

Leider nein. Da wird kein Fehler angezeigt. Unter welchem Reiter würde der stehen? Ich habe die Einstellungen der Phase2 mal wild geändert - da steht nie ein Fehler, die VErbindung wird stets hergestellt. Seltsam.

Edit: OK, Log output level war auf "none". Super.
Jetzt werden folgende Fehler angezeigt:
15/09/16 07:29:09 !! : invalid private netmask, defaulting to 255.255.255.0
15/09/16 07:29:19 !! : config packet ignored ( config already mature )
15/09/16 07:29:39 !! : config packet ignored ( config already mature )

erstelle die verbindung im shrew doch nochmal

Mache ich heute abend. Allerdings ist es die dritte. ich habe die Konfig unter XP, Win7 und Win10 eingerichtet. Unter XP parallel mit dem AVM client.

und achte auf die settings

Die sind "leider" genau so.

kann der shrew unter win10 denn zu anderen hosts connecten?

Ja. 2 Andere FBs funktionieren (mit den virt. IPs im Netz der FB und mit einem 24er Netz). Und es läuft auch unter XP und 7 nicht.

invalid private netmask. da tippe ich doch schwer, dass die im shrew eingestellte nicht mit der in der fb konfigurierten übereinstimmt. die .254 hast du gesetzt?
keine chance an die vpn.cfg der fb ranzukommen?

gruß
buc

invalid private netmask. da tippe ich doch schwer, dass die im shrew eingestellte nicht mit der in der fb konfigurierten übereinstimmt.

Dieser Fehler wird - leider - auch bei funktionierenden Verbindungen angezeigt. Und ich bekomme ihn auch nicht "weg", egal, was ich an netzwerkrelevanten Einstellungen vor nehme.

die .254 hast du gesetzt?

es ist die 192.168.100.1 - ich habe die IPs im Log geändert. Bleiben wir bei der .1

Aber ja, das habe ich in der policy in shrew gesetzt.

keine chance an die vpn.cfg der fb ranzukommen?

Welche weiterführenden Informationen erhoffst Du Dir daraus? Dei beiden Dateien enthalten eigentlich die selben Informationen, oder?

in deiner fritzclientvpn.cfg am anfang steht halt die .254. dann steht die 001

in der cfg der fritzbox ist in der phase 2 die lokale netzmaske definiert. da kann eine ip oder ein netzwerkrange stehen, so wie ich das gesehen habe. daher.

hat man die settings des hosts, kann man den client anpassen, oder?

sonst bin ich langsam auch ratlos, da es bei mir auf anhieb funktionierte...

lustig ist, dass google bei der suche nach "shrew invalid private netmask" diesen beitrag schon an 4. stelle listet...

wenn du auf die fb keinen zugriff hast, was sagt denn der admin dort? wurde die büchse mal neu gestartet? ist es möglich, diese vpn-verbindung neu einzuspielen?

Erstmal vielen Dank für Deine Mühe damit.

in der cfg der fritzbox ist in der phase 2 die lokale netzmaske definiert. da kann eine ip oder ein netzwerkrange stehen, so wie ich das gesehen habe. daher.
hat man die settings des hosts, kann man den client anpassen, oder?

Hast schon recht.

sonst bin ich langsam auch ratlos, da es bei mir auf anhieb funktionierte...

mags Du mir mal Deine config zeigen? Vielleicht fällt mir was auf.

lustig ist, dass google bei der suche nach "shrew invalid private netmask" diesen beitrag schon an 4. stelle listet...

Das stimmt. Allerdings wird dieser Fehler auch bei funktionierenden Verbindungen angezeigt.

wurde die büchse mal neu gestartet?

ist es möglich, diese vpn-verbindung neu einzuspielen?

auch schon passiert

Und auch wenn ich mich damit wiederhole: Mit der Software von AVM funktioniert es. Auf mehreren Rechnern. Es muss ein Routingproblem sein. Denn der lokale virtuelle Adapter bekommt von der entfernten FB die Adresse korrekt übermittelt. Da funktioniert doch nur, wenn der Tunnel fehelrfrei funktioniert, oder?

mal ganz doof: kannst du mit der identischen exportierten shrew konfiguration in windows xp/vista/7/8 eine verbindung aufbauen?

willst du die config des shrew oder der fb?

jedenfalls ist es definitiv in der phase 2. das ist doch schon etwas. unique, strict, obey etc. probiert? (normal ist "auto" o.k.)

wenn du die vpn.cfg der fb schon nicht ändern kannst, könnte denn der admin dort dir das file schicken? oder dir eine auskunft geben, ob das in der phase 2 eine ip (.254) oder ein range ist???

es ist natürlich ein routingproblem. der shrew kann mit dem in phase 2 definierten netzwerk der gegenseite nichts anfangen, geht auf default und kann dann trotzdem (da auch verkehrt) nichts dahin routen...

ich würde noch darauf achten, den shrew evtl. im kompatibilitätsmodus zu installieren und einen vorgänger ebenfalls zu probieren.

wenn wirs nicht bald packen, schafft avm es vorher, eine win10 version zu veröffentlichen, das wäre schade um die liebesmüh...

warum der fritzclient das kann?

mal ganz doof: kannst du mit der identischen exportierten shrew konfiguration in windows xp/vista/7/8 eine verbindung aufbauen?

Nein.

Weder, wenn ich die Konfig exportiere, noch wenn ich sie manuell anlege, funktioniert es unter Win10, Win 7 oder XP.

unique, strict, obey etc. probiert?

Nein. Jedenfalls nicht, dass ich mich bewusst daran erinnere. Ich habe viel herumgespielt. Klar kann ich es nochmal versuchen.

ob das in der phase 2 eine ip (.254) oder ein range ist

Eine IP. Sozusagen ein 32er Range. Der identisch mit der IP des GW ist.

Ein bisschen abgewandelt (Subnet, ext. IP, PSK, User-ID, sonst alles gleich) die Konfig der FB:

version {
revision = "$Revision: 1.30 $";
creatversion = "1.1";
}

pwcheck {
}

datapipecfg {
security = dpsec_quiet;
icmp {
ignore_echo_requests = no;
destunreach_rate {
burstfactor = 6;
timeout = 1;
}
timeexceeded_rate {
burstfactor = 6;
timeout = 1;
}
echoreply_rate {
burstfactor = 6;
timeout = 1;
}
}
masqtimeouts {
tcp = 15m;
tcp_fin = 2m;
tcp_rst = 3s;
udp = 5m;
icmp = 30s;
got_icmp_error = 15s;
any = 5m;
tcp_connect = 6m;
tcp_listen = 2m;
}
ipfwlow {
input {
}
output {
}
}
ipfwhigh {
input {
}
output {
}
}
NAT_T_keepalive_interval = 20;
}

targets {
policies {
name = "externeIP";
connect_on_channelup = no;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
virtualip = 192.168.178.201;
remoteip = 0.0.0.0;
remotehostname = "externeIP";
localid {
user_fqdn = "abc@123.xy";
}
mode = mode_aggressive;
phase1ss = "all/all/all";
keytype = keytype_pre_shared;
key = "123456";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipaddr = 192.168.178.201;
}
phase2remoteid {
ipnet {
ipaddr = 192.168.100.1;
mask = 255.255.255.255;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.100.1 255.255.255.255",
"reject udp any any eq 53",
"reject udp any any eq 500",
"reject udp any any eq 4500",
"permit ip any any";
wakeupremote = no;
}
}

policybindings {
}

EOF

Und des client:

vpncfg {
connections {
enabled = yes;
conn_type = conntype_user;
name = "abc@123.xy";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 192.168.178.201;
remoteid {
user_fqdn = "abc@123.xy";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "123456";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.100.1;
mask = 255.255.255.255;
}
}
phase2remoteid {
ipaddr = 192.168.178.201;
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist =
"permit ip 192.168.100.1 255.255.255.255 192.168.178.201 255.255.255.255",
"permit ip any 192.168.178.201 255.255.255.255";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}

EOF

IP der entfernten FB: 192.168.100.1

es ist natürlich ein routingproblem. der shrew kann mit dem in phase 2 definierten netzwerk der gegenseite nichts anfangen, geht auf default und kann dann trotzdem (da auch verkehrt) nichts dahin routen...

Aber warum funktionieren dann die manuellen Routen nicht?

ich würde noch darauf achten, den shrew evtl. im kompatibilitätsmodus zu installieren und einen vorgänger ebenfalls zu probieren.

Kann ich schon machen. Aber unter XP funktioniert es ja auch nicht.

so. ist doch klar: deine fb hat die virtual_ip 192.168.178.201. eine remote_virtual_ip ist nicht definiert. (lag ich doch erst nicht so verkehrt...)

dein avm client kann mit dem setting eine virtuelle ip beziehen, da die entwickler den fehler offenbar vorhergesehen haben. der shrew kann es nicht, da nichts definiert ist.
die .201 ist für die clienseite definitiv falsch, da es die virtuelle adresse der fb ist.

setze doch mal im shrew auf dem 1. reiter "general" unter local host --> adapter mode "use a virtual adapter and assigned ip adress" und (achtung!) statt "obtain automatically" 192.168.178.202 mit netmask 255.255.255.0

dann sollte das nun gehen. (hoffentlich)

lg
bucko

so. ist doch klar: deine fb hat die virtual_ip 192.168.178.201. eine remote_virtual_ip ist nicht definiert.

Hm, da bin ich mir nicht so sicher. Das ist immerhin die Standardkonfiguration, wenn man das Tool von AVM für die Konfiguration des Tunnels benutzt. Auf diesem Tool baut auch die Anleitung auf - mit dem Unterschied eben, dass dort die virtual IP im Netz der FB ist.

setze doch mal im shrew auf dem 1. reiter "general" unter local host --> adapter mode "use a virtual adapter and assigned ip adress" und (achtung!) statt "obtain automatically" 192.168.178.202 mit netmask 255.255.255.0

Das habe ich versucht. Auch mit weiteren IPs aus dem 178er Netz - aber das Ergebnis ist das selbe.

Was immer das jetzt bedeutet: Nachdem es initial funktionierte, kann ich ebenfalls keine Verbindung zu der FB mehr herstellen, wenn ich einen virtuellen IP-Bereich verwende. (local .112.201 remote .112.202)

"Normal" geht es mit dem Shrew nur noch, wenn ich die Settings in Phase 2 alle auf "auto" stelle. (Das war erst anders!)
Da das aber auch noch hinter einem Kabelprovider hängt, mag ich da nicht mehr testen, sondern bin froh, dass die nötige Site2Site Verbindung immerhin halbwegs stabil geht.

Du hast den Beitrag auf "gelöst" gesetzt, bitte poste doch nochmal, wenn du weiter gekommen bist! Wundert mich etwas, dass so wenige ein VPN mit der FB in einem virtuellen IP-Bereich realisieren wollen...

ich bleib dran, das interessiert mich jetzt!

lg
buc

Du hast den Beitrag auf "gelöst" gesetzt

Ich habe mal versehentlich auf "zur Lösung beigetragen" geklickt. Dass damit der Thread insgesamt als gelöst markiert ist, lässt sich anscheinend nicht rückgängig machen, oder?

bitte poste doch nochmal, wenn du weiter gekommen bist!

Ich bin keinen Schritt weiter gekommen. Ich bin recht sicher, dass die Virtual IP aus der Konfig für den Client bestimmt ist.
Und klar, ich würde gerne wissen, woran es liegt - aber mir gehen die Ideen aus. Ich habe noch mal versucht, mittels Routen mich heran zu tasten, aber auch das ohne Erfolg.

ich bleib dran, das interessiert mich jetzt!

Na dann - lass uns weiter machen ....

Zitat von @tillixx07:

ich bleib dran, das interessiert mich jetzt!

Na dann - lass uns weiter machen ....

Was ist denn daraus geworden? Ich habe leider exakt das gleiche Problem. Seitdem Windows 10 auf einem Gerät vor ca. einem Jahr nach Release frisch installiert wurde, und ich damals Tage in diesem Thema versenkt habe (AVM war zwar bemüht, aber nicht sonderlich hilfreich), schaue ich alle paar Monate nach, ob es neue Lösungsansätze zu dem Thema gibt. Nun habe ich diesen Thread gefunden und alle Beschreibungen von tillixx07 treffen bei mir in gleicher Weise zu, sodass ich gar nicht groß weiter ausführen möchte.

Gibt es irgendwelche neuen Erkennisse?

Was ist denn daraus geworden?

Ich habe das Projekt aufgeben und arbeite mit einer VM, Windows 7 und der Software von AVM.
So gerne ich auch wüsste, woran es liegt - aber irgendwann ist mal Schluss.

Möglicherweise hängt es bei shrew an den Einstellungen "nat traversal", "dns" oder auch beim Reiter "policy" . Ich hatte später ein VPN-Problem, wenn ich mich über Mobilfunk einwählen wollte und konnte das lösen, indem ich mit diesen Einstellungen experimentiert hatte (und schlicht Glück hatte, dass es nach ein paar Versuchen funktionierte).

Nur bin ich zu wenig in der Materie drin, als dass ich mich gezielt auf Fehlersuche begeben könnte. Ich hatte mir hier etwas in der Art erhofft: "Klar, die Pakete werden nicht geroutet, weil xy nicht funktioniert".

Aus meiner Sicht ist es wirklich nur ein kleines Problem, wenn man tiefer im grundsätzlichen Verständnis drin ist, wie Pakete geroutet werden und was typische Fehler sind. Denn der eigentliche Aufbau eines Tunnels funktioniert. Client und Gateway kommunizieren erfolgreich, da der Client vom GW immerhin eine IP bekommt. Normalerweise hakt es bei Problemen mit VPN-Verbindungen eher daran.

Die korrekten Shrew Einstellungen findet man im oben zitierten Tutorial.

Aber nicht zu dieser Konstellation. Das Tutorial funktioniert für den Fall, in dem die IP des virtuellen Adapters im Netz der entfernten FB ist.

Das ist aber gerade der Unterschied hier.

So, ich habe das spasseshalber eben mit dem Shrew nochmal nachgebaut und kann das soweit bestätigen:

Tunnel zur FB steht mit virtueller IP Client 192.168.112.202 und FB 192.168.112.201

Ping auf 192.168.112.201 ist problemlos möglich.

Ping auf 192.168.175.1 (meine lokale FB IP im Remote Netz) geht nicht.
add route 192.168.175.0 255.255.255.0 192.168.112.201 gesetzt, aber kein Erfolg.(auch:Client IP .202)
Der Shrew hat definitiv beide Netze definiert.
In der FB ebenfalls.

Tracert liefert Sternchen und der Wireshark sieht keine ICMP Pakete von Client-IP zu FB-IP. (???)
Das VPN-Trce Utility des Shrew liefert keine Fehler. Das VPN ist offenbar o.k.
Aber das Routing macht nix, als ob nichts gesetzt wäre.
Bei anderen Verbindungen sind die Pakete sichtbar.

Eine AVM-Client Einwahl habe ich nicht getestet, da ich ein funktionierendes IPSec mit dem Wireshark benötige und mir das zuviel rumfuhrwerkt...

Soweit bestätigt das aber Tillixx07's Theorie, dass der Client da eine Route setzt, die Shrew nicht beherrscht und auch über route add nicht zu bewerkstelligen ist. (???)

Mal rein theoretisch: Wenn ich Windows sage: "Route Pakete für Netz X nach Gateway Y" und Gateway Y hat dann eben definiert, dass es die Pakete weiter nach Z routet müsste doch Windows wenigstens im tracert bis y kommen bzw. der Wireshark etwas loggen. Da ist aber in dem Fall nix. Totenstille. WO ist der Fehler?

@aqui: hast du aktuell eine FB da? Ich sende dir gerne die vpn.cfg zum testen.
Evtl. kommst Du mit deinem Background da noch einen Schritt weiter. Das ist doch mal eine Herausforderung.

Ich strecke hier jedenfalls nun auch die Waffen.

(Hätte ich das produktiv im Einsatz, täte ich aber AVM solange nerven, bis ich einen Entwickler der VPN-Komponente am Wickel hätte.
Der rafft nämlich, was da in der FB geht und was evtl. nur so klingt, als ginge es...)

CU
Buc

Aber das Routing macht nix, als ob nichts gesetzt wäre.

Ist die lokale Winblows Firewall entsprechend angepasst ?? Die dekalriert den virtuellen IP Adapter in der Regel in ein falsches Interface (öffentlich statt privat) das muss man in jedem Falle ändern.

hast du aktuell eine FB da? Ich sende dir gerne die vpn.cfg zum testen.

Jau habe ich... kannst du machen... Ich kann das dann nochmal testen.
Geht nur um Shrew auf einem Win 10 Client, richtig ? Mit Win 7 klappt es wenn ich das richtig verstanden habe.

Geht nur um Shrew auf einem Win 10 Client, richtig ? Mit Win 7 klappt es wenn ich das richtig verstanden habe.

Nein. Also jedenfalls bei mir nicht. Auf Win 7 läuft halt der client von AVM, mit dem es funktioniert. Shrew funktioniert weder unter XP, 7 oder 10.

OK, wenn der Buc mal mit der Konfig rüberkommt, dann checke ich das !

Was nur sehr komisch ist an der ganzen Sache... AVM selber postet auf der VPN Seite von denen eine lauffähige Client Konfig mit Shrew unter Windows 10 !!!
https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-mit- ...

Da sollte man eigentlich davon ausgehen das das mit Win 7 ebenso sauber funktioniert ?! AVM selber sagt ja auch das es mit Win Vista / 7 und 8 sicher getestet funktioniert.
Wenn es dann dennoch nicht klappt muss man ja eigentlich von einer Fehlkonfiguration einer seite ausgehen, denn ein Hersteller wird ja kaum eine Lösung veröffentlichen die er selber nicht wasserdicht getestet hat.

Was nur sehr komisch ist an der ganzen Sache... AVM selber postet auf der VPN Seite von denen eine lauffähige Client Konfig mit Shrew unter Windows 10 !!!

Ja, das hat mich auch verwundert und in mir die Hoffnung geregt, dass es nur ein klitzekleines Routingproblem ist.

Und nochmal aqui, die Konfiguration funktioniert, wenn die IP des virtuellen Adapters Teil des lokalen Netzes der entfernten FB ist. So sind die ganzen Beispiele aufgebaut.

Lediglich das Konfigurationsbeispiel für die AVM-Software geht von einem Standard aus, in dem die IP des virtuellen Adapters in einem anderen Subnetz liegt. Diese Konfiguration bekommt man auch standardmäßig, wenn man die AVM-Tools zur Erstellung eines VPN-Zugangs nimmt (bzw. nahm, aktuell kann man die Verbindungen in der FB anlegen, wobei die virtuelle IP meines Wissens dann auch im Subnetz der FB liegt).

Mit anderen Worten: Über das AVM-Tool erstellte Konfigurationen weisen die Besonderheit auf, dass sie standardmäßig dem virtuellen Adapter eine IP aus einem anderen Subnetz geben. Dieser Umstand wird aber bei den Konfigurationsbeispielen ignoriert, die Shrew betreffen.

wenn die IP des virtuellen Adapters Teil des lokalen Netzes der entfernten FB ist.

Bei IPsec ist das doch Standard für die jeweiligen Tunnel Endpoints?!

Vielleicht liegt hier das Problem, dass das bei AVM eben nicht Standard ist. Denn so ist eben die Konstellation.
Beispiel:
IP Client: 192.168.1.1
IP Virt. Adapter: 192.168.2.1
Lokales Netz der FB: 192.168.3.0

So ist die Konfig, die mit der Software von AVM "out of the box" funktioniert. Bei shrew kommen da eben keine Pakete an.

OK, bevor wir hier endlos philosophieren warten wir mal auf die Konfig vom Freibeuter.....

Ihr habts auf den Punkt.

Ich habe ein getrenntes virtuelles Netz für die Client-Einwahl auf der PfSense auch problemlos laufen.
Also z.B. mit:

Client IP in seinem lokalen Netz: 192.168.1.100
Shrew-VPN virtuelle Client IP: 192.168.10.100
PfSense im Netz 192.168.2.0/24

Da routet das Windows ohne Anpassungen der Firewall alles.
Als Remote-Network ist im Shrew einfach nur das entfernte 192.168.2.0/24 definiert.
route print liefert die korrekten Ergebnisse. Im Client wird das nirgends weiter definiert.

Auch mit der FB werden die Routen offenbar gesetzt. (Nochmal gecheckt) Aber es pingt nicht.

Hier die FB-Konfig zum nachbauen:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "vpn_test";  
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 192.168.112.201;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.112.202;
                remoteid {
                        user_fqdn = "me@mydomain.tld";  
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "secret";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
		phase2localid {
                        ipnet {
                                ipaddr = 192.168.179.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.112.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = 
                             "permit ip any 192.168.175.0 255.255.255.0",  
                             "permit ip any 192.168.112.0 255.255.255.0",  
			"permit ip any 192.168.3.0 255.255.255.0";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
}

Was im Shrew gesetzt werden muss, sollte sich für aqui ergeben.

Viel Spass!
(Es soll regnen, am Wochenende!)

Buc

Edit: Hier Windows 8.1

@the-buccaneer
Öhm ...

26. ipaddr = 192.168.179.0;

Das Frittengastnetz??? Das ist doch reserviert ... und hat noch ganz andere Einschränkungen, oder war das ein Tippfehler ?!

Gruß Skybird

Stimmt ! Diese IP wäre tabu auf der FB ! Das sollte der Buc nochmal korrigieren.
Ich werde im Testsetup mal eine andere nehmen...

nun, da sollte natürlich im vorliegenden fall 192.168.175.0 stehen. keine ahnung wie das andere netz da reinkam, eigentlich war das ein copy/paste mit änderung der sensiblen daten...

die 192.168.179.0 geht aber sehr wohl auch, wenn die fb dieses netz als eigenes netz verwendet und das gastnetz deaktiviert ist. ist bei mir seit vor-gastnetzzeiten in einem fall so gewachsen...

was passiert, wenn man das gastnetz aktiviert, wenn die fb den range schon selber belegt? lieber mal in ruhe lassen...

jetzt kommts aber: heute komme ich mit der konfig, die definitiv ging, nicht mehr zu einer etablierten verbindung. es werden keine sa's ausgehandelt und natürlich geht da auch kein ping mehr auf die 192.168.112.201. definitiv keine einstellung verändert.

fb loggt nichts, shrew loggt keinen fehler. fb wurde neu gestartet, mein windows heute nicht mehr...

good luck!

buc

@tillixx07,

im Programm "FritzBox! Fernzugang einrichten", musst du die Option "iPhone/iPod touch/iPad" auswählen und folgende Einstellungen benutzen:

E-Mail-Adress des Benutzers: User ( User+KeyID später in Shrew)
Name der Fritzbox: egal

Anderes Netzwerk verwenden: Ziel-IP im LAN (das ist die Accesslist unten in der Config).
IP-Adresse des Benutzers: IP zum User

Schlüssel: Pre-shared Key
Kennwort: Password zum User

Es ensteht dann eine Konfigurationsdatei mit folgenden Beispielwerten:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "leo@grundig";  
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 172.16.0.1;
                remoteid {
                        key_id = "leo@fritzbox.lan";  
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "secret";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "leo@fritzbox.lan";  
                        passwd = "123";  
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 172.16.0.1;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";  
                accesslist = 
                             "permit ip 192.168.180.11 255.255.255.255 172.16.0.1 255.255.255.255";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
}

Wenn du kein XAuth nutzen möchtest, dann löschst du die Zeilen 22-27. Diese importierst du in die FritzBox und gehst weiter nach der Anleitung zu Windows10/Shrew bei AVM vor, bei der du nichts ändern musst.
Mit diesen Einstellungen bekommt der Client die IP 172.16.0.1 und kann nur mit der IP 192.168.180.11 im LAN der FB kommunizieren. Teste das trotzdem mal gründlich aus. Benutzt habe ich eine FB 7320 mit der Firmware 6.30.

Ich hoffe, ich habe das Problem auch richtig verstanden.

@Netziner, du kannst einfach das LAN der FritzBox eintragen.
Viel Erfolg
BB

Habs grad auch mal getestet auf einer FB 7240 und da rennt es ebefalls so wie oben vom Kollegen BitBurg beschrieben fehlerlos.

im Programm "FritzBox! Fernzugang einrichten", musst du die Option "iPhone/iPod touch/iPad" auswählen und folgende Einstellungen benutzen:

Ich kann die entfernte FB nicht konfigurieren, das ist ja das eingangs erwähnte Problem. Könnte ich es, würde ich einfach dem virtuellen Adapter eine IP aus dem LAN der FB geben und es würde auch mit shrew funktionieren.

Mit anderen Worten: Die Konfiguration er FB ist gesetzt. Es geht nur darum, dass mit dieser Konfiguration zwar ein Tunnel etabliert wird - aber es werden keine Pakete geroutet. Da aber der Client von AVM funktioniert, liegt es wohl daran, dass dieser Client die Pakete adressiert. Er legt auch keine Route an (laut route print) - daher wird es wohl etwas internes sein.
Aber da das nur darum geht, dem Paket zu sagen, wo es hin soll, wird das aus meiner Sicht nichts sein, was dem AVM-client vorbehalten ist. Entweder ist es eine Einstellung im shrew-client oder man muss eine manuelle Route setzen. Mit beidem habe ich experimentiert - aber vermutlich mache ich einen grundlegenden Fehler.

@tillixx07: die raffen es nicht.

jungs: bitte baut das von tillixx beschriebene setting nach. dann rennt es nämlich nur bis zur fb und nicht in das hinter der virtuellen ip der fb liegende "reale" netz.

Habe gerade die cfg von BitBurg versucht. Problemlos. Klar. Denn die FB hat da KEINE virtuelle IP. Nur der Client.
Bei Tillixx hat aber die FB UND der Client eine virtuelle IP im selben Range. (192.168.112.0/24)

Sobald ich in der cfg für die fb die virtuelle ip 192.168.112.201 zuweise wird zwar noch verbunden, der tunnel steht, routing geht auf die virtuelle ip 192.168.112.201 aber NICHT mehr auf das "reale" 192.168.175.0/24 er Netz.
Probiert es aus! Ihr werdet im Windows die vom Shrew gesetzten Routen auf die virtuelle IP der FB sehen.

meine config war die folgende (an BitBurg angepasst)

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "vpn_test2";  
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 192.168.112.201;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.112.202;
		remoteid {
		user_fqdn = "test@mydomain.tld";  
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "pssst";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
		phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        
                                ipaddr = 192.168.112.202;
                                
                }                
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = 
                             "permit ip any 192.168.175.0 255.255.255.0",  
                             "permit ip any 192.168.112.202 255.255.255.255";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
}

Ich habe gerade zwar keine Fritte zur Verfügung aber warum macht ihr nicht mal folgendes:
Baut eine VPN-Verbindung nach dem Schema auf und schaltet euch via Telnet auf die Box und schaut euch mal die Routing-Tabellen und die Status-Logs an, zusätzlich wäre eventuell ein packet trace (wireshark dump) der internen Interfaces hilfreich..., all das bietet die Fritte doch als Hilfsmittel an, so ist man nicht gezwungen nur rum zu raten ...

aber warum macht ihr nicht mal folgendes

weil ich eben die relevante "Fritte" auch nicht zur Hand habe.

Zitat von @tillixx07:
weil ich eben die relevante "Fritte" auch nicht zur Hand habe.

Das kann man doch mit jeder anderen Fritte auch testen ...!

In der Tat. Aber auch hier habe ich keine mit vertretbarem Aufwand verfügbar.

Vor allem: Welches Ergebnis erhoffst du Dir? Das Problem liegt ja nicht daran, dass die entfernte FB nicht richtig routet. Der client bekommt nach Aufbau des Tunnels völlig problemlos von der entfernten FB eine IP zugewiesen. In wie fern siehst du das Problem bei der FB? Ich vermute doch stark, das Problem liegt beim client und darin, dass zwischen dem Netz des virtuellen Adapters und des realen Adapters die Pakete nicht geroutet werden.

Oder sehe ich das falsch?

Naja, wenn du in der Config eine IP aus einem Netz eingibst das die Fritte erstens nicht kennt und dieses Szenario nicht wirklich von AVM supported ist, würde mich doch mal interessieren was in der Routing-Table der Fritte steht.
Denn ohne explizite Route in dieses virtuelle Netz werden die Pakete ihren Weg nicht zurückfinden.

Naja, wenn du in der Config eine IP aus einem Netz eingibst das die Fritte erstens nicht kennt und dieses Szenario nicht wirklich von AVM supported ist

Beide Aussagen stimmen so aber nicht.

1. ich gebe in der Config keine IP ein - der client bekommt sie von der entfernten FB.
2. das Szenario wird nicht nur von AVM supported, es ist das Standardszenario, WENN man den client von AVM benutzt. Mit dem Client von AVM funktioniert es - aber nicht mit shrew.

Zitat von @tillixx07:
1. ich gebe in der Config keine IP ein - der client bekommt sie von der entfernten FB.

Im Configfile der Fritzbox steht die virtuelle IP die dem Client dann zugewiesen wird.

2. das Szenario wird nicht nur von AVM supported, es ist das Standardszenario, WENN man den client von AVM benutzt. Mit dem Client von AVM funktioniert es - aber nicht mit shrew.

Das ist aber ein AVM eigener Client und der hat schon immer alles anders gemacht ...
Ich kenne keinen schrottigeren VPN-Client als diesen, Standard war und ist das Teil auf keinen Fall.

Die sollten auf Remoteseite wirklich mal darüber nachdenken einen "vernünftigen" VPN Responder hin zustellen. Fritten sind doch nur Spielzeuge für Miniklitschen.

Hallo Tillix,

ich hatte nur deine Eingangsfrage gelesen und wusste nicht, dass die Konfiguration der FB fix ist. Ich nehme an, dass deine eigentliche Frage zusammengefasst so lautet:

Du hast bisher eine Verbindung mit der FritzBox über den AVM-Client hergestellt. Die FritzBox hat dazu diese Konfiguration (aus einem deiner Beiträge), die du nicht ändern kannst:

vpncfg {

 connections {
 	enabled = yes;
 	conn_type = conntype_user;
 	name = "abc@123.xy";  
 	always_renew = no;
 	reject_not_encrypted = no;
 	dont_filter_netbios = yes;
 	localip = 0.0.0.0;
 	local_virtualip = 0.0.0.0;
 	remoteip = 0.0.0.0;
 	remote_virtualip = 192.168.178.201;

 	remoteid {
 		user_fqdn = "abc@123.xy";  
 	}

 	mode = phase1_mode_aggressive;
 	phase1ss = "all/all/all";  
 	keytype = connkeytype_pre_shared;
 	key = "123456";  
 	cert_do_server_auth = no;	
	use_nat_t = yes;
	use_xauth = no;	
	use_cfgmode = no;
	
	phase2localid {
 		ipnet {
 			ipaddr = 192.168.100.1;
 			mask = 255.255.255.255;
 		       }
 		   }

 	phase2remoteid {
 			ipaddr = 192.168.178.201;
 			}

	phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
 	accesslist = 
 		"permit ip 192.168.100.1 255.255.255.255 192.168.178.201 255.255.255.255",   
 		"permit ip any 192.168.178.201 255.255.255.255";  
 	}

 	ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
 			    "udp 0.0.0.0:4500 0.0.0.0:4500";  
}

Da der AVM-Client nicht auf Windows 10 läuft, möchtest du dafür Shrew nehmen. Dabei ist zu beachten, dass der Client eine IP außerhalb des LANs der FritzBox erhalten soll. Mit Shrew ist dir das nicht gelungen, darum hast du Windows 7 in einer VM installiert und nimmst weiterhin den AVM-Client.

Deine Frage ist nun, wie du mit Shrew den AVM-Client "imitieren" kannst. Du stellst die Frage deshalb hier, weil du schon alles möglichen Kombinationen ausprobiert hast.

Meine Antwort wäre kurz und bündig:
Wenn du die FB-Konfiguration nicht ändern kannst, dann ist das nicht möglich. Die technischen Details brauchen wir nicht besprechen, da man dann über IPSec, speziell das Protokoll IKE, reden müsste.

Ich hoffe, dass ich dich diesmal richtig verstanden habe. Bitte bestätige mal, ob das zutreffend ist. Falls es so richtig ist, sollten nachfolgend nur Vorschläge kommen, welche die Shrew-Konfiguration betreffen. Alles andere hilft dir nichts.

Und hör damit auf, dauernd von Routing zu reden. Das ist kein Routingproblem.

BB

würde mich doch mal interessieren was in der Routing-Table der Fritte steht.

Ich checke das mal aus....auch wenn es dennoch nicht klappen sollte.
Bastelfritzbox gibts übrigens für 10 Euronen bei eBay:

http://www.ebay.de/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313 ...

Zitat von @aqui:
Ich checke das mal aus....auch wenn es dennoch nicht klappen sollte.
Bastelfritzbox gibts übrigens für 10 Euronen bei eBay:

Selbst die sind mir für so ein Teil zu schade

. Die investier ich dann doch lieber in einen Strauß Blumen für die bessere Hälfte, oder ich schick minge Bodo zur Wellnessmassage

Ich nehme an, dass deine eigentliche Frage zusammengefasst so lautet:

Exakt!

Die technischen Details brauchen wir nicht besprechen, da man dann über IPSec, speziell das Protokoll IKE, reden müsste.

Schade. Gelöst (umgangen) habe ich das Problem ja. Mir ging es eher darum, zu verstehen, was genau schief läuft.

Und hör damit auf, dauernd von Routing zu reden. Das ist kein Routingproblem.

OK, ich höre auf damit. Aber was ist es dann? Der Tunnel wird korrekt aufgebaut, der Client bekommt vom entfernten GW eine IP zugewiesen, daraus folgere ich (mit zugegeben eingeschränktem Wissen auf dem Gebiet), dass der Client und das GW korrekt miteinander kommunizieren. Nur die Pakete "wissen" anscheinend nicht, wo sie hin sollen. Da gibt es eigentlich nur zwei relevante stellen, an dem dieser "Infomationsverlust" auftreten kann: Im lokalen Netz der FB oder zwischen virtuellem Adapter und realem Adapter auf dem Clientsystem.

Ich kenne keinen schrottigeren VPN-Client als diesen

Eigentlich läuft er ausgesprochen stabil und in Verbindung mit einer FB ist er leicht zu konfigurieren. Für kleine Anwendungsszenarien, die keinen großen Administrationsaufwand und -knowhow bereitstellen können, ist diese Kombination ziemlich ideal. Für größere Installationen ist die FB sicherlich nicht geeignet - aber dafür ist sie auch nicht gedacht.

Aber was ist es dann?

Die kranke IPsec Implementierung von AVM...

Eigentlich läuft er ausgesprochen stabil

Das kann man eigentlich nur bestätigen. Und das auch noch vollkommen Plattform übergreifend. Es gibt wenige bis keine Alternativen die das so umfassend und gut können wie dieser Client.

Zitat von @tillixx07:

Ich kenne keinen schrottigeren VPN-Client als diesen

Eigentlich läuft er ausgesprochen stabil

Ich meinte damit den AVM-Client, nicht Shrew

. Ich kann dir etliche Systeme aufzählen zu denen ich hinzugezogen wurde bei denen der AVM-Client diverse Probleme unterschiedlichster Art verursacht hat, bis hin zu völlig verhunzten Networkstacks und völlig verstellter IPSec-Windows-Config.

Ich meinte damit den AVM-Client

Ich auch.

Vermutlich schießt man sich auf manche Software ein, bei der man dann Fehler eher sieht. Soweit ich ds mitbekommen habe, ließ sich der AVM-Client stets gut vom System entfernen (was keine Selbstverständlichkeit ist) und hielt stabil die Verbindungen.

Aber ich will - mangels entsprechender Provision

- gar keine Werbung für AVM machen. Zumal der Client eh Geschichte ist. Ich fand, dass es schlechtere gab und gibt. Für bestimmte Anwendungsfälle sind die Lösungen von AVM nicht die schlechtesten. Im echten professionellen Umfeld gibt es aber unstreitig wesentlich bessere Lösungen.

Die kranke IPsec Implementierung von AVM...

Hier habe ich leider zu wenig know-how. In wie fern spielt IPsec beim Transport der Pakete eine Rolle? Ich hänge gedanklich noch immer an dem Punkt fest, dass der Tunnel aufgebaut wird UND der Client vom GW eine IP bekommt. Wie kann das sein?

@tillix
"Ich hänge gedanklich noch immer an dem Punkt fest, dass der Tunnel aufgebaut wird ..."

Wenn bei Shrew die Meldung "connected" bzw. "tunnel enabled" erscheint, heißt das nicht zwangsläufig, dass der "Tunnel" auch aufgebaut ist. Du kannst mal in Shrew bei Phase 2 und Policy irgendwas eingeben. Jedesmal wird er Erfolg vermelden.
Die Meldung besagt nur, dass du alle für Phase 1 des Protokolls IKEv1 notwendigen Parameter (IDs, PSK usw.) richtig eingegeben hast. Shrew und die FB haben sich gegenseitig authentifiziert und sind nun bereit, die Phase 2 (den Quick Mode) zu starten. Erst nachdem dieser erfolgreich abgeschlossen wurde, kann die Datenübertragung beginnen. Von dieser Meldung darfst du dich also nicht täuschen lassen.

Denn genau da, im Quick Mode, liegt das Problem in der Konfiguration. Er kann nicht abgearbeitet werden, weil die ID (phase2localid) in der FB, nicht mit den in Shrew möglichen, konfigurierbaren IDs übereínstimmt. Meiner Ansicht nach ist das ein Fehler, dass es mit dem AVM-Client funktioniert. Achte mal auf das Schlüsselwort "ipnet" in deiner Konfiguration, dort müsste dann auch ein Subnet stehen. Die andere korrekte Variante wäre nur die Angabe "ipaddr", wie darunter bei der phase2remoteid. Mit beiden Einstellungen funktioniert es auch mit Shrew.

In der FB müsste also anstelle der IP-Adresse das Subnet stehen:

phase2localid { 
		ipnet {
			ipaddr = 192.168.100.0;
			mask = 255.255.255.0;
		}
	} 

Alternativ eben nur der Parameter ipaddr (ohne ipnet und mask) mit der Host-IP, was dann jeweils in Shrew unter dem Reiter Policy anpasst werden muss. Dass im ersten Fall (Subnet) nur eine bestimmte IP im LAN der FB genutzt werden kann, wird dann durch die ACL in der Konfiguration geregelt. Leider kannst du ja daran nichts ändern.

Bei der ACL hat sich übrigens entweder das Programm "Fernzugang" verhaspelt oder es wurde schonmal manuell geändert. Die Regeln sind eigentlich ja doppelt:

 	accesslist = 
 		"permit ip 192.168.100.1 255.255.255.255 192.168.178.201 255.255.255.255",   
 		"permit ip any 192.168.178.201 255.255.255.255";  

In der ersten Zeile wird nur eine IP erlaubt und in der nächsten Zeile alle anderen. Dem Programm traue ich das allerdings auch zu. In einem meiner Versuche damit, hat es mir mal einen PSK mit nur einem Zeichen erstellt.
.
BB

Wenn bei Shrew die Meldung "connected" bzw. "tunnel enabled" erscheint, heißt das nicht zwangsläufig, dass der "Tunnel" auch aufgebaut ist.

Schon klar. Aber wenn der virtuelle Adapter die richtige IP vom Gateway bekommt, müssen Pakete ja richtig an kommen. Die Information, wie die IP lautet, hat ja nur das Gateway. Oder begehe ich hier einen Denkfehler und die IP wird nicht innerhalb des Tunnels "übergeben"? Sondern schon in Phase 1?

Mit anderen Worten: Die Verbindung ist so "gut", dass der Client vom GW die richtige IP bekommt, aber so "schlecht" dass Pakete vom und/oder zum Zielnetz nicht durch kommen? Ich vermute, ich habe da ein grundsätzliches Verständnisproblem.

Und dass es ein "Phase2-Problem" ist, spricht entgegen, dass es funktioniert, wenn ich diese Konstellation nachbaue und - entgegen der Standardeinstellung - dem virtuellen Adapter in der Konfigurationsdatei für die FB eine IP aus dem lokalen Netz der FB gebe. ich habe das damals recht ausgiebig mit einer FB getestet (die ich gerade nicht mehr habe, um es erneut zu testen). Sobald der virtuelle Adapter im Netz der FB ist, funktioniert es, ist er es nicht , funktioniert es nicht.

Das hat mich ja auf das Brett gebracht - auch wenn Du mir jetzt dafür an die Gurgel gehst - dass es ein Routingproblem ist, weil statt zwei Netzen deren drei beteiligt sind.

Ich habe meinen Beitrag kürzen wollen, hab aber irgendwas falsch gemacht.

Oder begehe ich hier einen Denkfehler und die IP wird nicht innerhalb des Tunnels "übergeben"? Sondern schon in Phase 1? Mit anderen Worten: Die Verbindung ist so "gut", dass der Client vom GW die richtige IP bekommt, aber so "schlecht" dass Pakete vom und/oder zum Zielnetz nicht durch kommen?

Die Verbindung besteht erst nach vollständigem Durchlauf des Quick Mode. Die IP Adresse bekommt der Client davor.

Das hat mich ja auf das Brett gebracht - auch wenn Du mir jetzt dafür an die Gurgel gehst - dass es ein Routingproblem ist, weil statt zwei Netzen deren drei beteiligt sind.

Ich verstehe schon deinen Gedankengang - wenn er die IP bekommt, dann muss auch der Tunnel stehen. Dem ist aber nicht so, weil mit der Originalkonfiguration der Quick Mode nicht durchläuft. Das ist kein Routingproblem.

Aber wenn doch, wie von mir nachgebaut ein Ping sehr wohl an die VIRTUELLE IP der FB geht, also in meinem Fall die 192.168.112.201 und der (Shrew-) Client die virtuelle IP 192.168.112.202 hat: Dann steht doch nun definitiv der IPSec Tunnel.

Das konnte ich nun auch mit dem Trace Utility verifizieren. Windows "Route Print" liefert die gesetzte Route für 192.168.175.0 über 192.168.112.201.
Trotzdem ging da nix durch. Im WireShark konnte ich KEIN Packet sehen. Da stimmt doch was im Routing nicht. Ich bin da bei Tillixx.

Ich hatte auch ein händisches route add versucht. niente.

Ich habe den AVM Client nicht installiert und getestet, aber ich bin sicher, das von Tillixx beschriebene Verhalten wäre da. (Es verbindet)

Warum ist es kein Routing Problem, wenn in einer etablierten VPN-Verbindung kein Traffic ins sekundäre Netz stattfindet?

Nur so zur Klarstellung: Die von Tillixx gepostete Konfig ist die des Clients. Die passende Konfig der FB müssen wir ja leider raten...

Buc

Buccaneer,

lies mal meinen zweiten Post. Tillixx hat bestätigt, dass das die aktuelle Konfiguration der FB ist. Diese kann er nicht ändern. Wenn du die dazu passenden Einstellungen in Shrew gefunden hast, mit oder ohne Routen, dann poste sie bitte. Alles andere hilft ihm nicht.

Nur so zur Klarstellung: Die von Tillixx gepostete Konfig ist die des Clients. Die passende Konfig der FB müssen wir ja leider raten...

Müsst ihr nicht. Ich habe die Konfig "nachgebaut" und gepostet.
Am 23.09.15:

Ein bisschen abgewandelt (Subnet, ext. IP, PSK, User-ID, sonst alles gleich) die Konfig der FB:

OK. Für mein Verständnis:
In Phase 1 wird ein Tunnel etabliert und das entfernte GW weist dem client eine IP zu. Ich gehe mal davon aus, dass bereits in dieser Phase ein verschlüsselter Tunnel existiert?

Dann stellt sich die Frage: Wofür ist die Phase 2 gedacht, wo doch schon ein Tunnel steht, über den Informationen fließen?

In Phase 2 werden die IPsec SAs zwischen den Teilnehmer negotiated !

Und da gibt es keine Meldung oder ein Log, das besagt: "Phase 2 hat nicht funktioniert"? Das ist ja für eine Fehlersuche übel, wenn brav die Meldung angezeigt wird, man sein mit dem GW verbunden.

Doch die gibt es immer wenn die Phase 2 SA Negotiation fehlschlägt.
Das Problem ist nur das bei den billigen Consumer Routern nicht dettailiert geloggt wird sondern meist nur sehr rudimentär...wenn überhaupt.

Leider enthält die von Tillixx gepostete FB-Konfig eine Menge an Werten, die in den mir sonst bekannten vpn.cfg nicht auftauchen.

Der von mir beschriebene Nachbau erstreckte sich darauf, überhaupt einmal eine FB und den Shrew mit virtuellen IP's zu verbinden.
Die verwendete cfg hatte ich geposted.

Das gelingt wie beschrieben bist zur virtuellen IP der FB. (immerhin!)
Leider hat das ausser mir (und Tillixx) niemand versucht.

@tillixx07: Wie hast du denn das nachgebaut, wenn du an die FB nicht ran kommst?

@aqui: Phase 2 steht bei mir wie ne 1. (Sonst kein Ping auf externe virtuelleip der FB und auch im Shrew unter SA's kein established.
Das müssen doch irgendwelche Routen sein.

Buc

(Das hat hier Chancen zum längsten Thread aller Zeiten aufzusteigen)

Wie hast du denn das nachgebaut, wenn du an die FB nicht ran kommst?

Ich habe ja die client-configfile. Und ich weiß, dass das AVM-Tool benutzt wurde, die beiden Files zu erstellen. Da ist es nicht allzu schwierig, das auszuprobieren und wenn als Ergebnis die client-configfile heraus kommt, hat man auch die der FB. Das Programm ist in seiner Konfigurierbarkeit sehr überschaubar.

Und insgesamt ist die Konfigurierbarkeit der Phase 2 ebenfalls überschaubar, @BitBurg @aqui. Wie gesagt, der einzige Unterschied zu der Anleitung von AVM zu shrew sind die drei Netze. Das sollte die Phase 2 doch gar nicht betreffen?

So.
Ich habe eine funktionierende VPN Verbindung mit Shrew und der Fritzbox mit einer virtuellen IP für den CLIENT.

Dazu habe ich mir jetzt aus Neugier doch mal das AVM Tool installiert und eine Konfiguration für die FB generiert.

 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "test@fqdn";  
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.112.201;
                remoteid {
                        user_fqdn = "test@fqdn";  
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "mickymaus";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.175.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.112.201;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = 
                             "permit ip 192.168.175.0 255.255.255.0 192.168.112.201 255.255.255.255";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
}


// EOF

Die von AVM konfigurierte Client Konfig sieht so aus:

version {
        revision = "$Revision: 1.30 $";  
        creatversion = "1.1";  
}


pwcheck {
}


datapipecfg {
        security = dpsec_quiet;
        icmp {
                ignore_echo_requests = no;
                destunreach_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                timeexceeded_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                echoreply_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
        }
        masqtimeouts {
                tcp = 15m;
                tcp_fin = 2m;
                tcp_rst = 3s;
                udp = 5m;
                icmp = 30s;
                got_icmp_error = 15s;
                any = 5m;
                tcp_connect = 6m;
                tcp_listen = 2m;
        }
        ipfwlow {
                input {
                }
                output {
                }
        }
        ipfwhigh {
                input {
                }
                output {
                }
        }
        NAT_T_keepalive_interval = 20;
}


targets {
        policies {
                name = "name_der_verbindung";  
                connect_on_channelup = no;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                virtualip = 192.168.112.201;
                remoteip = 0.0.0.0;
                remotehostname = "fqdn_der_fb";  
                localid {
                        user_fqdn = "test@fqdn";  
                }
                mode = mode_aggressive;
                phase1ss = "all/all/all";  
                keytype = keytype_pre_shared;
                key = "mickymaus";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipaddr = 192.168.112.201;
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.175.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 192.168.175.0 255.255.255.0";  
                wakeupremote = no;
        }
}


policybindings {
}


// EOF

Das lässt sich im Shrew easy einrichten, wenn man die Standards für Fritzboxen beachtet, die ich mir hier spare.

Was nicht funktioniert ist, der FB eine eigene virtuelle IP zuzuweisen, was ich bisher immer wollte, da ich Tillixx Anforderung so verstanden hatte.
Wie man den vorhandenen Parameter local_virtualip korrekt konfiguriert, bleibt mir auch nach all der Zeit ein Rätsel. Man kann ihm einen Wert zuweisen und der Client routet dann auch bis dahin. Aber von der virtuellen IP der FB zur realen IP der FB führt kein Weg.

@tillixx07: Du siehst, die von meinem AVM Tool generierte cfg sieht sehr anders aus. Insbesondere machen die Eintragungen zu UDP reject keinen Sinn, da sie eben das IPSec blocken. etc.pp.

Hier aber doch noch die Shrew Konfiguration, evtl. hing es ja doch an der...

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:0
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:1
n:policy-list-auto:0
n:phase2-keylen:256
n:phase1-keylen:256
s:network-host:fqdnfritzbox
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:disable
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-server-type:address
s:ident-client-data:test@fqdn
b:auth-mutual-psk:mickymaus
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
s:policy-level:auto
s:policy-list-include:192.168.175.0 / 255.255.255.0

Ich hoffe, es hilft dir. Ich bin soweit zufrieden und mit meiner Neugier am Ende.

Buc

(Der sich gerade nicht zu seinem Lieblingskiosk traut, da der Betreiber vorhin sagte, er hat ein Problem mit seiner Fritzbox...)

Zitat von @tillixx07:
Und insgesamt ist die Konfigurierbarkeit der Phase 2 ebenfalls überschaubar, @BitBurg @aqui. Wie gesagt, der einzige Unterschied zu der Anleitung von AVM zu shrew sind die drei Netze. Das sollte die Phase 2 doch gar nicht betreffen?

Das ist die aktuelle Konfiguration der FB und du hast die entsprechenden IP-Adressen in Shrew eingetragen. Damit funktioniert es nicht:

phase2localid { 
       ipnet {   <-- Achtung!!!
          ipaddr = 192.168.100.1;       = Remote Network Ressource (Shrew)
          mask = 255.255.255.255;
phase2remoteid {
          ipaddr = 192.168.178.201;     = Virtual Adapter (Shrew)

Ändert man die FB-Einstellungen wie folgt, dann klappt der Verbindungsaufbau:

phase2localid {
          ipaddr = 192.168.100.1;       = Remote Network Ressource (Shrew)
phase2remoteid {
          ipaddr = 192.168.178.201;     = Virtual Adapter (Shrew)

In beiden Fällen benutzt Shrew die gleichen Einstellungen. Man kann in Shrew nichts ändern, damit es mit dem ersten Beispiel funktioniert, denn es wird ja schon die passende IP verwendet. Die Änderung muss in der FB erfolgen

Durch Routingeinträge kannst du den Verbindungsaufbau nicht beeinflussen, die erforderlichen Routen leitet Shrew aus der Konfiguration ab und trägt sie selbständig ein. Von deiner Seite aus kannst du nichts machen.

BB

Von deiner Seite aus kannst du nichts machen

Damit kann ich wenigstens was anfangen - auch wenn es nicht das ist, was ich hören wollte

Vielleicht noch eine Verständnisfrage:
Warum klappt das dann mit dem Client von AVM? Der hat doch die selben Informationen wie shrew und da werden die Pakete transportiert?

Ich habe den Ausschnitt aus deiner Konfiguration:

FB:						        AVM-Client:              
phase2localid {				        phase2remoteid {         
 ipnet {		     <----------------->      ipnet { 
 ipaddr = 192.168.100.1;		      	        ipaddr = 192.168.100.1;
 mask = 255.255.255.255;			        mask = 255.255.255.255;

In FB und AVM-Client ist als ID-Typ "ipnet" und als Inhalt eine Host-Adresse eingetragen. Das akzeptiert die FB. Shrew sendet bei einer Host-IP den korrekten ID-Typ "ipaddr" und das stimmt dann nicht mehr überein.
Ganz genau kann ich das allerdings nicht sagen. Dazu müsste man den AVM-Client mal mit einem Linux-Rechner verbinden, dann könnte man sich das evtl. in Wireshark ansehen.

BB

gelöst Frage Netzwerke Router, Routing

Mehr von tillixx07

Batch: Übergabe einer Echo-Ausgabe in eine zweite Batch mit "call"tillixx07 - 6 Kommentare

Freigabenamen und Ports der installierten Drucker per batch auslesentillixx07 - 22 Kommentare

Namensauflösung für Client in anderem Subnetz funktioniert nichttillixx07 - 5 Kommentare

Suchfunktion in Windows7 findet keine Dateinamen mit Zahlen- und Buchstabenkombinationentillixx07 - 4 Kommentare

Heiß diskutiert