Fritzbox, vpcn Client, Gateway

back2live

Neuer User
Mitglied seit
16 Okt 2008
Beiträge
104
Punkte für Reaktionen
0
Punkte
16
Hallo,

ein Linux Client mit vpnc verbindet sich mit einer Fritzbox. Der vpnc Client hat noch ein weiteres Netzwerk dahinter.
Kann nun im Fritzboxnetzwerk der vpnc Client als Gateway für das Netzwerk hinter ihm verwendet werden?

Das will nicht funktionieren. Die Anfragen an das vpnc-netz werden nicht durch den vpn-tunnel geschickt.

Geht das überhaupt?

Andi
 
Ja, so etwas geht.
 
Ist der vpnc-Client so konfiguriert, dass er routet?
Haben die Geräte in dem Netz hinter dem vpnc-Client auch eine Route in das Fritzbox-Netz?
 
Ja beim vpnc ist nat-t eingeschaltet und die route ist eingetragen.

Das Problem beginnt auf der Fritzbox Seite. Ping auf die IP des vpnc Clients geht, anhand der Laufzeit ist auch klar das die Antwort wirklich vom vpnc-Client kommt.
Es ist eine route für das netz am vpnc Client eingetragen.

Das komische ist das ein Tracert zur ziel ip nicht durch den Tunnel läuft. Es geht zur Fritzbox dann zu einer IP der Telekom obwohl die route eingetragen ist.
 
Falsche "accesslist" ... mehr dazu zu schreiben bringt nur eine Verschlechterung der Suchergebnisse für spätere Interessenten.

Das Thema ist ausführlichst hier in diversen Threads behandelt. Die Information von mir in #2 sollte nur "Mut machen", daß es kein Holzweg ist - sie sollte keine Suche ersetzen.
 
Ja, an der cfg aus dem FritzBox-Einrichten tool, habe ich auch schon an der Accesslist versucht, ich habe da schonmal eine 2. Zeile eingebaut, hat aber nicht funktioniert.

Muss da das Netz rein wohin ich will oder etwas anderes?
 
Mir bliebe nur das "Selbstzitat" ... das Thema ist in vielen denkbaren Varianten (u.a. "FRITZ!Box via FRITZ!Box via FRITZ!Box") bereits durchgekaut.

Wenn Du bei der Suche nichts findest, verwendest Du vielleicht eine "falsche Technik". Ohne zu wissen, wie Du da gesucht hast, werden wir schlecht helfen können, diese Technik zu verbessern.

Ob und wie das mit "FRITZ!Fernzugang einrichten" am Ende überhaupt zu konfigurieren ist, will ich nicht beschwören ... man kann es aber einfach mit einen passenden Text-Editor machen. Aber ich komme schon wieder ins "Erklären" und das will ich tatsächlich nicht ... ich könnte wenig bis nichts schreiben, was nicht bereits (mehrfach) geschrieben wurde.
 
Ja natürlich per Texteditor.

Dann vielleicht abschließend noch ein Link von dir wo es behandelt wurde damit falls jemand den Thread findet auch noch geholfen wird wenn er schon bei der Suche nur diesen hier gefunden hat ;)
 
Wenn ich eine Liste derartiger Links hier liegen hätte, stünde da ggf. schon ein solcher ... ich kann (will) damit tatsächlich nicht dienen.

Ich weiß aber genau, daß ich schon die Fakten, was zu einer ordentlichen "Fehlermeldung" bei VPN-Problemen gehört, so oft wiederholt habe, daß es einigen hier zu den Ohren herauskam und auch zum Thema "accesslist" habe ich (aus meiner Sicht, wie das wohl funktioniert) so viel geschrieben (was ist das, wie wirkt das, was muß da wann hinein), daß ich einfach nicht glauben kann, daß man nichts findet.

