[Problem] FritzBox 7490 VPN und RDP

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

Harvey0815

Neuer User
Mitglied seit
2 Apr 2010
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Einen grandiosen guten Abend zusammen!

Stehe vor einem Problem!
Vllt. könnt Ihr mir helfen ich wäre euch sehr dankbar.
Ich habe schon etliche Threats gelesen auch in verschiedenen Foren und das Problem ist wohl nicht ganz unbekannt allerdings habe ich alle Lösungen schon ausprobiert und nie hat es zum Erfolg geführt....

Zum Problem:
Es werden in einem Netzwerk 192.168.178.0 drei Fritzboxen betrieben. Alle samt 7490 OS 6.51
192.168.178.1 , 192.168.178.2 und 192.168.178.13
DHCP ist bei allen deaktiviert. Das übernimmt ein Windows Server 2012.
Auf allen drein ist DynDNS aktiviert und es sind VPN Nutzer eingerichtet.
So weit so gut.

Nun will ich mich in eine der drei FritzBoxen per VPN einwählen und das funtkioniert auch auf den ersten Blick.
Will ich dann aber eine RDP Session zu einem PC hinter der FB starten kann diese nicht aufgebaut weden.
Komischweise nur zu einigen PCs, bei anderen klappt es.
Dieses Verhalten beobachte ich bei zwei FB bei der dritten nicht!

Ich kann das Problem auch auf einem anderen Gerät reproduzieren.
Also baue ich die selbe Verbindung mit dem selben Nutzer auf einem anderen sich zu verbindenden Gerät (z.B. Android Handy mit LTE Internet) auf und verbinde mich mit einer der beiden fehlerhaften FBs kann ich danach kein RDP aufbauen.
Mit der dritten und dem selben Handy geht es schon.

Baue ich ein VPN zu der dritten Fritte auf, kann ich sofort auf jeden PC per RDP zugreifen.

Ich schlussfolgere daraus, dass es nicht am PC liegt, denn mit der dritten FB klappt es ja zu jeder Zeit.
Ausserdem schlussfolgere ich, dass es nicht an Firewalleinstellungen der PCs liegt und auch nicht an dem Router oder Internetzugang auf der anderen Seite, denn ich habe es mit zwei verschiedenen Geräten an zwei verschiedenen Internzugängen versucht und bekomme haargenau das selbe Ergebnis.

Es macht auch keinen Unterschied ob ich nun einen VPN Nutzer direkt in der FB anlege oder per "FritzFernzugang einrichten" oder per VPN Assistent ....

Was meint Ihr?
Ist euch so eine Problematik schon mal über den Weg gelaufen?

Fragt verzweifelt

Harvey
 
Vielleicht sehe ich das ja zu simpel ... aber ich würde hier als erstes darauf tippen, daß genau die FRITZ!Box keine Probleme bereitet, die beim zu steuernden PC als Standard-Gateway eingetragen ist - die sieht nämlich dann auch die Daten, die anderen beiden nur dann, wenn da zusätzliches Routing eingerichtet ist, von dem in #1 aber keine Rede ist.
 
Danke dir für die Antwort ;)
den Gedanken hatte ich auch schon mit den Gateways aber auch dort zeichnet sich kein Muster ab.

Wie meinst du sollte ich ein zusätzliches Routing einrichten?
Auf dem zu steuernden PC oder auf dem der sich verbindet?

Der PC der die VPN Verbindung aufbaut bekommt sobald der Tunntel aufgebaut wird einen neuen Routing Eintrag.
Diese sehen alle gleich aus, egal mit welcher Fritte ich mich verbinde.
 
Der per VPN verbundene PC erhält eine IP-Adresse aus dem Segment der FRITZ!Box, mit der er sich verbindet. Da das bei Dir nach #1 alles 192.168.178.0/24 ist, kriegt der wahrscheinlich .200 oder irgendwas in der Richtung?

