Shrew - FB 7270 - Key

[AHoppe]

Hallo,

ich habe mit Hilfe der Fritz-Software den Fernzugang zu meiner FB eingerichtet. Auf meinem Rechner mit Win XP habe ich die erstellte Konfiguration importiert und es klappt auch einwandfrei.

Für mein Linux-Notebook habe ich Shrew installiert imd wollte dies gemäß AVM-Anleitung einrichten. Allerdings hänge ich jetzt gerade am Key, den ich im Reiter Authetification -> Credentials eingenen soll.

Bei der Einrichtung mittels Fritz!Fernzugang_einrichten wurde ich nicht nach einem Passwort gefragt. In den Konfigurationsdateien ist ein Key angegeben (viele Buchstaben und Zahlen), aber mit diesem bekomme ich keine Verbindung.

Die Linux-Variante erklärt mir:

"failed to attach to key daemon ..."

Ein Versuch unter Win XP berichtet (das XP, bei dem Fritz!Fernzugang funktioniert):

...
bringing up tunnel ...
gateway authentification error
tunnel disabled
detached from key daemon

Ich bin ahnungslos. Ich habe nach avm shrew key gegoogelt und finde keine andere Lösung als den langen Key-Eintrag in den Konfigurationsdateien. Der UFQDN-String stimmt übrigens.

Grüße

Andreas

 

[AHoppe]

Hallo Peter,

iked habe ich als root gestartet. Die Internet-Verbindung per UMTS steht und ich kann surfen. Mit dem gleichen UMTS-Stick geht der Fritz!Fernzugang.

Ich werde mir mal die Skript besorgen und dann weiter probieren.

Danke erstmal für die Antwort!

Andreas

 

[AHoppe]

O.K., erster Teilerfolg.

Der iked startete nicht richtig, was ich aber nicht gesehen habe, da dies automatisch beim Start passiert und ich gar nicht darauf aufgepasst habe. :argh:

Jetzt läuft der iked und ich komme bis zur selben Fehlermeldung wie bei Windows. Das Skript habe ich und muss es nur nich ausprobieren, aber jetzt muss ich erst einmal ans Arbeiten...

Grüße

Andreas

 

[AHoppe]

Das müsste ich mal ausprobieren. In meiner ausgedruckten Konfigurationsdatei ist es ein 34-stelliger String unter anderem mit einem #-Zeichen.

Ich werde die beiden Konfigurationen (für die FB und für den Client) mal händisch auf einen anderen Schlüssel bearbeiten.

Mit dem Skript hat es übrigens nicht geklappt. Ich bekomme einen "negotiation timeout occured".

Grüße

Andreas


Nachtrag:

Die händische Bearbeitung hat funktioniert. Jetzt bekommt er eine Verbindung. Nur Daten wollen noch keine Daten hin und her. Ich arbeite daran.

 

[AHoppe]

Nö, geht noch nicht, aber das kann ich erst heute Abend richtig ausprobieren, weil ich während der Arbeit sinnvolles machen sollte.

Aber ich denke das kriege ich irgendwie hin.

Grüße und Danke

Andreas

 

[AHoppe]

So, hab gestern Abend noch ein bissl probiert. Erstmal unter der Win-Variante.

Den Tunnel baut Shrew angeblich auf, auch wenn die FB nur sagt, dass die Verbindung gerade aufgebaut wird. Die pings funktionieren nicht bzw. gehen nicht zur FB durch. Eine Suche ergab zum einen:

Es sollte use_nat_t = yes gesetzt sein, was der Fall ist.

Dann sollten die Routen richtig gesetzt sein. Von meinem laienhaften Verständnis aus, muss also alles was von meinem Rechner draußen nach drinnen will, auf meine dyndns-Adresse gelenkt werden und alles was zurück kommt, muss auf meinen virtuellen Netzwerkadapter geroutet werden, oder?

Ist es dabei ein Problem, dass den tatsächlichen NW-Adaptern (Lan + WLan) jeweils eine Adresse aus dem gleichen IP-Bereich zugeordnet ist? Hintergrund: wenn ich im Büro bin, dann kann ich den Laptop schnell anstöpseln und bin im Netz. Wenn ich unterwegs bin, will ich mich einwählen. IP-Doppelvergaben bestehen aber definitiv nicht.

Grüße

Andreas

 

[pfeffer]

wahrscheinlich besteht doch ein Problem mit IP-Doppelvergaben: Wie ist denn die lokale IP der Router (Standard Gateways)?
Vermutlich sind die beide 192.168.178.1 - ich würde denken, dass es dann nicht funktionieren kann, denn die verschlüsselten VPN-Pakete müssen ja zunächst an den lokalen Router 192.168.178.1. Wenn nun die Route so gesetzt ist, dass alle Pakete an 192.168.178.x über das VPN laufen sollen, dann können die verschlüsselten VPN-Pakete nicht versendet werden, weil sie erneut verschlüsselt werden und versucht wird, sie über den Tunnel zu schicken.