Und das Thema wurde ja auch nicht nur von mir behandelt ... es gibt auch ältere Threads zu dieser Thematik, auch wenn da ggf. einiges in neuerer Firmware vielleicht nicht mehr 1:1 stimmt. Aber seit Version 06.2x (das war Herbst 2014 rum) hat AVM am VPN fast nichts mehr gemacht ... zumindest nichts, was sich auf die Art und Weise der Konfiguration oder die Notwendigkeit/den Sinn bestimmter Einstellungen ausgewirkt hätte.

Wenn Du schon weißt, daß offenbar der Traffic für Carol bei Alice nicht in den Tunnel zu Bob gelangt, dann muß man halt dafür sorgen, daß sich das ändert. Was Du jetzt da wo und wie konfiguriert hast in der berühmten "2. Zeile", kann niemand hier im Thread lesen und damit müßte man es maximal erraten - die Chancen, da einen Treffer zu landen, hängen aber nicht nur vom Ratenden ab, sondern auch davon, was Du in diesem Punkt verstanden hast (das verringert die Chance auf einen Treffer aber wieder). Also gehört da zu einer Problembeschreibung schon mal im Minimum die konkret verwendete Konfigurationsdatei und (zur Kontrolle, daß die Eintragungen in der Konfiguration auch an der richtigen Stelle stehen) die Beschreibung der beiden zu verbindenden Netze (bzw. hier sind es ja sogar drei).

Ich kenne Leute, die haben ein LAN2User-VPN aufgesetzt und wollen darüber dann LAN1 mit LAN3 verbinden lassen ... einfach weil sie den Unterschied nicht kennen oder kannten.
 
Hallo,