Du wirst ja hoffentlich nicht auf allen drei FRITZ!Boxen dieselbe VPN-Konfiguration eingerichtet haben, denn das kann nicht funktionieren, weil eine FRITZ!Box für eine aktivierte VPN-Verbindung mit "conntype_user" (das schließe ich daraus, daß der per VPN verbundenen PC seine eigene Adresse kriegt - wenn ich das richtig verstanden habe, die VPN-Konfiguration ist ja nun mehr als "im Nebel") ihrerseits anstelle des VPN-Clients auf lokale ARP-Anfragen antwortet (proxy ARP) und daher jeder Client im LAN den entfernten VPN-Client hinter der MAC-Adresse kontaktieren will, die zu der Antwort gehört, die bei ihm das "ARP race" gewonnen hat.

Einfacher Test, ob die/eine FRITZ!Box auch wirklich als ARP-Proxy antwortet:

1. VPN-Verbindung für irgendeinen Client einrichten (muß aber eine mit "conntype_user", also für "Benutzer" sein)
2. ARP-Tabelle eines lokalen Clients anzeigen lassen
3. von diesem Client aus ein Ping zu den FRITZ!Boxen (es gibt ja offenbar mehrere) und zur IP für diesen neuen Client machen, die IP-Adresse kriegt man notfalls aus den Export- oder den Support-Daten heraus
4. jetzt sollte bei der erneuten Ausgabe der ARP-Tabelle (obwohl das Ping für den Client ja nicht erfolgreich war) für dessen IP-Adresse die MAC-Adresse einer FRITZ!Box hinterlegt sein - normal wäre es (bei einem nicht vorhandenen lokalen Client mit so einer IP-Adresse), wenn da keine MAC-Adresse steht

Wenn es wirklich mehrere FRITZ!Boxen gibt, die genau denselben ARP-Request beantworten wollen, ist es reine Glückssache, welche FRITZ!Box das Rennen gewinnt. Allerdings wird dann so ein Eintrag auch immer wieder verwendet, solange er nicht nach einer Zeit ohne Zugriffe auf diese IP-Adresse dann irgendwann mal abläuft, aus dem Cache entfernt wird und dann erneut mit einer ARP-Abfrage gesucht wird, wenn es notwendig ist.

Also bitte etwas ausführlicher/genauer, was Du da nun wirklich machst ... es klingt allerdings tatsächlich etwas seltsam (schon die Tatsache, daß Du zu allen drei Boxen dieselbe Verbindung aufbauen kannst, wenn ich das richtig verstehe).

Mein Hinweis auf das Routing bezog sich nur darauf, daß man das mit ordentlicher Planung so hinbekommen könnte (so in der Art, daß RDP zu Server 1 nur über FRITZ!Box 1 geht, zu Server 2 über FRITZ!Box 2, usw.) ... das sollte keinesfalls zum Ausdruck bringen, daß das eine erstrebenswerte oder sinnvolle Konfiguration wäre - insofern meinte ich gar nicht, daß Du so etwas einrichten solltest.
 
PeterPawn schrieb:
Der per VPN verbundene PC erhält eine IP-Adresse aus dem Segment der FRITZ!Box, mit der er sich verbindet. Da das bei Dir nach #1 alles 192.168.178.0/24 ist, kriegt der wahrscheinlich .200 oder irgendwas in der Richtung?
Zum Vergrößern anklicken....

So ähnlich, habe festgestellt, dass es egal ist mit welchem Gerät ich mich mit diesem VPN Nutzer verbinde er bekommt immer die selbe IP.
Bei dem einen Nutzer der einen Box ist es z.B. die .134 bei dem anderen die .129 Oder ich erstelle per FritzFernzugang Einrichten ein VPN-Nutzerprofil und kann die IP selbst bestimmen.

PeterPawn schrieb:
Du wirst ja hoffentlich nicht auf allen drei FRITZ!Boxen dieselbe VPN-Konfiguration eingerichtet haben, denn das kann nicht funktionieren, weil eine FRITZ!Box für eine aktivierte VPN-Verbindung mit "conntype_user" (das schließe ich daraus, daß der per VPN verbundenen PC seine eigene Adresse kriegt - wenn ich das richtig verstanden habe, die VPN-Konfiguration ist ja nun mehr als "im Nebel") ihrerseits anstelle des VPN-Clients auf lokale ARP-Anfragen antwortet (proxy ARP) und daher jeder Client im LAN den entfernten VPN-Client hinter der MAC-Adresse kontaktieren will, die zu der Antwort gehört, die bei ihm das "ARP race" gewonnen hat.
Zum Vergrößern anklicken....