Vielleicht habe ich Dich auch missverstanden, was meinst Du mir "unterwegs bin"? - Befindest Du Dich dabei im gleichen Netz oder ist es ein anderes Netz mit nur der gleichen privaten IP? (in obiger Antwort habe ich letzteres angenommen)
Außerdem: was meinst Du mit "einwählen" - das Herstellen der WLAN-Verbindung oder der VPN-Verbindung? oder vielleicht UMTS?
Welche Verbindung nutzt Du zum Herstellen der VPN-Verbindung? WLAN? LAN? UMTS?
Hast Du Lan und Wlan gleichzeitig in Betrieb? - vermutlich nicht.

Zu dem Passowort: Ich glaube, AVM speichert das Passwort codiert in der .cfg. Das darin enthaltene Passwort ist also nicht das tatsächlich verwendete, vielmehr muss es erst decodiert werden. Ob das Passwort an dieser Stelle codiert ist, erkennt die Fritzbox an einer bestimmten Zeichenfolge, die die codierten Passwörter kennzeichnet (ich galub so aus dem Kopf mehrere $ am Anfang und/oder Ende der Zeichenfolge) - hmm, ich glaub, ich hab da was verwechselt.

Gruß,
Pfeffer.

 

[AHoppe]

Ja, ich habe gerade gesehen, dass mein Post schwer zu durchschauen ist...

Der Windows-Laptop, mit dem ich die Einstellungen zunächst prüfen will, ist wie folgt eingerichtet:

WLan deaktiviert, wenn aktiviert, ist die IP 192.168.0.101 zugeordnet.
Lan ist aktiviert, aber während der Tests nicht angeschlossen (logischerweise...), IP: 192.168.0.51

Gateway für beide ist die 192.168.0.253 (Fritz!Box).

Wenn ich unterwegs bin, habe ich eine UMTS-Verbindung, die mir eine IP aus dem 10er-Bereich zuteilt (klarmobil-UMTS-Flat). Die "VPN"-IP ist die 192.168.0.181.

Doppelte IP-Vergaben im 192.168.0.0-Netz bestehen definitiv nicht. Das gleiche Problem habe ich zur Zeit auch noch mit meinem privaten Linux-Laptop, das eine IP aus dem Bereich 192.168.100.0 hat.

Ich habe jetzt mit den Routen noch nicht viel probiert, weil ich zur Zeit faschingsaktiv bin.

Aber grundsätzlich sollte wohl alles, was nach 192.168.0.0 geht über die dyndns-Adresse laufen. Und alles was von 192.168.0.0 kommt, muss zu meiner 192.168.0.181, oder?

Bezüglich des Passwortes glaube ich nicht, dass das was anderes drinstehen muss als in den cfg-Dateien, denn wenn ich ein gämzlich anderes Passwort bei Shrew eingebe, dann meckert Shrew bereits zu Anfang der Verbindung, dass da was nicht richtig funktioniert. Gebe ich das PW so wie in der cfg an, dann läuft Shrew durch bis tunnel enabled.

Grüße

Andreas

 

[pfeffer]

Aber grundsätzlich sollte wohl alles, was nach 192.168.0.0 geht über die dyndns-Adresse laufen. Und alles was von 192.168.0.0 kommt, muss zu meiner 192.168.0.181, oder?

Du hast Dich nicht sehr präzise ausgedrückt. Wenn Du nur den Traffic in das lokale Netz über das VPN leiten willst, dann brauchst Du eigentlich keine richtige Route, da Du Dich nach dem Tunnelaufbau ja im selben Subnetz befindest.
Ich vermute, dass mit Deinen Policies was nicht stimmt. Offenbar klappt die Authentifizierung, deswegen schreibt die FritzBox "wird aufgebaut". Allerdings scheinen sich die beiden Seiten nicht über die Policies einigen zu können.

Gruß,
Pfeffer.

 

[AHoppe]

Ja, es soll nur der Traffic ins Netz 192.168.0.0 über den Tunnel gehen. Dann prüfe ich mal die Policies, aber das mache ich erst übermorgen, denn morgen ist Aschermittwoch, da bin ich nicht einsetzbar.

Grüße und Danke!

Andreas

 

[AHoppe]

So, ich bin jetzt ein wenig weiter.

Mit den Policies hatte mein Problem nichts zu tun, sondern wohl eher mit dem UMTS-Anbieter oder Linux und der UMTS-Karte.

Ich habe den Linux-Rechner statt über UMTS - weil ich es nicht hinbekommen habe - einfach mal per LAN an mein heimisches Netz (mit Fritz-Router) gehängt und die VPN-Verbindung hergestellt und siehe da, es funktioniert.

Bei einer Verbindung über UMTS erhalte ich zwar die Meldung, dass der Tunnel hergestellt worden ist, aber ich kann gar nicht mehr raus aus meinem Rechner (sozusagen), d.h. dass jeder Ping, der nicht auf meine Rechner-IPs (192.168.1.51 für mein lokales Heimnetz und 192.168.0.181 für das VPN-Netz) abgesetzt wird, gar keine Rückmeldung liefert. Ich bekomme auch keine sonstigen Internet-Aufrufe (Webseiten, Email, FTP ...) mehr hin.

