Drittes Netzwerk hinter VPN-Verbindung erreichen...

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
I

iLion

Neuer User
Mitglied seit
30 Jan 2006
Beiträge
59
Punkte für Reaktionen
2
Punkte
8
Hallo,

ich habe Probleme ein, bzw. mehrere Netzwerke durch einen VPN-Tunnel zu erreichen. Konkret sieht das so aus, das Netz A 192.168.30.0/24 mit Netz B 192.168.254.0/24 durch einen Tunnel durch zwei 7490 verbunden ist. Der Tunnel zwischen beiden Netzen steht. An der Box in Netz B ist ein weiterer Router angebunden, der ein Netz C 172.16.0.0/16 versorgt. Dieses Netz C möchte ich erreichen. Der Router von C taucht im Netz B unter der IP 192.168.254.10 auf. Bei dem Versuch eine statische Route auf der Box im Netz A nach dem Prinzip 172.16.0.0/255.255.0.0 und Gateway 192.168.254.10 zu setzen, verweigert die Box das Speichern. Genau mein Szenario hatte ich vorgestern noch direkt bei AVM gefunden, jetzt nur noch im Google Cache. Die dort beschriebenen Änderungen der VPN Konfiguration im Bereich "permit ip" sind natürlich umgesetzt. Der Support konnte bisher nicht helfen und verweist auf die neue Labor-Firmware zum testen. Eine Beta-Software in einem produktiven Netz einzusetzen halte ich jetzt jedoch nicht für glücklich.

Kann hier vielleicht jemand helfen?
 
Statische Routen übers Webinterface sind irgendwie laut Box immer falsch, du kannst aber auch in der anderen VPN-Konfig Routen angeben
 
Wie meinst Du das in der VPN-Konfiguration? Kannst Du das bitte genauer beschreiben? Ich habe den Eindruck, dass statische Routen immer nur auf IP-Adressen im eigenen Bereich zugelassen werden. Im Netz B funktioniert z.B. der Eintrag 172.16.0.0/255.255.0.0 auf 192.168.254.10, wobei .10 ja eben der Router des anderen Netzes ist.
 
In der VPN Konfiguration für die FB in Netz A ist auch eine "Routingtabelle", da kann das Webinterface dir nicht verbieten etwas einzutragen
 
Da fehlen in der Problembeschreibung einfach drei VPN-Konfigurationen für mind. zwei VPN-Verbindungen (d.h. die "mittlere Box" hat ja zwei unterschiedliche Konfigurationen in Benutzung). Dann braucht auch niemand etwas zu beschreiben oder einer von uns zu raten. Funktionieren würde das jedenfalls, wenn ich die Beschreibung nicht total falsch verstanden habe und es am Ende drei Teilnehmer gibt (Alice, Bob und Carol), wobei die Verbindung zwischen Alice und Carol über Bob als "Vermittler" laufen muß. Wenn das so stimmt, veröffentliche die drei Konfigurationsdateien (bitte mit Zuordnung, wer wer ist) und Dir wird bestimmt geholfen.
 
@PeterPawn

Nein, die Box in Netz B (die "mittlere") hat nur eine Konfiguration, nämlich die eine VPN Konfiguration zwischen Netz A und B aufzubauen. Die Konfigurationen der Boxen sind auch Standard, d.h. mit der Windows Software von AVM erstellt. Ich habe lediglich in der Konfiguration von A noch ein "permit ip any 172.16.0.0 255.255.0.0" ergänzt, damit dieser Verkehr durch die VPN Leitung darf.

Die Box B ist an sich ein Client an C, wobei C ein Lancom Router ist. An diesen Stellen gibt es auch gar kein Problem. Das Problem sitzt einzig darin, dass die Box A das Setzen der statischen Route auf 192.168.254.10 verweigert. Warum sie das tut, konnte mir selbst AVM bisher nicht beantworten.
 
@iLion:
Ich verstehe wohl schon die Problembeschreibung nicht und bin vermutlich hier raus ...

Eine statische Route irgendwohin gibt es/braucht es bei einer FRITZ!Box nicht, solange das Ziel über "dev dsl" (das ist die Default-Route) zu erreichen ist ... und AVM weiß sehr wohl, warum nur noch statische Routen eingerichtet werden dürfen (da läßt sich die Firmware auch nicht übertölpeln, nur mit einem direkten Shell-Befehl), die über "dev lan" gehen.