Nein die Nutzer lauten alle anders und die Profile sind dann auch immer nur in eine FB importiert worden.

PeterPawn schrieb:
Einfacher Test, ob die/eine FRITZ!Box auch wirklich als ARP-Proxy antwortet:

1. VPN-Verbindung für irgendeinen Client einrichten (muß aber eine mit "conntype_user", also für "Benutzer" sein)
2. ARP-Tabelle eines lokalen Clients anzeigen lassen
3. von diesem Client aus ein Ping zu den FRITZ!Boxen (es gibt ja offenbar mehrere) und zur IP für diesen neuen Client machen, die IP-Adresse kriegt man notfalls aus den Export- oder den Support-Daten heraus
4. jetzt sollte bei der erneuten Ausgabe der ARP-Tabelle (obwohl das Ping für den Client ja nicht erfolgreich war) für dessen IP-Adresse die MAC-Adresse einer FRITZ!Box hinterlegt sein - normal wäre es (bei einem nicht vorhandenen lokalen Client mit so einer IP-Adresse), wenn da keine MAC-Adresse steht
Zum Vergrößern anklicken....

Von wo aus meinst du nun?
ARP Tabelle anzeigen von dem Client der die Verbindung aufbaut?
Da steht nicht viel und schon gar nichts von dem Netzwerk auf das sich verbunden werden soll.
Oder vllt. mache ich etwas falsch. Habe OS X wie zeige ich mir da die komplette ARP Tabelle an?

PeterPawn schrieb:
Wenn es wirklich mehrere FRITZ!Boxen gibt, die genau denselben ARP-Request beantworten wollen, ist es reine Glückssache, welche FRITZ!Box das Rennen gewinnt. Allerdings wird dann so ein Eintrag auch immer wieder verwendet, solange er nicht nach einer Zeit ohne Zugriffe auf diese IP-Adresse dann irgendwann mal abläuft, aus dem Cache entfernt wird und dann erneut mit einer ARP-Abfrage gesucht wird, wenn es notwendig ist.

Also bitte etwas ausführlicher/genauer, was Du da nun wirklich machst ... es klingt allerdings tatsächlich etwas seltsam (schon die Tatsache, daß Du zu allen drei Boxen dieselbe Verbindung aufbauen kannst, wenn ich das richtig verstehe).
Zum Vergrößern anklicken....


Nein nicht die selbe VPN-Verbindung. Ich versuche hinter den Fritten die selben Clients zu erreichen und das geht nur bei einer Fritte, bei den anderen beiden spiel ich Roulette... Die Nutzer sind jeweils immer einzeln in der Fritte angelegt oder aber jeweils genau füe eine Fritte importierte Nutzer.

PeterPawn schrieb:
Mein Hinweis auf das Routing bezog sich nur darauf, daß man das mit ordentlicher Planung so hinbekommen könnte (so in der Art, daß RDP zu Server 1 nur über FRITZ!Box 1 geht, zu Server 2 über FRITZ!Box 2, usw.) ... das sollte keinesfalls zum Ausdruck bringen, daß das eine erstrebenswerte oder sinnvolle Konfiguration wäre - insofern meinte ich gar nicht, daß Du so etwas einrichten solltest.
Zum Vergrößern anklicken....

OK ich wollte eigentlich auch nicht anfangen für jeden einzelnen PC der sich verbinden soll Routing Einträge zu setzen zumal sich ja nun alle in das selbe Netz verbinden sollen.
 
Harvey0815 schrieb:
habe festgestellt, dass es egal ist mit welchem Gerät ich mich mit diesem VPN Nutzer verbinde er bekommt immer die selbe IP.
Zum Vergrößern anklicken....
Und das kann eigentlich nicht sein ... bzw. es darf an dieser Stelle nicht sein. Wenn da wirklich jede FRITZ!Box eine VPN-Konfiguration mit derselben "remote_virtualip" hat, kommen die sich bei ARP ins Gehege.

