[Gelöst] Fritzbox als Openvpn Server erreiche mit Client netzwerk hinter der Box nicht

[Cracymike]

Hallo,

ich habe folgendes Problem ich habe auf einer Fritzbox einen OpenVpn Server am laufen. Kann auch mit einem Client darauf zugreifen das VPN wird also etabliert. Danach soll der Client ein freigegebenes Verzeichnis aus dem Lan hinter der Fritzbox Mounten und das scheitert an der stelle an der der Client versucht den Rechner zu erreichen.
Konfiguration ist wie folgt:

Client Ubuntu:

Ip: 192.168.1.4 255.255.255.0

Fritzbox Erreichbar über DynDNS

IP der Box 192.168.178.1

VPN 192.168.33.1

Rechner den ich erreichen will
192.168.178.21

hier mein server.conf

dev tun
port 1194
proto udp
ifconfig 192.168.33.1 192.168.33.2
secret server.key
comp-lzo
ping 5
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3
float

und hier meine Client.conf

remote xxxxx.de
dev tun2
port 1194
proto udp
ifconfig 192.168.33.2 192.168.33.1
secret /etc/openvpn/xxxx/ovpn-xxxx.key
comp-lzo
ping 5
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3
float
log-append /var/log/ovpn-xxxx.log
status /etc/openvpn/xxxxx/ovpn-xxxx.status
route 192.168.178.21 255.255.255.255

ich habe keine Idee mehr habt ihr noch eine.

Besten Dank schon im Voraus

 

[MaxMuster]

Ist die "Server-FB" auch das "Defaultgateway" in dem LAN des PCs? Schließlich muss von dort auch alles "zurück" zum VPN-Client, also zur 192.168.33.2.
Dann: Das VPN ist ja ein "fremdes" Netz für 192.168.178.21, was sicher in der Firewall freigeschaltet sein muss (wenn es z.B ein Windows ist, geht das sonst nicht).

 

[Cracymike]

Ja die IP der Fritz also 192.168.178.1 ist der Gateway.

Aber wenn ich das Richtig verstehe reicht das ja noch nicht oder?

 

[MaxMuster]

Du kannst ja mal einen Trace vom Client zu dem PC machen (Linux: traceroute 192.168.178.21), der sollte erste zum VPN-Server gehen (192.168.33.1), dann zu dem PC.
Aber der PC muss den Weg zurück kennen (kannst du mit einem trace vom PC zum VPN-Client testen, Windows: "tracert 192.168.33.2"), und den Zugriff zulassen. Um zu Testen, ob es die FW iat, kannst du die ja vielleicht kurz deaktivieren und testen, ob es dann geht. Wenn es das ist, musst du das VPN-Netz oder zumindest den Client dort zulassen...

 

[Cracymike]

Erst mal Danke schon für deine Hilfe.

Habe das mal getestet also ein Trace geht nicht vom Client zum Server also du kannst von der 192.168.33.2 die 192.168.33.1 umgedreht geht das auch nicht.
Man kann vom Netz hinter der Fritzbox den VPNServer(192.168.33.1) erreichen danach ist Schluss.

Wenn ich den VPN auf dem Client Starte sieht der Log so aus:

Tue Mar  5 14:58:15 2013 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 2012
Tue Mar  5 14:58:15 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar  5 14:58:15 2013 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar  5 14:58:15 2013 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar  5 14:58:15 2013 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar  5 14:58:15 2013 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar  5 14:58:15 2013 LZO compression initialized
Tue Mar  5 14:58:15 2013 Socket Buffers: R=[229376->131072] S=[229376->131072]
Tue Mar  5 14:58:16 2013 ROUTE default_gateway=192.168.1.1
Tue Mar  5 14:58:16 2013 TUN/TAP device tun2 opened
Tue Mar  5 14:58:16 2013 TUN/TAP TX queue length set to 100
Tue Mar  5 14:58:16 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar  5 14:58:16 2013 /sbin/ifconfig tun2 192.168.33.2 pointopoint 192.168.33.1 mtu 1500
Tue Mar  5 14:58:16 2013 /sbin/route add -net 192.168.178.21 netmask 255.255.255.255 gw 192.168.33.1
Tue Mar  5 14:58:16 2013 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar  5 14:58:16 2013 Local Options hash (VER=V4): '182097bd'
Tue Mar  5 14:58:16 2013 Expected Remote Options hash (VER=V4): 'd6b30bfa'
Tue Mar  5 14:58:16 2013 UDPv4 link local (bound): [undef]
Tue Mar  5 14:58:16 2013 UDPv4 link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Tue Mar  5 14:58:16 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:22 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:26 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:26 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:31 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:36 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:36 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:41 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:46 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:46 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:51 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:56 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:58:57 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:59:01 2013 Inactivity timeout (--ping-restart), restarting
Tue Mar  5 14:59:01 2013 TCP/UDP: Closing socket
Tue Mar  5 14:59:01 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Mar  5 14:59:01 2013 Restart pause, 2 second(s)
Tue Mar  5 14:59:03 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar  5 14:59:03 2013 Re-using pre-shared static key
Tue Mar  5 14:59:03 2013 LZO compression initialized
Tue Mar  5 14:59:03 2013 Socket Buffers: R=[229376->131072] S=[229376->131072]
Tue Mar  5 14:59:03 2013 Preserving previous TUN/TAP instance: tun2
Tue Mar  5 14:59:03 2013 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar  5 14:59:03 2013 Local Options hash (VER=V4): '182097bd'
Tue Mar  5 14:59:03 2013 Expected Remote Options hash (VER=V4): 'd6b30bfa'
Tue Mar  5 14:59:03 2013 UDPv4 link local (bound): [undef]
Tue Mar  5 14:59:03 2013 UDPv4 link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Tue Mar  5 14:59:03 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:59:08 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:59:13 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Tue Mar  5 14:59:13 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