Wenn das am Ende eben nicht nur drei Teilnehmer sind, sondern vier (Alice, Bob, Carol und Dave) und nur zwischen Alice und Bob eine VPN-Verbindung besteht und eine weitere zwischen Carol und Dave, wobei Bob und Carol sich in ein und demselben LAN befinden (dann müssen sie ja auch ein gemeinsames Netzsegment haben, das soll wohl irgendwas mit 192.168.254.0/24 sein, die Adresse von Bob in seinem LAN müssen wir ja auswürfeln, die von Carol soll wohl die .10 sein), dann interessiert die FRITZ!Box bei Alice keine Route, weil das einfach über den Selektor für die IPSec-Transformation läuft. Die Box bei Bob, die braucht dann die Info, auf welchem Weg das andere Netz zu erreichen ist, denn dort kommt der Verkehr "wieder aus dem IPSec heraus".

Aber ich diskutiere ohne Plan und/oder Konfigurationsdateien nicht mehr ... von Bob fehlt z.B. die komplette Routing-Table. Wenn Du mit
iLion schrieb:
Im Netz B funktioniert z.B. der Eintrag 172.16.0.0/255.255.0.0 auf 192.168.254.10, wobei .10 ja eben der Router des anderen Netzes ist.
Zum Vergrößern anklicken....
irgendeinen beliebigen Host in Netz B meinen solltest (der stünde ja dann neben Bob und Carol), dann wärst Du ja sicherlich selbst auf die Idee gekommen, daß natürlich Bob auch eine solche Route braucht (und da läßt sie sich sogar per GUI setzen).

Wenn da dank Selektor der Traffic von Alice zu Bob geht, klemmt es offenbar irgendwo zwischen Bob und Carol oder sogar noch später zwischen Carol und Dave. Auch der Rückweg wäre ja eine mögliche Fehlerursache, das Setzen einer statischen Route bei Alice funktioniert jedenfalls absichtlich (und richtigerweise) nicht. Da hilft dann ein Packetdump unheimlich weiter, wenn man ansonsten keinen Fehler finden kann.
 
Zuletzt bearbeitet:
@KunterBunter: Danke, aber siehst Du in den beiden Artikel irgendeinen substantiellen Unterschied? Ich nicht. Es sind lediglich die IP-Bereich leicht geändert, der Text stimmt zu 95% überein. Zwei Telefonate und eine eMail mit AVM haben mich bei dem Problem leider auch nicht weiter gebracht. Die haben nämlich in ihre eigene Wissensdatenbank geschaut und wirkten ziemlich überfordert.
 
Zuletzt bearbeitet:
PeterPawn schrieb:
@iLion:
Ich verstehe wohl schon die Problembeschreibung nicht und bin vermutlich hier raus ...
...
Aber ich diskutiere ohne Plan und/oder Konfigurationsdateien nicht mehr ... von Bob fehlt z.B. die komplette Routing-Table. Wenn Du mit

...(und da läßt sie sich sogar per GUI setzen).
Zum Vergrößern anklicken....

Hallo PeterPawn,

da ich schon einige Beiträge von Dir gelesen habe, weiss ich um Dein Wissen und denke, Du siehst das in diesem Fall viel zu kompliziert. Ich fange mal hinten an. B hat so eine Route und ja, sie lässt sich per GUI setzen. Die sieht dann nämlich so aus:
IPv4-Netzwerk: 172.16.0.0
Subnetzmaske: 255.255.0.0
Gateway: 192.168.254.10

Die lässt sich halt auch speichern, da 192.168.254.0 sozusagen das Heimnetz der FRITZ!Box in Netz B ist.

Die Route in Netz A soll so aussehen (bzw. auch nach der AVM Anleitung):

IPv4-Netzwerk: 172.16.0.0
Subnetzmaske: 255.255.0.0
Gateway: 192.168.254.10

Dann kriege ich aber eine rot umrandete Box mit der Meldung:

"Es ist ein Fehler aufgetreten. Fehlerbeschreibung: Die Route ist nicht zulässig. Bitte geben Sie Ihre Daten noch einmal ein. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.".

Ich vermute, die Box stört sich am Gateway, was vermeintlich nicht in ihrem Netz liegt und nimmt von der VPN Verbindung keine Notiz.

Anbei die VPN-Konfiguration von Netzwerk A:

Code: 
/*
 */

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "Verbindung A zu B";
                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 = 0.0.0.0;
                remotehostname = "ip.router.b";
                localid {
                        fqdn = "name";
                }
                remoteid {
                        fqdn = "name";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "schluessel";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.30.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.254.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.254.0 255.255.255.0",
                			 "permit ip any 172.16.0.0 255.255.0.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";
}