Ich habe immer noch nicht begriffen, wie die VPN-Konfigurationen nun erzeugt wurden ... angesichts der als Beispiel genannten .129 oder .134 bei den VPN-Client (und abgeschalteten/nicht in den Standardeinstellungen geändertem DHCP-Server in den FRITZ!Boxen) ist das sehr undurchsichtig.

Also bitte konkret ... wie sehen die VPN-Verbindungen in den drei Boxen nun wirklich aus? Wo man das ermitteln kann, habe ich schon geschrieben.
 
Sorry hab mich falsch ausgedrückt:
Ich erstelle einen Nutzer auf einer der fehlerhaften FBs.
Diesen Nutzer richte ich auf einem OS X ein.
Diesen Nutzer richte ich auf einem Android Handy ein.
Ich verbinde mich mit dem OS X bekomme eine IP.
Ich baue die Verbindung wieder ab.
Ich verbinde mich mit dem Android Handy bekomme die selbe IP.
Ich achte schon darauf, dass es nicht zu Adresskonflikten kommt.
Das ist nicht das Problem.

Die VPN Nutzer werden in den FBs erstellt.
Dabei kann ich nur einen Nutzernamen anlegen und ein Passwort.
Mir wird dann ein PSK generiert. Das wars. Danach kann ich die Einstellungen einsehen und auf den sich zu vervbindenden Geräten einrichten.

Was brauchst du da noch für Infos?
 
Harvey0815 schrieb:
Was brauchst du da noch für Infos?
Zum Vergrößern anklicken....
Die vpn.cfg-Dateien aus allen beteiligten FRITZ!Boxen.

Im AVM-GUI werden eben für jeden Benutzer, der sich per VPN einwählen darf, passende Einträge in der vpn.cfg erzeugt, diese enthalten u.a. die bereits erwähnte "remote_virtualip". Da man im GUI diese Adressvergabe nur in sehr engen Grenzen (und auch nur indirekt) beeinflussen kann, muß man schon wissen, welche IP-Adressen denn nun in den jeweiligen Boxen dem jeweiligen Nutzer (wenn ich das richtig verstehe, sind ja wenigstens auch deren Accounts unterschiedlich) zugeordnet wurden.

Wenn ich von Adresskonflikten schreibe, dann meine ich nicht zwei Clients, die sich auf demselben Konto in einer FRITZ!Box gleichzeitig anmelden ... da gewinnt schlicht immer derjenige, der als letzter den Schlüsselaustausch abgeschlossen hat, was dann den anderen zu einen erneuten Schlüsselaustausch veranlaßt, dann ist der wieder der letzte und so geht das solange, bis der Strom alle ist oder das Internet wegen Ladenschluß zugemacht wird.
 
Wo bekomme ich die VPN.cfg her?

Es gibt keine IP Adresskonfilkte.
 
Im einfachsten Fall über System -> Sicherung in der Fritzbox. Die vpn.cfg ist Teil der dabei erzeugten export-Datei.
Die von der Fritzbox im VPN vergebenen IP-Adressen liegen normalerweise oberhalb von .200.
 
Zuletzt bearbeitet:
Nutzer mit IP .116 .117 und .119 sind per FritzFernzugang bzw. VPN Assistent angelegt.

Nutzer mit .134 wurde in der Fritzbox angelegt.

Code: 
**** CFGFILE:vpn.cfg
/*
 * /var/tmp.cfg
 * Sat Apr  2 22:27:46 2016
 */

meta { encoding = "utf-8"; }

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "[email protected]";
                boxuser_id = 0;
                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.119;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        user_fqdn = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.119;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.119 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "[email protected]";
                boxuser_id = 0;
                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.117;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        user_fqdn = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.117;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.117 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "user3";
                boxuser_id = 0;
                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.116;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "###";
                        passwd = "###";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.116;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.116 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "user4";
                boxuser_id = 14;
                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.134;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "###";
                        passwd = "###";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.134;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 0.0.0.0 0.0.0.0 192.168.178.134 255.255.255.255";
                app_id = 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
 
Zweite Fritte, bittesehr:
User mit IP .115 ist wieder über Import entstanden.
User mit IP .128 über die FB selbst.