ich weiß du meinst es gut. Leider ist das Internet voll mit Beiträgen in denen gesagt wird "das wurde schon x mal behandelt" leider finde ich diese allzu oft. Die wissenden in den Threds lassen dann leider keinen weiteren Link fallen (leider auch hier) somit ist das Netz jetzt um einen reicher :( Das wissen in verstaubten verlegten Büchern ist nichts wert.

Ich habe bereits nach sehr vielem gesucht. Wie auch sogar bei AVM etwas gefunden was nicht funktioniert hat.
Zu der Config gibt es keine gescheite Doku, woher sollte ich nun erfahren was die Parameter bedeuten. Bei wehavemorefun ist es auch bescheiden erklärt.
Wären nun einfach Routing Tabellen zu konfigurieren wäre das kein Problem.

Was ich im Moment gemacht habe was jetzt funktioniert ist das ich dem vpnc Client per iptables den Traffic an den client dahinter weiter natte.


Es wäre eben schön zu erfahren was es sich mit dem Config file bzw. der Access list auf sich hat.
 
Selbst wenn man Dir hier noch einmal gesondert helfen wollte ... wie soll man das bitte ohne eine konkrete Idee, wo Du Deinen Fehler machst, tun?

Meine Ansage "durch die Blume", daß Deine Problembeschreibung nun mal äußerst unvollständig ist, kommt ja offenbar nicht an ... vielleicht hilft Dir ja die Aufzählung am Ende dieses Beitrags dabei, eine Vorstellung zu entwickeln, was man dazu alles von Dir erfahren müßte (und da geht es noch um zwei Peers, während es bei Dir am Ende sogar drei sind).

Ich habe keine Idee, wie schwer es tatsächlich ist, (nur als Beispiel) den Thread 278794 zu finden ... ich habe unter 60 Sekunden bei einer Google-Suche mit den Stichworten "site:ip-phone-forum.de avm vpn accesslist format" benötigt, um im vierten Treffer bereits auf ein sehr ähnliches Problem zu stoßen und dieser Thread ist auch deutlich als "gelöst" markiert. Daß ich mich dort beteiligt hatte, ist nur eine Randnotiz ... wenn ich bei der Suche noch meinen eigenen Nickname einbeziehe, dann finde ich entsprechende Beiträge sogar noch schneller (was ich aber anderen nur bedingt anraten kann, das mache ich nur dann, wenn ich selbst nach etwas suche, was ich mal geschrieben hatte und da weiß ich dann in der Regel, worum es ging).

Jedenfalls wird da (m.E. recht ausführlich) auch erklärt, was so ein "accesslist"-Eintrag bewirkt ... es ist kein "Geheimwissen" und - so sehe ich das jedenfalls - weit von verstaubten und verlegten Büchern entfernt.

Die Weigerung, ständig solche Sachen erneut zu erklären und aufzuschreiben, basiert ja auch nicht nur auf Faulheit ... ganz im Gegenteil, meist sind solche Texte wie dieser hier noch viel länger und damit auch arbeitsintensiver.

Aber wenn sich wieder einmal etwas bei AVM ändern sollte, dann bringt jede zusätzliche (damit dann falsche) Erklärung für andere nur wieder mehr Durcheinander oder für den Autoren mehr Aufwand, wenn er nicht nur 1 (oder 10) nunmehr falsche Stellen korrigieren muß, sondern 100 (um mal gleich richtig in die Vollen zu gehen und wenn das jemandem zu übertrieben erscheint, kann er ja ein anderes Zahlensystem verwenden bei der Interpretation).

Meine "Arbeit mit der Suche" war jedenfalls alles andere als langwierig ... insofern hättest Du vielleicht auch auf meine Aufforderung in #8 reagieren und uns an Deinem Mißerfolg bei der Suche teilhaben lassen können. Selbst wenn es hier im Ergebnis vielleicht auf dasselbe hinausgelaufen wäre, hätte es Dir ja vielleicht bei der nächsten (einsamen) Suche helfen können.
 
Danke für die Links aber soweit war ich schon.

Bei den Beschreibungen geht es meistens um Fritzbox zu Fritzbox Verbindungen.

Bei mir ist es eben wie ober geschrieben vpnc.

Der vpnc Client verbindet sich nicht mehr wenn in der Config:

conn_type = conntype_lan;

steht. Das geht nur mit.

conn_type = conntype_user;

Die accesslisten wirken dann scheinbar anders in der Box und es wird überhaupt kein Netz durch den Tunnel geroutet sondern nur eine IP, egal was eingestellt wird. Ich kann mich aber auch täuschen.
 
Zuletzt bearbeitet:
Ich hatte mir schon fast so etwas gedacht ... u.a. deshalb habe ich in #10 im letzten Satz etwas dazu geschrieben.

Wenn der vpnc so offensichtlich das ungeeignete Mittel für diese Art von VPN-Verbindung ist (entschuldige, wenn ich Dich mit meiner Aussage in #2 verwirrt habe, daß ein solches Szenario sicher realisierbar wäre - da war meinerseits noch die Vermutung im Spiel, daß Du "vpnc" mehr oder weniger als Synonym für eine Funktion und nicht als konkreten Paketnamen verwendest, was will man hier auch mit einem Client für eine solche Verbindung, wenn es dahinter ein weiteres LAN geben soll), warum verwendest Du ihn dann überhaupt?

Wenn ein Linux-System seinerseits als Router in einem IPSec-Szenario verwendet werden soll (und das wäre das Linux-System bei Dir ja), dann nimmt man eben StrongSwan oder racoon oder was auch immer - in einem LAN2User-Szenario geht das Routen in ein weiteres Netz natürlich nicht (jedenfalls nicht ohne weiteres) und wenn Du irgendwann mal reagiert hättest und man die FRITZ!Box-VPN-Datei einmal gesehen hätte (das ist ja immer noch nicht der Fall), wäre diese Diskussion schon lange erledigt.

Sollte ich Dich also in #2 "verwirrt" haben, tut es mir in Ansätzen leid ... hättest Du auf die wiederholten Hinweise bereits vorher reagiert und man hätte früher erkennen müssen (die Bemerkung in #10 war ja nur ein - eher versteckter - Hinweis, weil sich in mir so langsam die Überzeugung breit machte, daß Du etwas fundamental falsch machen könntest - das war aber eine reine Vermutung), daß es so nicht geht, hättest Du (und auch ich) viel Zeit gespart.

Damit korrigiere ich die Aussage in #2 dahingehend, daß es mit "vpnc" (ich vermute, wir reden dann hier vom Paket "vpnc" von dieser Site: https://www.unix-ag.uni-kl.de/~massar/vpnc/) in Kombination mit einer FRITZ!Box (vermutlich) wohl nichts werden wird.

Ob das jetzt tatsächlich daran liegt, daß die FRITZ!Box ihrerseits keine Pakete in einen Tunnel für eine "conntype_user"-Verbindung schicken will, weiß ich nicht genau ... mir fiele allerdings per se kein Grund ein, warum das (bei korrekter "accesslist") so sein sollte.

Insofern würde ich (wenn ich die Wahl habe) tatsächlich den letzten Satz aus #13 in Betracht ziehen - vielleicht liegt es ja doch nur an einer falschen Konfiguration und da wir immer noch nicht wissen, wie diese (A) aussieht und (B) aussehen sollte, ist das Thema hier dann m.E. auch durch (zumindest für mich).
 
Ok, dann bin ich jedenfalls "beruhigter"

Auch sorry ich hab auch etwas über reagiert. Ich hab auch irgendwie angenommen das ich mit der Nennung von vpnc (ja genau das Packet ist gemeint z.b. auch in freetz) das Szenario klar sein sollte (wie user-vpn).

Vpnc hat in meinem Fall auf Anhieb funktioniert und hätte ich die configs gepostet hätte, hätte es wohl noch mehr verwirrt da der Aufbau doch etwas komplexer ist. Ich konnte das Problem aber auf die Verwendung von vpnc und Fritzbox eingrenzen, deshalb habe ich so gezielt gefragt ob das überhaupt klappt.
Dann ist das schon ok das es so nun nicht funktioniert. Ich kenne jetzt nicht im Detail wie das VPN in der Fritzbox gehändelt wird dann wäre es früher schon klar gewesen. Ich habe allerdings gute Kenntnisse über Routing und generell IP deshalb war ich da schon irgendwie am verzweifeln weshalb sich die Fritzbox so weigert die Daten nicht in den Tunnel zu schicken, ich hätte nicht gedacht das es scheinbar sogar absichtlich nun so ist.

Der Vorteil von vpnc ist das der vpnc-Client irgendwo stecken kann hinter einer anderen unbekanntem Box. z.B und der Tunnel doch einwandfrei aufgebaut wird ohne das die Rückverbindung per dyndns oder bekannte IP vorhanden sein muss.

Die Lösung ist nun da bei mir an dem vpnc-Client nur eine andere IP-Hardware steckt kann ich per iptables den traffic weiternatten, das klappt bestens.


Also nochmals sorry und danke :) das es nun doch aus gutem Grund nicht klappt.
 
Da hast Du mich allerdings falsch verstanden ... ich glaube noch nicht, daß die FRITZ!Box die Daten tatsächlich nicht in den Tunnel schickt, wenn die "accesslist" richtig ist. Zwar ist eine LAN2User-Verbindung tatsächlich etwas spezieller (u.a. weil die Box für den entfernten Peer Proxy-ARP macht, damit die lokalen Clients ganz normal über die IP-Adresse mit diesem kommunizieren können), aber es gibt erst einmal keine logische Erklärung, warum bei passendem Selektor Pakete anders gehandhabt werden sollten - ich würde das tatsächlich nicht voraussetzen.

Wenn Du Dich doch irgendwann mal dazu durchringen kannst, eine belastbare Beschreibung samt verwendeter Konfigurationsdatei mitzuteilen, könnte man event. vorhandene Fehler ja sehen. Solange die Box das Default-Gateway ist und die betreffenden Pakete "sieht", sollte sie die auch über den Tunnel schicken können - es gibt nichts, was da direkt dagegen spricht und vor allem braucht man auf der FRITZ!Box-Seite eben gar keine Routen. Das läuft über die Ausleitung des Verkehrs zum Peer und dessen IPSec-Kapselung, wo dann die äußere Verpackung im nächsten Schritt den Transport zum Peer sicherstellt.

Also bitte auch nicht so mißverstehen, daß ich jetzt zustimmen würde, daß es absolut nicht funktionieren kann ... der letzte Absatz in #14 war durchaus ernst gemeint.

Wenn Du das tatsächlich getestet hast und einen Packetdump haben solltest, wo trotz korrektem Selektor ein Paket auf der "1. Internetverbindung" im Klartext auftaucht, dann ist das etwas anderes ... da die wenigsten diese Konstellation testen werden, gibt es da sicherlich nicht allzu viele gesicherte Erkenntnisse.

Auf der anderen Seite würdest/müßtest Du ja eigentlich nicht hier fragen, wenn Du Dir tatsächlich sicher wärst, daß die "accesslist" stimmt bzw. dann sollte eigentlich erst recht nichts dagegen sprechen, wenn Du dazu nähere Angaben machst.
 
Nochmal eine Rückfrage, ob ihr nicht aneinander vorbei redet...

Proxy-ARP braucht man nur, wenn die beiden gekoppelten Netze den gleichen IP-Adressbereich verwenden.

Wenn das nicht der Fall ist (was ich annehme), braucht man selbstverständlich auf der Fritzbox eine Route für das entfernte Netz, damit der Traffic durch den Tunnel fließt.

Ich verstehe nur nicht, warum der vpnc-Client auch noch NAT machen soll, der kann das doch ganz normal routen?
 
Nochmal ganz deutlich: Nein, um die Daten für ein entferntes Netz bei einer FRITZ!Box über einen VPN-Tunnel zu transportieren, braucht es KEINE Route - diese ließe sich bei einer FRITZ!Box mit einem OS neueren Datums ohnehin nicht einrichten. Bei aktivierter VPN-Verbindung für den Client vermutlich nicht einmal bei Existenz einer "conntype_user"-Verbindung (aber das müßte ich auch erst testen, um da sicher zu sein) und bei einer "conntype_lan"-Verbindung schon prinzipiell nicht, weil das GUI nur Routen akzeptiert, deren "next hop" lokal ist.

Die einzige Stelle, wo es eventuell eine zusätzliche Route brauchen könnte, ist ein Client im LAN der FRITZ!Box ... aber auch nur dann, wenn dieser seinerseits die FRITZ!Box nicht ohnehin als Standard-Gateway verwendet. Wenn ein Paket am Gateway landet, sieht man ihm ohnehin nicht mehr an, ob es aufgrund einer speziellen Route dort ankommt oder weil es an das "default gateway" gesendet wurde.

Hier will jemand unbedingt "vpnc" verwenden ... die Gründe (nicht 100%ig klar) stehen in #15 im vierten Absatz. Da ich den Satz nicht richtig verstehe, kann ich mir auch kein Urteil anmaßen, ob da jemand die Geschichte mit "ohne das die Rückverbindung per dyndns oder bekannte IP vorhanden sein muss." am Ende nur falsch verstanden hat oder nicht.

Ich sehe tatsächlich weder in einer dynamischen IPv4-Adresse ein Hindernis noch wäre ein DynDNS-Account bei passender Konfiguration erforderlich ... zumindest auf der Seite, wo sich der "vpnc" befindet. Die FRITZ!Box muß ja auch bei dessen Verwendung irgendwie in den Weiten des Internets gefunden werden, das reicht i.d.R. auch vollkommen aus, um eine IPSec-Verbindung mit "NAT-T" aufzubauen, die dann auch wieder dazwischen liegende zusätzliche NAT-Router recht unbeschadet überbrücken kann.

Die Auswahl, welche Daten durch einen IPSec-Tunnel geschickt werden, trifft die FRITZ!Box immer auf der Basis der "accesslist" für die konfigurierten Tunnel - da hat ein Eintrag in der Routing-Tabelle überhaupt nichts mit zu tun. Er könnte nur störend wirken, wenn er dafür sorgt, daß diese Daten eben nicht an "dev dsl" gesendet werden, wo die IPSec-Transformationen dann auch stattfinden.

Da es sich hier beim TE gar nicht um die Kopplung zweier Netze handelt (sein VPN-Client erhält genau eine einzige IP-Adresse auf dem LAN-Segment der FRITZ!Box zugewiesen), macht die FRITZ!Box Proxy-ARP, damit alle anderen Clients im LAN (die normalerweise eben einen Host, dessen Adresse nach ihrer eigenen Konfiguration über Broadcasts (eben solche ARP-Requests) zu ermitteln sein sollte, direkt adressieren wollen auf L2 und den Traffic für ihn normalerweise nicht an das Gateway senden würden) die Daten für diesen "remote client" dann doch noch an die FRITZ!Box senden, die ihrerseits beim Aktivieren der VPN-Verbindung (nicht erst bei deren Aufbau, zumindest war es bisher so) einen Eintrag für die IP-Adresse des Peers in ihrer Routine-Table vornimmt und zwar so, daß dieser jetzt wieder auf "dev dsl" zeigt und die Daten für den Tunnel damit auf dem richtigen (WAN-)Interface ankommen, wo sie dann wieder gekapselt und mit der "public IP" des Peers auf die Reise geschickt werden.
 
Die Auswahl, welche Daten durch einen IPSec-Tunnel geschickt werden, trifft die FRITZ!Box immer auf der Basis der "accesslist" für die konfigurierten Tunnel - da hat ein Eintrag in der Routing-Tabelle überhaupt nichts mit zu tun.

Mangels Fritzbox kann ich das nicht überprüfen, aber ich würde fast wetten, dass ein Eintrag in diese accesslist intern zu einem Eintrag in die Kernel-IP-Routing-Tabelle führt.

Da es sich hier beim TE gar nicht um die Kopplung zweier Netze handelt (sein VPN-Client erhält genau eine einzige IP-Adresse auf dem LAN-Segment der FRITZ!Box zugewiesen), macht die FRITZ!Box Proxy-ARP,

Ah okay, dann ist es klar. Danke.
 
Die Wette verlierst Du ... eine "IPSec transform policy" in einem anderen Linux-System ist auch kein Eintrag in einer Routing-Table. Die Daten landen auf dem Interface und werden - sofern selektiert über die Filter für diese Policy - entsprechenden Transformationen unterzogen ((Ent-)Kapselung + (De-)Kompression, je nachdem, was man haben will).

Aus einer "accesslist" wird eben (leider) kein Eintrag in einer Routing-Table generiert, das führt bei mir (ich habe eine Route 192.168.0.0/16 über ein lokales Gateway in der FRITZ!Box, damit ich nicht bei jedem neuen - auch nur testweise eingeführten - lokalen Netzsegment eine neue Route auf der FRITZ!Box eintragen muß) sogar dazu, daß ich beim Aufbau einer VPN-Verbindung, die ein Netz aus diesem Bereich verwendet, selbst dafür sorgen muß, daß eine speziellere Route (eben über "dev dsl") für das entfernte Netz (auf der FRITZ!Box) in die Table eingetragen wird, ansonsten landet der Traffic von der FRITZ!Box in Richtung des entfernten LAN (auch bei aufgebauter VPN-Verbindung) einfach am lokalen Gateway für 192.168.0.0/16.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.