Auf einem anderen Rechner mit Windows 7 funktioniert der Fritz!Fernzugang mit der UMTS-Karte jedoch einwandfrei.

Ich werde jetzt mal auf dem Win7-Rechner nochmal Shrew installieren und mal dort den VPN-Zugang prüfen.

Grüße

Andreas

 

[Gompf]

Hi,

Ich habe genau das selbe Problem, Sowohl mit NAT als auch mit NAT-T. Der tunnel ist laut ikec aufgebaut aber es geht nichts durch. Auf der FB Seite steht das die Verbindung aufgebaut wird, aber noch nicht steht.

Der Hammer ist, das die Linux Machine (ein Server) und die FB public IPs haben, also die Vermutung auf NAT order Firewall ist nicht gegeben. Das Muesste alles so tun ?

Ich weis nicht weiter

/Chris

 

[AHoppe]

Ich hatte im Frühjahr dann den Win 7 Rechner mit Shrew ausprobiert und identische Einstellungen verwendet und es hat funktioniert. Die softwareseitigen Einstellungen für die Verbindung waren also richtig.

Die UMTS-Einstellung habe ich aber nicht mehr hinbekommen, was auch nicht weiter dramatisch war, da ich alle Fernzugangsaufgaben dann einfach mit meinem Win 7 Rechner gelöst habe, wenn ich unterwegs war.

Zuhause klappts über das kabelgebundene Netzwerk eh ohne Probleme sowohl unter Win 7 als auch unter SuSE und Debian.

Grüße

Andreas

 

[Gompf]

Einen Ping bitte,Vasili, nur einen einzigen Ping

Ich habe auch schon was neues. Sehr interessant. Wenn alles korrekt konfiguriert ist, dann fuehrt ein einziger Ping von der Linux Seite zu einem funtionierendem tunnel, und dann steht er.

SPrich auf der einen (FB) seite einen dauer ping auf die RemoteIP fahren. Mit Shrew auf der anderen Seite Connected, FB sagt ("Connecting", ist ne international, sorry also "Verbinden" wohl ...) und nichts geht durch und zwar genau so lange bis ich einen Ping von der Shrewseite losjage, einer reicht (der geht auch gleich durch), dann kommen ganz ploetzlich der dauer ping auch durch.

Laesst sich beliebig wiederholen. Ist leider nur nicht praktikabel im dauereinsatz.


/Chris

 

[AHoppe]

Dann würde sich also ein Startup-Skript anbieten:

Tunnel aufbauen
1 Ping absetzen
fertig...

Sehr verdächtig...

Grüße

Andreas

 

[Gompf]

Ich will da eigentlich eine AD Replizierung drueber hinbekommen, da die FB SMB blocked, egal was. Ich muss zwei direkt im internet stehende Server anbinden, deswegen muss da ein SoftVPN her (leider...).

Ich habe das ganze netz bei uns mit FB VPN aufgebaut, weil es ultra stabil ist und nie muckt. Da habe ich natuerlich bei der Idee einen VPN Tunnel mit einem ping zu treten massiv Magenweh.....


/Chris

 

[Gompf]

Netze Routen ?

Es wird noch schlimmer, nicht nur das man das Teil treten muss, nein man kann auch keine Netze routen. Egal was ich zu machen scheine, es scheint in die Tonne getreten zu werden. Selbst wenn ich es unter umgehung der FB route.

Sprich: Ich weise dem Tunnel ja eine lokale IP zu, und wenn ich von einem anderen Rechner auf diese IP etwas route, dann geht das trotzdem auf dem DSL interface der FB raus. Magisch.

/Chris

 

[AHoppe]

Funktioniert denn die Verbindung beider Server, wenn diese mit einem Win-System laufen? Ist natürlich etwas aufwändig sowas zu testen, man braucht ja erstmal zwei Rechner, die dann eben mal eingerichtet werden müssten...

Soviel muss mein Tunnel Gott sei Dank gar nicht leisten, bei mir geht es nur um die Integration eines Rechners von außen ins Netz.

Grüße

Andreas

 

[Gompf]

Nun das ist ein ubuntu Machinchen bei Hetzner, das VMWare Server fuer Windows Guest hat, von denen da 3 laufen. Da ich natuerlich aus offensichtlichen Gruenden mein VPN nicht gerne auf Hetzners Netzwerk loslasse, soll die Linux Kiste VPN mit der FB herstellen und das ganze als host only network zwischen den Windows VMs routen. Damit habe ich so zusagen eine pseudo FB dort, und bin nicht auf eine der Windows VMs angewiesen dass sie laufen, also auch wenn alle rebooten ist das VPN da. So solles jedenfalls in der Traumwelt sein aber wie ich sehe ist das alles nicht so einfach

/Chris

 

[AHoppe]

Ist es schlimm, wenn ich an dieser Stelle aussteige. Ich glaube das wird mir zu hoch. :doof:

Aber ich erkenne das Problem, dass mal nicht so schnell die Rechner getauscht sind. :mrgreen::mrgreen:

Grüße

Andreas