Auf die dritte Fritte habe ich keinen Zugriff.
Ist das wichtig?
Dort geht ja alles.
Wäre aber schonmal interessant ob das dort anders aussieht ....... hm

Code: 
**** CFGFILE:vpn.cfg
/*
 * /var/tmp.cfg
 * Sat Apr  2 23:02:29 2016
 */

meta { encoding = "utf-8"; }

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "user1";
                boxuser_id = 0;
                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.115;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "###";
                        passwd = "###";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.115;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.115 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "user2";
                boxuser_id = 11;
                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.128;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "###";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "###";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "###";
                        passwd = "###";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.128;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 0.0.0.0 0.0.0.0 192.168.178.128 255.255.255.255";
                app_id = 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
 
Harvey0815 schrieb:
Ist das wichtig?
Dort geht ja alles.
Zum Vergrößern anklicken....
Nein, ist reine Neugierde ...

Hast Du meinen Erklärungsversuch bzgl. Proxy-ARP durch die FRITZ!Box-Firmware verstanden? Wenn ja, dürfte sich die "Ist das wichtig?"-Frage eigentlich nicht stellen.

Wobei schon die Frage interessant ist, wie man eine FRITZ!Box dazu bekommt, automatisch im GUI für eine VPN-Verbindung für einen Benutzer die .134 zu vergeben. Das müssen schon sehr komische Einstellungen im DHCP-Server der FRITZ!Box sein (Range bis 133) oder es wurden bei einer Range bis 128 irgendwann mal mehrere solcher Verbindungen eingerichtet oder oder oder ... es ist jedenfalls recht merkwürdig, weil es eben nicht so einfach ist, dort überlappungsfreie Einträge zu generieren, wenn man von dem Mechanismus mit der Benutzung der ersten Adresse nach der Range für die erste VPN-Verbindung (nochmal, das gilt alles nur für conntype_user, sonst braucht es keine solche Adresse) eigentlich nichts wußte.

Da hätte man dann sehr viel Glück gehabt oder der Mechanismus mit den "neighbors" (also der, welcher auch für die "Netzwerkverbindungen" verantwortlich ist) hätte da Kollisionen verhindert - das wäre aber m.E. auch ziemliches Glück, weil natürlich nur solche Clients der jeweiligen FRITZ!Box bekannt sind, die auf Layer3 mit ihr selbst Kontakt hatten oder die von irgendwelchen Protokollen "announced" wurden. Eventuell hat aber AVM tatsächlich mit der 06.51 nachgebessert?

Jedenfalls kann das tatsächlich funktionieren, wenn wirklich alle Adressen disjunkt sind. Sind das oben die vollständigen Dateien aus den ersten beiden Boxen, dann gibt es zwischen diesen auch keinen IP-Adressenkonflikt.

Da Du das ja nach #9 schon weißt, brauchst Du auch nicht unbedingt die originale Datei aus der dritten Box "vorzeigen", es reicht ja aus, wenn Du die dort verwendeten Adressen einfach in Textform aufzählst oder zumindest selbst überprüfst, daß da tatsächlich keine mehrfache Vergabe erfolgt.

Wenn Du dabei auch noch eine Erklärung findest, wie Du die erste Box zur Verwendung der .134 überredet hast, wäre das auch nicht schlecht.

Solltest Du allerdings die VPN-Verbindungen (über das GUI, die anderen interessieren in diesem Punkt nicht) erst eingerichtet haben, nachdem bereits Version 06.51 installiert war, wäre es denkbar, daß AVM da nicht nur eine passende Fehlermeldung in die neue Firmware eingebaut hat, wenn keine freie Adresse für einen VPN-Client gefunden werden kann (eine entsprechende, neu hinzugekommene Fehlermeldung hatten wir letztens in irgendeinem Thread), sondern daß da auch noch der Algorithmus für diese Suche erweitert wurde. Das wäre eine richtig gute Nachricht ... da die meisten VPN-User hier sicherlich noch aus der "pre-06.51"-Periode stammen werden, ist das m.W. noch nicht richtig aufgefallen. Dann müßten aber diese IP-Adressen der VPN-Clients auch in den Netzwerk-Verbindungen irgendwie als "über <andere FRITZ!Box>" angezeigt werden ... insgesamt ist das alles schon komisch.

Wenn jedenfalls zwei FRITZ!Boxen unabhängig voneinander dieselbe IP-Adresse für einen VPN-Benutzer zuweisen, weil sie von der jeweils anderen nichts wissen (wissen sie es doch, stellt sich eben die Frage, wieso das so ist), ist das auch dann ein Adresskonflikt, wenn dieser VPN-Client (also der "Benutzer") nicht gleichzeitig mit beiden Boxen verbunden wird (was mit zwei verschiedenen Geräten ja auch möglich wäre). In diesem Kontext noch der Hinweis, daß Du nicht gesondert ansagen mußt, welcher Eintrag von der FRITZ!Box generiert wurde und welcher nicht ... man sieht es einfach daran, daß die von der Box erstellten im Eintrag "boxuser_id" einen Wert != 0 haben. Daran sieht man auch, daß es zu irgendeinem Zeitpunkt mindestens fünf Benutzer auf der ersten Box gegeben haben muß, denn das FRITZ!OS fängt beim Nummerieren der Benutzer mit 10 an.

Aber zurück zur Benutzung von RDP ... wenn wirklich sichergestellt ist, daß es tatsächlich keine Konflikte bei den IP-Adressen gibt (es gibt keine IP-Adresse, die in allen drei VPN-Konfigurationen mehr als einmal auftaucht - dabei ist es egal, ob diese Clients gerade verbunden sind oder nicht, die Adressen sind immer "vorhanden", das ist ja der Sinn von "proxy ARP"), dann kann man systematisch testen, woran es sonst noch liegen könnte.

Dazu nimmt sowohl der Laie als auch der Fachmann erst einmal das gute alte "ping" und stellt damit systematisch fest, welche Geräte jeweils erreichbar sind und welche nicht. Das logischerweise auch jeweils in beide Richtungen, weil selbst eine Antwort in Form eines "ICMP echo reply" noch nicht automatisch heißen muß, daß ein "ICMP echo request" in derselben Richtung auch funktioniert. Diese Tests müssen natürlich mit einem Client im LAN erfolgen (das kann auch eine der anderen FRITZ!Boxen sein), denn die Verbindung zur jeweiligen FRITZ!Box, in die der VPN-Client gerade "eingewählt" ist, ist etwas besonderes in diesem Falle (kein Transit).

Erst wenn die prinzipielle Erreichbarkeit (über Kreuz) aller Clients sichergestellt ist, erst dann macht es Sinn, beim RDP nach irgendwelchen Firewalls zu suchen oder irgendwelche AV-Suiten auf einem Windows-PC zu verdächtigen.
 
Danke für deine sehr ausführliche antwort.

DHCP Server ist immer noch ein Windows Server 2012 Range 200 aufwärts...
Das ist ja das komische, die Fritten scheinen willkürlch IP Adressen zu vergeben bzw. bei Erstellung des Profils sich eine zu nehmen ... aber nicht aus dem DHCP Bereich des Windows Servers.... ergal ich weise sie einfach manuell zu indem ich FritzFernzugang einrichten, den VPN Assisten oder eben die vpn.cfg bearbeite.....

ICMP, RDP, telnet, tracert führten alle zum selben Ergebnis nicht erreichbar.

Habe aber jetzt eine Lösung gefunden bzw. eine Policy aufgestellt, damit klappt es sowohl mit Android, Mac und Windows 7 Clients sehr stabil und alle PCs im Zielnetzwerk sind erreichbar:
Eine FB, eine IP, eine Internetleitung, ein eindeutiges Profil.

Kann auch gut sein, dass in der dritten Fritte IP Adressen vergeben sind, bzw. autoamtisch gegriffen wurden, die noch in der Config stehen (wie hier schon angesprochen wurde) und meine Config bei den anderen beiden Fritten gestört hat. Dem entgegen gewirkt habe ich in dem ich alle Nutzer gelöscht habe und neue nutzer mit neuen IPs vergeben habe.

Habe festgestellt, dass sobald man aus einem Netzwerk z.B. bei mir zu Hause (mit dem gleichen Internet also) sich mit zwei verschiedenen Geräten z.B. Win 7 und Mac zu einer FB verbindet (wobei natürlich die Profile eindeutige Nutzer und IP Adressen haben, die auch keinen Konflikt haben) gibt es massive Probleme.

Hoffe ich kann damit helfen, wenn es nochmal wo Probleme gibt, einfach Fragen vllt. kann ich aushelfen.

Nächster Test ist Windows 10 mit ShrewSoft, das wird noch mal nen Akt.
Aber ich denke die Grundlage ist nun erstmal geschaffen und die Fritten stabil.

Danke euch!

Harvey
 
Frage:
Hast Du die IPs der FB-VPN-Client-IPs (vpn.cfg: remote_virtualip) im Win2kxx-DHCP-Server excluded ?
Code: 
[FONT=courier new]FB1_User1: name="[EMAIL="[email protected]"][email protected][/EMAIL]"; remote_virtualip=192.168.178.119;
FB1_User2: name="[EMAIL="[email protected]"][email protected][/EMAIL]"; remote_virtualip=192.168.178.117;
FB1_User3: name="user3";           remote_virtualip=192.168.178.116;
FB1_User4: name="user4";           remote_virtualip=192.168.178.134;

FB2_User1: name="user1"            remote_virtualip=192.168.178.115;
FB2_User2: name="user2";           remote_virtualip=192.168.178.128;[/FONT]

dadurch wird proaktiv ein IP-Konflikt vermieden.

Wichtig: keine überlappenden IPs z.B. von Smartphones im WLAN (iphone_wlan) und VPN-Access (iphone_vpn)
da sonst IMHO das AVM-IPsec-VPN mit Proxy-ARP für Client2LAN-Zugriff nicht funktioniert.

LG Shirocco88
 
Zuletzt bearbeitet:
Harvey0815 schrieb:
Das ist ja das komische, die Fritten scheinen willkürlch IP Adressen zu vergeben bzw. bei Erstellung des Profils sich eine zu nehmen
Zum Vergrößern anklicken....
Das ist weder komisch noch willkürlich ... wenn auch von AVM nicht wirklich gut dokumentiert. Es hat auch mit dem DHCP-Protokoll im LAN überhaupt nichts zu tun und trotzdem spielen die Einstellungen für den DHCP-Server einer FRITZ!Box eine Rolle in diesem Zusammenhang, selbst wenn der DHCP-Server der FRITZ!Box gar nicht aktiviert ist.

Aber das habe ich jetzt alles mehrfach angeführt (auch in diesem Thread) und wenn Du Deine Lösung gefunden hast, ist das Thema ja auch erledigt. Ansonsten hilft die Forensuche oder eine Internet-Suchmaschine (ggf. mit Beschränkung auf diese Site) sicherlich weiter.

Harvey0815 schrieb:
Hoffe ich kann damit helfen, wenn es nochmal wo Probleme gibt, einfach Fragen vllt. kann ich aushelfen.
Zum Vergrößern anklicken....
So löblich ich dieses Vorhaben auch finde und so sehr logischerweise jeder willkommen ist, der anderen helfen will ... verstehe es bitte nicht falsch, wenn ich es besser finden würde, Du verstehst erst einmal wirklich, was da bisher bei Dir schief gelaufen ist und warum es jetzt funktioniert (Du bist ja fast bei der "Lösung" mit ordentlicher Planung aus #4, auch wenn das ohne explizites Routing auskommt, weil eben dank Proxy-ARP auch so die richtige MAC-Adresse des Gateways aufgelöst werden kann) und erst dann solltest Du anderen entsprechende Hinweise geben - oder zumindest vorher auch immer darauf hinweisen, wo Du selbst nur raten kannst und wo Du tatsächlich etwas weißt. Das ist einfach gegenüber den Fragestellern fairer ... ansonsten ist es ein wenig so, als wenn der eine Tourist dem anderen den Weg erklärt und ihn dabei in die entgegengesetzte Richtung schickt - da wäre die Auskunft "Frage lieber einen Einheimischen." dann wahrscheinlich hilfreicher.
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Statistik des Forums

Themen
248,926
Beiträge
2,305,422
Mitglieder
378,652
Neuestes Mitglied
ReddyBookClubsPoint

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