[Problem] 7270 als OpenVPN Client: Kein Server Zugriff via Browser/PC aber direkt von 7270 Sh.

[JMan]

Hallo,

Ich habe das erste mal ein Freetz Image gebaut (Neuester Trunk) um von PC's welche an einer 7270 haengen, welche wiederum als OpenVPN Client konfiguriert ist, auf mein Remote-Server Netzwerk zuzugreifen.

Soweit klappt auch fast alles.
Der VPN Tunnel steht und ich kann von meiner 7270 Busybox Shell auch alle IP-Adressen im Server Netzwerk pingen (192.168.1.0).

Jedoch kann ich von den PC's, welche an der 7270 haengen keinerlei Adressen im Server Netzwerk erreichen .
Wie gesagt, direkt von der 7270 Shell geht der Zugriff, aber nicht von den an der 7270 angeschlossen PC's (DNS Server und Gateway ist die 7270) .

Zugriffs Pfad ist wie folgt:

PC (192.168.3.11 [DHCP Client]) --> 7270 (192.168.3.1 [DHCP Server]) --> Internet --> D-Link DSR Router (192.168.14.0 - [OpenVPN VPN Server Network]) --> Server Network (192.168.1.0)

Habe schon das Forum durchsucht, aber nix gefunden.

Bin fuer jede Hilfe dankbar.

Gruss JMan.

Hier noch ein paar Details:

OpenVPN log file auf der 7270:

.............
Fri Nov 23 18:18:34 2012 [Server] Peer Connection Initiated with [AF_INET]80.xxx.xxx.xxx:1194
Fri Nov 23 18:18:36 2012 SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1)
Fri Nov 23 18:18:36 2012 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.14.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 192.168.14.6 192.168.14.5'
Fri Nov 23 18:18:36 2012 OPTIONS IMPORT: timers and/or timeouts modified
Fri Nov 23 18:18:36 2012 OPTIONS IMPORT: --ifconfig/up options modified
Fri Nov 23 18:18:36 2012 OPTIONS IMPORT: route options modified
Fri Nov 23 18:18:36 2012 TUN/TAP device tun0 opened
Fri Nov 23 18:18:36 2012 TUN/TAP TX queue length set to 100
Fri Nov 23 18:18:36 2012 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Nov 23 18:18:36 2012 /bin/ip link set dev tun0 up mtu 1500
Fri Nov 23 18:18:36 2012 /bin/ip addr add dev tun0 local 192.168.14.6 peer 192.168.14.5
Fri Nov 23 18:18:36 2012 /bin/ip route add 192.168.1.0/24 via 192.168.14.5
Fri Nov 23 18:18:36 2012 /bin/ip route add 192.168.14.0/24 via 192.168.14.5
Fri Nov 23 18:18:36 2012 chroot to '/tmp/openvpn' and cd to '/' succeeded
Fri Nov 23 18:18:36 2012 GID set to openvpn
Fri Nov 23 18:18:36 2012 UID set to openvpn
Fri Nov 23 18:18:36 2012 Initialization Sequence Completed

Routen:

root@fritz:/var/tmp# ip route
192.168.180.1 dev dsl  metric 2
192.168.180.2 dev dsl  metric 2
79.207.116.97 dev dsl  metric 2
192.168.3.201 dev dsl  metric 2
192.168.14.5 dev tun0  src 192.168.14.6
192.168.179.0/24 dev guest  src 192.168.179.1
192.168.3.0/24 dev lan  src 192.168.3.1
192.168.1.0/24 via 192.168.14.5 dev tun0
192.168.14.0/24 via 192.168.14.5 dev tun0
169.254.0.0/16 dev lan  src 169.254.1.1
default dev dsl  metric 2

 

[hermann72pb]

Du hast falsch gesucht. Es ist sowohl hier als auch auf der OpenVPN-Webseite bestimmt 1000 Mal durchgekaut... Aber keine Sorge, ich bin auch in die gleiche Falle vor kurzem geraten.
Lösung: Es geht so nicht mit statischen Schlüsseln. Du musst schon auf Zertifikate gehen, wenn du zwei Boxen miteinander verbindest und von einem Rechner hinter der Box A zum anderen Rechner hinter der anderen Box B zugreifen willst. Du kannst es bei TUN (Tunnel) belassen und musst nicht gleich auf TAP (Brücke) gehen, aber bitte mit Zertifikaten. Frag mich nicht warum und wieso, dafür kannst du sicherlich die Suche bemühen. Wenn ich mich richtig erinnere, gäbe es auch Wege, dies mit statischen Schlüsseln irgendwie "hinzubiegen", der Aufwand wäre aber zu hoch, weil man die ganzen Routen händisch "dazudichten" muss. Zertifikate wäre eine deutlich einfachere Variante (und zudem noch sicherer!).
Statische Schlüssel sind dafür gut, wenn du von unterwegs mit einem Rechner auf dein Netz zugreifen willst. Dann läuft die Klientanwendung direkt auf deinem Rechner. Routing ist nicht notwendig und alles klappt so. Wenn du das Ganze etwas erweiterst (wie in deinem Beispiel), dann musst du zunächst auf Zertifikate gehen. Wenn du es noch weiter treibst und z.B. willst, dass es mehrere Clients sich gleichzeitig anmelden, noch untereinader kommunizieren sollen, IPs automatisch per DHCP bekommen sollen, dann wird es durchaus sinnvoll sein, Richtung Brücke (TAP) nachzudenken.

MfG

 

[MaxMuster]

In dieser Konstellation sind Zertifikate nicht nötig, denke ich (solange das der einzige Client ist).
Was mit 99% Sicherheit bei dir "schief läuft", ist der "Rückweg" vom Servernetz zum Client:

Wenn der VPN-Client (bei dir die Box) etwas "hinter dem VPN" anspricht, nutzt sie die VPN-IP (hier die 192.168.14.6). Die "kennt" der Server und scheinbar nutzen alle Geräte im LAN des Servers diesen als Gateway. Meine Vermutung ist, dass dem VPN-Server eine Route für das LAN (192.168.3.0 zum VPN-Client) fehlt (in der Server-Config "route 192.168.3.0 255.255.255.0").
Kannst du einfach Testen, indem du aus diesem "Netz beim Server" die Client-FB anpingst, eimal mit der "VPN-IP" (oben die 192.168.14.6) und einmal die "LAN-IP", die 192.168.3.1
Wie gesagt, nur eine Vermutung und das geht in dieser Form nur mit einem VPN-Client, sonst brauchst du in der Tat Zertifikate.

 

[hermann72pb]

nene, MaxMuster, es ist schon tatsächlich so, dass man vom Client-Netz aus nicht ins Server-Netz gelangt, sobald man es nicht von der Box selbst macht, sondern von einem Rechner hinter der Client-Box.
Sicherlich fehlt da nur eine Route, allerdings bei der Client-Box. Wenn du etwas von der Client-Box direkt ausführst, dann bist du im Subnetz der VPN-Verbindung direkt und musst nichts routen. Wenn du es aber von einem Rechner hinter der Client-Box machst, dann muss die Client-Box routen.
Ob das schon immer so war, oder erst mit neueren OpenVPN-Versionen hinzu kam, weiß ich nicht. Ich hatte früher nie eine Box als OpenVPN-Client betrieben. Nur als Server. Wenn man zwei Boxen miteinander verbindet, dann tut man es eher als TAP und nicht als TUN. In dem Falle erübrigt sich die Frage.
Mittlerweile kann man sogar trotz TUN in das Client-Netz routen. Ich weiß nicht, ob es an meiner Sonderkonfiguration liegt, es war mir aber auch dies schon mal gelungen.

MfG

 

[MaxMuster]

Sorry, aber das glaube ich nicht.
Der Client hat die richtige Route für das "Servernetz" (192.168.1.0/24 via 192.168.14.5 dev tun0).

Die Erklärung, wie man das Routing testen kann, ist oben (Ping aus Servernetz auf LAN-IP der FB)
Alternativ kann auch der Client nicht die VPN sondern die LAN-IP als Absende-IP nutzen, das geht auch:

ping -I 192.168.3.1 192.168.1.1

 

[JMan]

Hallo,

ich glaube hier gibt es einige Missverständnisse .

Der VPN Tunnel an sich steht und funktioniert (PS: Ich benutze Zertifikate).

Ich glaube jedoch auch das eigentliche Problem gefunden zu haben.

Mit den 54.05.xx FW's geht folgendes nicht mehr:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Man bekommt dann folgenden Fehler:

iptables: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Wenn ich mich richtig belesen habe, fehlt mir genau dieser iptables Befehl damit das Routing richtig funktioniert.

Mit den aktuellen AVM FW's (xx.05.xx) und Freetz Trunks geht genau das jedoch nicht mehr geht.
Mehr hier:
http://freetz.org/ticket/1605

Falls jemand noch eine getestete Lösung mit Anleitung für einen Dummy hat, nur her damit.

Danke & Gruß

JMan

 

[µRaCoLi]

192.168.14.0/24 via 192.168.14.5 dev tun0

in deiner routingtabelle sieht komisch aus, weil es schon als tunnelnetz verwendet wird.
schlag dir das mit dem NATen aus dem kopf, du musst dein routing in ordnung bringen!

 

[JMan]

Mmmhhh,

also die 2 Routen

192.168.1.0/24 via 192.168.14.5 dev tun0
192.168.14.0/24 via 192.168.14.5 dev tun0

werden vom OpenVPN Server gepushed und sollten einwandfrei sein.
Hab noch mehrere Android Handy's und Tablet's als direkter OpenVPN Client laufen, ohne Probleme.

Mein Zugriffspfad ist wie gesagt ja:

PC (192.168.3.11 [DHCP Client]) --> 7270 (192.168.3.1 [DHCP Server]) --> Internet --> D-Link DSR Router (192.168.14.0 - [OpenVPN VPN Server Network]) --> Server Network (192.168.1.0)

Nochmal kurz, folgender Zugriff geht:

7270 (192.168.3.1 [DHCP Server]) --> Internet --> D-Link DSR Router (192.168.14.0 - [OpenVPN VPN Server Network]) --> Server Network (192.168.1.0)

aber halt nicht von den PC's welche per LAN oder WLAN an der 7270 angeschlossen sind.

Dafür bräuchte ich das NAT'en, wenn ich richtig liege.

Wenn natürlich wirklich noch was in den Routing Tables fehlt, bin gerne für Ideen offen.

Danke

JMan

 

[MaxMuster]

Dafür bräuchte ich das NAT'en, wenn ich richtig liege.

Nein, mit sehr großer Wahrscheinlichkeit nur das richtige Routing auf dem Server!

Wenn natürlich wirklich noch was in den Routing Tables fehlt, bin gerne für Ideen offen.

Ja, genau das ist der Fall, denke ich:

...
Meine Vermutung ist, dass dem VPN-Server eine Route für das LAN (192.168.3.0 zum VPN-Client) fehlt (in der Server-Config "route 192.168.3.0 255.255.255.0").
Kannst du einfach Testen, indem du aus diesem "Netz beim Server" die Client-FB anpingst, eimal mit der "VPN-IP" (oben die 192.168.14.6) und einmal die "LAN-IP", die 192.168.3.1
...