// EOF
und Netz B:

Code: 
/*
 */

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "Verbindung B zu A";
                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 = 0.0.0.0;
                remotehostname = "ip.router.a";
                localid {
                        fqdn = "name";
                }
                remoteid {
                        fqdn = "name";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "schluessel";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.254.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.30.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.30.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";
}


// EOF
 
@iLion:
Wie ich schon schrieb (nun sehe ich es in der Konfiguration von Alice ja auch) ... die Pakete von einem beliebigen Host im LAN von Alice sollten bei dieser Konfiguration vollkommen ohne weitere Routen über den IPSec-Tunnel bei Bob ankommen.

Wenn es dort irgendwo klemmt, dann zwischen Bob und Carol oder dahinter.

Es braucht keine Route zur 192.168.254.10 bei Alice ... der Verkehr für 172.16.0.0/16 wird bei Alice eingepackt, wenn er über die Standardroute auf "dev dsl" aufschlägt, über IPSec zu Bob gesendet und der entscheidet nach dem Auspacken dann, wie es weiter geht.

Wenn er eine Route zu Dave über Carol konfiguriert bekommen hat, schickt er das Paket an Carol. Was die damit dann macht, interessiert ihn nicht weiter. Für den Rückweg von Paketen muß dann eben Dave wieder wissen, daß er die 192.168.30.0/24 über Carol erreicht und auch Carol muß wissen, daß dieses Netz über Bob zu erreichen ist. Der packt das dann anhand der "accesslist" wieder ein und schickt es an Alice, wo es ausgepackt und im LAN verteilt wird.

EDIT: BTW ... die AVM-Anleitung spricht garantiert nicht von einer "Route" auf Alice ... es läßt sich seit 06.20 schlicht nicht mehr konfigurieren und ist eben auch vollkommen unnötig, weil die "Selektion" dieses Traffics für die IPSec-Kapselung ausreichend ist.
 
Zuletzt bearbeitet:
@PeterPawn: Danke für die Antwort. Was die AVM Anleitung angeht, Du hast recht. Ich habe tatsächlich beim lesen immer A und B verwechselt. Jetzt sehe ich das auch. Ich werde dann morgen noch mal die Konfiguration von C prüfen und Rückmeldung geben.
 
So, hier die versprochene Rückmeldung. Tatsächlich war die Konfiguration zwischen den FRITZ!Boxen genau so in Ordnung, wie es die oben konfiguriert ist. Ich musste noch die statische Route im Netz C für den Rückweg setzen, danach war alles in Ordnung.

Jetzt habe ich das ganze zwei Mal aufgebaut. Netz A<->B<->C und Netz D<->E<->C. Das klappt und ich kann aus C beide (A und D) erreichen. Leider kann ich noch nicht aus A D erreichen. Da für das Netz C, wie oben einmal beschrieben, ein Lancom Router zuständig ist, kann hier noch ein Fehler sein. Theoretisch sind hier die Routen zwischen A und D gesetzt (und auch die weiteren Netze per "permit ip" in den FRITZ!Boxen für das jeweils andere Netz ergänzt. Ich hatte diese Woche aber noch nicht die Zeit das noch mal genauer zu prüfen.

Falls jemand spontan eine Idee hat und mir wieder sagt, das liegt an Deiner Konfiguration in den FRITZ!Boxen, bitte, ich bin ganz Ohr. :-D Ansonsten schon mal Danke für die vorherige Hilfe.
 
Noch eine kleine Anmerkung meinerseits, weil das oben nicht so ganz eindeutig ist: Die korrekte Selektion für das komplette (ehemals Class-B-)Subnetz hinter 172.16.0.0/12 wäre natürlich "172.16.0.0 255.240.0.0". Die o.a. Maske ist auch gültig, umfaßt dann aber wirklich nur das Netz (oder die Netze, denn natürlich kann man da immer noch Subnetting betreiben) im Bereich von 172.16.0.0 bis 172.16.255.255 ... die anderen "privaten Netze" (172.17.0.0-172.31.255.255) wären da nicht dabei. Wenn das absichtlich passiert, ist es richtig - ansonsten ein schnell übersehener Stolperstein.

EDIT: Unter Umständen ist das ja auch der Grund, warum da Netz D nicht zu erreichen ist.
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Statistik des Forums

Themen
248,873
Beiträge
2,303,506
Mitglieder
378,533
Neuestes Mitglied
PatrickSt91

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
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.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten