[Gelöst] OpenVPN Problem

[hallihallo2]

Hallo,

leider habe ich Probleme mit der Einrichtung von OpenVPN, die ist nicht alleine lösen kann. Ich habe ewig gesucht, komme aber nicht weiter. Es sieht wie ein Routing Problem aus. Ich würde mich um jede Hilfe und Tipps freuen.

Zum Aufbau:

A) Heimnetz ist 192.168.200.0 255.255.255.0
Computer der Verbindung zum VPN Server herstellen soll, hat die 192.168.200.51

B) VPN Server ist auf einer Fritzbox (gefreetze Fritzbox 3770, FW 3370_06.30 IP: 192.168.178.57), die hinter einer anderen Fritzbox (192.168.178.1) als IP Client hängt

Ziel ist das sich der Computer A über VPN in das Netz von B einloggt, die Netzwerkfreigaben der Computer im Netz von B sehen kann und mit der externen IP von B surfen kann,-also wahrscheinlich das was alle wollen ;-)

Was geht bisher: Ich kann mich auf A erfolgreich mit dem VPN Server verbinden und die IP des VPN Servers pingen (192.168.178.57),
Was geht bisher nicht: Ich kann keinen anderen Computer im Netz von B pingen und auch nicht surfen.

Anbei das Ergebnis von tracert vom Computer A

Microsoft Windows [Version 10.0.17763.973]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\ptg>tracert 192.168.178.57

Routenverfolgung zu 192.168.178.57 über maximal 30 Hops

  1    42 ms    41 ms    42 ms  192.168.178.57

Ablaufverfolgung beendet.

C:\Users\ptg>tracert 192.168.178.1

Routenverfolgung zu 192.168.178.1 über maximal 30 Hops

  1    41 ms    43 ms    42 ms  192.168.1.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *     ^C
C:\Users\ptg>

Hier die Configs:

server als Code und als Screenshot angehängt:

# OpenVPN 2.4.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Jan 12 2020
# library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.10
#  Config date: Sat Jan 18 12:40:27 CET 2020
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 1194
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
topology subnet
push "topology subnet"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
mode server
ifconfig-pool 192.168.200.100 192.168.200.150
push "route 192.168.200.0 255.255.255.0"
client-config-dir clients_openvpn
route 255.255.255.0 192.168.200.111
route 255.255.255.0 192.168.200.112
client-to-client
push "dhcp-option DNS 192.168.178.1"
push "redirect-gateway"
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

clients_openvpn, examplarisch client1

ifconfig-push 192.168.1.111 255.255.255.0
iroute 255.255.255.0
push "route 255.255.255.0 192.1681.112"

client

 remote XXXXXXXX.myfritz.net
  proto udp
  dev tun
  tls-client
  ns-cert-type server
  tun-mtu 1500
  mssfix
  nobind
  pull
  cipher AES-256-CBC
  verb 3



# TLS-Auth als Client verwenden
key-direction 1

# Zertifikate und Schlüssel
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
XXXXXX
-----END OpenVPN Static key V1-----
</tls-auth>
<ca>
-----BEGIN CERTIFICATE-----
XXXXXXX
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
XXXXXX
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
XXXXXX
-----END PRIVATE KEY-----
</key>

 

[PeterPawn]

Die gezeigte Client-Konfiguration im Freetz-GUI ist Unsinn - mal abgesehen davon, daß die dort sichtbaren Adressen gar nicht zu den gezeigten Konfigurationen passen. Was soll das genau sein? Findet man dieses Bild tatsächlich so in irgendeiner Anleitung/Hilfe (was man nach der Überschrift "(Hilfe)" in diesem Bild schlußfolgern könnte)? Wenn ja, warum zeigst Du dann hier dieses Bild und nicht Deine eigenen Einstellungen? Ich finde dieses Bild jedenfalls nicht in der Anleitung von Freetz zum OpenVPN-Paket: https://freetz.github.io/wiki/packages/openvpn.html - daher meine Frage, wo man das so findet (zumal es m.E. deutlich falsche Einstellungen zeigt) oder welche Anleitung Dich auf die Idee genau dieser Einstellungen gebracht hat, wenn das doch ein Screenshot Deiner eigenen Einstellungen sein sollte (wogegen wiederum einiges spricht, komme ich gleich zu).

Und warum gibt es (auch bei Dir, falls das Bild doch ein falsches ist) überhaupt zwei Clients (zumindest nach dem, was in der Server-Konfiguration an "route"-Einträgen zu sehen ist für .111 und .112), wenn in der Beschreibung in #1 von einem Server und einem Client die Rede ist?

Und da kommen wir dann auch schon zu den Widersprüchen in der Konfiguration, die sich nicht mehr aus einem versehentlich falsch hinzugefügten Bild erklären lassen ... einerseits soll der Server für das Transportnetz 192.168.200.1/24 verwenden und andererseits steht in den Client-Konfigurationen dann etwas wie:

ifconfig-push 192.168.1.111 255.255.255.0
iroute 255.255.255.0
push "route 255.255.255.0 192.1681.112"

(Hint: 192.168.1.111 paßt als gepushte IP-Adresse für das TUN-Interface dann nicht zu dem, was der Server als sein Transportnetz betrachtet nach dem dort zu sehenden "ifconfig"-Statement.)

Und ein zweiter Stolperstein: Einerseits steht in der Beschreibung in #1, daß das dortige LAN die 192.168.200.0/24 verwenden würde, andererseits soll das jetzt gleichzeitig das Transportnetz ("topology subnet") für das VPN sein?

Nun mag einiges ja das Ergebnis falscher Einstellungen im Freetz-GUI sein ... aber das Ganze sieht nach einem Mischmasch von nicht zueinander passenden Bildern und Konfigurationen aus und generell nach einem falschen Verständnis, wie ein VPN mit einem Transportnetz (und genau dafür ist das verwendete GUI ausgelegt) eigentlich arbeitet. Das verwendete Transportnetz muß disjunkt zu allen LANs sein, die sich an diesem "Netzwerk" beteiligen sollen.

Leider kann man durch die Tatsache, daß die gezeigten Konfigurationsdateien kaum aus den Einstellungen im Bild resultieren können (und ich stelle mir immer noch die Frage, wo das Bild eigentlich herkommt und hoffe inständig, daß das nicht bei Freetz sooo falsch dokumentiert ist), auch nicht erkennen, wo da nun die falschen Einstellungen gemacht wurden.

Abgesehen davon, daß da bei "Client-VPN-IP" halt die Adresse eines solchen Clients im Transportnetz steht und dahinter steht dann (darum auch der Hinweis auf das korrekte Format über dem Eingabefeld für "Netz bei Client" - dieser "Kardinalfehler" im Screenshot ist es auch, der mich hoffen läßt, daß das so nicht in einer Anleitung steht), welches LAN der Client verwendet ... daraus werden ggf. die Routen für weitere Clients (eben in der "clients_openvpn" die "push"-Einträge) und für den Server selbst (hier direkt als "route"-Statement) generiert und wenn die das richtige Format haben, kann sich auch ein Client mit "pull" in seiner Konfiguration die passende IPv4-Konfiguration seines TUN-Interfaces vom Server laden. Dann sollten die Routen-Einträge da aber auch so aussehen: push "route 192.168.178.0 255.255.255.0 192.168.200.100", basierend auf dem "ifconfig-pool" in der Serverkonfiguration. Selbstverständlich ändern sich ALLE Adressen aus 192.168.200.0/24 mit, wenn man hier auf ein anderes Transportnetz umstellen sollte - das "LAN", was in #1 als "Heimnetz" beschrieben wurde, kriegen die Clients bei einer korrekten Serverkonfiguration automatisch übermittelt ... das muß man in der "Serverkonfiguration" im Freetz-GUI gar nicht extra angeben.

PS: Ich selbst verwende kein OpenVPN aus Freetz und daher sind meine "Einwände" mit Vorsicht zu genießen ... allerdings bilde ich mir ein, mich mit VPNs an sich und OpenVPN im Besonderen schon einigermaßen auszukennen - schließlich nutze ich das (seit vielen, vielen Jahren) auch selbst; nur halt ohne Freetz und daher sind meine Kenntnisse dieses GUIs zwar nur rudimentär, aber der Zusammenhang zwischen falscher Client-Konfiguration und den generierten (falschen!) Statements in den Konfigurationsdateien ist augenfällig. Abgesehen davon gehört zu einem solchen "VPN-Problem" auch immer das passende Protokoll - hier sogar derer zwei, nämlich vom "Server" und vom "Client". Das spart sooo viel Herumgerate, daß die Fehlersuche dann meist auch tatsächlich zum Erfolg führt.

 

[hallihallo2]

Hallo PeterPawn, vielen Dank für die Antwort und die Hinweise. Natürlich handelt es sich dabei um meine zusammengewürfelte Konfig,- anders würde es ja keinen Sinn machen, mich an das Forum zu wenden. Das die falsch ist war, mir ja klar, aber ich wollte dich mit einer derart falschen Konfig nicht beleidigen. Ich habe mir wirklich die größte Mühe gegeben.

Ich hatte das so verstanden, dass Computer A (192.168.200.51 ) vom OpenVPN Server als client1 die IP 192.168.1.111 bekommt, die dann ins Zielnetz (192.168.178.0 geroutet wird).

Um ehrlich zu sein, habe ich diese Konfig aus dem Freetz Wiki und anderen Beiträgen zusammen geklickt (u.a. https://crycode.de/openvpn-server-einrichten, https://crycode.de/openvpn-zugriff-auf-netzwerk-hinter-einem-client) , bei denen es hieß, das es läuft... es lief aber nie beim Befolgen der Original-Anleitungen, so dass ich einen Mischmasch gemacht und es über Webif zusammenfegklickt habe.

Zu deinen Fragen:
- OpenVPN soll mit Zertifikaten laufen, weil mehrere Clients verbinden, - auch gleichzeitig. Computer A war nur ein Beispiel, das der Vereinfachung gedient hat. Ich habe das so verstanden, dass OpenVPN die Adressen dynamisch im Range 192.168.1.100 - 192.168.1.150 vergibt, man aber mit client-config-dir auch "feste IPs vergeben kann.


So, also deinen ersten Teil habe ich verstanden, den 2. Teil hoffe, ich später zu verstehen,- aber du hast vollkommen Recht! Warum bei den Einstellungen im Webif von Freetz, so ein Müll in der Konfig (
cat /mod/etc/openvpn*.conf ) rauskommt ist mir schleierhaft. Das muss total falsch übergeben werden!!! Oder die Änderungen werden nicht komplett übernommen bzw. die alten gelöscht! Ich werde es mal mit dem neuen Webinterface kompilieren und von Hand ändern. Ich melde mich.

VG

 

[PeterPawn]

Ne, das Webinterface ist schon in Ordnung ... Deine Einstellungen darin passen nur nicht - und zwar auch nicht zu der Konfigurationdatei des Servers in #1. Der Screenshot zeigt andere Einstellungen, als zum Zeitpunkt des Auslesens der Konfiguration als Textdatei (für #1) aktiv gewesen sein können.

Das jetzt mit einem anderen Interface zu machen, ist zwar auch eine Option ... aber gerade wenn es um die Verwaltung eines Servers (auf einer FRITZ!Box) und mehrerer Clients - das Ganze auch noch mit Zertifikaten - geht, ist das "v1"-Interface eigentlich eine gute Wahl - das "v2" bietet zwar mehr Flexibilität, erfordert aber auch deutlich mehr (eigene) Kenntnisse über die Konfigurationsmöglichkeiten des OpenVPN.

Ich würde eher zum Verbleib beim "v1"-Interface raten und wenn Du den Hinweis mit dem Transportnetz berücksichtigst (man kann auch mal eine Suchmaschine bemühen, was ein solches Transportnetz im VPN-Kontext bedeutet), dann sollte das auch funktionieren.

Wenn also das Bild nicht zum Rest paßt, dann ist hier ja in Wahrheit die Box mit der Adresse 192.168.178.57 der Server (das muß da dann natürlich auch so konfiguriert werden) - die braucht (hier) dann trotzdem noch ein (gesondertes) Transportnetz und der Client (was das auch immer dann sein mag, denn "Computer" kann ja nun alles Mögliche bedeuten) behält auch seine 192.168.200.51, wenn er weiterhin in seinem eigenen LAN (192.168.200.0/24) kommunizieren können soll. Der kriegt dann nur - wie der Server auch - eine zusätzliche Adresse in diesem Transportnetz und dann muß durch das Routing entschieden werden, wohin die Pakete gehen. Wenn die Clients sich nicht auch untereinander kontaktieren sollen (also Client2 nicht auch auf andere Teilnehmer im LAN von Client1 zugreifen soll), braucht man die "Erweiterte Client-Konfiguration" gar nicht (und kann damit dort auch keinen Unsinn eintragen) - wen interessiert's, welche IP ein VPN-Client für seine Verbindung erhält? Das wird erst dann wichtig, wenn andere auf das Netz "hinter" einem solchen Client zugreifen sollen und dann wird es auch wieder interessant, hinter welchem Client sich jetzt welches LAN verbirgt. Aber auch dann muß man die Eintragungen dort immer noch im richtigen Format vornehmen ...

Etwas anderes wäre es, wenn der Computer 192.168.200.51 ausschließlich mit dem entfernten LAN kommunizieren soll - das wäre dann das Äquivalent zur IPSec-Bridge von AVM. Dabei wird der Computer komplett zum Bestandteil des anderen Netzes (und trotzdem gibt es ein "zusätzliches" Transportnetz auch in diesem Falle, auch wenn der Client bei AVM dann direkt in diesem Netz landet) und kann lokal nicht mehr kommunizieren. Das funktioniert allerdings auch nur dann, wenn dieser Computer per Kabel direkt mit dem Router verbunden wird - lokales WLAN und "Übergabe in ein entferntes Netz" widersprechen sich nun mal. Auch ein "redirect-gateway" beim OpenVPN ändert daran nichts (das verbirgt sich hinter dem "ajedes Paket des Client umleiten" im GUI) ... das verändert nur das "default gateway" für den gesamten Client und Zugriffe auf lokale "Mitbewohner" sind dann weiterhin möglich (und bei den meisten auch erwünscht). Ein Szenario wie bei der IPSec-Bridge von AVM kann man jedenfalls mit dem OpenVPN-GUI von Freetz (zumindest mit Version 1) nicht ohne weiteres konfigurieren - zumindest nicht ohne Kopfstände und ohne genaue Kenntnis, welches Statement aus welcher GUI-Einstellung generiert wird (und dazu muß man das Shell-File "openvpn_conf" aus dem v1-Paket verstehen).

 

[hallihallo2]

grr! ich raste aus. Ich habe die falsche Server Konfig in meinem ursprünglichen Post angehängt (die war aus einem älteren Zwischensave? oder Freetz hat die Einstellungen nicht sofort übernommen?). Das bedeutet, das Webinterface generiert doch richtig. Schande über mein Haupt.

So, jetzt hier die "richtige" falsche Konfig, die nicht geht.

# OpenVPN 2.4.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Jan 12 2020
# library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.10
#  Config date: Sat Jan 18 14:55:35 CET 2020
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 1194
ifconfig 192.168.1.1 255.255.255.0
push "route-gateway 192.168.1.1"
topology subnet
push "topology subnet"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
mode server
ifconfig-pool 192.168.1.100 192.168.1.150
push "route 192.168.1.0 255.255.255.0"
client-config-dir clients_openvpn
route 255.255.255.0 192.168.1.111
route 255.255.255.0 192.1681.112
client-to-client
push "redirect-gateway"
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher AES-256-CBC
float
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Ich versuche diese aber gemäß deinen Vorschlägen zu ändern...

also sorry, ich bekomme es immer noch nicht hin. Könntest du vielleicht eine funktionierende Basis Konfig posten, an der ich mich halten kann? Die im Freetz-Wiki sind alle mit "tap". Das ist wohl anders....

 

[maceis]

Ich glaube, dass Du "Jedes Paket des Clients umleiten" nicht möchtest und dass auch die Eintragungen bei "Optional: Routing von IP Netzen" nicht notwendig sind.
Das Routing zwischen den Netzen, wird m. W. durch den Haken bei "Client-zu-Client" aktiviert.
Ich würde auch die Eintragungen in "DHCP-Range für Clients"weglassen und zumindest zunächst feste IP Adressen verwenden.

Schau Dir doch ma die Konfiguration in meinem Thread an. Die funktioniert nämlich jetzt ;-).

HTH + Gruß
D.Mon

 

[hallihallo2]

Hallo nochmal, ich habe erneut viel gelesen und ich denke, ich habe mit eurer Hilfe viele Fehler ausgeräumt. Es geht leider immer noch nicht. Könnte sich bitte jemand nochmal die configs anschauen, - nicht das der Server auf der Fritzbox das Problem ist (also irgenwie ein falsch kompiliertes OpenVPN und das das "tun" Interface falsch ist. Das habe ich mal gelesen, leider nicht verstanden, wie man dann da weiter kommt). Außerdem ich mir unklar, ob es Probleme macht, dass der OpenVPN Server nicht der DHCP im Netz ist, sondern nur IP Client (aber wenn ich PeterPawns Hinweis richtig verstehe, ist der OpenVPN Server ja DHCP im Transportnetz, deswegen ist das egal, weil der zum anderen Netz routet....?)

Nocheinmal zum Setting (Beschriftungen geändert gemäß Hinweisen):


A) Heimnetz ist 192.168.200.0 255.255.255.0
Exemplarisch hier ein OpenVPN-Client, der die Verbindung zum VPN Server herstellen soll, hat die 192.168.200.51. Er heißt client1. client1 ist auch der Name im Zertifikat.

B) VPN Server ist auf einer Fritzbox (gefreetze Fritzbox 3770, FW 3370_06.30 IP: 192.168.178.57), die hinter einer anderen Fritzbox (192.168.178.1) als IP Client hängt

Ziel ist das sich der Client A über VPN in das Netz von B einloggt, die Netzwerkfreigaben der Computer im Netz von B sehen kann und mit der externen IP von B surfen kann,-also wahrscheinlich das was alle wollen ;-)

Was geht bisher: Ich kann mich auf A erfolgreich mit dem VPN Server verbinden und die IP des VPN Servers pingen (192.168.178.57), Der Client bekommt die eingestellte feste IP per Push (192.168.1.111)
Was geht bisher nicht: Ich kann keinen anderen Computer im Netz von B pingen.

Hier den Hinweisen zufolge geänderte Konfig:

Server:

# OpenVPN 2.4.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Jan 12 2020
# library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.10
#  Config date: Sun Jan 19 22:48:40 CET 2020
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 1194
ifconfig 192.168.1.1 255.255.255.0
push "route-gateway 192.168.1.1"
topology subnet
push "topology subnet"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
mode server
client-config-dir clients_openvpn
route 192.168.200.0 255.255.255.0 192.168.1.111
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
float
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

clients_openvpn/client1

ifconfig-push 192.168.1.111 255.255.255.0
iroute 192.168.200.0 255.255.255.0

client1.ovpn

 remote xxx.myfritz.net
  proto udp
  dev tun
  tls-client
  ns-cert-type server
  tun-mtu 1500
  mssfix
  nobind
  pull
  cipher AES-256-CBC
  verb 3

# TLS-Auth als Client verwenden
key-direction 1
 
# Zertifikate und Schlüssel
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
xxx
-----END OpenVPN Static key V1-----
</tls-auth>
<ca>
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
xxx
-----END PRIVATE KEY-----
</key>

Und zuletzt noch die Ergebnisse von tracert (Vom Client1 aus)

C:\Users\ptg>tracert 192.168.178.57

Routenverfolgung zu 192.168.178.57 über maximal 30 Hops

  1    41 ms    40 ms    42 ms  192.168.178.57

Ablaufverfolgung beendet.

C:\Users\ptg>tracert 192.168.178.1

Routenverfolgung zu fritz.box [192.168.178.1]
über maximal 30 Hops:

  1    42 ms    42 ms    49 ms  192.168.1.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *     ^C
C:\Users\ptg>

 

[PeterPawn]

Die anderen Hosts im Netz B senden wohl ihre Antworten weiterhin an die 192.168.178.1 (das wird deren Standard-Gateway sein), weil sie keinen anderen Weg zum Netz 192.168.200.0/24 kennen.

Wenn - wie hier - der VPN-Server nicht auf dem Standard-Gateway läuft, muß dort (oder auf jedem Client, der erreichbar sein soll) noch die Route für den Rückweg der Pakete nach 192.168.200.0/24 angegeben werden. Kleiner Tipp dazu: Die geht dann über den VPN-Server.

 

[hallihallo2]

Hallo und wiederum danke für die Antwort. Darum werde ich mich kümmern. Aber erscheint es akutell nicht so, dass der Hinweg schon nicht funktioniert?

Client1 kommt ja aus dem Netz A = 192.168.200.0/24er Netz und das trachert von oben ist von Client1 . Ich lese das so, dass beim Aufruf ins Netz von B (192.168.178.0/24) zwar die richtige Route über das Transportnetz auf den VPN Server geht, aber dann die Route nicht vom 192.168.1.0er Netz auf das 192.168.178.0er klappt (warum aber der Ping auf die .178er IP des VPN Servers klapptc, ist mir ein Rätsel).

Das Problem scheint auch nicht (nicht nur?) am Client1 (einem Windows 10 PC) zu liegen. Wenn ich mich nämlich mit Client2 auf einem Iphone über LTE mich auf den VPN-Server einlogge, kann ich genauso NUR den VPN-Server 192.168.178.57 im Netz B erreichen wie auch am Client 1.

Hat da bitte noch jemand einen Tipp? Gibt es eine Möglichkeit, sich die Routes auf der Fritzbox anzuschauen, wenn das helfen könnte?

 

[PeterPawn]

Was "erscheint" Dir denn da und welches "tracert" meinst Du genau?

Inwiefern widerspricht denn die Tatsache, daß das VPN-Gateway offenbar erreicht wird, aber ein Client einen Hop weiter dann nicht mehr, meiner Aussage, daß die Pakete den Rückweg nicht finden? So lese ich das "tracert" in #7 jedenfalls, aber ich lasse mich auch gerne eines Besseren belehren.

Die Antwort aber bitte mit Begründung und nicht "nach Gefühl" - es interessiert nämlich solche Geräte i.d.R. auch nicht, wie man sich dabei fühlt, die machen das strikt nach den programmierten Abläufen und Prinzipien.

Und um Deinem Gefühl mal etwas "Rationales" zum Kauen zu geben ... wie sollte denn der Client mit dem "ping" oder "tracert" darüber informiert werden, ob ein Paket angekommen ist oder nicht, wenn nicht durch eine (am besten noch passende) Antwort?

Woran siehst Du jetzt in der Ausgabe des "tracert" (oder auch in der Reaktion Deines Smartphones), daß die Pakete schon den Hinweg nicht schaffen?

Das KANN man zwar tatsächlich ermitteln durch einen Paketmitschnitt am Ziel (oder auch auf den "Zwischenstationen"), aber von einem solchen lese ich irgendwie auch nichts.

Wenn auch hier wieder das Gefühl den Ausschlag geben sollte, würde ich Dir empfehlen, einfach mal zum (am besten noch passenden) Werkzeug zu greifen und Deine Annahmen zu verifizieren oder zu falsifizieren ... je nach Ausgang der Sache kannst Du ja dann weitermachen.

 

[hallihallo2]

Puh, du hast du doch massiv mehr Ahnung als ich. Das ist unbestritten. Mit Gefühl meinte ich Verständnis. Du hattest auch wie immer Recht. Das Problem war das Routing ist der Haupt-Fritzbox. Auch wenn ich es nicht verstehe. Mit einer statischen Route von der Hauptfritzbox von LANB auf die Ip des VPN Servers auf das Transportnetz,- KLAPPT ES!!! Ich teste noch den Rückweg und melde mich. Sieht aber schon sehr gut aus! Herzlichen Dank schonmal!

 

[PeterPawn]

Na dann ... viel Spaß beim Testen.

Sollten diese Tests auch den Zugriff auf Windows-Freigaben im anderen Netz beinhalten und Du dabei dann feststellen, daß diese nicht funktionieren wollen, empfehle ich Dir die Suche nach entsprechenden Threads hier im IPPF, die sich mit den Windows-Firewall-Einstellungen beim Zugriff aus einem anderen Subnetz befassen. Die KB bei AVM enthält - nebenbei bemerkt - dann ähnliche Informationen zum "Troubleshooting" von SMB-Zugriffen im VPN-Umfeld.

Wobei ich mal hoffe, daß die eingetragene Route in der FRITZ!Box mit der Adresse 192.168.178.1 dann "192.168.200.0 255.255.255.0 192.168.178.57" lautet und nicht wirklich eine für das Transport-Netz ist. Das kennen die Clients im Netz B zwar auch nicht (und deshalb würden sie Pakete dafür auch an das Standard-Gateway senden), aber das müssen sie (und auch die FRITZ!Box selbst als Gateway) eigentlich auch nicht kennen ... denn es ist eben nur das, was der Name schon sagt: ein Transportnetz - und die FRITZ!Box an 192.168.178.57 kriegt ganz normal die Pakete aus LAN B mit Zieladressen in 192.168.200.0/24 und packt die so ein, daß "außen herum" die Transport-"Verpackung" steht und nur diese verwendet auch die IP-Adressen aus dem Transport-Netz. Die Clients in Netz A und Netz B sollten diese Adressen gar nicht kennen (außer natütlich die jeweiligen OpenVPN-Gateways) - man sollte auch tunlichst auf eine Route dafür verzichten, solange die Peers im Transportnetz auch noch andere IP-Adressen haben, unter denen sie ihre eigenen Dienste feilbieten ... dann nimmt man besser diese Adressen für den Zugriff auf irgendwelche Dienste auf den VPN-Gateways.

 

[maceis]

Gibt es eine Möglichkeit, sich die Routes auf der Fritzbox anzuschauen, wenn das helfen könnte?

Ja, und zwar indem man sich per ssh oder notfalls telnet auf der Box einlogt und das Kommando 'route' eingibt. M. E. macht es bei Problemen auch Sinn, die Ping-Tests zuerst direkt von den Boxen aus zu machen.

Und wenn Du auf den beteiligten Boxen (oder anderen Geräten) tcpdump installierst, kannst Du auch die von Peter empfohlenen (und sehr aufschlussreichen) Paketmitschnitte machen. Dann siehst Du schnell, wo irgendwelche ping-requests eingehen, ob diese beantwortet werden und wohin die Antworten evtl. geroutet werden. Musst nur aufpassen, dass Du die richtigen Schnittstellen abhörst.

 

[PeterPawn]

Wobei m.W. alle FRITZ!Boxen (außer ein paar Versionen, die von/für einem/n Provider verkrüppelt wurden) den Paketmitschnitt auch über das GUI (über die Support-Seite zu finden) erlauben ... dafür braucht man also nicht unbedingt eine Shell, wobei ein "ping" oder ein "traceroute" von der Box schon hilfreich sind und bei fast allen anderen SOHO-Routern auch zu finden wären - hier spielt AVM eine "Sonderrolle" und ich hatte die Hoffnung, daß man mit Wegfall des Shell-Zugangs (auch in den Inhouse-Versionen) so ein "connectivity test" irgendwie Einzug halten würde - aber leider ist das (bisher?) nicht der Fall.

EDIT: Ansonsten stehen die aktiven Routen natürlich auch in der Support-Datei ... auch dafür bräuchte man also keinen eigenen Shell-Zugriff.