Das sieht für mich so aus als wen der Client den Server gar nicht erreicht.
Aber ich habe ja keine Ahnung...

An dieser Stelle noch ein anderes Problem mit den VPN Server also der Fritz-Box, um dort den OpenVPN zu nutzen habe ich mich an einigen Anleitungen orientiert welche das ganze über den angesteckten USB Stick realisieren. Dabei wird auch die debug.cfg modifiziert. Dies habe ich nach Anleitung wie folgt gemacht:

mkdir /var/usb
mount /dev/sda /var/usb
/var/usb/start-openvpn.sh

Leider ignoriert die Fritzbox beim Start alles außer dem erstellen des Verzeichnisses /var/usb , der "mount" und der Aufruf des Scriptes werden ignoriert.
Wenn ich mich aber per Telnet einklinke und den mount und das Script manuell durchführe geht es.
Warum verstehe ich nicht.

Ich hoffe ihr habt Ideen..

Gruß Mike

 

[MaxMuster]

Ja, sieht so aus als würde keine Verbindung aufgebaut.
Ich hatte diach aber so verstanden, dass die Box selbs erreichbar ist und "nur" das Laufwerksmapping nicht geht?!?

Kann auch mit einem Client darauf zugreifen das VPN wird also etabliert.

Wie ist denn auf der FB die Portweiterleitung gemacht? Vielleicht auf eine "virtuelle IP"? Das war m.E. eine Situation, wo dieses Fehlerbild auftrat, wenn keine Weiterleitung auf "0.0.0.0" eingerichtet war.

...Dies habe ich nach Anleitung wie folgt gemacht:

mkdir /var/usb
mount /dev/sda /var/usb
/var/usb/start-openvpn.sh

Die Box mountet normalerweise den Stick von sich aus, soweit ich das weiß, auf jeden Fall wird die Box nie ein "/dev/sda" kennen.
Prüfe mal mit "mount", wo der Stick eingehängt ist (vermutlich unter "/var/media/ftp/...").
Dann muss sicher gestellt sein, dass ein von der debug.cfg aufgerufene Skript auch "endet" und nicht unendlich läuft (also z.B. das OpenVPN mit "--daemon" startet oder mit "&" in den Hintergrund bringt).

 

[Cracymike]

Hallo Danke noch mal für deine Geduld und sorry für das Durcheinander.

Damit du mal weist um was es geht.

Der Client der bei uns steht soll sich per Cronjob automatisch auf verschiedene Server(Fritzboxen) verbinden dann von einem Rechner hinter der Box eine freigabe mounten Dateien kopieren und dann die Verbindung wieder trennen. Diesen Konstrukt hat jemand gebaut der nicht mehr verfügbar ist, und ich habe das geerbt und darf es jetzt fertig machen.

Meine fälschliche Annahme das der Tunnel aufgebaut wird stammt daher das ich ein Testscript welches genau das oben beschriebene einmal durchführen soll und dieses Sagt mir VPN OK, nun wie wir jetzt eventuell wissen ist das wohl nicht so.

Wenn ich auf der Box Route eingebe kommt das Raus:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
87.xx.xx.xx    *               255.255.255.255 UH    2      0        0 dsl
192.168.33.2    *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

Zur FritzBox

Mount ergibt:

rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw,nodiratime)
ramfs on /var type ramfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
sysfs on /sys type sysfs (rw)
/dev/sda on /var/media/ftp/Intenso-MicroLine-00 type vfat (rw,nodiratime,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1,shortname=winnt)

Genau wie du sagst hängt sich der Stick automatisch bei /var/media/ftp... ein.

Habe also die debug.cfg angepasst, lasse das mkdir ,das mount weg und rufe das Script über den Automatischen Pfad auf.

Das Script was aufgerufen sieht so aus:

while !(ping -c 1 www.google.de); do
sleep 5
done
mknod /var/tmp/tun c 10 200
cd /var/media/ftp/Intenso-MicroLine-00
./openvpn --config server.conf --daemon --dev-node /var/tmp/tun

Was auch beim Neustart ignoriert wird, rufe ich das Script manuell auf klappt es im ersten Moment bricht dann aber mit diesem Fehler ab:

PING www.google.de (173.194.69.94): 56 data bytes
64 bytes from 173.194.69.94: seq=0 ttl=51 time=68.848 ms

--- www.google.de ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 68.848/68.848/68.848 ms
mknod: /var/tmp/tun: File exists
/var/media/ftp/Intenso-MicroLine-00/start-openvpn.sh: line 7: ./openvpn: Permission denied

Was ich nicht verstehe die zugriffsrechte sehen aber meiner Meinung nach gut aus

# ls -l /var/media/ftp/Intenso-MicroLine-00/openvpn
-rwxrwxrwx    1 root     root      3028043 Jan  5  2007 openvpn
-rwxrwxrwx    1 root     root         6264 Feb 28 16:33 ovpn-xxx_xxx_xxxxxxx.log
-rwxrwxrwx    1 root     root          252 Mar  7 08:38 ovpn-xxx_xxx_xxxxxxx.status
-rwxrwxrwx    1 root     root          275 Feb 28 16:36 server.conf
-rwxrwxrwx    1 root     root          636 Sep 19 16:22 server.key

Oh man Fragen über Fragen.....

Gruß Mike

 

[MaxMuster]

Also, das mit dem "/dev/sda" scheint es doch zu geben, ist aber wegen des automatischen mountens, "überflüssig". Es könnte allerdings sein, dass das Verzeichnis zu dem Zeitpunkt noch nicht gemountet war, vielleicht deshalb das "händische" mounten...
Zurück zum "Fehler": sieht so aus, als sein auf dem Stick noch ein Ordner "openvpn", in dem das Programm und die Config liegt; der Aufruf wäre damit:

...
cd /var/media/ftp/Intenso-MicroLine-00[B]/openvpn[/B]
./openvpn --config server.conf --daemon --dev-node /var/tmp/tun

Klappt das (erstmal in der Konsole) besser?

Insgesamt würde ich dann sowas etwas "generelleres" vorschlagen für die debug.cfg:

# Wie oft auf Mount pruefen
maxtrymount=5
# Wie oft auf Google pruefen
maxtryinet=5

# =========== Mountpoint finden ===========
getmp(){
mount | grep -E -o '/var/media/ftp/[^ ]*'
}

# =========== Pruefung, ob Mount erfolgt ist =======
wait4mount(){
MOUNTPOINT=$()
while [ $maxtrymount -gt 0 ] && [ -z "$(getmp)" ]; do
sleep 5
maxtrymount=$(($maxtrymount-1))
done 
}

# =========== Pruefung, ob Internet erreichbar =========
wait4google(){
while [ $maxtryinet -gt 0 ] && !(ping -c 1 www.google.de); do
sleep 5
maxtryinet=$(($maxtryinet-1))
done 
}
# ===========   Warten und dann OpenVPN-Skript ausfuehren  =======
# ===========  (im Hintergrund, damit debug.cfg weiterlaeuft) =======
(wait4mount && wait4google && sh "$(getmp)"/start-openvpn.sh )&

Im Prinzip kannst du dann den Inhalt des OpenVPN-Skriptes auch noch direkt in dei debug.cfg hineinbringen...

 

[Cracymike]

Mann die Zeit

Ich danke dir wie wahnsinnig zumindes den Automatischen Start des vpnservers auf der Fritzbox klappt jetzt perfekt dafür ein großes Dankeschön.

Bleibt das Problem mit dem Tunnel hast du dazu noch eine Idee.

Gruß Mike

 

[MaxMuster]

Also, jetzt "kommt die Fehlermeldung von oben", die "read UDPv4 [EHOSTUNREACH]: No route to host (code=113)"?

Dann zurück zur Frage, wie auf den Servern die "Portweiterleitung" gemacht ist? Ein "grep 1194 /var/flash/ar7.cfg" sollte reichen...

Könnte auch ein "MTU-Problem" sein. Dann könnte es helfen (auf beiden Seiten !) dieses in die Config aufzunehmen: tun-mtu 1500

 

[Cracymike]

Hi es war kein MTU Problem sondern wie so oft der offensichtlichste Fehler welcher zwischen Stuhl und Tastatur sitzt. Kurz gesagt ich.

Der "grep 1194 /var/flash/ar7.cfg" ergab folgendes "udp 0.0.0.0:1194 0.0.0.01:1194 0" ! Kann ja nicht gehen also umgestellt und siehe da es geht.

Danke Danke Danke...

 

[MaxMuster]

Prima, wenn es jetzt läuft. Markierst du den Thread bitte noch als "gelöst" im Titel? (Erster Beitrag -> Bearbeiten -> Erweitert )